From dotis@mail-abuse.org Thu Apr 1 09:33: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 1B38A3A69CC for ; Thu, 1 Apr 2010 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 tcjQPAKhSrBg for ; Thu, 1 Apr 2010 09:33:13 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 4D2253A69B4 for ; Thu, 1 Apr 2010 09:33:13 -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 56F16A94676 for ; Thu, 1 Apr 2010 16:33:42 +0000 (UTC) Message-ID: <4BB4CAE5.8010304@mail-abuse.org> Date: Thu, 01 Apr 2010 09:33:41 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: core@ietf.org References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] HTTP over UDP 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, 01 Apr 2010 16:33:14 -0000 On 3/31/10 3:15 PM, Dave Horwitz wrote: >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: Wednesday, March 31, 2010 12:11 AM >> > My view is if any nodes *need* TCP then it's not "optional" > in the protocol and must be specified as required for those > nodes. Otherwise it's implied that some requirement is not > being met? > Agreed. It is not reasonable for TCP to be a requirement. The socket API for an underlying transport, in this case running over UDP, should be able to mimic the API used for TCP. >> TCP likely will be more efficient that any lock-step protocol >> based on range requests - do we need that efficiency? TCP also >> makes the state explicit that would be involved in a caching >> scheme, but there may be other ways to do that. Again, I have >> not made up my mind yet. >> TCP requires reassembly buffers when a packet gets dropped. SCTP constructs over UDP would permit data framing for zero copy placement during packet loss, where only lost data is then retransmitted. Retransmissions would not include everything up to the last received byte, as with TCP. Proper data framing also offers significant innovations for multi-casting as well. -Doug From L.Wood@surrey.ac.uk Thu Apr 1 10:00: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 730743A6973 for ; Thu, 1 Apr 2010 10:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.104 X-Spam-Level: X-Spam-Status: No, score=-5.104 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 ADzsuNvfRWEc for ; Thu, 1 Apr 2010 10:00:23 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 3CA013A6839 for ; Thu, 1 Apr 2010 10:00:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-10.tower-82.messagelabs.com!1270141254!4053860!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 24691 invoked from network); 1 Apr 2010 17:00:54 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-10.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 1 Apr 2010 17:00:54 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Thu, 1 Apr 2010 18:00:54 +0100 From: To: , Date: Thu, 1 Apr 2010 17:58:16 +0100 Thread-Topic: [core] HTTP over UDP Thread-Index: AcrRuRz8End7HJg5QD23TaB5QShIigAA2ld5 Message-ID: References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> , <4BB4CAE5.8010304@mail-abuse.org> In-Reply-To: <4BB4CAE5.8010304@mail-abuse.org> Accept-Language: en-US, en-GB Content-Language: en-GB 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] HTTP over UDP 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, 01 Apr 2010 17:00:24 -0000 > TCP requires reassembly buffers when a packet gets dropped. SCTP > constructs over UDP would permit data framing for zero copy placement > during packet loss, where only lost data is then retransmitted. > Retransmissions would not include everything up to the last received > byte, as with TCP. um, SACK? L.= From dotis@mail-abuse.org Thu Apr 1 11:05:26 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 ED65A3A697B for ; Thu, 1 Apr 2010 11:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.447 X-Spam-Level: X-Spam-Status: No, score=-4.447 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 wbbM2uE4j2ry for ; Thu, 1 Apr 2010 11:05:24 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 9E2993A691D for ; Thu, 1 Apr 2010 11:05:24 -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 DF509A944E8; Thu, 1 Apr 2010 18:05:55 +0000 (UTC) Message-ID: <4BB4E083.9010100@mail-abuse.org> Date: Thu, 01 Apr 2010 11:05:55 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> , <4BB4CAE5.8010304@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] HTTP over UDP 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, 01 Apr 2010 18:05:26 -0000 On 4/1/10 9:58 AM, L.Wood@surrey.ac.uk wrote: >> TCP requires reassembly buffers when a packet gets dropped. SCTP >> constructs over UDP would permit data framing for zero copy placement >> during packet loss, where only lost data is then retransmitted. >> Retransmissions would not include everything up to the last received >> byte, as with TCP. >> > um, SACK? > TCP options are not always compatible with TCP anti-spoofing strategies. Even if optionally supported, TCP-SACK does not eliminate reassembly buffers without data framing, as object boundaries might have been lost. SCTP changed important rules engineered to run over UDP. :^) -Doug From L.Wood@surrey.ac.uk Thu Apr 1 11:41: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 087C23A67D7 for ; Thu, 1 Apr 2010 11:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 LJM6+1zfAYGH for ; Thu, 1 Apr 2010 11:41:29 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id AE6633A6A6F for ; Thu, 1 Apr 2010 11:41:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-13.tower-78.messagelabs.com!1270147318!3804195!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 3467 invoked from network); 1 Apr 2010 18:41:58 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-13.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 1 Apr 2010 18:41:58 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 1 Apr 2010 19:41:58 +0100 From: To: Date: Thu, 1 Apr 2010 19:41:57 +0100 Thread-Topic: [core] HTTP over UDP Thread-Index: AcrRxfupQjVcS9FoQr66Eu1aBJf42wABLP1Q Message-ID: References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> , <4BB4CAE5.8010304@mail-abuse.org> <4BB4E083.9010100@mail-abuse.org> In-Reply-To: <4BB4E083.9010100@mail-abuse.org> 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 Subject: Re: [core] HTTP over UDP 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, 01 Apr 2010 18:41:30 -0000 On 4/1/10 9:58 AM, L.Wood@surrey.ac.uk wrote: >>> TCP requires reassembly buffers when a packet gets dropped. SCTP=20 >>> constructs over UDP would permit data framing for zero copy placement=20 >>> during packet loss, where only lost data is then retransmitted. >>> Retransmissions would not include everything up to the last received=20 >>> byte, as with TCP. >>> =20 >> um, SACK? >> =20 >TCP options are not always compatible with TCP anti-spoofing strategies. and SCTP is not implemented on, well, anything. It's a protocol looking for= a purpose. What's your point, exactly? L. http://sat-net.com/L.Wood = From dotis@mail-abuse.org Fri Apr 2 12:01: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 957223A6BE9 for ; Fri, 2 Apr 2010 12:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 DcevRO-f6-uv for ; Fri, 2 Apr 2010 12:01:19 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id B61223A6C52 for ; Fri, 2 Apr 2010 11:34:02 -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 BD0B7A9467B; Fri, 2 Apr 2010 18:34:32 +0000 (UTC) Message-ID: <4BB638B8.6030807@mail-abuse.org> Date: Fri, 02 Apr 2010 11:34:32 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> , <4BB4CAE5.8010304@mail-abuse.org> <4BB4E083.9010100@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] HTTP over UDP 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, 02 Apr 2010 19:01:20 -0000 On 4/1/10 11:41 AM, L.Wood@surrey.ac.uk wrote: >> TCP options are not always compatible with TCP anti-spoofing strategies. >> > and SCTP is not implemented on, well, anything. It's a protocol looking for a purpose. > > What's your point, exactly? > Lloyd, SCTP just might be used by more people than TCP; something to consider when you place a call. As such, SCTP offers a ready set of constructs. SCTP is a protocol designed to offer robust and reliable control, directing messages of any size efficiently over common associations. SCTP was initially designed to run on UDP, but was then assigned an IP protocol ID of its own. This was good, as now SCTP is supported by 10Gb/sec NIC adapters along with math coprocessors able to offload its improved error checks. SCTP adopted a polynomial with improved Hamming distance with comparable coverage for jumbo frames as IEEE CRC for 12Kb frames. With faster instruction rates, overheads related to software CRC represents a diminishing portion of overhead when offloading is not available, while offering significant improvements in error detection rates. TCP might fail detection for 2% of bit specific bus errors. With TCP's lack of framing, there is little assurance secondary checks are not neglected due to the complexity, or that data placement remains simple and without increased risks. Home automation systems need to offer dependable and reliable services using minimal resources. I worked on facility automation for military installations that were quickly decommissioned once communication errors became evident. Don't ignore bus related error sources that occur beyond the PHY. Power companies need to trust communications are not garbled by relaying devices. With many homes able to produce power, it could prove fatal when excess energy gets placed onto the grid being serviced. The goal of this effort should be efficient and reliable use of limited resources. IMHO, applications will benefit more from socket compatibility in an environment lacking TCP support. -Doug From L.Wood@surrey.ac.uk Fri Apr 2 14:55: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 D96A23A67C1 for ; Fri, 2 Apr 2010 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 Cv7A6kqhR8TI for ; Fri, 2 Apr 2010 14:55:36 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 179993A62C1 for ; Fri, 2 Apr 2010 14:55:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-78.messagelabs.com!1270245365!3855511!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 3135 invoked from network); 2 Apr 2010 21:56:06 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-14.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 2 Apr 2010 21:56:06 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Fri, 2 Apr 2010 22:56:05 +0100 From: To: Date: Fri, 2 Apr 2010 22:56:04 +0100 Thread-Topic: [core] HTTP over UDP Thread-Index: AcrSkyVcKclwXqDOTSyz0NUUf0UPVwAGCpr0 Message-ID: References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> , <4BB4CAE5.8010304@mail-abuse.org> <4BB4E083.9010100@mail-abuse.org> , <4BB638B8.6030807@mail-abuse.org> In-Reply-To: <4BB638B8.6030807@mail-abuse.org> Accept-Language: en-US, en-GB Content-Language: en-GB 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 Subject: Re: [core] HTTP over UDP 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, 02 Apr 2010 21:55:37 -0000 Doug, Yes, SCTP's CRC32c across packets is stronger than TCP's/UDP's 16-bit one's= -complement checksum; I recall contributing to your RFC3309. It's refreshing to see an understanding of the importance of errors and the= ir detection; something that has been lacking elsewhere. (Thinking of the I= RTF DTNRG here, which has spent years ignoring the importance of errors, in= cluding in relaying devices, and not understanding timing and the requireme= nts of environments where these are important, and is now attempting to cor= rect its bundle protocol for these oversights.) However, SCTP is now an overengineered TCP-alike with bells and whistles th= at has been searching for new applications since its SS7 roots (it does ha= ve a small niche in carrying custom protocols doing WAN acceleration in the= Internet). If TCP is too large for an implementations, SCTP will also be. = And not running over UDP poses firewall problems, no? Hardware offload isn'= t much use when resources really are minimal; TCP can be offloaded similarl= y, but will the hardware be there? And that doesn't help check the reliabil= ity of the data passed to such hardware, which needs its own internal integ= rity checks to defend against memory errors, etc. SCTP framing doesn't help= with that, since that's still in the comms subsystem. Is use of sockets really that compelling? Anyway, we're diverging a bit from the subject line... cheers, L. http://sat-net.com/L.Wood ________________________________________ From: Douglas Otis [dotis@mail-abuse.org] Sent: 02 April 2010 19:34 To: Wood L Dr (Electronic Eng) Cc: core@ietf.org Subject: Re: [core] HTTP over UDP On 4/1/10 11:41 AM, L.Wood@surrey.ac.uk wrote: >> TCP options are not always compatible with TCP anti-spoofing strategies. >> > and SCTP is not implemented on, well, anything. It's a protocol looking f= or a purpose. > > What's your point, exactly? > Lloyd, SCTP just might be used by more people than TCP; something to consider when you place a call. As such, SCTP offers a ready set of constructs. SCTP is a protocol designed to offer robust and reliable control, directing messages of any size efficiently over common associations. SCTP was initially designed to run on UDP, but was then assigned an IP protocol ID of its own. This was good, as now SCTP is supported by 10Gb/sec NIC adapters along with math coprocessors able to offload its improved error checks. SCTP adopted a polynomial with improved Hamming distance with comparable coverage for jumbo frames as IEEE CRC for 12Kb frames. With faster instruction rates, overheads related to software CRC represents a diminishing portion of overhead when offloading is not available, while offering significant improvements in error detection rates. TCP might fail detection for 2% of bit specific bus errors. With TCP's lack of framing, there is little assurance secondary checks are not neglected due to the complexity, or that data placement remains simple and without increased risks. Home automation systems need to offer dependable and reliable services using minimal resources. I worked on facility automation for military installations that were quickly decommissioned once communication errors became evident. Don't ignore bus related error sources that occur beyond the PHY. Power companies need to trust communications are not garbled by relaying devices. With many homes able to produce power, it could prove fatal when excess energy gets placed onto the grid being serviced. The goal of this effort should be efficient and reliable use of limited resources. IMHO, applications will benefit more from socket compatibility in an environment lacking TCP support. -Doug From dotis@mail-abuse.org Fri Apr 2 18:53: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 EBB553A67D3 for ; Fri, 2 Apr 2010 18:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 gbKZdUwMSLfY for ; Fri, 2 Apr 2010 18:53:33 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 400F23A683C for ; Fri, 2 Apr 2010 18:53:27 -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 D5FB9A94477; Sat, 3 Apr 2010 01:53:21 +0000 (UTC) Message-ID: <4BB69F8F.207@mail-abuse.org> Date: Fri, 02 Apr 2010 18:53:19 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> , <4BB4CAE5.8010304@mail-abuse.org> <4BB4E083.9010100@mail-abuse.org> , <4BB638B8.6030807@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] HTTP over UDP 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, 03 Apr 2010 01:53:34 -0000 On 4/2/10 2:56 PM, L.Wood@surrey.ac.uk wrote: > If TCP is too large for an implementations, SCTP will also be. And not running over UDP poses firewall problems, no? Implementing a complete SCTP stack had not been suggested. Rather than conditionally using TCP on occasion, and UDP for everything else, a friendlier environment could be established using constructs established for SCTP used over UDP. This would identify data-elements within every packet (data framing), provide good error checking, and allow similar association initializations. TCP is unable to offer comprehensive security without conflicting options, nor can TCP provide simple and direct data placement, which helps in dealing with limited resources. Extensibility, such as mimicking the existence of a TCP transport as a layer above the transport constructs, could be achieved by leveraging APIs established for SCTP. Basic configurations should eliminate multi-homing and perhaps restrict support to a few streams. Rather than going to a single stream, permitting a few would allow multiple conversation to be bundled into a single packet. This could supplant use of BEEP, for example. > Hardware offload isn't much use when resources really are minimal; TCP can be offloaded similarly, but will the hardware be there? And that doesn't help check the reliability of the data passed to such hardware, which needs its own internal integrity checks to defend against memory errors, etc. SCTP framing doesn't help with that, since that's still in the comms subsystem. > Processors are now many times faster than data passed over slow networks, which these devices are likely to use, where software CRC should not represent a constraint. When networks become faster, it should be reasonable to expect servers will have math coprocessors, or hardware able to support speeds up to 10 Gb/s. > Is use of sockets really that compelling? > Target devices are likely to represent some type of embedded OS. By defining transport constructs, in addition to socket APIs, greater software diversity immediately becomes available, along with system interchangeability. And yes, having a socket that mimics TCP permits HTTP over UDP. UDP using transport constructs and socket APIs. -Doug From shidan@gmail.com Fri Apr 2 20:29: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 575403A6812 for ; Fri, 2 Apr 2010 20:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] 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 4tnup-pSk4VI for ; Fri, 2 Apr 2010 20:29:52 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 233ED3A685B for ; Fri, 2 Apr 2010 20:29:46 -0700 (PDT) Received: by qyk11 with SMTP id 11so2605216qyk.13 for ; Fri, 02 Apr 2010 20:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=+ClwkGOPq3MCBskwvRKj/BhG5qzVskcoE/OsWt3yYOM=; b=e959lWgYdnzZzm3gUBdVaf4yoFK08Hxpl3XHcyaquYc1M324F0+iNVdyaRrW1Q6uJ7 RFfs1fv51d9+eyfH2DC2Q4vhymT+MV4wYH6SpDUL0uK2FHoEzUPrp5U9FMhxGcMsCtJE 1OrIT8fgYvyaDH56yZYS08pZT58WitpwwOd0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=wzdbgCvlx6N6mL3NR6sVrhCkYbXFtRbpobEt7FrE9/aAxh6U/SgY5yQDLY1Qav1Xjh iSGAnXGjf9G5J5DxsZtTz5yFlTjTBN/Y0UgfyRpPlNctrpKrtKncJPVxJ4woNcbM8So4 SdICrQxSFw2PGEBBWFlGzgB2BX/ZTPkEeeO4Y= Received: by 10.224.60.5 with SMTP id n5mr971833qah.288.1270265382977; Fri, 02 Apr 2010 20:29:42 -0700 (PDT) Received: from [10.127.54.103] ([24.114.234.29]) by mx.google.com with ESMTPS id 23sm5315752qyk.11.2010.04.02.20.29.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 20:29:41 -0700 (PDT) References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> , <4BB4CAE5.8010304@mail-abuse.org> <4BB4E083.9010100@mail-abuse.org> , <4BB638B8.6030807@mail-abuse.org> <4BB69F8F.207@mail-abuse.org> Message-Id: From: Shidan Gouran To: Douglas Otis In-Reply-To: <4BB69F8F.207@mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 2 Apr 2010 23:29:24 -0400 Cc: "core@ietf.org" , "L.Wood@surrey.ac.uk" Subject: Re: [core] HTTP over UDP 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, 03 Apr 2010 03:29:53 -0000 +1 makes sense to me. Sent from my phone On Apr 2, 2010, at 9:53 PM, Douglas Otis wrote: > On 4/2/10 2:56 PM, L.Wood@surrey.ac.uk wrote: >> If TCP is too large for an implementations, SCTP will also be. And >> not running over UDP poses firewall problems, no? > Implementing a complete SCTP stack had not been suggested. Rather > than conditionally using TCP on occasion, and UDP for everything > else, a friendlier environment could be established using > constructs established for SCTP used over UDP. This would identify > data-elements within every packet (data framing), provide good error > checking, and allow similar association initializations. TCP is > unable to offer comprehensive security without conflicting options, > nor can TCP provide simple and direct data placement, which helps in > dealing with limited resources. Extensibility, such as mimicking > the existence of a TCP transport as a layer above the transport > constructs, could be achieved by leveraging APIs established for > SCTP. Basic configurations should eliminate multi-homing and > perhaps restrict support to a few streams. Rather than going to a > single stream, permitting a few would allow multiple conversation to > be bundled into a single packet. This could supplant use of BEEP, > for example. >> Hardware offload isn't much use when resources really are minimal; >> TCP can be offloaded similarly, but will the hardware be there? And >> that doesn't help check the reliability of the data passed to such >> hardware, which needs its own internal integrity checks to defend >> against memory errors, etc. SCTP framing doesn't help with that, >> since that's still in the comms subsystem. >> > Processors are now many times faster than data passed over slow > networks, which these devices are likely to use, where software CRC > should not represent a constraint. When networks become faster, it > should be reasonable to expect servers will have math coprocessors, > or hardware able to support speeds up to 10 Gb/s. >> Is use of sockets really that compelling? >> > Target devices are likely to represent some type of embedded OS. By > defining transport constructs, in addition to socket APIs, greater > software diversity immediately becomes available, along with system > interchangeability. And yes, having a socket that mimics TCP > permits HTTP over UDP. UDP using transport constructs and socket > APIs. > > -Doug > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From gtolle@archrock.com Mon Apr 5 12:38:56 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 956273A69BF for ; Mon, 5 Apr 2010 12:38:56 -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=[BAYES_50=0.001, 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 oVlMSAsGbB8i for ; Mon, 5 Apr 2010 12:38:55 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id C42063A69B5 for ; Mon, 5 Apr 2010 12:38:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 534ABAF954 for ; Mon, 5 Apr 2010 12:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgSyzwByXQun for ; Mon, 5 Apr 2010 12:38:50 -0700 (PDT) Received: from [192.168.1.105] (cpe-76-174-142-254.socal.res.rr.com [76.174.142.254]) by mail.sf.archrock.com (Postfix) with ESMTP id 8CD36AF834 for ; Mon, 5 Apr 2010 12:38:49 -0700 (PDT) Message-Id: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> From: Gilman Tolle To: core@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 12:38:48 -0700 X-Mailer: Apple Mail (2.936) Subject: [core] HTTP and CoAP - mapping and compression 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, 05 Apr 2010 19:38:56 -0000 I have a question about the HTTP<->CoAP mapping we're chartered to define... Because the operations in draft-shelby-core-coap-00 are different from the standard HTTP methods, I'd suggest that any mapping is likely to lead to a leaky abstraction between the two protocols. In addition, a mapping could become a source of divergence between CoAP and HTTP as further innovation happens in these two separate spaces. Do the CoAP protocol operations really need to be different from the HTTP protocol operations? If we think about this as a compression problem instead of a mapping problem, we could define CoAP as semantically identical to HTTP, but with a more compact concrete representation. Because we're running in constrained networks, we don't have to maintain every arbitrary HTTP optional header across the compression boundary, but we can easily maintain the core protocol operations and naming systems that make HTTP so powerful. Essentially, we'd be defining the CoAP protocol as an easily-compressible profile of HTTP along with a stateless transformation between the compressed and uncompressed versions. I'd like to point everyone to my EBHTTP draft (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00 ), which presents an alternative compressed-HTTP approach to the design of CoAP (as does the original Chopan draft, for that matter). I think there are a few other benefits of EBHTTP worth considering: * automatic stateless transcoding between EBHTTP and HTTP allows us to define upper layers (representation, discovery) once, but have them apply to both kinds of protocols * allowing multiple EBHTTP requests to be packed into a single UDP message can increase the overall message efficiency * EBHTTP can run over both UDP datagrams and TCP persistent connections * having a "response-is-optional" header flag allows for more efficient unreliable message delivery and enables multicast message delivery * making the sequence number/transaction id into an option means that we don't pay the sequence number overhead when we don't need it If we take a compression approach instead of a mapping approach, we still might be introducing abstraction leakage around the size of the resources and the choice of optional HTTP headers that are allowed to make it through the compression process, but at least the basic protocol transformation will remain sound and able to take advantage of future progress in HTTP. Gil From pister@eecs.berkeley.edu Mon Apr 5 13:28: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 69B3D28C11D for ; Mon, 5 Apr 2010 13:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_BACKHAIR_44=1, 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 5SD0XI4D39ls for ; Mon, 5 Apr 2010 13:28:19 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 0981C28C1C5 for ; Mon, 5 Apr 2010 13:21:30 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o35KLPn2026956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Apr 2010 13:21:26 -0700 (PDT) Message-ID: <4BBA4644.6010702@eecs.berkeley.edu> Date: Mon, 05 Apr 2010 13:21:24 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gilman Tolle References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> In-Reply-To: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 05 Apr 2010 20:28:20 -0000 +1 Gilman Tolle wrote: > I have a question about the HTTP<->CoAP mapping we're chartered to > define... > > Because the operations in draft-shelby-core-coap-00 are different from > the standard HTTP methods, I'd suggest that any mapping is likely to > lead to a leaky abstraction between the two protocols. In addition, a > mapping could become a source of divergence between CoAP and HTTP as > further innovation happens in these two separate spaces. > > Do the CoAP protocol operations really need to be different from the > HTTP protocol operations? > > If we think about this as a compression problem instead of a mapping > problem, we could define CoAP as semantically identical to HTTP, but > with a more compact concrete representation. Because we're running in > constrained networks, we don't have to maintain every arbitrary HTTP > optional header across the compression boundary, but we can easily > maintain the core protocol operations and naming systems that make > HTTP so powerful. Essentially, we'd be defining the CoAP protocol as > an easily-compressible profile of HTTP along with a stateless > transformation between the compressed and uncompressed versions. > > I'd like to point everyone to my EBHTTP draft > (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which > presents an alternative compressed-HTTP approach to the design of CoAP > (as does the original Chopan draft, for that matter). > > I think there are a few other benefits of EBHTTP worth considering: > > * automatic stateless transcoding between EBHTTP and HTTP allows us to > define upper layers (representation, discovery) once, but have them > apply to both kinds of protocols > * allowing multiple EBHTTP requests to be packed into a single UDP > message can increase the overall message efficiency > * EBHTTP can run over both UDP datagrams and TCP persistent connections > * having a "response-is-optional" header flag allows for more > efficient unreliable message delivery and enables multicast message > delivery > * making the sequence number/transaction id into an option means that > we don't pay the sequence number overhead when we don't need it > > If we take a compression approach instead of a mapping approach, we > still might be introducing abstraction leakage around the size of the > resources and the choice of optional HTTP headers that are allowed to > make it through the compression process, but at least the basic > protocol transformation will remain sound and able to take advantage > of future progress in HTTP. > > Gil > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Mon Apr 5 14:13: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 846843A6A56 for ; Mon, 5 Apr 2010 14:13:15 -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, J_BACKHAIR_44=1, 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 2HF+BoZZaReH for ; Mon, 5 Apr 2010 14:13: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 E77DE3A6891 for ; Mon, 5 Apr 2010 14:12:46 -0700 (PDT) Received: from [192.168.1.3] (line-5684.dyn.kponet.fi [85.29.68.137]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o35LCYJ8026870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Apr 2010 00:12:35 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> Date: Tue, 6 Apr 2010 00:12:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> To: Gilman Tolle X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 05 Apr 2010 21:13:16 -0000 Hi Gil, At the WG meeting (and in the hallways) we actually discussed using = standard GET, PUT, POST, DELETE method names in the next version of the = CoAP draft. Semantically they are already very, very close. I have no = problem with that suggestion (that is actually how we started out). Some of the features you listed below I would surely be open to = discussing for integration into our CoAP specification - they are = already close in header and functionality. Let's discuss that! Sorry I = haven't been able to give comments on your draft yet, recovering from = the IETF takes some time... Regarding Chopan, we have been working with Brian to integrate the ideas = from Chopan for quite a while already. In fact CoAP is a combination of = Chopan and a simple REST design from a clean slate. We had long = discussions on the 6lowapp list during chartering about compressing = HTTP, and my conclusion was that we should not do that (and are not = chartered to do that). The protocol we design in CoRE should be pure to = the REST architecture and semantics which are behind HTTP. If we are = also smart about re-using a subset of HTTP codes etc. then I don't see = that a CoAP conversion to HTTP would be more difficult than = compression/decompression (it should be simpler). So our goal is the = same here, we just took a clean slate approach to find the fundamental = features behind HTTP. Zach On Apr 5, 2010, at 22:38 , Gilman Tolle wrote: > I have a question about the HTTP<->CoAP mapping we're chartered to = define... >=20 > Because the operations in draft-shelby-core-coap-00 are different from = the standard HTTP methods, I'd suggest that any mapping is likely to = lead to a leaky abstraction between the two protocols. In addition, a = mapping could become a source of divergence between CoAP and HTTP as = further innovation happens in these two separate spaces. >=20 > Do the CoAP protocol operations really need to be different from the = HTTP protocol operations? >=20 > If we think about this as a compression problem instead of a mapping = problem, we could define CoAP as semantically identical to HTTP, but = with a more compact concrete representation. Because we're running in = constrained networks, we don't have to maintain every arbitrary HTTP = optional header across the compression boundary, but we can easily = maintain the core protocol operations and naming systems that make HTTP = so powerful. Essentially, we'd be defining the CoAP protocol as an = easily-compressible profile of HTTP along with a stateless = transformation between the compressed and uncompressed versions. >=20 > I'd like to point everyone to my EBHTTP draft = (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents = an alternative compressed-HTTP approach to the design of CoAP (as does = the original Chopan draft, for that matter). >=20 > I think there are a few other benefits of EBHTTP worth considering: >=20 > * automatic stateless transcoding between EBHTTP and HTTP allows us to = define upper layers (representation, discovery) once, but have them = apply to both kinds of protocols > * allowing multiple EBHTTP requests to be packed into a single UDP = message can increase the overall message efficiency > * EBHTTP can run over both UDP datagrams and TCP persistent = connections > * having a "response-is-optional" header flag allows for more = efficient unreliable message delivery and enables multicast message = delivery > * making the sequence number/transaction id into an option means that = we don't pay the sequence number overhead when we don't need it >=20 > If we take a compression approach instead of a mapping approach, we = still might be introducing abstraction leakage around the size of the = resources and the choice of optional HTTP headers that are allowed to = make it through the compression process, but at least the basic protocol = transformation will remain sound and able to take advantage of future = progress in HTTP. >=20 > Gil >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From brian.tridium@gmail.com Mon Apr 5 16:34: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 AE29E3A6914 for ; Mon, 5 Apr 2010 16:34:11 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RqfAGIN9UHSU for ; Mon, 5 Apr 2010 16:34:10 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 9709B3A63D3 for ; Mon, 5 Apr 2010 16:34:09 -0700 (PDT) Received: by bwz9 with SMTP id 9so3356651bwz.29 for ; Mon, 05 Apr 2010 16:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=cX/bGf9zO/AJsiQ38zKVW712uSNhpm9gAsOEanV0n48=; b=ijYTy5p1dciC6ig8zUM7ZHOpdIltF4F00zhu/+6FmycK79mvPRHklpX9NpedPWLsCM wJWJLLLoS0pUgU36qXDU1aO3HzyM3tSFLCrPsz3IoFvbFP+DrXSYg68/Bex5NPhs6dbU czblP8/lxlgjsuYVWZovnLxJprHXJO+7DjaP4= 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 :cc:content-type; b=NbAef6BE+WecAKTnUsiALwfhjE/u75zOrCxAXKN5NGf7oI7FScr2quFkeUZVjYVOSc Wn56OE4/0RGIaiKDEGEoj0Vj/TzYiyneZ6ciWj5fnSjsV8mxZsq6DyZyUKpbh0s/rWx8 XQKSroKgX3grqxjzA1ow+EDoShz+pOpXkcBWs= MIME-Version: 1.0 Received: by 10.204.103.135 with HTTP; Mon, 5 Apr 2010 16:34:01 -0700 (PDT) In-Reply-To: <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> Date: Mon, 5 Apr 2010 19:34:01 -0400 Received: by 10.204.33.131 with SMTP id h3mr3987034bkd.53.1270510441931; Mon, 05 Apr 2010 16:34:01 -0700 (PDT) Message-ID: From: Brian Frank To: Zach Shelby Content-Type: multipart/alternative; boundary=000325559a92932401048385c38b Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 05 Apr 2010 23:34:11 -0000 --000325559a92932401048385c38b Content-Type: text/plain; charset=ISO-8859-1 Its not really just about compressing HTTP as-is, but the harder issue is defining the subset of HTTP that is used (because few 6lowpan devices can really support it all). And even then it probably isn't a clean subset. For example the host header is required in HTTP, but we probably don't want to require it in CoAP. So after giving a lot of thought to how HTTP mapping happens with Chopan, I lean towards saying CoAP is something new with a well defined scope. Perhaps we may reference semantics in the HTTP spec, but wouldn't derive from it. I suspect a new separate path will actually make for a better mapping at the HTTP gateway. But then again I can see the reverse position that the HTTP mapping becomes a key aspect of our spec, in which case we are effectively defining a HTTP subset anyhow. On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby wrote: > Hi Gil, > > At the WG meeting (and in the hallways) we actually discussed using > standard GET, PUT, POST, DELETE method names in the next version of the CoAP > draft. Semantically they are already very, very close. I have no problem > with that suggestion (that is actually how we started out). > > Some of the features you listed below I would surely be open to discussing > for integration into our CoAP specification - they are already close in > header and functionality. Let's discuss that! Sorry I haven't been able to > give comments on your draft yet, recovering from the IETF takes some time... > > Regarding Chopan, we have been working with Brian to integrate the ideas > from Chopan for quite a while already. In fact CoAP is a combination of > Chopan and a simple REST design from a clean slate. We had long discussions > on the 6lowapp list during chartering about compressing HTTP, and my > conclusion was that we should not do that (and are not chartered to do > that). The protocol we design in CoRE should be pure to the REST > architecture and semantics which are behind HTTP. If we are also smart about > re-using a subset of HTTP codes etc. then I don't see that a CoAP conversion > to HTTP would be more difficult than compression/decompression (it should be > simpler). So our goal is the same here, we just took a clean slate approach > to find the fundamental features behind HTTP. > > Zach > > On Apr 5, 2010, at 22:38 , Gilman Tolle wrote: > > > I have a question about the HTTP<->CoAP mapping we're chartered to > define... > > > > Because the operations in draft-shelby-core-coap-00 are different from > the standard HTTP methods, I'd suggest that any mapping is likely to lead to > a leaky abstraction between the two protocols. In addition, a mapping could > become a source of divergence between CoAP and HTTP as further innovation > happens in these two separate spaces. > > > > Do the CoAP protocol operations really need to be different from the HTTP > protocol operations? > > > > If we think about this as a compression problem instead of a mapping > problem, we could define CoAP as semantically identical to HTTP, but with a > more compact concrete representation. Because we're running in constrained > networks, we don't have to maintain every arbitrary HTTP optional header > across the compression boundary, but we can easily maintain the core > protocol operations and naming systems that make HTTP so powerful. > Essentially, we'd be defining the CoAP protocol as an easily-compressible > profile of HTTP along with a stateless transformation between the compressed > and uncompressed versions. > > > > I'd like to point everyone to my EBHTTP draft ( > http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents an > alternative compressed-HTTP approach to the design of CoAP (as does the > original Chopan draft, for that matter). > > > > I think there are a few other benefits of EBHTTP worth considering: > > > > * automatic stateless transcoding between EBHTTP and HTTP allows us to > define upper layers (representation, discovery) once, but have them apply to > both kinds of protocols > > * allowing multiple EBHTTP requests to be packed into a single UDP > message can increase the overall message efficiency > > * EBHTTP can run over both UDP datagrams and TCP persistent connections > > * having a "response-is-optional" header flag allows for more efficient > unreliable message delivery and enables multicast message delivery > > * making the sequence number/transaction id into an option means that we > don't pay the sequence number overhead when we don't need it > > > > If we take a compression approach instead of a mapping approach, we still > might be introducing abstraction leakage around the size of the resources > and the choice of optional HTTP headers that are allowed to make it through > the compression process, but at least the basic protocol transformation will > remain sound and able to take advantage of future progress in HTTP. > > > > Gil > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system without > producing, distributing or retaining copies thereof. > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000325559a92932401048385c38b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Its not really just about compressing HTTP as-is, but the harder issue is d= efining the subset of HTTP that is used (because few 6lowpan devices can re= ally support it all). =A0And even then it probably isn't a clean subset= . =A0For example the host header is required in HTTP, but we probably don&#= 39;t want to require it in CoAP.

So after giving a lot of thought to how HTTP mapping happens= with Chopan, I lean towards saying CoAP is something new with a well defin= ed scope. =A0Perhaps we may reference semantics in the HTTP spec, but would= n't derive from it. =A0I suspect a new separate path will actually make= for a better mapping at the HTTP gateway.

But then again I can see the reverse position that the = HTTP mapping becomes a key aspect of our spec, in which case we are effecti= vely defining a HTTP subset anyhow.


On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby <zach@sensinode.com> wrote:
=
Hi Gil,

At the WG meeting (and in the hallways) we actually discussed using standar= d GET, PUT, POST, DELETE method names in the next version of the CoAP draft= . Semantically they are already very, very close. I have no problem with th= at suggestion (that is actually how we started out).

Some of the features you listed below I would surely be open to discussing = for integration into our CoAP specification - they are already close in hea= der and functionality. Let's discuss that! Sorry I haven't been abl= e to give comments on your draft yet, recovering from the IETF takes some t= ime...

Regarding Chopan, we have been working with Brian to integrate the ideas fr= om Chopan for quite a while already. In fact CoAP is a combination of Chopa= n and a simple REST design from a clean slate. We had long discussions on t= he 6lowapp list during chartering about compressing HTTP, and my conclusion= was that we should not do that (and are not chartered to do that). The pro= tocol we design in CoRE should be pure to the REST architecture and semanti= cs which are behind HTTP. If we are also smart about re-using a subset of H= TTP codes etc. then I don't see that a CoAP conversion to HTTP would be= more difficult than compression/decompression (it should be simpler). So o= ur goal is the same here, we just took a clean slate approach to find the f= undamental features behind HTTP.

Zach

On Apr 5, 2010, at 22:38 , Gilman Tolle wrote:

> I have a question about the HTTP<->CoAP mapping we're charte= red to define...
>
> Because the operations in draft-shelby-core-coap-00 are different from= the standard HTTP methods, I'd suggest that any mapping is likely to l= ead to a leaky abstraction between the two protocols. In addition, a mappin= g could become a source of divergence between CoAP and HTTP as further inno= vation happens in these two separate spaces.
>
> Do the CoAP protocol operations really need to be different from the H= TTP protocol operations?
>
> If we think about this as a compression problem instead of a mapping p= roblem, we could define CoAP as semantically identical to HTTP, but with a = more compact concrete representation. Because we're running in constrai= ned networks, we don't have to maintain every arbitrary HTTP optional h= eader across the compression boundary, but we can easily maintain the core = protocol operations and naming systems that make HTTP so powerful. Essentia= lly, we'd be defining the CoAP protocol as an easily-compressible profi= le of HTTP along with a stateless transformation between the compressed and= uncompressed versions.
>
> I'd like to point everyone to my EBHTTP draft (http://too= ls.ietf.org/html/draft-tolle-core-ebhttp-00), which presents an alterna= tive compressed-HTTP approach to the design of CoAP (as does the original C= hopan draft, for that matter).
>
> I think there are a few other benefits of EBHTTP worth considering: >
> * automatic stateless transcoding between EBHTTP and HTTP allows us to= define upper layers (representation, discovery) once, but have them apply = to both kinds of protocols
> * allowing multiple EBHTTP requests to be packed into a single UDP mes= sage can increase the overall message efficiency
> * EBHTTP can run over both UDP datagrams and TCP persistent connection= s
> * having a "response-is-optional" header flag allows for mor= e efficient unreliable message delivery and enables multicast message deliv= ery
> * making the sequence number/transaction id into an option means that = we don't pay the sequence number overhead when we don't need it
>
> If we take a compression approach instead of a mapping approach, we st= ill might be introducing abstraction leakage around the size of the resourc= es and the choice of optional HTTP headers that are allowed to make it thro= ugh the compression process, but at least the basic protocol transformation= will remain sound and able to take advantage of future progress in HTTP. >
> Gil
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--
http://www.sensinode= .com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - N= ew book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain lega= lly privileged information. If you are not the intended recipient, please c= ontact the sender and delete the e-mail from your system without producing,= distributing or retaining copies thereof.




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

--000325559a92932401048385c38b-- From apezzuto@cisco.com Tue Apr 6 05: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 9ED1E3A67A7 for ; Tue, 6 Apr 2010 05:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIRUigbhwqVa for ; Tue, 6 Apr 2010 05:51:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DDE163A68D4 for ; Tue, 6 Apr 2010 05:51:28 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8CANbKukuQ/uCWe2dsb2JhbACbShUBAQsLIgYcn2mYf4UJBA X-IronPort-AV: E=Sophos;i="4.51,372,1267401600"; d="scan'208";a="59029736" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2010 12:51:25 +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 o36CpPtZ009828; Tue, 6 Apr 2010 12:51:25 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); Tue, 6 Apr 2010 14:51:25 +0200 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, 6 Apr 2010 14:51:23 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reability of CoAP messages Thread-Index: AcrVh9zR+turVoEDQRKH+8ZglNwghw== From: "Adriano Pezzuto (apezzuto)" To: "Zach Shelby" X-OriginalArrivalTime: 06 Apr 2010 12:51:25.0428 (UTC) FILETIME=[DDF01340:01CAD587] Cc: core@ietf.org Subject: [core] Reability of CoAP messages 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, 06 Apr 2010 12:51:30 -0000 Hello Zach, some comments about 2.8.1. UDP section of http://www.ietf.org/id/draft-shelby-core-coap-00.txt. "The Transaction ID in CoAP message headers is used to match responses to open requests and is generated by the client (common counter across all requests)." I suppose, a receiver node will discard the message if a duplicated Transaction ID is received. If this is the case, I see two situations where this may have some sort of issues: 1. A receiver node receives two (or more) different requests from two different nodes and both requests have the same Transaction ID. The receiver node will discard the last request. 2. An application manager running CoAP sends requests to all nodes of the network (e.g. to node1, .... to node-i, .... to node-N). Not sure but the application manager can send a new request to the node-i before to receive the response to the last request and both requests have the same transaction ID. The receiver node-i will discard the last request. For case (1) a possible solution may be to use multiple separate counter on the receiver node - one for each transmitter, instead of a common counter. For case (2), a possible solution is to use a separate counter on the application manager - one for each node, instead of a common counter. May be a stop-and-wait (as stated in the same section of the draft) would be sufficient to avoid the case (2) but not sure what you mean exactly with stop-and-wait. Thank you, Adriano From lisa.dusseault@gmail.com Tue Apr 6 10:10: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 D984D3A6803 for ; Tue, 6 Apr 2010 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 Q3N1Kasv9zjx for ; Tue, 6 Apr 2010 10:10:22 -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 7783A3A6767 for ; Tue, 6 Apr 2010 10:10:20 -0700 (PDT) Received: by vws15 with SMTP id 15so42180vws.31 for ; Tue, 06 Apr 2010 10:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=W7SEJu5lIn1h6lmgBIu5c3zWTmj41MkmIE+E9/C4S4A=; b=FKUxCkwGom7QTQm8lDQnq2D5tbzh6yoarficZuNU73IXrT0tn6U73KoUhghnl2qZx4 MgrBxxAbA6/B4FrrP6JzVSTauHffOXXMYNMpYLpEubHS6kjPnT55KWYrnWefVaa2TgBk AdxYXkjNn+fUmbA/nTli8RayYkxQMYUBDhsnE= 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 :cc:content-type; b=HkMpdc7fogbfdPY+x/0r1cUSBThO+mAb0NYx7v66uHh6LMPt4p9u6r/QYOL6PPBQPn 2nzx23pDRm6xldrRuzj8OHsLA6fBwXJBtTu7hqrAmKtbyOgatqtteJBGq1MSvI3pUSoT NGUmmUrDB1R/BX0FwgsHFzcOCUY5+CDk6WT5I= MIME-Version: 1.0 Received: by 10.220.124.221 with HTTP; Tue, 6 Apr 2010 10:10:14 -0700 (PDT) In-Reply-To: References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> Date: Tue, 6 Apr 2010 10:10:14 -0700 Received: by 10.220.108.198 with SMTP id g6mr1321276vcp.82.1270573814373; Tue, 06 Apr 2010 10:10:14 -0700 (PDT) Message-ID: From: Lisa Dusseault To: Brian Frank Content-Type: multipart/alternative; boundary=00c09f8e5ccedde12f04839484a9 Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 06 Apr 2010 17:10:28 -0000 --00c09f8e5ccedde12f04839484a9 Content-Type: text/plain; charset=ISO-8859-1 I agree, defining a subset is much more valuable than defining a compression, and that CoAP is something new that ought to steal many things from HTTP. Defining a mapping of HTTP for gateways to use can reasonably done in the scale I understand gateways to have. But that means that gateways have to deal with the "deployed reality" of HTTP, which is pretty bad in terms of compliance to the HTTP spec and documented interoperability (although it is even worse when you add in HTML and cookies). That tradeoff seems reasonable -- requiring complex functionality in a node that can handle it in order to get some very useful features. Defining a compression of HTTP for the more constrained devices? Not so helpful. I wrote up my thoughts in more detail here. Lisa On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank wrote: > Its not really just about compressing HTTP as-is, but the harder issue is > defining the subset of HTTP that is used (because few 6lowpan devices can > really support it all). And even then it probably isn't a clean subset. > For example the host header is required in HTTP, but we probably don't want > to require it in CoAP. > > So after giving a lot of thought to how HTTP mapping happens with Chopan, I > lean towards saying CoAP is something new with a well defined scope. > Perhaps we may reference semantics in the HTTP spec, but wouldn't derive > from it. I suspect a new separate path will actually make for a better > mapping at the HTTP gateway. > > But then again I can see the reverse position that the HTTP mapping becomes > a key aspect of our spec, in which case we are effectively defining a HTTP > subset anyhow. > > > On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby wrote: > >> Hi Gil, >> >> At the WG meeting (and in the hallways) we actually discussed using >> standard GET, PUT, POST, DELETE method names in the next version of the CoAP >> draft. Semantically they are already very, very close. I have no problem >> with that suggestion (that is actually how we started out). >> >> Some of the features you listed below I would surely be open to discussing >> for integration into our CoAP specification - they are already close in >> header and functionality. Let's discuss that! Sorry I haven't been able to >> give comments on your draft yet, recovering from the IETF takes some time... >> >> Regarding Chopan, we have been working with Brian to integrate the ideas >> from Chopan for quite a while already. In fact CoAP is a combination of >> Chopan and a simple REST design from a clean slate. We had long discussions >> on the 6lowapp list during chartering about compressing HTTP, and my >> conclusion was that we should not do that (and are not chartered to do >> that). The protocol we design in CoRE should be pure to the REST >> architecture and semantics which are behind HTTP. If we are also smart about >> re-using a subset of HTTP codes etc. then I don't see that a CoAP conversion >> to HTTP would be more difficult than compression/decompression (it should be >> simpler). So our goal is the same here, we just took a clean slate approach >> to find the fundamental features behind HTTP. >> >> Zach >> >> On Apr 5, 2010, at 22:38 , Gilman Tolle wrote: >> >> > I have a question about the HTTP<->CoAP mapping we're chartered to >> define... >> > >> > Because the operations in draft-shelby-core-coap-00 are different from >> the standard HTTP methods, I'd suggest that any mapping is likely to lead to >> a leaky abstraction between the two protocols. In addition, a mapping could >> become a source of divergence between CoAP and HTTP as further innovation >> happens in these two separate spaces. >> > >> > Do the CoAP protocol operations really need to be different from the >> HTTP protocol operations? >> > >> > If we think about this as a compression problem instead of a mapping >> problem, we could define CoAP as semantically identical to HTTP, but with a >> more compact concrete representation. Because we're running in constrained >> networks, we don't have to maintain every arbitrary HTTP optional header >> across the compression boundary, but we can easily maintain the core >> protocol operations and naming systems that make HTTP so powerful. >> Essentially, we'd be defining the CoAP protocol as an easily-compressible >> profile of HTTP along with a stateless transformation between the compressed >> and uncompressed versions. >> > >> > I'd like to point everyone to my EBHTTP draft ( >> http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents an >> alternative compressed-HTTP approach to the design of CoAP (as does the >> original Chopan draft, for that matter). >> > >> > I think there are a few other benefits of EBHTTP worth considering: >> > >> > * automatic stateless transcoding between EBHTTP and HTTP allows us to >> define upper layers (representation, discovery) once, but have them apply to >> both kinds of protocols >> > * allowing multiple EBHTTP requests to be packed into a single UDP >> message can increase the overall message efficiency >> > * EBHTTP can run over both UDP datagrams and TCP persistent connections >> > * having a "response-is-optional" header flag allows for more efficient >> unreliable message delivery and enables multicast message delivery >> > * making the sequence number/transaction id into an option means that we >> don't pay the sequence number overhead when we don't need it >> > >> > If we take a compression approach instead of a mapping approach, we >> still might be introducing abstraction leakage around the size of the >> resources and the choice of optional HTTP headers that are allowed to make >> it through the compression process, but at least the basic protocol >> transformation will remain sound and able to take advantage of future >> progress in HTTP. >> > >> > Gil >> > >> > _______________________________________________ >> > core mailing list >> > core@ietf.org >> > https://www.ietf.org/mailman/listinfo/core >> >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may contain >> legally privileged information. If you are not the intended recipient, >> please contact the sender and delete the e-mail from your system without >> producing, distributing or retaining copies thereof. >> >> >> >> >> _______________________________________________ >> 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 > > --00c09f8e5ccedde12f04839484a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree, defining a subset is much more valuable than defining a compressio= n, and that CoAP is something new that ought to steal many things from HTTP= .

Defining a mapping of HTTP for gateways to use can reasonably done= in the scale I understand gateways to have.=A0 But that means that gateway= s have to deal with the "deployed reality" of HTTP, which is pret= ty bad in terms of compliance to the HTTP spec and documented interoperabil= ity (although it is even worse when you add in HTML and cookies).=A0 That t= radeoff seems reasonable -- requiring complex functionality in a node that = can handle it in order to get some very useful features.

Defining a compression of HTTP for the more constrained devices?=A0 Not= so helpful.=A0=A0 I wrote up my thoughts in more detail here= .

Lisa

On Mon, Apr 5, 2010 at 4:34 PM, = Brian Frank <brian.tridium@gmail.com> wrote:
Its not really just about compressing HTTP as-is, but the harder issue is d= efining the subset of HTTP that is used (because few 6lowpan devices can re= ally support it all). =A0And even then it probably isn't a clean subset= . =A0For example the host header is required in HTTP, but we probably don&#= 39;t want to require it in CoAP.

So after giving a lot of thought to how HTTP mapping happens= with Chopan, I lean towards saying CoAP is something new with a well defin= ed scope. =A0Perhaps we may reference semantics in the HTTP spec, but would= n't derive from it. =A0I suspect a new separate path will actually make= for a better mapping at the HTTP gateway.

But then again I can see the reverse position that the = HTTP mapping becomes a key aspect of our spec, in which case we are effecti= vely defining a HTTP subset anyhow.


On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby <zach@sensinode.com>= wrote:
Hi Gil,

At the WG meeting (and in the hallways) we actually discussed using standar= d GET, PUT, POST, DELETE method names in the next version of the CoAP draft= . Semantically they are already very, very close. I have no problem with th= at suggestion (that is actually how we started out).

Some of the features you listed below I would surely be open to discussing = for integration into our CoAP specification - they are already close in hea= der and functionality. Let's discuss that! Sorry I haven't been abl= e to give comments on your draft yet, recovering from the IETF takes some t= ime...

Regarding Chopan, we have been working with Brian to integrate the ideas fr= om Chopan for quite a while already. In fact CoAP is a combination of Chopa= n and a simple REST design from a clean slate. We had long discussions on t= he 6lowapp list during chartering about compressing HTTP, and my conclusion= was that we should not do that (and are not chartered to do that). The pro= tocol we design in CoRE should be pure to the REST architecture and semanti= cs which are behind HTTP. If we are also smart about re-using a subset of H= TTP codes etc. then I don't see that a CoAP conversion to HTTP would be= more difficult than compression/decompression (it should be simpler). So o= ur goal is the same here, we just took a clean slate approach to find the f= undamental features behind HTTP.

Zach

On Apr 5, 2010, at 22:38 , Gilman Tolle wrote:

> I have a question about the HTTP<->CoAP mapping we're charte= red to define...
>
> Because the operations in draft-shelby-core-coap-00 are different from= the standard HTTP methods, I'd suggest that any mapping is likely to l= ead to a leaky abstraction between the two protocols. In addition, a mappin= g could become a source of divergence between CoAP and HTTP as further inno= vation happens in these two separate spaces.
>
> Do the CoAP protocol operations really need to be different from the H= TTP protocol operations?
>
> If we think about this as a compression problem instead of a mapping p= roblem, we could define CoAP as semantically identical to HTTP, but with a = more compact concrete representation. Because we're running in constrai= ned networks, we don't have to maintain every arbitrary HTTP optional h= eader across the compression boundary, but we can easily maintain the core = protocol operations and naming systems that make HTTP so powerful. Essentia= lly, we'd be defining the CoAP protocol as an easily-compressible profi= le of HTTP along with a stateless transformation between the compressed and= uncompressed versions.
>
> I'd like to point everyone to my EBHTTP draft (http://too= ls.ietf.org/html/draft-tolle-core-ebhttp-00), which presents an alterna= tive compressed-HTTP approach to the design of CoAP (as does the original C= hopan draft, for that matter).
>
> I think there are a few other benefits of EBHTTP worth considering: >
> * automatic stateless transcoding between EBHTTP and HTTP allows us to= define upper layers (representation, discovery) once, but have them apply = to both kinds of protocols
> * allowing multiple EBHTTP requests to be packed into a single UDP mes= sage can increase the overall message efficiency
> * EBHTTP can run over both UDP datagrams and TCP persistent connection= s
> * having a "response-is-optional" header flag allows for mor= e efficient unreliable message delivery and enables multicast message deliv= ery
> * making the sequence number/transaction id into an option means that = we don't pay the sequence number overhead when we don't need it
>
> If we take a compression approach instead of a mapping approach, we st= ill might be introducing abstraction leakage around the size of the resourc= es and the choice of optional HTTP headers that are allowed to make it thro= ugh the compression process, but at least the basic protocol transformation= will remain sound and able to take advantage of future progress in HTTP. >
> Gil
>
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core

--
http://www.sensinode= .com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - N= ew book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain lega= lly privileged information. If you are not the intended recipient, please c= ontact the sender and delete the e-mail from your system without producing,= distributing or retaining copies thereof.




_______________________________________________
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


--00c09f8e5ccedde12f04839484a9-- From cabo@tzi.org Tue Apr 6 11:23: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 A026E3A69D9 for ; Tue, 6 Apr 2010 11:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[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 o8mhX0kzYcX3 for ; Tue, 6 Apr 2010 11:23:44 -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 C4C1128C132 for ; Tue, 6 Apr 2010 11:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o35JsNNd005259; Mon, 5 Apr 2010 21:54:23 +0200 (CEST) Received: from [192.168.217.101] (p5489B710.dip.t-dialin.net [84.137.183.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 2E233E4C1; Mon, 5 Apr 2010 21:54:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> Date: Mon, 5 Apr 2010 21:54:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18E78565-14C5-4C2A-8325-2F675AF30157@tzi.org> References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> To: Gilman Tolle X-Mailer: Apple Mail (2.1078) Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 06 Apr 2010 18:23:59 -0000 On Apr 5, 2010, at 21:38, Gilman Tolle wrote: > leaky abstraction=20 Would that be a problem? If yes, please explain how, best with an = example. (Would the mapping need to behave as if it were an abstraction at all?) As far as I understand the point of the mapping, this is not about = looking at a temp sensor with Firefox. It is about using HTTP to access CoAP-enabled devices. (Not in the sense of mis-using HTTP as a transport. But the resources visible on the HTTP side might be recognizably CoAPy, = which as you say they are likely to be in any case because of the = message size limitations on the side of the constrained network.) There is no fundamental difference in the achievable result space = between -- designing CoAP, -- compressing, restricting, modifying, reinterpreting, and extending = HTTP until we arrive at CoAP. Except that the latter, processwise, is likely to lead to more = complexity. (Some of us still have the scars from making SIP almost, but not = entirely, unlike HTTP.) Gruesse, Carsten (No WG chair hats were hurt in creating this message.) From robert.cragie@gridmerge.com Wed Apr 7 09:16: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 EB0B63A6B20 for ; Wed, 7 Apr 2010 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, 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 rMtdpuEncbGm for ; Wed, 7 Apr 2010 09:16:37 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id CC5C33A6B21 for ; Wed, 7 Apr 2010 09:14:36 -0700 (PDT) Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NzXtf-0006jP-W0 for core@ietf.org; Wed, 07 Apr 2010 17:14:32 +0100 Message-ID: <4BBCAF61.3020904@gridmerge.com> Date: Wed, 07 Apr 2010 17:14:25 +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: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050707060604020408030503" Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 07 Apr 2010 16:16:40 -0000 This is a cryptographically signed message in MIME format. --------------ms050707060604020408030503 Content-Type: multipart/alternative; boundary="------------050702080804050803020306" This is a multi-part message in MIME format. --------------050702080804050803020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I think a big issue is not regarding the syntactic mapping and=20 compression, but the transaction mapping of what is being proposed as a=20 'quasi-synchronous' protocol to synchronous HTTP. Obviously it is=20 straightforward to map synchronous transactions but if asynchronous=20 transactions take place in the CoAP environment, they are not going to=20 statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it=20 was called) may resurface and may need to be defined. On the same topic, I still don't see the need for NOTIFY in the current=20 specification. Define the concept of clients with subscription agents=20 (i.e. in a server role) and either define a comprehensive callback=20 subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take=20 it out completely and define using the CRUD methods. I prefer the latter.= Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 06/04/2010 6:10 PM, Lisa Dusseault wrote: > I agree, defining a subset is much more valuable than defining a=20 > compression, and that CoAP is something new that ought to steal many=20 > things from HTTP. > > Defining a mapping of HTTP for gateways to use can reasonably done in=20 > the scale I understand gateways to have. But that means that gateways = > have to deal with the "deployed reality" of HTTP, which is pretty bad=20 > in terms of compliance to the HTTP spec and documented=20 > interoperability (although it is even worse when you add in HTML and=20 > cookies). That tradeoff seems reasonable -- requiring complex=20 > functionality in a node that can handle it in order to get some very=20 > useful features. > > Defining a compression of HTTP for the more constrained devices? Not=20 > so helpful. I wrote up my thoughts in more detail here=20 > =20 > . > > Lisa > > On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank > wrote: > > Its not really just about compressing HTTP as-is, but the harder > issue is defining the subset of HTTP that is used (because few > 6lowpan devices can really support it all). And even then it > probably isn't a clean subset. For example the host header is > required in HTTP, but we probably don't want to require it in CoAP.= > > So after giving a lot of thought to how HTTP mapping happens with > Chopan, I lean towards saying CoAP is something new with a well > defined scope. Perhaps we may reference semantics in the HTTP > spec, but wouldn't derive from it. I suspect a new separate path > will actually make for a better mapping at the HTTP gateway. > > But then again I can see the reverse position that the HTTP > mapping becomes a key aspect of our spec, in which case we are > effectively defining a HTTP subset anyhow. > > > On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby > wrote: > > Hi Gil, > > At the WG meeting (and in the hallways) we actually discussed > using standard GET, PUT, POST, DELETE method names in the next > version of the CoAP draft. Semantically they are already very, > very close. I have no problem with that suggestion (that is > actually how we started out). > > Some of the features you listed below I would surely be open > to discussing for integration into our CoAP specification - > they are already close in header and functionality. Let's > discuss that! Sorry I haven't been able to give comments on > your draft yet, recovering from the IETF takes some time... > > Regarding Chopan, we have been working with Brian to integrate > the ideas from Chopan for quite a while already. In fact CoAP > is a combination of Chopan and a simple REST design from a > clean slate. We had long discussions on the 6lowapp list > during chartering about compressing HTTP, and my conclusion > was that we should not do that (and are not chartered to do > that). The protocol we design in CoRE should be pure to the > REST architecture and semantics which are behind HTTP. If we > are also smart about re-using a subset of HTTP codes etc. then > I don't see that a CoAP conversion to HTTP would be more > difficult than compression/decompression (it should be > simpler). So our goal is the same here, we just took a clean > slate approach to find the fundamental features behind HTTP. > > Zach > > On Apr 5, 2010, at 22:38 , Gilman Tolle wrote: > > > I have a question about the HTTP<->CoAP mapping we're > chartered to define... > > > > Because the operations in draft-shelby-core-coap-00 are > different from the standard HTTP methods, I'd suggest that any > mapping is likely to lead to a leaky abstraction between the > two protocols. In addition, a mapping could become a source of > divergence between CoAP and HTTP as further innovation happens > in these two separate spaces. > > > > Do the CoAP protocol operations really need to be different > from the HTTP protocol operations? > > > > If we think about this as a compression problem instead of a > mapping problem, we could define CoAP as semantically > identical to HTTP, but with a more compact concrete > representation. Because we're running in constrained networks, > we don't have to maintain every arbitrary HTTP optional header > across the compression boundary, but we can easily maintain > the core protocol operations and naming systems that make HTTP > so powerful. Essentially, we'd be defining the CoAP protocol > as an easily-compressible profile of HTTP along with a > stateless transformation between the compressed and > uncompressed versions. > > > > I'd like to point everyone to my EBHTTP draft > (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which > presents an alternative compressed-HTTP approach to the design > of CoAP (as does the original Chopan draft, for that matter). > > > > I think there are a few other benefits of EBHTTP worth > considering: > > > > * automatic stateless transcoding between EBHTTP and HTTP > allows us to define upper layers (representation, discovery) > once, but have them apply to both kinds of protocols > > * allowing multiple EBHTTP requests to be packed into a > single UDP message can increase the overall message efficiency > > * EBHTTP can run over both UDP datagrams and TCP persistent > connections > > * having a "response-is-optional" header flag allows for > more efficient unreliable message delivery and enables > multicast message delivery > > * making the sequence number/transaction id into an option > means that we don't pay the sequence number overhead when we > don't need it > > > > If we take a compression approach instead of a mapping > approach, we still might be introducing abstraction leakage > around the size of the resources and the choice of optional > HTTP headers that are allowed to make it through the > compression process, but at least the basic protocol > transformation will remain sound and able to take advantage of > future progress in HTTP. > > > > Gil > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - New book - "6LoWPAN: The Wireless > Embedded Internet" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may > contain legally privileged information. If you are not the > intended recipient, please contact the sender and delete the > e-mail from your system without producing, distributing or > retaining copies thereof. > > > > > _______________________________________________ > 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 --------------050702080804050803020306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think a big issue is not regarding the syntactic mapping and compression, but the transaction mapping of what is being proposed as a 'quasi-synchronous' protocol to synchronous HTTP. Obviously it is straightforward to map synchronous transactions but if asynchronous transactions take place in the CoAP environment, they are not going to statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it was called) may resurface and may need to be defined.

On the same topic, I still don't see the need for NOTIFY in the current specification. Define the concept of clients with subscription agents (i.e. in a server role) and either define a comprehensive callback subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take it out completely and define using the CRUD methods. I prefer the latter.

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 06/04/2010 6:10 PM, Lisa Dusseault wrote:
I agree, defining a subset is much more valuable than defining a compression, and that CoAP is something new that ought to steal many things from HTTP.

Defining a mapping of HTTP for gateways to use can reasonably done in the scale I understand gateways to have.  But that means that gatewa= ys have to deal with the "deployed reality" of HTTP, which is pretty bad in terms of compliance to the HTTP spec and documented interoperability (although it is even worse when you add in HTML and cookies).  That tradeoff seems reasonable -- requiring complex functionality in a node that can handle it in order to get some very useful features.

Defining a compression of HTTP for the more constrained devices?  No= t so helpful.   I wrote up my thoughts in more detail here =2E

Lisa

On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank = <brian.tridium@gmail.com><= /span> wrote:
Its not really just about compressing HTTP as-is, but the harder issue is defining the subset of HTTP that is used (because few 6lowpan devices can really support it all).  And even then it probably isn't a clean= subset.  For example the host header is required in HTTP, but we probably don't want to require it in CoAP.

So after giving a lot of thought to how HTTP mapping happens with Chopan, I lean towards saying CoAP is something new with a well defined scope.  Perhaps we may reference semantics in the HTTP spec,= but wouldn't derive from it.  I suspect a new separate path will actually make for a better mapping at the HTTP gateway.

But then again I can see the reverse position that the HTTP mapping becomes a key aspect of our spec, in which case we are effectively defining a HTTP subset anyhow.


On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby <zach@sensinode.com<= /a>> wrote:
Hi Gil,

At the WG meeting (and in the hallways) we actually discussed using standard GET, PUT, POST, DELETE method names in the next version of the CoAP draft. Semantically they are already very, very close. I have no problem with that suggestion (that is actually how we started out).

Some of the features you listed below I would surely be open to discussing for integration into our CoAP specification - they are already close in header and functionality. Let's discuss that! Sorry I haven't been able to give comments on your draft yet, recovering from the IETF takes some time...

Regarding Chopan, we have been working with Brian to integrate the ideas from Chopan for quite a while already. In fact CoAP is a combination of Chopan and a simple REST design from a clean slate. We had long discussions on the 6lowapp list during chartering about compressing HTTP, and my conclusion was that we should not do that (and are not chartered to do that). The protocol we design in CoRE should be pure to the REST architecture and semantics which are behind HTTP. If we are also smart about re-using a subset of HTTP codes etc. then I don't see that a CoAP conversion to HTTP would be more difficult than compression/decompression (it should be simpler). So our goal is the same here, we just took a clean slate approach to find the fundamental features behind HTTP.

Zach

On Apr 5, 2010, at 22:38 , Gilman Tolle wrote:

> I have a question about the HTTP<->CoAP mapping we're chartered to define...
>
> Because the operations in draft-shelby-core-coap-00 are different from the standard HTTP methods, I'd suggest that any mapping is likely to lead to a leaky abstraction between the two protocols. In addition, a mapping could become a source of divergence between CoAP and HTTP as further innovation happens in these two separate spaces.
>
> Do the CoAP protocol operations really need to be different from the HTTP protocol operations?
>
> If we think about this as a compression problem instead of a mapping problem, we could define CoAP as semantically identical to HTTP, but with a more compact concrete representation. Because we're running in constrained networks, we don't have to maintain every arbitrary HTTP optional header across the compression boundary, but we can easily maintain the core protocol operations and naming systems that make HTTP so powerful. Essentially, we'd be defining the CoAP protocol as an easily-compressible profile of HTTP along with a stateless transformation between the compressed and uncompressed versions.
>
> I'd like to point everyone to my EBHTTP draft (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00<= /a>), which presents an alternative compressed-HTTP approach to the design of CoAP (as does the original Chopan draft, for that matter).
>
> I think there are a few other benefits of EBHTTP worth considering:<= br> >
> * automatic stateless transcoding between EBHTTP and HTTP allows us to define upper layers (representation, discovery) once, but have them apply to both kinds of protocols
> * allowing multiple EBHTTP requests to be packed into a single UDP message can increase the overall message efficiency
> * EBHTTP can run over both UDP datagrams and TCP persistent connections
> * having a "response-is-optional" header flag allows for more efficient unreliable message delivery and enables multicast message delivery
> * making the sequence number/transaction id into an option means that we don't pay the sequence number overhead when we don't need it
>
> If we take a compression approach instead of a mapping approach, we still might be introducing abstraction leakage around the size of the resources and the choice of optional HTTP headers that are allowed to make it through the compression process, but at least the basic protocol transformation will remain sound and able to take advantage of future progress in HTTP.
>
> Gil
>
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core

--
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.




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


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



_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------050702080804050803020306-- --------------ms050707060604020408030503 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0 MDcxNjE0MjVaMCMGCSqGSIb3DQEJBDEWBBQpcsCDAu4hVqBxsiF2sf8/he8mTjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAAmrk2+T/IaX6hiNv5Jk72n3HzuivmrlOpF2P5hrypSnDqxRZOiRbpENKmFP9Xub+ca7 FwXPGA0NuD4n+EqwfsVG+5VCEFYCtam0xSwEnOCq99HFFrtpp8l4TeaAa1Ipbf3zgUf1HWZy 02AutZ8Pu56kNhlMJqZ47un7YhAjCNGZA4Qmy+s5q519GFWaUhcolymp58Oj4g1wrEzfOt0w kArVRKvUXspn5d2uU6rrbcmTvkNzH0JF/Fl2pZTU7b0G1itS4Y9ZgqSDnXJ+q0RdxjBUuotl xTeLmUcNmHTE6gG0kZnaC5PmKRgwrrcBIFCAW89jjk5fgX2ONBg9ipp1CQ0AAAAAAAA= --------------ms050707060604020408030503-- From apezzuto@cisco.com Wed Apr 7 23:16: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 ACB973A689D for ; Wed, 7 Apr 2010 23:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, 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 lM2PNcRFflPf for ; Wed, 7 Apr 2010 23:16:20 -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 2AE013A6888 for ; Wed, 7 Apr 2010 23:16:19 -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: AicFALsRvUurRN+J/2dsb2JhbACBPo4ki0pxnnyZGYUJBA X-IronPort-AV: E=Sophos;i="4.52,168,1270425600"; d="scan'208,217";a="112069170" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 08 Apr 2010 06:16:14 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o386GBe8003495; Thu, 8 Apr 2010 06:16: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); Thu, 8 Apr 2010 08:16:12 +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_01CAD6E2.FC4DA10C" Date: Thu, 8 Apr 2010 08:16:15 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC01A7AA94@XMB-AMS-106.cisco.com> In-Reply-To: <4BBCAF61.3020904@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] HTTP and CoAP - mapping and compression Thread-Index: AcrWbbloaPerCBELRBmSu1CYPFuPOgAcsfFQ References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> From: "Adriano Pezzuto (apezzuto)" To: , X-OriginalArrivalTime: 08 Apr 2010 06:16:12.0272 (UTC) FILETIME=[FC9F1F00:01CAD6E2] Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 08 Apr 2010 06:16:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD6E2.FC4DA10C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I think a big issue is not regarding the syntactic mapping and = compression, but the transaction mapping of what is being proposed as a = 'quasi-synchronous' protocol to=20 > synchronous HTTP. Obviously it is straightforward to map synchronous = transactions but if asynchronous transactions take place in the CoAP = environment, they are not > going to statelessly map onto synchronous HTTP. So the 'CoGII' (or = whatever it was called) may resurface and may need to be defined. =20 My opinion here is we do not need to resurface the 'CoGII' (or whatever = it was called). CoAP spec does not need to define an interworking = device. I think we need for a separate CoAP-HTTP spec where define = exactly both the syntactic and semantic mapping among two protocols. > On the same topic, I still don't see the need for NOTIFY in the = current specification. Define the concept of clients with subscription = agents (i.e. in a server role) and either > define a comprehensive callback subscription mechanism, e.g. = SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take it out completely and define = using the CRUD methods. > I prefer the latter. =20 The point here is that CoAP needs for asynch methods due to the nature = of its domain. We can choose to use any combination of CRUD methods to = simulate an asynch data delivery or define a specific asynch methods but = this does not change the point. =20 Adriano =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Robert Cragie Sent: mercoled=EC 7 aprile 2010 18.14 To: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression =20 I think a big issue is not regarding the syntactic mapping and = compression, but the transaction mapping of what is being proposed as a = 'quasi-synchronous' protocol to synchronous HTTP. Obviously it is = straightforward to map synchronous transactions but if asynchronous = transactions take place in the CoAP environment, they are not going to = statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it = was called) may resurface and may need to be defined. On the same topic, I still don't see the need for NOTIFY in the current = specification. Define the concept of clients with subscription agents = (i.e. in a server role) and either define a comprehensive callback = subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take = it out completely and define using the CRUD methods. I prefer the = latter. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 On 06/04/2010 6:10 PM, Lisa Dusseault wrote:=20 I agree, defining a subset is much more valuable than defining a = compression, and that CoAP is something new that ought to steal many = things from HTTP. Defining a mapping of HTTP for gateways to use can reasonably done in = the scale I understand gateways to have. But that means that gateways = have to deal with the "deployed reality" of HTTP, which is pretty bad in = terms of compliance to the HTTP spec and documented interoperability = (although it is even worse when you add in HTML and cookies). That = tradeoff seems reasonable -- requiring complex functionality in a node = that can handle it in order to get some very useful features.=20 Defining a compression of HTTP for the more constrained devices? Not so = helpful. I wrote up my thoughts in more detail here = . Lisa On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank = wrote: Its not really just about compressing HTTP as-is, but the harder issue = is defining the subset of HTTP that is used (because few 6lowpan devices = can really support it all). And even then it probably isn't a clean = subset. For example the host header is required in HTTP, but we = probably don't want to require it in CoAP.=20 =20 So after giving a lot of thought to how HTTP mapping happens with = Chopan, I lean towards saying CoAP is something new with a well defined = scope. Perhaps we may reference semantics in the HTTP spec, but = wouldn't derive from it. I suspect a new separate path will actually = make for a better mapping at the HTTP gateway. =20 But then again I can see the reverse position that the HTTP mapping = becomes a key aspect of our spec, in which case we are effectively = defining a HTTP subset anyhow. =20 On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby wrote: Hi Gil, At the WG meeting (and in the hallways) we actually discussed using = standard GET, PUT, POST, DELETE method names in the next version of the = CoAP draft. Semantically they are already very, very close. I have no = problem with that suggestion (that is actually how we started out). Some of the features you listed below I would surely be open to = discussing for integration into our CoAP specification - they are = already close in header and functionality. Let's discuss that! Sorry I = haven't been able to give comments on your draft yet, recovering from = the IETF takes some time... Regarding Chopan, we have been working with Brian to integrate the ideas = from Chopan for quite a while already. In fact CoAP is a combination of = Chopan and a simple REST design from a clean slate. We had long = discussions on the 6lowapp list during chartering about compressing = HTTP, and my conclusion was that we should not do that (and are not = chartered to do that). The protocol we design in CoRE should be pure to = the REST architecture and semantics which are behind HTTP. If we are = also smart about re-using a subset of HTTP codes etc. then I don't see = that a CoAP conversion to HTTP would be more difficult than = compression/decompression (it should be simpler). So our goal is the = same here, we just took a clean slate approach to find the fundamental = features behind HTTP. Zach On Apr 5, 2010, at 22:38 , Gilman Tolle wrote: > I have a question about the HTTP<->CoAP mapping we're chartered to = define... > > Because the operations in draft-shelby-core-coap-00 are different from = the standard HTTP methods, I'd suggest that any mapping is likely to = lead to a leaky abstraction between the two protocols. In addition, a = mapping could become a source of divergence between CoAP and HTTP as = further innovation happens in these two separate spaces. > > Do the CoAP protocol operations really need to be different from the = HTTP protocol operations? > > If we think about this as a compression problem instead of a mapping = problem, we could define CoAP as semantically identical to HTTP, but = with a more compact concrete representation. Because we're running in = constrained networks, we don't have to maintain every arbitrary HTTP = optional header across the compression boundary, but we can easily = maintain the core protocol operations and naming systems that make HTTP = so powerful. Essentially, we'd be defining the CoAP protocol as an = easily-compressible profile of HTTP along with a stateless = transformation between the compressed and uncompressed versions. > > I'd like to point everyone to my EBHTTP draft = (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents = an alternative compressed-HTTP approach to the design of CoAP (as does = the original Chopan draft, for that matter). > > I think there are a few other benefits of EBHTTP worth considering: > > * automatic stateless transcoding between EBHTTP and HTTP allows us to = define upper layers (representation, discovery) once, but have them = apply to both kinds of protocols > * allowing multiple EBHTTP requests to be packed into a single UDP = message can increase the overall message efficiency > * EBHTTP can run over both UDP datagrams and TCP persistent = connections > * having a "response-is-optional" header flag allows for more = efficient unreliable message delivery and enables multicast message = delivery > * making the sequence number/transaction id into an option means that = we don't pay the sequence number overhead when we don't need it > > If we take a compression approach instead of a mapping approach, we = still might be introducing abstraction leakage around the size of the = resources and the choice of optional HTTP headers that are allowed to = make it through the compression process, but at least the basic protocol = transformation will remain sound and able to take advantage of future = progress in HTTP. > > Gil > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof. _______________________________________________ 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 ------_=_NextPart_001_01CAD6E2.FC4DA10C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> I think a big issue is not regarding the = syntactic mapping and compression, but the transaction mapping of what is being = proposed as a 'quasi-synchronous' protocol to

> synchronous HTTP. Obviously it is = straightforward to map synchronous transactions but if asynchronous transactions take place = in the CoAP environment, they are not

> going to statelessly map onto synchronous = HTTP. So the 'CoGII' (or whatever it was called) may resurface and may need to be = defined.

 

My opinion here is we do not need to resurface the = 'CoGII' (or whatever it was called). CoAP spec does not need to define an = interworking device. I think we need for a separate CoAP-HTTP spec where define = exactly both the syntactic and semantic mapping among two protocols.

> On the same topic, I still don't see the need = for NOTIFY in the current specification. Define the concept of clients with subscription agents (i.e. in a server role) and either

> define a comprehensive callback subscription = mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take it out completely and = define using the CRUD methods.

> I prefer the latter.

 

The point here is that CoAP needs for asynch = methods due to the nature of its domain. We can choose to use any combination of CRUD = methods to simulate an asynch data delivery or define a specific asynch methods = but this does not change the point.

 

Adriano

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Robert Cragie
Sent: mercoled=EC 7 aprile 2010 18.14
To: core@ietf.org
Subject: Re: [core] HTTP and CoAP - mapping and = compression

 

I think a big issue is not regarding the syntactic = mapping and compression, but the transaction mapping of what is being proposed = as a 'quasi-synchronous' protocol to synchronous HTTP. Obviously it is straightforward to map synchronous transactions but if asynchronous transactions take place in the CoAP environment, they are not going to statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it = was called) may resurface and may need to be defined.

On the same topic, I still don't see the need for NOTIFY in the current specification. Define the concept of clients with subscription agents = (i.e. in a server role) and either define a comprehensive callback subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take it out = completely and define using the CRUD methods. I prefer the latter.

Robert

Robert Cragie (Pacific Gas & = Electric)

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


On 06/04/2010 6:10 PM, Lisa Dusseault wrote:

I agree, defining a = subset is much more valuable than defining a compression, and that CoAP is = something new that ought to steal many things from HTTP.

Defining a mapping of HTTP for gateways to use can reasonably done in = the scale I understand gateways to have.  But that means that gateways have = to deal with the "deployed reality" of HTTP, which is pretty bad in = terms of compliance to the HTTP spec and documented interoperability (although it = is even worse when you add in HTML and cookies).  That tradeoff seems reasonable -- requiring complex functionality in a node that can handle = it in order to get some very useful features.

Defining a compression of HTTP for the more constrained devices?  = Not so helpful.   I wrote up my thoughts in more detail here .

Lisa

On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank <brian.tridium@gmail.com> = wrote:

Its not really just about compressing HTTP as-is, = but the harder issue is defining the subset of HTTP that is used (because few = 6lowpan devices can really support it all).  And even then it probably = isn't a clean subset.  For example the host header is required in HTTP, but = we probably don't want to require it in CoAP.

 

So after giving a lot of thought to how HTTP = mapping happens with Chopan, I lean towards saying CoAP is something new with a well = defined scope.  Perhaps we may reference semantics in the HTTP spec, but = wouldn't derive from it.  I suspect a new separate path will actually make = for a better mapping at the HTTP gateway.

 

But then again I can = see the reverse position that the HTTP mapping becomes a key aspect of our spec, = in which case we are effectively defining a HTTP subset = anyhow.

 

On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby <zach@sensinode.com> wrote:

Hi Gil,

At the WG meeting (and in the hallways) we actually discussed using = standard GET, PUT, POST, DELETE method names in the next version of the CoAP = draft. Semantically they are already very, very close. I have no problem with = that suggestion (that is actually how we started out).

Some of the features you listed below I would surely be open to = discussing for integration into our CoAP specification - they are already close in = header and functionality. Let's discuss that! Sorry I haven't been able to give = comments on your draft yet, recovering from the IETF takes some time...

Regarding Chopan, we have been working with Brian to integrate the ideas = from Chopan for quite a while already. In fact CoAP is a combination of = Chopan and a simple REST design from a clean slate. We had long discussions on the = 6lowapp list during chartering about compressing HTTP, and my conclusion was = that we should not do that (and are not chartered to do that). The protocol we = design in CoRE should be pure to the REST architecture and semantics which are = behind HTTP. If we are also smart about re-using a subset of HTTP codes etc. = then I don't see that a CoAP conversion to HTTP would be more difficult than compression/decompression (it should be simpler). So our goal is the = same here, we just took a clean slate approach to find the fundamental features = behind HTTP.

Zach


On Apr 5, 2010, at 22:38 , Gilman Tolle wrote:

> I have a question about the HTTP<->CoAP mapping we're = chartered to define...
>
> Because the operations in draft-shelby-core-coap-00 are different = from the standard HTTP methods, I'd suggest that any mapping is likely to lead to = a leaky abstraction between the two protocols. In addition, a mapping = could become a source of divergence between CoAP and HTTP as further = innovation happens in these two separate spaces.
>
> Do the CoAP protocol operations really need to be different from = the HTTP protocol operations?
>
> If we think about this as a compression problem instead of a = mapping problem, we could define CoAP as semantically identical to HTTP, but = with a more compact concrete representation. Because we're running in = constrained networks, we don't have to maintain every arbitrary HTTP optional header = across the compression boundary, but we can easily maintain the core protocol operations and naming systems that make HTTP so powerful. Essentially, = we'd be defining the CoAP protocol as an easily-compressible profile of HTTP = along with a stateless transformation between the compressed and uncompressed = versions.
>
> I'd like to point everyone to my EBHTTP draft (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents an alternative compressed-HTTP approach to the design of = CoAP (as does the original Chopan draft, for that matter).
>
> I think there are a few other benefits of EBHTTP worth = considering:
>
> * automatic stateless transcoding between EBHTTP and HTTP allows us = to define upper layers (representation, discovery) once, but have them = apply to both kinds of protocols
> * allowing multiple EBHTTP requests to be packed into a single UDP = message can increase the overall message efficiency
> * EBHTTP can run over both UDP datagrams and TCP persistent = connections
> * having a "response-is-optional" header flag allows for = more efficient unreliable message delivery and enables multicast message = delivery
> * making the sequence number/transaction id into an option means = that we don't pay the sequence number overhead when we don't need it
>
> If we take a compression approach instead of a mapping approach, we = still might be introducing abstraction leakage around the size of the = resources and the choice of optional HTTP headers that are allowed to make it through = the compression process, but at least the basic protocol transformation will = remain sound and able to take advantage of future progress in HTTP.
>
> Gil
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net = - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, please = contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.





_______________________________________________
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
=A0 =
------_=_NextPart_001_01CAD6E2.FC4DA10C-- From zach@sensinode.com Thu Apr 8 07:03: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 572FD3A6A39 for ; Thu, 8 Apr 2010 07:03:07 -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=[AWL=1.300, BAYES_00=-2.599, J_BACKHAIR_44=1, 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 fOD1G9ahfB3C for ; Thu, 8 Apr 2010 07:03:05 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8E3CE3A6A45 for ; Thu, 8 Apr 2010 07:02:35 -0700 (PDT) Received: from [192.168.1.3] (line-5684.dyn.kponet.fi [85.29.68.137]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o38E28Wb026486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Apr 2010 17:02:25 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4BBCAF61.3020904@gridmerge.com> Date: Thu, 8 Apr 2010 16:21:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 08 Apr 2010 14:03:07 -0000 On Apr 7, 2010, at 19:14 , Robert Cragie wrote: > I think a big issue is not regarding the syntactic mapping and = compression, but the transaction mapping of what is being proposed as a = 'quasi-synchronous' protocol to synchronous HTTP. Obviously it is = straightforward to map synchronous transactions but if asynchronous = transactions take place in the CoAP environment, they are not going to = statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it = was called) may resurface and may need to be defined. That is a good point, CoAP is required to support an asynchronous push = model in addition to the typical synchronous model that HTTP uses. This = is part of the HTTP mapping description, which could be realized in some = COGII type thing. We don't need to define a COGII, just a mapping (which = correctly will involve state). There will be multiple ways to realize = this on the HTTP side including polling, long poll and other new = bi-directional techniques. We'll need to explore and discuss those...=20 >=20 > On the same topic, I still don't see the need for NOTIFY in the = current specification. Define the concept of clients with subscription = agents (i.e. in a server role) and either define a comprehensive = callback subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL = or take it out completely and define using the CRUD methods. I prefer = the latter. True, it could be possible to realize the notification mechanism = overloading a CRUD method. This gets more difficult if we start calling = those GET, POST, PUT, DELETE. Sending a NOTIFY has very different = semantics to the way synchronous methods work today. Also remember that = notifications can be sent also without a subscription (unsolicited = notification). The meaning of the URL in a notification is also inversed = - as you are notifying about a resource on the initiating server, so the = URL actually refers to a resource on the initiating node! Wouldn't it be = pretty confusing to overload that with existing methods? This is the = reasoning why it is a separate method. We did consider having = subscribe/unsubscribe methods at some point, but wanted to minimize the = number of methods. Plus these are fairly easy to design in a RESTful = manner. =20 Zach >=20 > Robert > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com >=20 >=20 > On 06/04/2010 6:10 PM, Lisa Dusseault wrote: >> I agree, defining a subset is much more valuable than defining a = compression, and that CoAP is something new that ought to steal many = things from HTTP. >>=20 >> Defining a mapping of HTTP for gateways to use can reasonably done in = the scale I understand gateways to have. But that means that gateways = have to deal with the "deployed reality" of HTTP, which is pretty bad in = terms of compliance to the HTTP spec and documented interoperability = (although it is even worse when you add in HTML and cookies). That = tradeoff seems reasonable -- requiring complex functionality in a node = that can handle it in order to get some very useful features.=20 >>=20 >> Defining a compression of HTTP for the more constrained devices? Not = so helpful. I wrote up my thoughts in more detail here . >>=20 >> Lisa >>=20 >> On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank = wrote: >> Its not really just about compressing HTTP as-is, but the harder = issue is defining the subset of HTTP that is used (because few 6lowpan = devices can really support it all). And even then it probably isn't a = clean subset. For example the host header is required in HTTP, but we = probably don't want to require it in CoAP. >>=20 >> So after giving a lot of thought to how HTTP mapping happens with = Chopan, I lean towards saying CoAP is something new with a well defined = scope. Perhaps we may reference semantics in the HTTP spec, but = wouldn't derive from it. I suspect a new separate path will actually = make for a better mapping at the HTTP gateway. >>=20 >> But then again I can see the reverse position that the HTTP mapping = becomes a key aspect of our spec, in which case we are effectively = defining a HTTP subset anyhow. >>=20 >>=20 >> On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby = wrote: >> Hi Gil, >>=20 >> At the WG meeting (and in the hallways) we actually discussed using = standard GET, PUT, POST, DELETE method names in the next version of the = CoAP draft. Semantically they are already very, very close. I have no = problem with that suggestion (that is actually how we started out). >>=20 >> Some of the features you listed below I would surely be open to = discussing for integration into our CoAP specification - they are = already close in header and functionality. Let's discuss that! Sorry I = haven't been able to give comments on your draft yet, recovering from = the IETF takes some time... >>=20 >> Regarding Chopan, we have been working with Brian to integrate the = ideas from Chopan for quite a while already. In fact CoAP is a = combination of Chopan and a simple REST design from a clean slate. We = had long discussions on the 6lowapp list during chartering about = compressing HTTP, and my conclusion was that we should not do that (and = are not chartered to do that). The protocol we design in CoRE should be = pure to the REST architecture and semantics which are behind HTTP. If we = are also smart about re-using a subset of HTTP codes etc. then I don't = see that a CoAP conversion to HTTP would be more difficult than = compression/decompression (it should be simpler). So our goal is the = same here, we just took a clean slate approach to find the fundamental = features behind HTTP. >>=20 >> Zach >>=20 >> On Apr 5, 2010, at 22:38 , Gilman Tolle wrote: >>=20 >> > I have a question about the HTTP<->CoAP mapping we're chartered to = define... >> > >> > Because the operations in draft-shelby-core-coap-00 are different = from the standard HTTP methods, I'd suggest that any mapping is likely = to lead to a leaky abstraction between the two protocols. In addition, a = mapping could become a source of divergence between CoAP and HTTP as = further innovation happens in these two separate spaces. >> > >> > Do the CoAP protocol operations really need to be different from = the HTTP protocol operations? >> > >> > If we think about this as a compression problem instead of a = mapping problem, we could define CoAP as semantically identical to HTTP, = but with a more compact concrete representation. Because we're running = in constrained networks, we don't have to maintain every arbitrary HTTP = optional header across the compression boundary, but we can easily = maintain the core protocol operations and naming systems that make HTTP = so powerful. Essentially, we'd be defining the CoAP protocol as an = easily-compressible profile of HTTP along with a stateless = transformation between the compressed and uncompressed versions. >> > >> > I'd like to point everyone to my EBHTTP draft = (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents = an alternative compressed-HTTP approach to the design of CoAP (as does = the original Chopan draft, for that matter). >> > >> > I think there are a few other benefits of EBHTTP worth considering: >> > >> > * automatic stateless transcoding between EBHTTP and HTTP allows us = to define upper layers (representation, discovery) once, but have them = apply to both kinds of protocols >> > * allowing multiple EBHTTP requests to be packed into a single UDP = message can increase the overall message efficiency >> > * EBHTTP can run over both UDP datagrams and TCP persistent = connections >> > * having a "response-is-optional" header flag allows for more = efficient unreliable message delivery and enables multicast message = delivery >> > * making the sequence number/transaction id into an option means = that we don't pay the sequence number overhead when we don't need it >> > >> > If we take a compression approach instead of a mapping approach, we = still might be introducing abstraction leakage around the size of the = resources and the choice of optional HTTP headers that are allowed to = make it through the compression process, but at least the basic protocol = transformation will remain sound and able to take advantage of future = progress in HTTP. >> > >> > Gil >> > >> > _______________________________________________ >> > core mailing list >> > core@ietf.org >> > https://www.ietf.org/mailman/listinfo/core >>=20 >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >>=20 >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >>=20 >> This e-mail and all attached material are confidential and may = contain legally privileged information. If you are not the intended = recipient, please contact the sender and delete the e-mail from your = system without producing, distributing or retaining copies thereof. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >>=20 >> 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 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From apezzuto@cisco.com Thu Apr 8 08:38: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 E35AD3A6A53 for ; Thu, 8 Apr 2010 08:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_BACKHAIR_44=1, 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 F4mUze9jL0F8 for ; Thu, 8 Apr 2010 08:38:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 063CF3A680E for ; Thu, 8 Apr 2010 08:38:01 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMCAK+VvUuQ/uCWe2dsb2JhbACbNBUBAQsLIgYcoHOZLIUJBA X-IronPort-AV: E=Sophos;i="4.52,171,1270425600"; d="scan'208";a="59153265" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2010 15:37:57 +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 o38FbvUG005715; Thu, 8 Apr 2010 15:37:57 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, 8 Apr 2010 17:37:57 +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: Thu, 8 Apr 2010 17:37:56 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC01B16F1F@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] HTTP and CoAP - mapping and compression Thread-Index: AcrXJDo+709MgMIaTva0ldSc+iUmVwADCizg References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> From: "Adriano Pezzuto (apezzuto)" To: "Zach Shelby" , X-OriginalArrivalTime: 08 Apr 2010 15:37:57.0310 (UTC) FILETIME=[7663C5E0:01CAD731] Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 08 Apr 2010 15:38:34 -0000 > Also remember that notifications can be sent also without a = subscription (unsolicited notification). Unsolicited notifications mean static (implicit or pre-provisioned) = subscriptions. If we need for dynamic (explicit or on-request) = notifications, the explicit Subscribe/Unsubscribe methods may be more = useful, especially in the mobile/nomadic scenarios. Adriano -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Zach Shelby Sent: gioved=EC 8 aprile 2010 15.22 To: robert.cragie@gridmerge.com Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression On Apr 7, 2010, at 19:14 , Robert Cragie wrote: > I think a big issue is not regarding the syntactic mapping and = compression, but the transaction mapping of what is being proposed as a = 'quasi-synchronous' protocol to synchronous HTTP. Obviously it is = straightforward to map synchronous transactions but if asynchronous = transactions take place in the CoAP environment, they are not going to = statelessly map onto synchronous HTTP. So the 'CoGII' (or whatever it = was called) may resurface and may need to be defined. That is a good point, CoAP is required to support an asynchronous push = model in addition to the typical synchronous model that HTTP uses. This = is part of the HTTP mapping description, which could be realized in some = COGII type thing. We don't need to define a COGII, just a mapping (which = correctly will involve state). There will be multiple ways to realize = this on the HTTP side including polling, long poll and other new = bi-directional techniques. We'll need to explore and discuss those...=20 >=20 > On the same topic, I still don't see the need for NOTIFY in the = current specification. Define the concept of clients with subscription = agents (i.e. in a server role) and either define a comprehensive = callback subscription mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL = or take it out completely and define using the CRUD methods. I prefer = the latter. True, it could be possible to realize the notification mechanism = overloading a CRUD method. This gets more difficult if we start calling = those GET, POST, PUT, DELETE. Sending a NOTIFY has very different = semantics to the way synchronous methods work today. Also remember that = notifications can be sent also without a subscription (unsolicited = notification). The meaning of the URL in a notification is also inversed = - as you are notifying about a resource on the initiating server, so the = URL actually refers to a resource on the initiating node! Wouldn't it be = pretty confusing to overload that with existing methods? This is the = reasoning why it is a separate method. We did consider having = subscribe/unsubscribe methods at some point, but wanted to minimize the = number of methods. Plus these are fairly easy to design in a RESTful = manner. =20 Zach >=20 > Robert > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com >=20 >=20 > On 06/04/2010 6:10 PM, Lisa Dusseault wrote: >> I agree, defining a subset is much more valuable than defining a = compression, and that CoAP is something new that ought to steal many = things from HTTP. >>=20 >> Defining a mapping of HTTP for gateways to use can reasonably done in = the scale I understand gateways to have. But that means that gateways = have to deal with the "deployed reality" of HTTP, which is pretty bad in = terms of compliance to the HTTP spec and documented interoperability = (although it is even worse when you add in HTML and cookies). That = tradeoff seems reasonable -- requiring complex functionality in a node = that can handle it in order to get some very useful features.=20 >>=20 >> Defining a compression of HTTP for the more constrained devices? Not = so helpful. I wrote up my thoughts in more detail here . >>=20 >> Lisa >>=20 >> On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank = wrote: >> Its not really just about compressing HTTP as-is, but the harder = issue is defining the subset of HTTP that is used (because few 6lowpan = devices can really support it all). And even then it probably isn't a = clean subset. For example the host header is required in HTTP, but we = probably don't want to require it in CoAP. >>=20 >> So after giving a lot of thought to how HTTP mapping happens with = Chopan, I lean towards saying CoAP is something new with a well defined = scope. Perhaps we may reference semantics in the HTTP spec, but = wouldn't derive from it. I suspect a new separate path will actually = make for a better mapping at the HTTP gateway. >>=20 >> But then again I can see the reverse position that the HTTP mapping = becomes a key aspect of our spec, in which case we are effectively = defining a HTTP subset anyhow. >>=20 >>=20 >> On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby = wrote: >> Hi Gil, >>=20 >> At the WG meeting (and in the hallways) we actually discussed using = standard GET, PUT, POST, DELETE method names in the next version of the = CoAP draft. Semantically they are already very, very close. I have no = problem with that suggestion (that is actually how we started out). >>=20 >> Some of the features you listed below I would surely be open to = discussing for integration into our CoAP specification - they are = already close in header and functionality. Let's discuss that! Sorry I = haven't been able to give comments on your draft yet, recovering from = the IETF takes some time... >>=20 >> Regarding Chopan, we have been working with Brian to integrate the = ideas from Chopan for quite a while already. In fact CoAP is a = combination of Chopan and a simple REST design from a clean slate. We = had long discussions on the 6lowapp list during chartering about = compressing HTTP, and my conclusion was that we should not do that (and = are not chartered to do that). The protocol we design in CoRE should be = pure to the REST architecture and semantics which are behind HTTP. If we = are also smart about re-using a subset of HTTP codes etc. then I don't = see that a CoAP conversion to HTTP would be more difficult than = compression/decompression (it should be simpler). So our goal is the = same here, we just took a clean slate approach to find the fundamental = features behind HTTP. >>=20 >> Zach >>=20 >> On Apr 5, 2010, at 22:38 , Gilman Tolle wrote: >>=20 >> > I have a question about the HTTP<->CoAP mapping we're chartered to = define... >> > >> > Because the operations in draft-shelby-core-coap-00 are different = from the standard HTTP methods, I'd suggest that any mapping is likely = to lead to a leaky abstraction between the two protocols. In addition, a = mapping could become a source of divergence between CoAP and HTTP as = further innovation happens in these two separate spaces. >> > >> > Do the CoAP protocol operations really need to be different from = the HTTP protocol operations? >> > >> > If we think about this as a compression problem instead of a = mapping problem, we could define CoAP as semantically identical to HTTP, = but with a more compact concrete representation. Because we're running = in constrained networks, we don't have to maintain every arbitrary HTTP = optional header across the compression boundary, but we can easily = maintain the core protocol operations and naming systems that make HTTP = so powerful. Essentially, we'd be defining the CoAP protocol as an = easily-compressible profile of HTTP along with a stateless = transformation between the compressed and uncompressed versions. >> > >> > I'd like to point everyone to my EBHTTP draft = (http://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents = an alternative compressed-HTTP approach to the design of CoAP (as does = the original Chopan draft, for that matter). >> > >> > I think there are a few other benefits of EBHTTP worth considering: >> > >> > * automatic stateless transcoding between EBHTTP and HTTP allows us = to define upper layers (representation, discovery) once, but have them = apply to both kinds of protocols >> > * allowing multiple EBHTTP requests to be packed into a single UDP = message can increase the overall message efficiency >> > * EBHTTP can run over both UDP datagrams and TCP persistent = connections >> > * having a "response-is-optional" header flag allows for more = efficient unreliable message delivery and enables multicast message = delivery >> > * making the sequence number/transaction id into an option means = that we don't pay the sequence number overhead when we don't need it >> > >> > If we take a compression approach instead of a mapping approach, we = still might be introducing abstraction leakage around the size of the = resources and the choice of optional HTTP headers that are allowed to = make it through the compression process, but at least the basic protocol = transformation will remain sound and able to take advantage of future = progress in HTTP. >> > >> > Gil >> > >> > _______________________________________________ >> > core mailing list >> > core@ietf.org >> > https://www.ietf.org/mailman/listinfo/core >>=20 >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >>=20 >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >>=20 >> This e-mail and all attached material are confidential and may = contain legally privileged information. If you are not the intended = recipient, please contact the sender and delete the e-mail from your = system without producing, distributing or retaining copies thereof. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >>=20 >> 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 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From robert.cragie@gridmerge.com Thu Apr 8 08:47: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 CFE443A68B3 for ; Thu, 8 Apr 2010 08:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, 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 Bwvj1pgf48cu for ; Thu, 8 Apr 2010 08:47:22 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 9D5E43A680E for ; Thu, 8 Apr 2010 08:47:21 -0700 (PDT) Received: from client-86-31-240-112.oxfd.adsl.virginmedia.com ([86.31.240.112] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1Nztwq-0007gF-Py; Thu, 08 Apr 2010 16:47:17 +0100 Message-ID: <4BBDFA7E.7040804@gridmerge.com> Date: Thu, 08 Apr 2010 16:47:10 +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: Zach Shelby References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010505040601080001080108" Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:47:24 -0000 This is a cryptographically signed message in MIME format. --------------ms010505040601080001080108 Content-Type: multipart/alternative; boundary="------------080709070905030701080402" This is a multi-part message in MIME format. --------------080709070905030701080402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Zach, Comments inline, bracketed by . Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 08/04/2010 2:21 PM, Zach Shelby wrote: > On Apr 7, 2010, at 19:14 , Robert Cragie wrote: > > =20 >> I think a big issue is not regarding the syntactic mapping and compres= sion, but the transaction mapping of what is being proposed as a 'quasi-s= ynchronous' protocol to synchronous HTTP. Obviously it is straightforward= to map synchronous transactions but if asynchronous transactions take pl= ace in the CoAP environment, they are not going to statelessly map onto s= ynchronous HTTP. So the 'CoGII' (or whatever it was called) may resurface= and may need to be defined. >> =20 > That is a good point, CoAP is required to support an asynchronous push = model in addition to the typical synchronous model that HTTP uses. This i= s part of the HTTP mapping description, which could be realized in some C= OGII type thing. We don't need to define a COGII, just a mapping (which c= orrectly will involve state). There will be multiple ways to realize this= on the HTTP side including polling, long poll and other new bi-direction= al techniques. We'll need to explore and discuss those... > =20 I agree, the mapping should be sufficient if you include the=20 stateful aspect. > =20 >> On the same topic, I still don't see the need for NOTIFY in the curren= t specification. Define the concept of clients with subscription agents (= i.e. in a server role) and either define a comprehensive callback subscri= ption mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take it out co= mpletely and define using the CRUD methods. I prefer the latter. >> =20 > True, it could be possible to realize the notification mechanism overlo= ading a CRUD method. This gets more difficult if we start calling those G= ET, POST, PUT, DELETE. Sending a NOTIFY has very different semantics to t= he way synchronous methods work today. Also remember that notifications c= an be sent also without a subscription (unsolicited notification). The me= aning of the URL in a notification is also inversed - as you are notifyin= g about a resource on the initiating server, so the URL actually refers t= o a resource on the initiating node! Wouldn't it be pretty confusing to o= verload that with existing methods? This is the reasoning why it is a sep= arate method. We did consider having subscribe/unsubscribe methods at som= e point, but wanted to minimize the number of methods. Plus these are fai= rly easy to design in a RESTful manner. > =20 The way I see it is that NOTIFY doesn't fit in terms of abstraction: (1) CoAP message ^ | (2) Request/response ^ | (3) CRUD methods NOTIFY is defined at level (3) but really belongs at level (2), as it is = just a message distinct from request/response from A to B without any=20 further implied meaning other than what's in the payload. Even then, the = use of request/response suggests synchronisation, but a request with the = A bit clear doesn't require it so becomes very similar to a notify. I don't see how an unsolicited notification to a URL is any different to = an UPDATE. If it's unsolicited, the URL bears no obvious relationship to = any initiating client, therefore it can be treated as a server. A=20 solicited NOTIFY would be better served with an asynchronous READ=20 request/response; the response is then clearly tagged to what solicited i= t. Anyway, just some food for thought. I'm not going to get too hung up=20 about this :-) > Zach > > =20 >> Robert >> Robert Cragie (Pacific Gas& Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 (0) 1924 910888 >> http://www.gridmerge.com >> >> >> On 06/04/2010 6:10 PM, Lisa Dusseault wrote: >> =20 >>> I agree, defining a subset is much more valuable than defining a comp= ression, and that CoAP is something new that ought to steal many things f= rom HTTP. >>> >>> Defining a mapping of HTTP for gateways to use can reasonably done in= the scale I understand gateways to have. But that means that gateways h= ave to deal with the "deployed reality" of HTTP, which is pretty bad in t= erms of compliance to the HTTP spec and documented interoperability (alth= ough it is even worse when you add in HTML and cookies). That tradeoff s= eems reasonable -- requiring complex functionality in a node that can han= dle it in order to get some very useful features. >>> >>> Defining a compression of HTTP for the more constrained devices? Not= so helpful. I wrote up my thoughts in more detail here . >>> >>> Lisa >>> >>> On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank = wrote: >>> Its not really just about compressing HTTP as-is, but the harder issu= e is defining the subset of HTTP that is used (because few 6lowpan device= s can really support it all). And even then it probably isn't a clean su= bset. For example the host header is required in HTTP, but we probably d= on't want to require it in CoAP. >>> >>> So after giving a lot of thought to how HTTP mapping happens with Cho= pan, I lean towards saying CoAP is something new with a well defined scop= e. Perhaps we may reference semantics in the HTTP spec, but wouldn't der= ive from it. I suspect a new separate path will actually make for a bett= er mapping at the HTTP gateway. >>> >>> But then again I can see the reverse position that the HTTP mapping b= ecomes a key aspect of our spec, in which case we are effectively definin= g a HTTP subset anyhow. >>> >>> >>> On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby wrot= e: >>> Hi Gil, >>> >>> At the WG meeting (and in the hallways) we actually discussed using s= tandard GET, PUT, POST, DELETE method names in the next version of the Co= AP draft. Semantically they are already very, very close. I have no probl= em with that suggestion (that is actually how we started out). >>> >>> Some of the features you listed below I would surely be open to discu= ssing for integration into our CoAP specification - they are already clos= e in header and functionality. Let's discuss that! Sorry I haven't been a= ble to give comments on your draft yet, recovering from the IETF takes so= me time... >>> >>> Regarding Chopan, we have been working with Brian to integrate the id= eas from Chopan for quite a while already. In fact CoAP is a combination = of Chopan and a simple REST design from a clean slate. We had long discus= sions on the 6lowapp list during chartering about compressing HTTP, and m= y conclusion was that we should not do that (and are not chartered to do = that). The protocol we design in CoRE should be pure to the REST architec= ture and semantics which are behind HTTP. If we are also smart about re-u= sing a subset of HTTP codes etc. then I don't see that a CoAP conversion = to HTTP would be more difficult than compression/decompression (it should= be simpler). So our goal is the same here, we just took a clean slate ap= proach to find the fundamental features behind HTTP. >>> >>> Zach >>> >>> On Apr 5, 2010, at 22:38 , Gilman Tolle wrote: >>> >>> =20 >>>> I have a question about the HTTP<->CoAP mapping we're chartered to d= efine... >>>> >>>> Because the operations in draft-shelby-core-coap-00 are different fr= om the standard HTTP methods, I'd suggest that any mapping is likely to l= ead to a leaky abstraction between the two protocols. In addition, a mapp= ing could become a source of divergence between CoAP and HTTP as further = innovation happens in these two separate spaces. >>>> >>>> Do the CoAP protocol operations really need to be different from the= HTTP protocol operations? >>>> >>>> If we think about this as a compression problem instead of a mapping= problem, we could define CoAP as semantically identical to HTTP, but wit= h a more compact concrete representation. Because we're running in constr= ained networks, we don't have to maintain every arbitrary HTTP optional h= eader across the compression boundary, but we can easily maintain the cor= e protocol operations and naming systems that make HTTP so powerful. Esse= ntially, we'd be defining the CoAP protocol as an easily-compressible pro= file of HTTP along with a stateless transformation between the compressed= and uncompressed versions. >>>> >>>> I'd like to point everyone to my EBHTTP draft (http://tools.ietf.org= /html/draft-tolle-core-ebhttp-00), which presents an alternative compress= ed-HTTP approach to the design of CoAP (as does the original Chopan draft= , for that matter). >>>> >>>> I think there are a few other benefits of EBHTTP worth considering: >>>> >>>> * automatic stateless transcoding between EBHTTP and HTTP allows us = to define upper layers (representation, discovery) once, but have them ap= ply to both kinds of protocols >>>> * allowing multiple EBHTTP requests to be packed into a single UDP m= essage can increase the overall message efficiency >>>> * EBHTTP can run over both UDP datagrams and TCP persistent connecti= ons >>>> * having a "response-is-optional" header flag allows for more effici= ent unreliable message delivery and enables multicast message delivery >>>> * making the sequence number/transaction id into an option means tha= t we don't pay the sequence number overhead when we don't need it >>>> >>>> If we take a compression approach instead of a mapping approach, we = still might be introducing abstraction leakage around the size of the res= ources and the choice of optional HTTP headers that are allowed to make i= t through the compression process, but at least the basic protocol transf= ormation will remain sound and able to take advantage of future progress = in HTTP. >>>> >>>> Gil >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> =20 >>> -- >>> http://www.sensinode.com >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Inter= net" >>> Mobile: +358 40 7796297 >>> >>> Zach Shelby >>> Head of Research >>> Sensinode Ltd. >>> Kidekuja 2 >>> 88610 Vuokatti, FINLAND >>> >>> This e-mail and all attached material are confidential and may contai= n legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> =20 > =20 --------------080709070905030701080402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Zach,

Comments inline, bracketed by <RCC></RCC>.

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 08/04/2010 2:21 PM, Zach Shelby wrote: 
On Apr 7, 2010, at 19:14 , Robert Cragie wrote:

  
I think a big issue is not regarding the syntactic map=
ping and compression, but the transaction mapping of what is being propos=
ed as a 'quasi-synchronous' protocol to synchronous HTTP. Obviously it is=
 straightforward to map synchronous transactions but if asynchronous tran=
sactions take place in the CoAP environment, they are not going to statel=
essly map onto synchronous HTTP. So the 'CoGII' (or whatever it was calle=
d) may resurface and may need to be defined.
    
That is a good point, CoAP is required to support an asynchronous push mo=
del in addition to the typical synchronous model that HTTP uses. This is =
part of the HTTP mapping description, which could be realized in some COG=
II type thing. We don't need to define a COGII, just a mapping (which cor=
rectly will involve state). There will be multiple ways to realize this o=
n the HTTP side including polling, long poll and other new bi-directional=
 techniques. We'll need to explore and discuss those...=20
<RCC>I agree, the mapping should be sufficient if you include the stateful aspect.</RCC>
  
On the same topic, I still don't see the need for NOTIFY in the current s=
pecification. Define the concept of clients with subscription agents (i.e=
=2E in a server role) and either define a comprehensive callback subscrip=
tion mechanism, e.g. SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL or take it out com=
pletely and define using the CRUD methods. I prefer the latter.
    
True, it could be possible to realize the notification mechanism overload=
ing a CRUD method. This gets more difficult if we start calling those GET=
, POST, PUT, DELETE. Sending a NOTIFY has very different semantics to the=
 way synchronous methods work today. Also remember that notifications can=
 be sent also without a subscription (unsolicited notification). The mean=
ing of the URL in a notification is also inversed - as you are notifying =
about a resource on the initiating server, so the URL actually refers to =
a resource on the initiating node! Wouldn't it be pretty confusing to ove=
rload that with existing methods? This is the reasoning why it is a separ=
ate method. We did consider having subscribe/unsubscribe methods at some =
point, but wanted to minimize the number of methods. Plus these are fairl=
y easy to design in a RESTful manner.  =20
<RCC>
The way I see it is that NOTIFY doesn't fit in terms of abstraction:

(1) CoAP message
      ^
      |
(2) Request/response
      ^
      |
(3) CRUD methods
  
NOTIFY is defined at level (3) but really belongs at level (2), as it is just a message distinct from request/response from A to B without any further implied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit clear doesn't require it so becomes very similar to a notify.

I don't see how an unsolicited notification to a URL is any different to an UPDATE. If it's unsolicited, the URL bears no obvious relationship to any initiating client, therefore it can be treated as a server. A solicited NOTIFY would be better served with an asynchronous READ request/response; the response is then clearly tagged to what solicited it.

Anyway, just some food for thought. I'm not going to get too hung up about this :-)
</RCC>

Zach

  
Robert
Robert Cragie (Pacific Gas & Electric)

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


On 06/04/2010 6:10 PM, Lisa Dusseault wrote:
    
I agree, defining a subset is much more valuable tha=
n defining a compression, and that CoAP is something new that ought to st=
eal many things from HTTP.

Defining a mapping of HTTP for gateways to use can reasonably done in the=
 scale I understand gateways to have.  But that means that gateways have =
to deal with the "deployed reality" of HTTP, which is pretty bad in terms=
 of compliance to the HTTP spec and documented interoperability (although=
 it is even worse when you add in HTML and cookies).  That tradeoff seems=
 reasonable -- requiring complex functionality in a node that can handle =
it in order to get some very useful features.=20

Defining a compression of HTTP for the more constrained devices?  Not so =
helpful.   I wrote up my thoughts in more detail here .

Lisa

On Mon, Apr 5, 2010 at 4:34 PM, Brian Frank <brian.tridium@gmail.com=
> wrote:
Its not really just about compressing HTTP as-is, but the harder issue is=
 defining the subset of HTTP that is used (because few 6lowpan devices ca=
n really support it all).  And even then it probably isn't a clean subset=
=2E  For example the host header is required in HTTP, but we probably don=
't want to require it in CoAP.

So after giving a lot of thought to how HTTP mapping happens with Chopan,=
 I lean towards saying CoAP is something new with a well defined scope.  =
Perhaps we may reference semantics in the HTTP spec, but wouldn't derive =
from it.  I suspect a new separate path will actually make for a better m=
apping at the HTTP gateway.

But then again I can see the reverse position that the HTTP mapping becom=
es a key aspect of our spec, in which case we are effectively defining a =
HTTP subset anyhow.


On Mon, Apr 5, 2010 at 5:12 PM, Zach Shelby <zach@sensinode.com> w=
rote:
Hi Gil,

At the WG meeting (and in the hallways) we actually discussed using stand=
ard GET, PUT, POST, DELETE method names in the next version of the CoAP d=
raft. Semantically they are already very, very close. I have no problem w=
ith that suggestion (that is actually how we started out).

Some of the features you listed below I would surely be open to discussin=
g for integration into our CoAP specification - they are already close in=
 header and functionality. Let's discuss that! Sorry I haven't been able =
to give comments on your draft yet, recovering from the IETF takes some t=
ime...

Regarding Chopan, we have been working with Brian to integrate the ideas =
from Chopan for quite a while already. In fact CoAP is a combination of C=
hopan and a simple REST design from a clean slate. We had long discussion=
s on the 6lowapp list during chartering about compressing HTTP, and my co=
nclusion was that we should not do that (and are not chartered to do that=
). The protocol we design in CoRE should be pure to the REST architecture=
 and semantics which are behind HTTP. If we are also smart about re-using=
 a subset of HTTP codes etc. then I don't see that a CoAP conversion to H=
TTP would be more difficult than compression/decompression (it should be =
simpler). So our goal is the same here, we just took a clean slate approa=
ch to find the fundamental features behind HTTP.

Zach

On Apr 5, 2010, at 22:38 , Gilman Tolle wrote:

      
I have a question about the HTTP<->CoAP mapp=
ing we're chartered to define...

Because the operations in draft-shelby-core-coap-00 are different from th=
e standard HTTP methods, I'd suggest that any mapping is likely to lead t=
o a leaky abstraction between the two protocols. In addition, a mapping c=
ould become a source of divergence between CoAP and HTTP as further innov=
ation happens in these two separate spaces.

Do the CoAP protocol operations really need to be different from the HTTP=
 protocol operations?

If we think about this as a compression problem instead of a mapping prob=
lem, we could define CoAP as semantically identical to HTTP, but with a m=
ore compact concrete representation. Because we're running in constrained=
 networks, we don't have to maintain every arbitrary HTTP optional header=
 across the compression boundary, but we can easily maintain the core pro=
tocol operations and naming systems that make HTTP so powerful. Essential=
ly, we'd be defining the CoAP protocol as an easily-compressible profile =
of HTTP along with a stateless transformation between the compressed and =
uncompressed versions.

I'd like to point everyone to my EBHTTP draft (h=
ttp://tools.ietf.org/html/draft-tolle-core-ebhttp-00), which presents=
 an alternative compressed-HTTP approach to the design of CoAP (as does t=
he original Chopan draft, for that matter).

I think there are a few other benefits of EBHTTP worth considering:

* automatic stateless transcoding between EBHTTP and HTTP allows us to de=
fine upper layers (representation, discovery) once, but have them apply t=
o both kinds of protocols
* allowing multiple EBHTTP requests to be packed into a single UDP messag=
e can increase the overall message efficiency
* EBHTTP can run over both UDP datagrams and TCP persistent connections
* having a "response-is-optional" header flag allows for more efficient u=
nreliable message delivery and enables multicast message delivery
* making the sequence number/transaction id into an option means that we =
don't pay the sequence number overhead when we don't need it

If we take a compression approach instead of a mapping approach, we still=
 might be introducing abstraction leakage around the size of the resource=
s and the choice of optional HTTP headers that are allowed to make it thr=
ough the compression process, but at least the basic protocol transformat=
ion will remain sound and able to take advantage of future progress in HT=
TP.

Gil

_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
        
--
http=
://www.sensinode.com
http://=
zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Inter=
net"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain le=
gally privileged information. If you are not the intended recipient, plea=
se contact the sender and delete the e-mail from your system without prod=
ucing, distributing or retaining copies thereof.




_______________________________________________
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

      
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------080709070905030701080402-- --------------ms010505040601080001080108 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0 MDgxNTQ3MTBaMCMGCSqGSIb3DQEJBDEWBBSMUPuHyRdWgUmVpytRGr/Z0IKYBTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBACPVH7jt14idkcyuuMthUMigUwbRUMErYgdjprNJQnqTomZZFp5OKtAv3kdBfxuWQDJY RrDlmNbkVauTXNwR7mNonqn41IWIaCbFVtfxROeYjH2VZYnINL4/pwS3mXHyr9vmcVwfmigH wRnAMOg6PWjPvA5KmRQZblhpVSV1z2x1WCyCgFNUc4jT6t/tnijAsA69WmvYtA+inDF9TdYh v0ODI+Xts1fdUfBO/EjppTHULFEUX8rJFQClgbxNZxgY9thOnX2jjRJug7VcFnZDaK+thyYw I+A5J80rh+mk3T568jIsVPQWnIUsngQCXeHKQGLilCnqZDAvwU2V6+OREp4AAAAAAAA= --------------ms010505040601080001080108-- From zach@sensinode.com Thu Apr 8 13:11:26 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 7DB603A69AC for ; Thu, 8 Apr 2010 13:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXoo42tjFUWc for ; Thu, 8 Apr 2010 13:11:25 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3F8F73A6927 for ; Thu, 8 Apr 2010 13:11:22 -0700 (PDT) Received: from [192.168.1.3] (line-5684.dyn.kponet.fi [85.29.68.137]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o38KB7Lo006048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Apr 2010 23:11:10 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4BBDFA7E.7040804@gridmerge.com> Date: Thu, 8 Apr 2010 23:11:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> <4BBDFA7E.7040804@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 08 Apr 2010 20:11:26 -0000 On Apr 8, 2010, at 18:47 , Robert Cragie wrote: > > The way I see it is that NOTIFY doesn't fit in terms of abstraction: >=20 > (1) CoAP message > ^ > | > (2) Request/response > ^ > | > (3) CRUD methods > =20 > NOTIFY is defined at level (3) but really belongs at level (2), as it = is just a message distinct from request/response from A to B without any = further implied meaning other than what's in the payload. Even then, the = use of request/response suggests synchronisation, but a request with the = A bit clear doesn't require it so becomes very similar to a notify. Got you. Sure, we could think about notification as a feature of = req/res. I had considered that at some point, and even making an = explicit notification message type. In agree we can live with just = req/res messages though.=20 >=20 > I don't see how an unsolicited notification to a URL is any different = to an UPDATE. If it's unsolicited, the URL bears no obvious relationship = to any initiating client, therefore it can be treated as a server. Any notification, even unsolicited, should be about a resource of the = sender of the notification. I think this is more about REST modeling of = notifications about resources and subscription rather than a transport = protocol issue. Maybe we should approach this by designing how RESTful = notification and subscription should function - and then figure out how = to realize it in CoAP? > A solicited NOTIFY would be better served with an asynchronous READ = request/response; the response is then clearly tagged to what solicited = it. This is equivalent to an HTTP long poll. The request would stay open = (not yet responded to) until there is a change/period at which point a = response is sent. Would that cause any problem with transaction IDs for = very long polls, and would this be a one-off mechanism or can a single = request have more than one response?=20 >=20 > Anyway, just some food for thought. I'm not going to get too hung up = about this :-) No problem, useful discussion! I myself am pretty neutral on how to = solve this one, we just need to find something that works.=20 Zach > --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From lisa.dusseault@gmail.com Thu Apr 8 19:31: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 1DECE3A6781 for ; Thu, 8 Apr 2010 19:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=1.244, 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 EPQVi92rCyfF for ; Thu, 8 Apr 2010 19:31:42 -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 298A33A672F for ; Thu, 8 Apr 2010 19:31:42 -0700 (PDT) Received: by vws4 with SMTP id 4so86681vws.31 for ; Thu, 08 Apr 2010 19:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=8u9Tu4oXHMnrFopyAirMDC+c7mGEdfHfoNDw2NAgYgQ=; b=kY6QhtoaYn2adFWpV370BDkId8dfq8DA2tq1whE/DnRzrScd81cmleDx6sjv5SFHmQ hlBMMXPDBHHDq7vMHifoBiGrRnFhml4yfxrhKLyMdWHyitfbvIyzdB96lPrh81UKqPpZ NecW4KoXMpAmOA2kQWFk47ih0P1AwPAaqMFS0= 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 :cc:content-type; b=aj/2Pg3zkHn+31SLQ3t3USoxOZsaS9CeT2cwkCgXaaYujz/YOzNuZEnmP8O33NlFfU Hs2tAhazaUSJcMECJfPJgbKOiHTIObOBkddO5LQzWjJdK4iExWFEqcAOmtKNBFRiV89i DDY0kJxPGHDd110eGxTtPt8gtGLFdLPARvEZo= MIME-Version: 1.0 Received: by 10.220.124.221 with HTTP; Thu, 8 Apr 2010 19:31:35 -0700 (PDT) In-Reply-To: <4BBDFA7E.7040804@gridmerge.com> References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> <4BBDFA7E.7040804@gridmerge.com> Date: Thu, 8 Apr 2010 19:31:35 -0700 Received: by 10.220.61.197 with SMTP id u5mr784096vch.72.1270780295245; Thu, 08 Apr 2010 19:31:35 -0700 (PDT) Message-ID: From: Lisa Dusseault To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=e0cb4e887cb715ef5a0483c49819 Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 09 Apr 2010 02:31:43 -0000 --e0cb4e887cb715ef5a0483c49819 Content-Type: text/plain; charset=ISO-8859-1 > The way I see it is that NOTIFY doesn't fit in terms of abstraction: > > (1) CoAP message > ^ > | > (2) Request/response > ^ > | > (3) CRUD methods > > NOTIFY is defined at level (3) but really belongs at level (2), as it is > just a message distinct from request/response from A to B without any > further implied meaning other than what's in the payload. Even then, the use > of request/response suggests synchronisation, but a request with the A bit > clear doesn't require it so becomes very similar to a notify. > > I don't see how an unsolicited notification to a URL is any different to an > UPDATE. If it's unsolicited, the URL bears no obvious relationship to any > initiating client, therefore it can be treated as a server. A solicited > NOTIFY would be better served with an asynchronous READ request/response; > the response is then clearly tagged to what solicited it. > > Anyway, just some food for thought. I'm not going to get too hung up about > this :-) > > > That's an excellent point. The CRUD operation on the resource might be PUSH (or Reverse PUT, containing the resource representation in a broadcast or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer semantic. Lisa --e0cb4e887cb715ef5a0483c49819 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <RCC>
The way I see it is that NOTIFY doesn't fit in terms of abstraction:
(1) CoAP message
=A0=A0=A0=A0=A0 ^
=A0=A0=A0=A0=A0 |
(2) Request/response
=A0=A0 =A0=A0 ^
=A0 =A0 =A0 |
(3) CRUD methods
=A0=A0
NOTIFY is defined at level (3) but really belongs at level (2), as it is just a message distinct from request/response from A to B without any further implied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit clear doesn't require it so becomes very similar to a notify.

I don't see how an unsolicited notification to a URL is any different to an UPDATE. If it's unsolicited, the URL bears no obvious relationship to any initiating client, therefore it can be treated as a server. A solicited NOTIFY would be better served with an asynchronous READ request/response; the response is then clearly tagged to what solicited it.

Anyway, just some food for thought. I'm not going to get too hung up about this :-)
</RCC>


That'= s an excellent point.=A0 The CRUD operation on the resource might be PUSH (= or Reverse PUT, containing the resource representation in a broadcast or un= icast) or CHANGED (containing no body) but just NOTIFY is a transfer semant= ic.

Lisa
--e0cb4e887cb715ef5a0483c49819-- From brian.tridium@gmail.com Fri Apr 9 05:48: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 DF33E3A6915 for ; Fri, 9 Apr 2010 05:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 tZp6NCsCg3b4 for ; Fri, 9 Apr 2010 05:48:14 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 5F07A3A690B for ; Fri, 9 Apr 2010 05:48:14 -0700 (PDT) Received: by bwz9 with SMTP id 9so2623309bwz.29 for ; Fri, 09 Apr 2010 05:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=GHgEat+x9Ida7kvhLeAZ6oq9TynfjBQ2E0DxBZiaq/8=; b=lBiXZOBAMgYcAvOKt+mpUF5FyUQz+MWQI1h2X1QujmnC14rBcFH4nmhxruDOvj2pJe yeg5sNrW1FLkWDZitPo3JzTDB4454hNGENziGgxJYXKRFtxJ34yO9xrQjR+Gp+eDnRem oxTgLCsyqHap7YxOfGA98xm3E2CZNExZum5ho= 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 :cc:content-type; b=N/pXqlyODZPArOCQ8A8eezvoPPB0iwDsI518NmAip2YLkmDSItV1Fv2aGyPfUrpYFD 90s7XKpqel7GXxChAzWeQNX3t6matSUziGv8+5e/K1UF0Yuh9tvifJ1zGWHCVHpn+MXN 6g7e1C5hYhRO0mvCP2rBMy4T7jyMZ1T4nzStw= MIME-Version: 1.0 Received: by 10.204.71.212 with HTTP; Fri, 9 Apr 2010 05:48:07 -0700 (PDT) In-Reply-To: References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> <4BBDFA7E.7040804@gridmerge.com> Date: Fri, 9 Apr 2010 08:48:07 -0400 Received: by 10.204.136.156 with SMTP id r28mr21034bkt.112.1270817287385; Fri, 09 Apr 2010 05:48:07 -0700 (PDT) Message-ID: From: Brian Frank To: Lisa Dusseault Content-Type: multipart/alternative; boundary=0015174a0e1cfd34c50483cd34b4 Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 09 Apr 2010 12:48:16 -0000 --0015174a0e1cfd34c50483cd34b4 Content-Type: text/plain; charset=ISO-8859-1 Regarding async notification, lets keep in mind that existing HTTP application level protocols such as oBIX and OPC-UA already have a subscription and notification model (both using polls, potentially long-polls). On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault wrote: > > >> The way I see it is that NOTIFY doesn't fit in terms of abstraction: >> >> (1) CoAP message >> ^ >> | >> (2) Request/response >> ^ >> | >> (3) CRUD methods >> >> NOTIFY is defined at level (3) but really belongs at level (2), as it is >> just a message distinct from request/response from A to B without any >> further implied meaning other than what's in the payload. Even then, the use >> of request/response suggests synchronisation, but a request with the A bit >> clear doesn't require it so becomes very similar to a notify. >> >> I don't see how an unsolicited notification to a URL is any different to >> an UPDATE. If it's unsolicited, the URL bears no obvious relationship to any >> initiating client, therefore it can be treated as a server. A solicited >> NOTIFY would be better served with an asynchronous READ request/response; >> the response is then clearly tagged to what solicited it. >> >> Anyway, just some food for thought. I'm not going to get too hung up about >> this :-) >> >> >> > That's an excellent point. The CRUD operation on the resource might be > PUSH (or Reverse PUT, containing the resource representation in a broadcast > or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer > semantic. > > Lisa > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --0015174a0e1cfd34c50483cd34b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Regarding async notification, lets keep in mind that existing HTTP applicat= ion level protocols such as oBIX and OPC-UA already have a subscription and= notification model (both using polls, potentially long-polls).


On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dussea= ult <lisa.= dusseault@gmail.com> wrote:
The way I see it is that NOTIFY doesn't fit in terms of abstraction:
(1) CoAP message
=A0=A0=A0=A0=A0 ^
=A0=A0=A0=A0=A0 |
(2) Request/response
=A0=A0 =A0=A0 ^
=A0 =A0 =A0 |
(3) CRUD methods
=A0=A0
NOTIFY is defined at level (3) but really belongs at level (2), as it is just a message distinct from request/response from A to B without any further implied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit clear doesn't require it so becomes very similar to a notify.

I don't see how an unsolicited notification to a URL is any different to an UPDATE. If it's unsolicited, the URL bears no obvious relationship to any initiating client, therefore it can be treated as a server. A solicited NOTIFY would be better served with an asynchronous READ request/response; the response is then clearly tagged to what solicited it.

Anyway, just some food for thought. I'm not going to get too hung up about this :-)
</RCC>


Tha= t's an excellent point.=A0 The CRUD operation on the resource might be = PUSH (or Reverse PUT, containing the resource representation in a broadcast= or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer = semantic.

Lisa

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


--0015174a0e1cfd34c50483cd34b4-- From d.sturek@att.net Fri Apr 9 06:58:48 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 E84AC3A6874 for ; Fri, 9 Apr 2010 06:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 J6UbSMu4SeML for ; Fri, 9 Apr 2010 06:58:48 -0700 (PDT) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id E8C7D3A6808 for ; Fri, 9 Apr 2010 06:58:47 -0700 (PDT) Received: (qmail 27924 invoked from network); 9 Apr 2010 13:58:41 -0000 Received: from adsl-69-108-50-59.dsl.sndg02.pacbell.net (d.sturek@69.108.50.59 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 09 Apr 2010 06:58:41 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: SW5DmAAVM1n.YAJMilwPD..ky4oSFLKTHtllRMDIwIEg0cXbDgHIdxEfMbCiLatCGEAHayxYwUhCkoBUp313hYEATFo8jKI829v6w_lL8Lmw92GhWcOXsmliUYDb.FoMg8OwT5_Fx_Q1.VdQHyzbQKBneaed4YjlqqUXzgmobfCArC3Y3D01Hd_sivLKsRdk1Mzq4wLTftjvJG.04m7WnQyYb4wOGrFOfmJXM.S7V..dhwyeU.qDZf2xE9leFBp9PMRqKRjjpTxBL7LoFD6xHoqFM3V1AGo1PT96iG8291nAOVoRNy8- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Brian Frank'" , "'Lisa Dusseault'" References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> <4BBDFA7E.7040804@gridmerge.com> In-Reply-To: Date: Fri, 9 Apr 2010 06:58:40 -0700 Message-ID: <00d001cad7ec$c2c2cb00$48486100$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01CAD7B2.1663F300" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrX4uusrYje9+dRRLalOoo1VFa5SgACckTw Content-Language: en-us Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 09 Apr 2010 13:58:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D1_01CAD7B2.1663F300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit oBIX is an inappropriate technology for constrained devices. Don From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Brian Frank Sent: Friday, April 09, 2010 5:48 AM To: Lisa Dusseault Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression Regarding async notification, lets keep in mind that existing HTTP application level protocols such as oBIX and OPC-UA already have a subscription and notification model (both using polls, potentially long-polls). On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault wrote: The way I see it is that NOTIFY doesn't fit in terms of abstraction: (1) CoAP message ^ | (2) Request/response ^ | (3) CRUD methods NOTIFY is defined at level (3) but really belongs at level (2), as it is just a message distinct from request/response from A to B without any further implied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit clear doesn't require it so becomes very similar to a notify. I don't see how an unsolicited notification to a URL is any different to an UPDATE. If it's unsolicited, the URL bears no obvious relationship to any initiating client, therefore it can be treated as a server. A solicited NOTIFY would be better served with an asynchronous READ request/response; the response is then clearly tagged to what solicited it. Anyway, just some food for thought. I'm not going to get too hung up about this :-) That's an excellent point. The CRUD operation on the resource might be PUSH (or Reverse PUT, containing the resource representation in a broadcast or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer semantic. Lisa _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_00D1_01CAD7B2.1663F300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

oBIX is an inappropriate technology for constrained = devices.

 

Don

 

 

From:= core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Brian Frank
Sent: Friday, April 09, 2010 5:48 AM
To: Lisa Dusseault
Cc: core@ietf.org
Subject: Re: [core] HTTP and CoAP - mapping and = compression

 

Regarding async notification, lets keep in mind = that existing HTTP application level protocols such as oBIX and OPC-UA = already have a subscription and notification model (both using polls, potentially long-polls).

 

On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault = <lisa.dusseault@gmail.com>= wrote:

<RCC>

The way I see it is that NOTIFY doesn't fit in = terms of abstraction:

(1) CoAP message
      ^
      = |
(2) = Request/response
      ^
      = |
(3) CRUD methods
  
NOTIFY is defined at level (3) but really belongs at level (2), as it is = just a message distinct from request/response from A to B without any further = implied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit = clear doesn't require it so becomes very similar to a notify.

I don't see how an unsolicited notification to a URL is any different to = an UPDATE. If it's unsolicited, the URL bears no obvious relationship to = any initiating client, therefore it can be treated as a server. A solicited = NOTIFY would be better served with an asynchronous READ request/response; the = response is then clearly tagged to what solicited it.

Anyway, just some food for thought. I'm not going to get too hung up = about this :-)
</RCC>

 


That's an excellent point.  The CRUD operation on the resource = might be PUSH (or Reverse PUT, containing the resource representation in a = broadcast or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer semantic.

Lisa


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

 

------=_NextPart_000_00D1_01CAD7B2.1663F300-- From brian.tridium@gmail.com Fri Apr 9 16:23: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 6B3313A6A6C for ; Fri, 9 Apr 2010 16:23:04 -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=0.250, 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 nSjgwPRXs4g2 for ; Fri, 9 Apr 2010 16:22:59 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 51A3E3A6A50 for ; Fri, 9 Apr 2010 16:22:58 -0700 (PDT) Received: by bwz9 with SMTP id 9so3008930bwz.29 for ; Fri, 09 Apr 2010 16:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=liqMKsR4RyjO5kC9feMGPDW0oKYgRMBPdVhomzOHpdQ=; b=lDDZSphk5HW40mbfbcxQ5+iVWguP6q0r1kAX0hGgTAB9KC/rksaCClCIApsUjxx34e 52ep7jCUzs42JWPuDpG+CLmqfYm+Pkibf+NLUQP6PkqJTTsUqf+tgjSofU15fW1Ft5Kg knOUwakd1cBCpE04FSl5ijCBfQVKzWTZ3GU/I= 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 :cc:content-type; b=DBQPno74eqXbCc6//4D5TU/p/KraH8pgY+Uc2jvdfo+CCXLxzPCEa0bYNXxvslKRxJ xuTaeUMRRX7YJ5/po7qa4RBaHpPaR+fVDsJvB5V5O1OhyCmOH7sbCXB/yNUIXFexMQwG xrplc8qHuuhoOapgyWo6HDmRG284MYvsWbEJg= MIME-Version: 1.0 Received: by 10.204.71.212 with HTTP; Fri, 9 Apr 2010 16:22:50 -0700 (PDT) In-Reply-To: <-2316151782061681919@unknownmsgid> References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> <4BBDFA7E.7040804@gridmerge.com> <-2316151782061681919@unknownmsgid> Date: Fri, 9 Apr 2010 19:22:50 -0400 Received: by 10.204.140.67 with SMTP id h3mr778663bku.137.1270855370400; Fri, 09 Apr 2010 16:22:50 -0700 (PDT) Message-ID: From: Brian Frank To: d.sturek@att.net Content-Type: multipart/alternative; boundary=0015174c1434e9e8470483d61293 Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 09 Apr 2010 23:23:05 -0000 --0015174c1434e9e8470483d61293 Content-Type: text/plain; charset=ISO-8859-1 Actually oBIX 1.1 defines a binary encoding, that makes oBIX quite well suited to 6LoWPAN devices. I would certainly hope that the resulting COAP protocol will allow transparent mapping from XML/HTTP obix to binary/COAP obix at the gateway. On Fri, Apr 9, 2010 at 9:58 AM, Don Sturek wrote: > oBIX is an inappropriate technology for constrained devices. > > > > Don > > > > > > *From:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf Of > *Brian Frank > *Sent:* Friday, April 09, 2010 5:48 AM > *To:* Lisa Dusseault > > *Cc:* core@ietf.org > *Subject:* Re: [core] HTTP and CoAP - mapping and compression > > > > Regarding async notification, lets keep in mind that existing HTTP > application level protocols such as oBIX and OPC-UA already have a > subscription and notification model (both using polls, potentially > long-polls). > > > > On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault > wrote: > > > > The way I see it is that NOTIFY doesn't fit in terms of abstraction: > > (1) CoAP message > ^ > | > (2) Request/response > ^ > | > (3) CRUD methods > > NOTIFY is defined at level (3) but really belongs at level (2), as it is > just a message distinct from request/response from A to B without any > further implied meaning other than what's in the payload. Even then, the use > of request/response suggests synchronisation, but a request with the A bit > clear doesn't require it so becomes very similar to a notify. > > I don't see how an unsolicited notification to a URL is any different to an > UPDATE. If it's unsolicited, the URL bears no obvious relationship to any > initiating client, therefore it can be treated as a server. A solicited > NOTIFY would be better served with an asynchronous READ request/response; > the response is then clearly tagged to what solicited it. > > Anyway, just some food for thought. I'm not going to get too hung up about > this :-) > > > > > > That's an excellent point. The CRUD operation on the resource might be > PUSH (or Reverse PUT, containing the resource representation in a broadcast > or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer > semantic. > > Lisa > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > --0015174c1434e9e8470483d61293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually oBIX 1.1 defines a binary encoding, that makes oBIX quite well sui= ted to 6LoWPAN devices. =A0I would certainly hope that the resulting COAP p= rotocol will allow transparent mapping from XML/HTTP obix to binary/COAP ob= ix at the gateway.


On Fri, Apr 9, 2010 at 9:58 AM, Don= Sturek <d.sturek@= att.net> wrote:

oBIX = is an inappropriate technology for constrained devices.

=A0

Don

=A0

=A0

From:= core-bounces@iet= f.org [mailto:core-bounces@ietf.org] On Behalf Of Brian Frank
Sent: Friday, April 09, 2010 5:48 AM
To: Lisa Dusseault


Cc: core@ietf.org=
Subject: Re: [core] HTTP and CoAP - mapping and compression

=

=A0

Regarding async notification, lets keep in mind that existing HTTP application level protocols such as oBIX and OPC-UA already h= ave a subscription and notification model (both using polls, potentially long-polls).

=A0

On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault <= lisa.dusseaul= t@gmail.com> wrote:

<RCC>

The way I see it is that NOTIFY doesn't fit in t= erms of abstraction:

(1) CoAP message
=A0=A0=A0=A0=A0 ^
=A0=A0=A0=A0=A0 |
(2) Request/response
=A0=A0 =A0=A0 ^
=A0 =A0 =A0 |
(3) CRUD methods
=A0=A0
NOTIFY is defined at level (3) but really belongs at level (2), as it is ju= st a message distinct from request/response from A to B without any further impl= ied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit cle= ar doesn't require it so becomes very similar to a notify.

I don't see how an unsolicited notification to a URL is any different t= o an UPDATE. If it's unsolicited, the URL bears no obvious relationship to a= ny initiating client, therefore it can be treated as a server. A solicited NOT= IFY would be better served with an asynchronous READ request/response; the resp= onse is then clearly tagged to what solicited it.

Anyway, just some food for thought. I'm not going to get too hung up ab= out this :-)
</RCC>

=A0


That's an excellent point.=A0 The CRUD operation on the resource might = be PUSH (or Reverse PUT, containing the resource representation in a broadcast= or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer semantic.

Lisa


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

=A0


--0015174c1434e9e8470483d61293-- From d.sturek@att.net Fri Apr 9 16:55: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 72B5D3A6A77 for ; Fri, 9 Apr 2010 16:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, 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 0ddKjvyNG4ke for ; Fri, 9 Apr 2010 16:55:10 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 5D6F13A6A50 for ; Fri, 9 Apr 2010 16:55:10 -0700 (PDT) Received: (qmail 92672 invoked from network); 9 Apr 2010 23:55:04 -0000 Received: from adsl-69-232-85-72.dsl.sndg02.pacbell.net (d.sturek@69.232.85.72 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 09 Apr 2010 16:55:04 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: VGIVLCIVM1lKiH2aFEwe3BWww4M7FyPqVUa8J3VM.44LOBb12ifXThVobi4XB0Ve_8Za3fp7ZGwy61g0_1MeJAH6kAA6NTvKfIFjCGFoOM47dSI8kDvFvtlaNKGMOnvuXjaceEz_wcXtKZngtt0lf4Mi.UIBpsDzpGqFevCU0UeVZYlWz.32HUEYxjXEiAmmgEG1BotIaJWn.AAUJ2NtDXUGLtOAElOLO68JQ_AcJuIiVlXu1lYzetFGFgz6h.JR2_i.kXmr95m1cWIznWjDqjobB54.0Qeb3QggFvwohWL.ceihAA-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Brian Frank'" References: <5E24E794-FA68-4186-8081-93652689457D@archrock.com> <9BA48676-6DED-46CE-9909-7559F64816E2@sensinode.com> <4BBCAF61.3020904@gridmerge.com> <4BBDFA7E.7040804@gridmerge.com> <-2316151782061681919@unknownmsgid> In-Reply-To: Date: Fri, 9 Apr 2010 16:55:03 -0700 Message-ID: <004701cad840$12d22930$38767b90$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01CAD805.66735130" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrYO5NVP1nIEzGzRTyH7i08wwFn0QABB3aA Content-Language: en-us Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression 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, 09 Apr 2010 23:55:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0048_01CAD805.66735130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ah, my experience was with oBIX 1.0. I will have a look. In general, I think the RPC, SOAP mechanisms are a challenge for small devices. I am pretty hopeful that a REST architecture is the right solution for CoRE. I think at some point we need to recognize we are working on an attribute protocol (REST) focused on data exchange versus a remote procedure call type mechanism. That said, offering a well known mapping between the two works for me as well (as long as the REST solution is not encumbered). Don From: Brian Frank [mailto:brian.tridium@gmail.com] Sent: Friday, April 09, 2010 4:23 PM To: d.sturek@att.net Cc: Lisa Dusseault; core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression Actually oBIX 1.1 defines a binary encoding, that makes oBIX quite well suited to 6LoWPAN devices. I would certainly hope that the resulting COAP protocol will allow transparent mapping from XML/HTTP obix to binary/COAP obix at the gateway. On Fri, Apr 9, 2010 at 9:58 AM, Don Sturek wrote: oBIX is an inappropriate technology for constrained devices. Don From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Brian Frank Sent: Friday, April 09, 2010 5:48 AM To: Lisa Dusseault Cc: core@ietf.org Subject: Re: [core] HTTP and CoAP - mapping and compression Regarding async notification, lets keep in mind that existing HTTP application level protocols such as oBIX and OPC-UA already have a subscription and notification model (both using polls, potentially long-polls). On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault wrote: The way I see it is that NOTIFY doesn't fit in terms of abstraction: (1) CoAP message ^ | (2) Request/response ^ | (3) CRUD methods NOTIFY is defined at level (3) but really belongs at level (2), as it is just a message distinct from request/response from A to B without any further implied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit clear doesn't require it so becomes very similar to a notify. I don't see how an unsolicited notification to a URL is any different to an UPDATE. If it's unsolicited, the URL bears no obvious relationship to any initiating client, therefore it can be treated as a server. A solicited NOTIFY would be better served with an asynchronous READ request/response; the response is then clearly tagged to what solicited it. Anyway, just some food for thought. I'm not going to get too hung up about this :-) That's an excellent point. The CRUD operation on the resource might be PUSH (or Reverse PUT, containing the resource representation in a broadcast or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer semantic. Lisa _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0048_01CAD805.66735130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ah, my experience was with oBIX 1.0.  I will have a = look.

 

In general, I think the RPC, SOAP mechanisms are a = challenge for small devices.  I am pretty hopeful that a REST architecture is the = right solution for CoRE.  I think at some point we need to recognize we = are working on an attribute protocol (REST) focused on data exchange versus a remote procedure call type mechanism.  That said, offering a well known = mapping between the two works for me as well (as long as the REST solution is not = encumbered).


Don

 

 

From:= Brian = Frank [mailto:brian.tridium@gmail.com]
Sent: Friday, April 09, 2010 4:23 PM
To: d.sturek@att.net
Cc: Lisa Dusseault; core@ietf.org
Subject: Re: [core] HTTP and CoAP - mapping and = compression

 

Actually oBIX 1.1 defines a binary encoding, that = makes oBIX quite well suited to 6LoWPAN devices.  I would certainly hope that = the resulting COAP protocol will allow transparent mapping from XML/HTTP = obix to binary/COAP obix at the gateway.

 

On Fri, Apr 9, 2010 at 9:58 AM, Don Sturek <d.sturek@att.net> = wrote:

oBIX is an inappropriate = technology for constrained devices.

 

Don

 

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Brian Frank
Sent: Friday, April 09, 2010 5:48 AM
To: Lisa Dusseault


Cc: core@ietf.org
Subject: Re: [core] HTTP and CoAP - mapping and = compression

 <= /o:p>

Regarding async notification, lets keep in mind that existing HTTP application = level protocols such as oBIX and OPC-UA already have a subscription and = notification model (both using polls, potentially long-polls).

 <= /p>

On Thu, Apr 8, 2010 at 10:31 PM, Lisa Dusseault <lisa.dusseault@gmail.com> wrote:

<RCC><= o:p>

=

The way I see it is that NOTIFY doesn't fit in terms of abstraction:

(1) CoAP message
      ^
      = |
(2) = Request/response
      ^
      = |
(3) CRUD methods
  
NOTIFY is defined at level (3) but really belongs at level (2), as it is = just a message distinct from request/response from A to B without any further = implied meaning other than what's in the payload. Even then, the use of request/response suggests synchronisation, but a request with the A bit = clear doesn't require it so becomes very similar to a notify.

I don't see how an unsolicited notification to a URL is any different to = an UPDATE. If it's unsolicited, the URL bears no obvious relationship to = any initiating client, therefore it can be treated as a server. A solicited = NOTIFY would be better served with an asynchronous READ request/response; the = response is then clearly tagged to what solicited it.

Anyway, just some food for thought. I'm not going to get too hung up = about this :-)
</RCC>

 <= /o:p>


That's an excellent point.  The CRUD operation on the resource = might be PUSH (or Reverse PUT, containing the resource representation in a = broadcast or unicast) or CHANGED (containing no body) but just NOTIFY is a transfer = semantic.

Lisa


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

 <= /o:p>

 

------=_NextPart_000_0048_01CAD805.66735130-- From oobles@gmail.com Mon Apr 12 07:01:09 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 830F93A68A9 for ; Mon, 12 Apr 2010 07:01:09 -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=[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 U0rI38xZ70k6 for ; Mon, 12 Apr 2010 07:01:08 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 4FB9B3A67E3 for ; Mon, 12 Apr 2010 07:01:08 -0700 (PDT) Received: by pvf33 with SMTP id 33so2405429pvf.31 for ; Mon, 12 Apr 2010 07:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=U7aGrmMrzpVcJbGG/U9Qnsd18SQbYvhQ50q82zgrNMQ=; b=b3VK9mU2hirXuOMktGdoZBjiBTi204OdzV4OaFmcATzdvARGSKiDqy2s8Pk28yi9Md zQravdf0hqXnhz/KR4hVi2zTWZiVdIhKUfTdBUI/lNGnMnE24G+lolZ5H4rymj3P3uN2 T/u2SE8+lupCRRqqr5avY70cJLXxOEZo4f8oo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KL2O7n5UPSyVsQf7Mj76qRMKN+9WJfHYRrgra88zw1XbSagB8XZunvhyr9FzHZd2r2 y8W42RaM7+XFxxBVXPHkjmu0bVtltPQxqUbC+LppCfMPTlq282otjinmgXDKeU0P/SUA oX0xwWQzH5I9JaZraGcP0MbdIWQN+/JDRcBy0= MIME-Version: 1.0 Received: by 10.231.10.136 with HTTP; Mon, 12 Apr 2010 07:00:58 -0700 (PDT) Date: Tue, 13 Apr 2010 00:00:58 +1000 Received: by 10.114.31.19 with SMTP id e19mr3259194wae.10.1271080858971; Mon, 12 Apr 2010 07:00:58 -0700 (PDT) Message-ID: From: David Ryan To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] COAP/CORE application definitions? 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, 12 Apr 2010 14:01:09 -0000 Following my recent implementation of the COAP protocol I started to think about the application layer specifications. Has anyone developed any RESTful application examples of how common functions will be implemented on COAP? I also realize that a DTLS implementation will be required and I'm wondering how stateless and RESTful the server can be when security is introduced. This question also relates back to the discussion regarding compatibility with HTTP and HTTP based specifications. If there is no compatibility it will mean that there will also be no compatibility with WADL or WSDL 2.0 based specifications. Does this mean we fall back on to textual specifications for the application layer? Seems like 2 steps forward and 3 back. If anyone has done any work on a RESTful application layer for a home automation or metering it would be useful if you could share it. I find without a real application layer to work with many of the protocol choices are academic. Regards, David. From angelo.castellani@gmail.com Tue Apr 13 06: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 4E4D73A692D for ; Tue, 13 Apr 2010 06:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 x8oMH1hKgvZA for ; Tue, 13 Apr 2010 06:14:16 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id 8AD9E3A6B22 for ; Tue, 13 Apr 2010 06:13:03 -0700 (PDT) Received: by yxe9 with SMTP id 9so3502223yxe.29 for ; Tue, 13 Apr 2010 06:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Y1XFHPO9ri2j+IaXeaoF1qfTgUzeGLbBhf9f3yxHCPM=; b=Cp8j3Q4mrnpYoYxpA5lB0zVFGg/EUaU/Usfh5onhZ3FeGCwDNCDPsAqF37Aosuqufm ufwz21bqT/PqlN62KhVyPLFGK0IylM4tIZMZYhHSLOrHwdeDFEH0x77LLsKcrxnOw6j3 nN/1hh21VF58i8LkqRFIiQ6YkozKE4cbUMRR4= 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=sFVBtRG1aULK8kWq3IYrSOB3lrHLUUBjjvTvqDwkI2EFhwvfrKVn/Wlt22rhq4qhaJ iqVM2xAzdvGQwrcWR3QwHOVXnBY1803tHqa0lQdddLUT5LG2ayFCmDEa0X87yuxhF0h4 LkaMRlolzoTF+X63xlhM35z9GaFgHkA/z/sTc= MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.90.106.17 with HTTP; Tue, 13 Apr 2010 06:12:34 -0700 (PDT) In-Reply-To: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> From: "Angelo P. Castellani" Date: Tue, 13 Apr 2010 15:12:34 +0200 X-Google-Sender-Auth: a1a9bb24fd57552c Received: by 10.90.141.20 with SMTP id o20mr2571669agd.97.1271164374872; Tue, 13 Apr 2010 06:12:54 -0700 (PDT) Message-ID: To: "Adriano Pezzuto (apezzuto)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages 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, 13 Apr 2010 13:14:17 -0000 (1) I suppose Transaction ID will be used for matching a session on the server using the (clientIP, transactionID) pair. (2) The same is valid on the client side, the session will be matched using (serverIP, transactionID) pair. However, as already pointed in a previous message titled "Some comments on draft-shelby-core-coap-00" on this list, the use of transaction ID seems really similar to the current use of client source port in the Internet... Bests, Angelo On Tue, Apr 6, 2010 at 14:51, Adriano Pezzuto (apezzuto) wrote: > Hello Zach, > some comments about 2.8.1. UDP section of > http://www.ietf.org/id/draft-shelby-core-coap-00.txt. > > "The Transaction ID in CoAP message headers is used to match > =A0 =A0 =A0responses to open requests and is generated by the client (com= mon > =A0 =A0 =A0counter across all requests)." > > I suppose, a receiver node will discard the message if a duplicated > Transaction ID is received. > If this is the case, I see two situations where this may have some sort > of issues: > > 1. A receiver node receives two (or more) different requests from two > different nodes and both requests have the same Transaction ID. The > receiver node will discard the last request. > > 2. An application manager running CoAP sends requests to all nodes of > the network (e.g. to node1, .... to node-i, .... to node-N). Not sure > but the application manager can send a new request to the node-i before > to receive the response to the last request and both requests have the > same transaction ID. The receiver node-i will discard the last request. > > For case (1) a possible solution may be to use multiple separate counter > on the receiver node - one for each transmitter, instead of a common > counter. For case (2), a possible solution is to use a separate counter > on the application manager - one for each node, instead of a common > counter. May be a stop-and-wait (as stated in the same section of the > draft) would be sufficient to avoid the case (2) but not sure what you > mean exactly with stop-and-wait. > > Thank you, > Adriano > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From oobles@gmail.com Tue Apr 13 18:37: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 954D33A6B6E for ; Tue, 13 Apr 2010 18:37:03 -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 jEOgW7x6ccQ7 for ; Tue, 13 Apr 2010 18:37:02 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 8174B3A6AF2 for ; Tue, 13 Apr 2010 18:36:59 -0700 (PDT) Received: by iwn27 with SMTP id 27so6069437iwn.5 for ; Tue, 13 Apr 2010 18:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UUTHzTO2Xovk0LfWPhT5UIdAO2j/FbXaybzJFnYh81A=; b=tle9FFPGnGkp+3OSOsPyknD0OayHvRszbEqU+r2G22Rox7MIhfjgcUrJXyrrhGPFTH c/7fjI1dzlUyfRrsCjRelQf8sCQKN6N2lCRiMW+4Qw7DAqzg0HAoi94YFMOAEpJfr5Xs hBVjoGrW4HAbuJyayMFyNrD7E4uApibUPdunI= 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 :cc:content-type:content-transfer-encoding; b=GHkLpnXjQ2yRLo9dBTmd8T2TCR32Pp2MW1fN6vW9MZiISDOBR/SvfZSb3uKSR7MB+k 3z0ZLXhjqc70Nf0fsxdx2hDH1R6ihvE/xct+K6aBPZP4n+b7r1Tdc9CMq8Wo0jzCGGH8 1QQC8898AF4ZfQaGhron0aO3aemIjJDlFHC9c= MIME-Version: 1.0 Received: by 10.231.10.136 with HTTP; Tue, 13 Apr 2010 18:36:50 -0700 (PDT) In-Reply-To: References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> Date: Wed, 14 Apr 2010 11:36:50 +1000 Received: by 10.231.174.137 with SMTP id t9mr1413984ibz.98.1271209010993; Tue, 13 Apr 2010 18:36:50 -0700 (PDT) Message-ID: From: David Ryan To: "Angelo P. Castellani" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages 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, 14 Apr 2010 01:37:03 -0000 Hi, See comments inline. > > 1. A receiver node receives two (or more) different requests from two > > different nodes and both requests have the same Transaction ID. The > > receiver node will discard the last request. On Tue, Apr 13, 2010 at 11:12 PM, Angelo P. Castellani wrote: > (1) I suppose Transaction ID will be used for matching a session on > the server using the (clientIP, transactionID) pair. I'd say that a server node should always process a request and provide a response and should not discard duplicate requests. It is important that the server does not need to retain state of client requests other than current pending/processing requests. Consider the scenario where a client sends a request and the server sends a response, however, the response is lost. The client may attempt to retry the request using the same transactionID. The server will process the request again and should send the same response. This is where design of the REST based server is important. All transactions should be idempotent (allowing safe retries). > > 2. An application manager running CoAP sends requests to all nodes of > > the network (e.g. to node1, .... to node-i, .... to node-N). Not sure > > but the application manager can send a new request to the node-i before > > to receive the response to the last request and both requests have the > > same transaction ID. The receiver node-i will discard the last request. > > (2) The same is valid on the client side, the session will be matched > using (serverIP, transactionID) pair. I think the transactionID counter across all nodes it is sending requests should be the same. ie node1 (transactionid 1), node2 (transactionId 2).. etc. If there are multiple clients running on a single node then the source port must be different as the transactionId may not be unique. Regards, David. > > However, as already pointed in a previous message titled "Some > comments on draft-shelby-core-coap-00" on this list, the use of > transaction ID seems really similar to the current use of client > source port in the Internet... > > Bests, > Angelo > > On Tue, Apr 6, 2010 at 14:51, Adriano Pezzuto (apezzuto) > wrote: >> Hello Zach, >> some comments about 2.8.1. UDP section of >> http://www.ietf.org/id/draft-shelby-core-coap-00.txt. >> >> "The Transaction ID in CoAP message headers is used to match >> =A0 =A0 =A0responses to open requests and is generated by the client (co= mmon >> =A0 =A0 =A0counter across all requests)." >> >> I suppose, a receiver node will discard the message if a duplicated >> Transaction ID is received. >> If this is the case, I see two situations where this may have some sort >> of issues: >> >> 1. A receiver node receives two (or more) different requests from two >> different nodes and both requests have the same Transaction ID. The >> receiver node will discard the last request. >> >> 2. An application manager running CoAP sends requests to all nodes of >> the network (e.g. to node1, .... to node-i, .... to node-N). Not sure >> but the application manager can send a new request to the node-i before >> to receive the response to the last request and both requests have the >> same transaction ID. The receiver node-i will discard the last request. >> >> For case (1) a possible solution may be to use multiple separate counter >> on the receiver node - one for each transmitter, instead of a common >> counter. For case (2), a possible solution is to use a separate counter >> on the application manager - one for each node, instead of a common >> counter. May be a stop-and-wait (as stated in the same section of the >> draft) would be sufficient to avoid the case (2) but not sure what you >> mean exactly with stop-and-wait. >> >> Thank you, >> Adriano >> _______________________________________________ >> 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 bobd@echelon.com Tue Apr 13 21:52: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 28E553A6816 for ; Tue, 13 Apr 2010 21:52:31 -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 B3lyxaRjUUux for ; Tue, 13 Apr 2010 21:52:30 -0700 (PDT) Received: from monk.echelon.com (monk.echelon.com [12.191.56.29]) by core3.amsl.com (Postfix) with ESMTP id 1369E3A67CC for ; Tue, 13 Apr 2010 21:52:30 -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: Tue, 13 Apr 2010 21:52:03 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Reability of CoAP messages Thread-Index: Acrbcvsvi2TPeGdUROyQOcVvgEkEXAAGS6qA References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> From: "Bob Dolin" To: "David Ryan" , "Angelo P. Castellani" Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages 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, 14 Apr 2010 04:52:31 -0000 I don't think defining away problems really makes them go away....=20 " All transactions should be idempotent (allowing safe retries)." Let us consider the case of a household with a prepay meter. In this = case, the household must pay for electricity in advance. Now let us = consider that the household was notified via their in-home display that = they are running low on their prepaid balance, so they decide to add to = it. So, they use the internet, or whatever to transfer cash to the = utility. Meanwhile, they are consuming energy at rates that vary with = time (time of use pricing is coming or already here). Now, the utility = adds some money to the meter, but it cannot know how much is left = without querying first, and by the time it gets the response it is out = of date due to the continuous consumption of electricity. How is the = addition done in an idempotent way? Or is this class of applications not = suitable for CoAPP? There are many examples of non-idempotent = transactions in the world besides this one. Do we want to restrict CoAPP = in all these unforeseen ways? " I think the transactionID counter across all nodes it is sending requests should be the same. ie node1 (transactionid 1), node2 (transactionId 2).. etc. If there are multiple clients running on a single node then the source port must be different as the transactionId may not be unique." So, are you suggesting that the server maintain a transaction ID = counter/address/port for each destination and ensure that it is the same = value for a single transaction across multiple clients? What will the = storage requirements be for such an implementation? -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = David Ryan Sent: Tuesday, April 13, 2010 6:37 PM To: Angelo P. Castellani Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages Hi, See comments inline. > > 1. A receiver node receives two (or more) different requests from = two > > different nodes and both requests have the same Transaction ID. The > > receiver node will discard the last request. On Tue, Apr 13, 2010 at 11:12 PM, Angelo P. Castellani wrote: > (1) I suppose Transaction ID will be used for matching a session on > the server using the (clientIP, transactionID) pair. I'd say that a server node should always process a request and provide a response and should not discard duplicate requests. It is important that the server does not need to retain state of client requests other than current pending/processing requests. Consider the scenario where a client sends a request and the server sends a response, however, the response is lost. The client may attempt to retry the request using the same transactionID. The server will process the request again and should send the same response. This is where design of the REST based server is important. All transactions should be idempotent (allowing safe retries). > > 2. An application manager running CoAP sends requests to all nodes = of > > the network (e.g. to node1, .... to node-i, .... to node-N). Not = sure > > but the application manager can send a new request to the node-i = before > > to receive the response to the last request and both requests have = the > > same transaction ID. The receiver node-i will discard the last = request. > > (2) The same is valid on the client side, the session will be matched > using (serverIP, transactionID) pair. I think the transactionID counter across all nodes it is sending requests should be the same. ie node1 (transactionid 1), node2 (transactionId 2).. etc. If there are multiple clients running on a single node then the source port must be different as the transactionId may not be unique. Regards, David. > > However, as already pointed in a previous message titled "Some > comments on draft-shelby-core-coap-00" on this list, the use of > transaction ID seems really similar to the current use of client > source port in the Internet... > > Bests, > Angelo > > On Tue, Apr 6, 2010 at 14:51, Adriano Pezzuto (apezzuto) > wrote: >> Hello Zach, >> some comments about 2.8.1. UDP section of >> http://www.ietf.org/id/draft-shelby-core-coap-00.txt. >> >> "The Transaction ID in CoAP message headers is used to match >> =A0 =A0 =A0responses to open requests and is generated by the client = (common >> =A0 =A0 =A0counter across all requests)." >> >> I suppose, a receiver node will discard the message if a duplicated >> Transaction ID is received. >> If this is the case, I see two situations where this may have some = sort >> of issues: >> >> 1. A receiver node receives two (or more) different requests from two >> different nodes and both requests have the same Transaction ID. The >> receiver node will discard the last request. >> >> 2. An application manager running CoAP sends requests to all nodes of >> the network (e.g. to node1, .... to node-i, .... to node-N). Not sure >> but the application manager can send a new request to the node-i = before >> to receive the response to the last request and both requests have = the >> same transaction ID. The receiver node-i will discard the last = request. >> >> For case (1) a possible solution may be to use multiple separate = counter >> on the receiver node - one for each transmitter, instead of a common >> counter. For case (2), a possible solution is to use a separate = counter >> on the application manager - one for each node, instead of a common >> counter. May be a stop-and-wait (as stated in the same section of the >> draft) would be sufficient to avoid the case (2) but not sure what = you >> mean exactly with stop-and-wait. >> >> Thank you, >> Adriano >> _______________________________________________ >> 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 oobles@gmail.com Tue Apr 13 22:48: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 9BE003A67E5 for ; Tue, 13 Apr 2010 22:48:07 -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 rBlmfBYp6QvP for ; Tue, 13 Apr 2010 22:48:06 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id A11A03A6912 for ; Tue, 13 Apr 2010 22:47:47 -0700 (PDT) Received: by iwn27 with SMTP id 27so6188592iwn.5 for ; Tue, 13 Apr 2010 22:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mwg7Cli+xEwBWpHAB2FIL/pBaelq/f3fhFRsAWIHKKw=; b=UDWQTFBAZB3Pt52d1bFjgzN890VkBSdAqT9CLFTxFIeIo2On8A+4Wt2QLicGSeK9K5 jjD4jx/zmNiblhamE3VlCCdc1JEhtB3mITWdfGcfxiD6tmIIWb7R3U+g6i4OIXpfXH49 EznHOkVdAlb6IE8hyhaCRr6JOmfVrKEgtlwtw= 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 :cc:content-type:content-transfer-encoding; b=BD5xan5y7RHvMaC0ogGPRI+EZaHKgCAYlK7bvd6orCOGbxJ1K+sCN0jcySKOwAsUTX yvH2jl/voGxkmdyDoK3oZhtQX7EX2QXSUPEZfUkqr2wmxfelfRelQKGPAG/Xy0Eknx/m ZrXb0QU7s4PGhh01g3jvxx6p24mx3iew0/IdQ= MIME-Version: 1.0 Received: by 10.231.10.136 with HTTP; Tue, 13 Apr 2010 22:47:38 -0700 (PDT) In-Reply-To: References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> Date: Wed, 14 Apr 2010 15:47:38 +1000 Received: by 10.231.153.205 with SMTP id l13mr3104099ibw.64.1271224058742; Tue, 13 Apr 2010 22:47:38 -0700 (PDT) Message-ID: From: David Ryan To: Bob Dolin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages 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, 14 Apr 2010 05:48:07 -0000 Hi Bob, You raise some good points that need to be discussed. On Wed, Apr 14, 2010 at 2:52 PM, Bob Dolin wrote: > I don't think defining away problems really makes them go away.... > > " All transactions should be idempotent (allowing safe retries)." > > Let us consider the case of a household with a prepay meter. In this case= , the household must pay for electricity in advance. Now let us consider th= at the household was notified via their in-home display that they are runni= ng low on their prepaid balance, so they decide to add to it. So, they use = the internet, or whatever to transfer cash to the utility. Meanwhile, they = are consuming energy at rates that vary with time (time of use pricing is c= oming or already here). Now, the utility adds some money to the meter, but = it cannot know how much is left without querying first, and by the time it = gets the response it is out of date due to the continuous consumption of el= ectricity. How is the addition done in an idempotent way? Or is this class = of applications not suitable for CoAPP? There are many examples of non-idem= potent transactions in the world besides this one. Do we want to restrict C= oAPP in all these unforeseen ways? Idempotent transactions will be a requirement for any protocol that is based on a lossy network, especially one that is built on UDP. There can be no guarantee that a request or probably more importantly that a response will be received. I also don't think this issue will effect just CoAPP; it will be true of any protocol that is built on messaging. The REST based answer to this problem is that transactions need to be designed so that what may look non-idempotent can be made to be idempotent at the transactional level. For example, take the issue you define of adding funds to a prepaid meter. One method would be to treat funds as a timestamped list. Each time funds are added a document is "put" on the server which has the additional funds. From a REST perspective you might have the following locations: URI://prepaid_host/funds/2010_04_1_10:35:02 URI://prepaid_host/funds/2010_04_14_21:09:12 The contents of the document 2010_04_14_21:09:12 has the amount of money added to the meter. This REST structure doubles as both a transaction list and adding funds to the prepaid meter. When a client adds funds it is performing a put or post to the location. In the event of a failure of a network failure the client can safely retry the put or post. If the server had previously received the document then it will either replace it and calculate the difference between documents or return an error code indicating that the document is already there. I'm sure there are numerous other ways to modify your example so that it becomes idempotent. Unless the Coap protocol is going to be truly transactional with two phase commit then I think it must be idempotent for all transactions. If you have other transactions which might cause problems in regard to being non-idempotent let me know. Working through these issues is one of the reasons I asked if anyone had built any models for a REST based meter or home automation elements. Without hitting some real world problems we won't know if the Coap protocol will be suitable. Obviously for your example the other requirement is that Coap support a form of authentication for requests. The current draft suggests that DTLS might be a valid option. I'm yet to see if this is suitable or fits the Coap model well. > > " I think the transactionID counter across all nodes it is sending > requests should be the same. ie node1 (transactionid 1), node2 > (transactionId 2).. =A0etc. > If there are multiple clients running on a single node then the source > port must be different as the transactionId may not be unique." > > So, are you suggesting that the server maintain a transaction ID counter/= address/port for each destination and ensure that it is the same value for = a single transaction across multiple clients? What will the storage require= ments be for such an implementation? No, the server should only maintain the source details for requests currently being processed. It should not maintain any state between requests. A client should maintain a table of all requests that it is expecting a response. The client request table is simply indexed on the transactionId. In this way the client does not maintain a different transaction id counter for each server it is sending requests. > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of D= avid Ryan > Sent: Tuesday, April 13, 2010 6:37 PM > To: Angelo P. Castellani > Cc: core@ietf.org > Subject: Re: [core] Reability of CoAP messages > > Hi, > > See comments inline. > >> > 1. A receiver node receives two (or more) different requests from two >> > different nodes and both requests have the same Transaction ID. The >> > receiver node will discard the last request. > On Tue, Apr 13, 2010 at 11:12 PM, Angelo P. Castellani > wrote: >> (1) I suppose Transaction ID will be used for matching a session on >> the server using the (clientIP, transactionID) pair. > > I'd say that a server node should always process a request and provide > a response and should not discard duplicate requests. =A0It is important > that the server does not need to retain state of client requests other > than current pending/processing requests. =A0Consider the scenario where > a client sends a request and the server sends a response, however, the > response is lost. =A0The client may attempt to retry the request using > the same transactionID. =A0The server will process the request again and > should send the same response. =A0This is where design of the REST based > server is important. =A0All transactions should be idempotent (allowing > safe retries). > >> > 2. An application manager running CoAP sends requests to all nodes of >> > the network (e.g. to node1, .... to node-i, .... to node-N). Not sure >> > but the application manager can send a new request to the node-i befor= e >> > to receive the response to the last request and both requests have the >> > same transaction ID. The receiver node-i will discard the last request= . >> >> (2) The same is valid on the client side, the session will be matched >> using (serverIP, transactionID) pair. > > I think the transactionID counter across all nodes it is sending > requests should be the same. ie node1 (transactionid 1), node2 > (transactionId 2).. =A0etc. > If there are multiple clients running on a single node then the source > port must be different as the transactionId may not be unique. > > Regards, > David. > >> >> However, as already pointed in a previous message titled "Some >> comments on draft-shelby-core-coap-00" on this list, the use of >> transaction ID seems really similar to the current use of client >> source port in the Internet... >> >> Bests, >> Angelo >> >> On Tue, Apr 6, 2010 at 14:51, Adriano Pezzuto (apezzuto) >> wrote: >>> Hello Zach, >>> some comments about 2.8.1. UDP section of >>> http://www.ietf.org/id/draft-shelby-core-coap-00.txt. >>> >>> "The Transaction ID in CoAP message headers is used to match >>> =A0 =A0 =A0responses to open requests and is generated by the client (c= ommon >>> =A0 =A0 =A0counter across all requests)." >>> >>> I suppose, a receiver node will discard the message if a duplicated >>> Transaction ID is received. >>> If this is the case, I see two situations where this may have some sort >>> of issues: >>> >>> 1. A receiver node receives two (or more) different requests from two >>> different nodes and both requests have the same Transaction ID. The >>> receiver node will discard the last request. >>> >>> 2. An application manager running CoAP sends requests to all nodes of >>> the network (e.g. to node1, .... to node-i, .... to node-N). Not sure >>> but the application manager can send a new request to the node-i before >>> to receive the response to the last request and both requests have the >>> same transaction ID. The receiver node-i will discard the last request. >>> >>> For case (1) a possible solution may be to use multiple separate counte= r >>> on the receiver node - one for each transmitter, instead of a common >>> counter. For case (2), a possible solution is to use a separate counter >>> on the application manager - one for each node, instead of a common >>> counter. May be a stop-and-wait (as stated in the same section of the >>> draft) would be sufficient to avoid the case (2) but not sure what you >>> mean exactly with stop-and-wait. >>> >>> Thank you, >>> Adriano >>> _______________________________________________ >>> 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 zach@sensinode.com Tue Apr 13 22:50: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 C44063A6BA9 for ; Tue, 13 Apr 2010 22:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-hklJHm69Cw for ; Tue, 13 Apr 2010 22:50:42 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A488E3A69AA for ; Tue, 13 Apr 2010 22:50:30 -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 o3E5oAJh029402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Apr 2010 08:50:11 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 14 Apr 2010 08:50:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2CFD58C8-23A9-42DF-AB7E-BC75A9D20374@sensinode.com> References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> To: "Bob Dolin" X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages 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, 14 Apr 2010 05:50:44 -0000 Guys, On Apr 14, 2010, at 7:52 , Bob Dolin wrote: > I don't think defining away problems really makes them go away....=20 >=20 > " All transactions should be idempotent (allowing safe retries)." >=20 > Let us consider the case of a household with a prepay meter. In this = case, the household must pay for electricity in advance. Now let us = consider that the household was notified via their in-home display that = they are running low on their prepaid balance, so they decide to add to = it. So, they use the internet, or whatever to transfer cash to the = utility. Meanwhile, they are consuming energy at rates that vary with = time (time of use pricing is coming or already here). Now, the utility = adds some money to the meter, but it cannot know how much is left = without querying first, and by the time it gets the response it is out = of date due to the continuous consumption of electricity. How is the = addition done in an idempotent way? Or is this class of applications not = suitable for CoAPP? There are many examples of non-idempotent = transactions in the world besides this one. Do we want to restrict CoAPP = in all these unforeseen ways? David maybe was too general on the idempotent thing, please read the = coap draft's sections on methods (and the HTTP ones). Only really the = READ method is idempotent, obviously other methods are not. >=20 > " I think the transactionID counter across all nodes it is sending > requests should be the same. ie node1 (transactionid 1), node2 > (transactionId 2).. etc. > If there are multiple clients running on a single node then the source > port must be different as the transactionId may not be unique." >=20 > So, are you suggesting that the server maintain a transaction ID = counter/address/port for each destination and ensure that it is the same = value for a single transaction across multiple clients? What will the = storage requirements be for such an implementation? It is the client which maintains the transaction ID. The server does not = keep state about transaction IDs, but just responds to incoming = requests. Overall I think David explained this correctly, at least I am thinking = along the same lines. Zach >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of David Ryan > Sent: Tuesday, April 13, 2010 6:37 PM > To: Angelo P. Castellani > Cc: core@ietf.org > Subject: Re: [core] Reability of CoAP messages >=20 > Hi, >=20 > See comments inline. >=20 >>> 1. A receiver node receives two (or more) different requests from = two >>> different nodes and both requests have the same Transaction ID. The >>> receiver node will discard the last request. > On Tue, Apr 13, 2010 at 11:12 PM, Angelo P. Castellani > wrote: >> (1) I suppose Transaction ID will be used for matching a session on >> the server using the (clientIP, transactionID) pair. >=20 > I'd say that a server node should always process a request and provide > a response and should not discard duplicate requests. It is important > that the server does not need to retain state of client requests other > than current pending/processing requests. Consider the scenario where > a client sends a request and the server sends a response, however, the > response is lost. The client may attempt to retry the request using > the same transactionID. The server will process the request again and > should send the same response. This is where design of the REST based > server is important. All transactions should be idempotent (allowing > safe retries). >=20 >>> 2. An application manager running CoAP sends requests to all nodes = of >>> the network (e.g. to node1, .... to node-i, .... to node-N). Not = sure >>> but the application manager can send a new request to the node-i = before >>> to receive the response to the last request and both requests have = the >>> same transaction ID. The receiver node-i will discard the last = request. >>=20 >> (2) The same is valid on the client side, the session will be matched >> using (serverIP, transactionID) pair. >=20 > I think the transactionID counter across all nodes it is sending > requests should be the same. ie node1 (transactionid 1), node2 > (transactionId 2).. etc. > If there are multiple clients running on a single node then the source > port must be different as the transactionId may not be unique. >=20 > Regards, > David. >=20 >>=20 >> However, as already pointed in a previous message titled "Some >> comments on draft-shelby-core-coap-00" on this list, the use of >> transaction ID seems really similar to the current use of client >> source port in the Internet... >>=20 >> Bests, >> Angelo >>=20 >> On Tue, Apr 6, 2010 at 14:51, Adriano Pezzuto (apezzuto) >> wrote: >>> Hello Zach, >>> some comments about 2.8.1. UDP section of >>> http://www.ietf.org/id/draft-shelby-core-coap-00.txt. >>>=20 >>> "The Transaction ID in CoAP message headers is used to match >>> responses to open requests and is generated by the client = (common >>> counter across all requests)." >>>=20 >>> I suppose, a receiver node will discard the message if a duplicated >>> Transaction ID is received. >>> If this is the case, I see two situations where this may have some = sort >>> of issues: >>>=20 >>> 1. A receiver node receives two (or more) different requests from = two >>> different nodes and both requests have the same Transaction ID. The >>> receiver node will discard the last request. >>>=20 >>> 2. An application manager running CoAP sends requests to all nodes = of >>> the network (e.g. to node1, .... to node-i, .... to node-N). Not = sure >>> but the application manager can send a new request to the node-i = before >>> to receive the response to the last request and both requests have = the >>> same transaction ID. The receiver node-i will discard the last = request. >>>=20 >>> For case (1) a possible solution may be to use multiple separate = counter >>> on the receiver node - one for each transmitter, instead of a common >>> counter. For case (2), a possible solution is to use a separate = counter >>> on the application manager - one for each node, instead of a common >>> counter. May be a stop-and-wait (as stated in the same section of = the >>> draft) would be sufficient to avoid the case (2) but not sure what = you >>> mean exactly with stop-and-wait. >>>=20 >>> Thank you, >>> Adriano >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From zach@sensinode.com Tue Apr 13 23:00: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 3064B3A6ADF for ; Tue, 13 Apr 2010 23:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WI6n+wfxWmp for ; Tue, 13 Apr 2010 23:00:23 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8DE5728C1A2 for ; Tue, 13 Apr 2010 23:00:21 -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 o3E60Bxv030268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Apr 2010 09:00:11 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 14 Apr 2010 09:00:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Ryan X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] COAP/CORE application definitions? 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, 14 Apr 2010 06:00:24 -0000 David, On Apr 12, 2010, at 17:00 , David Ryan wrote: > Following my recent implementation of the COAP protocol I started to > think about the application layer specifications. Has anyone > developed any RESTful application examples of how common functions > will be implemented on COAP? I also realize that a DTLS > implementation will be required and I'm wondering how stateless and > RESTful the server can be when security is introduced. That is an interesting point, I am not sure how DTLS/TLS affect the REST = model really. Anybody have experience on that from the HTTP world? DTLS = is surely not required, it is something that MAY be applied if needed. = IPSec is another alternative e.g. > This question also relates back to the discussion regarding > compatibility with HTTP and HTTP based specifications. If there is no > compatibility it will mean that there will also be no compatibility > with WADL or WSDL 2.0 based specifications. Does this mean we fall > back on to textual specifications for the application layer? Seems > like 2 steps forward and 3 back. CoAP will be 100% REST compatible, and it seems that we are leaning = towards using GET, POST, PUT, DELETE method names. So you should be able = to fully re-use WADL and even WSDL with CoAP. >=20 > If anyone has done any work on a RESTful application layer for a home > automation or metering it would be useful if you could share it. I > find without a real application layer to work with many of the > protocol choices are academic. In the WG meeting the ZigBee SE 2.0 people said they were working on a = draft about their application patterns, which should be what you are = looking for. The SENSEI project has also designed RESTful APIs which = make use of WADL together with a protocol somewhat like CoAP. You can = find public deliverables from that project here: = http://www.ict-sensei.org/index.php?option=3Dcom_content&task=3Dview&id=3D= 14&Itemid=3D31 Cheers, Zach=20 >=20 > Regards, > David. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From angelo.castellani@gmail.com Wed Apr 14 01:40: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 2BCB93A68EA for ; Wed, 14 Apr 2010 01:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 xDhBjdAK2beM for ; Wed, 14 Apr 2010 01:40:17 -0700 (PDT) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by core3.amsl.com (Postfix) with ESMTP id B26123A6836 for ; Wed, 14 Apr 2010 01:40:16 -0700 (PDT) Received: by yxe14 with SMTP id 14so3770232yxe.5 for ; Wed, 14 Apr 2010 01:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7rascGR8fGK+xUGfO8iszHRlGC2U3GHp9FeOwfq6ggA=; b=mcoXY462+SFNEOQI0G4+NkW6h1wxisGMOSDEjcxvlQ7YrKrzXKxIqt3LQrOxZBIx6/ VWu5HoYZnppwZWH5hXxVIba499/0X/Ves2kZO/YSOmlpIXbQ+Efig05HOaiWtpb73/pG +EA44V/hPf8TD9lkfRJNSKgYdNg0cD08EnGMg= 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=WPKrioYAZnYrdpR66A1+N8kY2sAtmHVcazNSV02OLpdGtqDUZa8MysXywnnOV63Lcm 2HleoZ7tQiEMwczGvbHgaWws5SrWVdmN4essRWEdCuCEI1qojeH9A8axEowO7ZoCevwx X4KZiZOzQvl7QWw2FfzoK4msmI/At0HrusS5w= MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.90.106.17 with HTTP; Wed, 14 Apr 2010 01:40:07 -0700 (PDT) In-Reply-To: References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> Date: Wed, 14 Apr 2010 10:40:07 +0200 X-Google-Sender-Auth: 10b0c7b4ccec7abd Received: by 10.90.210.10 with SMTP id i10mr3139359agg.88.1271234407657; Wed, 14 Apr 2010 01:40:07 -0700 (PDT) Message-ID: From: "Angelo P. Castellani" To: David Ryan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Reability of CoAP messages 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, 14 Apr 2010 08:40:18 -0000 My comments were about matching response to request in (2), and about matching equal (retransmitted?) requests in (1), which in my opinion, must not generate another action (for methods non-idempotents) but should however generate a response possibly the same response that the original request has generated (for idempotents methods this is straight-forward..). I'm in no way suggesting that the server should keep state for processed requests. However some state information is still required to overcome TCP absence and still handle retransmission. There are at least two different states where CoAP server needs to keep state for incoming requests: - HANDLING: when the request has been received and the response has not been sent >>> this is surely a duplicate request and should be ignored in my opinion - HANDLED_WAIT: when the request has been received and the response has been sent, similar to the CLOSE_WAIT state of TCP after the final ACK over the connection. Every handled request should be kept in this state until a timeout is fired, and it is required response is not ACKed >>> this should be handled as a duplicate, no action should be taken, howev= er possibly the same response message should be generated by the node. In my opinion this is required to handle response messages loss over the channel, in that case the client will send again the request with the same transaction ID and the server will respond with the same response that is gone loss without action duplication. Just a note, please consider removing transaction ID field, and using the client source UDP port as transaction ID... When using 6lowpan compression, UDP port field size automatically scales when that port goes over a range and we've already 16bit there in the worst case. If somebody isn't confident that this is good in every situation a transaction ID option can be added, that can be paired with the client source UDP port when needed. Bests, Angelo On Wed, Apr 14, 2010 at 03:36, David Ryan wrote: > Hi, > > See comments inline. > >> > 1. A receiver node receives two (or more) different requests from two >> > different nodes and both requests have the same Transaction ID. The >> > receiver node will discard the last request. > On Tue, Apr 13, 2010 at 11:12 PM, Angelo P. Castellani > wrote: >> (1) I suppose Transaction ID will be used for matching a session on >> the server using the (clientIP, transactionID) pair. > > I'd say that a server node should always process a request and provide > a response and should not discard duplicate requests. =A0It is important > that the server does not need to retain state of client requests other > than current pending/processing requests. =A0Consider the scenario where > a client sends a request and the server sends a response, however, the > response is lost. =A0The client may attempt to retry the request using > the same transactionID. =A0The server will process the request again and > should send the same response. =A0This is where design of the REST based > server is important. =A0All transactions should be idempotent (allowing > safe retries). > >> > 2. An application manager running CoAP sends requests to all nodes of >> > the network (e.g. to node1, .... to node-i, .... to node-N). Not sure >> > but the application manager can send a new request to the node-i befor= e >> > to receive the response to the last request and both requests have the >> > same transaction ID. The receiver node-i will discard the last request= . >> >> (2) The same is valid on the client side, the session will be matched >> using (serverIP, transactionID) pair. > > I think the transactionID counter across all nodes it is sending > requests should be the same. ie node1 (transactionid 1), node2 > (transactionId 2).. =A0etc. > If there are multiple clients running on a single node then the source > port must be different as the transactionId may not be unique. > > Regards, > David. > >> >> However, as already pointed in a previous message titled "Some >> comments on draft-shelby-core-coap-00" on this list, the use of >> transaction ID seems really similar to the current use of client >> source port in the Internet... >> >> Bests, >> Angelo >> >> On Tue, Apr 6, 2010 at 14:51, Adriano Pezzuto (apezzuto) >> wrote: >>> Hello Zach, >>> some comments about 2.8.1. UDP section of >>> http://www.ietf.org/id/draft-shelby-core-coap-00.txt. >>> >>> "The Transaction ID in CoAP message headers is used to match >>> =A0 =A0 =A0responses to open requests and is generated by the client (c= ommon >>> =A0 =A0 =A0counter across all requests)." >>> >>> I suppose, a receiver node will discard the message if a duplicated >>> Transaction ID is received. >>> If this is the case, I see two situations where this may have some sort >>> of issues: >>> >>> 1. A receiver node receives two (or more) different requests from two >>> different nodes and both requests have the same Transaction ID. The >>> receiver node will discard the last request. >>> >>> 2. An application manager running CoAP sends requests to all nodes of >>> the network (e.g. to node1, .... to node-i, .... to node-N). Not sure >>> but the application manager can send a new request to the node-i before >>> to receive the response to the last request and both requests have the >>> same transaction ID. The receiver node-i will discard the last request. >>> >>> For case (1) a possible solution may be to use multiple separate counte= r >>> on the receiver node - one for each transmitter, instead of a common >>> counter. For case (2), a possible solution is to use a separate counter >>> on the application manager - one for each node, instead of a common >>> counter. May be a stop-and-wait (as stated in the same section of the >>> draft) would be sufficient to avoid the case (2) but not sure what you >>> mean exactly with stop-and-wait. >>> >>> Thank you, >>> Adriano >>> _______________________________________________ >>> 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 oobles@gmail.com Wed Apr 14 04:48: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 CF37D3A6C61 for ; Wed, 14 Apr 2010 04:48:14 -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 nSo+QvRRqyH7 for ; Wed, 14 Apr 2010 04:48:13 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 112C628C116 for ; Wed, 14 Apr 2010 04:44:00 -0700 (PDT) Received: by iwn27 with SMTP id 27so2896iwn.5 for ; Wed, 14 Apr 2010 04:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fEpp16tqUjz3jiPqYP8cTpsul+/jmn26OguOUjKnA9I=; b=L77k2vMhzbOrhdGGI0GYOVKuxKMEyvN+PCuF1acwMKuwz5/B1rzlRvQh0ETUD1Jv9h NzX6IhLZC/yqlsmLhBmWf9zA9dpFWIpNLIz9ZF60AggiLcT+bnzbHpIlgm1EBfYUoeSU A2Yz7hJrzvWN/6n/nyAo4JRXtj8NHgV+B1BrA= 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 :cc:content-type:content-transfer-encoding; b=J/glIo3OD3CQPs87mRBCuTBo0gffUcM/xgdwlur46qJvMlUspC6eg9EXoF3suS3lGG SiZuzs++WsNEzRD+uRDZtX2dQ+Yzh9wr0+5Aj0b3AqCKeRx1HSk1eyijG9rDSb0H4HiS r2bBBb949aMzKn8o2iGshdsV8RnnV6YV4vCcE= MIME-Version: 1.0 Received: by 10.231.10.136 with HTTP; Wed, 14 Apr 2010 04:43:50 -0700 (PDT) In-Reply-To: <2CFD58C8-23A9-42DF-AB7E-BC75A9D20374@sensinode.com> References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> <2CFD58C8-23A9-42DF-AB7E-BC75A9D20374@sensinode.com> Date: Wed, 14 Apr 2010 21:43:50 +1000 Received: by 10.231.160.135 with SMTP id n7mr3291634ibx.26.1271245430950; Wed, 14 Apr 2010 04:43:50 -0700 (PDT) Message-ID: From: David Ryan To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages 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, 14 Apr 2010 11:48:14 -0000 Hi Zach, On Wed, Apr 14, 2010 at 3:50 PM, Zach Shelby wrote: > Guys, > > On Apr 14, 2010, at 7:52 , Bob Dolin wrote: > >> I don't think defining away problems really makes them go away.... >> >> " All transactions should be idempotent (allowing safe retries)." >> >> Let us consider the case of a household with a prepay meter. In this cas= e, the household must pay for electricity in advance. Now let us consider t= hat the household was notified via their in-home display that they are runn= ing low on their prepaid balance, so they decide to add to it. So, they use= the internet, or whatever to transfer cash to the utility. Meanwhile, they= are consuming energy at rates that vary with time (time of use pricing is = coming or already here). Now, the utility adds some money to the meter, but= it cannot know how much is left without querying first, and by the time it= gets the response it is out of date due to the continuous consumption of e= lectricity. How is the addition done in an idempotent way? Or is this class= of applications not suitable for CoAPP? There are many examples of non-ide= mpotent transactions in the world besides this one. Do we want to restrict = CoAPP in all these unforeseen ways? > > David maybe was too general on the idempotent thing, please read the coap= draft's sections on methods (and the HTTP ones). Only really the READ meth= od is idempotent, obviously other methods are not. I was just reading the definition of idempotent "1. A function f : D -> D is idempotent if f (f x) =3D f x for all x in D. I.e. repeated applications have the same effect as one. This can be extended to functions of more than one argument, e.g. Boolean & has x & x =3D x. Any value in the image of an idempotent function is a fixed point of the function. " Strictly speaking an idempotent request should always result in the same response. So I'm using the term idempotent a little incorrectly. I'm suggesting that applications should be designed so that any request should result in the same outcome/state on the server even if the request is resent. So a CREATE request could be sent and processed on a server, the response is lost and the client retries. The result might be that the server response to the second request is an error saying it is already created which different from the first success response (ie not idempotent as the response is different), however, the state on the server is idempotent. Of course, it will be possible that applications can be designed without this, but it will be up to the application to deal with the results, not the Coap protocol. Hopefully that clear up my meaning. :) Also, just to be a little pedantic, a READ method is not idempotent if the READ results in a dynamic response (eg temperature sensor). In this case each response is different. Obviously, a READ should always be safe. Although, once again there's nothing in the protocol to stop applications from doing the wrong thing here too. > >> >> " I think the transactionID counter across all nodes it is sending >> requests should be the same. ie node1 (transactionid 1), node2 >> (transactionId 2).. =A0etc. >> If there are multiple clients running on a single node then the source >> port must be different as the transactionId may not be unique." >> >> So, are you suggesting that the server maintain a transaction ID counter= /address/port for each destination and ensure that it is the same value for= a single transaction across multiple clients? What will the storage requir= ements be for such an implementation? > > It is the client which maintains the transaction ID. The server does not = keep state about transaction IDs, but just responds to incoming requests. > > Overall I think David explained this correctly, at least I am thinking al= ong the same lines. > > Zach > >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = David Ryan >> Sent: Tuesday, April 13, 2010 6:37 PM >> To: Angelo P. Castellani >> Cc: core@ietf.org >> Subject: Re: [core] Reability of CoAP messages >> >> Hi, >> >> See comments inline. >> >>>> 1. A receiver node receives two (or more) different requests from two >>>> different nodes and both requests have the same Transaction ID. The >>>> receiver node will discard the last request. >> On Tue, Apr 13, 2010 at 11:12 PM, Angelo P. Castellani >> wrote: >>> (1) I suppose Transaction ID will be used for matching a session on >>> the server using the (clientIP, transactionID) pair. >> >> I'd say that a server node should always process a request and provide >> a response and should not discard duplicate requests. =A0It is important >> that the server does not need to retain state of client requests other >> than current pending/processing requests. =A0Consider the scenario where >> a client sends a request and the server sends a response, however, the >> response is lost. =A0The client may attempt to retry the request using >> the same transactionID. =A0The server will process the request again and >> should send the same response. =A0This is where design of the REST based >> server is important. =A0All transactions should be idempotent (allowing >> safe retries). >> >>>> 2. An application manager running CoAP sends requests to all nodes of >>>> the network (e.g. to node1, .... to node-i, .... to node-N). Not sure >>>> but the application manager can send a new request to the node-i befor= e >>>> to receive the response to the last request and both requests have the >>>> same transaction ID. The receiver node-i will discard the last request= . >>> >>> (2) The same is valid on the client side, the session will be matched >>> using (serverIP, transactionID) pair. >> >> I think the transactionID counter across all nodes it is sending >> requests should be the same. ie node1 (transactionid 1), node2 >> (transactionId 2).. =A0etc. >> If there are multiple clients running on a single node then the source >> port must be different as the transactionId may not be unique. >> >> Regards, >> David. >> >>> >>> However, as already pointed in a previous message titled "Some >>> comments on draft-shelby-core-coap-00" on this list, the use of >>> transaction ID seems really similar to the current use of client >>> source port in the Internet... >>> >>> Bests, >>> Angelo >>> >>> On Tue, Apr 6, 2010 at 14:51, Adriano Pezzuto (apezzuto) >>> wrote: >>>> Hello Zach, >>>> some comments about 2.8.1. UDP section of >>>> http://www.ietf.org/id/draft-shelby-core-coap-00.txt. >>>> >>>> "The Transaction ID in CoAP message headers is used to match >>>> =A0 =A0 =A0responses to open requests and is generated by the client (= common >>>> =A0 =A0 =A0counter across all requests)." >>>> >>>> I suppose, a receiver node will discard the message if a duplicated >>>> Transaction ID is received. >>>> If this is the case, I see two situations where this may have some sor= t >>>> of issues: >>>> >>>> 1. A receiver node receives two (or more) different requests from two >>>> different nodes and both requests have the same Transaction ID. The >>>> receiver node will discard the last request. >>>> >>>> 2. An application manager running CoAP sends requests to all nodes of >>>> the network (e.g. to node1, .... to node-i, .... to node-N). Not sure >>>> but the application manager can send a new request to the node-i befor= e >>>> to receive the response to the last request and both requests have the >>>> same transaction ID. The receiver node-i will discard the last request= . >>>> >>>> For case (1) a possible solution may be to use multiple separate count= er >>>> on the receiver node - one for each transmitter, instead of a common >>>> counter. For case (2), a possible solution is to use a separate counte= r >>>> on the application manager - one for each node, instead of a common >>>> counter. May be a stop-and-wait (as stated in the same section of the >>>> draft) would be sufficient to avoid the case (2) but not sure what you >>>> mean exactly with stop-and-wait. >>>> >>>> Thank you, >>>> Adriano >>>> _______________________________________________ >>>> 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 > > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain le= gally privileged information. If you are not the intended recipient, please= contact the sender and delete the e-mail from your system without producin= g, distributing or retaining copies thereof. > > > > > From apezzuto@cisco.com Wed Apr 14 06:34: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 4A01F3A6AEA for ; Wed, 14 Apr 2010 06:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.335 X-Spam-Level: X-Spam-Status: No, score=-5.335 tagged_above=-999 required=5 tests=[AWL=-4.596, BAYES_20=-0.74, 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 0MtD4Rf6gmIc for ; Wed, 14 Apr 2010 06:34:06 -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 42A793A68A3 for ; Wed, 14 Apr 2010 06:31:31 -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: AvwBAH1gxUuQ/uCWe2dsb2JhbACBP5oZFQEBCwsiBhyjR5lwhQ0E X-IronPort-AV: E=Sophos;i="4.52,204,1270425600"; d="scan'208,217";a="5570514" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2010 12:55:33 +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 o3EDVOHa023734; Wed, 14 Apr 2010 13:31:24 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, 14 Apr 2010 15:31:24 +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_01CADBD6.C6B8DFDF" Date: Wed, 14 Apr 2010 15:31:22 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC01BA7DC7@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] New I-D: Initial Configuration of Resource-ConstrainedDevices (aka: Bootstrapping / Commissioning) Thread-Index: Acq52QauWhYparFBSh2geEx+R60x5Qh+p3Uw References: From: "Adriano Pezzuto (apezzuto)" To: "Oflynn, Colin" , X-OriginalArrivalTime: 14 Apr 2010 13:31:24.0018 (UTC) FILETIME=[C6E9DD20:01CADBD6] Subject: Re: [core] New I-D: Initial Configuration of Resource-ConstrainedDevices (aka: Bootstrapping / Commissioning) 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, 14 Apr 2010 13:34:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CADBD6.C6B8DFDF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Colin, regarding the proposed bootstrapping framework, it would be also useful = to distinguish among manual bootstrapping profile and auto bootstrapping = profile. =20 For example, at phy/link layer of IEEE802.15.4, the auto bootstrapping = profile of the end-nodes may include the radio channel selection while = the manual bootstrapping may include the PAN ID on the coordinator. = Moving at network 6lowpan level, the auto bootstrapping profile of the = nodes may include the network prefix from the neighbor discovery process = while the manual bootstrapping may include the network prefix = configuration on the edge router. =20 Hope this help. =20 Regards, Adriano =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Oflynn, Colin Sent: marted=EC 2 marzo 2010 8.22 To: core@ietf.org; 6lowapp@ietf.org Subject: [core] New I-D: Initial Configuration of = Resource-ConstrainedDevices (aka: Bootstrapping / Commissioning) =20 http://www.ietf.org/id/draft-oflynn-core-bootstrapping-00.txt Lots to do in here still. Note this was posted yesterday, but I didn't = get around to forwarding the announcement. This updates the previous = 6lowapp bootstrapping document a bit too, but is posted as a new I-D to = move to the CoRE group. Regards, -Colin Filename: draft-oflynn-core-bootstrapping Version: 00 Title: Initial Configuration of Resource-Constrained Devices Creation_date: 2010-02-28 WG ID: Individual Submission Number_of_pages: 28 Abstract: The Internet of Things is marching its way towards completion. Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP connectivity. IEEE Standards ensure connectivity at lower layers for resource-constrained devices. Yet a central problem remains at a more basic layer without a suitable answer: how to initially configure the network. Without configuration the network never advances beyond a large box of nodes. Current solutions tend to be specific to a certain vendor, node type, or application. This document outlines exactly what problems are faced in solving this problem. General problems faced in any low-power wireless network are outlined first; followed by how these apply to bootstrapping. A selection of currently proposed techniques is presented. From these a more generic approach is presented, which can solve the problem for a wide range of situations. An emphasis is on performing this bootstrapping in a secure manner. This document does not cover operation of the network securely. This document does provide the basis for allowing the network to operate securely however, by providing standard methods for key exchanges and authentication. Submitter: Colin O'Flynn (colin.oflynn@atmel.com) Author(s): Colin O'Flynn, colin.oflynn@atmel.com Behcet Sarikaya, sarikaya@ieee.org=20 ------_=_NextPart_001_01CADBD6.C6B8DFDF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New I-D: Initial Configuration of Resource-Constrained Devices = (aka: Bootstrapping / Commissioning)

Hi Colin,

regarding the proposed bootstrapping framework, it would = be also useful to distinguish among manual bootstrapping profile and auto = bootstrapping profile.

 

For example, at phy/link layer of IEEE802.15.4, the auto = bootstrapping profile of the end-nodes may include the radio channel selection while = the manual bootstrapping may include the PAN ID on the coordinator. Moving = at network 6lowpan level, the auto bootstrapping profile of the nodes may = include the network prefix from the neighbor discovery process while the manual = bootstrapping may include the network prefix configuration on the edge = router.

 

Hope this help.

 

Regards,

Adriano

 

From:= core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Oflynn, Colin
Sent: marted=EC 2 marzo 2010 8.22
To: core@ietf.org; 6lowapp@ietf.org
Subject: [core] New I-D: Initial Configuration of Resource-ConstrainedDevices (aka: Bootstrapping / = Commissioning)

 

ht= tp://www.ietf.org/id/draft-oflynn-core-bootstrapping-00.txt

Lots to do in here still. Note this was posted yesterday, but I didn't = get around to forwarding the announcement. This updates the previous 6lowapp bootstrapping document a bit too, but is posted as a new I-D to move to = the CoRE group.

Regards,

  -Colin


Filename:          draft-oflynn-core-bootstrapping
Version:           = 00
Title:           &= nbsp; Initial Configuration of Resource-Constrained Devices
Creation_date:     2010-02-28
WG = ID:           &nbs= p; Individual Submission
Number_of_pages: 28
Abstract:
The Internet of Things is marching its way towards completion.  = Nodes
can use standards from the 6LoWPAN and ROLL WG to achieve IP
connectivity.  IEEE Standards ensure connectivity at lower layers = for
resource-constrained devices.  Yet a central problem remains at = a
more basic layer without a suitable answer: how to initially
configure the network.  Without configuration the network never
advances beyond a large box of nodes.  Current solutions tend to = be
specific to a certain vendor, node type, or application.

This document outlines exactly what problems are faced in solving
this problem.  General problems faced in any low-power wireless
network are outlined first; followed by how these apply to
bootstrapping.  A selection of currently proposed techniques is
presented.  From these a more generic approach is presented, = which
can solve the problem for a wide range of situations.

An emphasis is on performing this bootstrapping in a secure manner.
This document does not cover operation of the network securely.  = This
document does provide the basis for allowing the network to operate
securely however, by providing standard methods for key exchanges = and
authentication.

Submitter: Colin O'Flynn (colin.oflynn@atmel.com)

Author(s):
Colin O'Flynn, colin.oflynn@atmel.com
Behcet Sarikaya, sarikaya@ieee.org

------_=_NextPart_001_01CADBD6.C6B8DFDF-- From mark@coactus.com Wed Apr 14 07:41: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 E74483A69C1 for ; Wed, 14 Apr 2010 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 o919QZtui05t for ; Wed, 14 Apr 2010 07:41:55 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id F03CA3A67EC for ; Wed, 14 Apr 2010 07:41:54 -0700 (PDT) Received: by pvf33 with SMTP id 33so109727pvf.31 for ; Wed, 14 Apr 2010 07:41:46 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.231.169.198 with HTTP; Wed, 14 Apr 2010 07:41:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Apr 2010 10:41:46 -0400 X-Google-Sender-Auth: d83c5fedfccb2d46 Received: by 10.142.4.31 with SMTP id 31mr3150902wfd.255.1271256106248; Wed, 14 Apr 2010 07:41:46 -0700 (PDT) Message-ID: From: Mark Baker To: David Ryan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] COAP/CORE application definitions? 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, 14 Apr 2010 14:41:56 -0000 On Mon, Apr 12, 2010 at 10:00 AM, David Ryan wrote: > This question also relates back to the discussion regarding > compatibility with HTTP and HTTP based specifications. =A0If there is no > compatibility it will mean that there will also be no compatibility > with WADL or WSDL 2.0 based specifications. WADL and WSDL have no role to play in a RESTful architecture because they tightly couple the client and server in a manner which REST is specifically designed to avoid. Mark. From d.sturek@att.net Wed Apr 14 07:50:56 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 E56CA3A69CF for ; Wed, 14 Apr 2010 07:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 2Se3hHzOz1h0 for ; Wed, 14 Apr 2010 07:50:56 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 26C4F3A67FD for ; Wed, 14 Apr 2010 07:50:56 -0700 (PDT) Received: (qmail 49627 invoked from network); 14 Apr 2010 14:50:36 -0000 Received: from Studio (d.sturek@69.225.120.138 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 14 Apr 2010 07:50:25 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: uscIVAsVM1mXifZ7mn.oSWeMPhGgH7uAE55Vt__BoU.XLlcUwOhppUDNOBxT5o5rBulU8sLJUeyqH1WTmc.Ze.eVwRyaYJ4ew_Eng7zSY7NvyJJFf0ws3sHKnt3p3IwbjhUpvbKAxDz3D2JGnGlIElPFAvY2dme4inbqowhOS73E4xm_l4I2y.obIt.Qc1wSNUUVsUs0o_0z_OeIsMjilsyz4KoyF7IQ3CbcyjluSVz5zmvOn_MyPxfvnxeAMrOLFIPxH0zlL38L.ZyNec.CPKSZdJ35k8fFXymW_V9uwMVk4EBAe3E- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Mark Baker'" , "'David Ryan'" References: In-Reply-To: Date: Wed, 14 Apr 2010 07:50:23 -0700 Message-ID: <00fc01cadbe1$d0ded730$729c8590$@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: Acrb4J783cNxhJkoS++fVJxuReHLOwAAJ3rQ Content-Language: en-us Cc: 'core' Subject: Re: [core] COAP/CORE application definitions? 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: Wed, 14 Apr 2010 14:50:57 -0000 Hi Mark (and David), I think what CoAP/CoRE is going to face is this: 1) CoRE assumes a REST environment. This is fundamentally at odds with = a SOA based solution 2) Attempts to make CoRE transparently address SOA will fail or make = CoRE useless 3) WSDLs, WADLs, etc. can be addressed by implementers that have legacy deployments (NOT the standard) I think it would be in the groups interest to note that REST is not SOA = and won't be. Industry wise, I believe there has been a shift towards REST so I think = we are making the right choice. I also think for constrained devices REST = is the appropriate choice. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Mark Baker Sent: Wednesday, April 14, 2010 7:42 AM To: David Ryan Cc: core Subject: Re: [core] COAP/CORE application definitions? On Mon, Apr 12, 2010 at 10:00 AM, David Ryan wrote: > This question also relates back to the discussion regarding > compatibility with HTTP and HTTP based specifications. =A0If there is = no > compatibility it will mean that there will also be no compatibility > with WADL or WSDL 2.0 based specifications. WADL and WSDL have no role to play in a RESTful architecture because they tightly couple the client and server in a manner which REST is specifically designed to avoid. Mark. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From rafik.dammak@gmail.com Wed Apr 14 08:01: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 5687B28C272 for ; Wed, 14 Apr 2010 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FopYCRR5zMLW for ; Wed, 14 Apr 2010 08:01:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id DE85928C276 for ; Wed, 14 Apr 2010 08:01:25 -0700 (PDT) Received: by wyb35 with SMTP id 35so103796wyb.31 for ; Wed, 14 Apr 2010 08:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=XbHeN9JWvCCx8LnS5Q5nKF4Icejq/cAP66DS5pHeRRk=; b=ioj4D4CXgKlXKZRb/9lPle8wib81L++WngaZSepZJZevTRQZFQ4cVUSMlAYuic9t/k LmYF+EeAt2q9FqTthDqEjavKGVys5UsQuWmccIDk+65Jhnc0asjejO/MngHNu5m2sVNJ TpPAnCkdUT4f1wYOef8dXgXAW5OwvjtsfJFuk= 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 :cc:content-type; b=qyzda9wcZ1VRr/XQXXwKMqirocA6xCmReanDW5YeFBvC/0UYWOIG24kcU1udrcaA5K O+xQFix650PzpvlN8z6gZ9+sGoDLVZ64IayyzTo4tn3dT473g7W7CzaLPQwXrm38Mt+j ajgH2uSUFQhDEc35ZXlRcLnauxUkQp8RBPQ30= MIME-Version: 1.0 Received: by 10.216.164.83 with HTTP; Wed, 14 Apr 2010 08:00:55 -0700 (PDT) In-Reply-To: <-626790865440579043@unknownmsgid> References: <-626790865440579043@unknownmsgid> From: Rafik Dammak Date: Thu, 15 Apr 2010 00:00:55 +0900 Received: by 10.216.87.140 with SMTP id y12mr5246030wee.36.1271257275296; Wed, 14 Apr 2010 08:01:15 -0700 (PDT) Message-ID: To: d.sturek@att.net Content-Type: multipart/alternative; boundary=0016e6d5667a531dbe048433a6ac Cc: core Subject: Re: [core] COAP/CORE application definitions? 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, 14 Apr 2010 15:01:45 -0000 --0016e6d5667a531dbe048433a6ac Content-Type: text/plain; charset=UTF-8 Hello all, my understanding is that for SOA people will think more to implement it in middelware, in server side for wireless sensor network case to provide web services. when REST architecture will make the devices looking as resources that we can access through HTTP requests. maybe I am misunderstanding. Regards Rafik PS well it is first mail here :) 2010/4/14 Don Sturek > Hi Mark (and David), > > I think what CoAP/CoRE is going to face is this: > 1) CoRE assumes a REST environment. This is fundamentally at odds with a > SOA based solution > 2) Attempts to make CoRE transparently address SOA will fail or make CoRE > useless > 3) WSDLs, WADLs, etc. can be addressed by implementers that have legacy > deployments (NOT the standard) > > I think it would be in the groups interest to note that REST is not SOA and > won't be. > > Industry wise, I believe there has been a shift towards REST so I think we > are making the right choice. I also think for constrained devices REST is > the appropriate choice. > > Don > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Mark > Baker > Sent: Wednesday, April 14, 2010 7:42 AM > To: David Ryan > Cc: core > Subject: Re: [core] COAP/CORE application definitions? > > On Mon, Apr 12, 2010 at 10:00 AM, David Ryan wrote: > > This question also relates back to the discussion regarding > > compatibility with HTTP and HTTP based specifications. If there is no > > compatibility it will mean that there will also be no compatibility > > with WADL or WSDL 2.0 based specifications. > > WADL and WSDL have no role to play in a RESTful architecture because > they tightly couple the client and server in a manner which REST is > specifically designed to avoid. > > Mark. > _______________________________________________ > 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 > --0016e6d5667a531dbe048433a6ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,


my understanding is that= for SOA people will think more to implement it in middelware, in server si= de for wireless sensor network case to provide web services. when REST arch= itecture will make the devices looking as resources that we can access thro= ugh HTTP requests. maybe I am misunderstanding.

Regards

Rafik=C2=A0
=
PS=C2=A0well it is first mail here :)
2010/4/14 Don Sturek <d.sturek@att.net>
Hi Mark (and David),

I think what CoAP/CoRE is going to face is this:
1) =C2=A0CoRE assumes a REST environment. =C2=A0This is fundamentally at od= ds with a
SOA based solution
2) =C2=A0Attempts to make CoRE transparently address SOA will fail or make = CoRE
useless
3) =C2=A0WSDLs, WADLs, etc. can be addressed by implementers that have lega= cy
deployments (NOT the standard)

I think it would be in the groups interest to note that REST is not SOA and=
won't be.

Industry wise, I believe there has been a shift towards REST so I think we<= br> are making the right choice. =C2=A0I also think for constrained devices RES= T is
the appropriate choice.

Don


-----Original Message-----
From: core-bounces@ietf.org [m= ailto:core-bounces@ietf.org] O= n Behalf Of Mark
Baker
Sent: Wednesday, April 14, 2010 7:42 AM
To: David Ryan
Cc: core
Subject: Re: [core] COAP/CORE application definitions?

On Mon, Apr 12, 2010 at 10:00 AM, David Ryan <oobles@gmail.com> wrote:
> This question also relates back to the discussion regarding
> compatibility with HTTP and HTTP based specifications. =C2=A0If there = is no
> compatibility it will mean that there will also be no compatibility > with WADL or WSDL 2.0 based specifications.

WADL and WSDL have no role to play in a RESTful architecture because
they tightly couple the client and server in a manner which REST is
specifically designed to avoid.

Mark.
_______________________________________________
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

--0016e6d5667a531dbe048433a6ac-- From zach@sensinode.com Wed Apr 14 10:06: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 0E7413A698F for ; Wed, 14 Apr 2010 10:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 A2VnA9DWSBAh for ; Wed, 14 Apr 2010 10:06:02 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 388E83A69C5 for ; Wed, 14 Apr 2010 10:05:51 -0700 (PDT) Received: from [10.10.2.9] ([84.239.254.28]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o3EH5V3x014488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Apr 2010 20:05:33 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <00fc01cadbe1$d0ded730$729c8590$@sturek@att.net> Date: Wed, 14 Apr 2010 19:20:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0826949F-FF74-449B-ADF8-7844F34C719D@sensinode.com> References: <00fc01cadbe1$d0ded730$729c8590$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1077) Cc: 'core' Subject: Re: [core] COAP/CORE application definitions? 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, 14 Apr 2010 17:06:04 -0000 On Apr 14, 2010, at 17:50 , Don Sturek wrote: > Hi Mark (and David), >=20 > I think what CoAP/CoRE is going to face is this: > 1) CoRE assumes a REST environment. This is fundamentally at odds = with a > SOA based solution Actually, as a transfer protocol CoAP is perfectly suited for misuse by = SoA just as HTTP is misused by SoA. So in a way you are right, but we = should be aware that some people will use it this way. Anyways - it = doesn't require us to change our RESTful architecture.=20 > 2) Attempts to make CoRE transparently address SOA will fail or make = CoRE > useless I agree, we shall not try to address SoA (nor do we need to). > 3) WSDLs, WADLs, etc. can be addressed by implementers that have = legacy > deployments (NOT the standard) RIght, CoAP does not need to take formal interface description languages = into account. I think there is a misunderstanding about WADL however, it = happens to be designed to describe RESTful interfaces and will surely be = used to describe CoAP interfaces by many designers (I am using it at = least). So nothing to do with legacy anything. Nor does WADL in any way = break the REST architecture... WSDL is aimed at designing SoA interactions, but the newest version = could be used to describe RESTful interfaces (yuck, not sure why a sane = person would do that though)... So we can basically ignore this.=20 Anyways, you can describe a REST interface in any number of ways, so we = shouldn't worry about it. As long as we have similar semantics to HTTP = (we do) then you can just re-use things like WADL if needed.=20 >=20 > I think it would be in the groups interest to note that REST is not = SOA and > won't be. +1 >=20 > Industry wise, I believe there has been a shift towards REST so I = think we > are making the right choice. I also think for constrained devices = REST is > the appropriate choice. Definitely! Zach >=20 > Don >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Mark > Baker > Sent: Wednesday, April 14, 2010 7:42 AM > To: David Ryan > Cc: core > Subject: Re: [core] COAP/CORE application definitions? >=20 > On Mon, Apr 12, 2010 at 10:00 AM, David Ryan wrote: >> This question also relates back to the discussion regarding >> compatibility with HTTP and HTTP based specifications. If there is = no >> compatibility it will mean that there will also be no compatibility >> with WADL or WSDL 2.0 based specifications. >=20 > WADL and WSDL have no role to play in a RESTful architecture because > they tightly couple the client and server in a manner which REST is > specifically designed to avoid. >=20 > Mark. > _______________________________________________ > 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 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From mark@coactus.com Wed Apr 14 11:29: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 A90AA3A681F for ; Wed, 14 Apr 2010 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 bYv5ECqbuLGM for ; Wed, 14 Apr 2010 11:29:39 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id DCC993A676A for ; Wed, 14 Apr 2010 11:29:38 -0700 (PDT) Received: by iwn27 with SMTP id 27so379153iwn.5 for ; Wed, 14 Apr 2010 11:29:30 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.231.169.198 with HTTP; Wed, 14 Apr 2010 11:29:28 -0700 (PDT) In-Reply-To: <0826949F-FF74-449B-ADF8-7844F34C719D@sensinode.com> References: <0826949F-FF74-449B-ADF8-7844F34C719D@sensinode.com> Date: Wed, 14 Apr 2010 14:29:28 -0400 X-Google-Sender-Auth: 742b6faad0caab8c Received: by 10.231.147.146 with SMTP id l18mr379176ibv.74.1271269769878; Wed, 14 Apr 2010 11:29:29 -0700 (PDT) Message-ID: From: Mark Baker To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] COAP/CORE application definitions? 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, 14 Apr 2010 18:29:39 -0000 On Wed, Apr 14, 2010 at 12:20 PM, Zach Shelby wrote: > Anyways, you can describe a REST interface in any number of ways, No, you can't. For the Web, the "RESTful interface" is specified by a set of standard protocols such as RFCs 2616, 3986, 2617, HTML, etc.. Anything WADL describes is just a snapshot of a subset of that interface for a given resource at a given point in time. It doesn't accommodate change and therefore encourages tight coupling and brittle code. That is the antithesis of REST. Mark. From zach@sensinode.com Wed Apr 14 13:25:51 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 4F00028C17B for ; Wed, 14 Apr 2010 13:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 nBlIhB8KMXsj for ; Wed, 14 Apr 2010 13:25: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 2F23C28C140 for ; Wed, 14 Apr 2010 13:24:04 -0700 (PDT) Received: from [10.25.3.98] ([62.237.237.210]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o3EKNjGo021895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Apr 2010 23:23:45 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 14 Apr 2010 23:23:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0826949F-FF74-449B-ADF8-7844F34C719D@sensinode.com> To: Mark Baker X-Mailer: Apple Mail (2.1077) Cc: core Subject: Re: [core] COAP/CORE application definitions? 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, 14 Apr 2010 20:25:51 -0000 On Apr 14, 2010, at 21:29 , Mark Baker wrote: > On Wed, Apr 14, 2010 at 12:20 PM, Zach Shelby = wrote: >> Anyways, you can describe a REST interface in any number of ways, >=20 > No, you can't. For the Web, the "RESTful interface" is specified by a > set of standard protocols such as RFCs 2616, 3986, 2617, HTML, etc.. > Anything WADL describes is just a snapshot of a subset of that > interface for a given resource at a given point in time. It doesn't > accommodate change and therefore encourages tight coupling and brittle > code. That is the antithesis of REST. ;-) I was waiting for someone to shoot me. Let's just agree that = interface description languages are out of scope for CoRE and thus we = don't care here.=20 Zach --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From darco@deepdarc.com Fri Apr 16 14:56: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 A48D63A6807 for ; Fri, 16 Apr 2010 14:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=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 CYBqX15NFAuL for ; Fri, 16 Apr 2010 14:56:07 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 0FA8A3A6B2B for ; Fri, 16 Apr 2010 14:56:04 -0700 (PDT) Received: from [166.205.136.51] (port=49265 helo=[10.98.180.47]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1O2tVw-0001Cz-Df; Fri, 16 Apr 2010 17:55:57 -0400 Message-Id: <51D4D37E-8C2D-4900-82A7-A3D36307F2EC@deepdarc.com> From: Robert Quattlebaum To: "core@ietf.org" Content-Type: multipart/alternative; boundary=Apple-Mail-3--1057513784 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 16 Apr 2010 14:55:44 -0700 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Subject: [core] Simple Monitoring and Control Protocol 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, 16 Apr 2010 22:26:56 -0000 --Apple-Mail-3--1057513784 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I recently bought a house, and this has spurred my interest in wireless sensor networks and home automation in general. After finding that there didn't seem to be a unified IP-based protocol for this sort of thing, I decided that I would go ahead and start to develop one. Today, I found CoRE, and I think that this may be a better forum for developing such a protocol than what I was previously envisioning. I just wanted to describe some of the work that I have done so far, as I think it may be relevant. Originally I started developing the protocol without realizing the extreme packet size limitations, so my original version was a bit verbose. Packets were nominally 130 bytes. I'm working on a much smaller version with the same features that would be suitable for use over 6LoWPAN. The protocol that I was working on I was informally calling the Simple Monitoring and Control Protocol. It had the following design goals: 1) Be largely layer 2 and layer 3 independent, even though I was targeting UDP over IPv6. 2) Be designed from the ground up with the security mechanisms to prevent unauthorized control of devices (including replay attacks) 3) Be designed to not require any centralized server. For example, the temperature sensor would be able to directly tell the heater to turn on or off. 4) Be event based. Each physical device contains a hierarchy of nodes, which are either one of the following: * Device - An organizational unit, like a folder. A physical device can contain several sub-devices, such as multiple temperature sensors, etc. * Variable - A named value that can be polled. Polling the value of a variable is considered an administrative action, and isn't done between devices. * Action - Invoked by an event to change or record something * Event - Invokes actions when certain criteria are met Devices/subdevices can contain variables, events, and actions. Variables can contain events and actions. Device names always end with a '/', Action names always begin with a '?', and event names always begin with a '!'. Variable names do not have any prefixes or suffixes. Individual nodes can be referenced using a URL syntax: * Subdevice: * Variable: * Action: * Event: The real workhorse of the system is the event/action relationship. Events are paired to actions using an administrative interface. Once an event is paired to an action, the two devices will communicate directly with each other. Pairings are created using a special request which is authenticated with the administrative credentials. Both the action and the event must be configured for the pairing. Each pairing contains it's own unique authentication credentials. If an attacker were to learn the credential of a pairing somehow, they would only be able to control the specific action the pairing was attached to. Probably the best way to describe how this system would work is by example. Lets say you wanted to have a light that would be triggered by a motion sensor. The device hierarchy would look something like this: MotionSensor/ !motion-detected Timer/ period remaining enabled ?set ?set=1 ?set=0 ?reset ?stop !fire LampController/ state ?set ?set=0 ?set=1 Keep in mind that just because I'm listing the timer separately doesn't mean that it is necessarily a separate physical device. It could easily be combined into same physical device as the motion sensor, or the lamp controller. Then we would make the following connections: (events on the left, actions on the right) MotionSensor/!motion-detected ........ Timer/?reset MotionSensor/!motion-detected ........ LampController/state?set=1 Timer/!fire ........ LampController/state?set=0 When motion is detected, the timer is reset and the lamp state is set to ON. When the timer expires, it turns the lamp off. This is a fairly simplistic example. Lets try one that is more complicated: What if we want to be able to control the lamp with a switch as well? Here, we add one more device: Switch state !changed !changed=0 !changed=1 Then we would make the following connections: MotionSensor/!motion-detected ........ Timer/?reset MotionSensor/!motion-detected ........ LampController/state?set=1 Timer/!fire ........ LampController/state?set=0 Switch/state!changed ........ LampController/state?set Switch/state!changed=1 ........ Timer/enabled?set=0 Switch/state!changed=0 ........ Timer/enabled?set=1 Whenever the light switch is on, the light will always be on. If the light switch is off, then the light will turn on when motion is detected and turn off after the timeout. If the user wants to turn off the light before the timeout happens, they simply need to only flip the switch on and off. A nice feature of this system is that it allows you to pair sensors and actuators across networks without any additional infrastructure other than what is needed for standard IP networking. There are a lot more details (ie: mechanisms for preventing infinite loops of events, authenticating pairings, challenge/response stuff, etc), but I'll spare them for now. Originally, the packet format was based on SIP and HTTP: very verbose, easy to read, easy to understand. Thinking that I had 1280 bytes to work with, I didn't think it would be a problem... But now that I'm aware of 6LoWPAN and its limitations, I'm considering re-working the packet format into something much more terse and compact. Thoughts and comments would be appreciated. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-3--1057513784 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I recently bought a house, and this has = spurred my interest in wireless sensor networks and home automation in = general. After finding that there didn't seem to be a unified IP-based = protocol for this sort of thing, I decided that I would go ahead and = start to develop one. Today, I found CoRE, and I think that this may be = a better forum for developing such a protocol than what I was previously = envisioning. 

I just wanted to describe = some of the work that I have done so far, as I think it may be relevant. = Originally I started developing the protocol without realizing the = extreme packet size limitations, so my original version was a bit = verbose. Packets were nominally 130 bytes. I'm working on a much smaller = version with the same features that would be suitable for use over = 6LoWPAN.

The protocol that I was working on I = was informally calling the Simple Monitoring and Control Protocol. It = had the following design goals:

1) Be largely = layer 2 and layer 3 independent, even though I was targeting UDP over = IPv6.
2) Be designed from the ground up with the security = mechanisms to prevent unauthorized control of devices (including replay = attacks)
3) Be designed to not require any centralized server. = For example, the temperature sensor would be able to directly tell the = heater to turn on or off. 
4) Be event = based.

Each physical device contains a = hierarchy of nodes, which are either one of the = following:

 * Device - An organizational = unit, like a folder. A physical device can contain several sub-devices, = such as multiple temperature sensors, etc.
 * Variable - = A named value that can be polled. Polling the value of a variable is = considered an administrative action, and isn't done between = devices.
 * Action - Invoked by an event to change or = record something
 * Event - Invokes actions when certain = criteria are met

Devices/subdevices can contain = variables, events, and actions. Variables can contain events and = actions. Device names always end with a '/', Action names always begin = with a '?', and event names always begin with a '!'. Variable names do = not have any prefixes or suffixes.

Individual = nodes can be referenced using a URL syntax:

* = Subdevice: <scmp://[::1]/sensor01/>
* Variable: = <scmp://[::1]/sensor01/temperature>
* Action: = <scmp://[::1]/sensor01/alarm-max?set>
* = Event: <scmp://[::1]/sensor01/temperature!changed>
The real workhorse of the system is the event/action = relationship. Events are paired to actions using an administrative = interface. Once an event is paired to an action, the two devices will = communicate directly with each other. Pairings are created using a = special request which is authenticated with the administrative = credentials. Both the action and the event must be configured for the = pairing. Each pairing contains it's own unique authentication = credentials. If an attacker were to learn the credential of a pairing = somehow, they would only be able to control the specific action the = pairing was attached to. 

Probably the = best way to describe how this system would work is by example. Lets say = you wanted to have a light that would be triggered by a motion sensor. = The device hierarchy would look something like = this:

  • MotionSensor/
    • !motion-detected
      • <= /ul>
    • Timer/
      • period
      • remaining
      • enabled
      • ?set
      • ?set=3D1
      • ?set=3D0
    • ?reset
    • ?= stop
    • !fire
  • LampController/
    • state
        • =
      • ?set
      • ?set=3D0
      • ?set=3D1

Keep in mind that just because I'm listing the timer separately = doesn't mean that it is necessarily a separate physical device. It could = easily be combined into same physical device as the motion sensor, or = the lamp controller.

Then we would make the = following connections: (events on the left, actions on the = right)

MotionSensor/!motion-detected = ........ Timer/?reset
MotionSensor/!motion-detected&nb= sp;........ LampController/state?set=3D1
Timer/!fire .= ....... LampController/state?set=3D0

When = motion is detected, the timer is reset and the lamp state is set to ON. = When the timer expires, it turns the lamp off. This is a fairly = simplistic example. Lets try one that is more complicated: What if we = want to be able to control the lamp with a switch as = well?

Here, we add one more = device: 

  • Switch
    • state
      • !changed
      • !changed=3D0
      • !changed=3D1

=
Then we would make the following = connections:

MotionSensor/!motion-detec= ted ........ Timer/?reset
MotionSensor/!motion-de= tected ........ LampController/state?set=3D1
Timer/!fi= re ........ LampController/state?set=3D0
Switch/state!= changed ........ LampController/state?set
Switch/= state!changed=3D1 ........ Timer/enabled?set=3D0
= Switch/state!changed=3D0 ........ Timer/enabled?set=3D1

Whenever the light switch is on, the light = will always be on. If the light switch is off, then the light will turn = on when motion is detected and turn off after the timeout. If the user = wants to turn off the light before the timeout happens, they simply need = to only flip the switch on and off. 

A = nice feature of this system is that it allows you to pair sensors and = actuators across networks without any additional infrastructure other = than what is needed for standard IP = networking.

There are a lot more details (ie: = mechanisms for preventing infinite loops of events, authenticating = pairings, challenge/response stuff, etc), but I'll spare them for = now. 

Originally, the packet format was = based on SIP and HTTP: very verbose, easy to read, easy to understand. = Thinking that I had 1280 bytes to work with, I didn't think it would be = a problem... But now that I'm aware of 6LoWPAN and its limitations, I'm = considering re-working the packet format into something much more terse = and = compact.

Thoughts = and comments would be appreciated.

Robert = Quattlebaum


=
= --Apple-Mail-3--1057513784-- From clint.chaplin@gmail.com Sun Apr 18 11:21: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 F3CD73A683B for ; Sun, 18 Apr 2010 11:21:43 -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 2rb7csHjFK4G for ; Sun, 18 Apr 2010 11:21:42 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 105D73A68BA for ; Sun, 18 Apr 2010 11:21:36 -0700 (PDT) Received: by pvf33 with SMTP id 33so2641106pvf.31 for ; Sun, 18 Apr 2010 11:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lRShlQVPRNZBRnCeCnVEp6xIWhJ0d4PBftDc2p33Oto=; b=uCA2GPcQHHnL0iU2NzPfsPQ54iQIOITmNyjyMGBKnqFtzKVTYKdYFHcuYLXx6RTUBf fHcIqzbmep7uoqMt4NL0yX2DywVw6RrxWWF0RefUWRoluOtSIWbMl66cjQP0hQfxZi+/ bRh/CjOxJ9a3ybUoCF6GQ2fX1czEc8nXv69vw= 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 :cc:content-type:content-transfer-encoding; b=N3LAT3Ez6YmkS/Rx+iGzv6Qp8mHOQEy8aupRv6x/fhlk/UDX7Zm4BfN3ccyj8NZGD2 EU8Uj5F5BtOgLYJLSiuKBnY8rNXrKpOjhCrqUl1ZDe9Ia6Gqwe5hwfKnimd1Dfos0xi1 EN3sFEnQ+j3ulHXxVIFBvbGGqiW/G8IYA4Xeo= MIME-Version: 1.0 Received: by 10.140.158.13 with HTTP; Sun, 18 Apr 2010 11:21:24 -0700 (PDT) In-Reply-To: <2CFD58C8-23A9-42DF-AB7E-BC75A9D20374@sensinode.com> References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> <2CFD58C8-23A9-42DF-AB7E-BC75A9D20374@sensinode.com> Date: Sun, 18 Apr 2010 11:21:24 -0700 Received: by 10.141.14.19 with SMTP id r19mr202831rvi.255.1271614884480; Sun, 18 Apr 2010 11:21:24 -0700 (PDT) Message-ID: From: Clint Chaplin To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages 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: Sun, 18 Apr 2010 18:21:44 -0000 What is this:? On Tue, Apr 13, 2010 at 10:50 PM, Zach Shelby wrote: > This e-mail and all attached material are confidential and may contain le= gally privileged information. If you are not the intended recipient, please= contact the sender and delete the e-mail from your system without producin= g, distributing or retaining copies thereof. Do we allow such disclaimers on ietf email lists? --=20 Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA From L.Wood@surrey.ac.uk Sun Apr 18 12:06: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 D1DDA3A6B78 for ; Sun, 18 Apr 2010 12:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SR+PPIOvS8X for ; Sun, 18 Apr 2010 12:06:25 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 6D6A43A67F9 for ; Sun, 18 Apr 2010 12:06:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-8.tower-72.messagelabs.com!1271617574!6409461!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 1122 invoked from network); 18 Apr 2010 19:06:14 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-8.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 18 Apr 2010 19:06:14 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Sun, 18 Apr 2010 20:06:13 +0100 From: To: , Date: Sun, 18 Apr 2010 20:06:10 +0100 Thread-Topic: [core] Reability of CoAP messages Thread-Index: AcrfI/4E5FhEVzUwS9eLo2jJIn5InAABgvpA Message-ID: References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> <2CFD58C8-23A9-42DF-AB7E-BC75A9D20374@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 Subject: Re: [core] Reability of CoAP messages 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: Sun, 18 Apr 2010 19:06:26 -0000 see =20 http://www.ietf.org/mail-archive/web/ietf-announce/current/msg02914.html -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cli= nt Chaplin Sent: 18 April 2010 19:21 To: Zach Shelby Cc: core@ietf.org Subject: Re: [core] Reability of CoAP messages What is this:? On Tue, Apr 13, 2010 at 10:50 PM, Zach Shelby wrote: > This e-mail and all attached material are confidential and may contain le= gally privileged information. If you are not the intended recipient, please= contact the sender and delete the e-mail from your system without producin= g, distributing or retaining copies thereof. Do we allow such disclaimers on ietf email lists? -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA From zach@sensinode.com Sun Apr 18 12:18: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 7C99A28C169 for ; Sun, 18 Apr 2010 12:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_40=-0.185, 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 W70UMltxQ+w5 for ; Sun, 18 Apr 2010 12:18:26 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A126A3A6B89 for ; Sun, 18 Apr 2010 12:18:02 -0700 (PDT) Received: from [192.168.1.3] (line-5265.dyn.kponet.fi [85.29.66.228]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o3IJHkfx007495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Apr 2010 22:17:47 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Sun, 18 Apr 2010 22:18:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D212BD466921646B58854FB79092CEC01A7A1EB@XMB-AMS-106.cisco.com> <2CFD58C8-23A9-42DF-AB7E-BC75A9D20374@sensinode.com> To: Clint Chaplin X-Mailer: Apple Mail (2.1077) Cc: core Subject: Re: [core] Reability of CoAP messages 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: Sun, 18 Apr 2010 19:18:28 -0000 Clint, Thanks for noticing, I actually fixed that last week when after = realizing that annoying statement was hanging around by default.=20 Zach On Apr 18, 2010, at 21:21 , Clint Chaplin wrote: > What is this:? >=20 > On Tue, Apr 13, 2010 at 10:50 PM, Zach Shelby = wrote: >> This e-mail and all attached material are confidential and may = contain legally privileged information. If you are not the intended = recipient, please contact the sender and delete the e-mail from your = system without producing, distributing or retaining copies thereof. >=20 >=20 >=20 > Do we allow such disclaimers on ietf email lists? > --=20 > Clint (JOATMON) Chaplin > Principal Engineer > Corporate Standardization (US) > SISA --=20 http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 From darco@deepdarc.com Mon Apr 19 16:32: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 2FC333A67F7 for ; Mon, 19 Apr 2010 16:32:40 -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.433, BAYES_50=0.001, HTML_MESSAGE=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 vIdqVVPV9K6x for ; Mon, 19 Apr 2010 16:32:38 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 4076D3A68B6 for ; Mon, 19 Apr 2010 16:32:38 -0700 (PDT) Received: from [166.205.138.25] (port=37585 helo=[10.20.97.49]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1O40Rs-0000Lm-5F; Mon, 19 Apr 2010 19:32:21 -0400 Message-Id: From: Robert Quattlebaum To: "zach@sensinode.com" , "Michael.Stuber@itron.com" , "d.sturek@att.net" , "brian.tridium@gmail.com" , "richard.kelsey@ember.com" Content-Type: multipart/alternative; boundary=Apple-Mail-1--792535837 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Mon, 19 Apr 2010 16:32:00 -0700 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: "core@ietf.org" Subject: [core] Comments on draft-shelby-core-coap-00 and draft-shelby-core-coap-req-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, 19 Apr 2010 23:32:40 -0000 --Apple-Mail-1--792535837 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello! Here are my comments on draft-shelby-core-coap-00: (Separated by '-----') What is the use case for the CREATE and DELETE methods? Wouldn't the resources exposed by a device be somewhat static? What sorts of resources would I be creating or deleting on a temperature sensor, a power meter, or an appliance module? ----- I think that the UPDATE method and the NOTIFY method could be combined into one method. I believe that it would be relatively easy to design the protocol in such a way as to make this distinction unnecessary. (Elaborated on in my comments on draft-shelby-core-coap-req-00, below) ----- I am assuming that, since URLs are being used, a physical device contains a hierarchy of nodes (Resources?) which can be read, updated, etc. If so, a explicit way to walk thru the hierarchy would be needed. I would recommend a walk-type mechanism (requiring multiple queries) as opposed to 'READ' returning all of the subnodes/resources---because the list of subnodes/resources may not fit into a single packet. It would also likely be easier to implement a walking system on highly constrained devices. ----- Additional error codes worth considering: 401 Unauthorized 403 Forbidden 405 Method Not Allowed 409 Conflict 500 Internal Server Error 503 Service Unavailable 504 Gateway Timeout ----- For the URI codes: 256 values may not be enough. Perhaps an adaptive encoding allowing for larger indices is warranted. A possible encoding scheme would be similar to the EXI Unsigned Integer encoding: . This integer encoding could also be used for the content-type encoding---which would reduce the size of that option by a byte for the 128 most common content types. ----- I am unconvinced of the utility or practicality of a TCP interface for this protocol. In any case where TCP would be considered, I think a protocol such as HTTP would likely be better suited. My thinking is that any device powerful enough to do proper TCP would surely be powerful enough to do simple HTTP. ----- Here are my comments on draft-shelby-core-coap-req-00: Having a push model be a requirement is a good thing, but I do not think that a subscribe/notify mechanism is the ideal way to go. I think a more flexible approach is one where each device exposes "events" (resources which push) to "actions" (resources which do something when they receive a push). Events are then "paired" to actions, using some sort of administrative interface. This gives you a huge amount of flexibility. This was the model I was using for "SCMP", which I document in considerably more detail here: For example, lets say that you have a light switch module and an appliance module. The module has a 'state' variable, that is either 'on' or 'off'. The state variable would have three events associated with it: 'changed', 'turned-on', and 'turned-off'. The payload is the same for each event, but 'turned-on' only fires when the switch is turned on, and 'turned-off' only fires when the switch is turned off. The appliance module has a 'state' variable as well, and it has the following actions: 'set', 'turn-on', and 'turn-off'. The 'set' action would update the 'state' variable to match the payload of the event, assuming the content-type of the event matches the type of the 'state' variable. The 'turn-on' and 'turn-off' events would change the state variable to 'on' or 'off' respectively, ignoring the payload of the event. In general events and actions don't have to be associated with variables, but I'm doing so here for the sake of clarity. You can pair the 'changed' event to the 'set' action, and then the light switch would control the appliance module. In this case, the 'set' action is getting the value to set from the payload of the 'changed' event. (This is why I suggest that the 'UPDATE' and 'NOTIFY' methods could perhaps be merged into a single method) Alternatively, you could have an inverse relationship: You could pair the 'turned-off' event to the 'turn-on' action, and pair the 'turned- on' event to the 'turn-off' action. Now whenever the light switch is 'on', the appliance module is 'off', and vise-versa. This works because the 'turn-on' and 'turn-off' actions don't care what the payload of the event they are receiving is---they perform a specific action whenever they are triggered. I think this mechanism is superior to the subscribe/notify mechanism for the following reasons: Additional metadata or actions can be associated with a pairing (such as reliability requirements). Security credentials can be created per-pairing. This way, if a device is completely compromised the only actions an attacker can take are the ones already paired. One-to-many pairings could be created that would use IPv6 multicasting for more efficient network utilization, while still maintaining the security credentials described above. All pairings happen at setup, so if any resource constraints are exceeded (i.e. too many pairings) it is known at configuration time. If subscriptions happen at run-time, then device resources could be exhausted under certain circumstances causing some subscriptions to fail. Pairings could be made in one of two ways: Using a user interface on a computer. Using a simple push-button pairing for simple, pre-defined device relationships. (e.g. light switch to lamp, volume knob to a stereo, temperature control panel to an HVAC system, etc.) There are a lot of implementation details I'm skipping over for the sake of clarity. Please don't hesitate to ask if you want me to clarify or elaborate on any of the point I have made. Thoughts? __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-1--792535837 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello!

Here are = my comments on draft-shelby-core-coap-00: (Separated = by '-----')

What is the use case for the CREATE = and DELETE methods? Wouldn't the resources exposed by a device be = somewhat static? What sorts of resources would I be creating or deleting = on a temperature sensor, a power meter, or an appliance = module?

-----

I think = that the UPDATE method and the NOTIFY method could be combined into one = method. I believe that it would be relatively easy to design the = protocol in such a way as to make this distinction unnecessary. = (Elaborated on in my comments = on draft-shelby-core-coap-req-00, = below)

-----

= I am assuming that, since URLs are being used, a physical device = contains a hierarchy of nodes (Resources?) which can be read, updated, = etc. If so, a explicit way to walk thru the hierarchy would be needed. I = would recommend a walk-type mechanism (requiring multiple queries) as = opposed to 'READ' returning all of the subnodes/resources---because the = list of subnodes/resources may not fit into a single packet. It would = also likely be easier to implement a walking system on highly = constrained = devices.

-----

Additional error codes worth considering:

  • 401 Unauthorized
  • 403 = Forbidden
  • 405 Method Not Allowed
  • 409 = Conflict
  • 500 Internal Server Error
  • 503 Service = Unavailable
  • 504 Gateway = Timeout

-----

=
For the URI codes: 256 values may not be enough. Perhaps an = adaptive encoding allowing for larger indices is warranted. A possible = encoding scheme would be similar to the EXI Unsigned Integer encoding: = <http://www.w3.o= rg/TR/exi/#encodingUnsignedInteger>. This integer encoding could = also be used for the content-type encoding---which would reduce the size = of that option by a byte for the 128 most common content = types.

-----

= I am unconvinced of the utility or practicality of a TCP interface for = this protocol. In any case where TCP would be considered, I think a = protocol such as HTTP would likely be better suited. My thinking is that = any device powerful enough to do proper TCP would surely be powerful = enough to do simple = HTTP.

-----

H= ere are my comments = on draft-shelby-core-coap-req-00:

<= div>Having a push model be a requirement is a good thing, but I do not = think that a subscribe/notify mechanism is the ideal way to go. I think = a more flexible approach is one where each device exposes "events" = (resources which push) to "actions" (resources which do something when = they receive a push). Events are then "paired" to actions, using some = sort of administrative interface. This gives you a huge amount of = flexibility.

This was the model I was = using for "SCMP", which I document in considerably more detail here: = <h= ttp://www.ietf.org/mail-archive/web/core/current/msg00119.html>

For example, lets say that you have a light = switch module and an appliance module. The module has a 'state' = variable, that is either 'on' or 'off'. The state variable would have = three events associated with it: 'changed', 'turned-on', and = 'turned-off'. The payload is the same for each event, but 'turned-on' = only fires when the switch is turned on, and 'turned-off' only fires = when the switch is turned off. The appliance module has a 'state' = variable as well, and it has the following actions: 'set', 'turn-on', = and 'turn-off'. The 'set' action would update the 'state' variable to = match the payload of the event, assuming the content-type of the event = matches the type of the 'state' variable. The 'turn-on' and 'turn-off' = events would change the state variable to 'on' or 'off' respectively, = ignoring the payload of the event. In general events and actions don't = have to be associated with variables, but I'm doing so here for the sake = of clarity.

You can pair the 'changed' event to = the 'set' action, and then the light switch would control the appliance = module. In this case, the 'set' action is getting the value to set from = the payload of the 'changed' event. (This is why I suggest that the = 'UPDATE' and 'NOTIFY' methods could perhaps be merged into a single = method)

Alternatively, you could have an = inverse relationship: You could pair the 'turned-off' event to the = 'turn-on' action, and pair the 'turned-on' event to the 'turn-off' = action. Now whenever the light switch is 'on', the appliance module is = 'off', and vise-versa. This works because the 'turn-on' and 'turn-off' = actions don't care what the payload of the event they are receiving = is---they perform a specific action whenever they are = triggered. 

I think this mechanism is = superior to the subscribe/notify mechanism for the following = reasons:

  • Additional= metadata or actions can be associated with a pairing (such as = reliability requirements).
  • Security credentials can be created = per-pairing. This way, if a device is completely compromised the only = actions an attacker can take are the ones already = paired. 
  • One-to-many pairings could be created that would = use IPv6 multicasting for more efficient network utilization, while = still maintaining the security credentials described = above. 
  • All pairings happen at setup, so if any resource = constraints are exceeded (i.e. too many pairings) it is known at = configuration time. If subscriptions happen at run-time, then device = resources could be exhausted under certain circumstances causing some = subscriptions to fail.

Pairings could be = made in one of two ways:

  • Using a user interface on a = computer.
  • Using a simple push-button pairing for simple, = pre-defined device relationships. (e.g. light switch to lamp, volume = knob to a stereo, temperature control panel to an HVAC system, = etc.)

There are a lot of implementation = details I'm skipping over for the sake of clarity. Please don't hesitate = to ask if you want me to clarify or elaborate on any of the point I have = made.

Thoughts?

<= div id=3D"AppleMailSignature">
Robert = Quattlebaum



= --Apple-Mail-1--792535837-- From zach@sensinode.com Tue Apr 20 05:11:36 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 9E2E03A68E8 for ; Tue, 20 Apr 2010 05:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72+No8lNa+Wr for ; Tue, 20 Apr 2010 05:11:34 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7AEB13A6889 for ; Tue, 20 Apr 2010 05:11:26 -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 o3KCBDTW025912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Apr 2010 15:11:13 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2010 15:11:15 +0300 References: <20100420120353.BBA043A69C2@core3.amsl.com> To: core Message-Id: <341BEAA8-4006-4F03-8D39-2F8907DC86DD@sensinode.com> 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-req-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, 20 Apr 2010 12:11:36 -0000 Hi, http://www.ietf.org/id/draft-shelby-core-coap-req-01.txt I submitted an updated version of the CoAP requirements draft. Based on = the feedback from the WG meeting I removed all the feature analysis = stuff, so this is now just a temporary requirements reference (not = planning on making any more updates). Thanks also to Bob, Alexey and = Xavi for comments on the draft - I tried to clarify some of the = requirements as suggested. Please keep in mind this is just summarizing = the charter and the industry requirement drafts, so this is just a = reference. For those of you not in Anaheim, I also made a nice graphic of these = requirements on Page 30 of = http://tools.ietf.org/agenda/77/slides/core-0.pdf. Capturing that in = this draft was way beyond my ASCII art skills. Volunteers? ;-) Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: April 20, 2010 15:03:53 GMT+03:00 > To: zach@sensinode.com > Cc: = Michael.Stuber@itron.com,d.sturek@att.net,brian.tridium@gmail.com,richard.= kelsey@ember.com > Subject: New Version Notification for draft-shelby-core-coap-req-01=20 >=20 >=20 > A new version of I-D, draft-shelby-core-coap-req-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-coap-req > Revision: 01 > Title: CoAP Requirements and Features > Creation_date: 2010-04-20 > WG ID: Independent Submission > Number_of_pages: 10 >=20 > Abstract: > This document considers the requirements for the design of the > Constrained Application Protocol (CoAP). The goal of the document is > to provide a basis for protocol design and related discussion. >=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 zach@sensinode.com Tue Apr 20 05:25: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 A7B5728C17D for ; Tue, 20 Apr 2010 05:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, J_CHICKENPOX_83=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 NzVD+CQE1jSq for ; Tue, 20 Apr 2010 05:25:28 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3C5AB28C192 for ; Tue, 20 Apr 2010 05:22: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 o3KCMQ4r030586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Apr 2010 15:22:27 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: Date: Tue, 20 Apr 2010 15:22:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bob Dolin X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] Comments on draft-shelby-core-coap-req-00.txt 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, 20 Apr 2010 12:25:30 -0000 Bob, Sorry I didn't get back to you earlier. Please see the latest draft just = posted where I clarified a couple of the requirements better. I am not = able to deal with all of your suggestions as much of this is already = from our approved charter, but here are some comments below: On Mar 23, 2010, at 18:48 , Bob Dolin wrote: > This didn=92t appear to go through last night, so I am re-sending. I = apologize in advance if you are receiving this twice. > =20 > =20 > Comments on CoAP Requirements and Features, = draft-shelby-core-coap-req-00, > issued on February 18, 2010. > =20 > Bob Dolin > Echelon Corporation > =20 > After reading this document, I have to say that the requirements = stated within it > are insufficient to serve the markets that my company does. Those = markets are, > I believe, what the expansion of IP to the "internet of things" is = intended to address. > Essential to this market is a uniform set of protocol services that = interoperate, to > enable applications to be easily developed with the result that a = bunch of intelligent > objects, made by different companies, and integrated together by an = unsophisticated user > work as expected. > =20 > Below, are some more detailed observations. > =20 > The document contains the following abstract: > =20 > Abstract > =20 > This document considers the requirements and resulting features > needed for the design of the Constrained Application Protocol = (CoAP). > Starting from requirements for energy and building automation > applications, the basic features are identified along with an > analysis of possible realizations. The goal of the document is to > provide a basis for protocol design and related discussion. > =20 > [bobd] I think this abstract is overly constrained in its scope, or = other > parts of this document far exceed the scope alluded to in the = abstract. It says > that its focus is on energy and building automation applications. = However, > the scope of IP for resource constrained devices, or IP for Smart = Objects > goes well beyond building automation and energy applications to = generic > sensing, monitoring and control of "things." I believe that the = abstract > should be to support the IP connectivity of smart objects, or = something > like that to encompass the broader "internet of things," or generic = M2M > applications or something along those lines. Yep, generic M2M is one of the areas taken into account. > =20 > In the requirements section of the document it says: > =20 > REQ9: CoAP will support a non-reliable multicast message to be = sent > to a group of Devices to manipulate a resource on all the > Devices simultaneously [charter]. The use of multicast to > query and advertise descriptions must be supported, along > with the support of unicast responses > [I-D.sturek-6lowapp-smartenergy]. > =20 > REQ11: Reliability must be possible for application layer messages > over UDP [I-D.sturek-6lowapp-smartenergy]. This is only for unicast UDP, now clarified in -01. In other words, a = multicast IP request message may result in a response but we won't try = to make that reliable (retransmissions). =20 > =20 > [bobd] These, along with the attendant features of duplicate packet > detection, transaction timing, retry counts and retry timers are = transport > layer services and are not part of an application layer protocol. = These > transport layer services should not be forced upon every application = author > to code up, get right, and interoperate with the other = implementations. > Typical application developers have application domain knowledge. = Typical > protocol engineers know about protocols, but do not have application > domain knowledge for every application that may use their protocol. It = is > unreasonable to expect either group to do a good job on the other's = area > of expertise. This was discussed at length when forming CoRE, and yes some longer-term = transport work may get started as a result of our experience here (but = that will take years). This WG needs to produce a simple solution using = UDP this year. Personally, I don't see a problem of doing a simple = stop-and-wait and possible retransmission using UDP. In the future when = some better transport becomes available someone can simply define a CoAP = binding to that as well.=20 > =20 > In the general case of IP for smart objects, I would expect (and my = company > has experienced) that developers move applications that were directly = wired, > no network, to one where the I/Os, and controllers are physically = separate and > interconnected with a communication network. In this more general = case, the > application may be thought of as a single state machine where the = advancement > to the next state is based upon reliable messaging -- if the message = didn't get > there, perhaps a shut down or a safety interlock should be actuated = rather than > just going on. In this environment, reliable unicasting and reliable = multicasting > with duplicate message detection (to support non-idempotent = messages)are required. > Thus, the set of requirements in this draft does not meet the general = requirements > for creating general, intelligent, distributed applications. > =20 > Given that features are needed from both a transport and from an = application layer, > the effort should be split into defining a transport protocol for = resource constrained > devices and an application protocol for resource constrained devices. In the IETF application layer model the transfer protocol and the actual = application protocol and logic are two separate things. The goal of CoRE = is to define a simple transfer protocol just as HTTP does. The transport = area may very well take on some related work in the future, but we can't = depend on that.=20 > =20 > Later on in the document it says: > =20 > REQ12: Latency times should be mimimized of the Home Area Network > (HAN), and ideally a typical exchange should consist of = just > a single request and a single response message. > [I-D.sturek-6lowapp-smartenergy] > =20 > [bobd] One technique to reduce latency is to support multicast = request/response > in the transport layer. It is a slight generalization to reliable = multicast where > a simple acknowledgement is replaced with an application generated = response. > In this way, a single request could be sent to, say 10 nodes, and each = node would > respond, for a total number of messages of 11, versus a unicast to = each, with a > total number of messages being 20. Multicast request/response service = should be > required. This is exactly what will be done. When we talk about multicast, it is = IP multicast. Therefore a=20 multicast message in that case may result in up to 11 messages. So no = problem here. If this multicast request needs to be 100% reliable then = that needs to be handled by the application protocol using CoAP.=20 The text below is no longer in the document, instead we are working on = that in the CoAP specification document now. Regards, Zach > =20 > Further down, the document states: > =20 > 2.8.1. UDP > =20 > The goal of binding CoAP to UDP is to provide the bare minimum > features for the protocol to operate over UDP, going nowhere near > trying to re-create the full feature set of TCP. The bare minimum > features required would be: > =20 > o Stop-and-wait would be sufficient for reliability. A simple > response message itself would suffice as an acknowledgement with > retransmission support. Not all requests require reliability, > thus this should be optional. Performance is not the key here = and > for more sophisticated reliability and flow control TCP could be > used. > [bobd] Stop-and-wait is not sufficient for a general purpose = application > even in building automation. Consider the case of a node that has as a = primary > responsibility, communicating with some set of other nodes and pinging > them for their application status -- maybe to display on a web page. = Consider > that the set of nodes is large, say 50 or even 100 -- a large building = may > have over 1,000 VAV (variable air volume) controllers in it, so = monitoring > just a hundred nodes is not far-fetched. Now, consider that one node = isn't > responding. With stop-and-wait, the monitor node cannot move on to ask = the > next node's status until all the timeouts and retries have been = exhausted on > the first node. Now consider that there is a link failure and multiple = nodes > aren't responding. With only stop-and-wait services, the monitoring = node's > performance will be unacceptable. Also, I have the same comment that > retries and such are NOT part of the application layer in the ISO = model. > =20 > Next the document says: > =20 > o A sequence number (transaction ID) is needed to match responses = to > open requests and would be generated by the client. A 12-16 bit > unsigned interger would be sufficient. = [I-D.frank-6lowapp-chopan] > also considered this solution. > [bobd] This doesn't belong in an application layer, it is a transport = service. > This seems pretty simple, but what about the error/edge cases, like a = client that > is using sequence number X and has a message outstanding, and then = restarts, and > issues its next request using sequence number X. Should sequence = numbers be > persistent across resets, or should one be reserved to only use after = a reset, which > one? What happens when different application developers use different = conventions? > Interoperability can be a real nightmare when such decisions are left = to each > application implementer. This working group needs to define a distinct = transport > layer and a distinct application layer with well defined services for = each. > =20 > Next the document says: > =20 > o Multicast support. Providing reliability with a multicast > destination address would be very complex. Therefore the goal = is > to provide a non-reliable multicast service. In many cases = there > may not be a response to a multicast message. A multicast = command > might result in an action being taken at a device, but no = response > being sent. Therefore a multicast request may be answered with = a > unicast response, however without reliability (retransmission > e.g.). > =20 > [bobd] I read this as, reliable multicast is really hard, and we need = it, but > since it is really hard, we will define away the requirement, even = though we > need it. Actually, reliable multicast, reliable request/response, and = multicast > repeated-but-unacked services are all a part of the distinct (as in = separate from > the network layer and application layer) transport layer of ISO/IEC = 14908-1, and > an optimized implementation of that standard fits in 12K bytes for the > MAC through L2 through L7, and consumes only 512 bytes for the RAM. > So, it doesn't have to be hard or complex, one could simply integrate = what has > already been done. Granted, in that protocol specification, commonly = called the > LonWorks(r) protocol or LonTalk(r) protocol, multicast groups cannot = be of arbitrary > size if reliable services are used, instead the specification does = support groups > of up to 64 members. The transport protocol itself has no such = limitation. If there > is interest, I could put together an internet draft of such a = transport layer that > depends only upon the services of an underlying UDP/IPv6 layer. > =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 Apr 20 05:47: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 2C77D3A6A77 for ; Tue, 20 Apr 2010 05:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.900, 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 SsdE9qWWmhbw for ; Tue, 20 Apr 2010 05:47: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 44F8E3A6BBA for ; Tue, 20 Apr 2010 05:47:04 -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 o3KCkfKr007189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Apr 2010 15:46:42 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: Date: Tue, 20 Apr 2010 15:46:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Quattlebaum X-Mailer: Apple Mail (2.1077) Cc: core Subject: Re: [core] Comments on draft-shelby-core-coap-00 and draft-shelby-core-coap-req-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: Tue, 20 Apr 2010 12:47:10 -0000 Hi Robert, Thanks for the comments.=20 On Apr 20, 2010, at 2:32 , Robert Quattlebaum wrote: > Hello! >=20 > Here are my comments on draft-shelby-core-coap-00: (Separated by = '-----') >=20 > What is the use case for the CREATE and DELETE methods? Wouldn't the = resources exposed by a device be somewhat static? What sorts of = resources would I be creating or deleting on a temperature sensor, a = power meter, or an appliance module? I am actually updating these methods to be called GET, PUT, POST, DELETE = as the semantics are very similar. One example of creating/deleting a = resource on a sensor node would be on some configuration parameter which = needs a list of things. RESTful interfaces actually make pretty heavy = use of all 4 methods.=20 >=20 > ----- >=20 > I think that the UPDATE method and the NOTIFY method could be combined = into one method. I believe that it would be relatively easy to design = the protocol in such a way as to make this distinction unnecessary. = (Elaborated on in my comments on draft-shelby-core-coap-req-00, below) Yep. Currently I am working on removing the NOTIFY method and instead am = defining a proper notification message type as suggested by Robert = Cragie.=20 >=20 > ----- >=20 > I am assuming that, since URLs are being used, a physical device = contains a hierarchy of nodes (Resources?) which can be read, updated, = etc. If so, a explicit way to walk thru the hierarchy would be needed. I = would recommend a walk-type mechanism (requiring multiple queries) as = opposed to 'READ' returning all of the subnodes/resources---because the = list of subnodes/resources may not fit into a single packet. It would = also likely be easier to implement a walking system on highly = constrained devices. RESTful URls work in a walk thru way. That is, if you GET /sensors that = will probably only return the links to sensors whereas if you GET = /sensors/temp that will likely return the representation of temperature. = Note that I say probably/likely as it is totally up to the server what = is returned. This works in the same way as HTTP. >=20 > ----- >=20 > Additional error codes worth considering: >=20 > =95 401 Unauthorized > =95 403 Forbidden > =95 405 Method Not Allowed > =95 409 Conflict > =95 500 Internal Server Error > =95 503 Service Unavailable > =95 504 Gateway Timeout What would 409 be used for? The others I can understand. Am planning a = section to list all the codes supported.=20 >=20 > ----- >=20 > For the URI codes: 256 values may not be enough. Perhaps an adaptive = encoding allowing for larger indices is warranted. A possible encoding = scheme would be similar to the EXI Unsigned Integer encoding: = . This integer = encoding could also be used for the content-type encoding---which would = reduce the size of that option by a byte for the 128 most common content = types. Sure, that scheme would work nicely. Will consider it. Although you = don't need to assign a code to every URL, only to the most commonly used = ones if you want to save overhead. Thus you will rarely run out of those = 256 codes.=20 >=20 > ----- >=20 > I am unconvinced of the utility or practicality of a TCP interface for = this protocol. In any case where TCP would be considered, I think a = protocol such as HTTP would likely be better suited. My thinking is that = any device powerful enough to do proper TCP would surely be powerful = enough to do simple HTTP. You know, I totally agree with that approach. The recent conversations = around SCTP and UDP/TCP negotiation have made me even more unsure if we = need to define a TCP binding at all. Maybe we end up just saying that if = you want to use TCP, then go ahead and use HTTP (okay, shoot me) ;-) >=20 > ----- >=20 > Here are my comments on draft-shelby-core-coap-req-00: >=20 > Having a push model be a requirement is a good thing, but I do not = think that a subscribe/notify mechanism is the ideal way to go. I think = a more flexible approach is one where each device exposes "events" = (resources which push) to "actions" (resources which do something when = they receive a push). Events are then "paired" to actions, using some = sort of administrative interface. This gives you a huge amount of = flexibility. Right, you can do this with CoAP notification. The subscription will be = just *one* way of setting up notifications. CoAP is just a transfer = protocol (like HTTP) whereas you need to develop your own protocol = logic. That logic may very well set up such event pairing and make use = of the notification feature of CoAP. I also find unsolicited = (pre-configured) notifications to be useful in many cases. Cheers, Zach >=20 > This was the model I was using for "SCMP", which I document in = considerably more detail here: = >=20 > For example, lets say that you have a light switch module and an = appliance module. The module has a 'state' variable, that is either 'on' = or 'off'. The state variable would have three events associated with it: = 'changed', 'turned-on', and 'turned-off'. The payload is the same for = each event, but 'turned-on' only fires when the switch is turned on, and = 'turned-off' only fires when the switch is turned off. The appliance = module has a 'state' variable as well, and it has the following actions: = 'set', 'turn-on', and 'turn-off'. The 'set' action would update the = 'state' variable to match the payload of the event, assuming the = content-type of the event matches the type of the 'state' variable. The = 'turn-on' and 'turn-off' events would change the state variable to 'on' = or 'off' respectively, ignoring the payload of the event. In general = events and actions don't have to be associated with variables, but I'm = doing so here for the sake of clarity. >=20 > You can pair the 'changed' event to the 'set' action, and then the = light switch would control the appliance module. In this case, the 'set' = action is getting the value to set from the payload of the 'changed' = event. (This is why I suggest that the 'UPDATE' and 'NOTIFY' methods = could perhaps be merged into a single method) >=20 > Alternatively, you could have an inverse relationship: You could pair = the 'turned-off' event to the 'turn-on' action, and pair the 'turned-on' = event to the 'turn-off' action. Now whenever the light switch is 'on', = the appliance module is 'off', and vise-versa. This works because the = 'turn-on' and 'turn-off' actions don't care what the payload of the = event they are receiving is---they perform a specific action whenever = they are triggered.=20 >=20 > I think this mechanism is superior to the subscribe/notify mechanism = for the following reasons: >=20 > =95 Additional metadata or actions can be associated with a = pairing (such as reliability requirements). > =95 Security credentials can be created per-pairing. This way, = if a device is completely compromised the only actions an attacker can = take are the ones already paired.=20 > =95 One-to-many pairings could be created that would use IPv6 = multicasting for more efficient network utilization, while still = maintaining the security credentials described above.=20 > =95 All pairings happen at setup, so if any resource constraints = are exceeded (i.e. too many pairings) it is known at configuration time. = If subscriptions happen at run-time, then device resources could be = exhausted under certain circumstances causing some subscriptions to = fail. >=20 > Pairings could be made in one of two ways: >=20 > =95 Using a user interface on a computer. > =95 Using a simple push-button pairing for simple, pre-defined = device relationships. (e.g. light switch to lamp, volume knob to a = stereo, temperature control panel to an HVAC system, etc.) >=20 > There are a lot of implementation details I'm skipping over for the = sake of clarity. Please don't hesitate to ask if you want me to clarify = or elaborate on any of the point I have made. >=20 > Thoughts? >=20 > __________________ > Robert Quattlebaum > Jabber: darco@deepdarc.com > eMail: darco@deepdarc.com > www: http://www.deepdarc.com/ >=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 From darco@deepdarc.com Tue Apr 20 12:10:48 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 6FAD53A6957 for ; Tue, 20 Apr 2010 12:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.311 X-Spam-Level: X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=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 dn8tkNYXZLFF for ; Tue, 20 Apr 2010 12:10:42 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 0770C3A68F6 for ; Tue, 20 Apr 2010 12:10:41 -0700 (PDT) Received: from [166.205.139.2] (port=20060 helo=[10.40.192.154]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1O4Iq1-0005Sr-My; Tue, 20 Apr 2010 15:10:31 -0400 Message-Id: <07D9EE93-1A79-4BAF-B38E-383BD53D7872@deepdarc.com> From: Robert Quattlebaum To: Zach Shelby Content-Type: multipart/alternative; boundary=Apple-Mail-2--721843636 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Tue, 20 Apr 2010 12:10:08 -0700 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: core Subject: Re: [core] Comments on draft-shelby-core-coap-00 and draft-shelby-core-coap-req-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: Tue, 20 Apr 2010 19:10:48 -0000 --Apple-Mail-2--721843636 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hello Zach! On Apr 20, 2010, at 5:46 AM, Zach Shelby wrote: > On Apr 20, 2010, at 2:32 , Robert Quattlebaum wrote: > >> Hello! >> >> Here are my comments on draft-shelby-core-coap-00: (Separated by =20 >> '-----') >> >> What is the use case for the CREATE and DELETE methods? Wouldn't =20 >> the resources exposed by a device be somewhat static? What sorts of =20= >> resources would I be creating or deleting on a temperature sensor, =20= >> a power meter, or an appliance module? > > I am actually updating these methods to be called GET, PUT, POST, =20 > DELETE as the semantics are very similar. One example of creating/=20 > deleting a resource on a sensor node would be on some configuration =20= > parameter which needs a list of things. RESTful interfaces actually =20= > make pretty heavy use of all 4 methods. This makes sense. These were exactly the same method names I was using =20= for SCMP, using POST for notifications. >> I am assuming that, since URLs are being used, a physical device =20 >> contains a hierarchy of nodes (Resources?) which can be read, =20 >> updated, etc. If so, a explicit way to walk thru the hierarchy =20 >> would be needed. I would recommend a walk-type mechanism (requiring =20= >> multiple queries) as opposed to 'READ' returning all of the =20 >> subnodes/resources---because the list of subnodes/resources may not =20= >> fit into a single packet. It would also likely be easier to =20 >> implement a walking system on highly constrained devices. > > RESTful URls work in a walk thru way. That is, if you GET /sensors =20 > that will probably only return the links to sensors whereas if you =20 > GET /sensors/temp that will likely return the representation of =20 > temperature. Note that I say probably/likely as it is totally up to =20= > the server what is returned. This works in the same way as HTTP. Well, yes, I guess it is, but if you can't fit the list of all of the =20= children of /sensors into one packet then you are in trouble. What I'm =20= suggesting is providing a way to walk thru the items in a level of the =20= hierarchy. For example, lets say there are 1000 sensors, but only 10 =20 can fit in a packet. First you would request the listing and it would =20= return the first 10 and then indicate that there are additional nodes. =20= You would then submit another query which includes the last item from =20= the previously returned list as the 'starting point'. You would then =20 continue this until you retrieved the names of all the sensors or you =20= exceeded some sort of hard limit on the number of returned items. >> Additional error codes worth considering: >> >> =E2=80=A2 401 Unauthorized >> =E2=80=A2 403 Forbidden >> =E2=80=A2 405 Method Not Allowed >> =E2=80=A2 409 Conflict >> =E2=80=A2 500 Internal Server Error >> =E2=80=A2 503 Service Unavailable >> =E2=80=A2 504 Gateway Timeout > > What would 409 be used for? The others I can understand. Am planning =20= > a section to list all the codes supported. 409 would be used whenever there is some sort of conflict that would =20 prevent the given request from being processed. For example, some =20 application protocols may want their requests to represent =20 transactions. If one device sends a request to another device and it =20 then receives a request from the same device before receiving a =20 response, it may return 409 to indicate that it can't process the =20 request until the pending transaction is complete. (If both sides =20 return 409 then that's no good either, so some sort of stateless tie-=20 break would be needed in this case, but you get the idea) >> I am unconvinced of the utility or practicality of a TCP interface =20= >> for this protocol. In any case where TCP would be considered, I =20 >> think a protocol such as HTTP would likely be better suited. My =20 >> thinking is that any device powerful enough to do proper TCP would =20= >> surely be powerful enough to do simple HTTP. > > You know, I totally agree with that approach. The recent =20 > conversations around SCTP and UDP/TCP negotiation have made me even =20= > more unsure if we need to define a TCP binding at all. Maybe we end =20= > up just saying that if you want to use TCP, then go ahead and use =20 > HTTP (okay, shoot me) ;-) I mentioned this, but later I was thinking about the possibility of =20 using this protocol over RS-232 serial line... It might be useful to =20 define how the protocol could be used in this way, but to recommend =20 against using it over TCP. *shrugs* >> Here are my comments on draft-shelby-core-coap-req-00: >> >> Having a push model be a requirement is a good thing, but I do not =20= >> think that a subscribe/notify mechanism is the ideal way to go. I =20 >> think a more flexible approach is one where each device exposes =20 >> "events" (resources which push) to "actions" (resources which do =20 >> something when they receive a push). Events are then "paired" to =20 >> actions, using some sort of administrative interface. This gives =20 >> you a huge amount of flexibility. > > Right, you can do this with CoAP notification. The subscription will =20= > be just *one* way of setting up notifications. CoAP is just a =20 > transfer protocol (like HTTP) whereas you need to develop your own =20 > protocol logic. That logic may very well set up such event pairing =20 > and make use of the notification feature of CoAP. I also find =20 > unsolicited (pre-configured) notifications to be useful in many cases. Is that to say that the subscription/pairing mechanism would be =20 defined in another draft-standard? Has there been any work on that =20 yet, or should I write up some proposals and run them by you? By the way... In the SCMP idea I was working on, devices could send =20 events to other devices, and those devices may send other events when =20= they receive events(Timers, room-controllers, etc). This presents the =20= possibility of having event-action loop that would flood the network =20 with events. I recommend adding another header, perhaps named "Cascade-=20= Hop-Count" or something. For every event which is triggered by another =20= event, the cascade-hop-count of the triggering event would first be =20 checked to make sure it is non-zero. If it is zero, the new event =20 isn't sent. If it is non-zero, it would be decremented and copied to =20 the new event. This way event loops eventually die and don't take down =20= the whole network. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-2--721843636 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello Zach!

On Apr 20, 2010, at 5:46 AM, Zach = Shelby wrote:

On Apr 20, 2010, at 2:32 , Robert Quattlebaum = wrote:

Hello!

Here are my = comments on draft-shelby-core-coap-00: (Separated by = '-----')

What is the use = case for the CREATE and DELETE methods? Wouldn't the resources exposed = by a device be somewhat static? What sorts of resources would I be = creating or deleting on a temperature sensor, a power meter, or an = appliance module?

I am actually updating these = methods to be called GET, PUT, POST, DELETE as the semantics are very = similar. One example of creating/deleting a resource on a sensor node = would be on some configuration parameter which needs a list of things. = RESTful interfaces actually make pretty heavy use of all 4 methods. =

This makes sense. These were exactly = the same method names I was using for SCMP, using POST for = notifications.

I am assuming that, since = URLs are being used, a physical device contains a hierarchy of nodes = (Resources?) which can be read, updated, etc. If so, a explicit way to = walk thru the hierarchy would be needed. I would recommend a walk-type = mechanism (requiring multiple queries) as opposed to 'READ' returning = all of the subnodes/resources---because the list of subnodes/resources = may not fit into a single packet. It would also likely be easier to = implement a walking system on highly constrained = devices.

RESTful URls work in a walk thru way. That is, = if you GET /sensors that will probably only return the links to sensors = whereas if you GET /sensors/temp that will likely return the = representation of temperature. Note that I say probably/likely as it is = totally up to the server what is returned. This works in the same way as = HTTP.

Well, yes, I guess it is, but if you = can't fit the list of all of the children of /sensors into one packet = then you are in trouble. What I'm suggesting is providing a way to walk = thru the items in a level of the hierarchy. For example, lets say there = are 1000 sensors, but only 10 can fit in a packet. First you would = request the listing and it would return the first 10 and then indicate = that there are additional nodes. You would then submit another query = which includes the last item from the previously returned list as the = 'starting point'. You would then continue this until you retrieved the = names of all the sensors or you exceeded some sort of hard limit on the = number of returned items.

Additional error codes = worth considering:

=E2=80=A2 = 401 Unauthorized
=E2=80=A2 = 403 Forbidden
=E2=80=A2 = 405 Method Not Allowed
=E2=80=A2 = 409 Conflict
=E2=80=A2 = 500 Internal Server Error
=E2=80=A2 = 503 Service Unavailable
=E2=80=A2 = 504 Gateway Timeout

What would 409 be used for? The = others I can understand. Am planning a section to list all the codes = supported.

409 would be used whenever there is some = sort of conflict that would prevent the given request from being = processed. For example, some application protocols may want their = requests to represent transactions. If one device sends a request to = another device and it then receives a request from the same device = before receiving a response, it may return 409 to indicate that it can't = process the request until the pending transaction is complete. (If both = sides return 409 then that's no good either, so some sort of stateless = tie-break would be needed in this case, but you get the idea)

I am unconvinced of the = utility or practicality of a TCP interface for this protocol. In any = case where TCP would be considered, I think a protocol such as HTTP = would likely be better suited. My thinking is that any device powerful = enough to do proper TCP would surely be powerful enough to do simple = HTTP.

You know, I totally agree with that approach. The = recent conversations around SCTP and UDP/TCP negotiation have made me = even more unsure if we need to define a TCP binding at all. Maybe we end = up just saying that if you want to use TCP, then go ahead and use HTTP = (okay, shoot me) ;-)

I mentioned this, but later I was = thinking about the possibility of using this protocol over RS-232 serial = line... It might be useful to define how the protocol could be used in = this way, but to recommend against using it over TCP. = *shrugs*

Here are my comments on = draft-shelby-core-coap-req-00:

Having a push = model be a requirement is a good thing, but I do not think that a = subscribe/notify mechanism is the ideal way to go. I think a more = flexible approach is one where each device exposes "events" (resources = which push) to "actions" (resources which do something when they receive = a push). Events are then "paired" to actions, using some sort of = administrative interface. This gives you a huge amount of = flexibility.

Right, you can do this with CoAP = notification. The subscription will be just *one* way of setting up = notifications. CoAP is just a transfer protocol (like HTTP) whereas you = need to develop your own protocol logic. That logic may very well set up = such event pairing and make use of the notification feature of CoAP. I = also find unsolicited (pre-configured) notifications to be useful in = many cases.

Is that to say that the = subscription/pairing mechanism would be defined in another = draft-standard? Has there been any work on that yet, or should I write = up some proposals and run them by you?

By the way... In the SCMP idea I was = working on, devices could send events to other devices, and those = devices may send other events when they receive events(Timers, = room-controllers, etc). This presents the possibility of having = event-action loop that would flood the network with events. I recommend = adding another header, perhaps named "Cascade-Hop-Count" or something. = For every event which is triggered by another event, the = cascade-hop-count of the triggering event would first be checked to make = sure it is non-zero. If it is zero, the new event isn't sent. If it is = non-zero, it would be decremented and copied to the new event. This way = event loops eventually die and don't take down the whole = network.

Robert = Quattlebaum



= --Apple-Mail-2--721843636-- From ynir@checkpoint.com Wed Apr 21 01:19: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 E0D7E3A69B7 for ; Wed, 21 Apr 2010 01:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-1.809, BAYES_50=0.001, MISSING_SUBJECT=1.762, 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 DmLoxpDtLgTa for ; Wed, 21 Apr 2010 01:19:19 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 7E2393A6822 for ; Wed, 21 Apr 2010 01:19:18 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o3L8J7pi029284 for ; Wed, 21 Apr 2010 11:19:08 +0300 (IDT) X-CheckPoint: {4BCEC23F-2-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 21 Apr 2010 11:19:36 +0300 From: Yoav Nir To: "'core@ietf.org'" Date: Wed, 21 Apr 2010 11:19:34 +0300 Thread-Index: AcrhK1ir3RTn3psmQOKTMvKwWjs4bg== Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C5A1@il-ex01.ad.checkpoint.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] (no subject) 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, 21 Apr 2010 08:19:20 -0000 >>> I am unconvinced of the utility or practicality of a TCP interface for= =20 >>> this protocol. In any case where TCP would be considered, I think a=20 >>> protocol such as HTTP would likely be better suited. My thinking is tha= t >>> any device powerful enough to do proper TCP would surely be powerful= =20 >>> enough to do simple HTTP. >> You know, I totally agree with that approach. The recent conversations=20 >> around SCTP and UDP/TCP negotiation have made me even more unsure if we= =20 >> need to define a TCP binding at all. Maybe we end up just saying that if= =20 >> you want to use TCP, then go ahead and use HTTP (okay, shoot me) ;-) > I mentioned this, but later I was thinking about the possibility of using= > this protocol over RS-232 serial line... It might be useful to define ho= w=20 > the protocol could be used in this way, but to recommend against using it= > over TCP. *shrugs* It depends on both the line speed and application. Some of the interfaces m= entioned in discussions here are as low as 1200 bps (DALI). RS-232 can hand= le 2400-19200 depending on cable length. 802.15.4 reduces power requirement= s by going down to 10000 bps.=20 A TCP packet over IPv6 is at least 60 bytes (480 bits) not counting layer 2= overhead. That's almost 1500 bits for the 3-way handshake alone, before th= e actual data gets sent. With a 1200 bps cable, that's over a 1-second addi= tional delay just to use TCP instead of UDP. This could be acceptable for s= ome sensors, and for controlling HVAC or even a fire alarm, but I don't thi= nk it would be acceptable for a light switch talking to a lighting fixture. Still, where timing is not critical, it's always a good idea to allow packe= ts to be sent through an arbitrary amount of hops, through VPN, or whatever= . And there's no beating TCP for getting the packet through. It takes the b= urden of reliability off of the application developer, so I guess it really= should be in there, with the appropriate caveats. Just as long as not ever= y light switch and lighting fixture need to support TCP for this. From robby.simpson@ge.com Wed Apr 21 07:45: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 895BD28C240 for ; Wed, 21 Apr 2010 07:45:20 -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 sXYWbUf-RtCg for ; Wed, 21 Apr 2010 07:45:16 -0700 (PDT) Received: from exprod5og109.obsmtp.com (exprod5og109.obsmtp.com [64.18.0.188]) by core3.amsl.com (Postfix) with ESMTP id BA82828C233 for ; Wed, 21 Apr 2010 07:17:10 -0700 (PDT) Received: from source ([4.79.213.129]) (using TLSv1) by exprod5ob109.postini.com ([64.18.4.12]) with SMTP ID DSNKS88I3Hsr39EdkaEWn616DModTKgD5mZV@postini.com; Wed, 21 Apr 2010 07:17:02 PDT Received: from unknown (HELO cinmlef09.e2k.ad.ge.com) ([3.159.213.56]) by Alpmlip08.e2k.ad.ge.com with ESMTP; 21 Apr 2010 10:16:50 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.51]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 10:16: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: Wed, 21 Apr 2010 10:16:34 -0400 Message-ID: In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C5A1@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] (no subject) Thread-Index: AcrhK1ir3RTn3psmQOKTMvKwWjs4bgAMGWYQ References: <006FEB08D9C6444AB014105C9AEB133FB37650C5A1@il-ex01.ad.checkpoint.com> From: "Simpson, Robby (GE Energy Services)" To: "Yoav Nir" , X-OriginalArrivalTime: 21 Apr 2010 14:16:49.0664 (UTC) FILETIME=[486AB000:01CAE15D] Subject: Re: [core] (no subject) 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, 21 Apr 2010 14:45:20 -0000 If there are concerns with the TCP 3-way handshake, I would suggest at least giving a peek at T/TCP (RFC 1379 and RFC 1644). - Robby -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, April 21, 2010 4:20 AM To: 'core@ietf.org' Subject: [core] (no subject) >>> I am unconvinced of the utility or practicality of a TCP interface=20 >>> for this protocol. In any case where TCP would be considered, I=20 >>> think a protocol such as HTTP would likely be better suited. My=20 >>> thinking is that >>> any device powerful enough to do proper TCP would surely be powerful enough to do simple HTTP. >> You know, I totally agree with that approach. The recent=20 >> conversations around SCTP and UDP/TCP negotiation have made me even=20 >> more unsure if we need to define a TCP binding at all. Maybe we end=20 >> up just saying that if you want to use TCP, then go ahead and use=20 >> HTTP (okay, shoot me) ;-) > I mentioned this, but later I was thinking about the possibility of=20 > using > this protocol over RS-232 serial line... It might be useful to > define how the protocol could be used in this way, but to recommend=20 > against using it > over TCP. *shrugs* It depends on both the line speed and application. Some of the interfaces mentioned in discussions here are as low as 1200 bps (DALI). RS-232 can handle 2400-19200 depending on cable length. 802.15.4 reduces power requirements by going down to 10000 bps.=20 A TCP packet over IPv6 is at least 60 bytes (480 bits) not counting layer 2 overhead. That's almost 1500 bits for the 3-way handshake alone, before the actual data gets sent. With a 1200 bps cable, that's over a 1-second additional delay just to use TCP instead of UDP. This could be acceptable for some sensors, and for controlling HVAC or even a fire alarm, but I don't think it would be acceptable for a light switch talking to a lighting fixture. Still, where timing is not critical, it's always a good idea to allow packets to be sent through an arbitrary amount of hops, through VPN, or whatever. And there's no beating TCP for getting the packet through. It takes the burden of reliability off of the application developer, so I guess it really should be in there, with the appropriate caveats. Just as long as not every light switch and lighting fixture need to support TCP for this. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From kerlyn2001@gmail.com Wed Apr 21 08:32: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 6FB493A6CA6 for ; Wed, 21 Apr 2010 08:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 TXDVzD8LUpSB for ; Wed, 21 Apr 2010 08:32:15 -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 766263A6BC1 for ; Wed, 21 Apr 2010 08:05:27 -0700 (PDT) Received: by wwb24 with SMTP id 24so539891wwb.31 for ; Wed, 21 Apr 2010 08:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=6+lD3VtMpd+HmrMwvxoy7exKibipTFo5tQz32eiO71A=; b=AVFDuPOAtlsaSY73aDWdEt3TH6BHejEXhKROnWTmennhQbdVF8LK2wuiUK96pCWwXi Goyp/j+0WiVytqiZmvYI5Yj6K0elDKLZLMlqig963imbKMWgyGpLRDj6bZmQ/x1M/woO X9uDMWlz5H/l0vMEbRgkkPl1+sxdR9L5CHXS0= 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 :cc:content-type; b=Az30rfHqgRsDJ0v2nBqMMqhFtBEGz30OQGNqHrD4sCq64Nfo6U7OkDtH9oaC+KRcGZ BHtYtNOIzTLUaZchE4uiunh1IJkiO1VegiNZsu00xQzLAiK4k+QiAAVBPxEsViQ3dpZ4 H9A9nEen2uRqJ9EcgP5nM/C/3CTV5yvR08zkk= MIME-Version: 1.0 Received: by 10.216.72.196 with HTTP; Wed, 21 Apr 2010 08:05:14 -0700 (PDT) In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB37650C5A1@il-ex01.ad.checkpoint.com> Date: Wed, 21 Apr 2010 11:05:14 -0400 Received: by 10.216.85.133 with SMTP id u5mr4802689wee.91.1271862314569; Wed, 21 Apr 2010 08:05:14 -0700 (PDT) Message-ID: From: Kerry Lynn To: "Simpson, Robby (GE Energy Services)" Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] (no subject) 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, 21 Apr 2010 15:32:16 -0000 T/TCP has some great properties (better channel utilization, per-host rather than per-session state) but has some well-know security issues we'd have to address: http://www.mid-way.org/doc/ttcp-sec.txt Re: serial comms, many RS-232 ports support 115.2Kbps . SLIP is the least complex encapsulation scheme (RFC 1055) but hasn't been updated for multi-protocol support, which is addressed here: http://ftp.rodents.montreal.qc.ca/pub/mouse/docs/ipv6-slip -K- On Wed, Apr 21, 2010 at 10:16 AM, Simpson, Robby (GE Energy Services) wrote: > If there are concerns with the TCP 3-way handshake, I would suggest at > least giving a peek at T/TCP (RFC 1379 and RFC 1644). > > - Robby > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Yoav Nir > Sent: Wednesday, April 21, 2010 4:20 AM > To: 'core@ietf.org' > Subject: [core] (no subject) > >>>> I am unconvinced of the utility or practicality of a TCP interface >>>> for this protocol. In any case where TCP would be considered, I >>>> think a protocol such as HTTP would likely be better suited. My >>>> thinking is that >>> any device powerful enough to do proper TCP > would surely be powerful enough to do simple HTTP. > >>> You know, I totally agree with that approach. The recent >>> conversations around SCTP and UDP/TCP negotiation have made me even >>> more unsure if we need to define a TCP binding at all. Maybe we end >>> up just saying that if you want to use TCP, then go ahead and use >>> HTTP (okay, shoot me) ;-) > >> I mentioned this, but later I was thinking about the possibility of >> using > this protocol over RS-232 serial line... It might be useful to > >> define how the protocol could be used in this way, but to recommend >> against using it > over TCP. *shrugs* > > It depends on both the line speed and application. Some of the > interfaces mentioned in discussions here are as low as 1200 bps (DALI). > RS-232 can handle 2400-19200 depending on cable length. 802.15.4 reduces > power requirements by going down to 10000 bps. > > A TCP packet over IPv6 is at least 60 bytes (480 bits) not counting > layer 2 overhead. That's almost 1500 bits for the 3-way handshake alone, > before the actual data gets sent. With a 1200 bps cable, that's over a > 1-second additional delay just to use TCP instead of UDP. This could be > acceptable for some sensors, and for controlling HVAC or even a fire > alarm, but I don't think it would be acceptable for a light switch > talking to a lighting fixture. > > Still, where timing is not critical, it's always a good idea to allow > packets to be sent through an arbitrary amount of hops, through VPN, or > whatever. And there's no beating TCP for getting the packet through. It > takes the burden of reliability off of the application developer, so I > guess it really should be in there, with the appropriate caveats. Just > as long as not every light switch and lighting fixture need to support > TCP for this. > _______________________________________________ > 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 darco@deepdarc.com Wed Apr 21 09:26: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 2D9753A69BD for ; Wed, 21 Apr 2010 09:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=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 iGhwDILsHyLa for ; Wed, 21 Apr 2010 09:26:17 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 579E028C51C for ; Wed, 21 Apr 2010 08:57:02 -0700 (PDT) Received: from c-67-161-40-140.hsd1.ca.comcast.net ([67.161.40.140]:34169 helo=[172.30.96.14]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1O4cIF-0008WM-0V; Wed, 21 Apr 2010 11:56:51 -0400 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-11--647050477 From: Robert Quattlebaum In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C5A1@il-ex01.ad.checkpoint.com> Date: Wed, 21 Apr 2010 08:56:49 -0700 Message-Id: <3E6CDE33-641C-4372-A7B5-28AAB429D450@deepdarc.com> References: <006FEB08D9C6444AB014105C9AEB133FB37650C5A1@il-ex01.ad.checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1078) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: "'core@ietf.org'" Subject: Re: [core] (no subject) 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, 21 Apr 2010 16:26:18 -0000 --Apple-Mail-11--647050477 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 21, 2010, at 1:19 AM, Yoav Nir wrote: >=20 >> I mentioned this, but later I was thinking about the possibility of = using > this protocol over RS-232 serial line... It might be useful to = define how=20 >> the protocol could be used in this way, but to recommend against = using it > over TCP. *shrugs* >=20 > It depends on both the line speed and application. Some of the = interfaces mentioned in discussions here are as low as 1200 bps (DALI). = RS-232 can handle 2400-19200 depending on cable length. 802.15.4 reduces = power requirements by going down to 10000 bps.=20 >=20 > A TCP packet over IPv6 is at least 60 bytes (480 bits) not counting = layer 2 overhead. That's almost 1500 bits for the 3-way handshake alone, = before the actual data gets sent. With a 1200 bps cable, that's over a = 1-second additional delay just to use TCP instead of UDP. This could be = acceptable for some sensors, and for controlling HVAC or even a fire = alarm, but I don't think it would be acceptable for a light switch = talking to a lighting fixture. >=20 > Still, where timing is not critical, it's always a good idea to allow = packets to be sent through an arbitrary amount of hops, through VPN, or = whatever. And there's no beating TCP for getting the packet through. It = takes the burden of reliability off of the application developer, so I = guess it really should be in there, with the appropriate caveats. Just = as long as not every light switch and lighting fixture need to support = TCP for this. I think I was misunderstood. I was referring to using a serial line in = the same way that a TCP connection would be used. No IP encapsulation = would be necessary---the only protocol used would be CoAP. One end of = the serial line would be a CoAP device, and the other end could be a = CoAP proxy... __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-11--647050477 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I mentioned this, but later I was thinking about the = possibility of using > this protocol over RS-232 serial line... It = might be useful to define how
the protocol could be used in this way, but to recommend = against using it > over TCP. *shrugs*

It depends = on both the line speed and application. Some of the interfaces mentioned = in discussions here are as low as 1200 bps (DALI). RS-232 can handle = 2400-19200 depending on cable length. 802.15.4 reduces power = requirements by going down to 10000 bps.

A TCP packet over IPv6 = is at least 60 bytes (480 bits) not counting layer 2 overhead. That's = almost 1500 bits for the 3-way handshake alone, before the actual data = gets sent. With a 1200 bps cable, that's over a 1-second additional = delay just to use TCP instead of UDP. This could be acceptable for some = sensors, and for controlling HVAC or even a fire alarm, but I don't = think it would be acceptable for a light switch talking to a lighting = fixture.

Still, where timing is not critical, it's always a good = idea to allow packets to be sent through an arbitrary amount of hops, = through VPN, or whatever. And there's no beating TCP for getting the = packet through. It takes the burden of reliability off of the = application developer, so I guess it really should be in there, with the = appropriate caveats. Just as long as not every light switch and lighting = fixture need to support TCP for = this.

I think I was = misunderstood. I was referring to using a serial line in the same way = that a TCP connection would be used. No IP encapsulation would be = necessary---the only protocol used would be CoAP. One end of the serial = line would be a CoAP device, and the other end could be a CoAP = proxy...




= --Apple-Mail-11--647050477-- From dotis@mail-abuse.org Wed Apr 21 09:43: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 712933A6B33 for ; Wed, 21 Apr 2010 09:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.029 X-Spam-Level: X-Spam-Status: No, score=-1.029 tagged_above=-999 required=5 tests=[AWL=2.970, 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 Isv4msvPuE5A for ; Wed, 21 Apr 2010 09:43:33 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id F0FAC3A6D5D for ; Wed, 21 Apr 2010 09:17:03 -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 21A76A94448 for ; Wed, 21 Apr 2010 16:16:48 +0000 (UTC) Message-ID: <4BCF24EE.1060001@mail-abuse.org> Date: Wed, 21 Apr 2010 09:16:46 -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: <006FEB08D9C6444AB014105C9AEB133FB37650C5A1@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C5A1@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] transport associations over UDP 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, 21 Apr 2010 16:43:34 -0000 On 4/21/10 1:19 AM, Yoav Nir wrote: >>> You know, I totally agree with that approach. The recent conversations around SCTP and UDP/TCP negotiation have made me even more unsure if we need to define a TCP binding at all. Maybe we end up just saying that if you want to use TCP, then go ahead and use HTTP (okay, shoot me) ;-) >>> >> I mentioned this, but later I was thinking about the possibility of using> this protocol over RS-232 serial line... It might be useful to define how the protocol could be used in this way, but to recommend against using it> over TCP. *shrugs* >> > It depends on both the line speed and application. Some of the interfaces mentioned in discussions here are as low as 1200 bps (DALI). RS-232 can handle 2400-19200 depending on cable length. 802.15.4 reduces power requirements by going down to 10000 bps. > > A TCP packet over IPv6 is at least 60 bytes (480 bits) not counting layer 2 overhead. That's almost 1500 bits for the 3-way handshake alone, before the actual data gets sent. With a 1200 bps cable, that's over a 1-second additional delay just to use TCP instead of UDP. This could be acceptable for some sensors, and for controlling HVAC or even a fire alarm, but I don't think it would be acceptable for a light switch talking to a lighting fixture. > > Still, where timing is not critical, it's always a good idea to allow packets to be sent through an arbitrary amount of hops, through VPN, or whatever. And there's no beating TCP for getting the packet through. It takes the burden of reliability off of the application developer, so I guess it really should be in there, with the appropriate caveats. Just as long as not every light switch and lighting fixture need to support TCP for this. > When each packet contains a verification tag (to identify an association), good error detection, transport sequence numbers, with TLV data framing, then associations can persist while retaining little state. Slower networks should safely allow use of smaller fields. SCTP demonstrated establishment of associations (TCP connections) with data exchanged sooner than with TCP, while also avoiding source spoofing and sync-flood attacks. Persistent associations permit single packet exchanges on par with that of UDP. But unlike UDP or T-TCP, recipients are able to detect source spoofing, and to determine packet loss. Keep-alives or heart-beats should be optional. Modes of operation would be negotiated when an association is initialized. With UDP, ordered or reliable delivery is not assured, so there should be a mode offering unordered unreliable delivery to mimic the dynamics of UDP. By including selective and cumulative transport sequence number acknowledgment, delivery modes well beyond what is offered by TCP becomes possible. The TLV data chunk used by SCTP for selective acknowledgment contains the following: Cumulative TSN Ack Advertised Receiver Window Credit Number of Gap Ack Blocks Number of Duplicate TSNs Gap Ack Block #1 Start Gap Ack Block #1 End Gap Ack Block #N Start Gap Ack Block #N End Duplicate TSN 1 ... Duplicate TSN X Modes of delivery for unicast and broadcast transmissions could include: 1) unreliable unordered delivery (without receiver or transmitter buffering) 2) unreliable ordered delivery (without receiver or transmitter buffering) 3) reliable unordered delivery (without receiver buffering) 4) reliable ordered delivery (with receiver and transmitter buffering) TCP only offers unicast reliable ordered delivery with receiver and transmitter buffering, but then lacks data framing. Data framing permits inclusion of information within each packet to enable zero copy placement of data received out of order. A socket API, much like what had been defined with SCTP, could easily mimic the mode of operation offered by TCP, while consuming less buffer resources, network traffic, while having lower latency and much higher reliability. -Doug From angelo.castellani@gmail.com Thu Apr 22 03:26: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 756B53A69B8 for ; Thu, 22 Apr 2010 03:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 1cla7a4KE9ae for ; Thu, 22 Apr 2010 03:26:52 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 37A4F3A6A8D for ; Thu, 22 Apr 2010 03:26:47 -0700 (PDT) Received: by ywh38 with SMTP id 38so4405060ywh.29 for ; Thu, 22 Apr 2010 03:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:received:message-id:subject:from:to:cc :content-type; bh=kk8zoB/0IDPusa0oyFEmx+cqeckcua70eeGJy8wBCCE=; b=d2j7ISUPpOuqUfVvJNqnb0KAELzkx0KnmfHfjDijWeC3o6X/ukoLfkGtae0BR2xq3b roKqJ2sxF4L+wNRCk5189cU7bOFuSWQ5rNVLNTI5RwFuc+Jw3WXQKcg9mjT/TD6ujDl7 17vcjqG1bMORXDsAitqbhE40fg9AlLB565m5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=f9vrDrt/81YMfx0qk5fSGutw2pc8vAow0nBQbMchG2xD7FUJBqBxQt40N0QNCo89jx YcmyDS5pnYiVMzq2nZiWwyokwGunRFvUq1WDco9HXWKWiYrokxopM4+ftiEgO4S0cc33 LghSIyhNBPLotq0SjdMvZq4UKxjBE2uy0bs14= MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.90.106.17 with HTTP; Thu, 22 Apr 2010 03:26:26 -0700 (PDT) Date: Thu, 22 Apr 2010 12:26:26 +0200 X-Google-Sender-Auth: 733984085725b5fd Received: by 10.91.185.3 with SMTP id m3mr5013192agp.79.1271931989156; Thu, 22 Apr 2010 03:26:29 -0700 (PDT) Message-ID: From: "Angelo P. Castellani" To: core Content-Type: text/plain; charset=ISO-8859-1 Cc: Nicola Bui , Michele Rossi , Michele Zorzi , Francesco Fornasiero Subject: [core] Transparent proxying 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, 22 Apr 2010 10:26:53 -0000 Dear all, we have started developing a plugin for the Squid Cache project, that will allow transparent proxying of compressed (BWS/CoAP?) HTTP packets to/from a 6LoWPAN/WSN; we are trying to do this following the format specified in the current CoAP draft. However this requires a well defined mapping from HTTP to CoAP and viceversa. >>>>> HTTP->CoAP: (1) Compressed requests should be small (2) State information should not be required by the proxy The major problem here is that the URI cannot be represented as a code (high-compression) but only by the full string representation. For such a reason I suggest the use of Binary-URI instead of URI-Code. You can find a possible definition for Binary-URI in what follows: Binary-URI is a compressed mapping of the String-URI: * It is N bytes long, where N is the depth of the resource in the String-URI. example: (a) /document/letter/order.html DEPTH: 3 (b) / DEPTH: 0 (c) /index.html DEPTH: 1 * byte K is equal to the sum modulo 256 of ASCII values forming the K-level resource name in the tree: (a) document = 95, letter = 144, order.html = 255. So Binary-URI = { 95, 144, 255 } (c-style representation) (b) no byte so Binary-URI = {} (c) index.html = 251. Binary-URI = { 251 } Here is the code of the program used to compute the values: sum.c #include #include int main (int argc, char* argv[]) { if (argc==2) { unsigned char* p = argv[1]; int sum=0; do { sum+=*p; } while (*(++p)); printf("word: \"%s\" sum: %d\n", argv[1], sum&0xff); } } Resources created on a CoAP server should not collide with each-other, to achieve this when we try to register a new resource the CoAP server should check if it is colliding with other available resources and accept the request only if this condition is satisfied. Instead using URI-Code a table is always needed to map between String-URI and Code-URI. Table mapping is an operation that requires knowledge on the entity operating that translation (CoAP will require state information to be translated, which should be avoided in my opinion), moreover table storage, handling and search requires a non-trivial cost on a costrained device. Cookie and Set-Cookie headers are really useful and should be included. Using cookies it is possible for CoAP servers to delegate state information memorization to the client. >>>> CoAP->HTTP: CoAP clients accessing HTTP servers may require to send arbitrary headers to that server. At least the most common headers should be handled by defining an option. Here is a very basic list to be completed: Host: (very important both to access virtual HTTP servers and to allow easier implementation of transparent proxying) Cookie: Set-Cookie: etc. etc. Moreover Binary-Cookie and Set-Binary-Cookie can be defined using the same format of binary mapping as described in the URI. An option to include an arbitrary header in my opinion is required and should be included. It can be Generic-Header string option carrying the header name and the full text contained. Best regards, Angelo P. Castellani From Sebastian.Hans@Sun.COM Mon Apr 26 04:14: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 ABF3A3A6B67 for ; Mon, 26 Apr 2010 04:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_66=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 32668dBkYm4o for ; Mon, 26 Apr 2010 04:14:51 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id EBD353A6819 for ; Mon, 26 Apr 2010 04:14:50 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3QBEawK008261 for ; Mon, 26 Apr 2010 11:14:36 GMT MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1H00N00CSG2100@fe-emea-09.sun.com> for core@ietf.org; Mon, 26 Apr 2010 12:14:24 +0100 (BST) Received: from [192.168.178.54] (p4FC11695.dip.t-dialin.net [79.193.22.149]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L1H006BBDVL8H20@fe-emea-09.sun.com> for core@ietf.org; Mon, 26 Apr 2010 12:14:09 +0100 (BST) Date: Mon, 26 Apr 2010 13:14:08 +0200 From: Sebastian Hans In-reply-to: <07D9EE93-1A79-4BAF-B38E-383BD53D7872@deepdarc.com> Sender: Sebastian.Hans@Sun.COM To: core Message-id: <4BD57580.9080009@sun.com> Content-transfer-encoding: QUOTED-PRINTABLE References: <07D9EE93-1A79-4BAF-B38E-383BD53D7872@deepdarc.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Cc: Sebastian.Hans@Sun.COM Subject: Re: [core] Comments on draft-shelby-core-coap-00 and draft-shelby-core-coap-req-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, 26 Apr 2010 11:14:52 -0000 Robert Quattlebaum wrote: > Hello Zach! >=20 > On Apr 20, 2010, at 5:46 AM, Zach Shelby wrote: >=20 >> On Apr 20, 2010, at 2:32 , Robert Quattlebaum wrote: >> >>> Hello! >>> >>> Here are my comments on draft-shelby-core-coap-00: (Separated by = '-----') >>> >>> What is the use case for the CREATE and DELETE methods? Wouldn't = the=20 >>> resources exposed by a device be somewhat static? What sorts of= =20 >>> resources would I be creating or deleting on a temperature sensor= , a=20 >>> power meter, or an appliance module? >> >> I am actually updating these methods to be called GET, PUT, POST,= =20 >> DELETE as the semantics are very similar. One example of=20 >> creating/deleting a resource on a sensor node would be on some= =20 >> configuration parameter which needs a list of things. RESTful=20 >> interfaces actually make pretty heavy use of all 4 methods. >=20 I agree CREATE/DELETE makes a lot of sense also for very small device= s=20 that are expected to live for a long time. In the ETSI M2M group they= =20 discuss the management of such devices and the creation and update of= =20 files for network settings and other resourced on the device. -Sebastian Hans > This makes sense. These were exactly the same method names I was us= ing=20 > for SCMP, using POST for notifications. >=20 >>> I am assuming that, since URLs are being used, a physical device= =20 >>> contains a hierarchy of nodes (Resources?) which can be read,= =20 >>> updated, etc. If so, a explicit way to walk thru the hierarchy wo= uld=20 >>> be needed. I would recommend a walk-type mechanism (requiring= =20 >>> multiple queries) as opposed to 'READ' returning all of the=20 >>> subnodes/resources---because the list of subnodes/resources may n= ot=20 >>> fit into a single packet. It would also likely be easier to imple= ment=20 >>> a walking system on highly constrained devices. >> >> RESTful URls work in a walk thru way. That is, if you GET /sensors= =20 >> that will probably only return the links to sensors whereas if you= GET=20 >> /sensors/temp that will likely return the representation of=20 >> temperature. Note that I say probably/likely as it is totally up t= o=20 >> the server what is returned. This works in the same way as HTTP. >=20 > Well, yes, I guess it is, but if you can't fit the list of all of t= he=20 > children of /sensors into one packet then you are in trouble. What = I'm=20 > suggesting is providing a way to walk thru the items in a level of = the=20 > hierarchy. For example, lets say there are 1000 sensors, but only 1= 0 can=20 > fit in a packet. First you would request the listing and it would r= eturn=20 > the first 10 and then indicate that there are additional nodes. You= =20 > would then submit another query which includes the last item from t= he=20 > previously returned list as the 'starting point'. You would then= =20 > continue this until you retrieved the names of all the sensors or y= ou=20 > exceeded some sort of hard limit on the number of returned items. >=20 >>> Additional error codes worth considering: >>> >>> =E2=80=A2 401 Unauthorized >>> =E2=80=A2 403 Forbidden >>> =E2=80=A2 405 Method Not Allowed >>> =E2=80=A2 409 Conflict >>> =E2=80=A2 500 Internal Server Error >>> =E2=80=A2 503 Service Unavailable >>> =E2=80=A2 504 Gateway Timeout >> >> What would 409 be used for? The others I can understand. Am planni= ng a=20 >> section to list all the codes supported. >=20 > 409 would be used whenever there is some sort of conflict that woul= d=20 > prevent the given request from being processed. For example, some= =20 > application protocols may want their requests to represent transact= ions.=20 > If one device sends a request to another device and it then receive= s a=20 > request from the same device before receiving a response, it may re= turn=20 > 409 to indicate that it can't process the request until the pending= =20 > transaction is complete. (If both sides return 409 then that's no g= ood=20 > either, so some sort of stateless tie-break would be needed in this= =20 > case, but you get the idea) >=20 >>> I am unconvinced of the utility or practicality of a TCP interfac= e=20 >>> for this protocol. In any case where TCP would be considered, I t= hink=20 >>> a protocol such as HTTP would likely be better suited. My thinkin= g is=20 >>> that any device powerful enough to do proper TCP would surely be= =20 >>> powerful enough to do simple HTTP. >> >> You know, I totally agree with that approach. The recent conversat= ions=20 >> around SCTP and UDP/TCP negotiation have made me even more unsure = if=20 >> we need to define a TCP binding at all. Maybe we end up just sayin= g=20 >> that if you want to use TCP, then go ahead and use HTTP (okay, sho= ot=20 >> me) ;-) >=20 > I mentioned this, but later I was thinking about the possibility of= =20 > using this protocol over RS-232 serial line... It might be useful t= o=20 > define how the protocol could be used in this way, but to recommend= =20 > against using it over TCP. *shrugs* >=20 >>> Here are my comments on draft-shelby-core-coap-req-00: >>> >>> Having a push model be a requirement is a good thing, but I do no= t=20 >>> think that a subscribe/notify mechanism is the ideal way to go. I= =20 >>> think a more flexible approach is one where each device exposes= =20 >>> "events" (resources which push) to "actions" (resources which do= =20 >>> something when they receive a push). Events are then "paired" to= =20 >>> actions, using some sort of administrative interface. This gives = you=20 >>> a huge amount of flexibility. >> >> Right, you can do this with CoAP notification. The subscription wi= ll=20 >> be just *one* way of setting up notifications. CoAP is just a tran= sfer=20 >> protocol (like HTTP) whereas you need to develop your own protocol= =20 >> logic. That logic may very well set up such event pairing and make= use=20 >> of the notification feature of CoAP. I also find unsolicited=20 >> (pre-configured) notifications to be useful in many cases. >=20 > Is that to say that the subscription/pairing mechanism would be def= ined=20 > in another draft-standard? Has there been any work on that yet, or= =20 > should I write up some proposals and run them by you? >=20 > By the way... In the SCMP idea I was working on, devices could send= =20 > events to other devices, and those devices may send other events wh= en=20 > they receive events(Timers, room-controllers, etc). This presents t= he=20 > possibility of having event-action loop that would flood the networ= k=20 > with events. I recommend adding another header, perhaps named=20 > "Cascade-Hop-Count" or something. For every event which is triggere= d by=20 > another event, the cascade-hop-count of the triggering event would = first=20 > be checked to make sure it is non-zero. If it is zero, the new even= t=20 > isn't sent. If it is non-zero, it would be decremented and copied t= o the=20 > new event. This way event loops eventually die and don't take down = the=20 > whole network. >=20 > __________________ > *Robert Quattlebaum* > Jabber: darco@deepdarc.com > eMail: darco@deepdarc.com > www: http://www.deepdarc.com/ >=20 >=20 >=20 >=20 > -------------------------------------------------------------------= ----- >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core