From cabo@tzi.org Thu Jul 1 00:41:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD993A67C3 for ; Thu, 1 Jul 2010 00:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.937 X-Spam-Level: X-Spam-Status: No, score=-4.937 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10YU+zicJesB for ; Thu, 1 Jul 2010 00:41:58 -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 B5EB13A679F for ; Thu, 1 Jul 2010 00:41:57 -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 o617g1AB021162; Thu, 1 Jul 2010 09:42:01 +0200 (CEST) Received: from [192.168.217.101] (p5489F311.dip.t-dialin.net [84.137.243.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 82A65B54F; Thu, 1 Jul 2010 09:42:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> Date: Thu, 1 Jul 2010 09:42:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <63585732-52DD-4801-92AF-3974F29C9EB9@tzi.org> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> To: Vipul Gupta X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 07:41:59 -0000 Vipul, the short answer is that we are chartered to do what we are doing. A slightly longer answer is that there are two approaches: "shoehorn = everything so it kind of works with HTTP" and "do what we actually = need". If you look at things like webhooks, these are dominated by = considerations of the first kind, with little attempt at actually = getting the architecture right. Do we waste time by creating a simple protocol? I know that we can = waste a lot of time by shoehorning an existing protocol into a space = that it wasn't designed for. Compression means you still have all the = complexity, the unexpected interactions, ... The comparison to WAP is useful. How did that fail? It started out as = this cute thing to do Web-like GUI apps over SMS. Only gradually did it creep into its "Mobile web replacement" role. And = invented its own content format. If we were doing another Web replacement here in CoRE, I'd indeed run = away as fast as I can. CoRE is about M2M. Gruesse, Carsten From cabo@tzi.org Thu Jul 1 00:52: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 A61C83A683C for ; Thu, 1 Jul 2010 00:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.675 X-Spam-Level: X-Spam-Status: No, score=-5.675 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhbFGLhiVJXr for ; Thu, 1 Jul 2010 00:52:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 828903A67BD for ; Thu, 1 Jul 2010 00:52:35 -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 o617qckS026753; Thu, 1 Jul 2010 09:52:38 +0200 (CEST) Received: from [192.168.217.101] (p5489F311.dip.t-dialin.net [84.137.243.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 6C189B560; Thu, 1 Jul 2010 09:52:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <45CA14FF-78D0-432D-AD03-CC4C68360DB1@sensinode.com> Date: Thu, 1 Jul 2010 09:52:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9059110F-0D69-4519-ACAD-D36D9887086E@tzi.org> References: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> <066.b7025225d8e17c1a85e060f68a8588f5@tools.ietf.org> <05C6A38D732F1144A8C4016BA4416BFE02F97B12@SPO-EXVS-02.itron.com> <882A03D5-CD6F-4B22-A33D-B02CD5C31F5D@tzi.org> <45CA14FF-78D0-432D-AD03-CC4C68360DB1@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: Michael Stuber , core Subject: Re: [core] #6: Date option text needs update 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 Jul 2010 07:52:36 -0000 On Jul 1, 2010, at 08:23, Zach Shelby wrote: > How about we move the date option out of coap-xx and into coap-misc = while we are pondering this? I would like to keep only the options we = are really sure about in the base spec. How does that sound? I had exactly the same thought. I also agree with Szymon that we should investigate relative dates. =20 Max-age already goes in that direction. (See also 14.18.1 in 2616, which is unchanged in 9.3.1 in = draft-ietf-httpbis-p1-messaging-09.txt.) Gruesse, Carsten From hgs@cs.columbia.edu Thu Jul 1 00:56:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74233A67BD for ; Thu, 1 Jul 2010 00:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 AyQZp+ipqAxi for ; Thu, 1 Jul 2010 00:56:32 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 0C0F23A679F for ; Thu, 1 Jul 2010 00:56:31 -0700 (PDT) Received: from dyn2060.panoulu.local (gw1.panoulu.net [212.50.147.101]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id o617ue5W014535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Jul 2010 03:56:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <9059110F-0D69-4519-ACAD-D36D9887086E@tzi.org> Date: Thu, 1 Jul 2010 03:56:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <708CE90E-2F3C-4BE5-BFCC-1AE1B866D3F8@cs.columbia.edu> References: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> <066.b7025225d8e17c1a85e060f68a8588f5@tools.ietf.org> <05C6A38D732F1144A8C4016BA4416BFE02F97B12@SPO-EXVS-02.itron.com> <882A03D5-CD6F-4B22-A33D-B02CD5C31F5D@tzi.org> <45CA14FF-78D0-432D-AD03-CC4C68360DB1@sensinode.com> <9059110F-0D69-4519-ACAD-D36D9887086E@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: Michael Stuber , core Subject: Re: [core] #6: Date option text needs update 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 Jul 2010 07:56:33 -0000 Since there can be a non-trivial (multiple seconds, if the MAC layer is = uncooperative) delay between request sending and response, I think = relative dates are not so useful. On Jul 1, 2010, at 3:52 AM, Carsten Bormann wrote: > On Jul 1, 2010, at 08:23, Zach Shelby wrote: >=20 >> How about we move the date option out of coap-xx and into coap-misc = while we are pondering this? I would like to keep only the options we = are really sure about in the base spec. How does that sound? >=20 > I had exactly the same thought. >=20 > I also agree with Szymon that we should investigate relative dates. =20= > Max-age already goes in that direction. > (See also 14.18.1 in 2616, which is unchanged in 9.3.1 in = draft-ietf-httpbis-p1-messaging-09.txt.) >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From cabo@tzi.org Thu Jul 1 01:22:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764933A688A for ; Thu, 1 Jul 2010 01:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjjqL31AOmMQ for ; Thu, 1 Jul 2010 01:22:04 -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 2E2843A683C for ; Thu, 1 Jul 2010 01:22:02 -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 o618LxD4013168; Thu, 1 Jul 2010 10:21:59 +0200 (CEST) Received: from [192.168.217.101] (p5489F311.dip.t-dialin.net [84.137.243.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id D2A0DB5A8; Thu, 1 Jul 2010 10:21:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <708CE90E-2F3C-4BE5-BFCC-1AE1B866D3F8@cs.columbia.edu> Date: Thu, 1 Jul 2010 10:21:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <007D0BC3-0811-4AEA-9B38-9E9CD22F7B29@tzi.org> References: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> <066.b7025225d8e17c1a85e060f68a8588f5@tools.ietf.org> <05C6A38D732F1144A8C4016BA4416BFE02F97B12@SPO-EXVS-02.itron.com> <882A03D5-CD6F-4B22-A33D-B02CD5C31F5D@tzi.org> <45CA14FF-78D0-432D-AD03-CC4C68360DB1@sensinode.com> <9059110F-0D69-4519-ACAD-D36D9887086E@tzi.org> <708CE90E-2F3C-4BE5-BFCC-1AE1B866D3F8@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1081) Cc: Michael Stuber , core Subject: Re: [core] #6: Date option text needs update 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 Jul 2010 08:22:06 -0000 On Jul 1, 2010, at 09:56, Henning Schulzrinne wrote: > Since there can be a non-trivial (multiple seconds, if the MAC layer = is uncooperative) delay between request sending and response, I think = relative dates are not so useful. Probably not on the time scale of seconds. More so for minutes, hours, = days. (Section 13.3.3 of RFC 2616 mentions a time constant of 60 seconds, = introduced there to handle clock skew *within* a server. Lots of fun.) Gruesse, Carsten From salvatore.loreto@ericsson.com Thu Jul 1 02:35: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 AC1373A67E5 for ; Thu, 1 Jul 2010 02:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.819 X-Spam-Level: X-Spam-Status: No, score=-3.819 tagged_above=-999 required=5 tests=[AWL=0.921, BAYES_20=-0.74, 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 j1HpEcl9jZdt for ; Thu, 1 Jul 2010 02:35:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 14CD83A67C3 for ; Thu, 1 Jul 2010 02:35:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-76-4c2c61697548 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 06.24.10125.9616C2C4; Thu, 1 Jul 2010 11:35:38 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 11:35:37 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 11:35:37 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 557D52372 for ; Thu, 1 Jul 2010 12:35:37 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1CE1C4FBB0 for ; Thu, 1 Jul 2010 12:35:37 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 98D364FBA3 for ; Thu, 1 Jul 2010 12:35:36 +0300 (EEST) Message-ID: <4C2C6168.4050102@ericsson.com> Date: Thu, 01 Jul 2010 11:35:36 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: core@ietf.org References: <20100607145200.988943A69B1@core3.amsl.com> <4DCE9944-2826-4360-AD52-ACA80695A793@sensinode.com> In-Reply-To: <4DCE9944-2826-4360-AD52-ACA80695A793@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 01 Jul 2010 09:35:37.0585 (UTC) FILETIME=[C333FE10:01CB1900] X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-coap-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: Thu, 01 Jul 2010 09:35:28 -0000 section 2.1.5 Transaction IDs states that the initial Transaction ID should be randomized and then changed for each new request/notify, but it does not define how it should be changed. still randomized or in an incremental way? /Sal On 6/7/10 5:00 PM, Zach Shelby wrote: > Hi, > > http://www.ietf.org/id/draft-ietf-core-coap-00.txt > > A new version of the (now working group) document for CoAP has been posted (note it became -00 again as it now has a draft-ietf name). We integrated a bunch of editorial comments, removed the TCP binding, removed the Magic Byte header and Uri-Code for now, and marked the Sub/Notify feature as Experimental while we are discussing the new design in the WG. Managed to make a doc a couple pages shorter ;-) Next step is to make WG trac tickets for all the open issues and TODOs, these we should plan to close by the next release of the doc planned for the end of June. > > Changes from shelby-01 to ietf-00: > > o Removed the TCP binding section, left open for the future. > > o Fixed a bug in the example. > > o Marked current Sub/Notify as (Experimental) while under WG > discussion. > > o Temporarily removed the Magic Byte header as TCP is no longer > included as a binding. > > o Removed the Uri-code Option as different URI encoding schemes > are being discussed. > > o Changed the rel= field to desc= for resource discovery. > > o Changed the maximum message size to 1024 bytes to allow for IP/ > UDP headers. > > o Made the URI slash optimization and method impotence MUSTs > > o Minor editing and bug fixing. > > > Begin forwarded message: > > >> From: IETF I-D Submission Tool >> Date: June 7, 2010 5:52:00 PM GMT+03:00 >> To: zach@sensinode.com >> Cc: brian@skyfoundry.com,d.sturek@att.net >> Subject: New Version Notification for draft-ietf-core-coap-00 >> >> >> A new version of I-D, draft-ietf-core-coap-00.txt has been successfully submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: draft-ietf-core-coap >> Revision: 00 >> Title: Constrained Application Protocol (CoAP) >> Creation_date: 2010-06-07 >> WG ID: core >> Number_of_pages: 30 >> >> Abstract: >> This document specifies the Constrained Application Protocol (CoAP), >> a specialized transfer protocol for use with constrained networks and >> nodes for machine-to-machine applications such as smart energy and >> building automation. These constrained nodes often have 8-bit >> microcontrollers with small amounts of ROM and RAM, while networks >> such as 6LoWPAN often have high packet error rates and typical >> throughput of 10s of kbit/s. CoAP provides request/reply and >> subscribe/notify interaction models between application end-points, >> supports built-in resource discovery, and includes key web concepts >> such as URIs and RESTful methods. CoAP easily translates to HTTP for >> integration with the web while meeting specialized requirements such >> as multicast support, very low overhead and simplicity for >> constrained environments. >> >> >> >> The IETF Secretariat. >> >> >> > -- Salvatore Loreto www.sloreto.com From cabo@tzi.org Thu Jul 1 03:17: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 AFA5A3A680F for ; Thu, 1 Jul 2010 03:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73bbO9jjD1Yz for ; Thu, 1 Jul 2010 03:17:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1686B3A6848 for ; Thu, 1 Jul 2010 03:17:11 -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 o61AHDv3017631; Thu, 1 Jul 2010 12:17:13 +0200 (CEST) Received: from [192.168.217.101] (p5489E521.dip.t-dialin.net [84.137.229.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id C254CB688; Thu, 1 Jul 2010 12:17:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <45CA14FF-78D0-432D-AD03-CC4C68360DB1@sensinode.com> Date: Thu, 1 Jul 2010 12:17:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> <066.b7025225d8e17c1a85e060f68a8588f5@tools.ietf.org> <05C6A38D732F1144A8C4016BA4416BFE02F97B12@SPO-EXVS-02.itron.com> <882A03D5-CD6F-4B22-A33D-B02CD5C31F5D@tzi.org> <45CA14FF-78D0-432D-AD03-CC4C68360DB1@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: Michael Stuber , core Subject: Re: [core] #6: Date option text needs update 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 Jul 2010 10:17:18 -0000 On Jul 1, 2010, at 08:23, Zach Shelby wrote: > move the date option out of coap-xx and into coap-misc=20 I just submitted a coap-misc-03 with text about options related to = absolute time, which also describes what I think the experimental Date = option is in coap-00. Gruesse, Carsten From zach@sensinode.com Thu Jul 1 04:05:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2163A6870 for ; Thu, 1 Jul 2010 04:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.776, 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 PAHDMYUsH950 for ; Thu, 1 Jul 2010 04:05:41 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id AAAEE3A6875 for ; Thu, 1 Jul 2010 04:05:40 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o61B5kDc026728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Jul 2010 14:05:47 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C2C6168.4050102@ericsson.com> Date: Thu, 1 Jul 2010 14:05:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100607145200.988943A69B1@core3.amsl.com> <4DCE9944-2826-4360-AD52-ACA80695A793@sensinode.com> <4C2C6168.4050102@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-coap-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: Thu, 01 Jul 2010 11:05:42 -0000 Hi, On Jul 1, 2010, at 12:35 PM, Salvatore Loreto wrote: > section 2.1.5 Transaction IDs states that the initial Transaction ID = should be randomized and then changed for each new request/notify, > but it does not define how it should be changed. still randomized or = in an incremental way? That is up to the implementation, you could do it either way. We do need = to improve the text describing how long you need to wait before re-using = old IDs however... Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From szymon.sasin@sensinode.com Thu Jul 1 04:24:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3AE3A6849 for ; Thu, 1 Jul 2010 04:24:29 -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 Vt+YUge8-Htp for ; Thu, 1 Jul 2010 04:24: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 70A723A6870 for ; Thu, 1 Jul 2010 04:24:27 -0700 (PDT) Received: from [192.168.0.65] (82-128-196-163-Torikatu-TR1.suomi.net [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o61BOXl5028761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jul 2010 14:24:35 +0300 Message-ID: <4C2C7AF7.6090209@sensinode.com> Date: Thu, 01 Jul 2010 14:24:39 +0300 From: Szymon User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Zach Shelby References: <20100607145200.988943A69B1@core3.amsl.com> <4DCE9944-2826-4360-AD52-ACA80695A793@sensinode.com> <4C2C6168.4050102@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-coap-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: Thu, 01 Jul 2010 11:24:29 -0000 On 1.7.2010 14:05, Zach Shelby wrote: > Hi, > > On Jul 1, 2010, at 12:35 PM, Salvatore Loreto wrote: > > >> section 2.1.5 Transaction IDs states that the initial Transaction ID should be randomized and then changed for each new request/notify, >> but it does not define how it should be changed. still randomized or in an incremental way? >> > That is up to the implementation, you could do it either way. We do need to improve the text describing how long you need to wait before re-using old IDs however... > Time for re-use ID could be calculated from formula: RESPONSE_TIMEOUT * (2 ^ MAX_RETRANSMIT - 1) Which would make sure that during possible retransmissions there is no new message with same tid. In case of 1s timeout and 5 retransmissions it gives 31 seconds. Szymon > Zach > > From zach@sensinode.com Thu Jul 1 04:25:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC80E3A6870 for ; Thu, 1 Jul 2010 04:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8ZP7MoeEaxa for ; Thu, 1 Jul 2010 04:25:41 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CC5E03A6826 for ; Thu, 1 Jul 2010 04:25:37 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o61BPkxI028872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Jul 2010 14:25:46 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <63585732-52DD-4801-92AF-3974F29C9EB9@tzi.org> Date: Thu, 1 Jul 2010 14:25:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <63585732-52DD-4801-92AF-3974F29C9EB9@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org, Vipul Gupta Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 11:25:42 -0000 Hi Vipul, When you start compressing and hacking HTTP, it is not HTTP anymore. = HTTP is one particular design of a web transfer protocol. As we saw from = the Chopan work, the end result from "compressing" HTTP ends up looking = a lot like CoAP. This is why we cooperated on designing CoAP. The = conclusion we came to when chartering is that defining a clean subset of = REST functionality specifically for M2M use is the right path, and = rather than pretending it was called HTTP and getting stuck with all its = complexity and pitfalls - we gave it its own name and limited the = feature set. Really this is just about naming - we could have called it = eHTTP or lightHTTP or M2M-HTTP - but yuck...=20 In the end both CoAP and HTTP are part of the web architecture, use the = same REST primitives and CoAP supports a small subset of HTTP response = codes along with content-types. So as Tom said, CoAP < HTTP. But at the = same time CoAP =3D M2M while HTTP =3D Web. There is a big difference in = the interaction models between a web browser and web server, and = autonomous embedded devices (Smart Energy, Building Automation etc.). = The asynchronous nature of those interactions, multicast, along with the = use of UDP take a lot more tweaking than just sticking HTTP on top of = UDP. SoAP-over-UDP is a good example... That said, coap-01 is aiming at still cleaner integration with the rest = of the web, while making the header and implementation still simpler. We = are also working on a subscription technique in coap-observe which = doesn't add any new methods (and doesn't require funky application layer = stuff), and will allow easy integration with things like HTTP Long Poll, = Webhooks, SIP etc. via a proxy. So hang in there! Zach On Jul 1, 2010, at 10:42 AM, Carsten Bormann wrote: > Vipul, >=20 > the short answer is that we are chartered to do what we are doing. >=20 > A slightly longer answer is that there are two approaches: "shoehorn = everything so it kind of works with HTTP" and "do what we actually = need". If you look at things like webhooks, these are dominated by = considerations of the first kind, with little attempt at actually = getting the architecture right. >=20 > Do we waste time by creating a simple protocol? I know that we can = waste a lot of time by shoehorning an existing protocol into a space = that it wasn't designed for. Compression means you still have all the = complexity, the unexpected interactions, ... >=20 > The comparison to WAP is useful. How did that fail? It started out = as this cute thing to do Web-like GUI apps over SMS. > Only gradually did it creep into its "Mobile web replacement" role. = And invented its own content format. > If we were doing another Web replacement here in CoRE, I'd indeed run = away as fast as I can. CoRE is about M2M. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pab@peoplepowerco.com Thu Jul 1 05:22:46 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 B232128C182 for ; Thu, 1 Jul 2010 05:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auLxZK06ER3K for ; Thu, 1 Jul 2010 05:22:45 -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 7DD813A69C6 for ; Thu, 1 Jul 2010 05:19:49 -0700 (PDT) Received: by vws14 with SMTP id 14so677798vws.31 for ; Thu, 01 Jul 2010 05:17:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.121.210 with SMTP id i18mr5684718vcr.8.1277986665943; Thu, 01 Jul 2010 05:17:45 -0700 (PDT) Received: by 10.220.105.137 with HTTP; Thu, 1 Jul 2010 05:17:45 -0700 (PDT) In-Reply-To: <45CA14FF-78D0-432D-AD03-CC4C68360DB1@sensinode.com> References: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> <066.b7025225d8e17c1a85e060f68a8588f5@tools.ietf.org> <05C6A38D732F1144A8C4016BA4416BFE02F97B12@SPO-EXVS-02.itron.com> <882A03D5-CD6F-4B22-A33D-B02CD5C31F5D@tzi.org> <45CA14FF-78D0-432D-AD03-CC4C68360DB1@sensinode.com> Date: Thu, 1 Jul 2010 07:17:45 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=001636d34ceb4051bd048a5275a4 Cc: Michael Stuber , core Subject: Re: [core] #6: Date option text needs update 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 Jul 2010 12:22:46 -0000 --001636d34ceb4051bd048a5275a4 Content-Type: text/plain; charset=ISO-8859-1 +1 On Thu, Jul 1, 2010 at 1:23 AM, Zach Shelby wrote: > > On Jul 1, 2010, at 2:41 AM, Carsten Bormann wrote: > > > On Jul 1, 2010, at 00:00, Peter Bigot wrote: > > > >> I recently moved, and my copy of Fielding's dissertation is in a box > somewhere, > > > > http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm > > > > It is not quite clear to me whether the CoAP Date option wants to be an > HTTP Date header (14.18 in 2616, 9.3 in > draft-ietf-httpbis-p1-messaging-09.txt) or a Last-Modified header (14.29 in > 2616, 6.6 in draft-ietf-httpbis-p4-conditional-09.txt). > > > > I think the latter may have been intended. > > > > Which one/what do we need? HTTP has both for a reason. Can we live with > just one? A different one? > > Or do we need one at all? > > As this seems to be an experimental subject at this point, and I am not > really sure if anybody is going to use this in real constrained devices. How > about we move the date option out of coap-xx and into coap-misc while we are > pondering this? I would like to keep only the options we are really sure > about in the base spec. How does that sound? > > Zach > > > > > Gruesse, Carsten > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > --001636d34ceb4051bd048a5275a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Thu, Jul 1, 2010 at 1:23 AM, Zach S= helby <zach@sens= inode.com> wrote:

On Jul 1, 2010, at 2:41 AM, Carsten Bormann wrote:

> On Jul 1, 2010, at 00:00, Peter Bigot wrote:
>
>> I recently moved, and my copy of Fielding's dissertation is in= a box somewhere,
>
> http://www.ics.uci.edu/~fielding/pubs/dissertation/top= .htm
>
> It is not quite clear to me whether the CoAP Date option wants to be a= n HTTP Date header (14.18 in 2616, 9.3 in draft-ietf-httpbis-p1-messaging-0= 9.txt) or a Last-Modified header (14.29 in 2616, 6.6 in draft-ietf-httpbis-= p4-conditional-09.txt).
>
> I think the latter may have been intended.
>
> Which one/what do we need? =A0HTTP has both for a reason. =A0Can we li= ve with just one? =A0A different one?

Or do we need one at all?

As this seems to be an experimental subject at this point, and I am not rea= lly sure if anybody is going to use this in real constrained devices. How a= bout we move the date option out of coap-xx and into coap-misc while we are= pondering this? I would like to keep only the options we are really sure a= bout in the base spec. How does that sound?

Zach

>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

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


--001636d34ceb4051bd048a5275a4-- From robby.simpson@ge.com Thu Jul 1 12:29:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B573A6A45 for ; Thu, 1 Jul 2010 12:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 9p8OuIlpfiPB for ; Thu, 1 Jul 2010 12:29:03 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by core3.amsl.com (Postfix) with ESMTP id B5FBF3A6A39 for ; Thu, 1 Jul 2010 12:29:02 -0700 (PDT) Received: from source ([12.71.149.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKTCzsb0/sZ562z+zJKE37Hn344URjJrzl@postini.com; Thu, 01 Jul 2010 12:29:14 PDT Received: from unknown (HELO ALPMLEF02.e2k.ad.ge.com) ([3.159.18.11]) by Cinmlip09.e2k.ad.ge.com with ESMTP; 01 Jul 2010 15:28:46 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.50]) by ALPMLEF02.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 15:28:46 -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: Thu, 1 Jul 2010 15:28:45 -0400 Message-ID: In-Reply-To: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoRE v/s Compressed HTTP Thread-Index: AcsY6ipjnwFMWIR1QF2b0ykbkdOWUwAaC2kw References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> From: "Simpson, Robby (GE Energy Services)" To: X-OriginalArrivalTime: 01 Jul 2010 19:28:46.0091 (UTC) FILETIME=[9F9B0DB0:01CB1953] Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 19:29:04 -0000 Hi Vipul, You are not alone -- I too have been wondering why compressed HTTP was taken off of the table from the very start. A couple themes I continuously hear are: - "HTTP is complex" -- I disagree with this one. The vast majority of what is possible with HTTP is not required and can be safely ignored. Further, I have a feeling use cases will be found in certain scenarios that will lead CoRE to needing that 'complexity' again for those use cases. - "CoRE is about M2M" -- HTTP is also used for M2M - quite a lot in fact! I doubt I need to list the plethora of examples that exist. Specifically trying to create compressed HTTP instead of starting from scratch will, IMO, end the concerns with HTTP mapping, lead to a protocol that will likely be useful outside of extremely constrained devices, and help prevent CoRE from creating something that is alienated from the rest of the Web. - Robby -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Vipul Gupta Sent: Thursday, July 01, 2010 2:54 AM To: core@ietf.org Cc: Vipul Gupta Subject: [core] CoRE v/s Compressed HTTP I've been following the mailing list discussion for some time now and even after reading through draft-ietf-core-coap-00, I'm unable to see=20 the compelling justification for a brand new protocol over using=20 compressed HTTP as a starting point which is what Brian's original=20 draft (http://tools.ietf.org/html/draft-frank-6lowapp-chopan-00) did.=20 I can't help but feel an uneasy sense a Deja Vu. I'm reminded of the=20 early days of the WAP forum which initially took the stance that=20 "standard" Internet protocols were too heavyweight for phones and set=20 about defining its own set of incompatible protocols. I'm particularly=20 aware of the security work where the forum defined WTLS as a "wireless"=20 version of TLS (the resuse of the TLS acronym seemed like a marketing=20 ploy because the two protocols were incompatible and some of the=20 incompatibilities introduced security vulnerabilities in WTLS). Our=20 work at Sun Labs on SSL/TLS for small devices (Palm PDAs and subsequently sensor nodes as small as the Berkeley mote[1][2]) showed otherwise. We=20 demonstrated that one could profile SSL/TLS appropriately so it could=20 still be used on the wireless devices of the day while maintaining=20 compatibility with the large majority of existing deployments. Eventually,=20 the right thing to do turned out to be the incorporation of Elliptic=20 Curve Cryptography (ECC) the public key cryptosystem used in WTLS,=20 into TLS (RFC 4492). This is now implemented in OpenSSL/Apache and=20 Firefox, IE and offers meaningful performance benefits even for=20 regular/unconstrained hosts [3]. I see strong parallels between adding ECC key exchange to TLS and=20 defining header compression for HTTP. I wonder whether there would=20 still be a place for COAP as currently defined if compressed HTTP=20 were to become a standard. To me, the following seems like a better=20 approach: - Define header compression for HTTP which has the potential of being=20 very useful even for regular/unconstrained browsers and servers=20 interacting over TCP (Note that HTTP header compression is an=20 important component of SPDY, http://en.wikipedia.org/wiki/SPDY). - Define a profile for compressed HTTP to be used in COAP, e.g.=20 subset of headers to be supported, restrictions on the size of=20 compressed messages so they can be carried over UDP, nailing=20 down the content of specific messages like subscriptions/ notifications and check-in (as in the chopan=20 draft). The Webhooks approach (http://webhooks.org,=20 http://wiki.webhooks.org/RESTful-WebHooks) seems clean=20 and simple but certain aspects of subscriptions/notifications are=20 currently underspecified. - Define how to carry compressed HTTP over UDP, e.g. handling of=20 retransmissions, congestion control, transaction IDs, etc This approach seems to have several advantages -- it makes HTTP mapping=20 easier, frees up the WG to devote its time to other important issues=20 (nailing down the content of subscription/notification messages,=20 discovery etc), and once regular browsers and servers adopt HTTP header=20 compression (Chrome already seems to have some support for this) it=20 makes true end-to-end security between COAP devices and the existing=20 Web a real possibility. Am I alone in feeling this way? What am I missing? vipul --- http://labs.oracle.com/people/mybio.php?uid=3D32495 [1] http://www.cs.plu.edu/courses/netsec/arts/coms.pdf [2] http://cents.cs.berkeley.edu/retreats/winter_2005/SSL_on_motes.pdf [3] http://labs.oracle.com/projects/crypto/ecc-ssl-ndss2004.pdf _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From richard.kelsey@ember.com Thu Jul 1 13:12: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 7B3F23A67B1 for ; Thu, 1 Jul 2010 13:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=-1.367, 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 ScSwwK-m5z7c for ; Thu, 1 Jul 2010 13:12:42 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 286333A6907 for ; Thu, 1 Jul 2010 13:12:42 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 16:12:53 -0400 Date: Thu, 01 Jul 2010 16:18:56 -0400 Message-Id: <87wrtfrm4v.fsf@kelsey-ws.hq.ember.com> To: "Simpson, Robby (GE Energy Services)" In-reply-to: (robby.simpson@ge.com) From: Richard Kelsey References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> X-OriginalArrivalTime: 01 Jul 2010 20:12:53.0365 (UTC) FILETIME=[C9810250:01CB1959] Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 20:12:43 -0000 Hi Robby, I am wondering what you see as the important differences between CoRE and compressed HTTP. Assuming that CoRE continues down its current path and also delivers on having a simple CoRE<->HTTP mapping, why wouldn't you consider the result compressed HTTP? It seems to me that most of the discussion on the CoRE lists falls into two categories: - exactly what HTTP functionality is required by the use cases - how to do subscription and notification The same discussions would be occuring, if in a slightly different form, if CoRE had decided to call what they were doing "compressed HTTP". -Richard Kelsey From zach@sensinode.com Thu Jul 1 13:13: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 8FDA63A6907 for ; Thu, 1 Jul 2010 13:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 S4q1ijP+-JpW for ; Thu, 1 Jul 2010 13:13:01 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 412373A67B1 for ; Thu, 1 Jul 2010 13:13:00 -0700 (PDT) Received: from [192.168.1.3] (line-5712.dyn.kponet.fi [85.29.68.165]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o61KD0xR025299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Jul 2010 23:13:01 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Thu, 1 Jul 2010 23:13:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> To: "Simpson, Robby (GE Energy Services)" X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 20:13:03 -0000 Hi Robby, We are actually agreeing. If you go and binary compress HTTP, hack away = the features not needed for our requirements etc. - you end up with = something that looks very much like CoAP (when we are done).=20 This WG simply made the decision not to call this thing HTTP and to set = a limited set of features and requirements to design for explicitly. The = IETF ADs clearly told us that trying to hack HTTP would be a = standardization nightmare and that production HTTP is much more complex = than it seems.=20 The charter goal is explicitly to make a RESTful protocol, which is part = of the web architecture. By no means did CoAP start from scratch, we = started with Chopan and the application requirements given to us. I = think we've made this more controversial than needed? The biggest = challenge (and difference from HTTP) we have to deal with are = asynchronous transactions over UDP, Chopan had to deal with the same = thing. We also have some requirements that differ clearly from HTTP - we = need to achieve those with REST. If you want to call CoAP a kind of compressed HTTP then go for it! As = CoAP is going to be 100% REST compatible and supports a subset of = application layer HTTP features this is very much part of the web (CoAP = < HTTP). In coap-01 we have also been able to better separate the UDP = transaction issues from REST, which will allow us to do e.g. = subscription without any new methods. coap-01 will also have no problems = with HTTP mapping. So we are getting there. So if it is just the name in the end that is the problem - then why = don't we change the name? Works for me. =20 - Embedded HTTP - Constrained HTTP=20 - Binary HTTP - Compressed HTTP - Constrained REST - M2M HTTP - M2M REST Zach On Jul 1, 2010, at 10:28 PM, Simpson, Robby (GE Energy Services) wrote: > Hi Vipul, >=20 > You are not alone -- I too have been wondering why compressed HTTP was > taken off of the table from the very start. >=20 > A couple themes I continuously hear are: >=20 > - "HTTP is complex" -- I disagree with this one. The vast majority of > what is possible with HTTP is not required and can be safely ignored. > Further, I have a feeling use cases will be found in certain scenarios > that will lead CoRE to needing that 'complexity' again for those use > cases. >=20 > - "CoRE is about M2M" -- HTTP is also used for M2M - quite a lot in > fact! I doubt I need to list the plethora of examples that exist. >=20 > Specifically trying to create compressed HTTP instead of starting from > scratch will, IMO, end the concerns with HTTP mapping, lead to a > protocol that will likely be useful outside of extremely constrained > devices, and help prevent CoRE from creating something that is = alienated > from the rest of the Web. >=20 > - Robby >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Vipul Gupta > Sent: Thursday, July 01, 2010 2:54 AM > To: core@ietf.org > Cc: Vipul Gupta > Subject: [core] CoRE v/s Compressed HTTP >=20 > I've been following the mailing list discussion for some time now and > even after reading through draft-ietf-core-coap-00, I'm unable to see=20= > the compelling justification for a brand new protocol over using=20 > compressed HTTP as a starting point which is what Brian's original=20 > draft (http://tools.ietf.org/html/draft-frank-6lowapp-chopan-00) did.=20= >=20 > I can't help but feel an uneasy sense a Deja Vu. I'm reminded of the=20= > early days of the WAP forum which initially took the stance that=20 > "standard" Internet protocols were too heavyweight for phones and set=20= > about defining its own set of incompatible protocols. I'm particularly=20= > aware of the security work where the forum defined WTLS as a = "wireless"=20 > version of TLS (the resuse of the TLS acronym seemed like a marketing=20= > ploy because the two protocols were incompatible and some of the=20 > incompatibilities introduced security vulnerabilities in WTLS). Our=20 > work at Sun Labs on SSL/TLS for small devices (Palm PDAs and > subsequently > sensor nodes as small as the Berkeley mote[1][2]) showed otherwise. We=20= > demonstrated that one could profile SSL/TLS appropriately so it could=20= > still be used on the wireless devices of the day while maintaining=20 > compatibility with the large majority of existing deployments. > Eventually,=20 > the right thing to do turned out to be the incorporation of Elliptic=20= > Curve Cryptography (ECC) the public key cryptosystem used in WTLS,=20 > into TLS (RFC 4492). This is now implemented in OpenSSL/Apache and=20 > Firefox, IE and offers meaningful performance benefits even for=20 > regular/unconstrained hosts [3]. >=20 > I see strong parallels between adding ECC key exchange to TLS and=20 > defining header compression for HTTP. I wonder whether there would=20 > still be a place for COAP as currently defined if compressed HTTP=20 > were to become a standard. To me, the following seems like a better=20 > approach: >=20 > - Define header compression for HTTP which has the potential of being=20= > very useful even for regular/unconstrained browsers and servers=20 > interacting over TCP (Note that HTTP header compression is an=20 > important component of SPDY, http://en.wikipedia.org/wiki/SPDY). >=20 > - Define a profile for compressed HTTP to be used in COAP, e.g.=20 > subset of headers to be supported, restrictions on the size of=20 > compressed messages so they can be carried over UDP, nailing=20 > down the content of specific messages like subscriptions/ > notifications and check-in (as in the chopan=20 > draft). The Webhooks approach (http://webhooks.org,=20 > http://wiki.webhooks.org/RESTful-WebHooks) seems clean=20 > and simple but certain aspects of subscriptions/notifications are=20 > currently underspecified. >=20 > - Define how to carry compressed HTTP over UDP, e.g. handling of=20 > retransmissions, congestion control, transaction IDs, etc >=20 > This approach seems to have several advantages -- it makes HTTP = mapping=20 > easier, frees up the WG to devote its time to other important issues=20= > (nailing down the content of subscription/notification messages,=20 > discovery etc), and once regular browsers and servers adopt HTTP = header=20 > compression (Chrome already seems to have some support for this) it=20 > makes true end-to-end security between COAP devices and the existing=20= > Web a real possibility. >=20 > Am I alone in feeling this way? What am I missing? >=20 > vipul > --- > http://labs.oracle.com/people/mybio.php?uid=3D32495 >=20 > [1] http://www.cs.plu.edu/courses/netsec/arts/coms.pdf > [2] http://cents.cs.berkeley.edu/retreats/winter_2005/SSL_on_motes.pdf > [3] http://labs.oracle.com/projects/crypto/ecc-ssl-ndss2004.pdf > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From d.sturek@att.net Thu Jul 1 13:32: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 4043B3A6809 for ; Thu, 1 Jul 2010 13:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.285 X-Spam-Level: ** X-Spam-Status: No, score=2.285 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_44=1, 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 4cMKhDcuhFYv for ; Thu, 1 Jul 2010 13:32:47 -0700 (PDT) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id CA41F3A677C for ; Thu, 1 Jul 2010 13:32:44 -0700 (PDT) Received: (qmail 32719 invoked from network); 1 Jul 2010 20:32:53 -0000 Received: from 65-122-15-169.dia.static.qwest.net (d.sturek@65.122.15.169 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 01 Jul 2010 13:32:52 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: hBVIIOsVM1kspXsFHj3P_ev_LnKbePgaXU8TpfVNa3IngH2HJb5B1VaqZZ04LDzBz9XTH.2w.qSI298mliokRvEo8fd4gdG2zazpnecvl9FyNo0UDxgduwbbPwcfKhbvzc99cZWo_ZZkXMrJMkZ4Xull2Xo5PflbDWo.hdM6GLkhRj3X.SHFGzw0yWl_wxf2ypVySl62p51suTQ0D7O4dJ4V6AnhNwJZt1Fr9y0Id36Ya6UjNampXRlW7hJPnHmiG9QRgInx.6Elgwxk2URsRiRV8H9OMFxDPfQyoBIhMcsVlgMmpUQ- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Richard Kelsey'" , "'Simpson, Robby \(GE Energy Services\)'" References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <87wrtfrm4v.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87wrtfrm4v.fsf@kelsey-ws.hq.ember.com> Date: Thu, 1 Jul 2010 13:32:42 -0700 Message-ID: <006e01cb195c$8f8f2600$aead7200$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsZWc11k9xjpBViSO+uCFEGwa6UxAAAoZiQ Content-Language: en-us Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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: Thu, 01 Jul 2010 20:32:48 -0000 Hi Richard, I think the main difference with compressed HTTP and CoAP/HTTP proxy is that the HTTP session is terminated at the proxy (along with security) and re-generated in CoAP. The HTTP proxy is one thing, however, mapping between TLS/DTLS sessions is another. You also need to be concerned about the type of device that is doing this since the keys on both sessions will be in the clear in the proxy. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Richard Kelsey Sent: Thursday, July 01, 2010 1:19 PM To: Simpson, Robby (GE Energy Services) Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP Hi Robby, I am wondering what you see as the important differences between CoRE and compressed HTTP. Assuming that CoRE continues down its current path and also delivers on having a simple CoRE<->HTTP mapping, why wouldn't you consider the result compressed HTTP? It seems to me that most of the discussion on the CoRE lists falls into two categories: - exactly what HTTP functionality is required by the use cases - how to do subscription and notification The same discussions would be occuring, if in a slightly different form, if CoRE had decided to call what they were doing "compressed HTTP". -Richard Kelsey _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From paduffy@cisco.com Thu Jul 1 13:35: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 71BA23A677C for ; Thu, 1 Jul 2010 13:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.473 X-Spam-Level: X-Spam-Status: No, score=-9.473 tagged_above=-999 required=5 tests=[AWL=1.126, 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 NfJBu3KauKNk for ; Thu, 1 Jul 2010 13:35:24 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BAC073A6809 for ; Thu, 1 Jul 2010 13:35:23 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEqZLExAZnwM/2dsb2JhbACfb3GIHp0cgXoLAYYvkgWCY4JCBIgt X-IronPort-AV: E=Sophos;i="4.53,522,1272844800"; d="scan'208";a="127868397" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2010 20:35:34 +0000 Received: from [161.44.65.101] ([161.44.65.101]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o61KZYw5010033; Thu, 1 Jul 2010 20:35:34 GMT Message-ID: <4C2CFC16.40506@cisco.com> Date: Thu, 01 Jul 2010 16:35:34 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Zach Shelby References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com> In-Reply-To: <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 20:35:25 -0000 Hi Zack, I share Vipul's and Robby's concerns. Recent conversation implied that CORE was headed off the HTTP semantic rails (addition of specific methods for subscription creation, etc.). If that is no longer the case, and STATELESS translation between HTTP and COAP will be possible ... that eases concerns. I'm looking for interchangeability of HTTP/CORE and payload encodings as appropriate for the resource constraints of specific deployments. Cheers On 7/1/2010 4:13 PM, Zach Shelby wrote: > Hi Robby, > > We are actually agreeing. If you go and binary compress HTTP, hack away the features not needed for our requirements etc. - you end up with something that looks very much like CoAP (when we are done). > > This WG simply made the decision not to call this thing HTTP and to set a limited set of features and requirements to design for explicitly. The IETF ADs clearly told us that trying to hack HTTP would be a standardization nightmare and that production HTTP is much more complex than it seems. > > The charter goal is explicitly to make a RESTful protocol, which is part of the web architecture. By no means did CoAP start from scratch, we started with Chopan and the application requirements given to us. I think we've made this more controversial than needed? The biggest challenge (and difference from HTTP) we have to deal with are asynchronous transactions over UDP, Chopan had to deal with the same thing. We also have some requirements that differ clearly from HTTP - we need to achieve those with REST. > > If you want to call CoAP a kind of compressed HTTP then go for it! As CoAP is going to be 100% REST compatible and supports a subset of application layer HTTP features this is very much part of the web (CoAP< HTTP). In coap-01 we have also been able to better separate the UDP transaction issues from REST, which will allow us to do e.g. subscription without any new methods. coap-01 will also have no problems with HTTP mapping. So we are getting there. > > So if it is just the name in the end that is the problem - then why don't we change the name? Works for me. > > - Embedded HTTP > - Constrained HTTP > - Binary HTTP > - Compressed HTTP > - Constrained REST > - M2M HTTP > - M2M REST > > Zach > > On Jul 1, 2010, at 10:28 PM, Simpson, Robby (GE Energy Services) wrote: > > >> Hi Vipul, >> >> You are not alone -- I too have been wondering why compressed HTTP was >> taken off of the table from the very start. >> >> A couple themes I continuously hear are: >> >> - "HTTP is complex" -- I disagree with this one. The vast majority of >> what is possible with HTTP is not required and can be safely ignored. >> Further, I have a feeling use cases will be found in certain scenarios >> that will lead CoRE to needing that 'complexity' again for those use >> cases. >> >> - "CoRE is about M2M" -- HTTP is also used for M2M - quite a lot in >> fact! I doubt I need to list the plethora of examples that exist. >> >> Specifically trying to create compressed HTTP instead of starting from >> scratch will, IMO, end the concerns with HTTP mapping, lead to a >> protocol that will likely be useful outside of extremely constrained >> devices, and help prevent CoRE from creating something that is alienated >> from the rest of the Web. >> >> - Robby >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >> Vipul Gupta >> Sent: Thursday, July 01, 2010 2:54 AM >> To: core@ietf.org >> Cc: Vipul Gupta >> Subject: [core] CoRE v/s Compressed HTTP >> >> I've been following the mailing list discussion for some time now and >> even after reading through draft-ietf-core-coap-00, I'm unable to see >> the compelling justification for a brand new protocol over using >> compressed HTTP as a starting point which is what Brian's original >> draft (http://tools.ietf.org/html/draft-frank-6lowapp-chopan-00) did. >> >> I can't help but feel an uneasy sense a Deja Vu. I'm reminded of the >> early days of the WAP forum which initially took the stance that >> "standard" Internet protocols were too heavyweight for phones and set >> about defining its own set of incompatible protocols. I'm particularly >> aware of the security work where the forum defined WTLS as a "wireless" >> version of TLS (the resuse of the TLS acronym seemed like a marketing >> ploy because the two protocols were incompatible and some of the >> incompatibilities introduced security vulnerabilities in WTLS). Our >> work at Sun Labs on SSL/TLS for small devices (Palm PDAs and >> subsequently >> sensor nodes as small as the Berkeley mote[1][2]) showed otherwise. We >> demonstrated that one could profile SSL/TLS appropriately so it could >> still be used on the wireless devices of the day while maintaining >> compatibility with the large majority of existing deployments. >> Eventually, >> the right thing to do turned out to be the incorporation of Elliptic >> Curve Cryptography (ECC) the public key cryptosystem used in WTLS, >> into TLS (RFC 4492). This is now implemented in OpenSSL/Apache and >> Firefox, IE and offers meaningful performance benefits even for >> regular/unconstrained hosts [3]. >> >> I see strong parallels between adding ECC key exchange to TLS and >> defining header compression for HTTP. I wonder whether there would >> still be a place for COAP as currently defined if compressed HTTP >> were to become a standard. To me, the following seems like a better >> approach: >> >> - Define header compression for HTTP which has the potential of being >> very useful even for regular/unconstrained browsers and servers >> interacting over TCP (Note that HTTP header compression is an >> important component of SPDY, http://en.wikipedia.org/wiki/SPDY). >> >> - Define a profile for compressed HTTP to be used in COAP, e.g. >> subset of headers to be supported, restrictions on the size of >> compressed messages so they can be carried over UDP, nailing >> down the content of specific messages like subscriptions/ >> notifications and check-in (as in the chopan >> draft). The Webhooks approach (http://webhooks.org, >> http://wiki.webhooks.org/RESTful-WebHooks) seems clean >> and simple but certain aspects of subscriptions/notifications are >> currently underspecified. >> >> - Define how to carry compressed HTTP over UDP, e.g. handling of >> retransmissions, congestion control, transaction IDs, etc >> >> This approach seems to have several advantages -- it makes HTTP mapping >> easier, frees up the WG to devote its time to other important issues >> (nailing down the content of subscription/notification messages, >> discovery etc), and once regular browsers and servers adopt HTTP header >> compression (Chrome already seems to have some support for this) it >> makes true end-to-end security between COAP devices and the existing >> Web a real possibility. >> >> Am I alone in feeling this way? What am I missing? >> >> vipul >> --- >> http://labs.oracle.com/people/mybio.php?uid=32495 >> >> [1] http://www.cs.plu.edu/courses/netsec/arts/coms.pdf >> [2] http://cents.cs.berkeley.edu/retreats/winter_2005/SSL_on_motes.pdf >> [3] http://labs.oracle.com/projects/crypto/ecc-ssl-ndss2004.pdf >> _______________________________________________ >> 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 Thu Jul 1 14:09: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 CB7503A691D for ; Thu, 1 Jul 2010 14:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.153 X-Spam-Level: X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 1vnEBce8z61h for ; Thu, 1 Jul 2010 14:09: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 EAA323A67B4 for ; Thu, 1 Jul 2010 14:09:41 -0700 (PDT) Received: from [192.168.1.3] (line-5712.dyn.kponet.fi [85.29.68.165]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o61L8xoE026700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 00:09:00 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C2CFC16.40506@cisco.com> Date: Fri, 2 Jul 2010 00:09:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <594280D3-4024-4548-A54E-8CC3B7AF4759@sensinode.com> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com> <4C2CFC16.40506@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 21:09:43 -0000 Paul, On Jul 1, 2010, at 11:35 PM, Paul Duffy wrote: > Hi Zack, >=20 > I share Vipul's and Robby's concerns. Recent conversation implied = that CORE was headed off the HTTP semantic rails (addition of specific = methods for subscription creation, etc.). If that is no longer the = case, and STATELESS translation between HTTP and COAP will be possible = ... that eases concerns. Correct, coap-01 (and coap-observe) will not add new methods and a = stateless translation is possible.=20 But as Richard pointed out, the same conversations we would be having = with compressed HTTP as well (the original EBHTML proposal had new = methods via GENA e.g.).=20 > I'm looking for interchangeability of HTTP/CORE and payload encodings = as appropriate for the resource constraints of specific deployments. So you mean applying the same web service interface design = interchangeably over HTTP and CoRE? Sure, this is a requirement that = makes sense, although of course HTTP has some limitations due to a lack = of built-in discovery, multicast and subscription. These we can = alleviate by making it easy for HTTP to borrow those paradigms from CoRE = (or use CoRE in the case of multicast). I have already added a section = about that WRT discovery in coap-01. The same should be possible for = subscription. Zach >=20 > Cheers >=20 >=20 > On 7/1/2010 4:13 PM, Zach Shelby wrote: >> Hi Robby, >>=20 >> We are actually agreeing. If you go and binary compress HTTP, hack = away the features not needed for our requirements etc. - you end up with = something that looks very much like CoAP (when we are done). >>=20 >> This WG simply made the decision not to call this thing HTTP and to = set a limited set of features and requirements to design for explicitly. = The IETF ADs clearly told us that trying to hack HTTP would be a = standardization nightmare and that production HTTP is much more complex = than it seems. >>=20 >> The charter goal is explicitly to make a RESTful protocol, which is = part of the web architecture. By no means did CoAP start from scratch, = we started with Chopan and the application requirements given to us. I = think we've made this more controversial than needed? The biggest = challenge (and difference from HTTP) we have to deal with are = asynchronous transactions over UDP, Chopan had to deal with the same = thing. We also have some requirements that differ clearly from HTTP - we = need to achieve those with REST. >>=20 >> If you want to call CoAP a kind of compressed HTTP then go for it! = As CoAP is going to be 100% REST compatible and supports a subset of = application layer HTTP features this is very much part of the web (CoAP< = HTTP). In coap-01 we have also been able to better separate the UDP = transaction issues from REST, which will allow us to do e.g. = subscription without any new methods. coap-01 will also have no problems = with HTTP mapping. So we are getting there. >>=20 >> So if it is just the name in the end that is the problem - then why = don't we change the name? Works for me. >>=20 >> - Embedded HTTP >> - Constrained HTTP >> - Binary HTTP >> - Compressed HTTP >> - Constrained REST >> - M2M HTTP >> - M2M REST >>=20 >> Zach >>=20 >> On Jul 1, 2010, at 10:28 PM, Simpson, Robby (GE Energy Services) = wrote: >>=20 >> =20 >>> Hi Vipul, >>>=20 >>> You are not alone -- I too have been wondering why compressed HTTP = was >>> taken off of the table from the very start. >>>=20 >>> A couple themes I continuously hear are: >>>=20 >>> - "HTTP is complex" -- I disagree with this one. The vast majority = of >>> what is possible with HTTP is not required and can be safely = ignored. >>> Further, I have a feeling use cases will be found in certain = scenarios >>> that will lead CoRE to needing that 'complexity' again for those use >>> cases. >>>=20 >>> - "CoRE is about M2M" -- HTTP is also used for M2M - quite a lot in >>> fact! I doubt I need to list the plethora of examples that exist. >>>=20 >>> Specifically trying to create compressed HTTP instead of starting = from >>> scratch will, IMO, end the concerns with HTTP mapping, lead to a >>> protocol that will likely be useful outside of extremely constrained >>> devices, and help prevent CoRE from creating something that is = alienated >>> from the rest of the Web. >>>=20 >>> - Robby >>>=20 >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >>> Vipul Gupta >>> Sent: Thursday, July 01, 2010 2:54 AM >>> To: core@ietf.org >>> Cc: Vipul Gupta >>> Subject: [core] CoRE v/s Compressed HTTP >>>=20 >>> I've been following the mailing list discussion for some time now = and >>> even after reading through draft-ietf-core-coap-00, I'm unable to = see >>> the compelling justification for a brand new protocol over using >>> compressed HTTP as a starting point which is what Brian's original >>> draft (http://tools.ietf.org/html/draft-frank-6lowapp-chopan-00) = did. >>>=20 >>> I can't help but feel an uneasy sense a Deja Vu. I'm reminded of the >>> early days of the WAP forum which initially took the stance that >>> "standard" Internet protocols were too heavyweight for phones and = set >>> about defining its own set of incompatible protocols. I'm = particularly >>> aware of the security work where the forum defined WTLS as a = "wireless" >>> version of TLS (the resuse of the TLS acronym seemed like a = marketing >>> ploy because the two protocols were incompatible and some of the >>> incompatibilities introduced security vulnerabilities in WTLS). Our >>> work at Sun Labs on SSL/TLS for small devices (Palm PDAs and >>> subsequently >>> sensor nodes as small as the Berkeley mote[1][2]) showed otherwise. = We >>> demonstrated that one could profile SSL/TLS appropriately so it = could >>> still be used on the wireless devices of the day while maintaining >>> compatibility with the large majority of existing deployments. >>> Eventually, >>> the right thing to do turned out to be the incorporation of Elliptic >>> Curve Cryptography (ECC) the public key cryptosystem used in WTLS, >>> into TLS (RFC 4492). This is now implemented in OpenSSL/Apache and >>> Firefox, IE and offers meaningful performance benefits even for >>> regular/unconstrained hosts [3]. >>>=20 >>> I see strong parallels between adding ECC key exchange to TLS and >>> defining header compression for HTTP. I wonder whether there would >>> still be a place for COAP as currently defined if compressed HTTP >>> were to become a standard. To me, the following seems like a better >>> approach: >>>=20 >>> - Define header compression for HTTP which has the potential of = being >>> very useful even for regular/unconstrained browsers and servers >>> interacting over TCP (Note that HTTP header compression is an >>> important component of SPDY, http://en.wikipedia.org/wiki/SPDY). >>>=20 >>> - Define a profile for compressed HTTP to be used in COAP, e.g. >>> subset of headers to be supported, restrictions on the size of >>> compressed messages so they can be carried over UDP, nailing >>> down the content of specific messages like subscriptions/ >>> notifications and check-in (as in the chopan >>> draft). The Webhooks approach (http://webhooks.org, >>> http://wiki.webhooks.org/RESTful-WebHooks) seems clean >>> and simple but certain aspects of subscriptions/notifications are >>> currently underspecified. >>>=20 >>> - Define how to carry compressed HTTP over UDP, e.g. handling of >>> retransmissions, congestion control, transaction IDs, etc >>>=20 >>> This approach seems to have several advantages -- it makes HTTP = mapping >>> easier, frees up the WG to devote its time to other important issues >>> (nailing down the content of subscription/notification messages, >>> discovery etc), and once regular browsers and servers adopt HTTP = header >>> compression (Chrome already seems to have some support for this) it >>> makes true end-to-end security between COAP devices and the existing >>> Web a real possibility. >>>=20 >>> Am I alone in feeling this way? What am I missing? >>>=20 >>> vipul >>> --- >>> http://labs.oracle.com/people/mybio.php?uid=3D32495 >>>=20 >>> [1] http://www.cs.plu.edu/courses/netsec/arts/coms.pdf >>> [2] = http://cents.cs.berkeley.edu/retreats/winter_2005/SSL_on_motes.pdf >>> [3] http://labs.oracle.com/projects/crypto/ecc-ssl-ndss2004.pdf >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> =20 >> =20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Thu Jul 1 14:10:46 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 D13933A6934 for ; Thu, 1 Jul 2010 14:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=-0.920, 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 p0NKoLr1oocs for ; Thu, 1 Jul 2010 14:10:46 -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 66AE13A691D for ; Thu, 1 Jul 2010 14:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o61L9xAs001395; Thu, 1 Jul 2010 23:10:04 +0200 (CEST) Message-Id: <5B079D4D-56EF-42F3-9078-75E239737A51@tzi.org> From: Carsten Bormann To: paduffy@cisco.com In-Reply-To: <4C2CFC16.40506@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Jul 2010 23:09:57 +0200 References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com> <4C2CFC16.40506@cisco.com> X-Mailer: Apple Mail (2.936) Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 21:10:46 -0000 On Jul 01 2010, at 22:35, Paul Duffy wrote: > interchangeability of HTTP/CORE I think we can take from this discussion that there is a strong desire to be able to map HTTP to CoAP and back. (At least those HTTP features that we do want to support.) However, I'm not happy with a restriction that CoAP can not ever do anything that HTTP can't. There are things that are extremely complex in HTTP that should be simple in a REST architecture. In this case, it is the job of the HTTP gateway to manage the complexity, not the job of the CoAP implementation in every single light switch. This is the main philosophical difference between the CoRE approach and "compressed HTTP". Gruesse, Carsten From robby.simpson@ge.com Thu Jul 1 14:13:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0833A695B for ; Thu, 1 Jul 2010 14:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.933, 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 Dl08UIrmHuUf for ; Thu, 1 Jul 2010 14:13:45 -0700 (PDT) Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by core3.amsl.com (Postfix) with ESMTP id 5A9F43A694E for ; Thu, 1 Jul 2010 14:13:45 -0700 (PDT) Received: from source ([12.71.149.1]) (using TLSv1) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKTC0FFPeft9xMycj4XITRferLCrkeRm2o@postini.com; Thu, 01 Jul 2010 14:13:57 PDT Received: from unknown (HELO alpmlef01.e2k.ad.ge.com) ([3.159.18.10]) by Cinmlip06.e2k.ad.ge.com with ESMTP; 01 Jul 2010 17:13:55 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.50]) by alpmlef01.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 17:13:55 -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: Thu, 1 Jul 2010 17:13:54 -0400 Message-ID: In-Reply-To: <87wrtfrm4v.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoRE v/s Compressed HTTP Thread-Index: AcsZWcundwHIsym6Ta6P8TfQeYx8wAAB3HVw References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <87wrtfrm4v.fsf@kelsey-ws.hq.ember.com> From: "Simpson, Robby (GE Energy Services)" To: "Richard Kelsey" X-OriginalArrivalTime: 01 Jul 2010 21:13:55.0711 (UTC) FILETIME=[506EA8F0:01CB1962] Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 21:13:49 -0000 Hi Richard, I think largely it's a matter of goals and scoping, which may or may not change the outcome. For instance, there has been much debate as to whether the same methods will be used between HTTP and the CoRE work. As another example, there has been much debate regarding translation and mapping with an intermediate device. To me, a truly compressed HTTP would be extremely similar to vanilla HTTP and may actually even be preferred in many non-constrained devices (for preservation of bandwidth, etc.). In terms of goals, if we consider ourselves to be creating compressed HTTP, we will look at HTTP and determine how to make it more compact and efficient. If we consider ourselves to be creating something from scratch that can be mapped to HTTP, then we may or may not end up with something that is similar to HTTP and may require a different set of architectures. If, in the end, whatever comes out has that drop-in look and feel, then I don't care what we call it -- to me its not a matter of names. - Robby -----Original Message----- From: Richard Kelsey [mailto:richard.kelsey@ember.com]=20 Sent: Thursday, July 01, 2010 4:19 PM To: Simpson, Robby (GE Energy Services) Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP Hi Robby, I am wondering what you see as the important differences between CoRE and compressed HTTP. Assuming that CoRE continues down its current path and also delivers on having a simple CoRE<->HTTP mapping, why wouldn't you consider the result compressed HTTP? It seems to me that most of the discussion on the CoRE lists falls into two categories: - exactly what HTTP functionality is required by the use cases - how to do subscription and notification The same discussions would be occuring, if in a slightly different form, if CoRE had decided to call what they were doing "compressed HTTP". -Richard Kelsey From gtolle@archrock.com Thu Jul 1 14:19: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 731843A6951 for ; Thu, 1 Jul 2010 14:19:37 -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] 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 YojDjwfM5cc2 for ; Thu, 1 Jul 2010 14:19:35 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 5B6F23A694E for ; Thu, 1 Jul 2010 14:19:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BC2B8AF9A3; Thu, 1 Jul 2010 14:17:51 -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 rcE9mwtl+CWM; Thu, 1 Jul 2010 14:17:48 -0700 (PDT) Received: from [10.0.1.200] (cpe-68-175-12-28.nyc.res.rr.com [68.175.12.28]) by mail.sf.archrock.com (Postfix) with ESMTP id 58F22AF99C; Thu, 1 Jul 2010 14:17:47 -0700 (PDT) Message-Id: <2DFFECBD-0220-4DD2-8CA6-45EF896BC11E@archrock.com> From: Gilman Tolle To: paduffy@cisco.com In-Reply-To: <4C2CFC16.40506@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Jul 2010 17:19:41 -0400 References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com> <4C2CFC16.40506@cisco.com> X-Mailer: Apple Mail (2.936) Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 21:19:37 -0000 +1 on the concerns in this thread, especially as regards interchangeability between HTTP and CoAP. Also, I'd like to be sure that whatever subscription mechanism we end up deciding is the "right" one for CoRE includes a concept similar to an explicit callback URL when making subscriptions. Simply using the source address when accepting a subscription request is rarely sufficient, because the source port is ephemeral, and the client may have chosen an arbitrary port on which to run CoAP and listen for notifications. In addition, explicitly specifying the receiver is necessary if the subscription request is being made through a proxy. I'd also suggest that the mechanism should allow the client to include some information that will be returned to it unchanged in the notification, to help it distinguish between different notifications. In an explicit callback URL, this would be the path component and the query string of the callback URL, but it may also be a simple opaque string. Gil On Jul 1, 2010, at 4:35 PM, Paul Duffy wrote: > Hi Zack, > > I share Vipul's and Robby's concerns. Recent conversation implied > that CORE was headed off the HTTP semantic rails (addition of > specific methods for subscription creation, etc.). If that is no > longer the case, and STATELESS translation between HTTP and COAP > will be possible ... that eases concerns. > > I'm looking for interchangeability of HTTP/CORE and payload > encodings as appropriate for the resource constraints of specific > deployments. > > Cheers > > > On 7/1/2010 4:13 PM, Zach Shelby wrote: >> Hi Robby, >> >> We are actually agreeing. If you go and binary compress HTTP, hack >> away the features not needed for our requirements etc. - you end up >> with something that looks very much like CoAP (when we are done). >> >> This WG simply made the decision not to call this thing HTTP and to >> set a limited set of features and requirements to design for >> explicitly. The IETF ADs clearly told us that trying to hack HTTP >> would be a standardization nightmare and that production HTTP is >> much more complex than it seems. >> >> The charter goal is explicitly to make a RESTful protocol, which is >> part of the web architecture. By no means did CoAP start from >> scratch, we started with Chopan and the application requirements >> given to us. I think we've made this more controversial than >> needed? The biggest challenge (and difference from HTTP) we have to >> deal with are asynchronous transactions over UDP, Chopan had to >> deal with the same thing. We also have some requirements that >> differ clearly from HTTP - we need to achieve those with REST. >> >> If you want to call CoAP a kind of compressed HTTP then go for it! >> As CoAP is going to be 100% REST compatible and supports a subset >> of application layer HTTP features this is very much part of the >> web (CoAP< HTTP). In coap-01 we have also been able to better >> separate the UDP transaction issues from REST, which will allow us >> to do e.g. subscription without any new methods. coap-01 will also >> have no problems with HTTP mapping. So we are getting there. >> >> So if it is just the name in the end that is the problem - then why >> don't we change the name? Works for me. >> >> - Embedded HTTP >> - Constrained HTTP >> - Binary HTTP >> - Compressed HTTP >> - Constrained REST >> - M2M HTTP >> - M2M REST >> >> Zach >> >> On Jul 1, 2010, at 10:28 PM, Simpson, Robby (GE Energy Services) >> wrote: >> >> >>> Hi Vipul, >>> >>> You are not alone -- I too have been wondering why compressed HTTP >>> was >>> taken off of the table from the very start. >>> >>> A couple themes I continuously hear are: >>> >>> - "HTTP is complex" -- I disagree with this one. The vast >>> majority of >>> what is possible with HTTP is not required and can be safely >>> ignored. >>> Further, I have a feeling use cases will be found in certain >>> scenarios >>> that will lead CoRE to needing that 'complexity' again for those use >>> cases. >>> >>> - "CoRE is about M2M" -- HTTP is also used for M2M - quite a lot in >>> fact! I doubt I need to list the plethora of examples that exist. >>> >>> Specifically trying to create compressed HTTP instead of starting >>> from >>> scratch will, IMO, end the concerns with HTTP mapping, lead to a >>> protocol that will likely be useful outside of extremely constrained >>> devices, and help prevent CoRE from creating something that is >>> alienated >>> from the rest of the Web. >>> >>> - Robby >>> >>> >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On >>> Behalf Of >>> Vipul Gupta >>> Sent: Thursday, July 01, 2010 2:54 AM >>> To: core@ietf.org >>> Cc: Vipul Gupta >>> Subject: [core] CoRE v/s Compressed HTTP >>> >>> I've been following the mailing list discussion for some time now >>> and >>> even after reading through draft-ietf-core-coap-00, I'm unable to >>> see >>> the compelling justification for a brand new protocol over using >>> compressed HTTP as a starting point which is what Brian's original >>> draft (http://tools.ietf.org/html/draft-frank-6lowapp-chopan-00) >>> did. >>> >>> I can't help but feel an uneasy sense a Deja Vu. I'm reminded of the >>> early days of the WAP forum which initially took the stance that >>> "standard" Internet protocols were too heavyweight for phones and >>> set >>> about defining its own set of incompatible protocols. I'm >>> particularly >>> aware of the security work where the forum defined WTLS as a >>> "wireless" >>> version of TLS (the resuse of the TLS acronym seemed like a >>> marketing >>> ploy because the two protocols were incompatible and some of the >>> incompatibilities introduced security vulnerabilities in WTLS). Our >>> work at Sun Labs on SSL/TLS for small devices (Palm PDAs and >>> subsequently >>> sensor nodes as small as the Berkeley mote[1][2]) showed >>> otherwise. We >>> demonstrated that one could profile SSL/TLS appropriately so it >>> could >>> still be used on the wireless devices of the day while maintaining >>> compatibility with the large majority of existing deployments. >>> Eventually, >>> the right thing to do turned out to be the incorporation of Elliptic >>> Curve Cryptography (ECC) the public key cryptosystem used in WTLS, >>> into TLS (RFC 4492). This is now implemented in OpenSSL/Apache and >>> Firefox, IE and offers meaningful performance benefits even for >>> regular/unconstrained hosts [3]. >>> >>> I see strong parallels between adding ECC key exchange to TLS and >>> defining header compression for HTTP. I wonder whether there would >>> still be a place for COAP as currently defined if compressed HTTP >>> were to become a standard. To me, the following seems like a better >>> approach: >>> >>> - Define header compression for HTTP which has the potential of >>> being >>> very useful even for regular/unconstrained browsers and servers >>> interacting over TCP (Note that HTTP header compression is an >>> important component of SPDY, http://en.wikipedia.org/wiki/SPDY). >>> >>> - Define a profile for compressed HTTP to be used in COAP, e.g. >>> subset of headers to be supported, restrictions on the size of >>> compressed messages so they can be carried over UDP, nailing >>> down the content of specific messages like subscriptions/ >>> notifications and check-in (as in the chopan >>> draft). The Webhooks approach (http://webhooks.org, >>> http://wiki.webhooks.org/RESTful-WebHooks) seems clean >>> and simple but certain aspects of subscriptions/notifications are >>> currently underspecified. >>> >>> - Define how to carry compressed HTTP over UDP, e.g. handling of >>> retransmissions, congestion control, transaction IDs, etc >>> >>> This approach seems to have several advantages -- it makes HTTP >>> mapping >>> easier, frees up the WG to devote its time to other important issues >>> (nailing down the content of subscription/notification messages, >>> discovery etc), and once regular browsers and servers adopt HTTP >>> header >>> compression (Chrome already seems to have some support for this) it >>> makes true end-to-end security between COAP devices and the existing >>> Web a real possibility. >>> >>> Am I alone in feeling this way? What am I missing? >>> >>> vipul >>> --- >>> http://labs.oracle.com/people/mybio.php?uid=32495 >>> >>> [1] http://www.cs.plu.edu/courses/netsec/arts/coms.pdf >>> [2] http://cents.cs.berkeley.edu/retreats/winter_2005/SSL_on_motes.pdf >>> [3] http://labs.oracle.com/projects/crypto/ecc-ssl-ndss2004.pdf >>> _______________________________________________ >>> 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 robby.simpson@ge.com Thu Jul 1 14:25:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0554A3A693A for ; Thu, 1 Jul 2010 14:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=1.100, 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 YN7s4KZ7Z2n9 for ; Thu, 1 Jul 2010 14:25:27 -0700 (PDT) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by core3.amsl.com (Postfix) with ESMTP id 59B3D3A6944 for ; Thu, 1 Jul 2010 14:25:07 -0700 (PDT) Received: from source ([12.71.149.1]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKTC0HvoD7fJ2BRLqOpnttPbURa4x0tFeD@postini.com; Thu, 01 Jul 2010 14:25:19 PDT Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by Cinmlip07.e2k.ad.ge.com with ESMTP; 01 Jul 2010 17:25:17 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.50]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 17:25:17 -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: Thu, 1 Jul 2010 17:25:15 -0400 Message-ID: In-Reply-To: <5B079D4D-56EF-42F3-9078-75E239737A51@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoRE v/s Compressed HTTP Thread-Index: AcsZYe16cQABGI+vTSaxq0fKq3gaigAAY5hQ References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com><4C2CFC16.40506@cisco.com> <5B079D4D-56EF-42F3-9078-75E239737A51@tzi.org> From: "Simpson, Robby (GE Energy Services)" To: "Carsten Bormann" , X-OriginalArrivalTime: 01 Jul 2010 21:25:17.0185 (UTC) FILETIME=[E69F5710:01CB1963] Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 21:25:28 -0000 On Jul 01 2010, at 17:10, Carsten Bormann wrote:=20 > There are things that are extremely complex in HTTP that should be =20 > simple in a REST architecture. > In this case, it is the job of the HTTP gateway to manage the =20 > complexity, not the job of the CoAP implementation in every single =20 > light switch. > This is the main philosophical difference between the CoRE approach =20 > and "compressed HTTP". Carsten, Good point. Can you elaborate on these complexities? I believe that will help some of us understand the underlying issues. Thanks, Robby From cabo@tzi.org Thu Jul 1 14:55: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 2AFD63A6986 for ; Thu, 1 Jul 2010 14:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.734 X-Spam-Level: X-Spam-Status: No, score=-5.734 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n5npoj+ouJZ for ; Thu, 1 Jul 2010 14:55:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 011C03A694E for ; Thu, 1 Jul 2010 14:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o61LtVgH015916 for ; Thu, 1 Jul 2010 23:55:31 +0200 (CEST) Received: from [192.168.217.101] (p5489E521.dip.t-dialin.net [84.137.229.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id E5879BAB2; Thu, 1 Jul 2010 23:55:30 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 1 Jul 2010 23:55:29 +0200 To: core Message-Id: <96E50458-FA71-43CA-B253-782C2258FCFA@tzi.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] How to handle drafts that change too often (coap-misc-04) 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 Jul 2010 21:55:30 -0000 We decided to use coap-misc as a working document for some of the small changes that are needed on the way from CoAP-00 to CoAP-01. As that work progresses quickly, the document also changes often. tools.ietf.org to the rescue: http://tools.ietf.org/html/draft-bormann-coap-misc At the tools page for a draft, you find links to get various previous versions of the document, as well as links to diffs in various forms. I particularly like the diff2 form to get a quick impression of what has changed in a document. Unfortunately, the tools files are only updated once an hour, but if you don't have a toolkit of diff tools at your disposal, this hour is well worth the wait. So, please do return to the linked page in about an hour -- -04 will be waiting... I mainly moved stuff that is now historic to an appendix, moved things where we still have ongoing discussion to another appendix, and added some discussion of error handling. Gruesse, Carsten From trac@tools.ietf.org Fri Jul 2 00:39: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 593EF3A6884 for ; Fri, 2 Jul 2010 00:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 LxLIBx4G2fBc for ; Fri, 2 Jul 2010 00:39:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ADB3B3A685E for ; Fri, 2 Jul 2010 00:39:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUaqZ-0006iv-Gr; Fri, 02 Jul 2010 00:39:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 07:39:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/2#comment:1 Message-ID: <066.ddca94d70d045ae1ed0b7bfd0f37bb48@tools.ietf.org> References: <057.f066386920aa68369202bab242483a0f@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <057.f066386920aa68369202bab242483a0f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #2: New Sub/Not design X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 07:39:34 -0000 #2: New Sub/Not design --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: critical | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Changes (by zach@…): * owner: zach@… => cabo@… Comment: The integration of subscription into the coap main document will be done in coap-02. coap-01 will be done in such a way that the addition of susbcription requires no new methods or messages, therefore this addition won't affect the protocol base. Ticket #1 was closed by capturing the requirements for subscription/notification in coap-observe. As part of this ticket, coap- observe will be improved with a minimal subscription technique compatible with coap-01 that can be tested and verified before integration with coap-02. -- Ticket URL: core From trac@tools.ietf.org Fri Jul 2 00:43:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9D43A68B3 for ; Fri, 2 Jul 2010 00:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 LVh3TMzkVXyA for ; Fri, 2 Jul 2010 00:43:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 527043A68A9 for ; Fri, 2 Jul 2010 00:43:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUauI-000783-L2; Fri, 02 Jul 2010 00:43:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: brian@skyfoundry.com, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 07:43:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/8#comment:1 Message-ID: <066.b680dd4af5bb6a22c94995199c1a70e5@tools.ietf.org> References: <057.5550c2ce1e044942c5f36167340ceedd@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <057.5550c2ce1e044942c5f36167340ceedd@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: brian@skyfoundry.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #8: Complete Section 5.3 Proxying X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 07:43:21 -0000 #8: Complete Section 5.3 Proxying --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Brian Frank Type: enhancement | Status: new Priority: major | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Comment(by zach@…): In coap-01 we should aim at completing the proxying specification with these featues: - Normal proxying using Uri-Full Option to indicate actual destination. - Support for GET caching In coap-02 we can also consider further improvements such as these, which in the mean time can be discussed in coap-misc: - Intercept proxying - Caching of POST and dealing with sleeping nodes -- Ticket URL: core From trac@tools.ietf.org Fri Jul 2 00:46:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D393A685E for ; Fri, 2 Jul 2010 00:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 jYqoTLVJbeiq for ; Fri, 2 Jul 2010 00:46:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CF8AF3A67A5 for ; Fri, 2 Jul 2010 00:46:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUaxK-0008Ql-RO; Fri, 02 Jul 2010 00:46:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 07:46:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/12#comment:2 Message-ID: <062.42bf67eaef83ce9dd9529527ac619bc2@tools.ietf.org> References: <053.53cedf67cafe230ec9b1f976a32da3c6@tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <053.53cedf67cafe230ec9b1f976a32da3c6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #12: URI option: Can't distinguish absolute-URI from abs-path X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 07:46:29 -0000 #12: URI option: Can't distinguish absolute-URI from abs-path --------------------------------+------------------------------------------- Reporter: hartke@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: coap | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Fixed in coap-01 as suggested by coap-misc-04 with two different URI options: Uri-Full and Uri-Path. -- Ticket URL: core From trac@tools.ietf.org Fri Jul 2 00:49: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 863C33A685E for ; Fri, 2 Jul 2010 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 zaUAA5FpRD7p for ; Fri, 2 Jul 2010 00:49:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DE8423A686C for ; Fri, 2 Jul 2010 00:49:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUb0g-00025h-Oq; Fri, 02 Jul 2010 00:50:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 07:50:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/14#comment:2 Message-ID: <062.fb877c02efb8024759e83054a3084cea@tools.ietf.org> References: <053.fcd7f1b19ef23ac844d763b2b4f1e8df@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <053.fcd7f1b19ef23ac844d763b2b4f1e8df@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #14: Should there be a "must understand" bit on options? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 07:49:56 -0000 #14: Should there be a "must understand" bit on options? --------------------------------+------------------------------------------- Reporter: hartke@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: coap | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Solved in coap-01 with Critical/Elective options by the use of odd/even option identifiers as suggested in coap-misc-04. -- Ticket URL: core From trac@tools.ietf.org Fri Jul 2 01:01: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 9521F3A68D8 for ; Fri, 2 Jul 2010 01:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001, 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 ek9nb76HU8-M for ; Fri, 2 Jul 2010 01:01:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DC5D13A6902 for ; Fri, 2 Jul 2010 01:00:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUbAp-0002xP-CM; Fri, 02 Jul 2010 01:00:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 08:00:35 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/5#comment:1 Message-ID: <066.28146c16c453c5bcf159beed8c11b7eb@tools.ietf.org> References: <057.d0fcfea87792cc64efe59a7a1c2cf3ac@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <057.d0fcfea87792cc64efe59a7a1c2cf3ac@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #5: Header improvements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:01:43 -0000 #5: Header improvements --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: The coap-01 includes an improved and simplified header structure, was not able to integrate all ideas though. The goal is to absolutely NOT change the base and option header anymore after coap-01. - Single byte for indicating methods or response codes. Requires less memory to hold a header structure. - Improved option TLV header as per coap-misc. - The consensus earlier in the WG was to have flexible options for future extensibility. Thus we chose to keep URIs and content-type as options. The other extreme would have been to remove options almost alltogether. - The number,size and complexity of options was reduced. The new header looks like this: {{{ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | OC | Code | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header Fields: Ver: Version. 2-bit unsigned integer. Indicates the version of CoAP. Implementations of this specification MUST set this field to 1. Other values are reserved for future versions. T: 2-bit unsigned integer Transaction Type field. Indicates if this message is a CoAP Confirmable (0), Non-Confirmable (1), Acknowledgement (2) or Reset (3). OC: 4-bit unsigned integer Number of Options field. Indicates if there are Option Headers following the base header. If set to 0 the payload (if any) immediately follows the base header. If greater than zero the field indicates the number of options to immediately follow the header. See Section 3.2 below. Code: 8-bit unsigned integer. This field indicates the Method or Response Code of a message. The value 0 indicates no code. The values 1-10 are used for Method Codes as defined in Table 1. The values 11-39 are reserved for future use. The values 40-255 are used for Response Codes as defined in Section 11.1. Transaction ID: 16-bit unsigned integer. A unique Transaction ID assigned by the source and used to match responses. The Transaction ID MUST be changed for each new request (regardless of the end-point) and MUST NOT be changed when retransmitting a request. _: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. +--------+------+ | Method | Code | +--------+------+ | GET | 1 | | POST | 2 | | PUT | 3 | | DELETE | 4 | +--------+------+ Table 1: Method Codes }}} -- Ticket URL: core From zach@sensinode.com Fri Jul 2 01:07:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8AF83A68B3 for ; Fri, 2 Jul 2010 01:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, J_CHICKENPOX_72=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 2K0f5dCTZ7oh for ; Fri, 2 Jul 2010 01:07:58 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2CBF83A6847 for ; Fri, 2 Jul 2010 01:07:57 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o62886wl016032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 11:08:06 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> Date: Fri, 2 Jul 2010 11:08:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> To: Carsten Bormann , core X-Mailer: Apple Mail (2.1081) Cc: core issue tracker Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 08:08:00 -0000 Any other comments on this one? Carsten didn't like the "physical = inteface", I can remove that. Otherwise I think discussing in terms of = MTU is the best we can do. Zach On Jun 30, 2010, at 1:39 PM, core issue tracker wrote: > #15: Consolidate maximum sizes (encodings, options table, maximum = datagram) > = --------------------------------+-----------------------------------------= -- > Reporter: hartke@=85 | Owner: =20 > Type: defect | Status: new > Priority: minor | Milestone: =20 > Component: coap | Version: 1.0 > Severity: Active WG Document | Keywords: =20 > = --------------------------------+-----------------------------------------= -- >=20 > Comment(by zach@=85): >=20 > - The URI and option length discrepency is being fixed already. >=20 > - Regarding the maximum message size, I propose text like this which = is > similar to that used by other UDP based protocols such as m-DNS: >=20 > "The resulting datagram carrying a CoAP message MUST fit within a = single > MTU of that phsical interface, which is typically 1500 bytes for an > Ethernet interface and 1280 bytes for a 6LoWPAN interface." >=20 > --=20 > Ticket URL: = > core >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Fri Jul 2 01:09: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 9D2263A6863 for ; Fri, 2 Jul 2010 01:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 wiBW8Y+iaij1 for ; Fri, 2 Jul 2010 01:09:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 861193A689B for ; Fri, 2 Jul 2010 01:09:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUbJF-00043C-PR; Fri, 02 Jul 2010 01:09:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: fluffy@cisco.com, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 08:09:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/6#comment:2 Message-ID: <066.887471e93151fe981cb9f3b6738e2d2d@tools.ietf.org> References: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: fluffy@cisco.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #6: Date option text needs update X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:09:08 -0000 #6: Date option text needs update --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Cullen Jennings Type: defect | Status: new Priority: trivial | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Changes (by zach@…): * milestone: coap-01 => coap-02 Comment: Moved to coap-misc for now, to be decided on for coap-02. -- Ticket URL: core From trac@tools.ietf.org Fri Jul 2 01:09: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 55BC23A68C6 for ; Fri, 2 Jul 2010 01:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 qOi-Vc-9m-Fk for ; Fri, 2 Jul 2010 01:09:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7868D3A689B for ; Fri, 2 Jul 2010 01:09:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUbJi-00045X-F8; Fri, 02 Jul 2010 01:09:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 08:09:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/2#comment:2 Message-ID: <066.d8c1d0c281f9734527f0e0676cb3d11c@tools.ietf.org> References: <057.f066386920aa68369202bab242483a0f@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <057.f066386920aa68369202bab242483a0f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #2: New Sub/Not design X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:09:36 -0000 #2: New Sub/Not design --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: critical | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Changes (by zach@…): * milestone: => coap-02 Comment: - Changed milestone to coap-02. -- Ticket URL: core From trac@tools.ietf.org Fri Jul 2 01:18: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 B59D03A68B3 for ; Fri, 2 Jul 2010 01:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 3YfL-i6zHKI6 for ; Fri, 2 Jul 2010 01:18:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A239E3A6863 for ; Fri, 2 Jul 2010 01:18:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUbS6-0000fC-Mu; Fri, 02 Jul 2010 01:18:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 08:18:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/16#comment:2 Message-ID: <060.1bdc68535fa58056fbd95d7e1baeacf9@tools.ietf.org> References: <051.e651a5fa9ebfe6fa6b1271bd2a8d69e2@tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <051.e651a5fa9ebfe6fa6b1271bd2a8d69e2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #16: Link Format (section 6.1) needs media type (mime-type) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:18:17 -0000 #16: Link Format (section 6.1) needs media type (mime-type) --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: coap | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: coap-01 defines a temporary MIME type (to be registered with IANA) in Section 11.2: | application/link-format [IANA_LINK_MIME] | 40 | -- Ticket URL: core From trac@tools.ietf.org Fri Jul 2 01:32:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335343A689B for ; Fri, 2 Jul 2010 01:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 lg1SYmeNgJ+N for ; Fri, 2 Jul 2010 01:32:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 59C183A6863 for ; Fri, 2 Jul 2010 01:32:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUbgE-0007Ok-18; Fri, 02 Jul 2010 01:33:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 08:33:01 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/17#comment:2 Message-ID: <066.97f4775f213ae1c3a70a1929b1c02d97@tools.ietf.org> References: <057.9774b631869c90d1e431ac016b476d16@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <057.9774b631869c90d1e431ac016b476d16@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #17: Pseudo Floating-point Representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:32:52 -0000 #17: Pseudo Floating-point Representation --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Integrated from coap-misc-04. -- Ticket URL: core From guido.moritz@uni-rostock.de Fri Jul 2 02:24: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 12B6D3A63EC for ; Fri, 2 Jul 2010 02:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=1.756, BAYES_00=-2.599, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4dW6c2kPy7P for ; Fri, 2 Jul 2010 02:24:32 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 475163A67AE for ; Fri, 2 Jul 2010 02:24:32 -0700 (PDT) Received: from email2.uni-rostock.de (139.30.8.209) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Jul 2010 11:24:43 +0200 Received: from Schlappi (139.30.201.226) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Jul 2010 11:24:42 +0200 From: Guido Moritz To: 'Vipul Gupta' References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> In-Reply-To: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> Date: Fri, 2 Jul 2010 11:24:46 +0200 Message-ID: <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsY6i8IlpOI16XsToy9+rNtQezMrgA2/XHg Content-Language: de Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 09:24:34 -0000 Vipul, I must admit, while following the mailings in the list I had the same thoughts. But it indeed turned out, that there are several differences = in design of CoAP and simple binary HTTP. (1) Both rely on a RESTful style. This is a point that needs no further discussion, but is the starting point for CoAP/HTTP mapping. (2) CoAP want's to use UDP instead of TCP. First I also did not found an obvious reason, until I read Saltzer et al. [1]. As long as we not need = the flow control mechanisms of TCP and we keep the packet sizes reasonable = small enough, the only task of the transport layer is the transport itself. = Data consistency is not the task of the transport layer. ACK must be done on = the application layer if you really want to be sure your message has been processed.=20 Using UDP now implies further problems if just using binary HTTP. HTTP = is server/client and thus request/response over the same connection (this = is why it is based on TCP and is also working behind a NAT). But UDP = related with the expected high delays in a multihop 6LoWPAN networks is what = makes it more a peer-to-peer network by design instead of the HTTP = server/client model. There might be scenarios where this statement is not fulfilled, = but CoAP should be universal applicable instead of tailored for short = distance single-hop scenarios.=20 (3) HTTP has no eventing, Pub/Sub, call it whatever. It has already been discussed that some concepts like long-living TCP connections are not working due to relying on UDP. Using the concepts of WebHooks sounds reasonable. It would ease up the mapping. (4) HTTP has no device discovery concepts by default. (5) HTTP is relying on TCP, but the charter and application scenarios = say we need multicast ... so we are back at UDP. [1] http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf So when I go through all these arguments, I feel that whatever we = designing here, this is not longer simply binary HTTP. As Zach mentioned, we might argue about the name. But CoAP is far beyond just making HTTP headers = binary and thus smaller.=20 Just watching around and what I find first is WebDav. You may argue = WebDav is HTTP. But I would say it has extensions what makes it different from native HTTP. Regards, Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von Vipul > Gupta > Gesendet: Donnerstag, 1. Juli 2010 08:54 > An: core@ietf.org > Cc: Vipul Gupta > Betreff: [core] CoRE v/s Compressed HTTP >=20 > I've been following the mailing list discussion for some time now and > even after reading through draft-ietf-core-coap-00, I'm unable to see > the compelling justification for a brand new protocol over using > compressed HTTP as a starting point which is what Brian's original > draft (http://tools.ietf.org/html/draft-frank-6lowapp-chopan-00) did. >=20 > I can't help but feel an uneasy sense a Deja Vu. I'm reminded of the > early days of the WAP forum which initially took the stance that > "standard" Internet protocols were too heavyweight for phones and set > about defining its own set of incompatible protocols. I'm particularly > aware of the security work where the forum defined WTLS as a = "wireless" > version of TLS (the resuse of the TLS acronym seemed like a marketing > ploy because the two protocols were incompatible and some of the > incompatibilities introduced security vulnerabilities in WTLS). Our > work at Sun Labs on SSL/TLS for small devices (Palm PDAs and = subsequently > sensor nodes as small as the Berkeley mote[1][2]) showed otherwise. We > demonstrated that one could profile SSL/TLS appropriately so it could > still be used on the wireless devices of the day while maintaining > compatibility with the large majority of existing deployments. = Eventually, > the right thing to do turned out to be the incorporation of Elliptic > Curve Cryptography (ECC) the public key cryptosystem used in WTLS, > into TLS (RFC 4492). This is now implemented in OpenSSL/Apache and > Firefox, IE and offers meaningful performance benefits even for > regular/unconstrained hosts [3]. >=20 > I see strong parallels between adding ECC key exchange to TLS and > defining header compression for HTTP. I wonder whether there would > still be a place for COAP as currently defined if compressed HTTP > were to become a standard. To me, the following seems like a better > approach: >=20 > - Define header compression for HTTP which has the potential of being > very useful even for regular/unconstrained browsers and servers > interacting over TCP (Note that HTTP header compression is an > important component of SPDY, http://en.wikipedia.org/wiki/SPDY). >=20 > - Define a profile for compressed HTTP to be used in COAP, e.g. > subset of headers to be supported, restrictions on the size of > compressed messages so they can be carried over UDP, nailing > down the content of specific messages like subscriptions/ > notifications and check-in (as in the chopan > draft). The Webhooks approach (http://webhooks.org, > http://wiki.webhooks.org/RESTful-WebHooks) seems clean > and simple but certain aspects of subscriptions/notifications are > currently underspecified. >=20 > - Define how to carry compressed HTTP over UDP, e.g. handling of > retransmissions, congestion control, transaction IDs, etc >=20 > This approach seems to have several advantages -- it makes HTTP = mapping > easier, frees up the WG to devote its time to other important issues > (nailing down the content of subscription/notification messages, > discovery etc), and once regular browsers and servers adopt HTTP = header > compression (Chrome already seems to have some support for this) it > makes true end-to-end security between COAP devices and the existing > Web a real possibility. >=20 > Am I alone in feeling this way? What am I missing? >=20 > vipul > --- > http://labs.oracle.com/people/mybio.php?uid=3D32495 >=20 > [1] http://www.cs.plu.edu/courses/netsec/arts/coms.pdf > [2] http://cents.cs.berkeley.edu/retreats/winter_2005/SSL_on_motes.pdf > [3] http://labs.oracle.com/projects/crypto/ecc-ssl-ndss2004.pdf > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From guido.moritz@uni-rostock.de Fri Jul 2 02:30: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 1F2793A696C for ; Fri, 2 Jul 2010 02:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=1.171, BAYES_00=-2.599, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcZ0++HWdizI for ; Fri, 2 Jul 2010 02:29:59 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id E44373A6959 for ; Fri, 2 Jul 2010 02:29:57 -0700 (PDT) Received: from email2.uni-rostock.de (139.30.8.209) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Jul 2010 11:30:06 +0200 Received: from Schlappi (139.30.201.226) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Jul 2010 11:30:05 +0200 From: Guido Moritz To: 'Gilman Tolle' References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com> <4C2CFC16.40506@cisco.com> <2DFFECBD-0220-4DD2-8CA6-45EF896BC11E@archrock.com> In-Reply-To: <2DFFECBD-0220-4DD2-8CA6-45EF896BC11E@archrock.com> Date: Fri, 2 Jul 2010 11:30:10 +0200 Message-ID: <003401cb19c9$2a926830$7fb73890$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsZYyhcCvjzQgwARoCSa37PrqLJnwAYt1nw Content-Language: de Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 09:30:34 -0000 OMG, it's me again pointing at the W3C SOAP Web Services stuff ;) Maybe a short look in the WS-Eventing Spec might be helpful (only to see it's concept): http://www.w3.org/Submission/WS-Eventing/=20 WS-Eventing defines several roles that are part of the process of subscription for and event, receiving events and managing subscriptions. = The roles are client, event source, subscription manager and event sink.=20 The client subscribes for an event source. This subscription is handled = by the subscription manager that must not be necessarily the same entity = like the event source. Because the event sink can be a different endpoint as = the client, a third party can create a subscription. So in this case the = third party can compose which event sink is connected to which event source. Client, event source, subscription manager and event sink can be = completely different devices/endpoints. Might we adapt (parts of) this behavior (independent of this 'which method' discussion).=20 Best, Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > Gilman Tolle > Gesendet: Donnerstag, 1. Juli 2010 23:20 > An: paduffy@cisco.com > Cc: core@ietf.org > Betreff: Re: [core] CoRE v/s Compressed HTTP >=20 > +1 on the concerns in this thread, especially as regards > interchangeability between HTTP and CoAP. >=20 > Also, I'd like to be sure that whatever subscription mechanism we end > up deciding is the "right" one for CoRE includes a concept similar to > an explicit callback URL when making subscriptions. Simply using the > source address when accepting a subscription request is rarely > sufficient, because the source port is ephemeral, and the client may > have chosen an arbitrary port on which to run CoAP and listen for > notifications. In addition, explicitly specifying the receiver is > necessary if the subscription request is being made through a proxy. > I'd also suggest that the mechanism should allow the client to include > some information that will be returned to it unchanged in the > notification, to help it distinguish between different notifications. > In an explicit callback URL, this would be the path component and the > query string of the callback URL, but it may also be a simple opaque > string. >=20 > Gil >=20 > On Jul 1, 2010, at 4:35 PM, Paul Duffy wrote: >=20 > > Hi Zack, > > > > I share Vipul's and Robby's concerns. Recent conversation implied > > that CORE was headed off the HTTP semantic rails (addition of > > specific methods for subscription creation, etc.). If that is no > > longer the case, and STATELESS translation between HTTP and COAP > > will be possible ... that eases concerns. > > > > I'm looking for interchangeability of HTTP/CORE and payload > > encodings as appropriate for the resource constraints of specific > > deployments. > > > > Cheers > > > > > > On 7/1/2010 4:13 PM, Zach Shelby wrote: > >> Hi Robby, > >> > >> We are actually agreeing. If you go and binary compress HTTP, hack > >> away the features not needed for our requirements etc. - you end up > >> with something that looks very much like CoAP (when we are done). > >> > >> This WG simply made the decision not to call this thing HTTP and to > >> set a limited set of features and requirements to design for > >> explicitly. The IETF ADs clearly told us that trying to hack HTTP > >> would be a standardization nightmare and that production HTTP is > >> much more complex than it seems. > >> > >> The charter goal is explicitly to make a RESTful protocol, which is > >> part of the web architecture. By no means did CoAP start from > >> scratch, we started with Chopan and the application requirements > >> given to us. I think we've made this more controversial than > >> needed? The biggest challenge (and difference from HTTP) we have to > >> deal with are asynchronous transactions over UDP, Chopan had to > >> deal with the same thing. We also have some requirements that > >> differ clearly from HTTP - we need to achieve those with REST. > >> > >> If you want to call CoAP a kind of compressed HTTP then go for it! > >> As CoAP is going to be 100% REST compatible and supports a subset > >> of application layer HTTP features this is very much part of the > >> web (CoAP< HTTP). In coap-01 we have also been able to better > >> separate the UDP transaction issues from REST, which will allow us > >> to do e.g. subscription without any new methods. coap-01 will also > >> have no problems with HTTP mapping. So we are getting there. > >> > >> So if it is just the name in the end that is the problem - then why > >> don't we change the name? Works for me. > >> > >> - Embedded HTTP > >> - Constrained HTTP > >> - Binary HTTP > >> - Compressed HTTP > >> - Constrained REST > >> - M2M HTTP > >> - M2M REST > >> > >> Zach > >> > >> On Jul 1, 2010, at 10:28 PM, Simpson, Robby (GE Energy Services) > >> wrote: > >> > >> > >>> Hi Vipul, > >>> > >>> You are not alone -- I too have been wondering why compressed HTTP > >>> was > >>> taken off of the table from the very start. > >>> > >>> A couple themes I continuously hear are: > >>> > >>> - "HTTP is complex" -- I disagree with this one. The vast > >>> majority of > >>> what is possible with HTTP is not required and can be safely > >>> ignored. > >>> Further, I have a feeling use cases will be found in certain > >>> scenarios > >>> that will lead CoRE to needing that 'complexity' again for those = use > >>> cases. > >>> > >>> - "CoRE is about M2M" -- HTTP is also used for M2M - quite a lot = in > >>> fact! I doubt I need to list the plethora of examples that exist. > >>> > >>> Specifically trying to create compressed HTTP instead of starting > >>> from > >>> scratch will, IMO, end the concerns with HTTP mapping, lead to a > >>> protocol that will likely be useful outside of extremely = constrained > >>> devices, and help prevent CoRE from creating something that is > >>> alienated > >>> from the rest of the Web. > >>> > >>> - Robby > >>> > >>> > >>> -----Original Message----- > >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On > >>> Behalf Of > >>> Vipul Gupta > >>> Sent: Thursday, July 01, 2010 2:54 AM > >>> To: core@ietf.org > >>> Cc: Vipul Gupta > >>> Subject: [core] CoRE v/s Compressed HTTP > >>> > >>> I've been following the mailing list discussion for some time now > >>> and > >>> even after reading through draft-ietf-core-coap-00, I'm unable to > >>> see > >>> the compelling justification for a brand new protocol over using > >>> compressed HTTP as a starting point which is what Brian's original > >>> draft (http://tools.ietf.org/html/draft-frank-6lowapp-chopan-00) > >>> did. > >>> > >>> I can't help but feel an uneasy sense a Deja Vu. I'm reminded of = the > >>> early days of the WAP forum which initially took the stance that > >>> "standard" Internet protocols were too heavyweight for phones and > >>> set > >>> about defining its own set of incompatible protocols. I'm > >>> particularly > >>> aware of the security work where the forum defined WTLS as a > >>> "wireless" > >>> version of TLS (the resuse of the TLS acronym seemed like a > >>> marketing > >>> ploy because the two protocols were incompatible and some of the > >>> incompatibilities introduced security vulnerabilities in WTLS). = Our > >>> work at Sun Labs on SSL/TLS for small devices (Palm PDAs and > >>> subsequently > >>> sensor nodes as small as the Berkeley mote[1][2]) showed > >>> otherwise. We > >>> demonstrated that one could profile SSL/TLS appropriately so it > >>> could > >>> still be used on the wireless devices of the day while maintaining > >>> compatibility with the large majority of existing deployments. > >>> Eventually, > >>> the right thing to do turned out to be the incorporation of = Elliptic > >>> Curve Cryptography (ECC) the public key cryptosystem used in WTLS, > >>> into TLS (RFC 4492). This is now implemented in OpenSSL/Apache and > >>> Firefox, IE and offers meaningful performance benefits even for > >>> regular/unconstrained hosts [3]. > >>> > >>> I see strong parallels between adding ECC key exchange to TLS and > >>> defining header compression for HTTP. I wonder whether there would > >>> still be a place for COAP as currently defined if compressed HTTP > >>> were to become a standard. To me, the following seems like a = better > >>> approach: > >>> > >>> - Define header compression for HTTP which has the potential of > >>> being > >>> very useful even for regular/unconstrained browsers and servers > >>> interacting over TCP (Note that HTTP header compression is an > >>> important component of SPDY, http://en.wikipedia.org/wiki/SPDY). > >>> > >>> - Define a profile for compressed HTTP to be used in COAP, e.g. > >>> subset of headers to be supported, restrictions on the size of > >>> compressed messages so they can be carried over UDP, nailing > >>> down the content of specific messages like subscriptions/ > >>> notifications and check-in (as in the chopan > >>> draft). The Webhooks approach (http://webhooks.org, > >>> http://wiki.webhooks.org/RESTful-WebHooks) seems clean > >>> and simple but certain aspects of subscriptions/notifications are > >>> currently underspecified. > >>> > >>> - Define how to carry compressed HTTP over UDP, e.g. handling of > >>> retransmissions, congestion control, transaction IDs, etc > >>> > >>> This approach seems to have several advantages -- it makes HTTP > >>> mapping > >>> easier, frees up the WG to devote its time to other important = issues > >>> (nailing down the content of subscription/notification messages, > >>> discovery etc), and once regular browsers and servers adopt HTTP > >>> header > >>> compression (Chrome already seems to have some support for this) = it > >>> makes true end-to-end security between COAP devices and the = existing > >>> Web a real possibility. > >>> > >>> Am I alone in feeling this way? What am I missing? > >>> > >>> vipul > >>> --- > >>> http://labs.oracle.com/people/mybio.php?uid=3D32495 > >>> > >>> [1] http://www.cs.plu.edu/courses/netsec/arts/coms.pdf > >>> [2] = http://cents.cs.berkeley.edu/retreats/winter_2005/SSL_on_motes.pdf > >>> [3] http://labs.oracle.com/projects/crypto/ecc-ssl-ndss2004.pdf > >>> _______________________________________________ > >>> 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 From L.Wood@surrey.ac.uk Fri Jul 2 02:36:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B5E3A6902 for ; Fri, 2 Jul 2010 02:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.692, 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 uUGzaJ71N1AF for ; Fri, 2 Jul 2010 02:36:57 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 46DFD3A68C0 for ; Fri, 2 Jul 2010 02:36:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-13.tower-78.messagelabs.com!1278063427!19686935!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 1061 invoked from network); 2 Jul 2010 09:37:08 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-13.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 2 Jul 2010 09:37:08 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 2 Jul 2010 10:37:07 +0100 From: To: Date: Fri, 2 Jul 2010 10:37:07 +0100 Thread-Topic: [core] CoRE v/s Compressed HTTP Thread-Index: AcsY6i8IlpOI16XsToy9+rNtQezMrgA2/XHgAADZCsA= Message-ID: References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> In-Reply-To: <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 09:36:58 -0000 Yes, only a high-layer check can guarantee that what was sent is what was r= eceived, without corruption. But to quote saltzer et al.: "Clearly, some effort at the lower levels to improve network reliability ca= n have a significant effect on application performance." So transport-layer data consistency can benefit implementations. It's a series of tradeoffs and engineering decisions, not necessarily clear= -cut. L. There is no end to the end-to-end argument. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Gui= do Moritz Sent: 02 July 2010 10:25 [..] (2) CoAP want's to use UDP instead of TCP. First I also did not found an ob= vious reason, until I read Saltzer et al. [1]. As long as we not need the f= low control mechanisms of TCP and we keep the packet sizes reasonable small= enough, the only task of the transport layer is the transport itself. Data= consistency is not the task of the transport layer. ACK must be done on th= e application layer if you really want to be sure your message has been pro= cessed. [..] From zach@sensinode.com Fri Jul 2 03:23:46 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 56F4F3A6897 for ; Fri, 2 Jul 2010 03:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=0.662, 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 3jVQH6gbHpoK for ; Fri, 2 Jul 2010 03:23:45 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4B1DE3A6809 for ; Fri, 2 Jul 2010 03:23:43 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o62ANlbG029135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 13:23:47 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <003401cb19c9$2a926830$7fb73890$@moritz@uni-rostock.de> Date: Fri, 2 Jul 2010 13:23:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <75EA05A9-7C80-4B2B-A1BC-FDB72623694B@sensinode.com> <4C2CFC16.40506@cisco.com> <2DFFECBD-0220-4DD2-8CA6-45EF896BC11E@archrock.com> <003401cb19c9$2a926830$7fb73890$@moritz@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 10:23:46 -0000 Guido, This is definitely a good reference to be included in coap-observe which = deals with the requirements and solution (next version) for subscription = in CoAP. Gil also had some good ideas for further requirements with regard to = tokens and third-party subscriptions. Those should also be considered in = coap-observe.=20 Zach=20 On Jul 2, 2010, at 12:30 PM, Guido Moritz wrote: > Maybe a short look in the WS-Eventing Spec might be helpful (only to = see > it's concept): http://www.w3.org/Submission/WS-Eventing/=20 >=20 > WS-Eventing defines several roles that are part of the process of > subscription for and event, receiving events and managing = subscriptions. The > roles are client, event source, subscription manager and event sink.=20= > The client subscribes for an event source. This subscription is = handled by > the subscription manager that must not be necessarily the same entity = like > the event source. Because the event sink can be a different endpoint = as the > client, a third party can create a subscription. So in this case the = third > party can compose which event sink is connected to which event source. > Client, event source, subscription manager and event sink can be = completely > different devices/endpoints. Might we adapt (parts of) this behavior > (independent of this 'which method' discussion).=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From guido.moritz@uni-rostock.de Fri Jul 2 03:26: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 C71223A67FA for ; Fri, 2 Jul 2010 03:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J+GfGRx2gP2 for ; Fri, 2 Jul 2010 03:26:39 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 7C9A83A67D7 for ; Fri, 2 Jul 2010 03:26:39 -0700 (PDT) Received: from email2.uni-rostock.de (139.30.8.209) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Jul 2010 12:26:50 +0200 Received: from Schlappi (139.30.201.226) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Jul 2010 12:26:50 +0200 From: Guido Moritz To: References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> In-Reply-To: Date: Fri, 2 Jul 2010 12:26:54 +0200 Message-ID: <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsY6i8IlpOI16XsToy9+rNtQezMrgA2/XHgAADZCsAAAZGToA== Content-Language: de Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 10:26:40 -0000 > "Clearly, some effort at the lower levels to improve network = reliability > can have a significant effect on > application performance." Jep, but from the CoAP point of view I would say this is what brings us closer to UDP than to TCP. TCP uses ACKs and Retransmissions to get some kind of reliability. But keep in mind that CoAP (and I assume it does) = has no huge packets on application layer. Of course, if application layer packets are much bigger than transport layer packets, the ACK/Retr = mechanism on transport layer is a huge advantage concerning performance issues. = But I think CoAP is more heading towards smaller packets. So packet size on application and transport layer might have the same size and thus an application packet fits in one transport packet. So there would be no = need for the TCP ACK/Retr of stuff TCP and you can do this on application = layer directly with the same efforts and higher degree of reliability ('Did = it' vs. 'Got it'). So the main question at this point: which message/packet sizes do we assume for a single request/response/transmission/what ever. The other side of the coin would the checksum mechanism of TCP. Do we = want to use this on our nodes or leave this up to other layers? The last thing is the flow control/sliding window stuff. I think we will = not really need this in CoAP due to quite small receive/send buffers implied = by the resource constraints. Guido > -----Urspr=FCngliche Nachricht----- > Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] > Gesendet: Freitag, 2. Juli 2010 11:37 > An: Guido Moritz > Cc: core@ietf.org > Betreff: RE: [core] CoRE v/s Compressed HTTP >=20 > Yes, only a high-layer check can guarantee that what was sent is what = was > received, without corruption. > But to quote saltzer et al.: > "Clearly, some effort at the lower levels to improve network = reliability > can have a significant effect on > application performance." > So transport-layer data consistency can benefit implementations. >=20 > It's a series of tradeoffs and engineering decisions, not necessarily > clear-cut. >=20 > L. >=20 > There is no end to the end-to-end argument. >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Guido Moritz > Sent: 02 July 2010 10:25 >=20 > [..] > (2) CoAP want's to use UDP instead of TCP. First I also did not found = an > obvious reason, until I read Saltzer et al. [1]. As long as we not = need the > flow control mechanisms of TCP and we keep the packet sizes reasonable > small enough, the only task of the transport layer is the transport itself. > Data consistency is not the task of the transport layer. ACK must be = done > on the application layer if you really want to be sure your message = has > been processed. > [..] From guido.moritz@uni-rostock.de Fri Jul 2 03:37: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 26FA23A67FA for ; Fri, 2 Jul 2010 03:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdPUj2Zs7kwh for ; Fri, 2 Jul 2010 03:37:38 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 022EF3A67C3 for ; Fri, 2 Jul 2010 03:37:31 -0700 (PDT) Received: from email2.uni-rostock.de (139.30.8.209) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Jul 2010 12:37:42 +0200 Received: from Schlappi (139.30.201.226) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Jul 2010 12:37:42 +0200 From: Guido Moritz To: 'Zach Shelby' , 'Carsten Bormann' , 'core' References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> In-Reply-To: Date: Fri, 2 Jul 2010 12:37:46 +0200 Message-ID: <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsZvbyxZzL1p3MDSaq5wONyy04dygAFLDKw Content-Language: de Cc: 'core issue tracker' Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 10:37:43 -0000 I don't like the differentiation depending on the 'link layer'. 1280 = seems to be reasonable as the magic number of 6LoWPAN networks in general ;) Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag > von Zach Shelby > Gesendet: Freitag, 2. Juli 2010 10:08 > An: Carsten Bormann; core > Cc: core issue tracker > Betreff: Re: [core] #15: Consolidate maximum sizes (encodings, options > table, maximum datagram) >=20 > Any other comments on this one? Carsten didn't like the "physical > inteface", I can remove that. Otherwise I think discussing in terms of > MTU is the best we can do. >=20 > Zach >=20 > On Jun 30, 2010, at 1:39 PM, core issue tracker wrote: >=20 > > #15: Consolidate maximum sizes (encodings, options table, maximum > datagram) > > = --------------------------------+------------------------------------ > ------- > > Reporter: hartke@=85 | Owner: > > Type: defect | Status: new > > Priority: minor | Milestone: > > Component: coap | Version: 1.0 > > Severity: Active WG Document | Keywords: > > = --------------------------------+------------------------------------ > ------- > > > > Comment(by zach@=85): > > > > - The URI and option length discrepency is being fixed already. > > > > - Regarding the maximum message size, I propose text like this which > is > > similar to that used by other UDP based protocols such as m-DNS: > > > > "The resulting datagram carrying a CoAP message MUST fit within a > single > > MTU of that phsical interface, which is typically 1500 bytes for an > > Ethernet interface and 1280 bytes for a 6LoWPAN interface." > > > > -- > > Ticket URL: > > > core > > >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Fri Jul 2 03:49: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 D49AE3A6959 for ; Fri, 2 Jul 2010 03:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.972 X-Spam-Level: X-Spam-Status: No, score=-2.972 tagged_above=-999 required=5 tests=[AWL=0.627, 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 qHolWD2ggBmh for ; Fri, 2 Jul 2010 03:49:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E55653A6809 for ; Fri, 2 Jul 2010 03:49:38 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o62AnkRj031933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 13:49:47 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> Date: Fri, 2 Jul 2010 13:49:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 10:49:41 -0000 Regarding UDP and congestion control, I really think everyone should = read the contribution from Lars: http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt One main point is that the whole congestion control model of TCP = wouldn't really help us, the flow model is totally different here. The = other issue we have in CoRE is that not all requests even need to be (or = should be) reliable - e.g. multicast or streaming. The current coap-01 limitation on CoAP message size is that the = resulting datagram must fit into the MTU. For 95% of the cases this = payload size is sufficient. For that 5% (firmware update?), which I am = personally not sure we should optimize for, coap-misc-04 does have a = proposed block option to enabled transferring blocks of a = representation. This is something to experiment with.=20 Zach On Jul 2, 2010, at 1:26 PM, Guido Moritz wrote: >> "Clearly, some effort at the lower levels to improve network = reliability >> can have a significant effect on >> application performance." > Jep, but from the CoAP point of view I would say this is what brings = us > closer to UDP than to TCP. TCP uses ACKs and Retransmissions to get = some > kind of reliability. But keep in mind that CoAP (and I assume it does) = has > no huge packets on application layer. Of course, if application layer > packets are much bigger than transport layer packets, the ACK/Retr = mechanism > on transport layer is a huge advantage concerning performance issues. = But I > think CoAP is more heading towards smaller packets. So packet size on > application and transport layer might have the same size and thus an > application packet fits in one transport packet. So there would be no = need > for the TCP ACK/Retr of stuff TCP and you can do this on application = layer > directly with the same efforts and higher degree of reliability ('Did = it' > vs. 'Got it'). So the main question at this point: which = message/packet > sizes do we assume for a single request/response/transmission/what = ever. >=20 > The other side of the coin would the checksum mechanism of TCP. Do we = want > to use this on our nodes or leave this up to other layers? >=20 > The last thing is the flow control/sliding window stuff. I think we = will not > really need this in CoAP due to quite small receive/send buffers = implied by > the resource constraints. >=20 > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] >> Gesendet: Freitag, 2. Juli 2010 11:37 >> An: Guido Moritz >> Cc: core@ietf.org >> Betreff: RE: [core] CoRE v/s Compressed HTTP >>=20 >> Yes, only a high-layer check can guarantee that what was sent is what = was >> received, without corruption. >> But to quote saltzer et al.: >> "Clearly, some effort at the lower levels to improve network = reliability >> can have a significant effect on >> application performance." >> So transport-layer data consistency can benefit implementations. >>=20 >> It's a series of tradeoffs and engineering decisions, not necessarily >> clear-cut. >>=20 >> L. >>=20 >> There is no end to the end-to-end argument. >>=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >> Guido Moritz >> Sent: 02 July 2010 10:25 >>=20 >> [..] >> (2) CoAP want's to use UDP instead of TCP. First I also did not found = an >> obvious reason, until I read Saltzer et al. [1]. As long as we not = need > the >> flow control mechanisms of TCP and we keep the packet sizes = reasonable >> small enough, the only task of the transport layer is the transport > itself. >> Data consistency is not the task of the transport layer. ACK must be = done >> on the application layer if you really want to be sure your message = has >> been processed. >> [..] >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From rgm@labs.htt-consult.com Fri Jul 2 04:40: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 EA5B63A680F for ; Fri, 2 Jul 2010 04:40:28 -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.299, 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 OLrkujj2c05X for ; Fri, 2 Jul 2010 04:40:21 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A3F723A67E2 for ; Fri, 2 Jul 2010 04:40:17 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 429FD68B5D; Fri, 2 Jul 2010 11:32:22 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+3gyWSDqrb5; Fri, 2 Jul 2010 07:32:11 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A8AC968B4C; Fri, 2 Jul 2010 07:32:11 -0400 (EDT) Message-ID: <4C2DD021.2030602@labs.htt-consult.com> Date: Fri, 02 Jul 2010 07:40:17 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Guido Moritz References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> In-Reply-To: <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> Content-Type: multipart/alternative; boundary="------------090407060800070902090807" Cc: core@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 11:40:31 -0000 This is a multi-part message in MIME format. --------------090407060800070902090807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 07/02/2010 06:26 AM, Guido Moritz wrote: >> "Clearly, some effort at the lower levels to improve network reliability >> can have a significant effect on >> application performance." >> > Jep, but from the CoAP point of view I would say this is what brings us > closer to UDP than to TCP. TCP uses ACKs and Retransmissions to get some > kind of reliability. But keep in mind that CoAP (and I assume it does) has > no huge packets on application layer. Of course, if application layer > packets are much bigger than transport layer packets, the ACK/Retr mechanism > on transport layer is a huge advantage concerning performance issues. But I > think CoAP is more heading towards smaller packets. So packet size on > application and transport layer might have the same size and thus an > application packet fits in one transport packet. So there would be no need > for the TCP ACK/Retr of stuff TCP and you can do this on application layer > directly with the same efforts and higher degree of reliability ('Did it' > vs. 'Got it'). So the main question at this point: which message/packet > sizes do we assume for a single request/response/transmission/what ever. > > The other side of the coin would the checksum mechanism of TCP. Do we want > to use this on our nodes or leave this up to other layers? > I may be pointing out something well known, but ESP has a MUCH better 'checksum' mechanism, but there is no retry tied to it. If the packet authentication fails the packet is silently discarded. > The last thing is the flow control/sliding window stuff. I think we will not > really need this in CoAP due to quite small receive/send buffers implied by > the resource constraints. > > Guido > > >> -----Ursprüngliche Nachricht----- >> Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] >> Gesendet: Freitag, 2. Juli 2010 11:37 >> An: Guido Moritz >> Cc: core@ietf.org >> Betreff: RE: [core] CoRE v/s Compressed HTTP >> >> Yes, only a high-layer check can guarantee that what was sent is what was >> received, without corruption. >> But to quote saltzer et al.: >> "Clearly, some effort at the lower levels to improve network reliability >> can have a significant effect on >> application performance." >> So transport-layer data consistency can benefit implementations. >> >> It's a series of tradeoffs and engineering decisions, not necessarily >> clear-cut. >> >> L. >> >> There is no end to the end-to-end argument. >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >> Guido Moritz >> Sent: 02 July 2010 10:25 >> >> [..] >> (2) CoAP want's to use UDP instead of TCP. First I also did not found an >> obvious reason, until I read Saltzer et al. [1]. As long as we not need >> > the > >> flow control mechanisms of TCP and we keep the packet sizes reasonable >> small enough, the only task of the transport layer is the transport >> > itself. > >> Data consistency is not the task of the transport layer. ACK must be done >> on the application layer if you really want to be sure your message has >> been processed. >> [..] >> > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > -- Robert Moskowitz Senior Technical Director ICSA Labs, an Independent Division of Verizon Business Systems W: 248-968-9809 F: 248-968-2824 VoIP: 248-291-0713 E: robert.moskowitz@icsalabs.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------090407060800070902090807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/02/2010 06:26 AM, Guido Moritz wrote: 
"Clearly, some effort at the lower levels to improve network reliability
can have a significant effect on
application performance."
    
Jep, but from the CoAP point of view I would say this is what brings us
closer to UDP than to TCP. TCP uses ACKs and Retransmissions to get some
kind of reliability. But keep in mind that CoAP (and I assume it does) has
no huge packets on application layer.  Of course, if application layer
packets are much bigger than transport layer packets, the ACK/Retr mechanism
on transport layer is a huge advantage concerning performance issues. But I
think CoAP is more heading towards smaller packets. So packet size on
application and transport layer might have the same size and thus an
application packet fits in one transport packet. So there would be no need
for the TCP ACK/Retr of stuff TCP and you can do this on application layer
directly with the same efforts and higher degree of reliability ('Did it'
vs. 'Got it'). So the main question at this point: which message/packet
sizes do we assume for a single request/response/transmission/what ever.

The other side of the coin would the checksum mechanism of TCP. Do we want
to use this on our nodes or leave this up to other layers?

I may be pointing out something well known, but ESP has a MUCH better 'checksum' mechanism, but there is no retry tied to it.  If the packet authentication fails the packet is silently discarded.


The last thing is the flow control/sliding window stuff. I think we will not
really need this in CoAP due to quite small receive/send buffers implied by
the resource constraints.

Guido

  
-----Ursprüngliche Nachricht-----
Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk]
Gesendet: Freitag, 2. Juli 2010 11:37
An: Guido Moritz
Cc: core@ietf.org
Betreff: RE: [core] CoRE v/s Compressed HTTP

Yes, only a high-layer check can guarantee that what was sent is what was
received, without corruption.
But to quote saltzer et al.:
"Clearly, some effort at the lower levels to improve network reliability
can have a significant effect on
application performance."
So transport-layer data consistency can benefit implementations.

It's a series of tradeoffs and engineering decisions, not necessarily
clear-cut.

L.

There is no end to the end-to-end argument.

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
Guido Moritz
Sent: 02 July 2010 10:25

[..]
(2) CoAP want's to use UDP instead of TCP. First I also did not found an
obvious reason, until I read Saltzer et al. [1]. As long as we not need
    
the
  
flow control mechanisms of TCP and we keep the packet sizes reasonable
small enough, the only task of the transport layer is the transport
    
itself.
  
Data consistency is not the task of the transport layer. ACK must be done
on the application layer if you really want to be sure your message has
been processed.
[..]
    

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

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

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------090407060800070902090807-- From trac@tools.ietf.org Fri Jul 2 05:44: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 83D253A67E3 for ; Fri, 2 Jul 2010 05:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 xyYJQRH9d3Qt for ; Fri, 2 Jul 2010 05:44:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CD34A3A67DA for ; Fri, 2 Jul 2010 05:44:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OUfbq-00071N-2m; Fri, 02 Jul 2010 05:44:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Jul 2010 12:44:46 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/9#comment:2 Message-ID: <066.b81cf146360e5b4111885c5825901612@tools.ietf.org> References: <057.991b4b209b798e7fdfa5e0f4fd31a63a@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <057.991b4b209b798e7fdfa5e0f4fd31a63a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #9: Section 6 "Resource Discovery" improvements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 12:44:38 -0000 #9: Section 6 "Resource Discovery" improvements --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Now included for coap-01. Still doing a detailed analysis and checking that we have taken all the SE2.0 requirements and scenarios into account before submission. -- Ticket URL: core From d.sturek@att.net Fri Jul 2 05:50: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 9D3E73A6835 for ; Fri, 2 Jul 2010 05:50:48 -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_00=-2.599, 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 klUhiYcgLa7I for ; Fri, 2 Jul 2010 05:50:46 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 93D963A680F for ; Fri, 2 Jul 2010 05:50:46 -0700 (PDT) Received: (qmail 29289 invoked from network); 2 Jul 2010 12:50:55 -0000 Received: from Studio (d.sturek@69.105.139.124 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 02 Jul 2010 05:50:54 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: xi4Xk_0VM1n1ZryI6w2BKWX04syESggV4GFRUa7jSggsEfN_BlD7hD2IQCq3aaW_7.VNRq9P8yVv7z33ipQLddpYfKPBKMl3MY4kmkbQiHLEhmzkMQPQmTp4IIXaYtDmBKkfbCfWtTy2Ofr7aLpKANQcc_ox0KYjO9oxFfJotKn4lEL1ciaQ64rE7nZ1nBkYCR7YDx2pPDs0.H6yOwuU9kA382lsCl1c9KhJUI_zKGcjM4y2YTVHfU0MVa0l1VFqiwgwMMcj7GFvOREKS1ywTnAn X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" , "'Guido Moritz'" References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> In-Reply-To: <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> Date: Fri, 2 Jul 2010 05:50:46 -0700 Message-ID: <006701cb19e5$316d6850$944838f0$@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: AcsZ1E+ieDLFnwa+TcayI2L9a2FgRAAEIQTw Content-Language: en-us Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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, 02 Jul 2010 12:50:48 -0000 Hi Zach, I think what you wrote is not quite correct. I think many solutions will need guaranteed delivery and I think many = will need fragmentation/reassembly. Only a small subset of solutions will = work with CoAP/UDP and all application messaging fitting into a single = packet. The reason I mention this is that I fully expect to see a need in some = of the features that TCP offers though I agree that congestion control in a mesh network is not one of them (at least as implemented in TCP). Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Zach Shelby Sent: Friday, July 02, 2010 3:50 AM To: Guido Moritz Cc: core@ietf.org; L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP Regarding UDP and congestion control, I really think everyone should = read the contribution from Lars: http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt One main point is that the whole congestion control model of TCP = wouldn't really help us, the flow model is totally different here. The other = issue we have in CoRE is that not all requests even need to be (or should be) reliable - e.g. multicast or streaming. The current coap-01 limitation on CoAP message size is that the = resulting datagram must fit into the MTU. For 95% of the cases this payload size = is sufficient. For that 5% (firmware update?), which I am personally not = sure we should optimize for, coap-misc-04 does have a proposed block option = to enabled transferring blocks of a representation. This is something to experiment with.=20 Zach On Jul 2, 2010, at 1:26 PM, Guido Moritz wrote: >> "Clearly, some effort at the lower levels to improve network = reliability >> can have a significant effect on >> application performance." > Jep, but from the CoAP point of view I would say this is what brings = us > closer to UDP than to TCP. TCP uses ACKs and Retransmissions to get = some > kind of reliability. But keep in mind that CoAP (and I assume it does) = has > no huge packets on application layer. Of course, if application layer > packets are much bigger than transport layer packets, the ACK/Retr mechanism > on transport layer is a huge advantage concerning performance issues. = But I > think CoAP is more heading towards smaller packets. So packet size on > application and transport layer might have the same size and thus an > application packet fits in one transport packet. So there would be no = need > for the TCP ACK/Retr of stuff TCP and you can do this on application = layer > directly with the same efforts and higher degree of reliability ('Did = it' > vs. 'Got it'). So the main question at this point: which = message/packet > sizes do we assume for a single request/response/transmission/what = ever. >=20 > The other side of the coin would the checksum mechanism of TCP. Do we = want > to use this on our nodes or leave this up to other layers? >=20 > The last thing is the flow control/sliding window stuff. I think we = will not > really need this in CoAP due to quite small receive/send buffers = implied by > the resource constraints. >=20 > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] >> Gesendet: Freitag, 2. Juli 2010 11:37 >> An: Guido Moritz >> Cc: core@ietf.org >> Betreff: RE: [core] CoRE v/s Compressed HTTP >>=20 >> Yes, only a high-layer check can guarantee that what was sent is what = was >> received, without corruption. >> But to quote saltzer et al.: >> "Clearly, some effort at the lower levels to improve network = reliability >> can have a significant effect on >> application performance." >> So transport-layer data consistency can benefit implementations. >>=20 >> It's a series of tradeoffs and engineering decisions, not necessarily >> clear-cut. >>=20 >> L. >>=20 >> There is no end to the end-to-end argument. >>=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >> Guido Moritz >> Sent: 02 July 2010 10:25 >>=20 >> [..] >> (2) CoAP want's to use UDP instead of TCP. First I also did not found = an >> obvious reason, until I read Saltzer et al. [1]. As long as we not = need > the >> flow control mechanisms of TCP and we keep the packet sizes = reasonable >> small enough, the only task of the transport layer is the transport > itself. >> Data consistency is not the task of the transport layer. ACK must be = done >> on the application layer if you really want to be sure your message = has >> been processed. >> [..] >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Fri Jul 2 05:57:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6463A67EE for ; Fri, 2 Jul 2010 05:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=0.596, 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 pgsqUCXBKkSP for ; Fri, 2 Jul 2010 05:57:32 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 94C443A67DA for ; Fri, 2 Jul 2010 05:57:31 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o62CvZXu012652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 15:57:37 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <006701cb19e5$316d6850$944838f0$@sturek@att.net> Date: Fri, 2 Jul 2010 15:57:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <006701cb19e5$316d6850$944838f0$@sturek@att.net> To: X-Mailer: Apple Mail (2.1081) Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 12:57:38 -0000 Morning Don, On Jul 2, 2010, at 3:50 PM, Don Sturek wrote: > Hi Zach, >=20 > I think what you wrote is not quite correct. >=20 > I think many solutions will need guaranteed delivery Agreed, and we have that. > and I think many will > need fragmentation/reassembly. =20 This is something we still need to experiment with and gain experience. = Can applications that need that do it themselves? Or is the Block Option = proposal in coap-misc-04 workable? If the WG concludes that we need it = and we have a way to do it then we surely will. > Only a small subset of solutions will work > with CoAP/UDP and all application messaging fitting into a single = packet. How did we go from transferring payloads in the sizes of 10s of bytes, = to several kBs in this WG? ;-) coap-01 requires this to fit in a single = MTU, which would usually be between 1280-1500 bytes. At least for all = the applications I have experience with in the 6LoWPAN world this is = sufficient. For the few things like firmware transfer that need more, = you can design a REST interface for that. What do you have in mind? >=20 > The reason I mention this is that I fully expect to see a need in some = of > the features that TCP offers though I agree that congestion control in = a > mesh network is not one of them (at least as implemented in TCP). Yep, Lars's document has a really good list of stuff we need to = experiment with and integrate into the base coap document as they are = verified. We hope to try some out already at the plugfest. Zach >=20 > Don >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Zach > Shelby > Sent: Friday, July 02, 2010 3:50 AM > To: Guido Moritz > Cc: core@ietf.org; L.Wood@surrey.ac.uk > Subject: Re: [core] CoRE v/s Compressed HTTP >=20 > Regarding UDP and congestion control, I really think everyone should = read > the contribution from Lars: >=20 > http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt >=20 > One main point is that the whole congestion control model of TCP = wouldn't > really help us, the flow model is totally different here. The other = issue we > have in CoRE is that not all requests even need to be (or should be) > reliable - e.g. multicast or streaming. >=20 > The current coap-01 limitation on CoAP message size is that the = resulting > datagram must fit into the MTU. For 95% of the cases this payload size = is > sufficient. For that 5% (firmware update?), which I am personally not = sure > we should optimize for, coap-misc-04 does have a proposed block option = to > enabled transferring blocks of a representation. This is something to > experiment with.=20 >=20 > Zach >=20 > On Jul 2, 2010, at 1:26 PM, Guido Moritz wrote: >=20 >>> "Clearly, some effort at the lower levels to improve network = reliability >>> can have a significant effect on >>> application performance." >> Jep, but from the CoAP point of view I would say this is what brings = us >> closer to UDP than to TCP. TCP uses ACKs and Retransmissions to get = some >> kind of reliability. But keep in mind that CoAP (and I assume it = does) has >> no huge packets on application layer. Of course, if application = layer >> packets are much bigger than transport layer packets, the ACK/Retr > mechanism >> on transport layer is a huge advantage concerning performance issues. = But > I >> think CoAP is more heading towards smaller packets. So packet size on >> application and transport layer might have the same size and thus an >> application packet fits in one transport packet. So there would be no = need >> for the TCP ACK/Retr of stuff TCP and you can do this on application = layer >> directly with the same efforts and higher degree of reliability ('Did = it' >> vs. 'Got it'). So the main question at this point: which = message/packet >> sizes do we assume for a single request/response/transmission/what = ever. >>=20 >> The other side of the coin would the checksum mechanism of TCP. Do we = want >> to use this on our nodes or leave this up to other layers? >>=20 >> The last thing is the flow control/sliding window stuff. I think we = will > not >> really need this in CoAP due to quite small receive/send buffers = implied > by >> the resource constraints. >>=20 >> Guido >>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] >>> Gesendet: Freitag, 2. Juli 2010 11:37 >>> An: Guido Moritz >>> Cc: core@ietf.org >>> Betreff: RE: [core] CoRE v/s Compressed HTTP >>>=20 >>> Yes, only a high-layer check can guarantee that what was sent is = what was >>> received, without corruption. >>> But to quote saltzer et al.: >>> "Clearly, some effort at the lower levels to improve network = reliability >>> can have a significant effect on >>> application performance." >>> So transport-layer data consistency can benefit implementations. >>>=20 >>> It's a series of tradeoffs and engineering decisions, not = necessarily >>> clear-cut. >>>=20 >>> L. >>>=20 >>> There is no end to the end-to-end argument. >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >>> Guido Moritz >>> Sent: 02 July 2010 10:25 >>>=20 >>> [..] >>> (2) CoAP want's to use UDP instead of TCP. First I also did not = found an >>> obvious reason, until I read Saltzer et al. [1]. As long as we not = need >> the >>> flow control mechanisms of TCP and we keep the packet sizes = reasonable >>> small enough, the only task of the transport layer is the transport >> itself. >>> Data consistency is not the task of the transport layer. ACK must be = done >>> on the application layer if you really want to be sure your message = has >>> been processed. >>> [..] >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Fri Jul 2 05:58:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1033A680F for ; Fri, 2 Jul 2010 05:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.567, 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 X5QANSHd4nNv for ; Fri, 2 Jul 2010 05:58:53 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DE23C3A67DA for ; Fri, 2 Jul 2010 05:58:52 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o62Cx1rS012802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 2 Jul 2010 15:59:01 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jul 2010 15:59:03 +0300 Message-Id: To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] -01 preview for implementors? 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 Jul 2010 12:58:54 -0000 We are getting pretty close to finishing up coap-01, I expect to submit = this by next Wednesday. The plugfest in Maastricht is coming fast, so = any implementors who need a preview before Wednesday to get started - = just drop me an e-mail. People should be able to participate in the = plugfest also remotely (IPv6, IPv4, Jabber), so not being there in = person is no excuse! =20 The minimum for participating is to implement the mandatory parts of = coap-01 which have become even simpler compared to coap-00. The = intention is also that the header and fields will not change after = coap-01, so this will be a safe version to try out. Some of us will try = to put servers on-line to test against as well soon after coap-01 is = released.=20 Zach =20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From d.sturek@att.net Fri Jul 2 06:01:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B95E3A68E7 for ; Fri, 2 Jul 2010 06:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[AWL=1.467, BAYES_00=-2.599, 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 L9HSpk87fqyE for ; Fri, 2 Jul 2010 06:01:30 -0700 (PDT) Received: from smtp105.sbc.mail.gq1.yahoo.com (smtp105.sbc.mail.gq1.yahoo.com [67.195.14.108]) by core3.amsl.com (Postfix) with SMTP id 8174C3A6855 for ; Fri, 2 Jul 2010 06:01:25 -0700 (PDT) Received: (qmail 55786 invoked from network); 2 Jul 2010 13:01:34 -0000 Received: from adsl-69-105-139-124.dsl.sndg02.pacbell.net (d.sturek@69.105.139.124 with login) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 02 Jul 2010 06:01:34 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 34GA1TUVM1nEf4pG1t1CiP.jaSvf5Ww6yqGyEtV2Bs.k4QmRFTrzD0BT4HW701GuJK10sKXwsq1Scz9UFlF3FHf1fXEcL55_MN83zAd3o6Anz0W5QjM5Sm152gNDmohR4kzqDk6ia0jUtHZ6tNrBDY9Y1SZkYPwcuNciVqviYNG_.7vaThAbI2xfpXJFz1RPpGKccwIwfsyx1DHmUamHSaMzBTmBKsFCdl8_4ZyKCAGn4jFA5thnlKT3VDiivj5EfuDn2MazXV60nMh34BbdU.RCHaSzAKzMPPmzQ_7_kTktgsggJ6jRZSh.fUwQWhBm7DP1t7vCSnjvGJ1DbnE3uw-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <006701cb19e5$316d6850$944838f0$@sturek@att.net> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> In-Reply-To: <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> Date: Fri, 2 Jul 2010 06:01:26 -0700 Message-ID: <007f01cb19e6$ae88bb40$0b9a31c0$@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: AcsZ5ihUeYUHUxNLQc+JUMApRKqhAQAADmgQ Content-Language: en-us Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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, 02 Jul 2010 13:01:32 -0000 Hi Zach, On the length, for IEEE 802.15.4 using 6LowPAN, I think we have around = 50 or so bytes to work with in the first block (application wise). If that = fits all the data you want to send that is great. However, many solutions = need more. Even if the application architects its control packets to fit = into those 50 bytes, the application may need to do reporting/etc which will cause at least a portion of those packets to be fragmented. Don -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Friday, July 02, 2010 5:58 AM To: d.sturek@att.net Cc: 'Guido Moritz'; core@ietf.org; L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP Morning Don, On Jul 2, 2010, at 3:50 PM, Don Sturek wrote: > Hi Zach, >=20 > I think what you wrote is not quite correct. >=20 > I think many solutions will need guaranteed delivery Agreed, and we have that. > and I think many will > need fragmentation/reassembly. =20 This is something we still need to experiment with and gain experience. = Can applications that need that do it themselves? Or is the Block Option proposal in coap-misc-04 workable? If the WG concludes that we need it = and we have a way to do it then we surely will. > Only a small subset of solutions will work > with CoAP/UDP and all application messaging fitting into a single = packet. How did we go from transferring payloads in the sizes of 10s of bytes, = to several kBs in this WG? ;-) coap-01 requires this to fit in a single = MTU, which would usually be between 1280-1500 bytes. At least for all the applications I have experience with in the 6LoWPAN world this is = sufficient. For the few things like firmware transfer that need more, you can design = a REST interface for that. What do you have in mind? >=20 > The reason I mention this is that I fully expect to see a need in some = of > the features that TCP offers though I agree that congestion control in = a > mesh network is not one of them (at least as implemented in TCP). Yep, Lars's document has a really good list of stuff we need to = experiment with and integrate into the base coap document as they are verified. We = hope to try some out already at the plugfest. Zach >=20 > Don >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Zach > Shelby > Sent: Friday, July 02, 2010 3:50 AM > To: Guido Moritz > Cc: core@ietf.org; L.Wood@surrey.ac.uk > Subject: Re: [core] CoRE v/s Compressed HTTP >=20 > Regarding UDP and congestion control, I really think everyone should = read > the contribution from Lars: >=20 > http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt >=20 > One main point is that the whole congestion control model of TCP = wouldn't > really help us, the flow model is totally different here. The other = issue we > have in CoRE is that not all requests even need to be (or should be) > reliable - e.g. multicast or streaming. >=20 > The current coap-01 limitation on CoAP message size is that the = resulting > datagram must fit into the MTU. For 95% of the cases this payload size = is > sufficient. For that 5% (firmware update?), which I am personally not = sure > we should optimize for, coap-misc-04 does have a proposed block option = to > enabled transferring blocks of a representation. This is something to > experiment with.=20 >=20 > Zach >=20 > On Jul 2, 2010, at 1:26 PM, Guido Moritz wrote: >=20 >>> "Clearly, some effort at the lower levels to improve network = reliability >>> can have a significant effect on >>> application performance." >> Jep, but from the CoAP point of view I would say this is what brings = us >> closer to UDP than to TCP. TCP uses ACKs and Retransmissions to get = some >> kind of reliability. But keep in mind that CoAP (and I assume it = does) has >> no huge packets on application layer. Of course, if application = layer >> packets are much bigger than transport layer packets, the ACK/Retr > mechanism >> on transport layer is a huge advantage concerning performance issues. = But > I >> think CoAP is more heading towards smaller packets. So packet size on >> application and transport layer might have the same size and thus an >> application packet fits in one transport packet. So there would be no need >> for the TCP ACK/Retr of stuff TCP and you can do this on application layer >> directly with the same efforts and higher degree of reliability ('Did = it' >> vs. 'Got it'). So the main question at this point: which = message/packet >> sizes do we assume for a single request/response/transmission/what = ever. >>=20 >> The other side of the coin would the checksum mechanism of TCP. Do we want >> to use this on our nodes or leave this up to other layers? >>=20 >> The last thing is the flow control/sliding window stuff. I think we = will > not >> really need this in CoAP due to quite small receive/send buffers = implied > by >> the resource constraints. >>=20 >> Guido >>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] >>> Gesendet: Freitag, 2. Juli 2010 11:37 >>> An: Guido Moritz >>> Cc: core@ietf.org >>> Betreff: RE: [core] CoRE v/s Compressed HTTP >>>=20 >>> Yes, only a high-layer check can guarantee that what was sent is = what was >>> received, without corruption. >>> But to quote saltzer et al.: >>> "Clearly, some effort at the lower levels to improve network = reliability >>> can have a significant effect on >>> application performance." >>> So transport-layer data consistency can benefit implementations. >>>=20 >>> It's a series of tradeoffs and engineering decisions, not = necessarily >>> clear-cut. >>>=20 >>> L. >>>=20 >>> There is no end to the end-to-end argument. >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >>> Guido Moritz >>> Sent: 02 July 2010 10:25 >>>=20 >>> [..] >>> (2) CoAP want's to use UDP instead of TCP. First I also did not = found an >>> obvious reason, until I read Saltzer et al. [1]. As long as we not = need >> the >>> flow control mechanisms of TCP and we keep the packet sizes = reasonable >>> small enough, the only task of the transport layer is the transport >> itself. >>> Data consistency is not the task of the transport layer. ACK must be done >>> on the application layer if you really want to be sure your message = has >>> been processed. >>> [..] >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Fri Jul 2 06:04:41 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 77BE93A6855 for ; Fri, 2 Jul 2010 06:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[AWL=0.541, 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 305wRu+Sl0HW for ; Fri, 2 Jul 2010 06:04:40 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 08D753A6853 for ; Fri, 2 Jul 2010 06:04:39 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o62D4kdY013644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 16:04:46 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <007f01cb19e6$ae88bb40$0b9a31c0$@sturek@att.net> Date: Fri, 2 Jul 2010 16:04:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <006701cb19e5$316d6850$944838f0$@sturek@att.net> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> <007f01cb19e6$ae88bb40$0b9a31c0$@sturek@att.net> To: X-Mailer: Apple Mail (2.1081) Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 13:04:41 -0000 On Jul 2, 2010, at 4:01 PM, Don Sturek wrote: > On the length, for IEEE 802.15.4 using 6LowPAN, I think we have around = 50 or > so bytes to work with in the first block (application wise). If that = fits > all the data you want to send that is great. However, many solutions = need > more. Even if the application architects its control packets to fit = into > those 50 bytes, the application may need to do reporting/etc which = will > cause at least a portion of those packets to be fragmented. Ahhh, now I see what you mean. As CoAP is at the application layer it = doesn't limit the size of a CoAP message to a single link-layer frame, = but instead to the IPv6 MTU. However, there is a recommendation in the = draft that says a message SHOULD fit into an 802.15.4 frame if possible = to avoid the penalty of fragmentation.=20 We can adjust that text if you think that SHOULD is too strong?=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From d.sturek@att.net Fri Jul 2 06:16: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 235873A67D9 for ; Fri, 2 Jul 2010 06:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.285 X-Spam-Level: X-Spam-Status: No, score=0.285 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, 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 NMeEzV4sI3a3 for ; Fri, 2 Jul 2010 06:16:32 -0700 (PDT) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id 015B13A68BE for ; Fri, 2 Jul 2010 06:16:16 -0700 (PDT) Received: (qmail 31202 invoked from network); 2 Jul 2010 13:16:24 -0000 Received: from adsl-69-105-139-124.dsl.sndg02.pacbell.net (d.sturek@69.105.139.124 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 02 Jul 2010 06:16:23 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 2LHC4VkVM1k_Ci9jiPjkWRxGsIq.BzgHcuRmVKKnbNWpVyWZjP7Jnbn586PpmISmQZwQirt_h3y_3UBIT6Y2RPbnAMRqfRBDen4oEhVeLZEMXfZQGGqV_DqGNZvA_65vTR_1K3GsjBqp3DMkv3xDsLqOEBLnlt_oTwYxZgSqjvYsS5gIjSxUdsT3Dr42tTRvpUheYOX40ezcDuLZbncjqhBuBrh0Q0GF40EomAMu7MuwMuoalOsqWHU_T6mnl0rZ8Dr1k8todt4J7t3PEB9V2MUKHMdDZ50kSAetywvE5wtLMyOGcw-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <006701cb19e5$316d6850$944838f0$@sturek@att.net> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> <007f01cb19e6$ae88bb40$0b9a31c0$@sturek@att.net> In-Reply-To: Date: Fri, 2 Jul 2010 06:16:15 -0700 Message-ID: <008701cb19e8$c098af50$41ca0df0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsZ5yuckqOl8aBBQnOGZsf0us7qdwAAVlmw Content-Language: en-us Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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, 02 Jul 2010 13:16:34 -0000 At least for our SE 2 application, we will clearly see fragmented packets. We have several types of data that will drive this: 1) Reports 2) Lists of events (certainly you can control how many you ask for but at least once you need to get the list of what you can ask for) Don -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Friday, July 02, 2010 6:05 AM To: d.sturek@att.net Cc: 'Guido Moritz'; core@ietf.org; L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP On Jul 2, 2010, at 4:01 PM, Don Sturek wrote: > On the length, for IEEE 802.15.4 using 6LowPAN, I think we have around 50 or > so bytes to work with in the first block (application wise). If that fits > all the data you want to send that is great. However, many solutions need > more. Even if the application architects its control packets to fit into > those 50 bytes, the application may need to do reporting/etc which will > cause at least a portion of those packets to be fragmented. Ahhh, now I see what you mean. As CoAP is at the application layer it doesn't limit the size of a CoAP message to a single link-layer frame, but instead to the IPv6 MTU. However, there is a recommendation in the draft that says a message SHOULD fit into an 802.15.4 frame if possible to avoid the penalty of fragmentation. We can adjust that text if you think that SHOULD is too strong? Zach -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From robby.simpson@ge.com Fri Jul 2 06:45: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 177353A67C2 for ; Fri, 2 Jul 2010 06:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[AWL=0.880, 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 4PUF+AfdaNWa for ; Fri, 2 Jul 2010 06:45:28 -0700 (PDT) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by core3.amsl.com (Postfix) with ESMTP id 366F43A684B for ; Fri, 2 Jul 2010 06:45:26 -0700 (PDT) Received: from source ([12.71.149.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKTC3tgRfQpCseFkbe9VoDop7+F1nK8Oal@postini.com; Fri, 02 Jul 2010 06:45:38 PDT Received: from unknown (HELO alpmlef01.e2k.ad.ge.com) ([3.159.18.10]) by Cinmlip09.e2k.ad.ge.com with ESMTP; 02 Jul 2010 09:45:35 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.50]) by alpmlef01.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 09:45:35 -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: Fri, 2 Jul 2010 09:45:36 -0400 Message-ID: In-Reply-To: <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoRE v/s Compressed HTTP Thread-Index: AcsY6i8IlpOI16XsToy9+rNtQezMrgA2/XHgAADZCsAAAZGToAAG7b2Q References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> From: "Simpson, Robby (GE Energy Services)" To: "Guido Moritz" , X-OriginalArrivalTime: 02 Jul 2010 13:45:35.0672 (UTC) FILETIME=[D92C3380:01CB19EC] Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 13:45:31 -0000 > The last thing is the flow control/sliding window stuff. I think we will not > really need this in CoAP due to quite small receive/send buffers implied by > the resource constraints. I think its useful to discuss flow control and congestion control separately (they are, in fact, quite different). I agree that many of the existing TCP congestion control algorithms have less-than-ideal behavior on wireless meshes, for instance. I further agree that if we keep the number of packets low and avoid links that have other flows, we may be able to get away with some less sophisticated congestion control algorithms for CoAp. Flow control, on the other hand, may be quite useful for constrained devices. As an example, my understanding is that the TCP flow control logic was intended to prevent more constrained devices from being overwhelmed by less constrained devices. TCP's advertisement of essentially free buffer space in the receiver is one useful way to achieve flow control. I would suggest we not dismiss such functionality as even amongst constrained devices some devices may be able to process 2 packets whereas another device may be able to process 3. - Robby From rdroms.ietf@gmail.com Fri Jul 2 07:25: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 21F3D3A67B7 for ; Fri, 2 Jul 2010 07:25: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 J2Mi+rLoxhtz for ; Fri, 2 Jul 2010 07:25:02 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 1CD773A679C for ; Fri, 2 Jul 2010 07:25:02 -0700 (PDT) Received: by qyk1 with SMTP id 1so366316qyk.10 for ; Fri, 02 Jul 2010 07:25:11 -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=tneGxXXyzIAgxMxUIaR5c9yaNMFWMUtaqYwVESeeWpk=; b=drT/stbk6cc+pqp1EB9iEMbDO6yAFUaevTeMvTwrJMTka5DV2Qb65mEq0ygno1hJmO H/cUmorRfKnK1nkm8+Uk75HWh3XvrjfQ4uKqm+N1jTwX4QsEQfWCy2Qx69t0HXn9mng6 dVxG95masWWF8ETH5hdD2ZNIRgf32NH3t4BkQ= 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=VJ7BVFwXQIqzR/BP03i4IwvVbq0ly1pPTfhfvt1EgUTcKoKPMKGlgmab5oTDOS2ntZ Mxd6zxVG1RQYw4natzwDnIJaiPzmMoATAuZZUeRH6iN+P7yw83nFJaPZ8n8+H/hzbFkw H/2t7dIJk1Df+XyNUt6X1BArpiOUv6NefcpKE= Received: by 10.224.20.77 with SMTP id e13mr452424qab.111.1278080711079; Fri, 02 Jul 2010 07:25:11 -0700 (PDT) Received: from [192.168.1.105] (c-24-91-221-214.hsd1.ma.comcast.net [24.91.221.214]) by mx.google.com with ESMTPS id j28sm2793824qck.23.2010.07.02.07.25.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 07:25:10 -0700 (PDT) References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> Message-Id: <603B58DF-C2AB-449F-8100-8CBB376FC56F@gmail.com> From: Ralph Droms To: "Simpson, Robby (GE Energy Services)" In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B367) Mime-Version: 1.0 (iPad Mail 7B367) Date: Fri, 2 Jul 2010 10:25:59 -0400 Cc: "core@ietf.org" , "" Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 14:25:03 -0000 Robby - you're correct in pointing out the flow control and congestion = control are separate components of TCP. In one special case, flow control can be used as a primitive form of = congestion control. If the receive window is set to one MSS, TCP = becomes a send-and-wait protocol. What is the concern with TCP congestion control: * performance, * code size, * something else? Do we have performance information on 6lowpan adaptation layer = fragmentation? Is It possible that TCP, with a very small MSS, would = provide better performance for traffic that won't fit in a 6lowpan frame = than either IP or 6lowpan fragmentation? - Ralph On Jul 2, 2010, at 9:45 AM, "Simpson, Robby (GE Energy Services)" = wrote: >> The last thing is the flow control/sliding window stuff. I think we > will not >> really need this in CoAP due to quite small receive/send buffers > implied by >> the resource constraints. >=20 > I think its useful to discuss flow control and congestion control > separately (they are, in fact, quite different). >=20 > I agree that many of the existing TCP congestion control algorithms = have > less-than-ideal behavior on wireless meshes, for instance. I further > agree that if we keep the number of packets low and avoid links that > have other flows, we may be able to get away with some less > sophisticated congestion control algorithms for CoAp. >=20 > Flow control, on the other hand, may be quite useful for constrained > devices. As an example, my understanding is that the TCP flow control > logic was intended to prevent more constrained devices from being > overwhelmed by less constrained devices. TCP's advertisement of > essentially free buffer space in the receiver is one useful way to > achieve flow control. I would suggest we not dismiss such = functionality > as even amongst constrained devices some devices may be able to = process > 2 packets whereas another device may be able to process 3. >=20 > - Robby > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From rdroms.ietf@gmail.com Fri Jul 2 07:29:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3FD3A68C0 for ; Fri, 2 Jul 2010 07:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 owjvKB6YbTwM for ; Fri, 2 Jul 2010 07:29: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 15FC43A68B9 for ; Fri, 2 Jul 2010 07:29:20 -0700 (PDT) Received: by vws14 with SMTP id 14so2187737vws.31 for ; Fri, 02 Jul 2010 07:29:30 -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=Bt1UUo5IbeOq72YWrfh4GQoJWpfn10Mz45nN8ZCCjv8=; b=GDrT+9HuFE4ETStGXn5eO8NDIbRwo0+sd9bknsNYugPKzvK8cXZDvPgVZfAKYg3Sfm ymK/9P5rhmOp96mhZVTBYdnBLHWing4IYiQD1bRbPpUzj/c/axNX2lPAZBcG2LICzqhK iqmJAliDsr3itnOKOHSJO7J/pL3AX94aeHTmo= 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=HF57SpxsEWsBsIfRq3SqoPhmxEJvsrdgTC/FcUAYzA5DI5U0yscrDSvOns4vlI1u+8 L4oMVXRRex3XOUPPpdT2iiQUYQFqPpq8DDPf9WkzqKrkqZD8FyNGE0ubu+jckiBd+A3T KvU1P8l54Zm6lEgOO1sIsQOIhppennLHQtFDc= Received: by 10.220.62.72 with SMTP id w8mr402151vch.201.1278080970249; Fri, 02 Jul 2010 07:29:30 -0700 (PDT) Received: from [10.98.10.82] (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id e20sm790841vcm.40.2010.07.02.07.29.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 07:29:29 -0700 (PDT) References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <603B58DF-C2AB-449F-8100-8CBB376FC56F@gmail.com> Message-Id: <4959564E-1C3E-445B-8D50-321723C02BC4@gmail.com> From: Ralph Droms To: Robby Simpson In-Reply-To: <603B58DF-C2AB-449F-8100-8CBB376FC56F@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B367) Mime-Version: 1.0 (iPad Mail 7B367) Date: Fri, 2 Jul 2010 10:30:17 -0400 Cc: "core@ietf.org" , "" Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 14:29:23 -0000 Being more specific about "performance": * network throughput * computation in the endpoint nodes - Ralph On Jul 2, 2010, at 10:25 AM, Ralph Droms wrote: > Robby - you're correct in pointing out the flow control and congestion = control are separate components of TCP. >=20 > In one special case, flow control can be used as a primitive form of = congestion control. If the receive window is set to one MSS, TCP = becomes a send-and-wait protocol. >=20 > What is the concern with TCP congestion control: > * performance, > * code size, > * something else? >=20 > Do we have performance information on 6lowpan adaptation layer = fragmentation? Is It possible that TCP, with a very small MSS, would = provide better performance for traffic that won't fit in a 6lowpan frame = than either IP or 6lowpan fragmentation? >=20 > - Ralph >=20 >=20 > On Jul 2, 2010, at 9:45 AM, "Simpson, Robby (GE Energy Services)" = wrote: >=20 >>> The last thing is the flow control/sliding window stuff. I think we >> will not >>> really need this in CoAP due to quite small receive/send buffers >> implied by >>> the resource constraints. >>=20 >> I think its useful to discuss flow control and congestion control >> separately (they are, in fact, quite different). >>=20 >> I agree that many of the existing TCP congestion control algorithms = have >> less-than-ideal behavior on wireless meshes, for instance. I further >> agree that if we keep the number of packets low and avoid links that >> have other flows, we may be able to get away with some less >> sophisticated congestion control algorithms for CoAp. >>=20 >> Flow control, on the other hand, may be quite useful for constrained >> devices. As an example, my understanding is that the TCP flow = control >> logic was intended to prevent more constrained devices from being >> overwhelmed by less constrained devices. TCP's advertisement of >> essentially free buffer space in the receiver is one useful way to >> achieve flow control. I would suggest we not dismiss such = functionality >> as even amongst constrained devices some devices may be able to = process >> 2 packets whereas another device may be able to process 3. >>=20 >> - Robby >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From hgs@cs.columbia.edu Fri Jul 2 07:35: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 C00BA3A6860 for ; Fri, 2 Jul 2010 07:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Qa3Kntu2hkMa for ; Fri, 2 Jul 2010 07:35:28 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 05C1E3A67DB for ; Fri, 2 Jul 2010 07:35:27 -0700 (PDT) Received: from dyn2060.panoulu.local (gw1.panoulu.net [212.50.147.101]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id o62EZPoh011025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 Jul 2010 10:35:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <008701cb19e8$c098af50$41ca0df0$@sturek@att.net> Date: Fri, 2 Jul 2010 10:35:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <006701cb19e5$316d6850$944838f0$@sturek@att.net> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> <007f01cb19e6$ae88bb40$0b9a31c0$@sturek@att.net> <008701cb19e8$c098af50$41ca0df0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1081) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: core@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 14:35:30 -0000 A basic law of protocol design: all messages start out small, but they = never get smaller. Corollary: even if you believe that you need only = small messages, somebody else will think of a good application for = larger ones - and won't be discouraged by the fact that you tell him = that the protocol wasn't designed for that.=20 (I can think of several high-visibility examples where this has been = true - DNS, DHCP and SIP-over-UDP come to mind immediately.) Henning On Jul 2, 2010, at 9:16 AM, Don Sturek wrote: > At least for our SE 2 application, we will clearly see fragmented = packets. > We have several types of data that will drive this: > 1) Reports > 2) Lists of events (certainly you can control how many you ask for = but at > least once you need to get the list of what you can ask for) >=20 > Don >=20 > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com]=20 > Sent: Friday, July 02, 2010 6:05 AM > To: d.sturek@att.net > Cc: 'Guido Moritz'; core@ietf.org; L.Wood@surrey.ac.uk > Subject: Re: [core] CoRE v/s Compressed HTTP >=20 >=20 > On Jul 2, 2010, at 4:01 PM, Don Sturek wrote: >=20 >> On the length, for IEEE 802.15.4 using 6LowPAN, I think we have = around 50 > or >> so bytes to work with in the first block (application wise). If that = fits >> all the data you want to send that is great. However, many solutions = need >> more. Even if the application architects its control packets to fit = into >> those 50 bytes, the application may need to do reporting/etc which = will >> cause at least a portion of those packets to be fragmented. >=20 >=20 > Ahhh, now I see what you mean. As CoAP is at the application layer it > doesn't limit the size of a CoAP message to a single link-layer frame, = but > instead to the IPv6 MTU. However, there is a recommendation in the = draft > that says a message SHOULD fit into an 802.15.4 frame if possible to = avoid > the penalty of fragmentation.=20 >=20 > We can adjust that text if you think that SHOULD is too strong?=20 >=20 > Zach=20 >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From L.Wood@surrey.ac.uk Fri Jul 2 07:41: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 2D1F33A68B9 for ; Fri, 2 Jul 2010 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.623, 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 refNH-UKgmkl for ; Fri, 2 Jul 2010 07:41:38 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 8F1373A67A4 for ; Fri, 2 Jul 2010 07:41:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-82.messagelabs.com!1278081708!9001551!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 3623 invoked from network); 2 Jul 2010 14:41:48 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-7.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 2 Jul 2010 14:41:48 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 2 Jul 2010 15:41:48 +0100 From: To: , Date: Fri, 2 Jul 2010 15:41:47 +0100 Thread-Topic: [core] CoRE v/s Compressed HTTP Thread-Index: AcsZ89sEH/w29o22RgGqNy+kvoOtXwAAMd4w Message-ID: References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <006701cb19e5$316d6850$944838f0$@sturek@att.net> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> <007f01cb19e6$ae88bb40$0b9a31c0$@sturek@att.net> <008701cb19e8$c098af50$41ca0df0$@sturek@att.net> 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] CoRE v/s Compressed HTTP 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 Jul 2010 14:41:40 -0000 Messages expand to overfill the space allocated for them.=20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: 02 July 2010 15:35 To: d.sturek@att.net Cc: 'Zach Shelby'; Wood L Dr (Electronic Eng); core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP Importance: High A basic law of protocol design: all messages start out small, but they neve= r get smaller. Corollary: even if you believe that you need only small mess= ages, somebody else will think of a good application for larger ones - and = won't be discouraged by the fact that you tell him that the protocol wasn't= designed for that.=20 (I can think of several high-visibility examples where this has been true -= DNS, DHCP and SIP-over-UDP come to mind immediately.) Henning On Jul 2, 2010, at 9:16 AM, Don Sturek wrote: > At least for our SE 2 application, we will clearly see fragmented packets= . > We have several types of data that will drive this: > 1) Reports > 2) Lists of events (certainly you can control how many you ask for=20 > but at least once you need to get the list of what you can ask for) >=20 > Don >=20 > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: Friday, July 02, 2010 6:05 AM > To: d.sturek@att.net > Cc: 'Guido Moritz'; core@ietf.org; L.Wood@surrey.ac.uk > Subject: Re: [core] CoRE v/s Compressed HTTP >=20 >=20 > On Jul 2, 2010, at 4:01 PM, Don Sturek wrote: >=20 >> On the length, for IEEE 802.15.4 using 6LowPAN, I think we have=20 >> around 50 > or >> so bytes to work with in the first block (application wise). If that=20 >> fits all the data you want to send that is great. However, many=20 >> solutions need more. Even if the application architects its control=20 >> packets to fit into those 50 bytes, the application may need to do=20 >> reporting/etc which will cause at least a portion of those packets to be= fragmented. >=20 >=20 > Ahhh, now I see what you mean. As CoAP is at the application layer it=20 > doesn't limit the size of a CoAP message to a single link-layer frame,=20 > but instead to the IPv6 MTU. However, there is a recommendation in the=20 > draft that says a message SHOULD fit into an 802.15.4 frame if=20 > possible to avoid the penalty of fragmentation. >=20 > We can adjust that text if you think that SHOULD is too strong?=20 >=20 > Zach >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From d.sturek@att.net Fri Jul 2 07:53:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875F33A6876 for ; Fri, 2 Jul 2010 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_05=-1.11, 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 lqiO-ZtHZuSq for ; Fri, 2 Jul 2010 07:53:41 -0700 (PDT) Received: from smtp104.sbc.mail.gq1.yahoo.com (smtp104.sbc.mail.gq1.yahoo.com [67.195.15.63]) by core3.amsl.com (Postfix) with SMTP id C263B3A67B8 for ; Fri, 2 Jul 2010 07:53:41 -0700 (PDT) Received: (qmail 56847 invoked from network); 2 Jul 2010 14:53:51 -0000 Received: from wsip-174-78-56-227.sd.sd.cox.net (d.sturek@174.78.56.227 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 02 Jul 2010 07:53:51 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Fn3S5oAVM1kVgjHiwnnUiRSvDh.9.aZQ7Z5hi87CweD.li7dGNqhME5ih3M6JsNIV8.eFDiy6rmxMP8OTrodeeG.vj2ohFgz_8gObO1yvUJ2ago_vEb8AbLBl9x.ROzzz2ZmUoC1mkwfz4XTC3yb7nEVUc24Ugpb4dztKaL8QVuKK6SpeUemDhjoiLN6WVna45KWym149E31vaO6MPd88clQPuSB9xflRJTRu6tq5UWavjBPp0BDU20fsKG6FZ094byj5iTbme1pY59oKwzJ1o.vgOS6xLfSpWM5lJebe3UzceUuGeU- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Simpson, Robby \(GE Energy Services\)'" , "'Guido Moritz'" , References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> In-Reply-To: Date: Fri, 2 Jul 2010 07:53:42 -0700 Message-ID: <002c01cb19f6$5dc85390$1958fab0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsY6i8IlpOI16XsToy9+rNtQezMrgA2/XHgAADZCsAAAZGToAAG7b2QAAKsjfA= Content-Language: en-us Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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, 02 Jul 2010 14:53:42 -0000 Hi Robby, Agree completely on flow control in TCP. I guess my point is almost immediately after finishing CoAP over UDP, we will begin to add back features of TCP. I would list fragmentation/reassembly, guaranteed delivery and flow control into that list. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Simpson, Robby (GE Energy Services) Sent: Friday, July 02, 2010 6:46 AM To: Guido Moritz; L.Wood@surrey.ac.uk Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP > The last thing is the flow control/sliding window stuff. I think we will not > really need this in CoAP due to quite small receive/send buffers implied by > the resource constraints. I think its useful to discuss flow control and congestion control separately (they are, in fact, quite different). I agree that many of the existing TCP congestion control algorithms have less-than-ideal behavior on wireless meshes, for instance. I further agree that if we keep the number of packets low and avoid links that have other flows, we may be able to get away with some less sophisticated congestion control algorithms for CoAp. Flow control, on the other hand, may be quite useful for constrained devices. As an example, my understanding is that the TCP flow control logic was intended to prevent more constrained devices from being overwhelmed by less constrained devices. TCP's advertisement of essentially free buffer space in the receiver is one useful way to achieve flow control. I would suggest we not dismiss such functionality as even amongst constrained devices some devices may be able to process 2 packets whereas another device may be able to process 3. - Robby _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From rgm@labs.htt-consult.com Fri Jul 2 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 11C5F3A68D6 for ; Fri, 2 Jul 2010 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq5MDky++BK0 for ; Fri, 2 Jul 2010 08:01:43 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 376083A682A for ; Fri, 2 Jul 2010 08:01:43 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0D80468B4F; Fri, 2 Jul 2010 14:53:46 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMjkemEQndnP; Fri, 2 Jul 2010 10:53:35 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 858C668B4B; Fri, 2 Jul 2010 10:53:35 -0400 (EDT) Message-ID: <4C2DFF55.9090304@labs.htt-consult.com> Date: Fri, 02 Jul 2010 11:01:41 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <006701cb19e5$316d6850$944838f0$@sturek@att.net> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> <007f01cb19e6$ae88bb40$0b9a31c0$@sturek@att.net> <008701cb19e8$c098af50$41ca0df0$@sturek@att.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060705040005090103040909" Cc: core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 15:01:45 -0000 This is a multi-part message in MIME format. --------------060705040005090103040909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/02/2010 10:41 AM, L.Wood@surrey.ac.uk wrote: > Messages expand to overfill the space allocated for them. > Thus UDP jumbograms were born. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 02 July 2010 15:35 > To: d.sturek@att.net > Cc: 'Zach Shelby'; Wood L Dr (Electronic Eng); core@ietf.org > Subject: Re: [core] CoRE v/s Compressed HTTP > Importance: High > > A basic law of protocol design: all messages start out small, but they never get smaller. Corollary: even if you believe that you need only small messages, somebody else will think of a good application for larger ones - and won't be discouraged by the fact that you tell him that the protocol wasn't designed for that. > > (I can think of several high-visibility examples where this has been true - DNS, DHCP and SIP-over-UDP come to mind immediately.) > > Henning > > On Jul 2, 2010, at 9:16 AM, Don Sturek wrote: > > >> At least for our SE 2 application, we will clearly see fragmented packets. >> We have several types of data that will drive this: >> 1) Reports >> 2) Lists of events (certainly you can control how many you ask for >> but at least once you need to get the list of what you can ask for) >> >> Don >> >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: Friday, July 02, 2010 6:05 AM >> To: d.sturek@att.net >> Cc: 'Guido Moritz'; core@ietf.org; L.Wood@surrey.ac.uk >> Subject: Re: [core] CoRE v/s Compressed HTTP >> >> >> On Jul 2, 2010, at 4:01 PM, Don Sturek wrote: >> >> >>> On the length, for IEEE 802.15.4 using 6LowPAN, I think we have >>> around 50 >>> >> or >> >>> so bytes to work with in the first block (application wise). If that >>> fits all the data you want to send that is great. However, many >>> solutions need more. Even if the application architects its control >>> packets to fit into those 50 bytes, the application may need to do >>> reporting/etc which will cause at least a portion of those packets to be fragmented. >>> >> >> Ahhh, now I see what you mean. As CoAP is at the application layer it >> doesn't limit the size of a CoAP message to a single link-layer frame, >> but instead to the IPv6 MTU. However, there is a recommendation in the >> draft that says a message SHOULD fit into an 802.15.4 frame if >> possible to avoid the penalty of fragmentation. >> >> We can adjust that text if you think that SHOULD is too strong? >> >> Zach >> >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > -- Robert Moskowitz Senior Technical Director ICSA Labs, an Independent Division of Verizon Business Systems W: 248-968-9809 F: 248-968-2824 VoIP: 248-291-0713 E: robert.moskowitz@icsalabs.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------060705040005090103040909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 07/02/2010 10:41 AM, L.Wood@surrey.ac.uk wrote: 
Messages expand to overfill the space allocated for them.

Thus UDP jumbograms were born.

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] 
Sent: 02 July 2010 15:35
To: d.sturek@att.net
Cc: 'Zach Shelby'; Wood L Dr (Electronic Eng); core@ietf.org
Subject: Re: [core] CoRE v/s Compressed HTTP
Importance: High

A basic law of protocol design: all messages start out small, but they never get smaller. Corollary: even if you believe that you need only small messages, somebody else will think of a good application for larger ones - and won't be discouraged by the fact that you tell him that the protocol wasn't designed for that. 

(I can think of several high-visibility examples where this has been true - DNS, DHCP and SIP-over-UDP come to mind immediately.)

Henning

On Jul 2, 2010, at 9:16 AM, Don Sturek wrote:

  
At least for our SE 2 application, we will clearly see fragmented packets.
We have several types of data that will drive this:
1)  Reports
2)  Lists of events (certainly you can control how many you ask for 
but at least once you need to get the list of what you can ask for)

Don

-----Original Message-----
From: Zach Shelby [mailto:zach@sensinode.com]
Sent: Friday, July 02, 2010 6:05 AM
To: d.sturek@att.net
Cc: 'Guido Moritz'; core@ietf.org; L.Wood@surrey.ac.uk
Subject: Re: [core] CoRE v/s Compressed HTTP


On Jul 2, 2010, at 4:01 PM, Don Sturek wrote:

    
On the length, for IEEE 802.15.4 using 6LowPAN, I think we have 
around 50
      
or
    
so bytes to work with in the first block (application wise).  If that 
fits all the data you want to send that is great.  However, many 
solutions need more.  Even if the application architects its control 
packets to fit into those 50 bytes, the application may need to do 
reporting/etc which will cause at least a portion of those packets to be fragmented.
      

Ahhh, now I see what you mean. As CoAP is at the application layer it 
doesn't limit the size of a CoAP message to a single link-layer frame, 
but instead to the IPv6 MTU. However, there is a recommendation in the 
draft that says a message SHOULD fit into an 802.15.4 frame if 
possible to avoid the penalty of fragmentation.

We can adjust that text if you think that SHOULD is too strong? 

Zach

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

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

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

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

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------060705040005090103040909-- From richard.kelsey@ember.com Fri Jul 2 08:42:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559E53A68E9 for ; Fri, 2 Jul 2010 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HocWc9+aUDAd for ; Fri, 2 Jul 2010 08:42:37 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 838683A67B8 for ; Fri, 2 Jul 2010 08:42:37 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 11:42:49 -0400 Date: Fri, 02 Jul 2010 11:49:02 -0400 Message-Id: <87sk41hok1.fsf@kelsey-ws.hq.ember.com> To: Ralph Droms In-reply-to: <603B58DF-C2AB-449F-8100-8CBB376FC56F@gmail.com> (message from Ralph Droms on Fri, 2 Jul 2010 10:25:59 -0400) From: Richard Kelsey References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <603B58DF-C2AB-449F-8100-8CBB376FC56F@gmail.com> X-OriginalArrivalTime: 02 Jul 2010 15:42:49.0017 (UTC) FILETIME=[395F7A90:01CB19FD] Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 15:42:38 -0000 > From: Ralph Droms > Date: Fri, 2 Jul 2010 10:25:59 -0400 > > What is the concern with TCP congestion control: > * performance, > * code size, > * something else? > > Do we have performance information on 6lowpan adaptation layer > fragmentation? Is It possible that TCP, with a very small MSS, would > provide better performance for traffic that won't fit in a 6lowpan > frame than either IP or 6lowpan fragmentation? Ralph, One of the advantages of using 6lowpan fragmentation is that the IPv6 header, TCP header, and TLS header and MAC (or other security) do not get duplicated in each fragment. This increases the available bandwidth and reduces the processing overhead. Sending a single TCP+TLS packet that fills two 6lowpan fragments rather than two unfragmented TCP+TLS packets switches 40+ bytes from being overhead to being payload. Given that those two unfragmented packets have maybe 60 bytes of TCP payload each, that is a big difference, as is having to process only half as many TLS records. -Richard Kelsey From pab@peoplepowerco.com Fri Jul 2 08:43: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 2E3DF3A67B2 for ; Fri, 2 Jul 2010 08:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cdzfzs5xxjR for ; Fri, 2 Jul 2010 08:43:02 -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 CAFC43A6452 for ; Fri, 2 Jul 2010 08:43:01 -0700 (PDT) Received: by vws14 with SMTP id 14so2261522vws.31 for ; Fri, 02 Jul 2010 08:43:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.203 with SMTP id l11mr457629vcs.265.1278085389906; Fri, 02 Jul 2010 08:43:09 -0700 (PDT) Received: by 10.220.105.137 with HTTP; Fri, 2 Jul 2010 08:43:09 -0700 (PDT) In-Reply-To: <-4101135245704635182@unknownmsgid> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> <-4101135245704635182@unknownmsgid> Date: Fri, 2 Jul 2010 10:43:09 -0500 Message-ID: From: Peter Bigot To: d.sturek@att.net Content-Type: multipart/alternative; boundary=e0cb4e887c8da87289048a697165 Cc: core@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 15:43:03 -0000 --e0cb4e887c8da87289048a697165 Content-Type: text/plain; charset=ISO-8859-1 I had understood CoAP to be an application-layer protocol that assumes a datagram-based transport. This has a fundamental impact on its architecture. Extending CoAP to make it pretend to be a stream-oriented protocol seems like a mistake. An IEEE 802.15.4 MTU is clearly too small to be useful at the application layer; the IPv6 MTU is better, but still arbitrary. Why encode these limitations into CoAP? Instead, select some defensible message limit (64KB, like UDP), so we know how many bits to reserve for length fields. Make some non-normative recommendations for common platforms and use cases like IEEE 802.15.4. For the rest of it, delegate responsibility for meeting the length requirements to the transport-layer and/or system designer. IPv6 already knows how to do fragment reassembly; other transport-layer protocols could be used to solve the problem too. I don't think replicating this sort of feature should be added to CoAP's task set. It'd be kinda like implementing telnet over HTTP: technically possible, but for heaven's sake *why*? Peter On Fri, Jul 2, 2010 at 8:16 AM, Don Sturek wrote: > At least for our SE 2 application, we will clearly see fragmented packets. > We have several types of data that will drive this: > 1) Reports > 2) Lists of events (certainly you can control how many you ask for but at > least once you need to get the list of what you can ask for) > > Don > > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: Friday, July 02, 2010 6:05 AM > To: d.sturek@att.net > Cc: 'Guido Moritz'; core@ietf.org; L.Wood@surrey.ac.uk > Subject: Re: [core] CoRE v/s Compressed HTTP > > > On Jul 2, 2010, at 4:01 PM, Don Sturek wrote: > > > On the length, for IEEE 802.15.4 using 6LowPAN, I think we have around 50 > or > > so bytes to work with in the first block (application wise). If that > fits > > all the data you want to send that is great. However, many solutions > need > > more. Even if the application architects its control packets to fit into > > those 50 bytes, the application may need to do reporting/etc which will > > cause at least a portion of those packets to be fragmented. > > > Ahhh, now I see what you mean. As CoAP is at the application layer it > doesn't limit the size of a CoAP message to a single link-layer frame, but > instead to the IPv6 MTU. However, there is a recommendation in the draft > that says a message SHOULD fit into an 802.15.4 frame if possible to avoid > the penalty of fragmentation. > > We can adjust that text if you think that SHOULD is too strong? > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --e0cb4e887c8da87289048a697165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had understood CoAP to be an application-layer protocol that assumes a da= tagram-based transport.=A0 This has a fundamental impact on its architectur= e.

Extending CoAP to make it pretend to be a stream-oriented protoco= l seems like a mistake.

An IEEE 802.15.4 MTU is clearly too small to be useful at the applicati= on layer; the IPv6 MTU is better, but still arbitrary.=A0 Why encode these = limitations into CoAP?=A0 Instead, select some defensible message limit (64= KB, like UDP), so we know how many bits to reserve for length fields.=A0 Ma= ke some non-normative recommendations for common platforms and use cases li= ke IEEE 802.15.4.

For the rest of it, delegate responsibility for meeting the length requ= irements to the transport-layer and/or system designer.=A0 IPv6 already kno= ws how to do fragment reassembly; other transport-layer protocols could be = used to solve the problem too.=A0 I don't think replicating this sort o= f feature should be added to CoAP's task set.=A0 It'd be kinda like= implementing telnet over HTTP: technically possible, but for heaven's = sake *why*?

Peter

On Fri, Jul 2, 2010 at 8:16 AM,= Don Sturek <d.stu= rek@att.net> wrote:
At least for our SE 2 application, we will clearly see fragmented packets.<= br> We have several types of data that will drive this:
1) =A0Reports
2) =A0Lists of events (certainly you can control how many you ask for but a= t
least once you need to get the list of what you can ask for)

Don

-----Original Message-----
From: Zach Shelby [mailto:zach@sensin= ode.com]
Sent: Friday, July 02, 2010 6:05 AM
To: d.sturek@att.net
Cc: 'Guido Moritz'; core@ietf.org; L.Wood@= surrey.ac.uk
Subject: Re: [core] CoRE v/s Compressed HTTP


On Jul 2, 2010, at 4:01 PM, Don Stu= rek wrote:

> On the length, for IEEE 802.15.4 using 6LowPAN, I think we have around= 50
or
> so bytes to work with in the first block (application wise). =A0If tha= t fits
> all the data you want to send that is great. =A0However, many solution= s need
> more. =A0Even if the application architects its control packets to fit= into
> those 50 bytes, the application may need to do reporting/etc which wil= l
> cause at least a portion of those packets to be fragmented.


Ahhh, now I see what you mean. As CoAP is at the application layer it
doesn't limit the size of a CoAP message to a single link-layer frame, = but
instead to the IPv6 MTU. However, there is a recommendation in the draft that says a message SHOULD fit into an 802.15.4 frame if possible to avoid<= br> the penalty of fragmentation.

We can adjust that text if you think that SHOULD is too strong?

Zach

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

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

--e0cb4e887c8da87289048a697165-- From rdroms.ietf@gmail.com Fri Jul 2 08:44:02 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 C5C3E3A67B2 for ; Fri, 2 Jul 2010 08:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HItV7yM4XvGr for ; Fri, 2 Jul 2010 08:44:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id D6B503A6452 for ; Fri, 2 Jul 2010 08:44:01 -0700 (PDT) Received: by pzk36 with SMTP id 36so737746pzk.31 for ; Fri, 02 Jul 2010 08:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=DS0GTCfJ5ODSDP2zAVqxzO9t1V7LhtnLvr4Juh86lU0=; b=WMX07P+t6q+CS1KqEaf//eQ390OR1PklLz+QaScaMfRA54nD0qCK1jTwGtTOQsulV9 5Wq4UaWJEo3rsoFOlvZ63A6/gChXaA1HdXIlI9vUxZm2MvHfekaP9Y7VKXx6r+Pjj2sQ 8SCDhKKedCTXI02iVAEtxqgaJynxSnwvRehqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=drBcpfbeAA2jVFWlc7XyHyM4jHRBe3La+ZR8W08tIXvyMVVrUJvRBJz43q0PpyVVN0 W1PoDw65LxJ1nxvL4UABswDMVpVAvrtSC68W4Lpklk0Mj4vbROGF5QKt+uhS3wrS5+Mc 3zWJby8K51h9m/K4qFV2duNzt+WJtzySjqmgw= Received: by 10.142.217.6 with SMTP id p6mr1317514wfg.24.1278085450400; Fri, 02 Jul 2010 08:44:10 -0700 (PDT) Received: from [10.21.108.85] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id c26sm880166rvf.3.2010.07.02.08.44.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 08:44:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <87sk41hok1.fsf@kelsey-ws.hq.ember.com> Date: Fri, 2 Jul 2010 11:44:04 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4FB8E24E-8F39-4885-BE87-8DD5F238451F@gmail.com> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <603B58DF-C2AB-449F-8100-8CBB376FC56F@gmail.com> <87sk41hok1.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1078) Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 15:44:03 -0000 Does 6lopwan fragmentation require reassembly at each intermediate node? - Ralph On Jul 2, 2010, at 11:49 AM 7/2/10, Richard Kelsey wrote: >> From: Ralph Droms >> Date: Fri, 2 Jul 2010 10:25:59 -0400 >> >> What is the concern with TCP congestion control: >> * performance, >> * code size, >> * something else? >> >> Do we have performance information on 6lowpan adaptation layer >> fragmentation? Is It possible that TCP, with a very small MSS, would >> provide better performance for traffic that won't fit in a 6lowpan >> frame than either IP or 6lowpan fragmentation? > > Ralph, > > One of the advantages of using 6lowpan fragmentation is that > the IPv6 header, TCP header, and TLS header and MAC (or > other security) do not get duplicated in each fragment. > This increases the available bandwidth and reduces the > processing overhead. Sending a single TCP+TLS packet that > fills two 6lowpan fragments rather than two unfragmented > TCP+TLS packets switches 40+ bytes from being overhead to > being payload. Given that those two unfragmented packets > have maybe 60 bytes of TCP payload each, that is a big > difference, as is having to process only half as many TLS > records. > -Richard Kelsey From zach@sensinode.com Fri Jul 2 08:44: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 12A4A3A67F0 for ; Fri, 2 Jul 2010 08:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 0DyQp+VwEl3Z for ; Fri, 2 Jul 2010 08:44:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A69883A6452 for ; Fri, 2 Jul 2010 08:44:38 -0700 (PDT) Received: from [192.168.1.3] (line-7650.dyn.kponet.fi [85.29.76.63]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o62FieRG029012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 18:44:40 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <002c01cb19f6$5dc85390$1958fab0$@sturek@att.net> Date: Fri, 2 Jul 2010 18:44:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <002c01cb19f6$5dc85390$1958fab0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 15:44:40 -0000 Please read = http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt and = then let's talk more about this, I found this a very useful draft. I = think we all agree that features for rate control, congestion control = and reliability that suit our charter requirements are needed.=20 Regarding TCP we already had WG consensus to remove that from the scope = of our work for now. Zach On Jul 2, 2010, at 5:53 PM, Don Sturek wrote: > Hi Robby, >=20 > Agree completely on flow control in TCP. >=20 > I guess my point is almost immediately after finishing CoAP over UDP, = we > will begin to add back features of TCP. I would list > fragmentation/reassembly, guaranteed delivery and flow control into = that > list. >=20 > Don >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Simpson, Robby (GE Energy Services) > Sent: Friday, July 02, 2010 6:46 AM > To: Guido Moritz; L.Wood@surrey.ac.uk > Cc: core@ietf.org > Subject: Re: [core] CoRE v/s Compressed HTTP >=20 >> The last thing is the flow control/sliding window stuff. I think we > will not >> really need this in CoAP due to quite small receive/send buffers > implied by >> the resource constraints. >=20 > I think its useful to discuss flow control and congestion control > separately (they are, in fact, quite different). >=20 > I agree that many of the existing TCP congestion control algorithms = have > less-than-ideal behavior on wireless meshes, for instance. I further > agree that if we keep the number of packets low and avoid links that > have other flows, we may be able to get away with some less > sophisticated congestion control algorithms for CoAp. >=20 > Flow control, on the other hand, may be quite useful for constrained > devices. As an example, my understanding is that the TCP flow control > logic was intended to prevent more constrained devices from being > overwhelmed by less constrained devices. TCP's advertisement of > essentially free buffer space in the receiver is one useful way to > achieve flow control. I would suggest we not dismiss such = functionality > as even amongst constrained devices some devices may be able to = process > 2 packets whereas another device may be able to process 3. >=20 > - Robby > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From rgm@labs.htt-consult.com Fri Jul 2 09:05:41 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 8F3693A68E3 for ; Fri, 2 Jul 2010 09:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 gyLd-gL-cqbD for ; Fri, 2 Jul 2010 09:05:40 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 900383A63D3 for ; Fri, 2 Jul 2010 09:05:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 3EAFE68B8C; Fri, 2 Jul 2010 15:57:15 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvyGLl6zU7Y7; Fri, 2 Jul 2010 11:57:03 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 43D7D68B43; Fri, 2 Jul 2010 11:57:03 -0400 (EDT) Message-ID: <4C2E0E35.9020104@labs.htt-consult.com> Date: Fri, 02 Jul 2010 12:05:09 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Bigot References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> <-4101135245704635182@unknownmsgid> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040107020808040302070503" Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 16:05:41 -0000 This is a multi-part message in MIME format. --------------040107020808040302070503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/02/2010 11:43 AM, Peter Bigot wrote: > I had understood CoAP to be an application-layer protocol that assumes > a datagram-based transport. This has a fundamental impact on its > architecture. Is there anyone here that is conversant with IEEE 11073? This is currently being used both in SmartGrid and in Medical BANs (why are not MBANs in the Req ID?) sensors and controllers. Is core competing with 11073 or going beyond it or what? BTW, upstream from the MBAN controllers in the Continua model is SOAP to HR7 systems. > > Extending CoAP to make it pretend to be a stream-oriented protocol > seems like a mistake. > > An IEEE 802.15.4 MTU is clearly too small to be useful at the > application layer; the IPv6 MTU is better, but still arbitrary. Why > encode these limitations into CoAP? Instead, select some defensible > message limit (64KB, like UDP), so we know how many bits to reserve > for length fields. Make some non-normative recommendations for common > platforms and use cases like IEEE 802.15.4. > > For the rest of it, delegate responsibility for meeting the length > requirements to the transport-layer and/or system designer. IPv6 > already knows how to do fragment reassembly; other transport-layer > protocols could be used to solve the problem too. I don't think > replicating this sort of feature should be added to CoAP's task set. > It'd be kinda like implementing telnet over HTTP: technically > possible, but for heaven's sake *why*? > > Peter > > On Fri, Jul 2, 2010 at 8:16 AM, Don Sturek > wrote: > > At least for our SE 2 application, we will clearly see fragmented > packets. > We have several types of data that will drive this: > 1) Reports > 2) Lists of events (certainly you can control how many you ask > for but at > least once you need to get the list of what you can ask for) > > Don > > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com > ] > Sent: Friday, July 02, 2010 6:05 AM > To: d.sturek@att.net > Cc: 'Guido Moritz'; core@ietf.org ; > L.Wood@surrey.ac.uk > Subject: Re: [core] CoRE v/s Compressed HTTP > > > On Jul 2, 2010, at 4:01 PM, Don Sturek wrote: > > > On the length, for IEEE 802.15.4 using 6LowPAN, I think we have > around 50 > or > > so bytes to work with in the first block (application wise). If > that fits > > all the data you want to send that is great. However, many > solutions need > > more. Even if the application architects its control packets to > fit into > > those 50 bytes, the application may need to do reporting/etc > which will > > cause at least a portion of those packets to be fragmented. > > > Ahhh, now I see what you mean. As CoAP is at the application layer it > doesn't limit the size of a CoAP message to a single link-layer > frame, but > instead to the IPv6 MTU. However, there is a recommendation in the > draft > that says a message SHOULD fit into an 802.15.4 frame if possible > to avoid > the penalty of fragmentation. > > We can adjust that text if you think that SHOULD is too strong? > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- Robert Moskowitz Senior Technical Director ICSA Labs, an Independent Division of Verizon Business Systems W: 248-968-9809 F: 248-968-2824 VoIP: 248-291-0713 E: robert.moskowitz@icsalabs.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------040107020808040302070503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/02/2010 11:43 AM, Peter Bigot wrote:
I had understood CoAP to be an application-layer protocol that assumes a datagram-based transport.  This has a fundamental impact on its architecture.

Is there anyone here that is conversant with IEEE 11073?  This is currently being used both in SmartGrid and in Medical BANs (why are not MBANs in the Req ID?) sensors and controllers.

Is core competing with 11073 or going beyond it or what?

BTW, upstream from the MBAN controllers in the Continua model is SOAP to HR7 systems.


Extending CoAP to make it pretend to be a stream-oriented protocol seems like a mistake.

An IEEE 802.15.4 MTU is clearly too small to be useful at the application layer; the IPv6 MTU is better, but still arbitrary.  Why encode these limitations into CoAP?  Instead, select some defensible message limit (64KB, like UDP), so we know how many bits to reserve for length fields.  Make some non-normative recommendations for common platforms and use cases like IEEE 802.15.4.

For the rest of it, delegate responsibility for meeting the length requirements to the transport-layer and/or system designer.  IPv6 already knows how to do fragment reassembly; other transport-layer protocols could be used to solve the problem too.  I don't think replicating this sort of feature should be added to CoAP's task set.  It'd be kinda like implementing telnet over HTTP: technically possible, but for heaven's sake *why*?

Peter

On Fri, Jul 2, 2010 at 8:16 AM, Don Sturek <d.sturek@att.net> wrote:
At least for our SE 2 application, we will clearly see fragmented packets.
We have several types of data that will drive this:
1)  Reports
2)  Lists of events (certainly you can control how many you ask for but at
least once you need to get the list of what you can ask for)

Don

-----Original Message-----
From: Zach Shelby [mailto:zach@sensinode.com]
Sent: Friday, July 02, 2010 6:05 AM
To: d.sturek@att.net
Cc: 'Guido Moritz'; core@ietf.org; L.Wood@surrey.ac.uk
Subject: Re: [core] CoRE v/s Compressed HTTP


On Jul 2, 2010, at 4:01 PM, Don Sturek wrote:

> On the length, for IEEE 802.15.4 using 6LowPAN, I think we have around 50
or
> so bytes to work with in the first block (application wise).  If that fits
> all the data you want to send that is great.  However, many solutions need
> more.  Even if the application architects its control packets to fit into
> those 50 bytes, the application may need to do reporting/etc which will
> cause at least a portion of those packets to be fragmented.


Ahhh, now I see what you mean. As CoAP is at the application layer it
doesn't limit the size of a CoAP message to a single link-layer frame, but
instead to the IPv6 MTU. However, there is a recommendation in the draft
that says a message SHOULD fit into an 802.15.4 frame if possible to avoid
the penalty of fragmentation.

We can adjust that text if you think that SHOULD is too strong?

Zach

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

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


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

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

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------040107020808040302070503-- From richard.kelsey@ember.com Fri Jul 2 09:41: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 18E803A68D6 for ; Fri, 2 Jul 2010 09:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 dOIGg7YP-aOf for ; Fri, 2 Jul 2010 09:41:08 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8EE3E3A67D4 for ; Fri, 2 Jul 2010 09:41:07 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 12:41:19 -0400 Date: Fri, 02 Jul 2010 12:47:33 -0400 Message-Id: <87r5jlhlui.fsf@kelsey-ws.hq.ember.com> To: Ralph Droms In-reply-to: <4FB8E24E-8F39-4885-BE87-8DD5F238451F@gmail.com> (message from Ralph Droms on Fri, 2 Jul 2010 11:44:04 -0400) From: Richard Kelsey References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <603B58DF-C2AB-449F-8100-8CBB376FC56F@gmail.com> <87sk41hok1.fsf@kelsey-ws.hq.ember.com> <4FB8E24E-8F39-4885-BE87-8DD5F238451F@gmail.com> X-OriginalArrivalTime: 02 Jul 2010 16:41:19.0291 (UTC) FILETIME=[65A8C8B0:01CB1A05] Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 16:41:09 -0000 > From: Ralph Droms > Date: Fri, 2 Jul 2010 11:44:04 -0400 > > Does 6lopwan fragmentation require reassembly at each intermediate node? Yes, at least officially. There are some games that can be played to avoid intermediate reassembly, but to me they seem fraught with potential difficulties. For packets that fit into a few 6lowpan fragments I don't think that the per-hop reassembly hurts performance all that much. Larger number of fragments are problematic, because of the increased buffering needed on intermediate nodes and the requirement that all fragments must traverse the same route. It would be good to have real data on this. To get this back to UDP, which Zach just reminded us has already been chosen by the group, the same fragment overhead issues apply to UDP packets as well as TCP, if somewhat less so. The UDP header is smaller to begin with and can be compressed by 6lowpan. On the other had, the DTLS packet overhead is a little greater that TLS, and the savings in processing fewer (D)TLS records is still there. -Richard Kelsey From geoff@proto6.com Fri Jul 2 12:00: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 C075D28C153 for ; Fri, 2 Jul 2010 12:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 bk6ykZzTpdBy for ; Fri, 2 Jul 2010 12:00:45 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id BE5FF3A690C for ; Fri, 2 Jul 2010 12:00:35 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id A95B918324; Fri, 2 Jul 2010 13:00:50 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o62J0jae009444; Fri, 2 Jul 2010 13:00:45 -0600 (MDT) From: Geoff Mulligan To: Ralph Droms In-Reply-To: <4FB8E24E-8F39-4885-BE87-8DD5F238451F@gmail.com> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <603B58DF-C2AB-449F-8100-8CBB376FC56F@gmail.com> <87sk41hok1.fsf@kelsey-ws.hq.ember.com> <4FB8E24E-8F39-4885-BE87-8DD5F238451F@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 02 Jul 2010 13:00:49 -0600 Message-ID: <1278097249.1606.21.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: core@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 19:00:45 -0000 Yes it does when using a route over design, though there are some tricks that might be able to be used. In a mesh under - no. geoff On Fri, 2010-07-02 at 11:44 -0400, Ralph Droms wrote: > Does 6lopwan fragmentation require reassembly at each intermediate node? > > - Ralph > > On Jul 2, 2010, at 11:49 AM 7/2/10, Richard Kelsey wrote: > > >> From: Ralph Droms > >> Date: Fri, 2 Jul 2010 10:25:59 -0400 > >> > >> What is the concern with TCP congestion control: > >> * performance, > >> * code size, > >> * something else? > >> > >> Do we have performance information on 6lowpan adaptation layer > >> fragmentation? Is It possible that TCP, with a very small MSS, would > >> provide better performance for traffic that won't fit in a 6lowpan > >> frame than either IP or 6lowpan fragmentation? > > > > Ralph, > > > > One of the advantages of using 6lowpan fragmentation is that > > the IPv6 header, TCP header, and TLS header and MAC (or > > other security) do not get duplicated in each fragment. > > This increases the available bandwidth and reduces the > > processing overhead. Sending a single TCP+TLS packet that > > fills two 6lowpan fragments rather than two unfragmented > > TCP+TLS packets switches 40+ bytes from being overhead to > > being payload. Given that those two unfragmented packets > > have maybe 60 bytes of TCP payload each, that is a big > > difference, as is having to process only half as many TLS > > records. > > -Richard Kelsey > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From edward.j.beroset@us.elster.com Fri Jul 2 13:01: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 46BFD3A6936 for ; Fri, 2 Jul 2010 13:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIo2zWvDtTnO for ; Fri, 2 Jul 2010 13:01:53 -0700 (PDT) Received: from mail54.messagelabs.com (mail54.messagelabs.com [216.82.241.131]) by core3.amsl.com (Postfix) with SMTP id 0BCC63A690C for ; Fri, 2 Jul 2010 13:01:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: edward.j.beroset@us.elster.com X-Msg-Ref: server-14.tower-54.messagelabs.com!1278100923!48935336!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 12380 invoked from network); 2 Jul 2010 20:02:04 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-14.tower-54.messagelabs.com with SMTP; 2 Jul 2010 20:02:04 -0000 In-Reply-To: References: To: zach@sensinode.com, 'Carsten Bormann' MIME-Version: 1.0 X-KeepSent: 0BBC53DA:F777A529-85257754:0069207B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: edward.j.beroset@us.elster.com Date: Fri, 2 Jul 2010 16:02:02 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 07/02/2010 03:57:24 PM, Serialize complete at 07/02/2010 03:57:24 PM Content-Type: multipart/alternative; boundary="=_alternative 006E0D7085257754_=" Cc: core Subject: Re: [core] -01 preview for implementors? 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 Jul 2010 20:01:55 -0000 This is a multipart message in MIME format. --=_alternative 006E0D7085257754_= Content-Type: text/plain; charset="US-ASCII" Zach Shelby wrote on 07/02/2010 08:59:03: > We are getting pretty close to finishing up coap-01, I expect to > submit this by next Wednesday. The plugfest in Maastricht is coming > fast, so any implementors who need a preview before Wednesday to get > started - just drop me an e-mail. People should be able to > participate in the plugfest also remotely (IPv6, IPv4, Jabber), so > not being there in person is no excuse! I hope to have an implementation that will be available (via IPv4 only), but unfortunately I won't be there on Sunday and may or may not have internet access. Meanwhile, I have been pestering Carsten's server to experiment with my client. Some observations/questions: 1. the content type in the Link Format is specified to be either media-type or media-code. In the case that it's a media-code, it's the short encoding from section 11.2, but the interpretation is ambiguous. Is it a raw 8-bit byte ("type=\x20") or some UTF-8 text encoding ("type=32")? 2. rather than assigning a new code for the compact accept option (in I-D. draft-bormann-coap-misc ) could we not simply use option type 0 in a GET request and allow multiples? 3. generally speaking, do we wish to allow or prohibit duplicate options? If allow, what would, say multiple URL options mean in a GET? Ed Beroset --=_alternative 006E0D7085257754_= Content-Type: text/html; charset="US-ASCII" Zach Shelby wrote on 07/02/2010 08:59:03:

> We are getting pretty close to finishing up coap-01, I expect to
> submit this by next Wednesday. The plugfest in Maastricht is coming
> fast, so any implementors who need a preview before Wednesday to get
> started - just drop me an e-mail. People should be able to
> participate in the plugfest also remotely (IPv6, IPv4, Jabber), so
> not being there in person is no excuse!  

I hope to have an implementation that will be available (via IPv4 only), but unfortunately I won't be there on Sunday and may or may not have internet access.  Meanwhile, I have been pestering Carsten's server to experiment with my client.  

Some observations/questions:
1. the content type in the Link Format is specified to be either media-type or media-code.  In the case that it's a media-code, it's the short encoding from section 11.2, but the interpretation is ambiguous.  Is it a raw 8-bit byte ("type=\x20") or some UTF-8 text encoding ("type=32")?
2. rather than assigning a new code for the compact accept option (in I-D.draft-bormann-coap-misc ) could we not simply use option type 0 in a GET request and allow multiples?
3. generally speaking, do we wish to allow or prohibit duplicate options?  If allow, what would, say multiple URL options mean in a GET?

Ed Beroset --=_alternative 006E0D7085257754_=-- From Colin.OFlynn@atmel.com Fri Jul 2 14:31: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 21B593A67F5 for ; Fri, 2 Jul 2010 14:31:33 -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 7HV2wPYzG3hK for ; Fri, 2 Jul 2010 14:31:20 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 9AB9D3A68AC for ; Fri, 2 Jul 2010 14:31:20 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o62LT1IV010520; Fri, 2 Jul 2010 14:29:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1A2D.DE63C858" Date: Fri, 2 Jul 2010 15:31:01 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoRE v/s Compressed HTTP Thread-Index: AcsZ/YWigDM/+zgPSAmmanAo2UAnsQAL4wR5 References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com><003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <002c01cb19f6$5dc85390$1958fab0$@sturek@att.net> From: "Oflynn, Colin" To: "Zach Shelby" , Cc: L.Wood@surrey.ac.uk, core@ietf.org Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 21:31:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1A2D.DE63C858 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, I think a key thing to remember about CoAP is that since it is using a = RESTful approach to access resources, those same resources should be = accessible by with normal HTTP over TCP.=20 So for example CoAP can safely have a maximum size of say 1280 bytes. It = prevents people from using CoAP for things it wasn't designed for by not = even pretending to support them. To do firmware transfers for instance = CoAP could at least point to a resource that can be accessed with = something like FTP/TFTP etc.=20 A node which is going to be routinely doing larger than 1280 byte = transfers is probably not very constrained. Such a node will = realistically be able to implement TCP/HTTP and can thus easily take = advantage of all the features TCP supports.=20 Keeping CoAP intensely focused on the constrained devices should make it = possible to implement on those constrained devices.=20 Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Zach Shelby Sent: Fri 02/07/2010 16:44 To: d.sturek@att.net Cc: core@ietf.org; L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP =20 Please read = http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt and = then let's talk more about this, I found this a very useful draft. I = think we all agree that features for rate control, congestion control = and reliability that suit our charter requirements are needed.=20 Regarding TCP we already had WG consensus to remove that from the scope = of our work for now. Zach On Jul 2, 2010, at 5:53 PM, Don Sturek wrote: > Hi Robby, >=20 > Agree completely on flow control in TCP. >=20 > I guess my point is almost immediately after finishing CoAP over UDP, = we > will begin to add back features of TCP. I would list > fragmentation/reassembly, guaranteed delivery and flow control into = that > list. >=20 > Don >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Simpson, Robby (GE Energy Services) > Sent: Friday, July 02, 2010 6:46 AM > To: Guido Moritz; L.Wood@surrey.ac.uk > Cc: core@ietf.org > Subject: Re: [core] CoRE v/s Compressed HTTP >=20 >> The last thing is the flow control/sliding window stuff. I think we > will not >> really need this in CoAP due to quite small receive/send buffers > implied by >> the resource constraints. >=20 > I think its useful to discuss flow control and congestion control > separately (they are, in fact, quite different). >=20 > I agree that many of the existing TCP congestion control algorithms = have > less-than-ideal behavior on wireless meshes, for instance. I further > agree that if we keep the number of packets low and avoid links that > have other flows, we may be able to get away with some less > sophisticated congestion control algorithms for CoAp. >=20 > Flow control, on the other hand, may be quite useful for constrained > devices. As an example, my understanding is that the TCP flow control > logic was intended to prevent more constrained devices from being > overwhelmed by less constrained devices. TCP's advertisement of > essentially free buffer space in the receiver is one useful way to > achieve flow control. I would suggest we not dismiss such = functionality > as even amongst constrained devices some devices may be able to = process > 2 packets whereas another device may be able to process 3. >=20 > - Robby > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CB1A2D.DE63C858 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] CoRE v/s Compressed HTTP

Hello All,

I think a key thing to remember about CoAP is that since it is using a = RESTful approach to access resources, those same resources should be = accessible by with normal HTTP over TCP.

So for example CoAP can safely have a maximum size of say 1280 bytes. It = prevents people from using CoAP for things it wasn't designed for by not = even pretending to support them. To do firmware transfers for instance = CoAP could at least point to a resource that can be accessed with = something like FTP/TFTP etc.

A node which is going to be routinely doing larger than 1280 byte = transfers is probably not very constrained. Such a node will = realistically be able to implement TCP/HTTP and can thus easily take = advantage of all the features TCP supports.

Keeping CoAP intensely focused on the constrained devices should make it = possible to implement on those constrained devices.

Regards,

  -Colin



-----Original Message-----
From: core-bounces@ietf.org on behalf of Zach Shelby
Sent: Fri 02/07/2010 16:44
To: d.sturek@att.net
Cc: core@ietf.org; L.Wood@surrey.ac.uk
Subject: Re: [core] CoRE v/s Compressed HTTP

Please read http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt= and then let's talk more about this, I found this a very useful = draft. I think we all agree that features for rate control, congestion = control and reliability that suit our charter requirements are = needed.

Regarding TCP we already had WG consensus to remove that from the scope = of our work for now.

Zach

On Jul 2, 2010, at 5:53 PM, Don Sturek wrote:

> Hi Robby,
>
> Agree completely on flow control in TCP.
>
> I guess my point is almost immediately after finishing CoAP over = UDP, we
> will begin to add back features of TCP.  I would list
> fragmentation/reassembly, guaranteed delivery and flow control into = that
> list.
>
> Don
>
>
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] = On Behalf Of
> Simpson, Robby (GE Energy Services)
> Sent: Friday, July 02, 2010 6:46 AM
> To: Guido Moritz; L.Wood@surrey.ac.uk
> Cc: core@ietf.org
> Subject: Re: [core] CoRE v/s Compressed HTTP
>
>> The last thing is the flow control/sliding window stuff. I = think we
> will not
>> really need this in CoAP due to quite small receive/send = buffers
> implied by
>> the resource constraints.
>
> I think its useful to discuss flow control and congestion = control
> separately (they are, in fact, quite different).
>
> I agree that many of the existing TCP congestion control algorithms = have
> less-than-ideal behavior on wireless meshes, for instance.  I = further
> agree that if we keep the number of packets low and avoid links = that
> have other flows, we may be able to get away with some less
> sophisticated congestion control algorithms for CoAp.
>
> Flow control, on the other hand, may be quite useful for = constrained
> devices.  As an example, my understanding is that the TCP flow = control
> logic was intended to prevent more constrained devices from = being
> overwhelmed by less constrained devices.  TCP's advertisement = of
> essentially free buffer space in the receiver is one useful way = to
> achieve flow control.  I would suggest we not dismiss such = functionality
> as even amongst constrained devices some devices may be able to = process
> 2 packets whereas another device may be able to process 3.
>
> - Robby
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core

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

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

------_=_NextPart_001_01CB1A2D.DE63C858-- From Colin.OFlynn@atmel.com Fri Jul 2 14:36: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 BDE003A67F5 for ; Fri, 2 Jul 2010 14:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=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 HcLgaGjShXL6 for ; Fri, 2 Jul 2010 14:36:51 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 7B5FF3A67B4 for ; Fri, 2 Jul 2010 14:36:51 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o62LZ1kD010870; Fri, 2 Jul 2010 14:35:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1A2E.B58006D4" Date: Fri, 2 Jul 2010 15:37:02 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) Thread-Index: AcsZvbyxZzL1p3MDSaq5wONyy04dygAFLDKwABbgv18= References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> From: "Oflynn, Colin" To: "Guido Moritz" , "Zach Shelby" , "Carsten Bormann" , "core" Cc: core issue tracker Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 21:36:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1A2E.B58006D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would also support just forcing a size of 1280. This 'artificial' = limit serves to stop people from trying to use CoAP for stuff it wasn't = designed for, even if their link-layer really does support bigger = packets. Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Guido Moritz Sent: Fri 02/07/2010 11:37 To: 'Zach Shelby'; 'Carsten Bormann'; 'core' Cc: 'core issue tracker' Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram) =20 I don't like the differentiation depending on the 'link layer'. 1280 = seems to be reasonable as the magic number of 6LoWPAN networks in general ;) Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag > von Zach Shelby > Gesendet: Freitag, 2. Juli 2010 10:08 > An: Carsten Bormann; core > Cc: core issue tracker > Betreff: Re: [core] #15: Consolidate maximum sizes (encodings, options > table, maximum datagram) >=20 > Any other comments on this one? Carsten didn't like the "physical > inteface", I can remove that. Otherwise I think discussing in terms of > MTU is the best we can do. >=20 > Zach >=20 > On Jun 30, 2010, at 1:39 PM, core issue tracker wrote: >=20 > > #15: Consolidate maximum sizes (encodings, options table, maximum > datagram) > > = --------------------------------+------------------------------------ > ------- > > Reporter: hartke@. | Owner: > > Type: defect | Status: new > > Priority: minor | Milestone: > > Component: coap | Version: 1.0 > > Severity: Active WG Document | Keywords: > > = --------------------------------+------------------------------------ > ------- > > > > Comment(by zach@.): > > > > - The URI and option length discrepency is being fixed already. > > > > - Regarding the maximum message size, I propose text like this which > is > > similar to that used by other UDP based protocols such as m-DNS: > > > > "The resulting datagram carrying a CoAP message MUST fit within a > single > > MTU of that phsical interface, which is typically 1500 bytes for an > > Ethernet interface and 1280 bytes for a 6LoWPAN interface." > > > > -- > > Ticket URL: > > > core > > >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CB1A2E.B58006D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram)

Hello,

I would also support just forcing a size of 1280. This 'artificial' = limit serves to stop people from trying to use CoAP for stuff it wasn't = designed for, even if their link-layer really does support bigger = packets.

Regards,

  -Colin


-----Original Message-----
From: core-bounces@ietf.org on behalf of Guido Moritz
Sent: Fri 02/07/2010 11:37
To: 'Zach Shelby'; 'Carsten Bormann'; 'core'
Cc: 'core issue tracker'
Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram)

I don't like the differentiation depending on the 'link layer'. 1280 = seems
to be reasonable as the magic number of 6LoWPAN networks in general = ;)

Guido

> -----Urspr=FCngliche Nachricht-----
> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] = Im Auftrag
> von Zach Shelby
> Gesendet: Freitag, 2. Juli 2010 10:08
> An: Carsten Bormann; core
> Cc: core issue tracker
> Betreff: Re: [core] #15: Consolidate maximum sizes (encodings, = options
> table, maximum datagram)
>
> Any other comments on this one? Carsten didn't like the = "physical
> inteface", I can remove that. Otherwise I think discussing in = terms of
> MTU is the best we can do.
>
> Zach
>
> On Jun 30, 2010, at 1:39 PM, core issue tracker wrote:
>
> > #15: Consolidate maximum sizes (encodings, options table, = maximum
> datagram)
> > = --------------------------------+------------------------------------
= > -------
> > Reporter:  = hartke@.           = ; |       Owner:
> >     Type:  = defect           &= nbsp;  |      Status:  new
> > Priority:  = minor           &n= bsp;   |   Milestone:
> > Component:  = coap           &nb= sp;    |     Version:  1.0
> > Severity:  Active WG Document  |    = Keywords:
> > = --------------------------------+------------------------------------
= > -------
> >
> > Comment(by zach@.):
> >
> > - The URI and option length discrepency is being fixed = already.
> >
> > - Regarding the maximum message size, I propose text like this = which
> is
> > similar to that used by other UDP based protocols such as = m-DNS:
> >
> > "The resulting datagram carrying a CoAP message MUST fit = within a
> single
> > MTU of that phsical interface, which is typically 1500 bytes = for an
> > Ethernet interface and 1280 bytes for a 6LoWPAN = interface."
> >
> > --
> > Ticket URL:
> <http= ://trac.tools.ietf.org/wg/core/trac/ticket/15#comment:2>
> > core <http://tools.ietf.org/core/><= BR> > >
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - = My blog "On the Internet of Things"
> http://6lowpan.net - My book = "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core

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

------_=_NextPart_001_01CB1A2E.B58006D4-- From cabo@tzi.org Fri Jul 2 14:51:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC103A68DA for ; Fri, 2 Jul 2010 14:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.751 X-Spam-Level: X-Spam-Status: No, score=-5.751 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 nNtDib0lSr+0 for ; Fri, 2 Jul 2010 14:51:52 -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 264463A68F9 for ; Fri, 2 Jul 2010 14:51:51 -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 o62Lprdt028228; Fri, 2 Jul 2010 23:51:53 +0200 (CEST) Received: from [192.168.217.101] (p5489F564.dip.t-dialin.net [84.137.245.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4804ABF23; Fri, 2 Jul 2010 23:51:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <008701cb19e8$c098af50$41ca0df0$@sturek@att.net> Date: Fri, 2 Jul 2010 23:51:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <938BB58C-EF6B-4134-AF5E-106EF7A85394@tzi.org> References: <8977BB27-E20B-4CA6-BB4A-655984542574@oracle.com> <003001cb19c8$69df0c10$3d9d2430$@moritz@uni-rostock.de> <004301cb19d1$17ae4fb0$470aef10$@moritz@uni-rostock.de> <451C2C3D-2454-47EE-940C-894C4C4CACA9@sensinode.com> <006701cb19e5$316d6850$944838f0$@sturek@att.net> <80A8A42C-0DE5-44AD-AC21-C1C4546B08DE@sensinode.com> <007f01cb19e6$ae88bb40$0b9a31c0$@sturek@att.net> <008701cb19e8$c098af50$41ca0df0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [core] CoRE v/s Compressed HTTP 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 Jul 2010 21:51:54 -0000 On Jul 2, 2010, at 15:16, Don Sturek wrote: > At least for our SE 2 application, we will clearly see fragmented = packets. > We have several types of data that will drive this: > 1) Reports > 2) Lists of events (certainly you can control how many you ask for = but at > least once you need to get the list of what you can ask for) coap-misc defines a block option to avoid the need for (too much) = fragmentation in this case. Since every block is acknowledged, this works well even in the presence = of losses. (Loss probabilities get much worse with many (n) fragments, as the = per-packet loss probability 1-(1-p)^n is close to p*n for small p. Some fragmentation is probably good to reduce header overhead; the = implementation at coap://ns.tzi.org:61616/ therefore uses a default = block size of 128 (which would typically need two or three 6lowpan = packets per IP packet). But that choice is up to the applications, nothing in CoAP stops us from = using MTU-size packets (IPv6: 1280). (I just wouldn't want to go beyond that without some path MTU discovery = -- this is the reason I believe something like the block option should = be a mandatory part of the protocol.) As a general note, *discovering* information about adaptation layer = fragmentation is nearly impossible, so either one of the sides knows = something and feeds it to the application, or we end up with lots of = adaptation layer fragmentation. Fortunately, 6LoWPANs are stub = networks, so if they are involved, at least one of the sides knows that. = That's why the the block option was designed so that both sides can = influence the block size. Gruesse, Carsten From klaus.hartke@googlemail.com Sun Jul 4 09:46:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35773A67B7 for ; Sun, 4 Jul 2010 09:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olHuGmz5o-aq for ; Sun, 4 Jul 2010 09:46:06 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A0D133A6452 for ; Sun, 4 Jul 2010 09:46:05 -0700 (PDT) Received: by bwz7 with SMTP id 7so2807511bwz.31 for ; Sun, 04 Jul 2010 09:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=u0y9pvPVMcL3cvqbjHoUoVfUOdmWC+K+gnun5s6K8UM=; b=P0VhfibJLiV6ou6WhrWVXhfVXTdFgJa2nf03b9Bt0LZlIEMkTaws/YC/iL84sMSHtT Sqzsa62PLdINr17PPjD4GQ0WXU/ffxGEyNUSpwnArSzd4UtMyz/2JkJIrZfQ6FDWQVkT nZj0XHZDg3HrLsIIjxpQ2YHmWpgFHxqDMKbRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=c0xrG8Xm5u/bnUKqKwDAux3g4t/ipA6CQbkVnTLXbNMP1Ql0kaqZ865jb6YXOy4ONf raTawQi1qhXWVTnf2UDH+F7i1AjMmSzG42RAzJ9ONBb43E9Bn7Ry9i3ov+cs7KViyqA5 b3RE++0nfv7+AdSdlIhn+YSGZxupwcXNbG1Ak= MIME-Version: 1.0 Received: by 10.204.23.197 with SMTP id s5mr1472034bkb.161.1278261961928; Sun, 04 Jul 2010 09:46:01 -0700 (PDT) Received: by 10.204.58.199 with HTTP; Sun, 4 Jul 2010 09:46:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 Jul 2010 18:46:01 +0200 Message-ID: From: Klaus Hartke To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] -01 preview for implementors? 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, 04 Jul 2010 16:46:06 -0000 > 3. generally speaking, do we wish to allow or prohibit duplicate options? For any option that can have multiple values (Accept, If-None-Match, ...) the simplest solution is probably to allow duplicate options instead of inventing a format for options with multiple values. On the other hand, such a format would be trivial for options with values of fixed width. > =A0If allow, what would, say multiple URL options mean in a GET? Multiple URL options do not have a lot of meaning in a GET, so I'd say the superfluous options should be treated like any unknown or malformed option in this case (see coap-misc-04, section 6.3). Klaus From robert.cragie@gridmerge.com Sun Jul 4 10:20: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 8FFD93A6860 for ; Sun, 4 Jul 2010 10:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.911 X-Spam-Level: **** X-Spam-Status: No, score=4.911 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_60=1, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 ecLvWl0rcfqQ for ; Sun, 4 Jul 2010 10:20:12 -0700 (PDT) Received: from webmail1.extendcp.co.uk (www.outitgoes.com [79.170.40.67]) by core3.amsl.com (Postfix) with ESMTP id 058FF3A676A for ; Sun, 4 Jul 2010 10:20:11 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail1.extendcp.co.uk with esmtp (Exim 4.43) id 1OVSrT-0004f4-D5; Sun, 04 Jul 2010 18:20:11 +0100 Message-Id: From: Robert Cragie To: core@ietf.org X-Mailer: Atmail Date: Sun, 04 Jul 2010 18:20:11 +0100 Content-Type: multipart/mixed; boundary="=_ed1f9e990bd89363423e29020ad87236" MIME-Version: 1.0 Subject: [core] Comments on draft-hartke-coap-observe-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: Sun, 04 Jul 2010 17:20:14 -0000 This is a message in Mime Format. If you see this, your mail reader does not support this format. --=_ed1f9e990bd89363423e29020ad87236 Content-Type: multipart/alternative; boundary="=_4cf3ed8555b7dda1791cb4eea09cea41" Content-Transfer-Encoding: 8bit --=_4cf3ed8555b7dda1791cb4eea09cea41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry these are a little late.=0A=0A To summarize:=0A=0A=09* The documen= t moves around layers of abstraction somewhat. Some of=0Athe concepts ar= e quite abstract (observer, subject etc.), then it=0Atalks about message= s, then it refers to reliable UDP. I think it=0Ashould keep to the abstr= act level and defer discussion on the more=0Aspecific layers to other do= cuments=0A=09* I know I have said this before but I believe it is import= ant to=0Aabstract the transaction model from the methods themselves. Thi= s means=0Awe can put a clean break between the RESTful part (plus pub/su= b) and=0Athe transactions (HTTP-like or more asynchronous for M2M). What= may be=0Amissing is to specify abstract properties of the delivery, whi= ch is=0Asort of addressed by message types in this document.=0A=0A I tri= ed to attach as modified original but I think it was too large=0Afor mai= l server. In the attachment my comments are in as . indicates=0Awhere I= have put out text not directly relevant to the comment.=0A=0A Robert=0A= -- =0A=0A=09Robert Cragie (Pacific Gas & Electric) =0A=0A=09Gridmerge Lt= d.=0A 89 Greenfield Crescent,=0A Wakefield, WF4 4WA, UK=0A +44 1924 9108= 88=0A +1 415 513 0064=0Ahttp://www.gridmerge.com [1]=0A=0A=0A=0ALinks:= =0A------=0A[1] http://www.gridmerge.com/=0A --=_4cf3ed8555b7dda1791cb4eea09cea41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry these are a little late.

=0A=0ATo summarize= :
  • The document moves around layers of abstraction=0A somewh= at. Some of=0Athe concepts are quite abstract (observer, subject etc.),= then it talks=0Aabout messages, then it refers to reliable UDP. I think= it should keep=0Ato the abstract level and defer discussion on the more= specific layers=0Ato other documents
  • I know I have said this be= fore but I believe =0Ait is important to abstract=0Athe transaction mode= l from the methods themselves. This means we can=0Aput a clean break bet= ween the RESTful part (plus pub/sub) and the=0Atransactions (HTTP-like o= r more asynchronous for M2M). What may be=0Amissing is to specify abstra= ct properties of the delivery, which is=0Asort of addressed by message t= ypes in this document.
=0A=0AI tried to attach as modified orig= inal but I think it was too large for =0Amail server. In the attachment= my comments are in as=0A<RCC></RCC>. <snip> indicates= where I have put out =0Atext not directly relevant to the comment.

=0A=0ARobert
--

Robert Cragie (Pacific Gas & Electric)

=0A

Gridmerge= Ltd.
=0A89 Greenfield Crescent,
=0AWakefield, WF4 4WA, UK=0A+44 1924 910888
=0A+1 415 513 0064
http://www.gridmerge.com



--=_4cf3ed8555b7dda1791cb4eea09cea41-- --=_ed1f9e990bd89363423e29020ad87236 Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?UTF-8?B?ZHJhZnQtaGFydGtlLWNvYXAtb2JzZXJ2ZS0wMC1yY2MtY29tbWVudHM=?= =?UTF-8?B?LnR4dA==?=" PHNuaXA+DQoNCjEuMS4gIERlc2lnbiBQYXR0ZXJuDQoNCiAgIE1hbnkgZGVzaWducyBhcmUg cG9zc2libGUgZm9yIHRoZSBvYnNlcnZlIGNhcGFiaWxpdHkgb2YgQ29BUC4gIFNvDQogICB0 aGF0IHdlIGRvbid0IGVuZCB1cCB3aXRoIGEgcmFuZG9tLCBhcmJpdHJhcnkgZGVzaWduLCB3 ZSBiYXNlIG91cg0KICAgY29uc2lkZXJhdGlvbnMgb24gdGhlIHdlbGwta25vd24gc3ViamVj dC9vYnNlcnZlciBkZXNpZ24gcGF0dGVybi4gIEluDQogICB0aGlzIHBhdHRlcm4sIGFuIG9i amVjdCwgY2FsbGVkIHRoZSBzdWJqZWN0LCBtYWludGFpbnMgYSBsaXN0IG9mDQogICBpbnRl cmVzdGVkIHBhcnRpZXMsIGNhbGxlZCBvYnNlcnZlcnMsIGFuZCBub3RpZmllcyB0aGVtIGF1 dG9tYXRpY2FsbHkNCiAgIG9mIGFueSBzdGF0ZSBjaGFuZ2VzLg0KDQogICBUaGVyZSBhcmUg YSBudW1iZXIgb2YgdmFyaWFudHMgb2YgdGhhdCBkZXNpZ24gcGF0dGVybi4gIFdlIGxpa2Ug b25lDQogICB0aGF0IGV4cGxpY2l0bHkgY29uc2lkZXJzIHRoZSB3YXkgdGhlIGV2b2x1dGlv biBvZiB0aGUgcmVzb3VyY2Ugc3RhdGUNCiAgIG1pZ2h0IGVuZCBbRFVBTF0uICBJbiBkZXRh aWwsIHRoaXMgdmFyaWFudCBvZiB0aGUgZGVzaWduIHBhdHRlcm4NCiAgIGNvbnNpc3RzIG9m IHRoZSBmb2xsb3dpbmcgZWxlbWVudHM6DQoNCjxSQ0M+J29iamVjdCcgdXNlZCBhYm92ZTwv UkNDPg0KDQogICBvICBBIF9zdWJqZWN0Xywgd2hpY2ggc2VuZHMgbm90aWZpY2F0aW9ucyB0 byBvYnNlcnZlcnMuICBJdCBoYXMgYQ0KICAgICAgc2luZ2xlIG1ldGhvZCwgU1VCU0NSSUJF LCB3aGljaCBpcyBjYWxsZWQgYnkgb2JzZXJ2ZXJzIHRoYXQgd2lzaA0KICAgICAgdG8gcmVj ZWl2ZSBub3RpZmljYXRpb25zIGZyb20gdGhlIHN1YmplY3QuDQoNCjxSQ0M+DQpJdCBpcyBw cm9iYWJseSB3b3J0aCBlbHVjaWRhdGluZyB0aGUgbXVsdGlwbGljaXR5IG9mIHRoZSBvYmpl Y3QgYXNzb2NpYXRpb25zIGluIHRoZSB0ZXh0DQoNCltTVUJKXS0rLTEtLS0tbi0tLVtTVUJT XS0tLTEtLS0tMS0tLVtPQlNdDQogICAgICAgfA0KICAgICAgICstMS0tLS1uLS0tW09CU10N Cg0KPC9SQ0M+DQoNCiAgIG8gIEFuIF9vYnNlcnZlcl8sIHdoaWNoIHJlY2VpdmVzIG5vdGlm aWNhdGlvbnMgZnJvbSBhIHN1YmplY3QuICBJdA0KICAgICAgaGFzIHRocmVlIG1ldGhvZHM6 IFlJRUxELCB3aGljaCBzdXBwbGllcyB0aGUgb2JzZXJ2ZXIgd2l0aCBuZXcgb3INCiAgICAg IGN1cnJlbnQgaW5mb3JtYXRpb247IFRIUk9XLCB3aGljaCBpbmZvcm1zIHRoZSBvYnNlcnZl ciB0aGF0IHRoZQ0KICAgICAgc3ViamVjdCBleHBlcmllbmNlZCBhbiBlcnJvciBjb25kaXRp b247IGFuZCBCUkVBSywgd2hpY2ggaW5kaWNhdGVzDQogICAgICB0aGF0IHRoZSBzdWJqZWN0 IGhhcyBmaW5pc2hlZCBzZW5kaW5nIG5vdGlmaWNhdGlvbnMuICBUaGUgZ3JhbW1hcg0KICAg ICAgb2Ygbm90aWZpY2F0aW9ucyB0byBiZSBleHBlY3RlZCBvdmVyIHRpbWUgdGhlcmVmb3Jl IGlzOg0KDQogICAgICBZSUVMRCogKCBCUkVBSyB8IFRIUk9XICk/DQogICAgIA0KPFJDQz4N Ck1ldGhvZHMgYXJlIGNhbGxlZCBzbyBpdCBpcyBiZXR0ZXIgdG8gZGVzY3JpYmUgdXNpbmcg dGhlIGNhbGxlci4NCllJRUxEIG1ldGhvZCBpcyBjYWxsZWQgYnkgdGhlIHN1YmplY3QgdG8g c3VwcGx5IHRoZSBvYnNlcnZlciB3aXRoIG5ldyBvciBjdXJyZW50IGluZm9ybWF0aW9uDQpU SFJPVyBtZXRob2QgaXMgY2FsbGVkIGJ5IHRoZSBzdWJqZWN0IHRvIGluZm9ybSB0aGUgb2Jz ZXJ2ZXIgdGhhdCBhbiBlcnJvciBjb25kaXRpb24gaGFzIG9jY3VycmVkDQpCUkVBSyBtZXRo b2QgaXMgY2FsbGVkIGJ5IHRoZSBzdWJqZWN0IChzdWJzY3JpcHRpb24/KSB0byBpbmZvcm0g dGhlIG9ic2VydmVyIHRoYXQgdGhlIHN1YmplY3QgaGFzIGZpbmlzaGVkIHNlbmRpbmcgbm90 aWZpY2F0aW9ucyBhbmQgdGhlIHN1YnNjcmlwdGlvbiBpcyBubyBsb25nZXIgdmFsaWQuDQo8 L1JDQz4NCg0KICAgbyAgQSBfc3Vic2NyaXB0aW9uXywgd2hpY2ggcmVwcmVzZW50cyB0aGUg aW50ZXJlc3Qgb2YgYW4gb2JzZXJ2ZXIgaW4NCiAgICAgIGEgc3ViamVjdC4gIEl0IGhhcyBh IHNpbmdsZSBtZXRob2QsIFVOU1VCU0NSSUJFLCB3aGljaCBlbmFibGVzIHRoZQ0KICAgICAg c3ViamVjdCB0byB1bnN1YnNjcmliZSBvYnNlcnZlcnMgd2hlbiBub3RpZmljYXRpb24gaGFz IGZpbmlzaGVkLg0KICAgICAgT2JzZXJ2ZXJzIHJlY2VpdmUgYSByZWZlcmVuY2UgdG8gdGhl IHN1YnNjcmlwdGlvbiBmcm9tIHRoZQ0KICAgICAgU1VCU0NSSUJFIG1ldGhvZCwgc28gdGhl eSBjYW4gYWxzbyBjYWxsIHRoZSBVTlNVQlNDUklCRSBtZXRob2QgdG8NCiAgICAgIHVuc3Vi c2NyaWJlIGJlZm9yZSB0aGUgc3ViamVjdCBoYXMgZmluaXNoZWQgc2VuZGluZyBub3RpZmlj YXRpb25zLg0KDQo8UkNDPkkgdGhpbmsgaXQgYWxzbyBuZWVkcyBSRUZSRVNIIGJhc2VkIG9u IGxhdGVyIHRleHQ8L1JDQz4NCg0KPHNuaXA+DQoNCiAgIFdlIGludGVycHJldCByZXNvdXJj ZXMgYXMgdGhlIF9zdWJqZWN0c18gb2YgdGhlIHN1YmplY3Qvb2JzZXJ2ZXINCiAgIHBhdHRl cm4uICBUaGUgX3N1YnNjcmlwdGlvbl8gY2F1c2VzIHRoZSBzdWJqZWN0IHRvIGNvbnRpbnVv dXNseQ0KICAgc3VwcGx5IGFuIF9vYnNlcnZlcl8gd2l0aCB0aGUgc3RhdGUgb2YgdGhlIHJl c291cmNlOiBvbmNlIHVwb24NCiAgIHN1YnNjcmlwdGlvbiBhbmQgdGhlbiB3aGVuZXZlciB0 aGUgc3RhdGUgb2YgdGhlIHJlc291cmNlIGNoYW5nZXMuICBXZQ0KICAgY2FsbCBhIENvQVAg bm9kZSBvZmZlcmluZyBhIHJlc291cmNlIF9zZXJ2ZXJfLCBhbmQgYSBDb0FQIG5vZGUNCiAg IHN1YnNjcmliaW5nIGFuIG9ic2VydmVyIHRvIGEgcmVzb3VyY2UgX2NsaWVudF8uDQoNCjxS Q0M+DQpTdGFydGluZyB0byBtaXggbmFtZXMgaGVyZS4NCiJhIENvQVAgbm9kZSBvZmZlcmlu ZyBhIHJlc291cmNlIF9zZXJ2ZXJfIiAtPiAiYSBDb0FQIG5vZGUgb2ZmZXJpbmcgYSBzdWJq ZWN0IF9zZXJ2ZXJfIg0KImFuZCBhIENvQVAgbm9kZSBzdWJzY3JpYmluZyBhbiBvYnNlcnZl ciB0byBhIHJlc291cmNlIF9jbGllbnRfIiAtPiAiYW5kIGEgQ29BUCBub2RlIHN1YnNjcmli aW5nIGFuIG9ic2VydmVyIHRvIGEgc3ViamVjdCBfY2xpZW50XyINCjwvUkNDPg0KDQogICBB cyB3aXRoIHRoZSBleGlzdGluZw0KICAgUkVTVCBtZXRob2RzLCB0aGlzIGFyY2hpdGVjdHVy ZSBpcyBhYm91dCBleGNoYW5naW5nIHJlcHJlc2VudGF0aW9ucw0KICAgb2YgcmVzb3VyY2Vz LCBub3QgYWJvdXQgdGhlIG1lc3NhZ2VzIChvciBtZXRob2QgY2FsbHMpLg0KICANCjxSQ0M+ VGhpcyBzZWVtcyB0byBjb25mbGljdCB3aXRoIHRoZSBvYmplY3QtYmFzZWQgYXBwcm9hY2gg YWJvdmUgd2l0aCBleHBsaWNpdCBtZXRob2RzPC9SQ0M+DQoNCjxzbmlwPg0KDQoyLiAgUmVx dWlyZW1lbnRzDQoNCiAgIFRoZSByZXF1aXJlbWVudHMgZm9yIGltcGxlbWVudGluZyB0aGUg c3ViamVjdC9vYnNlcnZlciBkZXNpZ24gcGF0dGVybg0KICAgb3ZlciBVRFAgc3RlbSBsYXJn ZWx5IGZyb20gdGhlIHRoZSBmYWN0IHRoYXQgVURQIGlzIGFuIHVucmVsaWFibGUsDQogICBj b25uZWN0aW9ubGVzcyB0cmFuc3BvcnQuICBUaGlzIG1lYW5zIHRoYXQgbWV0aG9kIGNhbGxz IG11c3QgYmUNCiAgIGV4cHJlc3NlZCBhcyBtZXNzYWdlcywgdGhhdCBwcmVwYXJhdGlvbiBt dXN0IGJlIHRha2VuIGZvciB0aGUgY2FzZQ0KICAgdGhhdCBtZXNzYWdlcyBhcnJpdmUgb3V0 IG9mIG9yZGVyLCBhcHBlYXIgZHVwbGljYXRlZCwgb3IgZ28gbWlzc2luZw0KICAgd2l0aG91 dCBub3RpY2UsIGFuZCB0aGF0IHRoZSB0cmFuc3BvcnQga2VlcHMgbm8gc3RhdGUgYmV0d2Vl bg0KICAgbWVzc2FnZXMgdGhhdCBjYW4gYmUgdXRpbGl6ZWQuDQogIA0KPFJDQz5JcyBpdCBu ZWNlc3NhcnkgdG8gYWRkIHJlcXVpcmVtZW50cyBmb3IgVURQIGludG8gdGhpcyBkb2N1bWVu dD8gSSB0aGluayBpdCBjb25mdXNlcyB0aGUgZGVzaWduIHBhdHRlcm4uPC9SQ0M+DQoNCiAg IFRoZSBkZXRhaWxlZCByZXF1aXJlbWVudHMgdGhhdCBmb2xsb3cgZnJvbSB0aGlzIGFyZToN Cg0KICAgbyAgQW4gaW52b2NhdGlvbiBvZiB0aGUgU1VCU0NSSUJFIG1ldGhvZCBvbiBhbiBv YnNlcnZhYmxlIHJlc291cmNlIGlzDQogICAgICBpbXBsZW1lbnRlZCBieSBzZW5kaW5nIGEg bWVzc2FnZSAoYSBzdWJzY3JpcHRpb24gcmVxdWVzdCkgZnJvbSB0aGUNCiAgICAgIHN1YnNj cmliaW5nIGNsaWVudCB0byB0aGUgc2VydmVyIHRoYXQgb2ZmZXJzIHRoZSByZXNvdXJjZS4N Cg0KICAgICAgVGhlIGNsaWVudCBtdXN0IGJlIGFibGUgdG8gZGV0ZXJtaW5lIGlmIGEgc3Vi c2NyaXB0aW9uIHJlcXVlc3Qgd2FzDQogICAgICByZWNlaXZlZCBieSB0aGUgc2VydmVyLCBh bmQsIGlmIG5vdCwgbXVzdCBiZSBhYmxlIHRvIHJldHJhbnNtaXQNCiAgICAgIHRoZSByZXF1 ZXN0Lg0KDQogICAgICBUaGUgc2VydmVyIG11c3QgYWNrbm93bGVkZ2UgdGhlIHN1YnNjcmlw dGlvbiByZXF1ZXN0LCBhbmQgbXVzdCBiZQ0KICAgICAgcHJlcGFyZWQgdG8gcmVjZWl2ZSBk dXBsaWNhdGVkIHN1YnNjcmlwdGlvbiByZXF1ZXN0cy4NCg0KICAgICAgU2luY2Ugc3Vic2Ny aWJpbmcgY2FuIGJlIG1hZGUgaWRlbXBvdGVudCAoU2VjdGlvbiA2KSwgdGhlIHNlcnZlcg0K ICAgICAgbmVlZCBub3QgYmUgYWJsZSB0byBkZXRlY3QgYSBkdXBsaWNhdGVkIHN1YnNjcmlw dGlvbiByZXF1ZXN0IGFzDQogICAgICBzdWNoLg0KDQogICAgICBUaGUgY2xpZW50IG11c3Qg YmUgYWJsZSB0byByZWxhdGUgdGhlIGFja25vd2xlZGdlbWVudCB0byB0aGUNCiAgICAgIHN1 YnNjcmlwdGlvbiByZXF1ZXN0Lg0KDQo8UkNDPklmIHlvdSBhcmUgZ29pbmcgdG8gZ28gZG93 biB0aGlzIHJvYWQsIEkgd291bGQgY2xhc3NpZnkgdGhlIHRyYW5zYWN0aW9uIHR5cGVzIGJl dHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIgYW5kIGRlc2NyaWJlIHRoZSByZXF1aXJlZCBwcm9w ZXJ0aWVzPC9SQ0M+DQoNCiAgIG8gIFRoZSB1c3VhbCBjb25zaWRlcmF0aW9ucyBmb3IgcmV0 cmlldmluZyB0aGUgcmVwcmVzZW50YXRpb24gb2YgYQ0KICAgICAgcmVzb3VyY2UgaW4gYSBS RVNULWJhc2VkIHByb3RvY29sIGFwcGx5LCBlLmcuOg0KDQogICAgICBBIHN1YnNjcmliaW5n IGNsaWVudCBtdXN0IGJlIGFibGUgdG8gaW5mbHVlbmNlIHRoZSByZXByZXNlbnRhdGlvbg0K ICAgICAgZm9ybWF0IGluIHdoaWNoIHRoZSBzZXJ2ZXIgc3VwcGxpZXMgdGhlIHJlc291cmNl IHN0YXRlIHRvIHRoZQ0KICAgICAgY2xpZW50Lg0KDQo8UkNDPk9ubHkgaWYgdGhlIHJlc291 cmNlIGlzIGFibGUgdG8gYmUgcmVwcmVzZW50ZWQgaW4gdmFyaW91cyB3YXlzOyBpZiBpdCBp cywgaG93IGlzIHRoaXMga25vd2xlZGdlIGltcGFydGVkPyBEdXJpbmcgcmVzb3VyY2UgZGlz Y292ZXJ5PyBRdWVyeSB0byByZXNvdXJjZT88L1JDQz4NCg0KPHNuaXA+DQoNCiAgIG8gIFRv IHRha2UgYWR2YW50YWdlIG9mIHRoZSBtdWx0aWNhc3QgY2FwYWJpbGl0aWVzIG9mIHRoZSB0 cmFuc3BvcnQsDQogICAgICBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gc3Vic2NyaWJlIGEg VURQIG11bHRpY2FzdCBncm91cCB0byBhDQogICAgICByZXNvdXJjZS4gIEluIGNvbnRyYXN0 IHRvIHN1YnNjcmliaW5nIG11bHRpcGxlIGNsaWVudHMNCiAgICAgIGluZGl2aWR1YWxseSB0 byB0aGUgcmVzb3VyY2UsIHRoZSBzZXJ2ZXIgaW4gdGhpcyBjYXNlIG11c3QgdHJlYXQNCiAg ICAgIHRoZSBtdWx0aWNhc3QgZ3JvdXAgYXMgYSBzaW5nbGUgb2JzZXJ2ZXIuDQogICAgIA0K PFJDQz5BZ2FpbiwgYWJzdHJhY3QgdGhpcy48L1JDQz4NCg0KICAgbyAgRm9yIHJvYnVzdG5l c3MsIGEgc3Vic2NyaXB0aW9uIGhhcyB0byBiZSBtYWludGFpbmVkIHRocm91Z2gNCiAgICAg IHBlcmlvZGljIHJlZnJlc2hpbmcuICBJZiBhIHN1YnNjcmlwdGlvbiBpcyBub3QgcmVmcmVz aGVkLCBpdHMNCiAgICAgIGxpZmV0aW1lIG11c3QgZW5kIGFmdGVyIGEgY2VydGFpbiBkdXJh dGlvbiB0aGF0IGlzIG5lZ290aWF0ZWQgYXMNCiAgICAgIHBhcnQgb2YgdGhlIG1lc3NhZ2Ug ZXhjaGFuZ2UgdGhhdCBpbXBsZW1lbnRzIHRoZSBTVUJTQ1JJQkUgbWV0aG9kDQogICAgICBj YWxsLg0KDQo8UkNDPlRoaXMgaXMganVzdCBhIHN1YnNjcmlwdGlvbiBwYXJhbWV0ZXIuIE5v IG5lZWQgdG8gdGFsayBhYm91dCAnbWVzc2FnZSBleGNoYW5nZSc8L1JDQz4NCiAgICAgDQog ICAgICBTbyBhIHN1YnNjcmliaW5nIGNsaWVudCBtdXN0IGJlIGFibGUgdG8gc3BlY2lmeSBh IHN1YnNjcmlwdGlvbg0KICAgICAgbGlmZXRpbWUgZHVyYXRpb24gaW4gYSBzdWJzY3JpcHRp b24gcmVxdWVzdC4gIEEgc2VydmVyIG11c3QgYmUNCiAgICAgIGFibGUgdG8gcmV0dXJuIHRo ZSBuZWdvdGlhdGVkIHN1YnNjcmlwdGlvbiBsaWZldGltZSBkdXJhdGlvbiBiYWNrDQogICAg ICB0byB0aGUgY2xpZW50Lg0KDQogICAgICBTaW5jZSB0aGUgY2xpZW50IGlzIHJlc3BvbnNp YmxlIGZvciB0YWtpbmcgY2FyZSBvZiB0aGUNCiAgICAgIHN1YnNjcmlwdGlvbiwgcmVmcmVz aGluZyBhIHN1YnNjcmlwdGlvbiBtdXN0IGJlIGltcGxlbWVudGVkIGJ5DQogICAgICBzZW5k aW5nIGEgbWVzc2FnZSAoYSBzdWJzY3JpcHRpb24gcmVmcmVzaCByZXF1ZXN0KSBmcm9tIHRo ZQ0KICAgICAgc3Vic2NyaWJlZCBjbGllbnQgdG8gdGhlIHNlcnZlci4NCiAgICAgDQo8UkND PlNvIGFkZCBhbm90aGVyIG1ldGhvZDogUkVGUkVTSDwvUkNDPg0KDQo8c25pcD4NCg0KICAg ICAgVGhlIHNlcnZlciBtdXN0IGJlIHByZXBhcmVkIGZvciBhIHJlZnJlc2ggcmVxdWVzdCB0 byBhcnJpdmUgYWZ0ZXINCiAgICAgIHRoZSBzdWJzY3JpcHRpb24gZXhwaXJlZC4gIEluIHRo aXMgY2FzZSwgdGhlIHN1YnNjcmlwdGlvbiByZWZyZXNoDQogICAgICByZXF1ZXN0IGlzIHRy ZWF0ZWQgdGhlIHNhbWUgYXMgYSBzdWJzY3JpcHRpb24gcmVxdWVzdCwgc2luY2UgdGhlDQog ICAgICBjbGllbnQgZXhwcmVzc2VkIHRoZSBkZXNpcmUgdG8gY29udGludWUgYmVpbmcgc3Vi c2NyaWJlZCB0byB0aGUNCiAgICAgIHJlc291cmNlLg0KICAgICANCjxSQ0M+SSBkb24ndCBh Z3JlZSB3aXRoIHRoaXMuIFRoZSBzdWJzY3JpcHRpb24ncyBCUkVBSyBzaG91bGQgYmUgc3Vm ZmljaWVudCB0byBtYW5hZ2UgdGhlIG9ic2VydmVyLiBPdGhlcndpc2UgeW91IG1heSBnZXQg YSBSRUZSRVNIIHJlY2VpdmVkIGFmdGVyIHRoZSBCUkVBSyBoYXMgYmVlbiBzZW50IGFuZCBp dCBpcyB0aGVuIHRyZWF0ZWQgbGlrZSBhIFNVQlNDUklCRSBidXQgdGhlIG9ic2VydmVyIG9u IHJlY2VpdmluZyB0aGUgQlJFQUsgdGhpbmtzIHRoZSBzdWJzY3JpcHRpb24gbm8gbG9uZ2Vy IGV4aXN0cy48L1JDQz4NCg0KPHNuaXA+DQoNCiAgIG8gIFRoZSByZXByZXNlbnRhdGlvbiBm b3JtYXQgdXNlZCBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIGENCiAgICAgIHN1YnNjcmlwdGlv biBtdXN0IG5vdCBjaGFuZ2UuICBJZiB0aGUgc2VydmVyIGlzIHVuYWJsZSB0byBjb250aW51 ZQ0KICAgICAgbm90aWZ5aW5nIGEgY2xpZW50IGluIHRoZSByZXF1ZXN0ZWQgcmVwcmVzZW50 YXRpb24gZm9ybWF0LCBpdCBtdXN0DQogICAgICBpbnZva2UgdGhlIFRIUk9XIG1ldGhvZCBv biB0aGUgb2JzZXJ2ZXIuDQoNCiAgIG8gIEEgc2VydmVyIG11c3Qgbm90IHNlbmQgYW55IGZ1 cnRoZXIgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGFmdGVyDQogICAgICBzZW5kaW5nIGEgbm90 aWZpY2F0aW9uIG1lc3NhZ2UgdGhhdCBkZW5vdGVzIGEgQlJFQUsgb3IgVEhST1cuDQoNCjxS Q0M+UmVmZXIgdG8gaW52b2tpbmcgWUlFTEQgbWV0aG9kIGluc3RlYWQ8L1JDQz4NCg0KPHNu aXA+DQoNCiAgIG8gIEFuIEFDSyByZXBseSBpbmRpY2F0ZXMgYW4gYWNrbm93bGVkZ2VtZW50 IG9mIGEgcmVxdWVzdC4NCg0KICAgbyAgQSBSU1QgcmVwbHkgaW5kaWNhdGVzIHRoZSByZWpl Y3Rpb24gb2YgYSByZXF1ZXN0Lg0KDQogICAoUmVzcG9uc2VzIGluIENvQVAgYXJlIHJlcGxp ZXMgdGhhdCBtYXkgY2FycnkgYSByZXNvdXJjZQ0KICAgcmVwcmVzZW50YXRpb24uKQ0KDQo8 UkNDPkkgdGhpbmsgaXQgaXMgY29uZnVzaW5nIHRvIGRpZmZlcmVudGlhdGUgcmVwbGllcyBh bmQgcmVzcG9uc2VzLjwvUkNDPg0KDQozLjMuMy4gIE5vdGlmaWNhdGlvbnMNCg0KICAgTWF0 Y2hpbmcgdGhlIG1ldGhvZHMgb2YgYW4gb2JzZXJ2ZXIsIHRoZSBub3RpZmljYXRpb24gbWVz c2FnZSB0eXBlcw0KICAgY2FuIGJlIHN1bW1hcml6ZWQgYXMgZm9sbG93czoNCg0KICAgbyAg QSBZSUVMRCBub3RpZmljYXRpb24gc3VwcGxpZXMgdGhlIHN1YnNjcmliZWQgY2xpZW50IHdp dGggdGhlIHN0YXRlDQogICAgICBvZiBhIHJlc291cmNlIGluIHNvbWUgcmVwcmVzZW50YXRp b24uDQoNCiAgIG8gIEEgQlJFQUsgbm90aWZpY2F0aW9uIGluZGljYXRlcyB0aGF0IHRoZSBv YnNlcnZlZCByZXNvdXJjZSBoYXMNCiAgICAgIGZpbmlzaGVkIHNlbmRpbmcgbm90aWZpY2F0 aW9ucy4NCg0KICAgbyAgQSBUSFJPVyBub3RpZmljYXRpb24gaW5mb3JtcyB0aGUgc3Vic2Ny aWJlZCBjbGllbnQgb2YgYW4gZXJyb3INCiAgICAgIGNvbmRpdGlvbi4NCg0KICAgRWFjaCBv ZiB0aGVzZSBub3RpZmljYXRpb24gbWVzc2FnZXMgY2FuIGJlIHNlbnQgYXMgYSBtZXNzYWdl IHRoYXQNCiAgIGRvZXMgbm90IHJlcXVpcmUgYWNrbm93bGVkZ2VtZW50LCBhcyBhIGNvbmZp cm1hYmxlIG1lc3NhZ2UgdGhhdCBkb2VzDQogICByZXF1aXJlIGFja25vd2xlZGdlbWVudCAo d2hpY2ggbWFrZXMgaXQgYSByZXF1ZXN0KSwgb3IgKGluIGNhc2Ugb2YgYW4NCiAgIGluaXRp YWwgbm90aWZpY2F0aW9uKSBwaWdneS1iYWNrZWQgd2l0aCB0aGUgQUNLIG1lc3NhZ2UgdGhh dCBpcyBzZW50DQogICBpbiByZXBseSB0byB0aGUgc3Vic2NyaXB0aW9uIHJlcXVlc3QuDQog IA0KPFJDQz5JIHRoaW5rIHRoZSBjbGFyaXR5IG9mIG1lc3NhZ2UgdHlwZXMgaGFzIGJlZW4g bG9zdCBub3cgYXMgeW91IGFyZSBjbGFzc2lmeWluZyBhIG1lc3NhZ2UgdHlwZSBhcyBhbm90 aGVyIG1lc3NhZ2UsIGkuZS4gYSBZSUVMRCBub3RpZmljYXRpb24gY291bGQgYWxzbyBiZSBh IFlJRUxEIHJlcXVlc3QuIEluIHRoYXQgY2FzZSwgd2h5IG5vdCBzZXBhcmF0ZSB0aGUgbWVz c2FnZSBmcm9tIHRoZSB0cmFuc2FjdGlvbiB1c2VkIHRvIGNvbnZleSB0aGUgbWVzc2FnZT8g VGhpcyB3YXMgbXkgb3JpZ2luYWwgcHJvcG9zYWwuIFRoaXMgbWFrZXMgc2Vuc2UgaW4gdGhh dCBkaWZmZXJlbnQgdHJhbnNhY3Rpb24gbW9kZWxzIGNhbiB0aGVuIGRlZmluZWQsIGZyb20g YSBzaW1wbGUgY2FsbC9jYWxsYmFjayB0byBhIGZ1bGx5IHN5bmNocm9ub3VzIGNsaWVudC9z ZXJ2ZXIgdHJhbnNhY3Rpb24uIElmIHdlIGRvIHRoYXQsIHRoZSB3aG9sZSBjb25jZXB0IG9m ICdtZXNzYWdlJyBjYW4gZ28gYXdheTsgd2UgYXJlIGxlZnQgd2l0aCAnbWV0aG9kJy48L1JD Qz4NCg0KPHNuaXA+DQoNCiAgIDMuICBUaGUgc2VydmVyIHBlcmZvcm1zIG9uZSBvZiB0aGUg Zm9sbG93aW5nIGFjdGlvbnM6DQoNCiAgICAgICAqICBJZiBhbiBlcnJvciBvY2N1cnJlZCwg dGhlIHNlcnZlciBzZW5kcyBhIFRIUk9XIG5vdGlmaWNhdGlvbg0KICAgICAgICAgIChlaXRo ZXIgYXMgVEhST1cgcmVxdWVzdCBvciBhcyBBQ0srVEhST1cgcmVwbHkgdG8gdGhlDQogICAg ICAgICAgU1VCU0NSSUJFIHJlcXVlc3QpLg0KDQo8UkNDPldoeSB3b3VsZCBpdCBiZSBhIFRI Uk9XIHJlcXVlc3Q/IENhbGxpbmcgaXQgdGhpcyBsb3NlcyB0aGUgZWZmZWN0IHRoYXQgaXQg aXMgYSByZXBseSB0byB0aGUgU1VCU0NSSUJFIHJlcXVlc3QuIElmIGl0IHJlYWxseSBpcyBh IHJlcXVlc3QsIGRpc3Rpbmd1aXNoIGl0IGZyb20gdGhlIFNVQlNDUklCRSByZXF1ZXN0IGF0 IHRoYXQgbGV2ZWwuIFRoZSBhYmlsaXR5IHRvIGNvbmNhdGVuYXRlIG1lc3NhZ2VzIHNob3Vs ZCBiZSBsZWZ0IHRvIHRoZSB0cmFuc2FjdGlvbiBtYW5hZ2VtZW50LiBJbiBmYWN0LCB3aGF0 IGFjdHVhbGx5IGlzIGFuIEFDSz88L1JDQz4gICAgICAgICANCg0KICAgICAgICogIElmIHRo ZSByZXNvdXJjZSBoYXMgZmluaXNoZWQgc2VuZGluZyBub3RpZmljYXRpb25zLCB0aGUgc2Vy dmVyDQogICAgICAgICAgc2VuZHMgYSBCUkVBSyBub3RpZmljYXRpb24gKGVpdGhlciBhcyBC UkVBSyByZXF1ZXN0IG9yIGFzIEFDSysNCiAgICAgICAgICBCUkVBSyByZXBseSB0byB0aGUg U1VCU0NSSUJFIHJlcXVlc3QpLg0KDQo8UkNDPlNhbWUgYXMgY29tbWVudCBmb3IgVEhST1c8 L1JDQz4NCg0KICAgICAgICogIE90aGVyd2lzZSwgdGhlIHNlcnZlciBzdXBwbGllcyB0aGUg b2JzZXJ2ZXIgd2l0aCB0aGUgY3VycmVudA0KICAgICAgICAgIHJlc291cmNlIHN0YXRlIGlu IHRoZSByZXF1ZXN0ZWQgcmVwcmVzZW50YXRpb24gZm9ybWF0LCBvcg0KICAgICAgICAgIGlu ZGljYXRlcyB0aGF0IHRoZSBjYWNoZWQgc3RhdGUgaXMgdGhlIGN1cnJlbnQgc3RhdGUgKGVp dGhlcg0KICAgICAgICAgIGFzIFlJRUxEIHJlcXVlc3Qgb3IgYXMgQUNLK1lJRUxEIHJlcGx5 IHRvIHRoZSBTVUJTQ1JJQkUNCiAgICAgICAgICByZXF1ZXN0KS4NCg0KPFJDQz5TYW1lIGFz IGNvbW1lbnQgZm9yIFRIUk9XPC9SQ0M+DQoNCiAgICAgICBJZiB0aGUgc2VydmVyIHNlbmRz IGEgVEhST1csIEJSRUFLIG9yIFlJRUxEIHJlcXVlc3QsIHRoZSByZXF1ZXN0DQogICAgICAg aXMgdHJlYXRlZCBsaWtlIGFueSBvdGhlciBub3RpZmljYXRpb24gKGkuZS4gdGhlIGNsaWVu dCBtdXN0DQogICAgICAgYWNrbm93bGVkZ2UgaXQgaWYgdGhlIG1lc3NhZ2UgaXMgbWFya2Vk IGFzIGNvbmZpcm1hYmxlLCBldGMuKS4NCg0KPFJDQz5JcyBhIHJlcXVlc3QgdGhlcmVmb3Jl IGEgdHlwZSBvZiBub3RpZmljYXRpb24gb3IgaXMgaXQgYXQgdGhlIHNhbWUgbGV2ZWwgb2Yg YWJzdHJhY3Rpb24/PC9SQ0M+DQoNCiAgIDQuICBJZiB0aGUgY2xpZW50IGRvZXMgbm90IHJl Y2VpdmUgdGhlIEFDSywgQUNLK1RIUk9XLCBBQ0srQlJFQUsgb3INCiAgICAgICBBQ0srWUlF TEQgcmVwbHkgd2l0aGluIGEgY2VydGFpbiB0aW1lIGZyYW1lIChiZWNhdXNlIHRoZSByZXF1 ZXN0DQogICAgICAgb3IgdGhlIHJlcGx5IHdlbnQgbWlzc2luZyksIHRoZSBjbGllbnQgcmV0 cmFuc21pdHMgdGhlIFNVQlNDUklCRQ0KICAgICAgIHJlcXVlc3QgdXNpbmcgdGhlIHNhbWUg cmVxdWVzdCBpZGVudGlmaWVyLg0KICAgICAgDQo8UkNDPkkgd291bGQgc2F5ICdtYXkgcmV0 cmFuc21pdCcuIFRoZXJlIG1heSBiZSBzY2VuYXJpb3Mgd2hlcmUgdGhpcyBpcyBub3QgcmVx dWlyZWQuPC9SQ0M+DQoNCjxzbmlwPg0KDQogICAgICAgVGhlIHNlcnZlciBtYXkgb3IgbWF5 IG5vdCBtYXJrIHRoZSByZXF1ZXN0IHNlbnQgYXMgY29uZmlybWFibGUNCiAgICAgICAoIltj XSIpLiAgVGhlIHNlcnZlciBtYXJrcyBhIHJlcXVlc3QgYXMgY29uZmlybWFibGUgYmVjYXVz ZSBpdA0KICAgICAgIHdhbnRzIHRvIGNoZWNrIGlmIHRoZSBvYnNlcnZlciBpcyBzdGlsbCBh bGl2ZSwgb3IgYmVjYXVzZSB0aGVyZQ0KICAgICAgIG1pZ2h0IG5vdCBiZSBhbm90aGVyIG5v dGlmaWNhdGlvbiBpbiB0aGUgbmVhciBmdXR1cmUgYW5kIHRoZQ0KICAgICAgIGNvbmZpcm1h dGlvbiBwcm9jZXNzIGlzIHRoZXJlZm9yZSBuZWVkZWQgdG8gZW5zdXJlIGV2ZW50dWFsDQog ICAgICAgY29uc2lzdGVuY3kuDQoNCjxSQ0M+VG8gc29tZSBleHRlbnQsIGl0IG1pZ2h0IGJl IGJldHRlciBpZiB0aGUgc2VydmVyIHJlcXVpcmVzIGEgY2VydGFpbiBkZWxpdmVyeSBwcm9w ZXJ0eSBmcm9tIHRoZSB0cmFuYWN0aW9uIGhhbmRsaW5nLiBUaGVuIHdoZXRoZXIgaXQgaXMg QUNLZWQgb3Igbm90IGlzIG5vdCBhIGNvbmNlcm4gZm9yIHRoZSBhcHBsaWNhdGlvbiBsYXll ci4gVGhlIGludm9jYXRpb24gcmV0dXJuIHdvdWxkIGluZGljYXRlIHRoZSBzdWNjZXNzIGFj Y29yZGluZyB0byB0aGUgdW5kZXJseWluZyB0cmFuc2FjdGlvbjwvUkNDPg0KDQo8c25pcD4N Cg0KICAgTm90ZSB0aGF0IGFuIHN1YnNjcmliZWQgY2xpZW50IGNhbiBhbHNvIHVuc3Vic2Ny aWJlIGJ5ICJmb3JnZXR0aW5nIg0KICAgdGhlIHN1YnNjcmlwdGlvbiBhbmQgc3Vic2VxdWVu dGx5IHJlcGx5aW5nIHdpdGggYSBSU1QgdG8gdGhlIG5leHQNCiAgIG5vdGlmaWNhdGlvbi4g IChJbiBvcmRlciB0byBhbGxvdyBzZW5kaW5nIHRoYXQgUlNUIGV2ZW4gZm9yIG1lc3NhZ2Vz DQogICB0aGF0IGFyZSBub3QgbWFya2VkIGFzIGNvbmZpcm1hYmxlLCBhbiBvdGhlcndpc2Ug cmVkdW5kYW50DQogICB0cmFuc2FjdGlvbiBpZGVudGlmaWVyIGlzIHNlbnQgaW4gYWxsIG1l c3NhZ2VzLikNCiAgDQo8UkNDPkRvZXMgdGhhdCBuZWNlc3NhcmlseSBpbmRpY2F0ZSBhbiB1 bnN1YnNjcmlwdGlvbj8gSXQgY291bGQgYmUgYSBmYWlsdXJlIHRvIHByb2Nlc3MgZm9yIGFu eSByZWFzb24uIFRoZSBzZXJ2ZXIgbWF5IG5vdCBuZWNlc3NhcmlseSBrbm93LjwvUkNDPg0K DQo8c25pcD4NCg0KICAgT2J2aW91c2x5LCBjaGFuZ2luZyB0aGUgc3RhdGUgb2YgdGhpcyBy ZXNvdXJjZSBsZWFkcyB0byBub3RpZmljYXRpb24NCiAgIG9mIGFueSBvYnNlcnZlcnMgb2Yg bmV3IHN0YXRlLiAgUFVUIGlzIGlkZW1wb3RlbnQsIGJ1dCBpZiB3ZSBhZGQNCiAgIG5vdGlm aWNhdGlvbnMgaXQgbWF5IGJlIGEgYml0IHN1cnByaXNpbmcgdGhhdCBhIGR1cGxpY2F0ZWQg b3INCiAgIHJldHJhbnNtaXR0ZWQgUFVUIG1pZ2h0IHNlbmQgbm90aWZpY2F0aW9ucyB0d2lj ZS4gIFRvIHByZXZlbnQgdGhhdCwNCiAgIHRoZSByZXNvdXJjZSBtaWdodCBjaGVjayB3aGV0 aGVyIGl0IGlzIGJlaW5nIGNoYW5nZWQgdG8gdGhlIHNhbWUNCiAgIHN0YXRlIGl0IGhhZCBi ZWZvcmUgYW5kIG5vdCBzZW5kIG5vdGlmaWNhdGlvbnMgaW4gdGhhdCBjYXNlLg0KICANCjxS Q0M+VGhpcyB3b3VsZCBiZSBiZXR0ZXIgaGFuZGxlZCBieSBkZWxlZ2F0aW5nIHRvIHRoZSB0 cmFuc2FjdGlvbiBtYW5hZ2VtZW50PC9SQ0M+DQoNCjxzbmlwPg0KDQogICBBbm90aGVyIGFw cHJvYWNoIHRvIGNhY2hpbmcgbXVsdGlwbGUgdmFsdWVzIGZvciBhIHJlc291cmNlIGlzIHRv DQogICBleHByZXNzIGVhY2ggcG9zc2libGUgdmFsdWUgb2YgdGhlIHJlc291cmNlJ3MgcmVw cmVzZW50YXRpb24gYnkgYQ0KICAgcmVmZXJlbmNlIHRvIGFub3RoZXIgKHVuY2hhbmdpbmcp IHJlc291cmNlLiAgVGhpcyBsZXRzIGEgcmVzb3VyY2UNCiAgIGNoYW5nZSBzdGF0ZXMgYmV0 d2VlbiBhIHNldCBvZiBzdWNoIHJlZmVyZW5jZXMgdGhhdCB0aGVuIHByb3ZpZGUgdGhlDQog ICBhY3R1YWwgc3RhdGUgaW5mb3JtYXRpb24uICBBIHN1YnNjcmliZWQgY2xpZW50IGZldGNo ZXMgdGhlIGluZGl2aWR1YWwNCiAgIHJlc291cmNlcyBvbiBkZW1hbmQgYW5kIGNhY2hlcyB0 aGUgcmVzdWx0cyBmb3IgZnV0dXJlIHVzZS4NCg0KPFJDQz5Ob3Qgc3VyZSBJIHVuZGVyc3Rh bmQgdGhpcy4gSW4gZXNzZW5jZSwgaXQgc291bmRzIGp1c3QgbGlrZSB3aGF0IFJFU1QgaXMs IGkuZS4gc2VuZGluZyBhIHJlcHJlc2VudGF0aW9uIG9mIGEgcmVzb3VyY2UgYnV0IGluIHRo aXMgY2FzZSwgYSAnc2hvcnRoYW5kJyB3aGljaCBjYW4gYmUgdXNlZCB0byBpbmRleCB0aGUg YWN0dWFsIHNldCBvZiBkYXRhIHRoZSBpbmRleCByZXByZXNlbnRzLjxSQ0M+DQoNCjxzbmlw Pg0KDQo2LiAgSWRlbnRpZnlpbmcgbm90aWZpY2F0aW9ucyBhbmQgc3Vic2NyaXB0aW9ucw0K DQogICBUaGVyZSBhcmUgdHdvIHdheXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBjb3VsZCBiZSBy ZWxhdGVkIHRvIHRoZQ0KICAgcmVzb3VyY2UgdGhhdCBpdCBpcyBhYm91dDoNCg0KICAgMS4g IFRoZSBub3RpZmljYXRpb24gY291bGQgbmFtZSB0aGUgcmVzb3VyY2UgKGl0cyBVUkkpLg0K DQogICAyLiAgVGhlIG5vdGlmaWNhdGlvbiBjb3VsZCBuYW1lIGEgdGFyZ2V0IHRoYXQgcmVs YXRlcyB0byBhDQogICAgICAgc3Vic2NyaXB0aW9uLCB3aGljaCBpbiB0dXJuIHJlbGF0ZXMg YmFjayB0byB0aGUgcmVzb3VyY2UuDQoNCiAgIE9uZSBvciBib3RoIHdheXMgY291bGQgYmUg aW1wbGVtZW50ZWQgaW4gQ29BUCwgdGhlcmUgYXJlIG5vdA0KICANCjxSQ0M+TWlzc2luZyB0 ZXh0PzwvUkNDPg0KDQogICBGb3Igd2F5IDEsIGVhY2ggbm90aWZpY2F0aW9uIHdvdWxkIGNv bnRhaW4gdGhlIFVSSSBvZiB0aGUgcmVzb3VyY2UuDQogICBUaGlzIGlzIHBhcnRpY3VsYXJs eSB1c2VmdWwgZm9yIG11bHRpY2FzdCBtZXNzYWdlcywgYnV0IGNvdWxkIGJlDQogICByZWxh dGl2ZWx5IHdhc3RlZnVsLiAgQWxzbywgaXQgaXMgbm90IGVudGlyZWx5IGNsZWFyIHRoYXQg YWxsIHNlcnZlcnMNCiAgIHdpbGwgYmUgYXdhcmUgb2YgdGhlaXIgb3duIGF1dGhvcml0eS4g IEFwYXJ0IGZyb20gY2FjaGVkIHN0YXRlcw0KICAgKFNlY3Rpb24gNSkgYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHRoYXQgY291bGQgYmUgcGFydCBvZiBhIEdFVCwgYQ0KICAgc3Vic2NyaXB0 aW9uIHdvdWxkIHNpbXBseSBiZSB0aGUgdHJpcGxlDQoNCiAgICAgIFtVUkksIG9ic2VydmVy IHRyYW5zcG9ydCBhZGRyZXNzLCBsaWZldGltZV0NCg0KPFJDQz5XaGF0IGlzICdvYnNlcnZl ciB0cmFuc3BvcnQgYWRkcmVzcyc/IFRvIGJlIFJFU1RmdWwsIHRoZSBjbGllbnQgc2hvdWxk IGJlIGEgVVJJIHRvbywgc2hvdWxkIGl0IG5vdD88L1JDQz4NCg0KICAgUmVzdWJzY3JpYmlu ZyAob3IgYSBkdXBsaWNhdGUgc3Vic2NyaXB0aW9uIHJlcXVlc3QpIGZvciB0aGUgc2FtZQ0K ICAgW1VSSSwgb2JzZXJ2ZXIgdHJhbnNwb3J0IGFkZHJlc3NdIHBhaXIgc2ltcGx5IHVwZGF0 ZXMgdGhlIGxpZmV0aW1lOw0KICAgdGh1cywgdGhlIHN1YnNjcmlwdGlvbiBvcGVyYXRpb24g aXMgaWRlbXBvdGVudC4gIFNpbWlsYXJseSwNCiAgIHJlc3Vic2NyaWJpbmcgd2l0aCBhIGxp ZmV0aW1lIG9mIDAgd2lsbCBzZXJ2ZSB0byBkZWxldGUgdGhlDQogICBzdWJzY3JpcHRpb24g KGhvd2V2ZXIsIGEgU1VCU0NSSUJFIG1lc3NhZ2Ugd2lsbCBiZSByZXBsaWVkIHRvIHdpdGgN CiAgIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSByZXNvdXJjZTsgYSBTVUJTQ1JJQkUgd2l0 aCBsaWZldGltZSAwIGlzDQogICB0aHVzIGVxdWl2YWxlbnQgdG8gYSBHRVQgd2l0aCB0aGUg c2lkZSBlZmZlY3Qgb2YgZGVsZXRpbmcgdGhlDQogICBzdWJzY3JpcHRpb24pLg0KICANCjxS Q0M+Q29uZnVzaW5nIHdyaXR0ZW4gaW4gbmFycmF0aXZlIHRleHQgLSBsaXN0IHRoZSBjaG9p Y2VzPC9SQ0M+DQoNCjxzbmlwPg== --=_ed1f9e990bd89363423e29020ad87236-- From zach@sensinode.com Sun Jul 4 23:48: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 BDA243A657C for ; Sun, 4 Jul 2010 23:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[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 v9FNMTvtV8q4 for ; Sun, 4 Jul 2010 23:48:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 52DC03A6902 for ; Sun, 4 Jul 2010 23:48:08 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o656m5OZ026857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Jul 2010 09:48:05 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: Date: Mon, 5 Jul 2010 09:48:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <23784A49-24D1-470B-90A5-F08B45A731EA@sensinode.com> References: To: Robert Cragie X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Comments on draft-hartke-coap-observe-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, 05 Jul 2010 06:48:10 -0000 On Jul 4, 2010, at 8:20 PM, Robert Cragie wrote: > Sorry these are a little late. >=20 > To summarize: > =95 The document moves around layers of abstraction somewhat. = Some of the concepts are quite abstract (observer, subject etc.), then = it talks about messages, then it refers to reliable UDP. I think it = should keep to the abstract level and defer discussion on the more = specific layers to other documents Definitely. In the next version I would like to see two parts to the = document actually. 1. The requirements and purely abstract model (using = sane terminology). 2. The solution for doing subscription using coap-01 = (so it still makes it before the -01 cutoff). We decided to move the = solution to the next version of coap-observe to avoid contaminating the = base coap document while it is perfected. The goal is to move the = feature to coap-02 after Maastricht.=20 > =95 I know I have said this before but I believe it is important = to abstract the transaction model from the methods themselves. This = means we can put a clean break between the RESTful part (plus pub/sub) = and the transactions (HTTP-like or more asynchronous for M2M). What may = be missing is to specify abstract properties of the delivery, which is = sort of addressed by message types in this document. Bingo! This is exactly what we have done in coap-01, so far it seems to = work nicely, and it even further simplified the header. Zach > I tried to attach as modified original but I think it was too large = for mail server. In the attachment my comments are in as . = indicates where I have put out text not directly relevant to the = comment. >=20 > Robert > --=20 > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com >=20 >=20 >=20 > = ___________________________= ____________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Mon Jul 5 01:36:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117643A67B3 for ; Mon, 5 Jul 2010 01:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.856 X-Spam-Level: X-Spam-Status: No, score=-101.856 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 DV5+dEjhtJVr for ; Mon, 5 Jul 2010 01:36:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 57EBA3A672E for ; Mon, 5 Jul 2010 01:36:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OVhAA-00028A-I0; Mon, 05 Jul 2010 01:36:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: brian@skyfoundry.com, zach@sensinode.com X-Trac-Project: core Date: Mon, 05 Jul 2010 08:36:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/8#comment:2 Message-ID: <066.06d4c0da111bfe55221ac38c2282c4a3@tools.ietf.org> References: <057.5550c2ce1e044942c5f36167340ceedd@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <057.5550c2ce1e044942c5f36167340ceedd@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: brian@skyfoundry.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #8: Complete Section 5.3 Proxying X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:36:29 -0000 #8: Complete Section 5.3 Proxying --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Brian Frank Type: enhancement | Status: closed Priority: major | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: coap-01 section completed. Will make a new ticket for coap-02 improvements later. -- Ticket URL: core From trac@tools.ietf.org Mon Jul 5 01:44:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3083A67FE for ; Mon, 5 Jul 2010 01:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 bYVIJU-DdNHS for ; Mon, 5 Jul 2010 01:44:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2A54A3A65A5 for ; Mon, 5 Jul 2010 01:44:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OVhHu-0002TQ-8q; Mon, 05 Jul 2010 01:44:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Mon, 05 Jul 2010 08:44:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/15#comment:3 Message-ID: <062.be1f2d3450e5d61a8247669418ca1499@tools.ietf.org> References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:44:29 -0000 #15: Consolidate maximum sizes (encodings, options table, maximum datagram) --------------------------------+------------------------------------------- Reporter: hartke@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: coap | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Based on the list discussion it seems that we should keep the MUST fit in a datagram and recommend a size when the MTU is unknown of 1280 byte. The text about 6LoWPAN was left out as this really is link-specific, and should be obvious to the implementor on such a constrained node/network. The text for coap-01 is thus planned as: "The length of the Payload in a CoAP message is calculated from the datagram length. A CoAP message MUST fit within a single datagram. When the MTU is not known, then the minimum IPv6 MTU of 1280 bytes SHOULD be assumed." This text would change if the Block Option from coap-misc would be added later. -- Ticket URL: core From zach@sensinode.com Mon Jul 5 01:47:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49FC3A683E for ; Mon, 5 Jul 2010 01:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.492 X-Spam-Level: X-Spam-Status: No, score=-0.492 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_40=-0.185, J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=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 W6jeRKMjBDop for ; Mon, 5 Jul 2010 01:47:48 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id F28EF3A65A5 for ; Mon, 5 Jul 2010 01:47:47 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o658lelG004974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Jul 2010 11:47:41 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: Date: Mon, 5 Jul 2010 11:47:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <30A25E3E-29BF-4A6C-9A07-262E2BAAC995@sensinode.com> References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> To: "Oflynn, Colin" X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 08:47:49 -0000 Yep, I removed the 6LoWPAN text as that should be obvious to people = using it. For the vast majority of LAN link-layers that MTU is 1500 = bytes, so letting them use that doesn't stretch the use of CoAP that = much. In the case of e.g. 6LoWPAN the MTU would be 1280 bytes. The = current text assumes 1280 bytes unless the MTU is otherwise known. Zach On Jul 3, 2010, at 12:37 AM, Oflynn, Colin wrote: > Hello, >=20 > I would also support just forcing a size of 1280. This 'artificial' = limit serves to stop people from trying to use CoAP for stuff it wasn't = designed for, even if their link-layer really does support bigger = packets. >=20 > Regards, >=20 > -Colin >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org on behalf of Guido Moritz > Sent: Fri 02/07/2010 11:37 > To: 'Zach Shelby'; 'Carsten Bormann'; 'core' > Cc: 'core issue tracker' > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram) >=20 > I don't like the differentiation depending on the 'link layer'. 1280 = seems > to be reasonable as the magic number of 6LoWPAN networks in general ;) >=20 > Guido >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag > > von Zach Shelby > > Gesendet: Freitag, 2. Juli 2010 10:08 > > An: Carsten Bormann; core > > Cc: core issue tracker > > Betreff: Re: [core] #15: Consolidate maximum sizes (encodings, = options > > table, maximum datagram) > > > > Any other comments on this one? Carsten didn't like the "physical > > inteface", I can remove that. Otherwise I think discussing in terms = of > > MTU is the best we can do. > > > > Zach > > > > On Jun 30, 2010, at 1:39 PM, core issue tracker wrote: > > > > > #15: Consolidate maximum sizes (encodings, options table, maximum > > datagram) > > > = --------------------------------+------------------------------------ > > ------- > > > Reporter: hartke@. | Owner: > > > Type: defect | Status: new > > > Priority: minor | Milestone: > > > Component: coap | Version: 1.0 > > > Severity: Active WG Document | Keywords: > > > = --------------------------------+------------------------------------ > > ------- > > > > > > Comment(by zach@.): > > > > > > - The URI and option length discrepency is being fixed already. > > > > > > - Regarding the maximum message size, I propose text like this = which > > is > > > similar to that used by other UDP based protocols such as m-DNS: > > > > > > "The resulting datagram carrying a CoAP message MUST fit within a > > single > > > MTU of that phsical interface, which is typically 1500 bytes for = an > > > Ethernet interface and 1280 bytes for a 6LoWPAN interface." > > > > > > -- > > > Ticket URL: > > > > > core > > > > > > > -- > > Zach Shelby, Chief Nerd, Sensinode Ltd. > > http://zachshelby.org - My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" > > Mobile: +358 40 7796297 > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Mon Jul 5 02:29: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 E974E3A688D for ; Mon, 5 Jul 2010 02:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 Lex6yrfiubiW for ; Mon, 5 Jul 2010 02:29:33 -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 977B73A686A for ; Mon, 5 Jul 2010 02:29:32 -0700 (PDT) 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 o659TWQX021293; Mon, 5 Jul 2010 11:29:32 +0200 (CEST) Received: from [192.168.217.101] (p5489CBB7.dip.t-dialin.net [84.137.203.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 0F8E2B70C; Mon, 5 Jul 2010 11:29:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> Date: Mon, 5 Jul 2010 11:29:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 09:29:35 -0000 On Jul 2, 2010, at 12:37, Guido Moritz wrote: > 1280 seems > to be reasonable as the magic number of 6LoWPAN networks in general ;) Well, 1280 is the magic number of IPv6 MTUs. 6LoWPAN does support 1280 byte packets, but splitting a packet into 15 = or 20 fragments is expensive in terms of reduced probability of = delivery. Worse, Protocols like RPL can steal some of these bytes (and the IP and = UDP headers will, too). CoAP implementations should be able to operate on any UDP datagram that = fits into the IPv6 MTU. =20 But having a good idea of what is actually efficient to use also helps. So I would rarely send a CoAP payload of more than 1024 bytes; adding in = CoAP options (the total size of which depends a lot on the length of the = URI), CoAP fixed header (4 bytes), UDP header and IP header then is = likely to leave some room for RPL and other tunnel stunts. For applications such as firmware transfers on 6LoWPAN, I would stick = with a payload size of 64 (1 fragment) or 128 (two fragments); that's = why coap://ns.tzi.org:61616/ has 128 as the default block size. Gruesse, Carsten From Colin.OFlynn@atmel.com Mon Jul 5 03:19: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 479553A6849 for ; Mon, 5 Jul 2010 03:19:48 -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 rEeQbK6uQVGl for ; Mon, 5 Jul 2010 03:19:47 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 216E43A6814 for ; Mon, 5 Jul 2010 03:19:46 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o65AHN8Q014269; Mon, 5 Jul 2010 03:17:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1C2B.8AD61238" Date: Mon, 5 Jul 2010 04:14:45 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) Thread-Index: AcscHlIkrEjN2CokTLesM5NjfU4hfQADJIXx References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.be1f2d3450e5d61a8247669418ca1499@tools.ietf.org> From: "Oflynn, Colin" To: "core issue tracker" , , Cc: core@ietf.org Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 10:19:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1C2B.8AD61238 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, > When > the MTU is not known, then the minimum IPv6 MTU of 1280 bytes SHOULD = be > assumed. I think this text is somewhat dangerous, and would prefer just a fixed = limit still. It's not entirely clear what MTU you are talking about. e.g.: Someone could be sending a CoAP packet on an Ethernet network, and = not know that the other end of it will actually be a 6LoWPAN network. = Thus they use the MTU of the Ethernet network which seems in line with = the specification, but will cause problems on 6LoWPAN. Or am I missing something here? Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of core issue tracker Sent: Mon 05/07/2010 09:44 To: cabo@tzi.org; zach@sensinode.com Cc: core@ietf.org Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table, maximum datagram) =20 #15: Consolidate maximum sizes (encodings, options table, maximum = datagram) --------------------------------+----------------------------------------= --- Reporter: hartke@. | Owner: =20 Type: defect | Status: closed Priority: minor | Milestone: =20 Component: coap | Version: 1.0 =20 Severity: Active WG Document | Resolution: fixed=20 Keywords: | =20 --------------------------------+----------------------------------------= --- Changes (by zach@.): * status: new =3D> closed * resolution: =3D> fixed Comment: Based on the list discussion it seems that we should keep the MUST fit = in a datagram and recommend a size when the MTU is unknown of 1280 byte. = The text about 6LoWPAN was left out as this really is link-specific, and should be obvious to the implementor on such a constrained = node/network. The text for coap-01 is thus planned as: "The length of the Payload in a CoAP message is calculated from the datagram length. A CoAP message MUST fit within a single datagram. When the MTU is not known, then the minimum IPv6 MTU of 1280 bytes SHOULD be assumed." This text would change if the Block Option from coap-misc would be = added later. --=20 Ticket URL: = core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CB1C2B.8AD61238 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] #15: Consolidate maximum sizes (encodings, options = table, maximum datagram)

Hello,

> When
> the MTU is not known, then the minimum IPv6 MTU of 1280 bytes = SHOULD be
> assumed.

I think this text is somewhat dangerous, and would prefer just a fixed = limit still. It's not entirely clear what MTU you are talking about.

e.g.: Someone could be sending a CoAP packet on an Ethernet network, and = not know that the other end of it will actually be a 6LoWPAN network. = Thus they use the MTU of the Ethernet network which seems in line with = the specification, but will cause problems on 6LoWPAN.

Or am I missing something here?

Regards,

  -Colin


-----Original Message-----
From: core-bounces@ietf.org on behalf of core issue tracker
Sent: Mon 05/07/2010 09:44
To: cabo@tzi.org; zach@sensinode.com
Cc: core@ietf.org
Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table, maximum datagram)

#15: Consolidate maximum sizes (encodings, options table, maximum = datagram)
--------------------------------+----------------------------------------= ---
 Reporter:  = hartke@.           = ; |        = Owner:       
     Type:  = defect           &= nbsp;  |       Status:  = closed
 Priority:  = minor           &n= bsp;   |    = Milestone:       
Component:  = coap           &nb= sp;    |      Version:  = 1.0  
 Severity:  Active WG Document  |   = Resolution:  fixed
 Keywords:         &nbs= p;            = | 
--------------------------------+----------------------------------------= ---
Changes (by zach@.):

  * status:  new =3D> closed
  * resolution:  =3D> fixed


Comment:

 Based on the list discussion it seems that we should keep the MUST = fit in
 a datagram and recommend a size when the MTU is unknown of 1280 = byte. The
 text about 6LoWPAN was left out as this really is link-specific, = and
 should be obvious to the implementor on such a constrained = node/network.
 The text for coap-01 is thus planned as:

 "The length of the Payload in a CoAP message is calculated = from the
 datagram length. A CoAP message MUST fit within a single datagram. = When
 the MTU is not known, then the minimum IPv6 MTU of 1280 bytes = SHOULD be
 assumed."

 This text would change if the Block Option from coap-misc would be = added
 later.

--
Ticket URL: <http= ://trac.tools.ietf.org/wg/core/trac/ticket/15#comment:3>
core <http://tools.ietf.org/core/><= BR>
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/= mailman/listinfo/core

------_=_NextPart_001_01CB1C2B.8AD61238-- From cabo@tzi.org Mon Jul 5 03:29: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 5453F3A685B for ; Mon, 5 Jul 2010 03:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7erIIU2hROVd for ; Mon, 5 Jul 2010 03:29:42 -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 3C6913A63EC for ; Mon, 5 Jul 2010 03:29:41 -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 o65ATWhw027303; Mon, 5 Jul 2010 12:29:32 +0200 (CEST) Received: from [192.168.217.101] (p5489CBB7.dip.t-dialin.net [84.137.203.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id BE19BB778; Mon, 5 Jul 2010 12:29:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 5 Jul 2010 12:29:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65A60A31-AE1D-4962-9A44-9F8FA097CC0E@tzi.org> References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.be1f2d3450e5d61a8247669418ca1499@tools.ietf.org> To: "Oflynn, Colin" X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core@ietf.org Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 10:29:43 -0000 On Jul 5, 2010, at 12:14, Oflynn, Colin wrote: > fixed limit 1152? Divides the space between 1280 (IPv6 MTU) and 1024 (useful largest = payload size) evenly between CoAP headers/options and = IPv6/UDP/extension(RH, ESP, ...) headers. Gruesse, Carsten From Colin.OFlynn@atmel.com Mon Jul 5 03:50: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 AF6CB3A686C for ; Mon, 5 Jul 2010 03:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, WEIRD_PORT=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 PCBFnl3-dvRH for ; Mon, 5 Jul 2010 03:50:19 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 1A40A3A67C0 for ; Mon, 5 Jul 2010 03:50:19 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o65AlvEu016908; Mon, 5 Jul 2010 03:47:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1C2F.CFDC14D4" Date: Mon, 5 Jul 2010 04:49:58 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) Thread-Index: AcscJJ2alFgzRGStSGu5V97sYQNbpgAB919S References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> From: "Oflynn, Colin" To: "Carsten Bormann" , "Guido Moritz" Cc: core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 10:50:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1C2F.CFDC14D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I think unfortunately the question of "optimum packet size" will always = be "it depends". I'm assuming in the following you *need* to send a = larger packet for some reason.=20 Performing the fragmentation at the 6LoWPAN layer should be the most = efficient, as you don't waste having IP/UDP/CoAP headers on each packet. = This would suggest sending as large an IPv6 packet as possible. Under = reasonable network conditions a 6LoWPAN network can do this pretty = reliably (1280 byte delivery). But in a bad RF environment though the lower layers may not deliver this = message as reliably. Normally 802.15.4 will retry sending each 6LoWPAN = fragment three times, after which it gives up. You then need to resend = the entire IPv6 packet until all the fragments get through. As each time = you are sending many (say 10) fragments, this could take a few tries! = This would suggest keeping the IPv6 packet as small as possible, so each = individual IPv6 packet is likely to get through, and when they fail you = aren't resending as much. Again I think it comes down to CoAP being a simple protocol. It will = work great for small packets basically no matter what. It should work = pretty well for larger packets too even. But if you want to transfer = lots of data (firmware, etc) it's better to use something designed for = the purpose.=20 Another consideration for CoAP data is not just the transfer of it, but = actually buffering the data in memory. I would guess most constrained = (ie: 8-bit processor) devices are designed around having a 1280 byte IP = buffer. The actual resources need to be designed with this in mind too! Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Carsten Bormann Sent: Mon 05/07/2010 10:29 To: Guido Moritz Cc: core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram) =20 On Jul 2, 2010, at 12:37, Guido Moritz wrote: > 1280 seems > to be reasonable as the magic number of 6LoWPAN networks in general ;) Well, 1280 is the magic number of IPv6 MTUs. 6LoWPAN does support 1280 byte packets, but splitting a packet into 15 = or 20 fragments is expensive in terms of reduced probability of = delivery. Worse, Protocols like RPL can steal some of these bytes (and the IP and = UDP headers will, too). CoAP implementations should be able to operate on any UDP datagram that = fits into the IPv6 MTU. =20 But having a good idea of what is actually efficient to use also helps. So I would rarely send a CoAP payload of more than 1024 bytes; adding in = CoAP options (the total size of which depends a lot on the length of the = URI), CoAP fixed header (4 bytes), UDP header and IP header then is = likely to leave some room for RPL and other tunnel stunts. For applications such as firmware transfers on 6LoWPAN, I would stick = with a payload size of 64 (1 fragment) or 128 (two fragments); that's = why coap://ns.tzi.org:61616/ has 128 as the default block size. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CB1C2F.CFDC14D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram)

Hello,

I think unfortunately the question of "optimum packet size" = will always be "it depends". I'm assuming in the following you = *need* to send a larger packet for some reason.

Performing the fragmentation at the 6LoWPAN layer should be the most = efficient, as you don't waste having IP/UDP/CoAP headers on each packet. = This would suggest sending as large an IPv6 packet as possible. Under = reasonable network conditions a 6LoWPAN network can do this pretty = reliably (1280 byte delivery).

But in a bad RF environment though the lower layers may not deliver this = message as reliably. Normally 802.15.4 will retry sending each 6LoWPAN = fragment three times, after which it gives up. You then need to resend = the entire IPv6 packet until all the fragments get through. As each time = you are sending many (say 10) fragments, this could take a few tries! = This would suggest keeping the IPv6 packet as small as possible, so each = individual IPv6 packet is likely to get through, and when they fail you = aren't resending as much.

Again I think it comes down to CoAP being a simple protocol. It will = work great for small packets basically no matter what. It should work = pretty well for larger packets too even. But if you want to transfer = lots of data (firmware, etc) it's better to use something designed for = the purpose.

Another consideration for CoAP data is not just the transfer of it, but = actually buffering the data in memory. I would guess most constrained = (ie: 8-bit processor) devices are designed around having a 1280 byte IP = buffer. The actual resources need to be designed with this in mind = too!

Regards,

   -Colin




-----Original Message-----
From: core-bounces@ietf.org on behalf of Carsten Bormann
Sent: Mon 05/07/2010 10:29
To: Guido Moritz
Cc: core
Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram)

On Jul 2, 2010, at 12:37, Guido Moritz wrote:

> 1280 seems
> to be reasonable as the magic number of 6LoWPAN networks in general = ;)

Well, 1280 is the magic number of IPv6 MTUs.
6LoWPAN does support 1280 byte packets, but splitting a packet into 15 = or 20 fragments is expensive in terms of reduced probability of = delivery.

Worse, Protocols like RPL can steal some of these bytes (and the IP and = UDP headers will, too).
CoAP implementations should be able to operate on any UDP datagram that = fits into the IPv6 MTU.

But having a good idea of what is actually efficient to use also = helps.
So I would rarely send a CoAP payload of more than 1024 bytes; adding in = CoAP options (the total size of which depends a lot on the length of the = URI), CoAP fixed header (4 bytes), UDP header and IP header then is = likely to leave some room for RPL and other tunnel stunts.
For applications such as firmware transfers on 6LoWPAN, I would stick = with a payload size of 64 (1 fragment) or 128 (two fragments); that's = why coap://ns.tzi.org:61616/ has 128 as the default block size.

Gruesse, Carsten

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

------_=_NextPart_001_01CB1C2F.CFDC14D4-- From zach@sensinode.com Mon Jul 5 03:59:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6AA3A6820 for ; Mon, 5 Jul 2010 03:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 QfTVXQzpuJXB for ; Mon, 5 Jul 2010 03:59:11 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B9B313A6874 for ; Mon, 5 Jul 2010 03:59:10 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o65Ax114024389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Jul 2010 13:59:02 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 5 Jul 2010 13:59:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> To: "Oflynn, Colin" X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 10:59:12 -0000 Colin, You captured the situation perfectly. So now just to get that down in = text for coap-01 - the hard part. Seems I closed that ticket = prematurely. Carsten pointed that we have two options: 1. Define that this must fit in an IPv6 packet with an MTU of 1280 = bytes.=20 or 2. Define a fixed octet limit of e.g. 1152. At that point why not just = say 1024 bytes. Regarding 6LoWPAN how about we do the following. We include some text = about this in the introduction, which is then also referenced from the = text about maximum packet sizes. We can't force applications to avoid = adaptation layer fragmentation, but we can point out that it was a = design requirement. =20 The Block Option discussion we can have separately to this. But as = Carsten pointed out it shouldn't affect this text as you would use a = block size < 1024 bytes anyways.=20 Zach On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote: > Hello, >=20 > I think unfortunately the question of "optimum packet size" will = always be "it depends". I'm assuming in the following you *need* to send = a larger packet for some reason. >=20 > Performing the fragmentation at the 6LoWPAN layer should be the most = efficient, as you don't waste having IP/UDP/CoAP headers on each packet. = This would suggest sending as large an IPv6 packet as possible. Under = reasonable network conditions a 6LoWPAN network can do this pretty = reliably (1280 byte delivery). >=20 > But in a bad RF environment though the lower layers may not deliver = this message as reliably. Normally 802.15.4 will retry sending each = 6LoWPAN fragment three times, after which it gives up. You then need to = resend the entire IPv6 packet until all the fragments get through. As = each time you are sending many (say 10) fragments, this could take a few = tries! This would suggest keeping the IPv6 packet as small as possible, = so each individual IPv6 packet is likely to get through, and when they = fail you aren't resending as much. >=20 > Again I think it comes down to CoAP being a simple protocol. It will = work great for small packets basically no matter what. It should work = pretty well for larger packets too even. But if you want to transfer = lots of data (firmware, etc) it's better to use something designed for = the purpose. >=20 > Another consideration for CoAP data is not just the transfer of it, = but actually buffering the data in memory. I would guess most = constrained (ie: 8-bit processor) devices are designed around having a = 1280 byte IP buffer. The actual resources need to be designed with this = in mind too! >=20 > Regards, >=20 > -Colin >=20 >=20 >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org on behalf of Carsten Bormann > Sent: Mon 05/07/2010 10:29 > To: Guido Moritz > Cc: core > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram) >=20 > On Jul 2, 2010, at 12:37, Guido Moritz wrote: >=20 > > 1280 seems > > to be reasonable as the magic number of 6LoWPAN networks in general = ;) >=20 > Well, 1280 is the magic number of IPv6 MTUs. > 6LoWPAN does support 1280 byte packets, but splitting a packet into 15 = or 20 fragments is expensive in terms of reduced probability of = delivery. >=20 > Worse, Protocols like RPL can steal some of these bytes (and the IP = and UDP headers will, too). > CoAP implementations should be able to operate on any UDP datagram = that fits into the IPv6 MTU. >=20 > But having a good idea of what is actually efficient to use also = helps. > So I would rarely send a CoAP payload of more than 1024 bytes; adding = in CoAP options (the total size of which depends a lot on the length of = the URI), CoAP fixed header (4 bytes), UDP header and IP header then is = likely to leave some room for RPL and other tunnel stunts. > For applications such as firmware transfers on 6LoWPAN, I would stick = with a payload size of 64 (1 fragment) or 128 (two fragments); that's = why coap://ns.tzi.org:61616/ has 128 as the default block size. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Mon Jul 5 04: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 8ACEA3A63EC for ; Mon, 5 Jul 2010 04:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeA-16P7Ilqw for ; Mon, 5 Jul 2010 04:16:38 -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 9663C3A68FB for ; Mon, 5 Jul 2010 04:16:35 -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 o65BFw7t022896; Mon, 5 Jul 2010 13:15:58 +0200 (CEST) Received: from [192.168.217.101] (p5489CBB7.dip.t-dialin.net [84.137.203.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id BDA4FB7BF; Mon, 5 Jul 2010 13:15:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> Date: Mon, 5 Jul 2010 13:15:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: "Oflynn, Colin" , core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 11:16:39 -0000 > 2. Define a fixed octet limit of e.g. 1152. At that point why not just = say 1024 bytes. Because that would mean the biggest CoAP payload that is a power of two = in size would be 512. (Historical anecdote: Why was the IPv6 MTU set at 1280? Because 1500 is = the Ethernet MTU, and 1024 bytes is a useful payload size. Allowing for reasonable headers both internal and external, 1280 =3D = (1024 + (1536-1024)/2) sounded round enough and about right. (1500 is a rather odd number in binary, hence 1536 in the above = formula.)) > block size < 1024 bytes anyways.=20 I'd make that =E2=89=A4 1024 bytes, which makes 1152 as the message an = attractive number: (1024 + (1280-1024)/2). 1024 bytes of payload sounds right for power-line applications. For 6LoWPAN, 64 or 128 may be closer to optimal. BTW, CoAP *is* designed to do large transfers (if you include the block = option). It may not be *fast* (as in saturating the link), because it is = lock-step (until we add TCP-like congestion control as another option). But it is efficient in every other way. (And I wouldn't want to saturate a 6LoWPAN anyway.) Gruesse, Carsten From Colin.OFlynn@atmel.com Mon Jul 5 04:21: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 EC5B03A686B for ; Mon, 5 Jul 2010 04:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, WEIRD_PORT=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 ZUCD12dE1ZLh for ; Mon, 5 Jul 2010 04:21:53 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id CF1C13A67F7 for ; Mon, 5 Jul 2010 04:21:53 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o65BJVqB018895; Mon, 5 Jul 2010 04:19:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1C34.38B62BF4" Date: Mon, 5 Jul 2010 05:21:32 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) Thread-Index: AcscMRlD3kNCaRQYQkStwuu4zyq/vAAAPc7w References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <004a01cb19d2$9c3e5b70$d4bb1250$@moritz@uni-rostock.de> <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> From: "Oflynn, Colin" To: "Zach Shelby" Cc: core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 11:21:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1C34.38B62BF4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zach, >Carsten pointed that we have two options: Both work for me. Using #2 w/ the 1024 option you suggest would leave room for extra IP = header options to be slotted in later. Not sure if that is actually = something we care about to be honest? >We can't force applications to avoid adaptation layer fragmentation, = but we can point out that it was a design requirement.=20 To me sounds like a good idea, other thoughts? I think it's easy for = someone to pick up any spec without having a full appreciation of the = design space. A quick summary of fragmentation problems might help one = understand why the emphasis on small packet sizes is present. Regards, -Colin -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Mon 05/07/2010 11:59 To: Oflynn, Colin Cc: Carsten Bormann; Guido Moritz; core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table, maximum datagram) =20 Colin, You captured the situation perfectly. So now just to get that down in = text for coap-01 - the hard part. Seems I closed that ticket = prematurely. Carsten pointed that we have two options: 1. Define that this must fit in an IPv6 packet with an MTU of 1280 = bytes.=20 or 2. Define a fixed octet limit of e.g. 1152. At that point why not just = say 1024 bytes. Regarding 6LoWPAN how about we do the following. We include some text = about this in the introduction, which is then also referenced from the = text about maximum packet sizes. We can't force applications to avoid = adaptation layer fragmentation, but we can point out that it was a = design requirement. =20 The Block Option discussion we can have separately to this. But as = Carsten pointed out it shouldn't affect this text as you would use a = block size < 1024 bytes anyways.=20 Zach On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote: > Hello, >=20 > I think unfortunately the question of "optimum packet size" will = always be "it depends". I'm assuming in the following you *need* to send = a larger packet for some reason. >=20 > Performing the fragmentation at the 6LoWPAN layer should be the most = efficient, as you don't waste having IP/UDP/CoAP headers on each packet. = This would suggest sending as large an IPv6 packet as possible. Under = reasonable network conditions a 6LoWPAN network can do this pretty = reliably (1280 byte delivery). >=20 > But in a bad RF environment though the lower layers may not deliver = this message as reliably. Normally 802.15.4 will retry sending each = 6LoWPAN fragment three times, after which it gives up. You then need to = resend the entire IPv6 packet until all the fragments get through. As = each time you are sending many (say 10) fragments, this could take a few = tries! This would suggest keeping the IPv6 packet as small as possible, = so each individual IPv6 packet is likely to get through, and when they = fail you aren't resending as much. >=20 > Again I think it comes down to CoAP being a simple protocol. It will = work great for small packets basically no matter what. It should work = pretty well for larger packets too even. But if you want to transfer = lots of data (firmware, etc) it's better to use something designed for = the purpose. >=20 > Another consideration for CoAP data is not just the transfer of it, = but actually buffering the data in memory. I would guess most = constrained (ie: 8-bit processor) devices are designed around having a = 1280 byte IP buffer. The actual resources need to be designed with this = in mind too! >=20 > Regards, >=20 > -Colin >=20 >=20 >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org on behalf of Carsten Bormann > Sent: Mon 05/07/2010 10:29 > To: Guido Moritz > Cc: core > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table,maximum datagram) >=20 > On Jul 2, 2010, at 12:37, Guido Moritz wrote: >=20 > > 1280 seems > > to be reasonable as the magic number of 6LoWPAN networks in general = ;) >=20 > Well, 1280 is the magic number of IPv6 MTUs. > 6LoWPAN does support 1280 byte packets, but splitting a packet into 15 = or 20 fragments is expensive in terms of reduced probability of = delivery. >=20 > Worse, Protocols like RPL can steal some of these bytes (and the IP = and UDP headers will, too). > CoAP implementations should be able to operate on any UDP datagram = that fits into the IPv6 MTU. >=20 > But having a good idea of what is actually efficient to use also = helps. > So I would rarely send a CoAP payload of more than 1024 bytes; adding = in CoAP options (the total size of which depends a lot on the length of = the URI), CoAP fixed header (4 bytes), UDP header and IP header then is = likely to leave some room for RPL and other tunnel stunts. > For applications such as firmware transfers on 6LoWPAN, I would stick = with a payload size of 64 (1 fragment) or 128 (two fragments); that's = why coap://ns.tzi.org:61616/ has 128 as the default block size. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 ------_=_NextPart_001_01CB1C34.38B62BF4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] #15: Consolidate maximum sizes (encodings, options = table, maximum datagram)

Hi Zach,

>Carsten pointed that we have two options:

Both work for me.

Using #2 w/ the 1024 option you suggest would leave room for extra IP = header options to be slotted in later. Not sure if that is actually = something we care about to be honest?

>We can't force applications to avoid adaptation layer fragmentation, = but we can point out that it was a design requirement.

To me sounds like a good idea, other thoughts? I think it's easy for = someone to pick up any spec without having a full appreciation of the = design space. A quick summary of fragmentation problems might help one = understand why the emphasis on small packet sizes is present.

Regards,

  -Colin


-----Original Message-----
From: Zach Shelby [mailto:zach@sensinode.com]
Sent: Mon 05/07/2010 11:59
To: Oflynn, Colin
Cc: Carsten Bormann; Guido Moritz; core
Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table, maximum datagram)

Colin,

You captured the situation perfectly. So now just to get that down in = text for coap-01 - the hard part. Seems I closed that ticket = prematurely.

Carsten pointed that we have two options:

1. Define that this must fit in an IPv6 packet with an MTU of 1280 = bytes.
or
2. Define a fixed octet limit of e.g. 1152. At that point why not just = say 1024 bytes.

Regarding 6LoWPAN how about we do the following. We include some text = about this in the introduction, which is then also referenced from the = text about maximum packet sizes. We can't force applications to avoid = adaptation layer fragmentation, but we can point out that it was a = design requirement. 

The Block Option discussion we can have separately to this. But as = Carsten pointed out it shouldn't affect this text as you would use a = block size < 1024 bytes anyways.

Zach

On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote:

> Hello,
>
> I think unfortunately the question of "optimum packet = size" will always be "it depends". I'm assuming in the = following you *need* to send a larger packet for some reason.
>
> Performing the fragmentation at the 6LoWPAN layer should be the = most efficient, as you don't waste having IP/UDP/CoAP headers on each = packet. This would suggest sending as large an IPv6 packet as possible. = Under reasonable network conditions a 6LoWPAN network can do this pretty = reliably (1280 byte delivery).
>
> But in a bad RF environment though the lower layers may not deliver = this message as reliably. Normally 802.15.4 will retry sending each = 6LoWPAN fragment three times, after which it gives up. You then need to = resend the entire IPv6 packet until all the fragments get through. As = each time you are sending many (say 10) fragments, this could take a few = tries! This would suggest keeping the IPv6 packet as small as possible, = so each individual IPv6 packet is likely to get through, and when they = fail you aren't resending as much.
>
> Again I think it comes down to CoAP being a simple protocol. It = will work great for small packets basically no matter what. It should = work pretty well for larger packets too even. But if you want to = transfer lots of data (firmware, etc) it's better to use something = designed for the purpose.
>
> Another consideration for CoAP data is not just the transfer of it, = but actually buffering the data in memory. I would guess most = constrained (ie: 8-bit processor) devices are designed around having a = 1280 byte IP buffer. The actual resources need to be designed with this = in mind too!
>
> Regards,
>
>    -Colin
>
>
>
>
> -----Original Message-----
> From: core-bounces@ietf.org on behalf of Carsten Bormann
> Sent: Mon 05/07/2010 10:29
> To: Guido Moritz
> Cc: core
> Subject: Re: [core] #15: Consolidate maximum sizes (encodings, = options table,maximum datagram)
>
> On Jul 2, 2010, at 12:37, Guido Moritz wrote:
>
> > 1280 seems
> > to be reasonable as the magic number of 6LoWPAN networks in = general ;)
>
> Well, 1280 is the magic number of IPv6 MTUs.
> 6LoWPAN does support 1280 byte packets, but splitting a packet into = 15 or 20 fragments is expensive in terms of reduced probability of = delivery.
>
> Worse, Protocols like RPL can steal some of these bytes (and the IP = and UDP headers will, too).
> CoAP implementations should be able to operate on any UDP datagram = that fits into the IPv6 MTU.
>
> But having a good idea of what is actually efficient to use also = helps.
> So I would rarely send a CoAP payload of more than 1024 bytes; = adding in CoAP options (the total size of which depends a lot on the = length of the URI), CoAP fixed header (4 bytes), UDP header and IP = header then is likely to leave some room for RPL and other tunnel = stunts.
> For applications such as firmware transfers on 6LoWPAN, I would = stick with a payload size of 64 (1 fragment) or 128 (two fragments); = that's why coap://ns.tzi.org:61616/ has 128 as the default block = size.
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core

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

------_=_NextPart_001_01CB1C34.38B62BF4-- From trac@tools.ietf.org Mon Jul 5 06:16: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 655733A698D for ; Mon, 5 Jul 2010 06:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 IFPPPECA3muS for ; Mon, 5 Jul 2010 06:16:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9C2943A68F3 for ; Mon, 5 Jul 2010 06:16:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OVlWv-0004Lv-Uu; Mon, 05 Jul 2010 06:16:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 05 Jul 2010 13:16:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/11#comment:1 Message-ID: <066.68f93549cbbbad866f69af60013d84cf@tools.ietf.org> References: <057.6a78f44a17984067e2625df14b0e601d@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <057.6a78f44a17984067e2625df14b0e601d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #11: Finish Examples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 13:16:14 -0000 #11: Finish Examples --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Comment(by zach@…): Added 3 more exampels to coap-01. -- Ticket URL: core From pab@peoplepowerco.com Mon Jul 5 06:17: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 90A743A6988 for ; Mon, 5 Jul 2010 06:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, WEIRD_PORT=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 i2j7zHDRS1md for ; Mon, 5 Jul 2010 06:17:07 -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 6FC7F3A68F3 for ; Mon, 5 Jul 2010 06:17:07 -0700 (PDT) Received: by vws14 with SMTP id 14so4551626vws.31 for ; Mon, 05 Jul 2010 06:17:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.196 with SMTP id l4mr1541243vcs.174.1278335823620; Mon, 05 Jul 2010 06:17:03 -0700 (PDT) Received: by 10.220.105.137 with HTTP; Mon, 5 Jul 2010 06:17:03 -0700 (PDT) In-Reply-To: <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> Date: Mon, 5 Jul 2010 08:17:03 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=e0cb4e88794dabacc1048aa3c061 Cc: "Oflynn, Colin" , core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 13:17:09 -0000 --e0cb4e88794dabacc1048aa3c061 Content-Type: text/plain; charset=ISO-8859-1 > > Seems I closed that ticket prematurely. > Too bad; I was all set to +1 the proposed wording. I understand the desire to define a small fixed limit so people don't forget that "constrained" is significant and try to use CoAP to stream HD video. But I can't see a rationale for any numeric limit that doesn't end up unnecessarily coupling CoAP to a specific technology. If I have a whole infrastructure set up with CoAP, I might really like to be able to re-use it on a network where the MTU is, say, 2048 bytes. I'd be kinda upset if I had to replace the entire system because the specification included arbitrary assumptions about maximum packet size. Fragmentation is hard, so I think CoAP should make it somebody else's problem. What's wrong with referring to the MTU of the underlying transport protocol (as long as "MTU" is defined)? I might even have a system where, for technical reasons (e.g., the devices have only 512B of RAM) the MTU isn't as large as IPv6 requires. I ought to be able to use CoAP in that system. In any closed system designers will be able to determine the appropriate MTU. For open systems with unmanaged clients, well, degradation due to loss of network or link-layer fragments is a risk in any communication path. At least if clients are using IPv6 there's infrastructure to determine the end-to-end MTU limits, and adjust the application messages accordingly. I agree with Colin that an introductory section on packet sizes, fragmentation, and their effects on CoAP architecture and use would help avoid problems with folks not familiar with the constrained domain. Peter On Mon, Jul 5, 2010 at 5:59 AM, Zach Shelby wrote: > Colin, > > You captured the situation perfectly. So now just to get that down in text > for coap-01 - the hard part. Seems I closed that ticket prematurely. > > Carsten pointed that we have two options: > > 1. Define that this must fit in an IPv6 packet with an MTU of 1280 bytes. > or > 2. Define a fixed octet limit of e.g. 1152. At that point why not just say > 1024 bytes. > > Regarding 6LoWPAN how about we do the following. We include some text about > this in the introduction, which is then also referenced from the text about > maximum packet sizes. We can't force applications to avoid adaptation layer > fragmentation, but we can point out that it was a design requirement. > > The Block Option discussion we can have separately to this. But as Carsten > pointed out it shouldn't affect this text as you would use a block size < > 1024 bytes anyways. > > Zach > > On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote: > > > Hello, > > > > I think unfortunately the question of "optimum packet size" will always > be "it depends". I'm assuming in the following you *need* to send a larger > packet for some reason. > > > > Performing the fragmentation at the 6LoWPAN layer should be the most > efficient, as you don't waste having IP/UDP/CoAP headers on each packet. > This would suggest sending as large an IPv6 packet as possible. Under > reasonable network conditions a 6LoWPAN network can do this pretty reliably > (1280 byte delivery). > > > > But in a bad RF environment though the lower layers may not deliver this > message as reliably. Normally 802.15.4 will retry sending each 6LoWPAN > fragment three times, after which it gives up. You then need to resend the > entire IPv6 packet until all the fragments get through. As each time you are > sending many (say 10) fragments, this could take a few tries! This would > suggest keeping the IPv6 packet as small as possible, so each individual > IPv6 packet is likely to get through, and when they fail you aren't > resending as much. > > > > Again I think it comes down to CoAP being a simple protocol. It will work > great for small packets basically no matter what. It should work pretty well > for larger packets too even. But if you want to transfer lots of data > (firmware, etc) it's better to use something designed for the purpose. > > > > Another consideration for CoAP data is not just the transfer of it, but > actually buffering the data in memory. I would guess most constrained (ie: > 8-bit processor) devices are designed around having a 1280 byte IP buffer. > The actual resources need to be designed with this in mind too! > > > > Regards, > > > > -Colin > > > > > > > > > > -----Original Message----- > > From: core-bounces@ietf.org on behalf of Carsten Bormann > > Sent: Mon 05/07/2010 10:29 > > To: Guido Moritz > > Cc: core > > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options > table,maximum datagram) > > > > On Jul 2, 2010, at 12:37, Guido Moritz wrote: > > > > > 1280 seems > > > to be reasonable as the magic number of 6LoWPAN networks in general ;) > > > > Well, 1280 is the magic number of IPv6 MTUs. > > 6LoWPAN does support 1280 byte packets, but splitting a packet into 15 or > 20 fragments is expensive in terms of reduced probability of delivery. > > > > Worse, Protocols like RPL can steal some of these bytes (and the IP and > UDP headers will, too). > > CoAP implementations should be able to operate on any UDP datagram that > fits into the IPv6 MTU. > > > > But having a good idea of what is actually efficient to use also helps. > > So I would rarely send a CoAP payload of more than 1024 bytes; adding in > CoAP options (the total size of which depends a lot on the length of the > URI), CoAP fixed header (4 bytes), UDP header and IP header then is likely > to leave some room for RPL and other tunnel stunts. > > For applications such as firmware transfers on 6LoWPAN, I would stick > with a payload size of 64 (1 fragment) or 128 (two fragments); that's why > coap://ns.tzi.org:61616/ has 128 as the default block size. > > > > Gruesse, Carsten > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --e0cb4e88794dabacc1048aa3c061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Seems I closed th= at ticket prematurely.

Too bad; I was all set to += 1 the proposed wording.

I understand the desire to define a small fixed limit so people don'= ;t forget that "constrained" is significant and try to use CoAP t= o stream HD video.=A0 But I can't see a rationale for any numeric limit= that doesn't end up unnecessarily coupling CoAP to a specific technolo= gy.=A0 If I have a whole infrastructure set up with CoAP, I might really li= ke to be able to re-use it on a network where the MTU is, say, 2048 bytes.= =A0 I'd be kinda upset if I had to replace the entire system because th= e specification included arbitrary assumptions about maximum packet size.
Fragmentation is hard, so I think CoAP should make it somebody else'= ;s problem.=A0 What's wrong with referring to the MTU of the underlying= transport protocol (as long as "MTU" is defined)?=A0 I might eve= n have a system where, for technical reasons (e.g., the devices have only 5= 12B of RAM) the MTU isn't as large as IPv6 requires.=A0 I ought to be a= ble to use CoAP in that system.

In any closed system designers will be able to determine the appropriat= e MTU.=A0 For open systems with unmanaged clients, well, degradation due to= loss of network or link-layer fragments is a risk in any communication pat= h.=A0 At least if clients are using IPv6 there's infrastructure to dete= rmine the=20 end-to-end MTU limits, and adjust the application messages accordingly.
=
I agree with Colin that an introductory section on packet sizes, fragme= ntation, and their effects on CoAP architecture and use would help avoid pr= oblems with folks not familiar with the constrained domain.

Peter

On Mon, Jul 5, 2010 at 5:= 59 AM, Zach Shelby <zach@sensinode.com> wrote:
Colin,

You captured the situation perfectly. So now just to get that down in text = for coap-01 - the hard part. Seems I closed that ticket prematurely.

Carsten pointed that we have two options:

1. Define that this must fit in an IPv6 packet with an MTU of 1280 bytes. or
2. Define a fixed octet limit of e.g. 1152. At that point why not just say = 1024 bytes.

Regarding 6LoWPAN how about we do the following. We include some text about= this in the introduction, which is then also referenced from the text abou= t maximum packet sizes. We can't force applications to avoid adaptation= layer fragmentation, but we can point out that it was a design requirement= .

The Block Option discussion we can have separately to this. But as Carsten = pointed out it shouldn't affect this text as you would use a block size= < 1024 bytes anyways.

Zach

On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote:

> Hello,
>
> I think unfortunately the question of "optimum packet size" = will always be "it depends". I'm assuming in the following yo= u *need* to send a larger packet for some reason.
>
> Performing the fragmentation at the 6LoWPAN layer should be the most e= fficient, as you don't waste having IP/UDP/CoAP headers on each packet.= This would suggest sending as large an IPv6 packet as possible. Under reas= onable network conditions a 6LoWPAN network can do this pretty reliably (12= 80 byte delivery).
>
> But in a bad RF environment though the lower layers may not deliver th= is message as reliably. Normally 802.15.4 will retry sending each 6LoWPAN f= ragment three times, after which it gives up. You then need to resend the e= ntire IPv6 packet until all the fragments get through. As each time you are= sending many (say 10) fragments, this could take a few tries! This would s= uggest keeping the IPv6 packet as small as possible, so each individual IPv= 6 packet is likely to get through, and when they fail you aren't resend= ing as much.
>
> Again I think it comes down to CoAP being a simple protocol. It will w= ork great for small packets basically no matter what. It should work pretty= well for larger packets too even. But if you want to transfer lots of data= (firmware, etc) it's better to use something designed for the purpose.=
>
> Another consideration for CoAP data is not just the transfer of it, bu= t actually buffering the data in memory. I would guess most constrained (ie= : 8-bit processor) devices are designed around having a 1280 byte IP buffer= . The actual resources need to be designed with this in mind too!
>
> Regards,
>
> =A0 =A0-Colin
>
>
>
>
> -----Original Message-----
> From: core-bounces@ietf.org on behalf of Carsten Bormann
> Sent: Mon 05/07/2010 10:29
> To: Guido Moritz
> Cc: core
> Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options= table,maximum datagram)
>
> On Jul 2, 2010, at 12:37, Guido Moritz wrote:
>
> > 1280 seems
> > to be reasonable as the magic number of 6LoWPAN networks in gener= al ;)
>
> Well, 1280 is the magic number of IPv6 MTUs.
> 6LoWPAN does support 1280 byte packets, but splitting a packet into 15= or 20 fragments is expensive in terms of reduced probability of delivery.<= br> >
> Worse, Protocols like RPL can steal some of these bytes (and the IP an= d UDP headers will, too).
> CoAP implementations should be able to operate on any UDP datagram tha= t fits into the IPv6 MTU.
>
> But having a good idea of what is actually efficient to use also helps= .
> So I would rarely send a CoAP payload of more than 1024 bytes; adding = in CoAP options (the total size of which depends a lot on the length of the= URI), CoAP fixed header (4 bytes), UDP header and IP header then is likely= to leave some room for RPL and other tunnel stunts.
> For applications such as firmware transfers on 6LoWPAN, I would stick = with a payload size of 64 (1 fragment) or 128 (two fragments); that's w= hy coap://ns.tzi.org= :61616/ has 128 as the default block size.
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

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

_______________________________________________

--e0cb4e88794dabacc1048aa3c061-- From zach@sensinode.com Tue Jul 6 05:45:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B9A3A6863 for ; Tue, 6 Jul 2010 05:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 8rlKmcTzWT05 for ; Tue, 6 Jul 2010 05:45:56 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 859913A6864 for ; Tue, 6 Jul 2010 05:45:55 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o66CjnwN011904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Jul 2010 15:45:49 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Tue, 6 Jul 2010 15:45:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6C4B7998-CFC0-455E-8DCD-EEEBB236D2BE@sensinode.com> References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: "Oflynn, Colin" , core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 12:45:58 -0000 I understand both arguments there. I added introduction text about = adaptation layer fragmentation, and referenced that. Now this gives you = the obvious hard upper bound as this is UDP, plus lets you use a Path = MTU if you know it. I propose this text: The length of the Payload in a CoAP message is calculated from the datagram length. While specific link layers make it beneficial to keep CoAP messages small enough to fit into their link layer packets (see Section 1), this is a matter of implementation quality. The CoAP specification itself provides only an upper bound to the message size. A CoAP message SHOULD fit within a single IP packet and MUST fit within a single IP datagram. If the Path MTU is not known for a destination, an MTU of 1280 octets SHOULD be assumed. On Jul 5, 2010, at 4:17 PM, Peter Bigot wrote: > Seems I closed that ticket prematurely. >=20 > Too bad; I was all set to +1 the proposed wording. >=20 > I understand the desire to define a small fixed limit so people don't = forget that "constrained" is significant and try to use CoAP to stream = HD video. But I can't see a rationale for any numeric limit that = doesn't end up unnecessarily coupling CoAP to a specific technology. If = I have a whole infrastructure set up with CoAP, I might really like to = be able to re-use it on a network where the MTU is, say, 2048 bytes. = I'd be kinda upset if I had to replace the entire system because the = specification included arbitrary assumptions about maximum packet size. >=20 > Fragmentation is hard, so I think CoAP should make it somebody else's = problem. What's wrong with referring to the MTU of the underlying = transport protocol (as long as "MTU" is defined)? I might even have a = system where, for technical reasons (e.g., the devices have only 512B of = RAM) the MTU isn't as large as IPv6 requires. I ought to be able to use = CoAP in that system. >=20 > In any closed system designers will be able to determine the = appropriate MTU. For open systems with unmanaged clients, well, = degradation due to loss of network or link-layer fragments is a risk in = any communication path. At least if clients are using IPv6 there's = infrastructure to determine the end-to-end MTU limits, and adjust the = application messages accordingly. >=20 > I agree with Colin that an introductory section on packet sizes, = fragmentation, and their effects on CoAP architecture and use would help = avoid problems with folks not familiar with the constrained domain. >=20 > Peter >=20 > On Mon, Jul 5, 2010 at 5:59 AM, Zach Shelby = wrote: > Colin, >=20 > You captured the situation perfectly. So now just to get that down in = text for coap-01 - the hard part. Seems I closed that ticket = prematurely. >=20 > Carsten pointed that we have two options: >=20 > 1. Define that this must fit in an IPv6 packet with an MTU of 1280 = bytes. > or > 2. Define a fixed octet limit of e.g. 1152. At that point why not just = say 1024 bytes. >=20 > Regarding 6LoWPAN how about we do the following. We include some text = about this in the introduction, which is then also referenced from the = text about maximum packet sizes. We can't force applications to avoid = adaptation layer fragmentation, but we can point out that it was a = design requirement. >=20 > The Block Option discussion we can have separately to this. But as = Carsten pointed out it shouldn't affect this text as you would use a = block size < 1024 bytes anyways. >=20 > Zach >=20 > On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote: >=20 > > Hello, > > > > I think unfortunately the question of "optimum packet size" will = always be "it depends". I'm assuming in the following you *need* to send = a larger packet for some reason. > > > > Performing the fragmentation at the 6LoWPAN layer should be the most = efficient, as you don't waste having IP/UDP/CoAP headers on each packet. = This would suggest sending as large an IPv6 packet as possible. Under = reasonable network conditions a 6LoWPAN network can do this pretty = reliably (1280 byte delivery). > > > > But in a bad RF environment though the lower layers may not deliver = this message as reliably. Normally 802.15.4 will retry sending each = 6LoWPAN fragment three times, after which it gives up. You then need to = resend the entire IPv6 packet until all the fragments get through. As = each time you are sending many (say 10) fragments, this could take a few = tries! This would suggest keeping the IPv6 packet as small as possible, = so each individual IPv6 packet is likely to get through, and when they = fail you aren't resending as much. > > > > Again I think it comes down to CoAP being a simple protocol. It will = work great for small packets basically no matter what. It should work = pretty well for larger packets too even. But if you want to transfer = lots of data (firmware, etc) it's better to use something designed for = the purpose. > > > > Another consideration for CoAP data is not just the transfer of it, = but actually buffering the data in memory. I would guess most = constrained (ie: 8-bit processor) devices are designed around having a = 1280 byte IP buffer. The actual resources need to be designed with this = in mind too! > > > > Regards, > > > > -Colin > > > > > > > > > > -----Original Message----- > > From: core-bounces@ietf.org on behalf of Carsten Bormann > > Sent: Mon 05/07/2010 10:29 > > To: Guido Moritz > > Cc: core > > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, = options table,maximum datagram) > > > > On Jul 2, 2010, at 12:37, Guido Moritz wrote: > > > > > 1280 seems > > > to be reasonable as the magic number of 6LoWPAN networks in = general ;) > > > > Well, 1280 is the magic number of IPv6 MTUs. > > 6LoWPAN does support 1280 byte packets, but splitting a packet into = 15 or 20 fragments is expensive in terms of reduced probability of = delivery. > > > > Worse, Protocols like RPL can steal some of these bytes (and the IP = and UDP headers will, too). > > CoAP implementations should be able to operate on any UDP datagram = that fits into the IPv6 MTU. > > > > But having a good idea of what is actually efficient to use also = helps. > > So I would rarely send a CoAP payload of more than 1024 bytes; = adding in CoAP options (the total size of which depends a lot on the = length of the URI), CoAP fixed header (4 bytes), UDP header and IP = header then is likely to leave some room for RPL and other tunnel = stunts. > > For applications such as firmware transfers on 6LoWPAN, I would = stick with a payload size of 64 (1 fragment) or 128 (two fragments); = that's why coap://ns.tzi.org:61616/ has 128 as the default block size. > > > > Gruesse, Carsten > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From Colin.OFlynn@atmel.com Tue Jul 6 05:51: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 422BB3A6887 for ; Tue, 6 Jul 2010 05:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, WEIRD_PORT=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 HHFINVQh4vl4 for ; Tue, 6 Jul 2010 05:51:41 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 7773D3A6864 for ; Tue, 6 Jul 2010 05:51:41 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o66CnPjX003816; Tue, 6 Jul 2010 05:49:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1D09.F31A2B90" Date: Tue, 6 Jul 2010 06:46:53 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) Thread-Index: AcsdCS5iJNkHFwm0S3OqIKqlBBBiTAAACDrm References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> <6C4B7998-CFC0-455E-8DCD-EEEBB236D2BE@sensinode.com> From: "Oflynn, Colin" To: "Zach Shelby" , "Peter Bigot" Cc: core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 12:51:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1D09.F31A2B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zach, This looks really good to me. Specifying path MTU closes my concern = about 'which MTU will people use', and the paragraph is strongly worded = enough to get the idea across of e.g.: don't send big packets unless you = know what you are doing! Thanks, -Colin -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Tue 06/07/2010 13:45 To: Peter Bigot Cc: Oflynn, Colin; core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table, maximum datagram) =20 I understand both arguments there. I added introduction text about = adaptation layer fragmentation, and referenced that. Now this gives you = the obvious hard upper bound as this is UDP, plus lets you use a Path = MTU if you know it. I propose this text: The length of the Payload in a CoAP message is calculated from the datagram length. While specific link layers make it beneficial to keep CoAP messages small enough to fit into their link layer packets (see Section 1), this is a matter of implementation quality. The CoAP specification itself provides only an upper bound to the message size. A CoAP message SHOULD fit within a single IP packet and MUST fit within a single IP datagram. If the Path MTU is not known for a destination, an MTU of 1280 octets SHOULD be assumed. On Jul 5, 2010, at 4:17 PM, Peter Bigot wrote: > Seems I closed that ticket prematurely. >=20 > Too bad; I was all set to +1 the proposed wording. >=20 > I understand the desire to define a small fixed limit so people don't = forget that "constrained" is significant and try to use CoAP to stream = HD video. But I can't see a rationale for any numeric limit that = doesn't end up unnecessarily coupling CoAP to a specific technology. If = I have a whole infrastructure set up with CoAP, I might really like to = be able to re-use it on a network where the MTU is, say, 2048 bytes. = I'd be kinda upset if I had to replace the entire system because the = specification included arbitrary assumptions about maximum packet size. >=20 > Fragmentation is hard, so I think CoAP should make it somebody else's = problem. What's wrong with referring to the MTU of the underlying = transport protocol (as long as "MTU" is defined)? I might even have a = system where, for technical reasons (e.g., the devices have only 512B of = RAM) the MTU isn't as large as IPv6 requires. I ought to be able to use = CoAP in that system. >=20 > In any closed system designers will be able to determine the = appropriate MTU. For open systems with unmanaged clients, well, = degradation due to loss of network or link-layer fragments is a risk in = any communication path. At least if clients are using IPv6 there's = infrastructure to determine the end-to-end MTU limits, and adjust the = application messages accordingly. >=20 > I agree with Colin that an introductory section on packet sizes, = fragmentation, and their effects on CoAP architecture and use would help = avoid problems with folks not familiar with the constrained domain. >=20 > Peter >=20 > On Mon, Jul 5, 2010 at 5:59 AM, Zach Shelby = wrote: > Colin, >=20 > You captured the situation perfectly. So now just to get that down in = text for coap-01 - the hard part. Seems I closed that ticket = prematurely. >=20 > Carsten pointed that we have two options: >=20 > 1. Define that this must fit in an IPv6 packet with an MTU of 1280 = bytes. > or > 2. Define a fixed octet limit of e.g. 1152. At that point why not just = say 1024 bytes. >=20 > Regarding 6LoWPAN how about we do the following. We include some text = about this in the introduction, which is then also referenced from the = text about maximum packet sizes. We can't force applications to avoid = adaptation layer fragmentation, but we can point out that it was a = design requirement. >=20 > The Block Option discussion we can have separately to this. But as = Carsten pointed out it shouldn't affect this text as you would use a = block size < 1024 bytes anyways. >=20 > Zach >=20 > On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote: >=20 > > Hello, > > > > I think unfortunately the question of "optimum packet size" will = always be "it depends". I'm assuming in the following you *need* to send = a larger packet for some reason. > > > > Performing the fragmentation at the 6LoWPAN layer should be the most = efficient, as you don't waste having IP/UDP/CoAP headers on each packet. = This would suggest sending as large an IPv6 packet as possible. Under = reasonable network conditions a 6LoWPAN network can do this pretty = reliably (1280 byte delivery). > > > > But in a bad RF environment though the lower layers may not deliver = this message as reliably. Normally 802.15.4 will retry sending each = 6LoWPAN fragment three times, after which it gives up. You then need to = resend the entire IPv6 packet until all the fragments get through. As = each time you are sending many (say 10) fragments, this could take a few = tries! This would suggest keeping the IPv6 packet as small as possible, = so each individual IPv6 packet is likely to get through, and when they = fail you aren't resending as much. > > > > Again I think it comes down to CoAP being a simple protocol. It will = work great for small packets basically no matter what. It should work = pretty well for larger packets too even. But if you want to transfer = lots of data (firmware, etc) it's better to use something designed for = the purpose. > > > > Another consideration for CoAP data is not just the transfer of it, = but actually buffering the data in memory. I would guess most = constrained (ie: 8-bit processor) devices are designed around having a = 1280 byte IP buffer. The actual resources need to be designed with this = in mind too! > > > > Regards, > > > > -Colin > > > > > > > > > > -----Original Message----- > > From: core-bounces@ietf.org on behalf of Carsten Bormann > > Sent: Mon 05/07/2010 10:29 > > To: Guido Moritz > > Cc: core > > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, = options table,maximum datagram) > > > > On Jul 2, 2010, at 12:37, Guido Moritz wrote: > > > > > 1280 seems > > > to be reasonable as the magic number of 6LoWPAN networks in = general ;) > > > > Well, 1280 is the magic number of IPv6 MTUs. > > 6LoWPAN does support 1280 byte packets, but splitting a packet into = 15 or 20 fragments is expensive in terms of reduced probability of = delivery. > > > > Worse, Protocols like RPL can steal some of these bytes (and the IP = and UDP headers will, too). > > CoAP implementations should be able to operate on any UDP datagram = that fits into the IPv6 MTU. > > > > But having a good idea of what is actually efficient to use also = helps. > > So I would rarely send a CoAP payload of more than 1024 bytes; = adding in CoAP options (the total size of which depends a lot on the = length of the URI), CoAP fixed header (4 bytes), UDP header and IP = header then is likely to leave some room for RPL and other tunnel = stunts. > > For applications such as firmware transfers on 6LoWPAN, I would = stick with a payload size of 64 (1 fragment) or 128 (two fragments); = that's why coap://ns.tzi.org:61616/ has 128 as the default block size. > > > > Gruesse, Carsten > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 ------_=_NextPart_001_01CB1D09.F31A2B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] #15: Consolidate maximum sizes (encodings, options = table, maximum datagram)

Hi Zach,

This looks really good to me. Specifying path MTU closes my concern = about 'which MTU will people use', and the paragraph is strongly worded = enough to get the idea across of e.g.: don't send big packets unless you = know what you are doing!

Thanks,

  -Colin


-----Original Message-----
From: Zach Shelby [mailto:zach@sensinode.com]
Sent: Tue 06/07/2010 13:45
To: Peter Bigot
Cc: Oflynn, Colin; core
Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options = table,  maximum datagram)

I understand both arguments there. I added introduction text about = adaptation layer fragmentation, and referenced that. Now this gives you = the obvious hard upper bound as this is UDP, plus lets you use a Path = MTU if you know it. I propose this text:

   The length of the Payload in a CoAP message is calculated = from the
   datagram length.  While specific link layers make it = beneficial to
   keep CoAP messages small enough to fit into their link = layer packets
   (see Section 1), this is a matter of implementation = quality.  The
   CoAP specification itself provides only an upper bound to = the message
   size.  A CoAP message SHOULD fit within a single IP = packet and MUST
   fit within a single IP datagram.  If the Path MTU is = not known for a
   destination, an MTU of 1280 octets SHOULD be assumed.

On Jul 5, 2010, at 4:17 PM, Peter Bigot wrote:

> Seems I closed that ticket prematurely.
>
> Too bad; I was all set to +1 the proposed wording.
>
> I understand the desire to define a small fixed limit so people = don't forget that "constrained" is significant and try to use = CoAP to stream HD video.  But I can't see a rationale for any = numeric limit that doesn't end up unnecessarily coupling CoAP to a = specific technology.  If I have a whole infrastructure set up with = CoAP, I might really like to be able to re-use it on a network where the = MTU is, say, 2048 bytes.  I'd be kinda upset if I had to replace = the entire system because the specification included arbitrary = assumptions about maximum packet size.
>
> Fragmentation is hard, so I think CoAP should make it somebody = else's problem.  What's wrong with referring to the MTU of the = underlying transport protocol (as long as "MTU" is = defined)?  I might even have a system where, for technical reasons = (e.g., the devices have only 512B of RAM) the MTU isn't as large as IPv6 = requires.  I ought to be able to use CoAP in that system.
>
> In any closed system designers will be able to determine the = appropriate MTU.  For open systems with unmanaged clients, well, = degradation due to loss of network or link-layer fragments is a risk in = any communication path.  At least if clients are using IPv6 there's = infrastructure to determine the end-to-end MTU limits, and adjust the = application messages accordingly.
>
> I agree with Colin that an introductory section on packet sizes, = fragmentation, and their effects on CoAP architecture and use would help = avoid problems with folks not familiar with the constrained domain.
>
> Peter
>
> On Mon, Jul 5, 2010 at 5:59 AM, Zach Shelby = <zach@sensinode.com> wrote:
> Colin,
>
> You captured the situation perfectly. So now just to get that down = in text for coap-01 - the hard part. Seems I closed that ticket = prematurely.
>
> Carsten pointed that we have two options:
>
> 1. Define that this must fit in an IPv6 packet with an MTU of 1280 = bytes.
> or
> 2. Define a fixed octet limit of e.g. 1152. At that point why not = just say 1024 bytes.
>
> Regarding 6LoWPAN how about we do the following. We include some = text about this in the introduction, which is then also referenced from = the text about maximum packet sizes. We can't force applications to = avoid adaptation layer fragmentation, but we can point out that it was a = design requirement.
>
> The Block Option discussion we can have separately to this. But as = Carsten pointed out it shouldn't affect this text as you would use a = block size < 1024 bytes anyways.
>
> Zach
>
> On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote:
>
> > Hello,
> >
> > I think unfortunately the question of "optimum packet = size" will always be "it depends". I'm assuming in the = following you *need* to send a larger packet for some reason.
> >
> > Performing the fragmentation at the 6LoWPAN layer should be = the most efficient, as you don't waste having IP/UDP/CoAP headers on = each packet. This would suggest sending as large an IPv6 packet as = possible. Under reasonable network conditions a 6LoWPAN network can do = this pretty reliably (1280 byte delivery).
> >
> > But in a bad RF environment though the lower layers may not = deliver this message as reliably. Normally 802.15.4 will retry sending = each 6LoWPAN fragment three times, after which it gives up. You then = need to resend the entire IPv6 packet until all the fragments get = through. As each time you are sending many (say 10) fragments, this = could take a few tries! This would suggest keeping the IPv6 packet as = small as possible, so each individual IPv6 packet is likely to get = through, and when they fail you aren't resending as much.
> >
> > Again I think it comes down to CoAP being a simple protocol. = It will work great for small packets basically no matter what. It should = work pretty well for larger packets too even. But if you want to = transfer lots of data (firmware, etc) it's better to use something = designed for the purpose.
> >
> > Another consideration for CoAP data is not just the transfer = of it, but actually buffering the data in memory. I would guess most = constrained (ie: 8-bit processor) devices are designed around having a = 1280 byte IP buffer. The actual resources need to be designed with this = in mind too!
> >
> > Regards,
> >
> >    -Colin
> >
> >
> >
> >
> > -----Original Message-----
> > From: core-bounces@ietf.org on behalf of Carsten Bormann
> > Sent: Mon 05/07/2010 10:29
> > To: Guido Moritz
> > Cc: core
> > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, = options table,maximum datagram)
> >
> > On Jul 2, 2010, at 12:37, Guido Moritz wrote:
> >
> > > 1280 seems
> > > to be reasonable as the magic number of 6LoWPAN networks = in general ;)
> >
> > Well, 1280 is the magic number of IPv6 MTUs.
> > 6LoWPAN does support 1280 byte packets, but splitting a packet = into 15 or 20 fragments is expensive in terms of reduced probability of = delivery.
> >
> > Worse, Protocols like RPL can steal some of these bytes (and = the IP and UDP headers will, too).
> > CoAP implementations should be able to operate on any UDP = datagram that fits into the IPv6 MTU.
> >
> > But having a good idea of what is actually efficient to use = also helps.
> > So I would rarely send a CoAP payload of more than 1024 bytes; = adding in CoAP options (the total size of which depends a lot on the = length of the URI), CoAP fixed header (4 bytes), UDP header and IP = header then is likely to leave some room for RPL and other tunnel = stunts.
> > For applications such as firmware transfers on 6LoWPAN, I = would stick with a payload size of 64 (1 fragment) or 128 (two = fragments); that's why coap://ns.tzi.org:61616/ has 128 as the default = block size.
> >
> > Gruesse, Carsten
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/= mailman/listinfo/core
> >
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/= mailman/listinfo/core
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - = My blog "On the Internet of Things"
> http://6lowpan.net - My book = "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core
>

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

------_=_NextPart_001_01CB1D09.F31A2B90-- From pab@peoplepowerco.com Tue Jul 6 05:53: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 5788F3A6864 for ; Tue, 6 Jul 2010 05:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, WEIRD_PORT=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 f6Uealhtq5Ao for ; Tue, 6 Jul 2010 05:53:01 -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 834893A6900 for ; Tue, 6 Jul 2010 05:53:00 -0700 (PDT) Received: by vws14 with SMTP id 14so6020531vws.31 for ; Tue, 06 Jul 2010 05:52:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.72 with SMTP id w8mr2453387vch.60.1278420778646; Tue, 06 Jul 2010 05:52:58 -0700 (PDT) Received: by 10.220.105.137 with HTTP; Tue, 6 Jul 2010 05:52:58 -0700 (PDT) In-Reply-To: References: <053.a0ff3d5e9c6477f269450091f9012627@tools.ietf.org> <062.9e94455b9b92598d26a57d43623ace79@tools.ietf.org> <84EA4DD9-77FB-4587-844C-38441C5C0D37@sensinode.com> <6C4B7998-CFC0-455E-8DCD-EEEBB236D2BE@sensinode.com> Date: Tue, 6 Jul 2010 07:52:58 -0500 Message-ID: From: Peter Bigot To: "Oflynn, Colin" Content-Type: multipart/alternative; boundary=e0cb4e887811627cb3048ab7886c Cc: core Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options table, maximum datagram) 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 Jul 2010 12:53:03 -0000 --e0cb4e887811627cb3048ab7886c Content-Type: text/plain; charset=ISO-8859-1 Yes, thank you. Peter On Tue, Jul 6, 2010 at 7:46 AM, Oflynn, Colin wrote: > Hi Zach, > > This looks really good to me. Specifying path MTU closes my concern about > 'which MTU will people use', and the paragraph is strongly worded enough to > get the idea across of e.g.: don't send big packets unless you know what you > are doing! > > Thanks, > > > -Colin > > > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com ] > Sent: Tue 06/07/2010 13:45 > To: Peter Bigot > Cc: Oflynn, Colin; core > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options > table, maximum datagram) > > I understand both arguments there. I added introduction text about > adaptation layer fragmentation, and referenced that. Now this gives you the > obvious hard upper bound as this is UDP, plus lets you use a Path MTU if you > know it. I propose this text: > > The length of the Payload in a CoAP message is calculated from the > datagram length. While specific link layers make it beneficial to > keep CoAP messages small enough to fit into their link layer packets > (see Section 1), this is a matter of implementation quality. The > CoAP specification itself provides only an upper bound to the message > size. A CoAP message SHOULD fit within a single IP packet and MUST > fit within a single IP datagram. If the Path MTU is not known for a > destination, an MTU of 1280 octets SHOULD be assumed. > > On Jul 5, 2010, at 4:17 PM, Peter Bigot wrote: > > > Seems I closed that ticket prematurely. > > > > Too bad; I was all set to +1 the proposed wording. > > > > I understand the desire to define a small fixed limit so people don't > forget that "constrained" is significant and try to use CoAP to stream HD > video. But I can't see a rationale for any numeric limit that doesn't end > up unnecessarily coupling CoAP to a specific technology. If I have a whole > infrastructure set up with CoAP, I might really like to be able to re-use it > on a network where the MTU is, say, 2048 bytes. I'd be kinda upset if I had > to replace the entire system because the specification included arbitrary > assumptions about maximum packet size. > > > > Fragmentation is hard, so I think CoAP should make it somebody else's > problem. What's wrong with referring to the MTU of the underlying transport > protocol (as long as "MTU" is defined)? I might even have a system where, > for technical reasons (e.g., the devices have only 512B of RAM) the MTU > isn't as large as IPv6 requires. I ought to be able to use CoAP in that > system. > > > > In any closed system designers will be able to determine the appropriate > MTU. For open systems with unmanaged clients, well, degradation due to loss > of network or link-layer fragments is a risk in any communication path. At > least if clients are using IPv6 there's infrastructure to determine the > end-to-end MTU limits, and adjust the application messages accordingly. > > > > I agree with Colin that an introductory section on packet sizes, > fragmentation, and their effects on CoAP architecture and use would help > avoid problems with folks not familiar with the constrained domain. > > > > Peter > > > > On Mon, Jul 5, 2010 at 5:59 AM, Zach Shelby wrote: > > Colin, > > > > You captured the situation perfectly. So now just to get that down in > text for coap-01 - the hard part. Seems I closed that ticket prematurely. > > > > Carsten pointed that we have two options: > > > > 1. Define that this must fit in an IPv6 packet with an MTU of 1280 bytes. > > or > > 2. Define a fixed octet limit of e.g. 1152. At that point why not just > say 1024 bytes. > > > > Regarding 6LoWPAN how about we do the following. We include some text > about this in the introduction, which is then also referenced from the text > about maximum packet sizes. We can't force applications to avoid adaptation > layer fragmentation, but we can point out that it was a design requirement. > > > > The Block Option discussion we can have separately to this. But as > Carsten pointed out it shouldn't affect this text as you would use a block > size < 1024 bytes anyways. > > > > Zach > > > > On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote: > > > > > Hello, > > > > > > I think unfortunately the question of "optimum packet size" will always > be "it depends". I'm assuming in the following you *need* to send a larger > packet for some reason. > > > > > > Performing the fragmentation at the 6LoWPAN layer should be the most > efficient, as you don't waste having IP/UDP/CoAP headers on each packet. > This would suggest sending as large an IPv6 packet as possible. Under > reasonable network conditions a 6LoWPAN network can do this pretty reliably > (1280 byte delivery). > > > > > > But in a bad RF environment though the lower layers may not deliver > this message as reliably. Normally 802.15.4 will retry sending each 6LoWPAN > fragment three times, after which it gives up. You then need to resend the > entire IPv6 packet until all the fragments get through. As each time you are > sending many (say 10) fragments, this could take a few tries! This would > suggest keeping the IPv6 packet as small as possible, so each individual > IPv6 packet is likely to get through, and when they fail you aren't > resending as much. > > > > > > Again I think it comes down to CoAP being a simple protocol. It will > work great for small packets basically no matter what. It should work pretty > well for larger packets too even. But if you want to transfer lots of data > (firmware, etc) it's better to use something designed for the purpose. > > > > > > Another consideration for CoAP data is not just the transfer of it, but > actually buffering the data in memory. I would guess most constrained (ie: > 8-bit processor) devices are designed around having a 1280 byte IP buffer. > The actual resources need to be designed with this in mind too! > > > > > > Regards, > > > > > > -Colin > > > > > > > > > > > > > > > -----Original Message----- > > > From: core-bounces@ietf.org on behalf of Carsten Bormann > > > Sent: Mon 05/07/2010 10:29 > > > To: Guido Moritz > > > Cc: core > > > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options > table,maximum datagram) > > > > > > On Jul 2, 2010, at 12:37, Guido Moritz wrote: > > > > > > > 1280 seems > > > > to be reasonable as the magic number of 6LoWPAN networks in general > ;) > > > > > > Well, 1280 is the magic number of IPv6 MTUs. > > > 6LoWPAN does support 1280 byte packets, but splitting a packet into 15 > or 20 fragments is expensive in terms of reduced probability of delivery. > > > > > > Worse, Protocols like RPL can steal some of these bytes (and the IP and > UDP headers will, too). > > > CoAP implementations should be able to operate on any UDP datagram that > fits into the IPv6 MTU. > > > > > > But having a good idea of what is actually efficient to use also helps. > > > So I would rarely send a CoAP payload of more than 1024 bytes; adding > in CoAP options (the total size of which depends a lot on the length of the > URI), CoAP fixed header (4 bytes), UDP header and IP header then is likely > to leave some room for RPL and other tunnel stunts. > > > For applications such as firmware transfers on 6LoWPAN, I would stick > with a payload size of 64 (1 fragment) or 128 (two fragments); that's why > coap://ns.tzi.org:61616/ has 128 as the default block size. > > > > > > Gruesse, Carsten > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > -- > > Zach Shelby, Chief Nerd, Sensinode Ltd. > > http://zachshelby.org - My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > > Mobile: +358 40 7796297 > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > > --e0cb4e887811627cb3048ab7886c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, thank you.

Peter

On Tue, Jul = 6, 2010 at 7:46 AM, Oflynn, Colin <Colin.OFlynn@atmel.com> wrote:

Hi Zach,

This looks really good to me. Specifying path MTU closes my concern about &= #39;which MTU will people use', and the paragraph is strongly worded en= ough to get the idea across of e.g.: don't send big packets unless you = know what you are doing!

Thanks,



=A0 -Colin


-----Original Message-----
From: Zach Shelby [= mailto:zach@sensinode.com]
Sent: Tue 06/07/2010 13:45
To: Peter Bigot
Cc: Oflynn, Colin; core
Subject: Re: [core] #15: Consolidate maximum sizes (encodings, options tabl= e,=A0 maximum datagram)

I understand both arguments there. I added introduction text about adaptati= on layer fragmentation, and referenced that. Now this gives you the obvious= hard upper bound as this is UDP, plus lets you use a Path MTU if you know = it. I propose this text:

=A0=A0 The length of the Payload in a CoAP message is calculated from the =A0=A0 datagram length.=A0 While specific link layers make it beneficial to=
=A0=A0 keep CoAP messages small enough to fit into their link layer packets=
=A0=A0 (see Section 1), this is a matter of implementation quality.=A0 The<= br> =A0=A0 CoAP specification itself provides only an upper bound to the messag= e
=A0=A0 size.=A0 A CoAP message SHOULD fit within a single IP packet and MUS= T
=A0=A0 fit within a single IP datagram.=A0 If the Path MTU is not known for= a
=A0=A0 destination, an MTU of 1280 octets SHOULD be assumed.

On Jul 5, 2010, at 4:17 PM, Peter Bigot wrote:

> Seems I closed that ticket prematurely.
>
> Too bad; I was all set to +1 the proposed wording.
>
> I understand the desire to define a small fixed limit so people don= 9;t forget that "constrained" is significant and try to use CoAP = to stream HD video.=A0 But I can't see a rationale for any numeric limi= t that doesn't end up unnecessarily coupling CoAP to a specific technol= ogy.=A0 If I have a whole infrastructure set up with CoAP, I might really l= ike to be able to re-use it on a network where the MTU is, say, 2048 bytes.= =A0 I'd be kinda upset if I had to replace the entire system because th= e specification included arbitrary assumptions about maximum packet size. >
> Fragmentation is hard, so I think CoAP should make it somebody else= 9;s problem.=A0 What's wrong with referring to the MTU of the underlyin= g transport protocol (as long as "MTU" is defined)?=A0 I might ev= en have a system where, for technical reasons (e.g., the devices have only = 512B of RAM) the MTU isn't as large as IPv6 requires.=A0 I ought to be = able to use CoAP in that system.
>
> In any closed system designers will be able to determine the appropria= te MTU.=A0 For open systems with unmanaged clients, well, degradation due t= o loss of network or link-layer fragments is a risk in any communication pa= th.=A0 At least if clients are using IPv6 there's infrastructure to det= ermine the end-to-end MTU limits, and adjust the application messages accor= dingly.
>
> I agree with Colin that an introductory section on packet sizes, fragm= entation, and their effects on CoAP architecture and use would help avoid p= roblems with folks not familiar with the constrained domain.
>
> Peter
>
> On Mon, Jul 5, 2010 at 5:59 AM, Zach Shelby <zach@sensinode.com> wrote:
> Colin,
>
> You captured the situation perfectly. So now just to get that down in = text for coap-01 - the hard part. Seems I closed that ticket prematurely. >
> Carsten pointed that we have two options:
>
> 1. Define that this must fit in an IPv6 packet with an MTU of 1280 byt= es.
> or
> 2. Define a fixed octet limit of e.g. 1152. At that point why not just= say 1024 bytes.
>
> Regarding 6LoWPAN how about we do the following. We include some text = about this in the introduction, which is then also referenced from the text= about maximum packet sizes. We can't force applications to avoid adapt= ation layer fragmentation, but we can point out that it was a design requir= ement.
>
> The Block Option discussion we can have separately to this. But as Car= sten pointed out it shouldn't affect this text as you would use a block= size < 1024 bytes anyways.
>
> Zach
>
> On Jul 5, 2010, at 1:49 PM, Oflynn, Colin wrote:
>
> > Hello,
> >
> > I think unfortunately the question of "optimum packet size&q= uot; will always be "it depends". I'm assuming in the followi= ng you *need* to send a larger packet for some reason.
> >
> > Performing the fragmentation at the 6LoWPAN layer should be the m= ost efficient, as you don't waste having IP/UDP/CoAP headers on each pa= cket. This would suggest sending as large an IPv6 packet as possible. Under= reasonable network conditions a 6LoWPAN network can do this pretty reliabl= y (1280 byte delivery).
> >
> > But in a bad RF environment though the lower layers may not deliv= er this message as reliably. Normally 802.15.4 will retry sending each 6LoW= PAN fragment three times, after which it gives up. You then need to resend = the entire IPv6 packet until all the fragments get through. As each time yo= u are sending many (say 10) fragments, this could take a few tries! This wo= uld suggest keeping the IPv6 packet as small as possible, so each individua= l IPv6 packet is likely to get through, and when they fail you aren't r= esending as much.
> >
> > Again I think it comes down to CoAP being a simple protocol. It w= ill work great for small packets basically no matter what. It should work p= retty well for larger packets too even. But if you want to transfer lots of= data (firmware, etc) it's better to use something designed for the pur= pose.
> >
> > Another consideration for CoAP data is not just the transfer of i= t, but actually buffering the data in memory. I would guess most constraine= d (ie: 8-bit processor) devices are designed around having a 1280 byte IP b= uffer. The actual resources need to be designed with this in mind too!
> >
> > Regards,
> >
> >=A0=A0=A0 -Colin
> >
> >
> >
> >
> > -----Original Message-----
> > From: = core-bounces@ietf.org on behalf of Carsten Bormann
> > Sent: Mon 05/07/2010 10:29
> > To: Guido Moritz
> > Cc: core
> > Subject: Re: [core] #15: Consolidate maximum sizes (encodings, op= tions table,maximum datagram)
> >
> > On Jul 2, 2010, at 12:37, Guido Moritz wrote:
> >
> > > 1280 seems
> > > to be reasonable as the magic number of 6LoWPAN networks in = general ;)
> >
> > Well, 1280 is the magic number of IPv6 MTUs.
> > 6LoWPAN does support 1280 byte packets, but splitting a packet in= to 15 or 20 fragments is expensive in terms of reduced probability of deliv= ery.
> >
> > Worse, Protocols like RPL can steal some of these bytes (and the = IP and UDP headers will, too).
> > CoAP implementations should be able to operate on any UDP datagra= m that fits into the IPv6 MTU.
> >
> > But having a good idea of what is actually efficient to use also = helps.
> > So I would rarely send a CoAP payload of more than 1024 bytes; ad= ding in CoAP options (the total size of which depends a lot on the length o= f the URI), CoAP fixed header (4 bytes), UDP header and IP header then is l= ikely to leave some room for RPL and other tunnel stunts.
> > For applications such as firmware transfers on 6LoWPAN, I would s= tick with a payload size of 64 (1 fragment) or 128 (two fragments); that= 9;s why coap://ns.tz= i.org:61616/ has 128 as the default block size.
> >
> > Gruesse, Carsten
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/core
> >
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/core
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.= org=A0 - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core
>

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



--e0cb4e887811627cb3048ab7886c-- From gtolle@archrock.com Tue Jul 6 19:55: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 379863A6359 for ; Tue, 6 Jul 2010 19:55:24 -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 3VaqvkW0vtbp for ; Tue, 6 Jul 2010 19:55:23 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 45AE33A6964 for ; Tue, 6 Jul 2010 19:55:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 6F337AFA04 for ; Tue, 6 Jul 2010 19:53:32 -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 vRcZnJDzOi3F for ; Tue, 6 Jul 2010 19:53:27 -0700 (PDT) Received: from [10.0.1.200] (cpe-68-175-12-28.nyc.res.rr.com [68.175.12.28]) by mail.sf.archrock.com (Postfix) with ESMTP id 61B27AF8E7 for ; Tue, 6 Jul 2010 19:53:27 -0700 (PDT) Message-Id: 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: Tue, 6 Jul 2010 22:55:19 -0400 X-Mailer: Apple Mail (2.936) Subject: [core] A few questions about the latest coap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 02:55:24 -0000 I have a few additional questions and comments about the latest CoAP draft: Why was the "Location" header omitted from the allowable header options? At the very least, properly supporting the "201 Created" response requires it. "201 Created - The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field." - RFC 2616 Why must the URI be broken up into separate "scheme", "authority", and "path" components? Was that decision intended to save 2 bytes by replacing the 3-byte "://" portion of the URI with 1 byte's worth of option headers in the case when a CoAP node is requesting resources via a proxy, and to save a byte in non-proxied requests by enabling omission of the leading "/"? It just seems like needless complexity to me, as compared with a single "URI" option. And, if we add the Location header, then will it be split up like the URI header or maintained as a single option? Why were the HTTP redirection codes (301, 302, 303) omitted from the allowed CoAP response codes? Even though the common-practice implementation of code 302 doesn't match the standard, having a well- specified redirection technique within CoAP seems like it would be valuable. A 301 redirection code could be used to notify clients about the preferred URIs on a server for the purposes of URI-shortening, for example, or to support evolution in REST APIs defined over CoAP. Since the options are variable-length and must be sequentially parsed in all cases, what's the intended benefit of including the option count in the header? Gil From cabo@tzi.org Tue Jul 6 23:17:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80C23A67CC for ; Tue, 6 Jul 2010 23:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK5St8dfhE8g for ; Tue, 6 Jul 2010 23:17:01 -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 3FACE3A67EC for ; Tue, 6 Jul 2010 23:17:00 -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 o676GsZ2009466; Wed, 7 Jul 2010 08:16:54 +0200 (CEST) Received: from [192.168.217.101] (p5489A3B0.dip.t-dialin.net [84.137.163.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 17847B4E7; Wed, 7 Jul 2010 08:16:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 7 Jul 2010 08:16:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Gilman Tolle X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] A few questions about the latest coap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 06:17:06 -0000 Hi Gilman, that is great feedback. Let my try to answer this from what I know. > Why was the "Location" header omitted from the allowable header = options? At the very least, properly supporting the "201 Created" = response requires it. I can't answer that question ("why"), but obviously, the use cases for = POST have received little discussion so far. Do you have some that you could share? > "201 Created - The request has been fulfilled and resulted in a new = resource being created. The newly created resource can be referenced by = the URI(s) returned in the entity of the response, with the most = specific URI for the resource given by a Location header field." - RFC = 2616 (This is from the POST section. 201 Created on a PUT relies less on = Location:) > Why must the URI be broken up into separate "scheme", "authority", and = "path" components? Was that decision intended to save 2 bytes by = replacing the 3-byte "://" portion of the URI with 1 byte's worth of = option headers in the case when a CoAP node is requesting resources via = a proxy, and to save a byte in non-proxied requests by enabling omission = of the leading "/"? It just seems like needless complexity to me, as = compared with a single "URI" option. In the majority of cases, there will be "path" only. Saving the = redundant byte consumed by the initial "/" seemed worth adding another = option for the case when there indeed is a scheme and an authority in = the message. Separating scheme and authority allows some useful = defaulting and possibly opens the door to a binary representation of = authority (see coap-misc-05). > And, if we add the Location header, then will it be split up like the = URI header or maintained as a single option? It would be logical to handle it the same way. > Why were the HTTP redirection codes (301, 302, 303) omitted from the = allowed CoAP response codes? Even though the common-practice = implementation of code 302 doesn't match the standard, having a = well-specified redirection technique within CoAP seems like it would be = valuable. A 301 redirection code could be used to notify clients about = the preferred URIs on a server for the purposes of URI-shortening, for = example, or to support evolution in REST APIs defined over CoAP. Again, it would be beneficial to discuss use cases -- just because HTTP = has it is not sufficient IMHO. E.g., do we need all of the redirects? But I agree one can imagine use cases where some redirect functionality = would be useful. > Since the options are variable-length and must be sequentially parsed = in all cases, what's the intended benefit of including the option count = in the header? That is the way to know when the options end. (And "end of options" indication would consume one byte by itself or one = bit per option, which we don't really have; it would also make at least = one option required. Since there is space in the header, spending four = bits there sounds right.) Gruesse, Carsten From robert.cragie@gridmerge.com Tue Jul 6 23:42: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 EAA2F3A685F for ; Tue, 6 Jul 2010 23:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.695 X-Spam-Level: ** X-Spam-Status: No, score=2.695 tagged_above=-999 required=5 tests=[AWL=2.633, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 iGLFq2+PW9e4 for ; Tue, 6 Jul 2010 23:42:49 -0700 (PDT) Received: from webmail2.extendcp.co.uk (www.outitgoes.com [79.170.40.67]) by core3.amsl.com (Postfix) with ESMTP id 654AC3A6897 for ; Tue, 6 Jul 2010 23:42:45 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail2.extendcp.co.uk with esmtp (Exim 4.43) id 1OWOJb-00009J-2E; Wed, 07 Jul 2010 07:41:03 +0100 Message-Id: From: Robert Cragie To: "Carsten Bormann" ,"Gilman Tolle" X-Mailer: Atmail in-reply-to: Date: Wed, 07 Jul 2010 07:41:03 +0100 Content-Type: multipart/alternative; boundary="=_a503ebf5d4769e93acb056c004c5e21d" MIME-Version: 1.0 Cc: core@ietf.org Subject: Re: [core] A few questions about the latest coap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 06:42:53 -0000 --=_a503ebf5d4769e93acb056c004c5e21d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I presume this refers to the 'pre-draft'. Is coap-01 going to be=0Arelea= sed soon? Otherwise this is going to get complicated.=0A=0ARobert=0A=0A-= ---- Original Message -----=0AFrom: Carsten Bormann =0ATo:"Gilman Tolle"= =0ACc:=0ASent:Wed, 7 Jul 2010 08:16:52 +0200=0ASubject:Re: [core] A few= questions about the latest coap draft=0A=0A Hi Gilman,=0A=0A that is gr= eat feedback. Let my try to answer this from what I know.=0A=0A > Why wa= s the "Location" header omitted from the allowable header=0Aoptions? At= the very least, properly supporting the "201 Created"=0Aresponse requir= es it.=0A=0A I can't answer that question ("why"), but obviously, the us= e cases=0Afor POST have received little discussion so far.=0A Do you hav= e some that you could share?=0A=0A > "201 Created - The request has been= fulfilled and resulted in a=0Anew resource being created. The newly cre= ated resource can be=0Areferenced by the URI(s) returned in the entity o= f the response, with=0Athe most specific URI for the resource given by a= Location header=0Afield." - RFC 2616=0A=0A (This is from the POST secti= on. 201 Created on a PUT relies less on=0ALocation:)=0A=0A > Why must th= e URI be broken up into separate "scheme", "authority",=0Aand "path" com= ponents? Was that decision intended to save 2 bytes by=0Areplacing the 3= -byte "://" portion of the URI with 1 byte's worth of=0Aoption headers i= n the case when a CoAP node is requesting resources=0Avia a proxy, and t= o save a byte in non-proxied requests by enabling=0Aomission of the lead= ing "/"? It just seems like needless complexity to=0Ame, as compared wit= h a single "URI" option.=0A=0A In the majority of cases, there will be "= path" only. Saving the=0Aredundant byte consumed by the initial "/" seem= ed worth adding another=0Aoption for the case when there indeed is a sch= eme and an authority in=0Athe message. Separating scheme and authority a= llows some useful=0Adefaulting and possibly opens the door to a binary r= epresentation of=0Aauthority (see coap-misc-05).=0A=0A > And, if we add= the Location header, then will it be split up like=0Athe URI header or= maintained as a single option?=0A=0A It would be logical to handle it t= he same way.=0A=0A > Why were the HTTP redirection codes (301, 302, 303)= omitted from=0Athe allowed CoAP response codes? Even though the common-= practice=0Aimplementation of code 302 doesn't match the standard, having= a=0Awell-specified redirection technique within CoAP seems like it woul= d=0Abe valuable. A 301 redirection code could be used to notify clients= =0Aabout the preferred URIs on a server for the purposes of=0AURI-shorte= ning, for example, or to support evolution in REST APIs=0Adefined over C= oAP.=0A=0A Again, it would be beneficial to discuss use cases -- just be= cause=0AHTTP has it is not sufficient IMHO.=0A E.g., do we need all of t= he redirects?=0A But I agree one can imagine use cases where some redire= ct=0Afunctionality would be useful.=0A=0A > Since the options are variab= le-length and must be sequentially=0Aparsed in all cases, what's the int= ended benefit of including the=0Aoption count in the header?=0A=0A That= is the way to know when the options end.=0A (And "end of options" indic= ation would consume one byte by itself or=0Aone bit per option, which we= don't really have; it would also make at=0Aleast one option required. S= ince there is space in the header,=0Aspending four bits there sounds rig= ht.)=0A=0A Gruesse, Carsten=0A=0A ______________________________________= _________=0A core mailing list=0A=0A core@ietf.org=0A https://www.ietf.o= rg [1]/mailman/listinfo/core=0A=0A=0ALinks:=0A------=0A[1] http://www.ie= tf.org=0A --=_a503ebf5d4769e93acb056c004c5e21d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I presume this refers to the 'pre-draft'. Is coap-01 going t= o be released soon? Otherwise this is going to get complicated.
Robert

----- Original Message -----
From:
Carsten Bormann <c= abo@tzi.org>
To:
"Gi= lman Tolle" <gtolle@archrock.com>
Cc:
<core@ietf.org>
Sent:
Wed, 7 Jul 2010 08:16:52 +0200
Subject:
Re: [core] A few questions about the latest coa= p draft


=0AHi Gilman,

=0Athat is great feedb= ack. Let my try to answer this from what I know.

=0A> Why= was the "Location" header omitted from the allowable header options? At= the very least, properly supporting the "201 Created" response requires= it.

=0AI can't answer that question ("why"), but obviously,= the use cases for POST have received little discussion so far.
=0A= Do you have some that you could share?

=0A> "201 Created -= The request has been fulfilled and resulted in a new resource being cre= ated. The newly created resource can be referenced by the URI(s) returne= d in the entity of the response, with the most specific URI for the reso= urce given by a Location header field." - RFC 2616

=0A(This i= s from the POST section. 201 Created on a PUT relies less on Location:)=

=0A> Why must the URI be broken up into separate "scheme"= , "authority", and "path" components? Was that decision intended to save= 2 bytes by replacing the 3-byte "://" portion of the URI with 1 byte's= worth of option headers in the case when a CoAP node is requesting reso= urces via a proxy, and to save a byte in non-proxied requests by enablin= g omission of the leading "/"? It just seems like needless complexity to= me, as compared with a single "URI" option.

=0AIn the majori= ty of cases, there will be "path" only. Saving the redundant byte consu= med by the initial "/" seemed worth adding another option for the case w= hen there indeed is a scheme and an authority in the message. Separatin= g scheme and authority allows some useful defaulting and possibly opens= the door to a binary representation of authority (see coap-misc-05).
=0A> And, if we add the Location header, then will it be spl= it up like the URI header or maintained as a single option?

= =0AIt would be logical to handle it the same way.

=0A> Why= were the HTTP redirection codes (301, 302, 303) omitted from the allowe= d CoAP response codes? Even though the common-practice implementation of= code 302 doesn't match the standard, having a well-specified redirectio= n technique within CoAP seems like it would be valuable. A 301 redirecti= on code could be used to notify clients about the preferred URIs on a se= rver for the purposes of URI-shortening, for example, or to support evol= ution in REST APIs defined over CoAP.

=0AAgain, it would be b= eneficial to discuss use cases -- just because HTTP has it is not suffic= ient IMHO.
=0AE.g., do we need all of the redirects?
=0ABut I= agree one can imagine use cases where some redirect functionality would= be useful.

=0A> Since the options are variable-length and= must be sequentially parsed in all cases, what's the intended benefit o= f including the option count in the header?

=0AThat is the wa= y to know when the options end.
=0A(And "end of options" indication= would consume one byte by itself or one bit per option, which we don't= really have; it would also make at least one option required. Since th= ere is space in the header, spending four bits there sounds right.)

=0AGruesse, Carsten

=0A_______________________________= ________________
=0Acore mailing list

=0Acore@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/core
--=_a503ebf5d4769e93acb056c004c5e21d-- From zach@sensinode.com Wed Jul 7 01:39:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCD63A689D for ; Wed, 7 Jul 2010 01:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.492, 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 irReje--pI37 for ; Wed, 7 Jul 2010 01:38:53 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CD7C63A659C for ; Wed, 7 Jul 2010 01:38:27 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o678cIFl023435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Jul 2010 11:38:18 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 7 Jul 2010 11:38:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Cragie X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] A few questions about the latest coap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 08:39:32 -0000 coap-01 is being released at the end of today EET, currently just = integrating the last contributions and finishing editing. Yes, Gil is = discussing a draft which was sent to interested developers. Let's keep = that feedback discussion with the authors for now as not to confuse = people.=20 In general I agree with Carsten, the goal here is to support response = codes and options that have a clearly identified purpose for CoAP use = cases. As we find a need for a specific option or code then we will = analyze them, make a ticket, and then get it into the next draft based = on WG discussion. So no hurry there to get every possible option and = code into coap-01. coap-misc is currently being used as a playground for = things we think we might need...=20 Zach On Jul 7, 2010, at 9:41 AM, Robert Cragie wrote: > I presume this refers to the 'pre-draft'. Is coap-01 going to be = released soon? Otherwise this is going to get complicated. >=20 > Robert >=20 > ----- Original Message ----- > From: > Carsten Bormann >=20 > To: > "Gilman Tolle" > Cc: > > Sent: > Wed, 7 Jul 2010 08:16:52 +0200 > Subject: > Re: [core] A few questions about the latest coap draft >=20 >=20 > Hi Gilman, >=20 > that is great feedback. Let my try to answer this from what I know. >=20 > > Why was the "Location" header omitted from the allowable header = options? At the very least, properly supporting the "201 Created" = response requires it. >=20 > I can't answer that question ("why"), but obviously, the use cases for = POST have received little discussion so far. > Do you have some that you could share? >=20 > > "201 Created - The request has been fulfilled and resulted in a new = resource being created. The newly created resource can be referenced by = the URI(s) returned in the entity of the response, with the most = specific URI for the resource given by a Location header field." - RFC = 2616 >=20 > (This is from the POST section. 201 Created on a PUT relies less on = Location:) >=20 > > Why must the URI be broken up into separate "scheme", "authority", = and "path" components? Was that decision intended to save 2 bytes by = replacing the 3-byte "://" portion of the URI with 1 byte's worth of = option headers in the case when a CoAP node is requesting resources via = a proxy, and to save a byte in non-proxied requests by enabling omission = of the leading "/"? It just seems like needless complexity to me, as = compared with a single "URI" option. >=20 > In the majority of cases, there will be "path" only. Saving the = redundant byte consumed by the initial "/" seemed worth adding another = option for the case when there indeed is a scheme and an authority in = the message. Separating scheme and authority allows some useful = defaulting and possibly opens the door to a binary representation of = authority (see coap-misc-05). >=20 > > And, if we add the Location header, then will it be split up like = the URI header or maintained as a single option? >=20 > It would be logical to handle it the same way. >=20 > > Why were the HTTP redirection codes (301, 302, 303) omitted from the = allowed CoAP response codes? Even though the common-practice = implementation of code 302 doesn't match the standard, having a = well-specified redirection technique within CoAP seems like it would be = valuable. A 301 redirection code could be used to notify clients about = the preferred URIs on a server for the purposes of URI-shortening, for = example, or to support evolution in REST APIs defined over CoAP. >=20 > Again, it would be beneficial to discuss use cases -- just because = HTTP has it is not sufficient IMHO. > E.g., do we need all of the redirects? > But I agree one can imagine use cases where some redirect = functionality would be useful. >=20 > > Since the options are variable-length and must be sequentially = parsed in all cases, what's the intended benefit of including the option = count in the header? >=20 > That is the way to know when the options end. > (And "end of options" indication would consume one byte by itself or = one bit per option, which we don't really have; it would also make at = least one option required. Since there is space in the header, spending = four bits there sounds right.) >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list >=20 > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Wed Jul 7 01:52: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 1D1883A689D for ; Wed, 7 Jul 2010 01:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ErO56mj2bjeW for ; Wed, 7 Jul 2010 01:52:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BDDBB3A687A for ; Wed, 7 Jul 2010 01:52:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWQMx-0001og-2h; Wed, 07 Jul 2010 01:52:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 07 Jul 2010 08:52:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/3#comment:1 Message-ID: <066.55f77d9458112ea3c2b6078eaeb9541e@tools.ietf.org> References: <057.9990f45e4a0caf57c2536f6cbd946c0d@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <057.9990f45e4a0caf57c2536f6cbd946c0d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #3: Section 2.1 improvements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:52:56 -0000 #3: Section 2.1 improvements --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Section 2 completed for coap-01. The transaction ID on a large client will still need some work, a new ticket needs to be opened on that. -- Ticket URL: core From trac@tools.ietf.org Wed Jul 7 01:53:00 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 0B4C13A68B1 for ; Wed, 7 Jul 2010 01:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XJnmHvaTwNXH for ; Wed, 7 Jul 2010 01:52:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EA88B3A68A3 for ; Wed, 7 Jul 2010 01:52:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWQNJ-0001or-62; Wed, 07 Jul 2010 01:53:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 07 Jul 2010 08:53:01 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/11#comment:2 Message-ID: <066.8060539b0fbf9529c1f6f73729183ce2@tools.ietf.org> References: <057.6a78f44a17984067e2625df14b0e601d@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <057.6a78f44a17984067e2625df14b0e601d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #11: Finish Examples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:53:00 -0000 #11: Finish Examples --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: 3 new examples added to coap-01. -- Ticket URL: core From robby.simpson@ge.com Wed Jul 7 06:12:13 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 175913A67B6 for ; Wed, 7 Jul 2010 06:12:13 -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 Qr+q1NpCy9Fy for ; Wed, 7 Jul 2010 06:12:11 -0700 (PDT) Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by core3.amsl.com (Postfix) with ESMTP id 79CF73A67E9 for ; Wed, 7 Jul 2010 06:12:11 -0700 (PDT) Received: from source ([12.43.191.1]) (using TLSv1) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKTDR9LYF+xN0oF4Ou8vzbRzbzBb1dczjd@postini.com; Wed, 07 Jul 2010 06:12:15 PDT Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by Alpmlip04.e2k.ad.ge.com with ESMTP; 07 Jul 2010 09:12:12 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.50]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 09:12:12 -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, 7 Jul 2010 09:12:11 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] A few questions about the latest coap draft Thread-Index: AcsdnAm2cf93cr9gSY+FCG3B7lT4lgAOTReQ References: From: "Simpson, Robby (GE Energy Services)" To: "Carsten Bormann" , "Gilman Tolle" X-OriginalArrivalTime: 07 Jul 2010 13:12:12.0042 (UTC) FILETIME=[02FB46A0:01CB1DD6] Cc: core@ietf.org Subject: Re: [core] A few questions about the latest coap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 13:12:13 -0000 >> Why was the "Location" header omitted from the allowable header options? At the very least, properly supporting the "201 Created" response requires it. > I can't answer that question ("why"), but obviously, the use cases for POST have received little discussion so far. > Do you have some that you could share? I'm uncertain as to how formal a use case you'd like to see, but here's a simple example: Imagine a list of events, where each event is a resource. Further, imagine that each resource is addressed via an arbitrary number (event ID) assigned by the server. If an external device (client) wished to POST a new event, but leave it to the server to assign the address, then a Location header would be very useful in pointing to the newly assigned address for the event POSTed. In short, when a server exposes a set of resources in a collection, where the addresses of the items of the collection are assigned by the server, but items are added to the collection by clients. - Robby From zach@sensinode.com Wed Jul 7 06:31: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 9B61B3A67CC for ; Wed, 7 Jul 2010 06:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=0.447, 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 o0d8qMSgVQtd for ; Wed, 7 Jul 2010 06:31:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9468D3A67B6 for ; Wed, 7 Jul 2010 06:31:34 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o67DVQJN018403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Jul 2010 16:31:26 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 7 Jul 2010 16:31:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8CEC2911-AC92-47CA-BC1A-E47A780230F3@sensinode.com> References: To: "Simpson, Robby (GE Energy Services)" X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] A few questions about the latest coap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 13:31:36 -0000 Robby, I agree, this is a clear case for Location, as is a redirect in case a = resource has moved on a CoAP end-point. But in both cases we only need a = Location with a relative URI (as supported in modern HTTP browsers as = well).=20 Proposal: How about a Location Option supporting only a relative URI? = The format would be identical to Uri-Path but Location would be = Elective.=20 Zach On Jul 7, 2010, at 4:12 PM, Simpson, Robby (GE Energy Services) wrote: >>> Why was the "Location" header omitted from the allowable header > options? At the very least, properly supporting the "201 Created" > response requires it. >=20 >> I can't answer that question ("why"), but obviously, the use cases = for > POST have received little discussion so far. >> Do you have some that you could share? >=20 > I'm uncertain as to how formal a use case you'd like to see, but = here's > a simple example: > Imagine a list of events, where each event is a resource. Further, > imagine that each resource is addressed via an arbitrary number (event > ID) assigned by the server. >=20 > If an external device (client) wished to POST a new event, but leave = it > to the server to assign the address, then a Location header would be > very useful in pointing to the newly assigned address for the event > POSTed. >=20 > In short, when a server exposes a set of resources in a collection, > where the addresses of the items of the collection are assigned by the > server, but items are added to the collection by clients. >=20 > - Robby > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From gtolle@archrock.com Wed Jul 7 06:56: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 D2BE83A6859 for ; Wed, 7 Jul 2010 06:56:57 -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] 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 hCuFKd0tFIS2 for ; Wed, 7 Jul 2010 06:56:56 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id A49013A6861 for ; Wed, 7 Jul 2010 06:56:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9D08CAF9B7; Wed, 7 Jul 2010 06:55:06 -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 EB0kxLzU5LMH; Wed, 7 Jul 2010 06:55:03 -0700 (PDT) Received: from [10.0.1.200] (cpe-68-175-12-28.nyc.res.rr.com [68.175.12.28]) by mail.sf.archrock.com (Postfix) with ESMTP id 6E308AF928; Wed, 7 Jul 2010 06:55:02 -0700 (PDT) Message-Id: From: Gilman Tolle To: Zach Shelby In-Reply-To: <8CEC2911-AC92-47CA-BC1A-E47A780230F3@sensinode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Jul 2010 09:56:54 -0400 References: <8CEC2911-AC92-47CA-BC1A-E47A780230F3@sensinode.com> X-Mailer: Apple Mail (2.936) Cc: core@ietf.org Subject: Re: [core] A few questions about the latest coap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 13:56:57 -0000 Responding on the list because I was discussing issues which appear in the coap-00 draft (excluding the option count, which was added in the coap-01 prerelease). I wouldn't reasonably expect this feedback to be included in coap-01 because it's so close to being released, and am happy to keep specific comments about the prerelease draft among the authors. Seconding Robby's use case for Location on 201 Created. When a sensor or meter is POSTing a new event to a server, the server should be able to notify the client of the URL for the stored event. A second use case: an end-user device sends a command via POST to another device, but that command may take a long time to execute. The server should be able to return the URL for a resource that can be periodically accessed in order to get the progress of the command, so the client can update a display. In response to Carsten's earlier comment, we don't need all the redirect codes, but I'd suggest including 301 (permanent redirect) and 302 (temporary redirect while maintaining the same method, as it's specified in HTTP/1.1). Both of those will enable a degree of flexibility in the resource locations defined by a particular REST API over CoAP. The 303 See Other redirect is intended for GET-after-POST, but I think our intended use of 201 Created fulfills a similar role, suggesting that 303 is not needed. Between 201 Created and the redirects, I'd support adding an elective Location header with a relative URI, similar to Uri-Path. Comment withdrawn about the option count -- I agree that it's necessary. Gil On Jul 7, 2010, at 9:31 AM, Zach Shelby wrote: > Robby, > > I agree, this is a clear case for Location, as is a redirect in case > a resource has moved on a CoAP end-point. But in both cases we only > need a Location with a relative URI (as supported in modern HTTP > browsers as well). > > Proposal: How about a Location Option supporting only a relative > URI? The format would be identical to Uri-Path but Location would > be Elective. > > Zach > > On Jul 7, 2010, at 4:12 PM, Simpson, Robby (GE Energy Services) wrote: > >>>> Why was the "Location" header omitted from the allowable header >> options? At the very least, properly supporting the "201 Created" >> response requires it. >> >>> I can't answer that question ("why"), but obviously, the use cases >>> for >> POST have received little discussion so far. >>> Do you have some that you could share? >> >> I'm uncertain as to how formal a use case you'd like to see, but >> here's >> a simple example: >> Imagine a list of events, where each event is a resource. Further, >> imagine that each resource is addressed via an arbitrary number >> (event >> ID) assigned by the server. >> >> If an external device (client) wished to POST a new event, but >> leave it >> to the server to assign the address, then a Location header would be >> very useful in pointing to the newly assigned address for the event >> POSTed. >> >> In short, when a server exposes a set of resources in a collection, >> where the addresses of the items of the collection are assigned by >> the >> server, but items are added to the collection by clients. >> >> - Robby >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > From root@core3.amsl.com Thu Jul 8 01:30:29 2010 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D193F3A696D; Thu, 8 Jul 2010 01:30:09 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100708083017.D193F3A696D@core3.amsl.com> Date: Thu, 8 Jul 2010 01:30:03 -0700 (PDT) Cc: core@ietf.org Subject: [core] I-D Action:draft-ietf-core-coap-01.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: Thu, 08 Jul 2010 08:30:29 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Constrained Application Protocol (CoAP) Author(s) : Z. Shelby, et al. Filename : draft-ietf-core-coap-01.txt Pages : 36 Date : 2010-07-08 This document specifies the Constrained Application Protocol (CoAP), a specialized RESTful transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides the REST Method/ Response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-coap-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-core-coap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-08012453.I-D@ietf.org> --NextPart-- From trac@tools.ietf.org Thu Jul 8 01:37:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2FA3A69E0 for ; Thu, 8 Jul 2010 01:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 OLM38n383VuQ for ; Thu, 8 Jul 2010 01:36:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 31D133A6972 for ; Thu, 8 Jul 2010 01:35:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWma3-000896-PR; Thu, 08 Jul 2010 01:35:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dsturek@grid2home.com, zach@sensinode.com X-Trac-Project: core Date: Thu, 08 Jul 2010 08:35:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/10#comment:1 Message-ID: <066.0593f155bbbf72f64e19acf7a952791f@tools.ietf.org> References: <057.c60ec3c41742023dc334f5017523d546@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <057.c60ec3c41742023dc334f5017523d546@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dsturek@grid2home.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #10: HTTP Mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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 Jul 2010 08:37:43 -0000 #10: HTTP Mapping --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Don Sturek Type: enhancement | Status: closed Priority: major | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-01 -- Ticket URL: core From zach@sensinode.com Thu Jul 8 01:46:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44823A6897 for ; Thu, 8 Jul 2010 01:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 FhYQL+9CDB-F for ; Thu, 8 Jul 2010 01:46:41 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C28F53A6A00 for ; Thu, 8 Jul 2010 01:46:40 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o688YBWw028321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 8 Jul 2010 11:34:11 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jul 2010 11:34:12 +0300 References: <20100708082454.0091A3A6862@core3.amsl.com> To: core Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Fwd: New Version Notification for draft-ietf-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 08:46:42 -0000 CoAP-01 is now available: http://www.ietf.org/id/draft-ietf-core-coap-01.txt Thanks to everyone on the list, and especially Carsten and Klaus for a = huge amount of help in getting this done and in such good shape. Since = -00 we have closed 14 tickets and gone through 10 editorial versions. = This version of the draft will now be used as the basis for the = Maastricht plugfest. CoAP-02 is planned for just after Maastricht to = take into account interop feedback and integrate subscription. More = coming about plugfest organization soon. Changes from ietf-00 to ietf-01: o New cleaner transaction message model and header (#5) o Removed subscription while being designed (#1) o Section 2 re-written (#3) o Text added about use of short URIs (#4) o Improved header option scheme (#5, #14) o Date option removed whiled being designed (#6) o New text for CoAP default port (#7) o Completed proxying section (#8) o Completed resource discovery section (#9) o Completed HTTP mapping section (#10) o Several new examples added (#11) o URI split into 3 options (#12) o MIME type defined for link-format (#13, #16) o New text on maximum message size (#15) o Location Option added Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: July 8, 2010 11:24:54 AM GMT+03:00 > To: zach@sensinode.com > Cc: brian@skyfoundry.com,d.sturek@att.net > Subject: New Version Notification for draft-ietf-core-coap-01=20 >=20 >=20 > A new version of I-D, draft-ietf-core-coap-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-core-coap > Revision: 01 > Title: Constrained Application Protocol (CoAP) > Creation_date: 2010-07-08 > WG ID: core > Number_of_pages: 36 >=20 > Abstract: > This document specifies the Constrained Application Protocol (CoAP), > a specialized RESTful transfer protocol for use with constrained > networks and nodes for machine-to-machine applications such as smart > energy and building automation. These constrained nodes often have > 8-bit microcontrollers with small amounts of ROM and RAM, while > networks such as 6LoWPAN often have high packet error rates and a > typical throughput of 10s of kbit/s. CoAP provides the REST Method/ > Response interaction model between application end-points, supports > built-in resource discovery, and includes key web concepts such as > URIs and content-types. CoAP easily translates to HTTP for > integration with the web while meeting specialized requirements such > as multicast support, very low overhead and simplicity for > constrained environments. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Thu Jul 8 02:48:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E883A6A00 for ; Thu, 8 Jul 2010 02:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 xmH9q8JmyEeD for ; Thu, 8 Jul 2010 02:48:41 -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 176523A6982 for ; Thu, 8 Jul 2010 02:48:35 -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 o689mVw5009021 for ; Thu, 8 Jul 2010 11:48:31 +0200 (CEST) Received: from [134.102.2.127] (unknown [134.102.2.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id A0B3EBABA; Thu, 8 Jul 2010 11:48:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 8 Jul 2010 11:48:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F1BD244-2293-4E39-A3BF-4E2BBB75E108@tzi.org> References: <20100708082454.0091A3A6862@core3.amsl.com> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 09:48:42 -0000 On Jul 8, 2010, at 10:34, Zach Shelby wrote: > This version of the draft will now be used as the basis for the = Maastricht plugfest. In preparation for that, the test server at coap://ns.tzi.org:61616/ now runs CoAP-01. (The updated code is very preliminary and doesn't do anything but GET, = but the basics should work.) Gruesse, Carsten From zach@sensinode.com Thu Jul 8 06:07: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 588C43A6AC6 for ; Thu, 8 Jul 2010 06:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=0.378, 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 aih2j7RHs3P8 for ; Thu, 8 Jul 2010 06:07:30 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B365E3A6AC3 for ; Thu, 8 Jul 2010 06:07:28 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o68D7Tkc025652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 8 Jul 2010 16:07:29 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jul 2010 16:07:30 +0300 Message-Id: To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Maastricht CoRE plugfest 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 Jul 2010 13:07:31 -0000 I started a Wiki page for the upcoming CoRE plugfest in Maastricht: http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest This just has an initial bullet-point list of specifications, technical = info, minimal configurations, experimental features etc. Purely my own = opinion at this point, so feel free to comment and give ideas for the = event. I guess Carsten and I will maintain the wiki page but others are = totally welcome to add things there as well, e.g.: - coap-01 servers on-line, if you put up a server then add a link there = so people can test!=20 - Experimental features you would like to test (with a reference to the = specification) - Other useful info or links? Examples? We have created an IRC channel irc.freenode.net #coap which can be used = by people implementing and testing coap-01 running up to and during the = event. This will be the communication channel for remote participants as = well. Already there are 3 people on-line ;-) Regards, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From ynir@checkpoint.com Thu Jul 8 06:48: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 4813F3A6876 for ; Thu, 8 Jul 2010 06:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 wyugr5nkHG5W for ; Thu, 8 Jul 2010 06:48:42 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id C2FCC3A67E7 for ; Thu, 8 Jul 2010 06:48:41 -0700 (PDT) X-CheckPoint: {4C35E3D1-1-1B221DC2-2FFFF} 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 o68DmiDq012654; Thu, 8 Jul 2010 16:48:44 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 8 Jul 2010 16:49:16 +0300 From: Yoav Nir To: "'Zach Shelby'" , core Date: Thu, 8 Jul 2010 16:49:15 +0300 Thread-Topic: [core] Maastricht CoRE plugfest Thread-Index: Acsenp+Vg/xrr2UtSki30xCYuSD6VQABWDeQ Message-ID: <006FEB08D9C6444AB014105C9AEB133FFE28C51DDA@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Maastricht CoRE plugfest 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 Jul 2010 13:48:44 -0000 Wouldn't it be better to hold it on one of the evenings? I think most peopl= e will only arrive on Sunday, and may miss the event because of flight sche= dules. (I know I will) -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: Thursday, July 08, 2010 4:08 PM To: core Subject: [core] Maastricht CoRE plugfest I started a Wiki page for the upcoming CoRE plugfest in Maastricht: http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest This just has an initial bullet-point list of specifications, technical inf= o, minimal configurations, experimental features etc. Purely my own opinion= at this point, so feel free to comment and give ideas for the event. I gue= ss Carsten and I will maintain the wiki page but others are totally welcome= to add things there as well, e.g.: - coap-01 servers on-line, if you put up a server then add a link there so = people can test!=20 - Experimental features you would like to test (with a reference to the spe= cification) - Other useful info or links? Examples? We have created an IRC channel irc.freenode.net #coap which can be used by = people implementing and testing coap-01 running up to and during the event.= This will be the communication channel for remote participants as well. Al= ready there are 3 people on-line ;-) Regards, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core Scanned by Check Point Total Security Gateway. From cabo@tzi.org Thu Jul 8 06:52: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 0E63D3A67E7 for ; Thu, 8 Jul 2010 06:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCCveKJBW9Mu for ; Thu, 8 Jul 2010 06:52:03 -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 94FD63A6A59 for ; Thu, 8 Jul 2010 06:52:02 -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 o68Dpurr005085; Thu, 8 Jul 2010 15:51:56 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id F25D2BC62; Thu, 8 Jul 2010 15:51:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FFE28C51DDA@il-ex01.ad.checkpoint.com> Date: Thu, 8 Jul 2010 15:51:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <174284C1-A73B-48C4-A68C-23E2F1C3CD58@tzi.org> References: <006FEB08D9C6444AB014105C9AEB133FFE28C51DDA@il-ex01.ad.checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Maastricht CoRE plugfest 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 Jul 2010 13:52:04 -0000 On Jul 8, 2010, at 15:49, Yoav Nir wrote: > Wouldn't it be better to hold it on one of the evenings?=20 No, but that doesn't have to stop us from trying a repeat performance on = one of the evenings. Thursday? Gruesse, Carsten From edward.j.beroset@us.elster.com Thu Jul 8 07:50:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6123A6AE8; Thu, 8 Jul 2010 07:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4EI0YuyRvmi; Thu, 8 Jul 2010 07:50:16 -0700 (PDT) Received: from mail136.messagelabs.com (mail136.messagelabs.com [216.82.249.3]) by core3.amsl.com (Postfix) with SMTP id ECCBF3A6AE6; Thu, 8 Jul 2010 07:50:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: edward.j.beroset@us.elster.com X-Msg-Ref: server-13.tower-136.messagelabs.com!1278600618!42747789!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 16105 invoked from network); 8 Jul 2010 14:50:18 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-13.tower-136.messagelabs.com with SMTP; 8 Jul 2010 14:50:18 -0000 In-Reply-To: <174284C1-A73B-48C4-A68C-23E2F1C3CD58@tzi.org> References: <006FEB08D9C6444AB014105C9AEB133FFE28C51DDA@il-ex01.ad.checkpoint.com> <174284C1-A73B-48C4-A68C-23E2F1C3CD58@tzi.org> To: cabo@tzi.org MIME-Version: 1.0 X-KeepSent: 79DBDAB4:08EF0823-8525775A:00517000; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: edward.j.beroset@us.elster.com Date: Thu, 8 Jul 2010 10:50:20 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 07/08/2010 10:45:36 AM, Serialize complete at 07/08/2010 10:45:36 AM Content-Type: multipart/alternative; boundary="=_alternative 005183C98525775A_=" Cc: core-bounces@ietf.org, core Subject: Re: [core] Maastricht CoRE plugfest 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 Jul 2010 14:50:27 -0000 This is a multipart message in MIME format. --=_alternative 005183C98525775A_= Content-Type: text/plain; charset="US-ASCII" Carsten Bormann wrote on 07/08/2010 09:51:51: > On Jul 8, 2010, at 15:49, Yoav Nir wrote: > > > Wouldn't it be better to hold it on one of the evenings? > > No, but that doesn't have to stop us from trying a repeat > performance on one of the evenings. Thursday? +1 on a repeat for Thursday evening. Ed --=_alternative 005183C98525775A_= Content-Type: text/html; charset="US-ASCII" Carsten Bormann wrote on 07/08/2010 09:51:51:

> On Jul 8, 2010, at 15:49, Yoav Nir wrote:
>
> > Wouldn't it be better to hold it on one of the evenings?
>
> No, but that doesn't have to stop us from trying a repeat
> performance on one of the evenings.  Thursday?

+1 on a repeat for Thursday evening.

Ed --=_alternative 005183C98525775A_=-- From cabo@tzi.org Thu Jul 8 12:41: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 7B3523A68A3 for ; Thu, 8 Jul 2010 12:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30lu0aVDbe6V for ; Thu, 8 Jul 2010 12:41:52 -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 85AAD3A6B39 for ; Thu, 8 Jul 2010 12:41:47 -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 o68Jffg2011995 for ; Thu, 8 Jul 2010 21:41:41 +0200 (CEST) Received: from [192.168.217.101] (p5489A397.dip.t-dialin.net [84.137.163.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id A2C95BDCA; Thu, 8 Jul 2010 21:41:41 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Carsten Bormann Date: Thu, 8 Jul 2010 21:41:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100708193026.8FDCF3A6B5D@core3.amsl.com> To: core X-Mailer: Apple Mail (2.1081) Subject: [core] Fwd: I-D Action:draft-hartke-coap-observe-01.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: Thu, 08 Jul 2010 19:41:53 -0000 Klaus and I have added a fleshed-out minimal specification to the draft = so we can discuss this in more specific terms. (We haven't really had time to update the existing text, which is now = maintained as the rationale in an appendix -- maybe we can manage to do = this before the I-D cutoff.) Now I would love to have time to implement that... Gruesse, Carsten Begin forwarded message: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Observing Resources in CoAP > Author(s) : K. Hartke, C. Bormann > Filename : draft-hartke-coap-observe-01.txt > Pages : 29 > Date : 2010-07-08 >=20 > The state of a resource can change over time. We want to give > clients of the CoRE WG CoAP protocol the ability to observe this > change. This short I-D provides an example design for such an > addition to CoAP, in order to be able to discuss the design > alternatives in specific terms. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hartke-coap-observe-01.txt From hariharasudhan.tce@gmail.com Tue Jul 13 02:20: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 B1A333A6A5D for ; Tue, 13 Jul 2010 02:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 Rf1WEAbSTsF4 for ; Tue, 13 Jul 2010 02:20:56 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E5EE63A6A5B for ; Tue, 13 Jul 2010 02:20:55 -0700 (PDT) Received: by iwn38 with SMTP id 38so5914968iwn.31 for ; Tue, 13 Jul 2010 02:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=DbHaDGlWNlIZgzKdKzmv/TPbKi+9OfaSy4MJmG/pDnY=; b=h7LKyv4TNrW0adchdYH2UDsk4yZ0dA78fuifuFh354/aODhKMnxZf4Ldw0KCS87Rgp Xqxu8G1yCfIanfDCVOIH/Mg75ITlQaz7tx9oRIeyM6IY1NKPiY0EC0wyJ/BdJGjnDqyH +XhWfJjfY+oojo66ymW6UzlITlub8/U4eYPg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RwYSTt/WRG52l432WMJlP3gS7/cXCG2g4DwbH6PSCqQLwa75LGGgGhcq2+5wu7g6sS 7sih/GbeFx+nw1lAC1PrmKzlBQPy7BbyTFWsb6Al0RTDzFX5caFL0ktfVGMLBA0plTFB PKjTuTeFNYnHZsdtwqa7ZbQBQYe0hXWyhapfY= MIME-Version: 1.0 Received: by 10.231.145.1 with SMTP id b1mr15509440ibv.69.1279012864277; Tue, 13 Jul 2010 02:21:04 -0700 (PDT) Received: by 10.231.15.139 with HTTP; Tue, 13 Jul 2010 02:21:04 -0700 (PDT) Date: Tue, 13 Jul 2010 14:51:04 +0530 Message-ID: From: Hari Hara Sudhan R To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] transaction ID in 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: Tue, 13 Jul 2010 09:20:56 -0000 Hi All, I'm reading through the COAP specification. Who is resposible for creating transaction ID? Will the COAP application provide it as an argument to COAP implementaion or COAP implementation will automatically create a transaction ID for all the requests made? Thanks and Regards, Hari Hara Sudhan R From kerlyn2001@gmail.com Tue Jul 13 05:07: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 C14173A69C9 for ; Tue, 13 Jul 2010 05:07: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 YsYu-3ojCIxq for ; Tue, 13 Jul 2010 05:07:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C39443A69E9 for ; Tue, 13 Jul 2010 05:07:30 -0700 (PDT) Received: by gyh3 with SMTP id 3so3436082gyh.31 for ; Tue, 13 Jul 2010 05:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=rbQNUiXbOfAWhgz2ZdZQBAMRtTpdIpKlthxDS9TKOWs=; b=uCOY3YfBb7Y2/htSqn+xq6R+DMQDeUPWOtbiKRkfvtAHUqnEk+SyxZjoPVAbGT9SNc rDdCx7wYL1MyvLPNugdLlilp94RzOHiQ6+kAFIJ8ZWD2LmIv2O8XOxabaTZGTdv05m5E vlkdWSOEF2BkNnmH6GvkwO36Ly/FJla+KrGEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=l1tKdeOa+57GPPBlFWfG/K0s3KikoDTFGkV5/IqXK0gAVtty2DI4A077RbrjV9yu0w fUtqs8e9tyuazT/g3ipmGAZIptbP84xVLBsP/GwA95be76ohQ8Zsz0rZf12wit6Bx2h2 xNZEyXy1iBg+wl6qA6fK4Hma6C5UBLH+sbXlE= MIME-Version: 1.0 Received: by 10.90.66.8 with SMTP id o8mr9556187aga.180.1279022851188; Tue, 13 Jul 2010 05:07:31 -0700 (PDT) Received: by 10.90.117.6 with HTTP; Tue, 13 Jul 2010 05:07:31 -0700 (PDT) In-Reply-To: <20100711115331.D6B983A694E@core3.amsl.com> References: <20100711115331.D6B983A694E@core3.amsl.com> Date: Tue, 13 Jul 2010 08:07:31 -0400 Message-ID: From: Kerry Lynn To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-bc-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, 13 Jul 2010 12:07:31 -0000 Greetings, Jerry Martocci et al. have submitted an update to "Commercial Building Application Requirements": http://www.ietf.org/internet-drafts/draft-martocci-6lowapp-building-applica= tions-01.txt and Peter van der Stock et al. and I have submitted "CoAP Utilization for Building Control" which is a first attempt at describing a CoAP example for this application: http://www.ietf.org/id/draft-vanderstok-core-bc-01.txt The links to drafts marked "new" on the core status pages seem to be giving some difficulty this morning, but the links above should work. Happy reading, Kerry Lynn (for the authors) A new version of I-D, draft-vanderstok-core-bc-01.txt has been successfully submitted by Peter Van der Stok and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-vanderstok-core-bc Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 CoAP Utilization for Building Control Creation_date: =A0 2010-07-09 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 18 Abstract: This I-D describes an example use of the RESTful CoAP protocol for building control applications such as HVAC and lighting. =A0A few basic design assumptions are stated first. =A0The URI structure is exploited to define multicast as well as unicast scopes. =A0RFC 3986 defines the URI components as (1) a scheme, (2) an authority, used here to locate the building, area, or node under control, (3) a path, used here to locate the resource under control, and (4) a query and fragment part, where fragments are not supported in CoAP. This proposal supports the view that (1) building control is likely to move in steps toward all-IP control networks based on the legacy efforts provided by DALI, LON, BACnet, ZigBee, and other standards, (2) service discovery is complimentary to resource discovery and facilitates control network scaling, and (3) the provision of a reliable group communication protocol is essential to support building control applications. The IETF Secretariat. From fluffy@cisco.com Tue Jul 13 09:16:02 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 E85E33A681E for ; Tue, 13 Jul 2010 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.351 X-Spam-Level: X-Spam-Status: No, score=-110.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxRVjq5QT-XZ for ; Tue, 13 Jul 2010 09:16:02 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F032C3A6A5C for ; Tue, 13 Jul 2010 09:16:01 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGUuPExAZnwM/2dsb2JhbACfZHGlPppghScEiE0 X-IronPort-AV: E=Sophos;i="4.55,196,1278288000"; d="scan'208";a="131865463" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2010 16:15:47 +0000 Received: from ams3-vpn-dhcp5740.cisco.com (ams3-vpn-dhcp5740.cisco.com [10.61.86.107]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6DGDeKJ017728; Tue, 13 Jul 2010 16:15:44 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 13 Jul 2010 17:15:46 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <006FEB08D9C 6444AB014105C9AEB133FFE28C51DDA@il-ex01.ad.checkpoint.com> <174284C1-A73B-48C4-A68C-23E2F1C3CD58@tzi.org> To: core X-Mailer: Apple Mail (2.1081) Subject: [core] Maastricht CoRE plugfest 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 Jul 2010 16:16:03 -0000 The plugfest session will happen in the 0.6 Madrid room. Cullen From marcvale@cisco.com Wed Jul 14 00:48:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5451A3A6855 for ; Wed, 14 Jul 2010 00:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.178 X-Spam-Level: X-Spam-Status: No, score=-9.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYwkKSXUSU9r for ; Wed, 14 Jul 2010 00:48:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4A5CE3A6861 for ; Wed, 14 Jul 2010 00:48:24 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4101 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwFAFMIPUxAZnwM/2dsb2JhbACBRJFhjEJxpEGaVwKFIgSLBA X-IronPort-AV: E=Sophos;i="4.55,200,1278288000"; d="gif'147?p7s'147?scan'147,208,217,147";a="132155725" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2010 07:48:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6E7mNqx000055 for ; Wed, 14 Jul 2010 07:48:33 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 09:48:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jul 2010 09:48:28 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0068_01CB2339.B5DEB2D0" Message-ID: <1B1C4BD9D5034E42B736327F0D4FB2C501E5D777@XMB-AMS-113.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Service Discovery for constrained devices Thread-Index: AcsjKPJOQjzyBrEJQryLxR4Mm/F4pA== From: "Marco Valente (marcvale)" To: X-OriginalArrivalTime: 14 Jul 2010 07:48:29.0430 (UTC) FILETIME=[F3182160:01CB2328] Subject: [core] Service Discovery for constrained devices 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 Jul 2010 07:48:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0068_01CB2339.B5DEB2D0 Content-Type: multipart/related; boundary="----=_NextPart_001_0069_01CB2339.B5DEB2D0" ------=_NextPart_001_0069_01CB2339.B5DEB2D0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_006A_01CB2339.B5DEB2D0" ------=_NextPart_002_006A_01CB2339.B5DEB2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 Yesterday I had a look to the new draft-vanderstok-core-bc-01. I think = the proposed approach for using DNS-SD in combination with coap is quite interesting (section 7.), and it looks in line with the CoAP = specifications (section 6.2.). Now a couple of general questions came up to my mind. First, both section 6.2. of coap-01 and draft-vanderstok-core-bc-01 = raise some attention on service discovery (finding IP address, port and = protocol of an unknown service), while so far the focus of the WG has more been = on resource discovery (fine-grained discovery of resource URIs offered = within a web service). Is the evaluation, selection and deployment of a service discovery protocol for constrained networks within the scope of this = working group? I have the impression this is a topic which is quite compelling = and may need some design=85 Second, would SLP (or a subset of it) represent a valid alternative to DNS-SD?=20 =20 Kind regards, Marco Valente =20 http://www.cisco.com/swa/i/logo.gif Marco Valente Corporate Development Technology Group marcvale@cisco.com Phone: +41 21 822 1686 Mobile: +41 79 570 9430 Cisco Systems International S=E0rl Avenue des Uttins 5 1180 Rolle - Vaud Switzerland www.cisco.com =20 =20 Think before you print.Think before you print. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------=_NextPart_002_006A_01CB2339.B5DEB2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Yesterday I had a look to the new draft-vanderstok-core-bc-01. I think the proposed approach for using = DNS-SD in combination with coap is quite interesting (section 7.), and it looks in = line with the CoAP specifications (section 6.2.). Now a couple of general = questions came up to my mind.

First, both section 6.2. of coap-01 and draft-vanderstok-core-bc-01 raise some attention on service discovery = (finding IP address, port and protocol of an unknown service), while so far the = focus of the WG has more been on resource discovery (fine-grained discovery of = resource URIs offered within a web service). Is the evaluation, selection and = deployment of a service discovery protocol for constrained networks within the = scope of this working group? I have the impression this is a topic which is quite compelling and may need some design…

Second, would SLP (or a subset of it) represent a = valid alternative to DNS-SD?

 

Kind regards,

Marco Valente

 

3D"http://www.cisco.com/swa/i/logo.gif"

= Marco Valente

Corporate Development Technology = Group=
marcvale@cisco.com=
Phone: +41 21 822 1686
Mobile: +41 79 570 9430

= Cisco Systems International S=E0rl
Avenue des Uttins 5
1180 Rolle - Vaud
Switzerland
www.cisco.com<= span = style=3D'font-size:8.5pt;font-family:"Arial","sans-serif";color:#666666'>=

 

 

3D"ThinkThink before you print.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/in= dex.html=


 

------=_NextPart_002_006A_01CB2339.B5DEB2D0-- ------=_NextPart_001_0069_01CB2339.B5DEB2D0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------=_NextPart_001_0069_01CB2339.B5DEB2D0 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_001_0069_01CB2339.B5DEB2D0-- ------=_NextPart_000_0068_01CB2339.B5DEB2D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVDCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMYwggOuoAMCAQICEEjBQtuPLj9lJ2EGXJe9kLowDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEWMBQGA1UEAxQNTWFyY28gVmFsZW50ZTEhMB8GCSqG SIb3DQEJARYSbWFyY3ZhbGVAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCc KJxdLCcOEjEsU2197IiK+QxzEy6w8USnL3d5g3l92qtMieXH46XtoKzqg9JPnHCQO8HQ4COD1U88 P7GrpNWmEvuUvIHBNDrUtYLSwcF0hkIntQXw7+uLR2ZHLKPp0Ltj4lNyIBheWA0831zLz8Vv/KZ0 UzgDlkx6iQt+wUF7JQIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0 cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0G CSqGSIb3DQEBBQUAA4IBAQAH5b54SLsFjwghjN3UepYmNENo/ouASi4+PwBeWpdElhopBK3mZkmo JkRNSUfT4gIZU0mfNI8RGGpKA6EcW92/kbnCsqi9jsozWt44+Wfp/HcGluGwKWb+hGZ2+1FOLVpv cG3DIP/AqkfBlviUkdpdbBH02hTMKRBEGWIPPD55PdxxOtQwIXCDnEygithA5698kD6sOttcMg2u hKVdq62fin0wJAtKf4EdJr3ix3c/1Xy/4aXE8FsnWTggXlTdyxiW2DO1ROkux0ZcJXulFHX9j5lP FlAFtyrsoEgph9QEgGs4DC7v0UnOcsBoD4qv0LSCwNn5GjByIYzKFqu4CruYMYIEczCCBG8CAQEw gfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQ SMFC248uP2UnYQZcl72QujAJBgUrDgMCGgUAoIIC1jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xMDA3MTQwNzQ4MjhaMCMGCSqGSIb3DQEJBDEWBBSOTdMdpdV7YKmQ s3JPU6Mms6r+wDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0C BTCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhBIwULbjy4/ZSdhBlyXvZC6MIIBBQYLKoZIhvcNAQkQAgsxgfWg gfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQ SMFC248uP2UnYQZcl72QujANBgkqhkiG9w0BAQEFAASBgAo/IY2CHlIWUQSiS34YvUZFTUGsqeGm V9RUcK9jFzHiXjFlo9jxrVW79Obtq2nK5w5oesZXVmAIlR5z6Z68M+d0fUFw7Hv+0TVDl4Gb3xOw IltyKzVu85AfZil0d4CL+U0/8WKff4ISxM4QowbOnFN9a3WH9ODj/5ovQgrctnGxAAAAAAAA ------=_NextPart_000_0068_01CB2339.B5DEB2D0-- From klaus.hartke@googlemail.com Wed Jul 14 02:46: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 CC1E83A67C2 for ; Wed, 14 Jul 2010 02:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, 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 SOFpbNAfJYmh for ; Wed, 14 Jul 2010 02:46:23 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9CBC03A659C for ; Wed, 14 Jul 2010 02:46:23 -0700 (PDT) Received: by bwz7 with SMTP id 7so4307072bwz.31 for ; Wed, 14 Jul 2010 02:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=iYNx8gBM7JQt/hF/pO833spFBJxHiQL1xacw5lDmF/Q=; b=nNMPkU1y16xzbH2J9/8JmHVfGBRN/kuciRJ/sEzbQ1AXNrETZY6CwkKNVxp3NgPhH/ 3jAOvGyjkZdypAuL6HtpU12mQBvSmnX+gnNrIwfuMJcDDFqIkhnQ+dDXz4541i81VyS+ YbLwRmv5197jJzW5O6TSJ0uTpBfVLN09/Ia/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=r5f+M8D5Bucg4GXxOCCyXUt/IozrvzylPoUqq6/0sV6hs3MxPPui0t9qo1Z5AEgYTd bLtej3lRZn3s5zoWPa69L9bguGpovfganZAWW1YlI5a0V62PgrHxujPv7LuZN1ACbuYW zdJyqWYqj+GzYxb+Wyhi9SIipKO6IqC6Bi88Q= MIME-Version: 1.0 Received: by 10.204.75.81 with SMTP id x17mr7164851bkj.72.1279100786904; Wed, 14 Jul 2010 02:46:26 -0700 (PDT) Received: by 10.204.101.78 with HTTP; Wed, 14 Jul 2010 02:46:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 11:46:26 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] transaction ID in COAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 09:46:24 -0000 On 13 July 2010 11:21, Hari Hara Sudhan R wrote: > I'm reading through the COAP specification. > Who is resposible for creating transaction ID? The node that sends a confirmable (or non-confirmable) message. A node that receives a confirmable message just echoes the transaction ID in its acknowledgement/reset. > Will the COAP application provide it as an argument to COAP > implementaion or COAP implementation will automatically create > a transaction ID for all the requests made? The CoAP application "thinks" in REST and should not be aware of the CoAP Transactions layer. So having the CoAP implementation automatically create the transaction ID for all requests made sounds like a good idea. (This is also what coap-01 section 2.2.5. indicates; have a look at that section for requirements on how a transaction ID should be created.) Klaus From pab@peoplepowerco.com Thu Jul 15 19:42:02 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 71B4B3A6822 for ; Thu, 15 Jul 2010 19:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAYWceVxHcMg for ; Thu, 15 Jul 2010 19:42:00 -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 D56623A63D3 for ; Thu, 15 Jul 2010 19:41:59 -0700 (PDT) Received: by vws14 with SMTP id 14so2085701vws.31 for ; Thu, 15 Jul 2010 19:42:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.121.233 with SMTP id i41mr162453vcr.3.1279248124597; Thu, 15 Jul 2010 19:42:04 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Thu, 15 Jul 2010 19:42:04 -0700 (PDT) Date: Thu, 15 Jul 2010 21:42:04 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=001636d33e9e0bd760048b782a30 Subject: [core] format of id and n link params 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 Jul 2010 02:42:02 -0000 --001636d33e9e0bd760048b782a30 Content-Type: text/plain; charset=ISO-8859-1 In coap-01 section 6.1, the id link param is defined to have a value conforming to "integer", but "integer" is not defined in the grammar in that section, nor in RFC5234, nor in nottingham-http-link-header, that I can find. The descriptive text says "e.g. UUID", but UUIDs are rarely expressed in text as (decimal) integers. What is the structure of the id link parameter? If it's an ASCII decimal integer, is there a limit on its magnitude? Similarly, "string" as used for the instance name link parameter should be clarified. Section 6.2 says it "can be considered the 'Instance' part of a DNS-SD name", but that's not very rigorous. If that's the intent, cheshire-dnsext-dns-sd section 7.2 implies it has a 63-byte length limitation, and if one follows the reference trail long enough, one might conclude it's a "character-string" as defined in RFC1035 section 5.1. But I'm not sure that's what we want, as it allows arbitrary characters to appear within double quotes, which might make tokenizing the link value unnecessarily painful. Peter --001636d33e9e0bd760048b782a30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In coap-01 section 6.1, the id link param is defined to have a value confor= ming to "integer", but "integer" is not defined in the = grammar in that section, nor in RFC5234, nor in nottingham-http-link-header= , that I can find.

The descriptive text says "e.g. UUID", but UUIDs are rarely e= xpressed in text as (decimal) integers.

What is the structure of the= id link parameter?=A0 If it's an ASCII decimal integer, is there a lim= it on its magnitude?

Similarly, "string" as used for the instance name link parame= ter should be clarified.=A0 Section 6.2 says it "can be considered the= 'Instance' part of a DNS-SD name", but that's not very ri= gorous.=A0 If that's the intent, cheshire-dnsext-dns-sd section 7.2 imp= lies it has a 63-byte length limitation, and if one follows the reference t= rail long enough, one might conclude it's a "character-string"= ; as defined in RFC1035 section 5.1.=A0 But I'm not sure that's wha= t we want, as it allows arbitrary characters to appear within double quotes= , which might make tokenizing the link value unnecessarily painful.

Peter
--001636d33e9e0bd760048b782a30-- From fluffy@cisco.com Thu Jul 15 23:02:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23CD3A68AF for ; Thu, 15 Jul 2010 23:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3k+3fP0h1UV for ; Thu, 15 Jul 2010 23:02:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 167023A67A4 for ; Thu, 15 Jul 2010 23:02:55 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPSSP0yrR7H+/2dsb2JhbACfa3GjfppVhSQEg36EUg X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208";a="559888957" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2010 06:03:05 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6G6345A025252; Fri, 16 Jul 2010 06:03:05 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 00:03:04 -0600 Message-Id: <29FD2178-FAF2-4122-B571-362F8ADF3324@cisco.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Draft Agenda for IETF 78 CORE WG 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 Jul 2010 06:02:59 -0000 The following agenda is my wishful thinking of the the agenda I wish we = could have. The main problem with it is that is is roughly and hour or = so more than we have (assuming a few things go over as usual). The = agenda below will change - and we probably need to reduce the number of = drafts we try to cover in this meeting as well as reduce the length of = time of some of the sections.=20 What Carsten and I need is input from folks on what are the really key = parts that we really can not remove from this meeting as well as the = parts we can't make any shorter. Help us get the agenda so it represents = what the WG needs to make good progress. Recognize that we don't have to = solve all the problems in this meeting and even it something does not = get agenda time, decisions can be made on the mailing list and there are = future meetings.=20 I have been in other WG meetings where there was so little time for each = topic that absolutely no decisions were made and no progress was made. I = really don't want to have that. ------------ Draft Agenda v1=20 This agenda is likely to change as we figure out how to devote more time = to the key topics. You will note the times below add up to much more = time than we have.=20 Status Update & Administrative - 10 min (Chairs)=20 =20 Base CoAP Protocol - 40 min (Zach) draft-ietf-core-coap-01.txt Subscriptions Options - 30 min (Klaus) draft-hartke-coap-observe-01 CoAP Miscellaneous Changes - 20 min (Carsten) draft-bormann-coap-misc-05 Congestion Control - 20 min (Lars) draft-eggert-core-congestion-control-00 HTTP Mapping - 15 min (Zach) No draft on this Sleeping Nodes - 15 min (Akbar) draft-rahman-core-sleeping-00 Bootstrap Approach - 15 min (Colin) draft-oflynn-core-bootstrapping-01 CoAP Usage - 20 min (TBD 1 or 2 people)=20 draft-vanderstok-core-bc-01 draft-braun-core-compressed-ipfix-01 From salvatore.loreto@ericsson.com Fri Jul 16 04:29:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0DE3A698D for ; Fri, 16 Jul 2010 04:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 vG85a2xfbcMQ for ; Fri, 16 Jul 2010 04:29:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BADCE3A6944 for ; Fri, 16 Jul 2010 04:29:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-9d-4c404291f216 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EA.38.10125.192404C4; Fri, 16 Jul 2010 13:29:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 13:28:33 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 13:16:47 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 60F1F24BC; Fri, 16 Jul 2010 14:16:47 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 210444FBC9; Fri, 16 Jul 2010 14:16:47 +0300 (EEST) Received: from n166.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CDB1C4F631; Fri, 16 Jul 2010 14:16:46 +0300 (EEST) Message-ID: <4C403F9E.8040909@ericsson.com> Date: Fri, 16 Jul 2010 14:16:46 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Angelo P. Castellani" , core@ietf.org References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 16 Jul 2010 11:16:47.0600 (UTC) FILETIME=[61690700:01CB24D8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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: Fri, 16 Jul 2010 11:29:13 -0000 in line /Sal On 6/24/10 1:00 PM, Angelo P. Castellani wrote: > I like a lot your contribution on congestion control (totally missing). > > Transmission credits and RTT estimation are two important improvements > to CoAP in my opinion... > > Just a note, you define in your document that there is an aggregate > limit on the outstanding number of transactions that a node can > produce.. I was wondering if this congestion control technique is > leaving two problems open: > > a) A CoAP server provides 1/many "popular" resources. Many clients may > send concurrent requests to the server, and the server concurrent > responses. > > The responses should be concurring to the "tx credit"? (in my opinion yes) > [Sal] Section 3.1.2 of [RFC5405] recommends that such application protocols: -employ congestion control for both directions of a bi-directional communication so I also think that the right answer is yes. > The server cannot directly know whether the sent response has been > received, how can responses partecipate to the Reno-like AIMD scheme > depicted in the document? (in my opinion a response can be considered > to be "correctly received" if the server doesn't receive in the > subsequent time window of X seconds a retransmission of the served > request) > > b) "big-I" Internet<-> Constrained nodes island intercommunication is > *probably* a congestion bottleneck that is harder to handle. Is this > scheme sufficient to handle congestion on a highly congested path that > may be formed by very constrained relays? > [Sal] that in some way means an interaction between the TCP congestion control and the CoAP one... > I suspect that handling these problems may lead to very specific > discussion on transport that is probably out-of-scope in this WG. > > Regards, > Angelo From salvatore.loreto@ericsson.com Fri Jul 16 05:54: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 7616D3A692C for ; Fri, 16 Jul 2010 05:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 QYkOb2fbP5MH for ; Fri, 16 Jul 2010 05:54:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2049C3A695D for ; Fri, 16 Jul 2010 05:54:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-8b-4c4056a665cd Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3F.31.10125.6A6504C4; Fri, 16 Jul 2010 14:55:02 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 14:54:34 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 14:51:36 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9DACE24BC for ; Fri, 16 Jul 2010 15:51:36 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 695DD4FC0C for ; Fri, 16 Jul 2010 15:51:36 +0300 (EEST) Received: from n166.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2A0F74FBFB for ; Fri, 16 Jul 2010 15:51:36 +0300 (EEST) Message-ID: <4C4055D8.7050504@ericsson.com> Date: Fri, 16 Jul 2010 15:51:36 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: core@ietf.org References: <20100708193026.8FDCF3A6B5D@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 16 Jul 2010 12:51:36.0839 (UTC) FILETIME=[A0760170:01CB24E5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Fwd: I-D Action:draft-hartke-coap-observe-01.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: Fri, 16 Jul 2010 12:54:52 -0000 Hi there, in section 4. "HTTP mapping" As long as the resource state hasn’t changed, the proxy holds the request and waits for the resource to change, instead of sending an empty (304) response. however the presence of unknown timeouts values anywhere in the path between client, server and also in any proxy present along the path implies that sometime the answer can not wait as long as it that for the resource to change, but an empty (304) response have to be sent anyway. http://www.ietf.org/id/draft-loreto-http-timeout-00.txt is a first proposal on how to deal with timeout during a long poll request. cheers /Sal On 7/8/10 10:41 PM, Carsten Bormann wrote: > Klaus and I have added a fleshed-out minimal specification to the draft so we can discuss this in more specific terms. > (We haven't really had time to update the existing text, which is now maintained as the rationale in an appendix -- maybe we can manage to do this before the I-D cutoff.) > > Now I would love to have time to implement that... > > Gruesse, Carsten > > Begin forwarded message: > > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Observing Resources in CoAP >> Author(s) : K. Hartke, C. Bormann >> Filename : draft-hartke-coap-observe-01.txt >> Pages : 29 >> Date : 2010-07-08 >> >> The state of a resource can change over time. We want to give >> clients of the CoRE WG CoAP protocol the ability to observe this >> change. This short I-D provides an example design for such an >> addition to CoAP, in order to be able to discuss the design >> alternatives in specific terms. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hartke-coap-observe-01.txt >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- Salvatore Loreto www.sloreto.com From salvatore.loreto@ericsson.com Fri Jul 16 08:44: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 E11693A6A67 for ; Fri, 16 Jul 2010 08:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 bKDwpwLh-Slz for ; Fri, 16 Jul 2010 08:44:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 79A1A3A6A31 for ; Fri, 16 Jul 2010 08:44:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-09-4c407e600e7d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 09.71.10125.06E704C4; Fri, 16 Jul 2010 17:44:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 17:44:32 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 17:44:32 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 47B7624BC; Fri, 16 Jul 2010 18:44:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 09F4B4FC0C; Fri, 16 Jul 2010 18:44:32 +0300 (EEST) Received: from cs78166197.pp.htv.fi (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A7DB14FBFB; Fri, 16 Jul 2010 18:44:31 +0300 (EEST) Message-ID: <4C407E5F.7070500@ericsson.com> Date: Fri, 16 Jul 2010 18:44:31 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Carsten Bormann References: <20100708193026.8FDCF3A6B5D@core3.amsl.com> <4C4055D8.7050504@ericsson.com> <8A7C764E-231A-41B8-86E3-0271A9FC475C@tzi.org> In-Reply-To: <8A7C764E-231A-41B8-86E3-0271A9FC475C@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 16 Jul 2010 15:44:32.0772 (UTC) FILETIME=[C8FFBC40:01CB24FD] X-Brightmail-Tracker: AAAAAA== Cc: "core@ietf.org" Subject: Re: [core] Fwd: I-D Action:draft-hartke-coap-observe-01.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: Fri, 16 Jul 2010 15:44:29 -0000 On 7/16/10 4:27 PM, Carsten Bormann wrote: >> http://www.ietf.org/id/draft-loreto-http-timeout-00.txt is a first >> proposal on how to deal with timeout during a >> long poll request. >> > Salvatore, > > these new headers appear to be interesting optimizations. > In my previous work that used long-polling I have never found an absolute need to solve the problems you are noting, though. > I also think it would be dangerous to have an HTTP mapping that relies on new features that aren't universally deployed today. > > So if your proposal is picked up on the HTTP side, what do you think should be the transition strategy? > I am not suggesting to use the header(s) proposed in the draft, the draft was just a pointer to better explain the fact that in the HTTP side the long delay in an answer (in this case in a long polling request) can cause time-out (in the client or in an intermediary) making impossible deliver the answer once the server has one to provide back to the client. That is something that IMO is worth to be mentioned in the draft. /Sal -- Salvatore Loreto www.sloreto.com > (As far as I can see, there is no impact on the CoAP side, just potentially on the preferred headers used by an HTTP mapper.) > > Gruesse, Carsten > > From cabocabo@gmail.com Fri Jul 16 12:12:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C572B3A69A1 for ; Fri, 16 Jul 2010 12:12:23 -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 pBpvJwgYnlvm for ; Fri, 16 Jul 2010 12:12:17 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A10DA3A6824 for ; Fri, 16 Jul 2010 12:12:16 -0700 (PDT) Received: by bwz7 with SMTP id 7so1649852bwz.31 for ; Fri, 16 Jul 2010 12:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:date:subject:to:message-id:mime-version :x-mailer; bh=Dm1gPIXsPBX9yjV/fLUlP7I6a/7YRz3Ix2i4ird4FaQ=; b=LwXjuS7QXAdA6wgoSjWge1jHTX87mdDEjQ/nVtcxcoTr/bjyeZE21hXY7dAnPMtnGJ pDIShckT0CFFXpii57A3zW6vwikeyyzif0wzqpLuSW42J0S0OnkFOO0w/wGiFAJi42/c f5K75ri0NSxxdFfqLAClljoLJBSWL9cRs44H8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; b=QtMU9FkoQCuK5HcmOh3+qzLzMj1EhDEcvNMLSLcLyQ2PAmj57ceL2KI8uP+c612CjO WUq66ZY9FbNn+C5t5woZJ+ZprWwdvbO9aBkjS68lGJW60C6RKt8grFdTaQjCfPROlX9J y5UiOOPASxwJmNpeSoeBGIwm3DzcwjW6YmM38= Received: by 10.204.9.146 with SMTP id l18mr1267800bkl.16.1279307544305; Fri, 16 Jul 2010 12:12:24 -0700 (PDT) Received: from [192.168.217.101] (p5489DA79.dip.t-dialin.net [84.137.218.121]) by mx.google.com with ESMTPS id o20sm12155223bkw.15.2010.07.16.12.12.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 12:12:22 -0700 (PDT) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 21:12:20 +0200 To: core Message-Id: <594D5189-924F-4773-973D-753E866E234D@tzi.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 16 Jul 2010 12:16:07 -0700 Subject: [core] First pre-Plugfest Plugfest completed 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 Jul 2010 19:12:23 -0000 Within TZI, we currently have four CoAP implementations (in C, C#, = Python, Ruby). We had a little meeting today to run all of them against each other. Angelo Castellani also briefly joined from remote with a fifth = implementation on a Telosb mote. This was all very ad-hoc, unprepared, but we were able to test basic = GET, basic PUT, retransmissions/backoff, short and long options, the = block option, and some error handling. Klaus will take what we learned and create a proposed test procedure for = one-on-one testing in Maastricht on Sunday 10-16. BTW, we plan to do a third plugfest in the Wed 1300-1530 slot, very = ad-hoc in the terminal room. Just wanted to let you know... Gruesse, Carsten From cabo@tzi.org Fri Jul 16 21:40:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533613A67D7 for ; Fri, 16 Jul 2010 21:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyWXHxe3wzwI for ; Fri, 16 Jul 2010 21:40:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id D70883A67F0 for ; Fri, 16 Jul 2010 21:40:27 -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 o6GGfDBi017363 for ; Fri, 16 Jul 2010 18:41:13 +0200 (CEST) Received: from [134.102.2.187] (unknown [134.102.2.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 3A406B403; Fri, 16 Jul 2010 18:41:13 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 18:41:12 +0200 To: core Message-Id: <8D2C8223-95F4-4DDC-B186-D8D60F160CE6@tzi.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] First pre-Plugfest Plugfest completed 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, 17 Jul 2010 04:40:29 -0000 Within TZI, we currently have four CoAP implementations (in C, C#, = Python, Ruby). We had a little meeting today to run all of them against each other. Angelo Castellani also briefly joined from remote with a fifth = implementation on a Telosb mote. This was all very ad-hoc, unprepared, but we were able to test basic = GET, basic PUT, retransmissions/backoff, short and long options, the = block option, and some error handling. Klaus will take what we learned and create a proposed test procedure for = one-on-one testing in Maastricht on Sunday 10-16. BTW, we plan to do a third plugfest in the Wed 1300-1530 slot, very = ad-hoc in the terminal room. Just wanted to let you know... Gruesse, Carsten From cabo@tzi.org Fri Jul 16 21:40: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 0A9CB3A68A0 for ; Fri, 16 Jul 2010 21:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anR-tnHLDokM for ; Fri, 16 Jul 2010 21:40:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id C93E53A6857 for ; Fri, 16 Jul 2010 21:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6GDS0PL007100; Fri, 16 Jul 2010 15:28:00 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 54D9EBFB7; Fri, 16 Jul 2010 15:28:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4C4055D8.7050504@ericsson.com> Date: Fri, 16 Jul 2010 15:27:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A7C764E-231A-41B8-86E3-0271A9FC475C@tzi.org> References: <20100708193026.8FDCF3A6B5D@core3.amsl.com> <4C4055D8.7050504@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Fwd: I-D Action:draft-hartke-coap-observe-01.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: Sat, 17 Jul 2010 04:40:31 -0000 > http://www.ietf.org/id/draft-loreto-http-timeout-00.txt is a first > proposal on how to deal with timeout during a > long poll request. Salvatore, these new headers appear to be interesting optimizations. In my previous work that used long-polling I have never found an = absolute need to solve the problems you are noting, though. I also think it would be dangerous to have an HTTP mapping that relies = on new features that aren't universally deployed today. So if your proposal is picked up on the HTTP side, what do you think = should be the transition strategy? (As far as I can see, there is no impact on the CoAP side, just = potentially on the preferred headers used by an HTTP mapper.) Gruesse, Carsten From pab@peoplepowerco.com Sat Jul 17 10:46: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 F10083A6892 for ; Sat, 17 Jul 2010 10:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.082 X-Spam-Level: X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0UFfOwM20Yg for ; Sat, 17 Jul 2010 10:46:28 -0700 (PDT) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by core3.amsl.com (Postfix) with ESMTP id 801183A67EC for ; Sat, 17 Jul 2010 10:46:28 -0700 (PDT) Received: by vws19 with SMTP id 19so4850412vws.27 for ; Sat, 17 Jul 2010 10:46:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.213 with SMTP id z21mr1557496vcn.141.1279388800333; Sat, 17 Jul 2010 10:46:40 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Sat, 17 Jul 2010 10:46:40 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Jul 2010 12:46:40 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=0016e6475534f93aa3048b98ea9f Subject: Re: [core] format of id and n link params 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, 17 Jul 2010 17:46:30 -0000 --0016e6475534f93aa3048b98ea9f Content-Type: text/plain; charset=ISO-8859-1 In response to my own question, the following proposed clarifications: I believe 6.2 needs to be more resolute about whether the n= attribute is intended to be the "Instance" part of a DNS-SD name, and what to do about non-default "Service" and "Domain" parts. This has syntactic and semantic impact. Syntactically, if it is such a name, it technically may comprise 1 to 63 octets with values above 0x1f, including commas, semicolons, and dots. Suggest providing a grammar rule for "string" that is more restricted in allowed characters. Perhaps: string = 1*( ptokenchar | SP ) A length limitation is also required for its use in n=. The current text of 6.2 suggests default values for "Service" and "Domain" and implies different values may be provided, but does not describe how to determine their presence or absence given that dot is a valid character within a DNS label. Suggest adding an attribute sd= which, if present, must provide the "Service" and "Domain" per section 7 of [I-D.cheshire-dnsext-dns-sd], excluding the terminating root label. If absent, the value of the sd= attribute is assumed to be "_coap._udp.local". I hold no opinion on whether this should be split into sds= and sdd= to allow independent specification of "Service" (default "_coap._udp") and "Domain" (default "local"). For parmname, reference [I-D.reschke-rfc2231-in-http] or explicitly define it: parmname = 1*attr-char attr-char = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" ; token except ( "*" / "'" / "%" ) I suspect a length limitation SHOULD be suggested for parmname, as the implementation must be able to use these as keys. Suggest that id= be defined to have a value conforming to string, rather like ETag in that it is not interpretable but different in that it is not limited to 4 octets in length. Unless there's a particular need for it to be an integer for ordinal comparisons in some use case? Peter On Thu, Jul 15, 2010 at 9:42 PM, Peter Bigot wrote: > In coap-01 section 6.1, the id link param is defined to have a value > conforming to "integer", but "integer" is not defined in the grammar in that > section, nor in RFC5234, nor in nottingham-http-link-header, that I can > find. > > The descriptive text says "e.g. UUID", but UUIDs are rarely expressed in > text as (decimal) integers. > > What is the structure of the id link parameter? If it's an ASCII decimal > integer, is there a limit on its magnitude? > > Similarly, "string" as used for the instance name link parameter should be > clarified. Section 6.2 says it "can be considered the 'Instance' part of a > DNS-SD name", but that's not very rigorous. If that's the intent, > cheshire-dnsext-dns-sd section 7.2 implies it has a 63-byte length > limitation, and if one follows the reference trail long enough, one might > conclude it's a "character-string" as defined in RFC1035 section 5.1. But > I'm not sure that's what we want, as it allows arbitrary characters to > appear within double quotes, which might make tokenizing the link value > unnecessarily painful. > > Peter > --0016e6475534f93aa3048b98ea9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In response to my own question, the following proposed clarifications:
<= br>I believe 6.2 needs to be more resolute about whether the n=3D attribute= is intended to be the "Instance" part of a DNS-SD name, and what= to do about non-default "Service" and "Domain" parts.= =A0 This has syntactic and semantic impact.

Syntactically, if it is such a name, it technically may comprise 1 to 6= 3 octets with values above 0x1f, including commas, semicolons, and dots.=A0= Suggest providing a grammar rule for "string" that is more restr= icted in allowed characters.=A0 Perhaps:

=A0=A0=A0 string=A0= =A0=A0=A0=A0=A0=A0=A0 =3D 1*( ptokenchar | SP )

A length limitation is also required for i= ts use in n=3D.

The current text of 6.2 suggests default values for = "Service" and "Domain" and implies different values may= be provided, but does not describe how to determine their presence or abse= nce given that dot is a valid character within a DNS label.=A0 Suggest addi= ng an attribute sd=3D which, if present, must provide the "Service&quo= t; and "Domain" per section 7 of [I-D.cheshire-dnsext-dns-sd], ex= cluding the terminating root label.=A0 If absent, the value of the sd=3D at= tribute is assumed to be "_coap._udp.local".=A0 I hold no opinion= on whether this should be split into sds=3D and sdd=3D to allow independen= t specification of "Service" (default "_coap._udp") and= "Domain" (default "local").

For parmname, reference [I-D.reschke-rfc2231-in-http] or explicitly def= ine it:

=A0=A0= =A0=A0 parmname=A0=A0=A0=A0=A0 =3D 1*attr-char
=A0=A0=A0=A0 attr-char= =A0=A0=A0=A0 =3D ALPHA / DIGIT
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / "!" / "#&quo= t; / "$" / "&" / "+" / "-" / &q= uot;."
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / "^" / "_" / "`= " / "|" / "~"
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ; token except ( "= *" / "'" / "%" )

I suspect a length limitation SHOULD be suggested for parmname, as the = implementation must be able to use these as keys.

Suggest that id=3D= be defined to have a value conforming to string, rather like ETag in that = it is not interpretable but different in that it is not limited to 4 octets= in length.=A0 Unless there's a particular need for it to be an integer= for ordinal comparisons in some use case?

Peter

On Thu, Jul 15, 2010 at 9:42 PM= , Peter Bigot <pab@peoplepowerco.com> wrote:
In coap-01 section 6.1, the id link param is defined to have a value confor= ming to "integer", but "integer" is not defined in the = grammar in that section, nor in RFC5234, nor in nottingham-http-link-header= , that I can find.

The descriptive text says "e.g. UUID", but UUIDs are rarely e= xpressed in text as (decimal) integers.

What is the structure of the= id link parameter?=A0 If it's an ASCII decimal integer, is there a lim= it on its magnitude?

Similarly, "string" as used for the instance name link parame= ter should be clarified.=A0 Section 6.2 says it "can be considered the= 'Instance' part of a DNS-SD name", but that's not very ri= gorous.=A0 If that's the intent, cheshire-dnsext-dns-sd section 7.2 imp= lies it has a 63-byte length limitation, and if one follows the reference t= rail long enough, one might conclude it's a "character-string"= ; as defined in RFC1035 section 5.1.=A0 But I'm not sure that's wha= t we want, as it allows arbitrary characters to appear within double quotes= , which might make tokenizing the link value unnecessarily painful.

Peter

--0016e6475534f93aa3048b98ea9f-- From pab@peoplepowerco.com Sat Jul 17 17:56:00 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 A9F143A6A28 for ; Sat, 17 Jul 2010 17:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.218 X-Spam-Level: X-Spam-Status: No, score=0.218 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnBrsEy8vnQb for ; Sat, 17 Jul 2010 17:55:59 -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 BEF8A3A6A20 for ; Sat, 17 Jul 2010 17:55:59 -0700 (PDT) Received: by vws14 with SMTP id 14so3921202vws.31 for ; Sat, 17 Jul 2010 17:56:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.5 with SMTP id v5mr1532163vch.221.1279414571253; Sat, 17 Jul 2010 17:56:11 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Sat, 17 Jul 2010 17:56:11 -0700 (PDT) Date: Sat, 17 Jul 2010 19:56:11 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=e0cb4e887ee90a4124048b9eebb6 Subject: [core] link-format clarification: URI-reference as attribute value 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 Jul 2010 00:56:00 -0000 --e0cb4e887ee90a4124048b9eebb6 Content-Type: text/plain; charset=ISO-8859-1 Since comma and semicolon are both valid pchars within a URI per RFC3986, the values of the d= and sh= attributes must be enclosed in angle brackets or double-quotes to avoid ambiguity. The value for these attributes should also probably be URI-reference rather than URI, otherwise the example showing "sh=/l" is not valid as it lacks a scheme. link-param = ( ( "d" "=" <"> URI-reference <"> ) | ( "sh" "=" <"> URI-reference <"> ) ... (Also note the mis-capitalization of URI-reference in the link-value rule.) Peter --e0cb4e887ee90a4124048b9eebb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since comma and semicolon are both valid pchars within a URI per RFC3986, t= he values of the d=3D and sh=3D attributes must be enclosed in angle bracke= ts or double-quotes to avoid ambiguity.=A0 The value for these attributes s= hould also probably be URI-reference rather than URI, otherwise the example= showing "sh=3D/l" is not valid as it lacks a scheme.
=A0
=A0=A0=A0=A0=A0 = link-param=A0=A0=A0=A0=A0=A0=A0 =3D ( ( "d" "=3D" <&= quot;> URI-reference <"> )
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ( &= quot;sh" "=3D" <"> URI-reference <"> )=
=A0=A0=A0=A0=A0 ...

(Also note the mis-capitalization of URI-referen= ce in the link-value rule.)

Peter

--e0cb4e887ee90a4124048b9eebb6-- From pab@peoplepowerco.com Sat Jul 17 17:57:13 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 5A23A3A6A2E for ; Sat, 17 Jul 2010 17:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.257 X-Spam-Level: X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROHgwn9oUmuz for ; Sat, 17 Jul 2010 17:57:12 -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 81A713A6A20 for ; Sat, 17 Jul 2010 17:57:12 -0700 (PDT) Received: by vws14 with SMTP id 14so3921623vws.31 for ; Sat, 17 Jul 2010 17:57:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.200 with SMTP id s8mr1833008vcx.76.1279414645256; Sat, 17 Jul 2010 17:57:25 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Sat, 17 Jul 2010 17:57:25 -0700 (PDT) Date: Sat, 17 Jul 2010 19:57:25 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=001485e0b496737180048b9eef15 Subject: [core] link-format clarification: multiple descriptions in a representation 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 Jul 2010 00:57:13 -0000 --001485e0b496737180048b9eef15 Content-Type: text/plain; charset=ISO-8859-1 coap-01 states that multiple link representations are separated by commas and references [I-D.nottingham-http-link-header]. The details of [I-D.nottingham-http-link-header] and its reliance on the ABNF notation of RFC2616 to define "#link-value" allow LWS to occur before each representation and before the comma separating two representations. The description at the example at the end of section 6.1 implies this is not intended to be true for CoAP. Peter --001485e0b496737180048b9eef15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable coap-01 states that multiple link representations are separated by=20 commas and references [I-D.nottingham-http-link-header].=A0 The details of [I-D.nottingham-http-link-header] and its reliance on the ABNF notation of RFC2616 to define "#link-value" allow LWS to occur before eac= h=20 representation and before the comma separating two representations.=A0 The description at the example at the end of section 6.1 implies this is=20 not intended to be true for CoAP.

Peter
--001485e0b496737180048b9eef15-- From pab@peoplepowerco.com Sat Jul 17 19:53: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 9201F3A6A4A for ; Sat, 17 Jul 2010 19:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.168 X-Spam-Level: X-Spam-Status: No, score=0.168 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN9WhLwN-hFB for ; Sat, 17 Jul 2010 19:53:54 -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 E769C3A6A49 for ; Sat, 17 Jul 2010 19:53:53 -0700 (PDT) Received: by vws18 with SMTP id 18so6770vws.31 for ; Sat, 17 Jul 2010 19:54:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.136 with SMTP id x8mr1591387vch.35.1279421646123; Sat, 17 Jul 2010 19:54:06 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Sat, 17 Jul 2010 19:54:06 -0700 (PDT) Date: Sat, 17 Jul 2010 21:54:06 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=e0cb4e887453bc3191048ba09053 Subject: [core] link-format clarification: multiple media types 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 Jul 2010 02:53:55 -0000 --e0cb4e887453bc3191048ba09053 Content-Type: text/plain; charset=ISO-8859-1 The presence of a comma in the ct= attribute value implies that value also should be quoted to remove ambiguity between a comma separating media types and one separating resource descriptions. Alternatively, remove the option of listing multiple media types for a resource description. Since the Content-Type header option only applies to the body of a message, and there is no Accepts header, there's currently no way to request a resource be provided in a particular media type. Prior discussion on this list from roughly 28Jun2010 implied the requirement to influence the representation format could be satisfied by distinct resource URIs. So supporting exactly one media type in the resource description is sufficient. Peter --e0cb4e887453bc3191048ba09053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The presence of a comma in the ct=3D attribute value implies that value als= o should be quoted to remove ambiguity between a comma separating media typ= es and one separating resource descriptions.

Alternatively, remove t= he option of listing multiple media types for a resource description.=A0 Si= nce the Content-Type header option only applies to the body of a message, a= nd there is no Accepts header, there's currently no way to request a re= source be provided in a particular media type.=A0 Prior discussion on this = list from roughly 28Jun2010 implied the requirement to influence the repres= entation format could be satisfied by distinct resource URIs.=A0 So support= ing exactly one media type in the resource description is sufficient.

Peter
--e0cb4e887453bc3191048ba09053-- From lars.eggert@nokia.com Mon Jul 19 01:04:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6643D3A6992 for ; Mon, 19 Jul 2010 01:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, 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 Z2qDyxJM5TZG for ; Mon, 19 Jul 2010 01:04:47 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E2CBF3A68C1 for ; Mon, 19 Jul 2010 01:04:46 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6J84iC6008465; Mon, 19 Jul 2010 11:04:56 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 11:04:53 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 11:04:51 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6J84nNe026322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 11:04:50 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-83-571772713; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4C403F9E.8040909@ericsson.com> Date: Mon, 19 Jul 2010 11:04:43 +0300 Message-Id: <0B22C2B0-15A4-42F2-9586-CB091B2840D0@nokia.com> References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> <4C403F9E.8040909@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Mon, 19 Jul 2010 11:04:43 +0300 (EEST) X-OriginalArrivalTime: 19 Jul 2010 08:04:51.0082 (UTC) FILETIME=[104516A0:01CB2719] X-Nokia-AV: Clean Cc: "core@ietf.org" Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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: Mon, 19 Jul 2010 08:04:50 -0000 --Apple-Mail-83-571772713 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-7-16, at 14:16, Salvatore Loreto wrote: > On 6/24/10 1:00 PM, Angelo P. Castellani wrote: >> a) A CoAP server provides 1/many "popular" resources. Many clients = may >> send concurrent requests to the server, and the server concurrent >> responses. >>=20 >> The responses should be concurring to the "tx credit"? (in my opinion = yes) >>=20 > [Sal] > Section 3.1.2 of [RFC5405] recommends that such application protocols: > -employ congestion control for both directions of a bi-directional=20 > communication >=20 > so I also think that the right answer is yes. yes, the intent is that the send credits cover any transmission into the = network, whether initiated by a local app or in response to a query from = an app on another node, or even locally generated error messages. >> The server cannot directly know whether the sent response has been >> received, how can responses partecipate to the Reno-like AIMD scheme >> depicted in the document? (in my opinion a response can be considered >> to be "correctly received" if the server doesn't receive in the >> subsequent time window of X seconds a retransmission of the served >> request) Right. How you know that something got successfully delivered (so you = can increase your send credit count for the next time interval) isn't = well-defined at the moment, especially for unreliably transmitted = messages. Another reason this is experimental... >> b) "big-I" Internet<-> Constrained nodes island intercommunication = is >> *probably* a congestion bottleneck that is harder to handle. Is this >> scheme sufficient to handle congestion on a highly congested path = that >> may be formed by very constrained relays? >>=20 > [Sal] that in some way means an interaction between the TCP congestion=20= > control and the CoAP one... The intent is that the proposed send credit scheme is implemented by all = COAP speakers, including those in the big-I Internet. If there is a = translating gateway (e.g. HTTP<->COAP), then it needs to implement the = scheme when sending into the COAP network. Lars= --Apple-Mail-83-571772713 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcxOTA4 MDQ0M1owIwYJKoZIhvcNAQkEMRYEFLaPczx0tnG+WMrFYKMXEFaXoYFyMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAJT2f7e57ZsdmcAhOKelrfpOs8mJQvJpQTT7xPtp6cZs684nP1tG vwEwNYcsRlzLofvaGwzN5/rmfYQsWtDeNtcaBcJSgJjO7AeLF17GzSXu75/yK6kGyXX5EKX6sKKR UmAgDQEM4yLRrnEcOZd1R3iYZP98QYGjiKRvWcedkEpt+1mdT+tpqHW4Htkt6YDbSVl/KRl07xzf rcv5tYknSOLvCo4HPLCgcBUPSkmn7drN8KBsld7MTaKIErvs9/IoeKBam+HNNSOeX2iAHzzq6C8h /vSfRudzmRPImobQQGFMAUQIfazPHOJbBsaSXsbMIRqji67/E9TbxZrKt36aBGQAAAAAAAA= --Apple-Mail-83-571772713-- From pab@peoplepowerco.com Mon Jul 19 15:36: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 A954C3A6BB5 for ; Mon, 19 Jul 2010 15:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKPdFd5DN0yI for ; Mon, 19 Jul 2010 15:36: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 CE0083A6B91 for ; Mon, 19 Jul 2010 15:35:17 -0700 (PDT) Received: by vws16 with SMTP id 16so1352166vws.31 for ; Mon, 19 Jul 2010 15:32:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.169.21 with SMTP id w21mr3627526vcy.62.1279578763469; Mon, 19 Jul 2010 15:32:43 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Mon, 19 Jul 2010 15:32:43 -0700 (PDT) Date: Mon, 19 Jul 2010 17:32:43 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=0016e6469b1ea8a55a048bc52541 Subject: [core] explicit option for URI query part 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 Jul 2010 22:36:43 -0000 --0016e6469b1ea8a55a048bc52541 Content-Type: text/plain; charset=ISO-8859-1 Technically, the query part of a URI is distinct from the path part, but it seems that coap-01 currently requires that they be combined in the Uri-Path option for functions like resource description query filtering. Suggest a distinct option Uri-Query be added, which if absent indicates lack of a query part, and if present comprises the query part exclusive of the introductory hook ("?"). This would restore the distinction between the path and query portions of a URI, and make it easier for an end-point to detect the presence of a query part. And make it easier to add fragment support (as another option) if that should ever be useful. Peter --0016e6469b1ea8a55a048bc52541 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Technically, the query part of a URI is distinct from the path part, but it= seems that coap-01 currently requires that they be combined in the Uri-Pat= h option for functions like resource description query filtering.=A0 Sugges= t a distinct option Uri-Query be added, which if absent indicates lack of a= query part, and if present comprises the query part exclusive of the intro= ductory hook ("?").

This would restore the distinction between the path and query portions = of a URI, and make it easier for an end-point to detect the presence of a q= uery part.=A0 And make it easier to add fragment support (as another option= ) if that should ever be useful.

Peter
--0016e6469b1ea8a55a048bc52541-- From angelo.castellani@gmail.com Tue Jul 20 01:28: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 9CB753A68BD for ; Tue, 20 Jul 2010 01:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 VoaYAe19Znx6 for ; Tue, 20 Jul 2010 01:28:43 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7D64E3A69F5 for ; Tue, 20 Jul 2010 01:28:43 -0700 (PDT) Received: by bwz7 with SMTP id 7so3332003bwz.31 for ; Tue, 20 Jul 2010 01:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=56neVPyvUl+Mz7/0/easS6YjvxynLzVFTvU1Rb1IYJI=; b=m7VlfEod0SnQW8Wi162lLOvKdBdy1G85MtW2T9wQLUwpb/8BGA42aMAVEKHtpaR2fP Oevwv1XYwxDPcg+uZBo3ZPe2c0l76TwdKOz2VU75ER5XzitwGXyfxT5Y4IYrSK5gI98D q3uQtYq/C9xL2Vs9uBIYXaEdvPlMiAbPUjQTc= 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; b=ZEJSD4EicQM+RCp1p1jVXGkyz7zvaaSQgU8Uq/VxUCjO7a1dJWNV9vVxwL71xWzYj4 bKxAy6q0bzwIr5o/t6RvX5Sn4/uYmOMQmKts5jCnCz8LC3/d8Uqd6lTMsTQn7fL+XPsM ok/bQrrkqmoIjS/Csa2iaB9Zavwu5Ps7pf5So= Received: by 10.204.70.201 with SMTP id e9mr4844858bkj.141.1279614535217; Tue, 20 Jul 2010 01:28:55 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.204.114.200 with HTTP; Tue, 20 Jul 2010 01:28:35 -0700 (PDT) In-Reply-To: <0B22C2B0-15A4-42F2-9586-CB091B2840D0@nokia.com> References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> <4C403F9E.8040909@ericsson.com> <0B22C2B0-15A4-42F2-9586-CB091B2840D0@nokia.com> From: "Angelo P. Castellani" Date: Tue, 20 Jul 2010 10:28:35 +0200 X-Google-Sender-Auth: oeGFUBvGQ3Z6EDwnP6BOkE8x2gQ Message-ID: To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org" Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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 Jul 2010 08:28:44 -0000 Hi, thanks for the reply. On Mon, Jul 19, 2010 at 10:04, Lars Eggert wrote: > The intent is that the proposed send credit scheme is implemented by all COAP speakers, including those in the big-I Internet. If there is a translating gateway (e.g. HTTP<->COAP), then it needs to implement the scheme when sending into the COAP network. Maybe a problem arise when multiple CoAP speakers are on the big-I Internet, talking simultaneously with multiple CoAP speakers on the LR-WPAN. All this traffic has to go through the IPv6/Ethernet<->6LoWPAN/802.15.4 gateway, that will easily became a congestion bottleneck, both in the big-I -> LR-WPAN direction (easier to handle through buffering), LR-WPAN -> big-I (harder to handle because the 802.15.4 link between the GW and the nodes can have an high number of hosts competing for the channel). Best, Angelo From lars.eggert@nokia.com Tue Jul 20 01:38:46 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 74A8F3A6C53 for ; Tue, 20 Jul 2010 01:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, J_BACKHAIR_44=1, J_CHICKENPOX_12=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 oFwBvIBvKfS5 for ; Tue, 20 Jul 2010 01:38:45 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 35A153A6C3C for ; Tue, 20 Jul 2010 01:38:25 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6K8agZr005345; Tue, 20 Jul 2010 11:36:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:36:53 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:36:53 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6K8arXA011665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 11:36:53 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lars Eggert In-Reply-To: Date: Tue, 20 Jul 2010 11:36:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2D77314F-BAAA-49A2-9657-032D0A02D37A@nokia.com> References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> <4C403F9E.8040909@ericsson.com> <0B22C2B0-15A4-42F2-9586-CB091B2840D0@nokia.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 20 Jul 2010 11:36:43 +0300 (EEST) X-OriginalArrivalTime: 20 Jul 2010 08:36:53.0864 (UTC) FILETIME=[B4C01680:01CB27E6] X-Nokia-AV: Clean Cc: "core@ietf.org" Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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 Jul 2010 08:38:46 -0000 Hi, On 2010-7-20, at 11:28, Angelo P. Castellani wrote: > On Mon, Jul 19, 2010 at 10:04, Lars Eggert = wrote: >> The intent is that the proposed send credit scheme is implemented by = all COAP speakers, including those in the big-I Internet. If there is a = translating gateway (e.g. HTTP<->COAP), then it needs to implement the = scheme when sending into the COAP network. >=20 > Maybe a problem arise when multiple CoAP speakers are on the big-I > Internet, talking simultaneously with multiple CoAP speakers on the > LR-WPAN. >=20 > All this traffic has to go through the > IPv6/Ethernet<->6LoWPAN/802.15.4 gateway, that will easily became a > congestion bottleneck, both in the big-I -> LR-WPAN direction (easier > to handle through buffering), LR-WPAN -> big-I (harder to handle > because the 802.15.4 link between the GW and the nodes can have an > high number of hosts competing for the channel). right. So what will happen is that messages will be lost. This in turn = will cause the COAP senders that emitted them to reduce their send = credit budget during their next time interval, which will reduce the = congestion on those links. (With some hand-waving, because the send credits are obviously not = accounted for per destination. This means that the budget will be = reduced even if these nodes in the next time interval don't send = messages across the proxy. But I at least can't come up with a simple = scheme that would more accurately track this, or at least not one that = would need some network feedback a'la ECN.) Lars= From cabocabo@gmail.com Tue Jul 20 05:02: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 7BEBB3A6BD2 for ; Tue, 20 Jul 2010 05:02:17 -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, WEIRD_PORT=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 oJgHWlrJLOEs for ; Tue, 20 Jul 2010 05:02:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E65E93A67B5 for ; Tue, 20 Jul 2010 05:02:15 -0700 (PDT) Received: by fxm1 with SMTP id 1so3023861fxm.31 for ; Tue, 20 Jul 2010 05:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=UF7S7Da1gQrULTJO9Lh3+vQW7FLiZwNKgDgPtIzNFJw=; b=JDpyvFEpMepBDMtHWc4+zSrn5fcJ2gUkojnXndqKNfEdtpG88woVZDLSQB53xpPjYP jo+C4n00WY34x8lUZhqJ6gaRzpvWQAHisqGLVnRmi95PUerb4Eox9e+B/uSbkqHuythl Qvu0uVYNTW0FLkmHNFtI3QRRLqSPnP969Ht14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=bHmlm3ChJvpM/MdJ1Re+yZM3Ui2NNPB0vcNTZsHiX2H+n+N5W5wILPJNkNVFsxNhC/ Gk/ZBvIVJndy+ebXEIrWvOJqFvX4ccj36N70vjqxHmBqYsejo0dn2qSSZf7HrGt7QSw7 BmNXBW6A6HlRN4zTWtsKd+CkQ+jrybLyxdgFg= Received: by 10.223.122.148 with SMTP id l20mr5171051far.84.1279627350466; Tue, 20 Jul 2010 05:02:30 -0700 (PDT) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) by mx.google.com with ESMTPS id d15sm1002912faa.3.2010.07.20.05.02.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 05:02:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 20 Jul 2010 14:02:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 12:02:17 -0000 [Apologies for sending duplicates; there is an IPv6 problem between two = mail servers waiting to be debugged... My real mail address is cabo@tzi.org.] On Jul 20, 2010, at 00:32, Peter Bigot wrote: > Uri-Query Interesting. That would be a critical option, so a node that does not want to = implement queries would reject them without any additional code. The split into scheme/authority/path could make simple nodes simpler, = because they only have to implement Uri-Path. On the other hand, accepting this implementation strategy means that = nodes should not send gratuitous Scheme/Authority options if the default = value is fine. (This is probably already a good idea for space reasons. But it does = mean a little more code for nodes that do need to send them sometimes.) Note that this would mean a quite different default URI parse strategy = than for HTTP, where sending a Host: header is mandatory. With a URI of coap://ns.tzi.org:61616 I certainly don't have to send the Uri-Scheme option (as the default = value is fine), but do I have to send the Uri-Authority header? If we support what is called "virtual hosts" in HTTP (multiple authority = values on one IP address), one would have to. How important are virtual hosts then on the CoAP side? (Less important on IPv6 than they were for HTTP on IPv4, but how much = less?) Gruesse, Carsten From angelo.castellani@gmail.com Tue Jul 20 06:32:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9063A6B08 for ; Tue, 20 Jul 2010 06:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, WEIRD_PORT=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 cDonnZ26qWQR for ; Tue, 20 Jul 2010 06:32:04 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8AD133A6805 for ; Tue, 20 Jul 2010 06:32:04 -0700 (PDT) Received: by bwz7 with SMTP id 7so3509106bwz.31 for ; Tue, 20 Jul 2010 06:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=D8p//erngmjAXnOtmzF3cPR2IZy2QlbP1D6oYlVBhh4=; b=A121nx5Iwr0R6O//jKYlPIP1QERMnavD0cZMjbGzq21fx1GUDX69uOhNBPDJvA1e5S SUxP2TPDgzDx5iEor0Wbci6POWHJqGVBsLIsBXipJ52x66l7LnUj92AXVHLU9Pef24Ur LDIaeP8BI2IAC5gwd/gAmdRgUveDtHBjzAAZQ= 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=p9ZWu970lvV7r7GY6Smeljot9IHIKMd2zFeaFt2tHVcr1kZH+P61yGCU+15o6p+Q+D kp4ZwchshzsaQiRz8j8yPXPg2FjBkUiR1WnEXLP9X6q7UZwnadEUyJSaXn+Ufp1au4IK NMK8QatO1iPnFdrbtyvyYJT8uXc5p2yQcLZCI= Received: by 10.204.19.83 with SMTP id z19mr5115742bka.43.1279632736171; Tue, 20 Jul 2010 06:32:16 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.204.114.200 with HTTP; Tue, 20 Jul 2010 06:31:56 -0700 (PDT) In-Reply-To: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> References: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> From: "Angelo P. Castellani" Date: Tue, 20 Jul 2010 15:31:56 +0200 X-Google-Sender-Auth: uKMUIWIuV12JeU6K4o81_bPA1VA Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 13:32:07 -0000 Splitting query parameters from URI is a good idea in my opinion, however for parsing simplicity we can also do something more. A Query-Parameter option already splitted up in the different parameters. Example: "parm1=3Dhello&parm2=3Dworld" This would became two Query-Parameter options respectively with value "parm1=3Dhello" and "parm2=3Dworld" Even better if we can figure out a way to split also parameter name from the value, but I can't came up with any solution for this... About Uri-Authority I think is a very important feature for compatibility with HTTP, however why isn't that option called Host (like in HTTP?) and defined to carry the same value as in HTTP? Angelo On Tue, Jul 20, 2010 at 14:02, Carsten Bormann wrote: > [Apologies for sending duplicates; there is an IPv6 problem between two m= ail servers waiting to be debugged... > My real mail address is cabo@tzi.org.] > > On Jul 20, 2010, at 00:32, Peter Bigot wrote: > >> Uri-Query > > Interesting. > That would be a critical option, so a node that does not want to implemen= t queries would reject them without any additional code. > > The split into scheme/authority/path could make simple nodes simpler, bec= ause they only have to implement Uri-Path. > On the other hand, accepting this implementation strategy means that node= s should not send gratuitous Scheme/Authority options if the default value = is fine. > (This is probably already a good idea for space reasons. =A0But it does m= ean a little more code for nodes that do need to send them sometimes.) > > Note that this would mean a quite different default URI parse strategy th= an for HTTP, where sending a Host: header is mandatory. > With a URI of > =A0 =A0 =A0 =A0coap://ns.tzi.org:61616 > > I certainly don't have to send the Uri-Scheme option (as the default valu= e is fine), but do I have to send the Uri-Authority header? > If we support what is called "virtual hosts" in HTTP (multiple authority = values on one IP address), one would have to. > > How important are virtual hosts then on the CoAP side? > (Less important on IPv6 than they were for HTTP on IPv4, but how much les= s?) > > Gruesse, Carsten > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From cabocabo@gmail.com Tue Jul 20 07:06: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 EE0F33A6B02 for ; Tue, 20 Jul 2010 07:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXCOakP5zCUB for ; Tue, 20 Jul 2010 07:06:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 426F93A69EF for ; Tue, 20 Jul 2010 07:06:50 -0700 (PDT) Received: by fxm1 with SMTP id 1so3121877fxm.31 for ; Tue, 20 Jul 2010 07:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=D2hyLKucChhagG6NXFh/y6eZdPAZ3Afsp6UgKYIgXsM=; b=NngDzOwNTNCm2KVgzJCU7UruKF90DjxJRyoXWUWj+OhG/cZK2GPOCSaMDMX/pLzMOG CFDXkVQufMlCIkjgkDOA3bi60zQXmV8wf35LnyP6Kdrp1YvCRnGS3mXnsPmrLL1DTRzx YGGQ8Q8s8HHCR5nfhiFdf9BJAMQLxUUtDXCnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=p3UOVxkUYpeqbrAX29lbi4yx5W6ofnoGvUESyjH0Q2+5t/v3mft93fBesbKVufy0M3 suV9Y2GpNERUJoc+73X0K0w1qYIeDlz0TLd3biraSx1nX4o26gvlmiZXoDJsJbskKtZK pbpO2y6WeQnpIFtVZ6JdRaoB9CAfsqvccr8Z0= Received: by 10.86.86.2 with SMTP id j2mr4125025fgb.0.1279634825106; Tue, 20 Jul 2010 07:07:05 -0700 (PDT) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) by mx.google.com with ESMTPS id q17sm2468831faa.21.2010.07.20.07.07.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 07:07:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Carsten Bormann In-Reply-To: Date: Tue, 20 Jul 2010 16:07:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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 Jul 2010 14:06:52 -0000 [Another resend, sorry.] On Jun 24, 2010, at 12:00, Angelo P. Castellani wrote: > The server cannot directly know whether the sent response has been > received, how can responses partecipate to the Reno-like AIMD scheme > depicted in the document? (in my opinion a response can be considered > to be "correctly received" if the server doesn't receive in the > subsequent time window of X seconds a retransmission of the served > request) Two observations here. First, any TCP server has the same problem with the SYN ACK. Unless I have missed some recent work, we don't really know how to = congestion control initial responses. Yes, a CoAP response might be up to 20 times larger than a SYN ACK. This is maybe one area where a CC algorithm could change something:=20 The server could start sending smaller packets (using the block option). Second, any retransmission of the original request by the other party = will be subject to binary backoff. It is not clear to me how a server could add to that, except by sending = smaller packets (see above). Since retransmissions should be done by the peer by using the same TID, = a server can get a pretty good measurement of how many ACKs it needs to = send to get one through. This could go into per-peer or global CC = state, in turn influencing the default block size. Global state makes a lot of sense if the bottleneck is likely to be = close to the server. One other interesting observation: The way the block option is defined right now, we assume a constant = block size for all transactions in a transfer. This helps simplifying things a lot, but reduces the granularity of = adaptation possible in a packet-size adaptive CC algorithm. I'd still rather stick with a constant block size. Gruesse, Carsten From angelo.castellani@gmail.com Tue Jul 20 07:08:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453CA3A6B0F for ; Tue, 20 Jul 2010 07:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=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 DGULjAnkf9EH for ; Tue, 20 Jul 2010 07:08:49 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4E34F3A6A25 for ; Tue, 20 Jul 2010 07:08:48 -0700 (PDT) Received: by bwz7 with SMTP id 7so3536161bwz.31 for ; Tue, 20 Jul 2010 07:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Kw3JVq12d8aEy47kZjx49zK9WsAogLrT8ZXy6LUYr40=; b=Me5Az6bmzyL7oEfNZtQ5LkYPMkI2zUMI2XSloZOTtiSexP0RmZgM9fDeqJnQGb/Ew7 XvwY0ZQ5EYqttX12OPOLN+N00hpMtAySrmx5/T9tGKgaLXLSbBixz03bOjguYUPLau18 JugTJDV/GTCX9Jti7Z+K7jOiUn/Vlq5LcSkAU= 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=S0jhlhjrZU85CheW7Qzbc3qb/Voof+9tnkQQ2UsHwyk3MEBO1eBAvycXahnu8dQ1WT mz4i265U+OT+DeTWZOc6Uso4o5UkT+kFCGhjyRtq9B4Ignpe+91nX7j1azRlLlWRgmth /d8fn+Y4z+bd4DWSnFdRS5dBs/ueyLRIa1/Gg= Received: by 10.204.81.148 with SMTP id x20mr5237619bkk.138.1279634939153; Tue, 20 Jul 2010 07:08:59 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.204.114.200 with HTTP; Tue, 20 Jul 2010 07:08:39 -0700 (PDT) In-Reply-To: <2D77314F-BAAA-49A2-9657-032D0A02D37A@nokia.com> References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> <4C403F9E.8040909@ericsson.com> <0B22C2B0-15A4-42F2-9586-CB091B2840D0@nokia.com> <2D77314F-BAAA-49A2-9657-032D0A02D37A@nokia.com> From: "Angelo P. Castellani" Date: Tue, 20 Jul 2010 16:08:39 +0200 X-Google-Sender-Auth: ktu5lh-GwyyaoCqWdwYrwkWUGio Message-ID: To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org" Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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 Jul 2010 14:08:50 -0000 Hi, On Tue, Jul 20, 2010 at 10:36, Lars Eggert wrote: > right. So what will happen is that messages will be lost. This in turn wi= ll cause the COAP senders that emitted them to reduce their send credit bud= get during their next time interval, which will reduce the congestion on th= ose links. > > (With some hand-waving, because the send credits are obviously not accoun= ted for per destination. This means that the budget will be reduced even if= these nodes in the next time interval don't send messages across the proxy= . But I at least can't come up with a simple scheme that would more accurat= ely track this, or at least not one that would need some network feedback a= 'la ECN.) I agree that ECN is the only solution I can think to this kind of problem.. Maybe ECN are really useful in this environment. CoAP big-I<->LR-WPAN gateways can be required to support ECN marking? Angelo From angelo.castellani@gmail.com Tue Jul 20 07:15: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 C92E73A67F7 for ; Tue, 20 Jul 2010 07:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=0.525, 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 sAlnxnJ6-+Ks for ; Tue, 20 Jul 2010 07:15:07 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id AE8E33A68B8 for ; Tue, 20 Jul 2010 07:15:06 -0700 (PDT) Received: by bwz7 with SMTP id 7so3542991bwz.31 for ; Tue, 20 Jul 2010 07:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=WjtwwN4e8iPWja/UrndUOU2tp9BkcVptDEiOgm+Qn04=; b=mQGXt+r1SZykfIirR3+6fSeuneV/HjdJlHOmzrsXdLXG/owZDiwM+8lOzyBHrvaR13 T3bkBxBgV7A6c86ExYNXhpsatsXoBqt8k6Zftjsnh3QtVtPF4vzHJv2nmBFolMDfTqpI ymtPdU5lYpPozm1Mwina8cgt612JNQCtl/tSI= 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; b=jj0bpk+e7wYCaamLwGLuXjM50OjCokynKsa4KLyl1y/TjiLHqVzCnF4CFAFnbTibvv CL5dvCWi2Ki/WjDfu1z2gC6nJyeOsQg3rphXFm1vsHn1bnt2QIP4kt4xGP1EKVCfkX28 ION97fhzPRluJnheR614tohWHWYut09DS4cds= Received: by 10.204.46.159 with SMTP id j31mr5202733bkf.5.1279635312174; Tue, 20 Jul 2010 07:15:12 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.204.114.200 with HTTP; Tue, 20 Jul 2010 07:14:52 -0700 (PDT) In-Reply-To: References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> From: "Angelo P. Castellani" Date: Tue, 20 Jul 2010 16:14:52 +0200 X-Google-Sender-Auth: -hIspxs8xiOrSvHXNyvKjwN2OSU Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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 Jul 2010 14:15:07 -0000 Hi, On Tue, Jul 20, 2010 at 10:52, Carsten Bormann wrote: > Yes, a CoAP response might be up to 20 times larger than a SYN ACK. > This is maybe one area where a CC algorithm could change something: > The server could start sending smaller packets (using the block option). Sending smaller packets first and using block option could be an useful addition I think. Another issue about the tx credits definition: "Sending one CoAP message consumes one transmission credit". But when we send a very big CoAP message which results in 10 or more 802.15.4 PHY packets being sent on the LR-WPAN, this can lead to some issues. Probably TX credits should be more strictly related to the PHY MTU on the path, which however requires a knowledge that the end-point could not have. Moreover 6LoWPAN compression depends upon the IPv6 addresses on the packet.. So can be hard to predict how many frames are required to send a single CoAP message. Angelo From lars.eggert@nokia.com Tue Jul 20 07:18:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1063A681C for ; Tue, 20 Jul 2010 07:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 gP5vjfqX34Y4 for ; Tue, 20 Jul 2010 07:18:57 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6F6EB3A6989 for ; Tue, 20 Jul 2010 07:18:57 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6KEJ86O029866; Tue, 20 Jul 2010 17:19:08 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:19:07 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:19:07 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6KEJ7vM010848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 17:19:07 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lars Eggert In-Reply-To: Date: Tue, 20 Jul 2010 17:19:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <96D21B18-9070-43FB-BCD0-5E91A92A42F7@nokia.com> References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> <4C403F9E.8040909@ericsson.com> <0B22C2B0-15A4-42F2-9586-CB091B2840D0@nokia.com> <2D77314F-BAAA-49A2-9657-032D0A02D37A@nokia.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 20 Jul 2010 17:19:01 +0300 (EEST) X-OriginalArrivalTime: 20 Jul 2010 14:19:07.0662 (UTC) FILETIME=[83D902E0:01CB2816] X-Nokia-AV: Clean Cc: "core@ietf.org" Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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 Jul 2010 14:18:58 -0000 On 2010-7-20, at 17:08, Angelo P. Castellani wrote: > CoAP big-I<->LR-WPAN gateways can be required to support ECN marking? It's not only the gateways that need to do ECN, it's all nodes that can = potentially become bottlenecks - in other words, all of them. And ECN = alone doesn't help, we also need to build mechanisms into COAP that do = something useful with the information. Lars= From pab@peoplepowerco.com Tue Jul 20 07:27: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 0A1303A6814 for ; Tue, 20 Jul 2010 07:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_44=0.6, WEIRD_PORT=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 Jbj53O40ntjp for ; Tue, 20 Jul 2010 07:27:18 -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 308563A67F8 for ; Tue, 20 Jul 2010 07:27:18 -0700 (PDT) Received: by vws13 with SMTP id 13so595035vws.31 for ; Tue, 20 Jul 2010 07:27:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.129.13 with SMTP id m13mr3595739vcs.272.1279636051973; Tue, 20 Jul 2010 07:27:31 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Tue, 20 Jul 2010 07:27:31 -0700 (PDT) In-Reply-To: References: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> Date: Tue, 20 Jul 2010 09:27:31 -0500 Message-ID: From: Peter Bigot To: "Angelo P. Castellani" Content-Type: multipart/alternative; boundary=e0cb4e887b1b51d943048bd27c55 Cc: Carsten Bormann , core Subject: Re: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 14:27:20 -0000 --e0cb4e887b1b51d943048bd27c55 Content-Type: text/plain; charset=ISO-8859-1 Re "Query-Parameter": we could do that, but.... coap-01 section 2.5.2 talks about splitting the URI into "its three parts"; where I was going is that there are actually five major parts to a URI: the scheme, the authority and path, the query, and the fragment. Most of the time we only care about the path. (The text describing how the full URI can be created by concatenating the parts or their defaults needs to be updated to add the missing glue text: the suffix ":" on the scheme, the prefix "//" on the authority, the prefix "/" on the path, etc.) My reluctance to go further and create a Query-Parameter option is that the common syntax of a query being ampersand-separated key=value pairs is not syntactically part of the URI specification (RFC3986), not even for HTTP URIs. Though as long as the option name doesn't include "Uri-", maybe it would be OK to add that and derive the default value for Uri-Query from it. It would certainly be convenient. An argument could be made that we should have a Host option that behaves as you suggest, but it is not the same thing as Uri-Authority, neither syntactically (authority allows an optional userinfo "@") nor semantically. It's also unnecessary: HTTP requires the Host header keyword because it has stripped that information from the URI that appears in the request-line. With the full set of URI options, CoAP doesn't need to do that, and translations to/from HTTP's Host header can use the Uri-Authority option without needing to impact its name (and its use for other schemes that don't have HTTP's limitations). HTTP needs the Host header because the authority part of the URI is otherwise present only in the envelope (the TCP packet). Similarly, the Uri-Authority provides an explicit representation of what is otherwise the end-point address. My initial feeling is that I don't want Uri-Authority to be a required option because (a) it can be pretty long, and (b) the only things that will care about it are proxies and (as Carsten points out) any CoAP end-point that presents a virtual host interface. On the other hand, I'm concerned about having the default value of Uri-Authority be the empty string: that means something different than an actual host+port as determined by the endpoint, and it may not be reasonable to require the implementation to provide envelope information so that the correct default value can be reconstructed. Making Uri-Authority required would eliminate propagating envelope information, as well as the current requirement that a client needs to know whether it's talking to a proxy in order to determine whether it needs to provide the Uri-Authority option. I'll tell you though: I expect my end-points to ignore it. If we do start adding all these options, including ones like Query-Parameter that could appear multiple times, we're going to need a mechanism to support more than 15 options in a header. Peter On Tue, Jul 20, 2010 at 8:31 AM, Angelo P. Castellani wrote: > Splitting query parameters from URI is a good idea in my opinion, > however for parsing simplicity we can also do something more. > > A Query-Parameter option already splitted up in the different parameters. > > Example: "parm1=hello&parm2=world" > > This would became two Query-Parameter options respectively with value > "parm1=hello" and "parm2=world" > > Even better if we can figure out a way to split also parameter name > from the value, but I can't came up with any solution for this... > > About Uri-Authority I think is a very important feature for > compatibility with HTTP, however why isn't that option called Host > (like in HTTP?) and defined to carry the same value as in HTTP? > > Angelo > > On Tue, Jul 20, 2010 at 14:02, Carsten Bormann wrote: > > [Apologies for sending duplicates; there is an IPv6 problem between two > mail servers waiting to be debugged... > > My real mail address is cabo@tzi.org.] > > > > On Jul 20, 2010, at 00:32, Peter Bigot wrote: > > > >> Uri-Query > > > > Interesting. > > That would be a critical option, so a node that does not want to > implement queries would reject them without any additional code. > > > > The split into scheme/authority/path could make simple nodes simpler, > because they only have to implement Uri-Path. > > On the other hand, accepting this implementation strategy means that > nodes should not send gratuitous Scheme/Authority options if the default > value is fine. > > (This is probably already a good idea for space reasons. But it does > mean a little more code for nodes that do need to send them sometimes.) > > > > Note that this would mean a quite different default URI parse strategy > than for HTTP, where sending a Host: header is mandatory. > > With a URI of > > coap://ns.tzi.org:61616 > > > > I certainly don't have to send the Uri-Scheme option (as the default > value is fine), but do I have to send the Uri-Authority header? > > If we support what is called "virtual hosts" in HTTP (multiple authority > values on one IP address), one would have to. > > > > How important are virtual hosts then on the CoAP side? > > (Less important on IPv6 than they were for HTTP on IPv4, but how much > less?) > > > > Gruesse, Carsten > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > --e0cb4e887b1b51d943048bd27c55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re "Query-Parameter": we could do that, but....

coap-01 se= ction 2.5.2 talks about splitting the URI into "its three parts";= where I was going is that there are actually five major parts to a URI: th= e scheme, the authority and path, the query, and the fragment.=A0 Most of t= he time we only care about the path.=A0 (The text describing how the full U= RI can be created by concatenating the parts or their defaults needs to be = updated to add the missing glue text: the suffix ":" on the schem= e, the prefix "//" on the authority, the prefix "/" on = the path, etc.)

My reluctance to go further and create a Query-Parameter option is that= the common syntax of a query being ampersand-separated key=3Dvalue pairs i= s not syntactically part of the URI specification (RFC3986), not even for H= TTP URIs.=A0 Though as long as the option name doesn't include "Ur= i-", maybe it would be OK to add that and derive the default value for= Uri-Query from it.=A0 It would certainly be convenient.

An argument could be made that we should have a Host option that behave= s as you suggest, but it is not the same thing as Uri-Authority, neither sy= ntactically (authority allows an optional userinfo "@") nor seman= tically.=A0 It's also unnecessary: HTTP requires the Host header keywor= d because it has stripped that information from the URI that appears in the= request-line.=A0 With the full set of URI options, CoAP doesn't need t= o do that, and translations to/from HTTP's Host header can use the Uri-= Authority option without needing to impact its name (and its use for other = schemes that don't have HTTP's limitations).

HTTP needs the Host header because the authority part of the URI is oth= erwise present only in the envelope (the TCP packet).=A0 Similarly, the Uri= -Authority provides an explicit representation of what is otherwise the end= -point address.=A0 My initial feeling is that I don't want Uri-Authorit= y to be a required option because (a) it can be pretty long, and (b) the on= ly things that will care about it are proxies and (as Carsten points out) a= ny CoAP end-point that presents a virtual host interface.=A0 On the other h= and, I'm concerned about having the default value of Uri-Authority be the empty string: that means something different=20 than an actual host+port as determined by the endpoint, and it may not be r= easonable to require the implementation to provide envelope information so = that the correct default value can be reconstructed.=A0 Making Uri-Authorit= y required would eliminate propagating envelope information, as well as the= current requirement that a client needs to know whether it's talking t= o a proxy in order to determine whether it needs to provide the Uri-Authori= ty option.=A0 I'll tell you though: I expect my end-points to ignore it= .

If we do start adding all these options, including ones like Query-Para= meter that could appear multiple times, we're going to need a mechanism= to support more than 15 options in a header.

Peter

On Tue, Jul 20, 2010 at 8:31 AM, Angelo P. Castellani <= ;angelo@castellani.net> wrote:
Splitting query parameters from URI is a good idea in my opinion,
however for parsing simplicity we can also do something more.

A Query-Parameter option already splitted up in the different parameters.
Example: "parm1=3Dhello&parm2=3Dworld"

This would became two Query-Parameter options respectively with value
"parm1=3Dhello" and "parm2=3Dworld"

Even better if we can figure out a way to split also parameter name
from the value, but I can't came up with any solution for this...

About Uri-Authority I think is a very important feature for
compatibility with HTTP, however why isn't that option called Host
(like in HTTP?) and defined to carry the same value as in HTTP?

Angelo

On Tue, Jul 20, 2010 at 14:02, Carsten Bormann <cabocabo@gmail.com> wrote:
> [Apologies for sending duplicates; there is an IPv6 problem between tw= o mail servers waiting to be debugged...
> My real mail address is cabo@tzi.org.]
>
> On Jul 20, 2010, at 00:32, Peter Bigot wrote:
>
>> Uri-Query
>
> Interesting.
> That would be a critical option, so a node that does not want to imple= ment queries would reject them without any additional code.
>
> The split into scheme/authority/path could make simple nodes simpler, = because they only have to implement Uri-Path.
> On the other hand, accepting this implementation strategy means that n= odes should not send gratuitous Scheme/Authority options if the default val= ue is fine.
> (This is probably already a good idea for space reasons. =A0But it doe= s mean a little more code for nodes that do need to send them sometimes.) >
> Note that this would mean a quite different default URI parse strategy= than for HTTP, where sending a Host: header is mandatory.
> With a URI of
> =A0 =A0 =A0 =A0coap://ns.tzi.org:61616
>
> I certainly don't have to send the Uri-Scheme option (as the defau= lt value is fine), but do I have to send the Uri-Authority header?
> If we support what is called "virtual hosts" in HTTP (multip= le authority values on one IP address), one would have to.
>
> How important are virtual hosts then on the CoAP side?
> (Less important on IPv6 than they were for HTTP on IPv4, but how much = less?)
>
> Gruesse, Carsten
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--e0cb4e887b1b51d943048bd27c55-- From cabocabo@gmail.com Tue Jul 20 08:34: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 79ADE3A692B for ; Tue, 20 Jul 2010 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 o4B3pBDkvFqm for ; Tue, 20 Jul 2010 08:32:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9AB603A68CC for ; Tue, 20 Jul 2010 08:31:30 -0700 (PDT) Received: by fxm1 with SMTP id 1so3209749fxm.31 for ; Tue, 20 Jul 2010 08:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Bgru3W5fQe+x6uE0bH5QxAr2tjNJwD2+TNjkhjI1EdY=; b=lVT2w855XmH08JLmJ5KrUdiFCm2GOHgTE/mJtOZQoucSU0MIJDDzu29nAmNGchIGp/ rt6r6DONDKTOVxKwNTEjiV1HPQLmZK0RTZCWKFbr3LXS7++p/VTbpGMSfxejZdktykZp 9yuAOCSAL4LkPByNQsxrVQ/gcLkY1Dgea8ihs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QNiD1UCmtpeLzxmp/nhw640NYBIyZSp897ySopaYcnwMsa0t1QL6i9OPagDFXFwJIK 1b5K4sFd6K2FcjF0CkPoXkEYDbgcljbeGbdNBZYaUwXcKIx+XAk8nQe83PtfRQjx5905 ZzQbMVauh6pZDnvd2XDVx9dXd+GA0pNAOaADE= Received: by 10.223.119.147 with SMTP id z19mr5524215faq.64.1279639872659; Tue, 20 Jul 2010 08:31:12 -0700 (PDT) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) by mx.google.com with ESMTPS id b11sm2495859faq.6.2010.07.20.08.31.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 08:31:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 20 Jul 2010 17:31:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <851B53C5-E021-4339-B7EA-29F865B371C3@gmail.com> References: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 15:34:58 -0000 Peter, +1 for most of what you said. Two comments though: 1) always requiring the Uri-Authority option would bloat packets badly = (and, as you say, simple nodes will ignore that bloat anyway). I don't see what's wrong with keeping the "default/empty authority" = semantics as "the node that acts as server". However, we need to either explicitly indicate virtual hosts in a URI or = outlaw them to enable this. 2) Re: On Jul 20, 2010, at 16:27, Peter Bigot wrote: > we're going to need a mechanism to support more than 15 options in a = header. More than 15 options in a single CoAP message makes me shudder. (It is very easy to add such a capability, even in a way that does not = punish messages with less than 15 options. But I'm not seeing the = application.) A more radical question: Who needs lots and lots of queries? I'm not seeing them very much in modern HTTP applications. Gruesse, Carsten (Still posting from Gmail while we wait for att.net to heal.) From pab@peoplepowerco.com Tue Jul 20 09:14:22 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 7FC0B3A69A6 for ; Tue, 20 Jul 2010 09:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spPUTI3dqJuK for ; Tue, 20 Jul 2010 09:14:21 -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 07B583A68EC for ; Tue, 20 Jul 2010 09:14:19 -0700 (PDT) Received: by vws13 with SMTP id 13so712676vws.31 for ; Tue, 20 Jul 2010 09:14:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.75.200 with SMTP id z8mr4280939vcj.197.1279642475163; Tue, 20 Jul 2010 09:14:35 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Tue, 20 Jul 2010 09:14:35 -0700 (PDT) In-Reply-To: <851B53C5-E021-4339-B7EA-29F865B371C3@gmail.com> References: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> <851B53C5-E021-4339-B7EA-29F865B371C3@gmail.com> Date: Tue, 20 Jul 2010 11:14:35 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e64605a22beef0048bd3fbaa Cc: core Subject: Re: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 16:14:22 -0000 --0016e64605a22beef0048bd3fbaa Content-Type: text/plain; charset=ISO-8859-1 I don't want or expect to see dozens of options either, but I do think as a protocol we should be prepared to accommodate them for situations we can't foresee. It will be more important if we have options that can be repeated (as with a Query-Parameter), or if we start having so many optional options that we need to use the fence-post mechanism to adjust for large option-delta values (since each fencepost use contributes to the option count). With the current set I can see having Max-Age, Accepts, Uri-Scheme, Uri-Authority, Uri-Path, and Etag all being necessary for a request directed to a caching end-point. That's using close to half the available spaces, and we're still proposing new, presumably useful, options. I think any such extension has to be formed as a critical option for it to be useful. Perhaps option type 15 as Option-Block, with its value being a sequence of delta-length-value--encoded options. Allow it to be repeated for perverse situations. Peter On Tue, Jul 20, 2010 at 10:31 AM, Carsten Bormann wrote: > > we're going to need a mechanism to support more than 15 options in a > header. > > > More than 15 options in a single CoAP message makes me shudder. > (It is very easy to add such a capability, even in a way that does not > punish messages with less than 15 options. But I'm not seeing the > application.) > > A more radical question: > Who needs lots and lots of queries? > I'm not seeing them very much in modern HTTP applications. > > Gruesse, Carsten > (Still posting from Gmail while we wait for att.net to heal.) > > --0016e64605a22beef0048bd3fbaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't want or expect to see dozens of options either, but I do think = as a protocol we should be prepared to accommodate them for situations we c= an't foresee.=A0 It will be more important if we have options that can = be repeated (as with a Query-Parameter), or if we start having so many opti= onal options that we need to use the fence-post mechanism to adjust for lar= ge option-delta values (since each fencepost use contributes to the option = count).

With the current set I can see having Max-Age, Accepts, Uri-Scheme, Uri= -Authority, Uri-Path, and Etag all being necessary for a request directed t= o a caching end-point.=A0 That's using close to half the available spac= es, and we're still proposing new, presumably useful, options.

I think any such extension has to be formed as a critical option for it= to be useful.=A0 Perhaps option type 15 as Option-Block, with its value be= ing a sequence of delta-length-value--encoded options.=A0 Allow it to be re= peated for perverse situations.

Peter

On Tue, Jul 20, 2010 at 10:31 A= M, Carsten Bormann <cabocabo@gmail.com> wrote:
> we're going to need a mechanism to support more than 15 options in= a header.


More than 15 options in a single CoAP message makes me shudder. (It is very easy to add such a capability, even in a way that does not puni= sh messages with less than 15 options. =A0But I'm not seeing the applic= ation.)

A more radical question:
Who needs lots and lots of queries?
I'm not seeing them very much in modern HTTP applications.

Gruesse, Carsten
(Still posting from Gmail while we wait for att.net to heal.)


--0016e64605a22beef0048bd3fbaa-- From pab@peoplepowerco.com Tue Jul 20 09:15: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 6D67B3A69A6 for ; Tue, 20 Jul 2010 09:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR8nYtn13BZD for ; Tue, 20 Jul 2010 09:15:07 -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 89C973A6878 for ; Tue, 20 Jul 2010 09:15:07 -0700 (PDT) Received: by vws13 with SMTP id 13so713526vws.31 for ; Tue, 20 Jul 2010 09:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.126.152 with SMTP id c24mr3542071vcs.152.1279642522386; Tue, 20 Jul 2010 09:15:22 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Tue, 20 Jul 2010 09:15:22 -0700 (PDT) Date: Tue, 20 Jul 2010 11:15:22 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=001636c93289fc824a048bd3fd7f Subject: [core] private option type codes 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 Jul 2010 16:15:08 -0000 --001636c93289fc824a048bd3fd7f Content-Type: text/plain; charset=ISO-8859-1 Can/should we reserve a block of option types for application use, as with link-extension fields in the resource description? If I find a situation where my application needs such a feature (e.g., an option providing application-specific authentication information), I'd rather not have to worry that IANA will come along and use the same type code for something else. Peter --001636c93289fc824a048bd3fd7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can/should we reserve a block of option types for=20 application use, as with link-extension fields in the resource=20 description?=A0 If I find a situation where my application needs such a=20 feature (e.g., an option providing application-specific authentication=20 information), I'd rather not have to worry that IANA will come along an= d use the same type code for something else.

Peter
--001636c93289fc824a048bd3fd7f-- From pete.st.pierre@oracle.com Tue Jul 20 09:45: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 2CC783A68ED for ; Tue, 20 Jul 2010 09:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwwdTQdiJxWo for ; Tue, 20 Jul 2010 09:45:06 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 684923A6829 for ; Tue, 20 Jul 2010 09:45:06 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6KGjJAg030375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Jul 2010 16:45:21 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6KDIVff006329; Tue, 20 Jul 2010 16:45:15 GMT Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 420679191279644304; Tue, 20 Jul 2010 09:45:04 -0700 Received: from dhcp-umpk16-79-132.sfbay.sun.com (/129.146.79.132) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Jul 2010 09:45:04 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Pete St. Pierre" In-Reply-To: Date: Tue, 20 Jul 2010 09:45:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80746C37-A1D4-44D8-BAAF-F85B5408DFEE@oracle.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C45D29E.0070:SCFMA4539814,ss=1,fgs=0 Cc: core Subject: Re: [core] private option type codes 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 Jul 2010 16:45:11 -0000 This is a really good question. I'm curious if we're really using the = Option Code field in the most efficient manner right now. Using the = odd/even mechanism to distinguish "critical" from "elective" is = interesting and has some conveniences, but I certainly wouldn't object = to using some of the 4 bits assigned as 'length' bits to give us = additional flexibility.=20 We could then have a constant 8 bit length field (allow options of 0-255 = bytes instead of 0-270) which further simplifies packet processing. Out of curiousity, in the original options code creation, how many IANA = approved options were we really expecting? It is expected to be an even = split between "criticial" options and "elective" options? ...Pete On Jul 20, 2010, at 9:15 AM, Peter Bigot wrote: > Can/should we reserve a block of option types for application use, as = with link-extension fields in the resource description? If I find a = situation where my application needs such a feature (e.g., an option = providing application-specific authentication information), I'd rather = not have to worry that IANA will come along and use the same type code = for something else. >=20 > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Pete St. Pierre Pete.St.Pierre@oracle.com Sun Labs Oracle=20 16 Network Circle Menlo Park, CA 94025 From pab@peoplepowerco.com Tue Jul 20 09:46:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F563A68ED for ; Tue, 20 Jul 2010 09:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=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 Q12KDi4FxIUg for ; Tue, 20 Jul 2010 09:46:21 -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 7F6893A6829 for ; Tue, 20 Jul 2010 09:46:21 -0700 (PDT) Received: by vws13 with SMTP id 13so746500vws.31 for ; Tue, 20 Jul 2010 09:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.169.131 with SMTP id z3mr1173622vcy.1.1279644393256; Tue, 20 Jul 2010 09:46:33 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Tue, 20 Jul 2010 09:46:32 -0700 (PDT) In-Reply-To: <851B53C5-E021-4339-B7EA-29F865B371C3@gmail.com> References: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> <851B53C5-E021-4339-B7EA-29F865B371C3@gmail.com> Date: Tue, 20 Jul 2010 11:46:32 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016364c693d7fb821048bd46d6f Cc: core Subject: Re: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 16:46:23 -0000 --0016364c693d7fb821048bd46d6f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 10:31 AM, Carsten Bormann wrote: > 1) always requiring the Uri-Authority option would bloat packets badly > (and, as you say, simple nodes will ignore that bloat anyway). > I don't see what's wrong with keeping the "default/empty authority" > semantics as "the node that acts as server". > I don't think that semantics is currently explicit, and whether it's workable depends on its interpretation. Does it imply that, when reconstructing the URI from the options, it's necessary to extract the envelope's source end-point address+host or destination end-point address+host so that the server node can be explicitly identified? This would get really ugly, since "server" depends on the method and which end is processing the message, Plus, what happens if the end-point received the message over multicast (which can't be the end-point address because it can't be used for a UDP source address)? Then the reconstructed URI is different on each recipient. That would introduce an issue with recognizing an asynchronous response. I propose making Uri-Authority have no default, rather than an empty string default: an empty string doesn't conform to the ABNF for authority in section 3.2 of RFC3986. I would interpret "absent authority" as "no authority specified", with the meaning of that delegated to standard interpretation of a URI that lacks a "//" authority sequence. If a non-absent Uri-Authority is present, then the reconstructed URI includes the "//" prefix followed by the option's value. (This may be pragmatically equivalent to what you suggested.) However, we need to either explicitly indicate virtual hosts in a URI or > outlaw them to enable this. > If that's true (not convinced), outlaw 'em. Life's complicated enough already. If you want HTTP, use it. Peter > > 2) Re: > > On Jul 20, 2010, at 16:27, Peter Bigot wrote: > > > we're going to need a mechanism to support more than 15 options in a > header. > > More than 15 options in a single CoAP message makes me shudder. > (It is very easy to add such a capability, even in a way that does not > punish messages with less than 15 options. But I'm not seeing the > application.) > > A more radical question: > Who needs lots and lots of queries? > I'm not seeing them very much in modern HTTP applications. > > Gruesse, Carsten > (Still posting from Gmail while we wait for att.net to heal.) > > --0016364c693d7fb821048bd46d6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 20, 2010 at 10:31 AM, Carsten Borman= n <cabocabo@gmai= l.com> wrote:
1) always requiring the Uri-Authority option would bloat packets badly (and= , as you say, simple nodes will ignore that bloat anyway).
I don't see what's wrong with keeping the "default/empty autho= rity" semantics as "the node that acts as server".

I don't think that semantics is currently explicit, and= whether it's workable depends on its interpretation.

Does it imply that, when reconstructing the URI from the options, it= 9;s necessary to extract the envelope's source end-point address+host o= r destination end-point=20 address+host so that the server node can be explicitly identified?=A0 This = would get really ugly, since "server" depends on the method and w= hich end is processing the message,=A0 Plus, what happens if the end-point = received the message over multicast (which can't be the end-point addre= ss because it can't be used for a UDP source address)?=A0 Then the reco= nstructed URI is different on each recipient.=A0 That would introduce an is= sue with recognizing an asynchronous response.

I propose making Uri-Authority have no default, rather than an empty st= ring default: an empty string doesn't conform to the ABNF for authority= in section 3.2 of RFC3986.=A0 I would interpret "absent authority&quo= t; as "no authority specified", with the meaning of that delegate= d to standard interpretation of a URI that lacks a "//" authority= sequence.=A0 If a non-absent Uri-Authority is present, then the reconstruc= ted URI includes the "//" prefix followed by the option's val= ue.

(This may be pragmatically equivalent to what you suggested.)

However, we need to either explicitly indicate virtual hosts in a URI or ou= tlaw them to enable this.

If that's true (not = convinced), outlaw 'em.=A0 Life's complicated enough already.=A0 If= you want HTTP, use it.

Peter
=A0

2) Re:

On Jul 20, 2010, at 16:27, Peter Bigot wrote:

> we're going to need a mechanism to support more than 15 options in= a header.

More than 15 options in a single CoAP message makes me shudder.
(It is very easy to add such a capability, even in a way that does not puni= sh messages with less than 15 options. =A0But I'm not seeing the applic= ation.)

A more radical question:
Who needs lots and lots of queries?
I'm not seeing them very much in modern HTTP applications.

Gruesse, Carsten
(Still posting from Gmail while we wait for att.net to heal.)


--0016364c693d7fb821048bd46d6f-- From cabocabo@gmail.com Tue Jul 20 10: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 390663A6BF7 for ; Tue, 20 Jul 2010 10:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vHGj0n52WhaL for ; Tue, 20 Jul 2010 10:14:15 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CABBA3A6A4C for ; Tue, 20 Jul 2010 10:14:14 -0700 (PDT) Received: by fxm1 with SMTP id 1so3313174fxm.31 for ; Tue, 20 Jul 2010 10:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=GJ6/nau+AAPwvNHc2pQkfD8PIiPxhYW1UQE9gSGhXLs=; b=EGCz37TYBMEwX3f+OVZloptkfVnCrZKfPpug8CDjGUdPs41HwKkMYTvOCrc8osIA2R tbuNQ3X5KfVoyilcsKdwT5K5ebneCj/zqNm3yiTAuGM/LV2Xi2UQs8UltAH8ZjJ5+qaJ Ee7AVsehF7AxRWUEnDZJqY+mCtoNkA9tclTOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=eWK9V01jsJEBj5VvUxe79JzNtn4YWigvdvu3uIbQSnvjzqvcTIn4rGyWjU/sXNT5TL NW9WCEGPj9hdmXkmNhoQisZALENA+Fz/ZLJYnaiaGYxzzGfh+Gd+YMgeK6hepWUdWZIl GTgWwOSI+qIq42yk/rLWrKPEVTGe2DfaJv0pg= Received: by 10.223.107.211 with SMTP id c19mr5707283fap.20.1279646069787; Tue, 20 Jul 2010 10:14:29 -0700 (PDT) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) by mx.google.com with ESMTPS id h8sm2527859faj.14.2010.07.20.10.14.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 10:14:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 20 Jul 2010 19:14:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66623090-71DB-458A-BA0C-0150C60BE51B@gmail.com> References: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> <851B53C5-E021-4339-B7EA-29F865B371C3@gmail.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 17:14:17 -0000 On Jul 20, 2010, at 18:14, Peter Bigot wrote: > Option-Block, with its value being a sequence of = delta-length-value--encoded options. Yep, I had that in an early version of coap-misc, and I took it out = because I don't think we should plan for a bazillion options. But yes, if we move toward micro-options like the Uri-Query element, we = could go back to that. The "Options" option of coap-misc was a single option that was = alternative to having other options at the top level. Like this (ignore the idea to limit to 7 options in a message; we now = have up to 15 just from the header). Options Option -------------- There is no hard boundary that can be given for the number of options required in a message. While messages will rarely require more than 4 or 5 options, some will, and it would be wasteful to provide a large enough option counter in the message header to cater for the worst case. Instead, we propose to limit the option counter in the message header to a maximum value of 7 (i.e., it can be represented in 3 bits). If 8 or more options are required, **all** options are packaged into an `Options` option, giving explicitly the length of the option part of the message. This option, if present, must be the first and only option (so the option counter in the message header will be 1). The Options option MAY NOT be used unless needed (i.e., 8 or more options in the message). As a consequence, Options options never can = nest. Within the Options option, the running option number increased by the options delta starts at zero again. Gruesse, Carsten From cabocabo@gmail.com Tue Jul 20 10:24: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 5E88E3A6969 for ; Tue, 20 Jul 2010 10:24:28 -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=-0.600, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_74=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 vOPO+ENAObHA for ; Tue, 20 Jul 2010 10:24:27 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 439253A687E for ; Tue, 20 Jul 2010 10:24:27 -0700 (PDT) Received: by fxm1 with SMTP id 1so3320576fxm.31 for ; Tue, 20 Jul 2010 10:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=iA5B91SspGVqgO62qnhZoxEszcmhDZwcFUe3OJrJLfU=; b=oeQ/CQgxsVarx8sGtdIBPekPi2BZxpdYcKqvvqgCz35ptn7Jsxx4W3dYWZllzuEufR jfNwcJe3CdZvnn6vGdLG+uTH5bpSRKEDQbRSftbv2I3tkxq4rEXTidQYRFkJF8LyWBBG IkGpf8kzntnPPXj2gdaoAkaAcB0XahtoOrDQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=EJVV6K/2Y/jiLbBUcuL8Zg+y1acrrD791jf16c7dCvQxhSViF+SjAD+gRbkTSJLrmI 6sMmIYbjhA0hpj5icvd/CNXlMMxtMxqsxoSjSdLeVPUXtIAAGYnJ4s9GSBeJ+nHy8lQW MZwMWATXCV1L7v6Jju0QH9NmnhXSJtKLh9T6U= Received: by 10.223.121.19 with SMTP id f19mr5693708far.73.1279646681335; Tue, 20 Jul 2010 10:24:41 -0700 (PDT) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) by mx.google.com with ESMTPS id r10sm2530940faq.29.2010.07.20.10.24.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 10:24:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 20 Jul 2010 19:24:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C758489-73B5-4BF6-88D7-EC8185A8B133@gmail.com> References: <57878FD7-7C7F-43B1-99B8-A474114A55CE@gmail.com> <851B53C5-E021-4339-B7EA-29F865B371C3@gmail.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 17:24:28 -0000 On Jul 20, 2010, at 18:46, Peter Bigot wrote: > On Tue, Jul 20, 2010 at 10:31 AM, Carsten Bormann = wrote: > 1) always requiring the Uri-Authority option would bloat packets badly = (and, as you say, simple nodes will ignore that bloat anyway). > I don't see what's wrong with keeping the "default/empty authority" = semantics as "the node that acts as server". >=20 > I don't think that semantics is currently explicit, Let's fix that then. > and whether it's workable depends on its interpretation. Let's do a workable interpretation then :-) > Does it imply that, when reconstructing the URI from the options, it's = necessary to extract the envelope's source end-point address+host or = destination end-point address+host so that the server node can be = explicitly identified? =20 No, the idea is that there is an identifiable receiver of the = request/emitter of the response, and that is addressed by the = request/emits the response. > This would get really ugly, since "server" depends on the method and = which end is processing the message, Plus, what happens if the = end-point received the message over multicast (which can't be the = end-point address because it can't be used for a UDP source address)? =20= Indeed, if a multicast request is to be useful in any way, it needs to = *leave out* authority (or have a group authority), and make the = authority actually acting on the request implicitly derived. > Then the reconstructed URI is different on each recipient. That would = introduce an issue with recognizing an asynchronous response. Not so sure about that. If f::0:0 tells me their /bar is 14, that may = be exactly what I want to know. > I propose making Uri-Authority have no default, rather than an empty = string default: an empty string doesn't conform to the ABNF for = authority in section 3.2 of RFC3986. =20 Really? Page 18: host =3D IP-literal / IPv4address / reg-name Page 21: reg-name =3D *( unreserved / pct-encoded / sub-delims ) Note that *(...) means zero or more of. It goes on to say: If the URI scheme defines a default for host, then that default applies when the host subcomponent is undefined or when the registered name is empty (zero length). For example, the "file" URI scheme is defined so that no authority, an empty host, and "localhost" all mean the end-user's machine, whereas the "http" scheme considers a missing authority or empty host invalid. >> However, we need to either explicitly indicate virtual hosts in a URI = or outlaw them to enable this. >=20 > If that's true (not convinced), outlaw 'em. Life's complicated enough = already. If you want HTTP, use it. Sounds good to me. Gruesse, Carsten From cabocabo@gmail.com Tue Jul 20 10:34: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 97F053A6B32 for ; Tue, 20 Jul 2010 10:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, WEIRD_PORT=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 ZPOzhiQcPrsg for ; Tue, 20 Jul 2010 10:34:35 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 232363A6992 for ; Tue, 20 Jul 2010 10:34:34 -0700 (PDT) Received: by bwz7 with SMTP id 7so3722615bwz.31 for ; Tue, 20 Jul 2010 10:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Aame9PF3WfAgvK5IXyIBWj6RwNoJKKPWwMfvOfswkzE=; b=rypyKa2KEDMt3VRDOrswt84dCg4/9YZsyBCN1i4nSDsGA1i+zPWLuuh0bN4CdcQQrc k7hdk2ytaa0U8W3ZMvffKDqhhOJZD1VBxSlmC9rFXN/luNw6k24DsTdLWV37ZZH5q2/d IaB/iyXM/vO06nfKiGThGc7Nc6Ehj6WJkRwmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fPfDr4GOA8GE48kOHMDc7Jl4FjG6i0hBc0etepQ29AkWnsi0kXOWsuJ1HNiJ2/K1Vi G9byRuCvsw2WMwFdYU82mNK5whI3hsqWPhr0I99wjtoY8EysRN92O9HS73YdJfzw3MYE 8qCvP5NK697bDFDZSWJStRp0HIh+3lrZGi/RM= Received: by 10.204.118.3 with SMTP id t3mr5415214bkq.163.1279647287161; Tue, 20 Jul 2010 10:34:47 -0700 (PDT) Received: from [134.102.2.199] ([134.102.2.199]) by mx.google.com with ESMTPS id a9sm28252807bky.11.2010.07.20.10.34.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 10:34:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <80746C37-A1D4-44D8-BAAF-F85B5408DFEE@oracle.com> Date: Tue, 20 Jul 2010 19:34:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07F51D76-85C1-4328-95AE-1BDC6A4874AD@gmail.com> References: <80746C37-A1D4-44D8-BAAF-F85B5408DFEE@oracle.com> To: Pete St. Pierre X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] private option type codes 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 Jul 2010 17:34:36 -0000 On Jul 20, 2010, at 18:45, Pete St. Pierre wrote: > This is a really good question. I'm curious if we're really using the = Option Code field in the most efficient manner right now. [...] > Out of curiousity, in the original options code creation, how many = IANA approved options were we really expecting? It is expected to be an = even split between "criticial" options and "elective" options? Right now, we have more critical than elective ones. I expect that to = change a bit when people start thinking up real "options" though. How critical (pun intended) is it to have an even split? We would have = wasted a bit on the critical/elective decision anyway, and using it for = the option type as well is prudent. =20 I think the interesting observation is that in nearly all messages that = came to coap://ns.tzi.org:61616 so far, *all* option headers (the things = in front of option values) were exactly one byte. Longer takes too much = space, shorter is a pain to process. So I think we are *exactly* where = we want to be. Gruesse, Carsten From brian.tridium@gmail.com Tue Jul 20 11:10: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 63FCC3A6A4D for ; Tue, 20 Jul 2010 11:10:16 -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 Cso9scTgLWWp for ; Tue, 20 Jul 2010 11:10:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 480F83A67AC for ; Tue, 20 Jul 2010 11:10:12 -0700 (PDT) Received: by bwz7 with SMTP id 7so3751442bwz.31 for ; Tue, 20 Jul 2010 11:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZMGpKjmIu7PDYtsoNtjkRNKgQxiyWd3oD+NFugSjQJM=; b=ePmxPSqslSfWHwsOPgMu50IjSZM+rsdryBHKkQRnUCAgO9V5gwgzt9shXhcob5fSj7 H/lq8tJKKrlsGctiKyAHAzGv7RnIN2EI9kLYQx5kpN3DMdXKhd0GWfeGeq0Rt4qQBbTr Z3G/Q5ihjvSRssy/nPlXd40CBubuFdMcQCK+M= 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=gt0/FIGB7M2R9n6zozQX6+R0nzrxpAsRk+MYuLU4zpfxY951QYuJ/8KnK4VdWoYsQw IIvncZ9xMRZQ2ALgYWU5i63EpbKE8VA9q+/DxUA/5ypGRbt7lrjrwEzjMdCMwZPpRG+T PqsGy5siqyUQ8p2r6EUkH800bddb82JBji+c4= MIME-Version: 1.0 Received: by 10.204.74.195 with SMTP id v3mr5426851bkj.35.1279649421963; Tue, 20 Jul 2010 11:10:21 -0700 (PDT) Received: by 10.204.113.70 with HTTP; Tue, 20 Jul 2010 11:10:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Jul 2010 14:10:21 -0400 Message-ID: From: Brian Frank To: Peter Bigot Content-Type: multipart/alternative; boundary=0016e6d785433bc9f1048bd599e7 Cc: core Subject: Re: [core] private option type codes 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 Jul 2010 18:10:16 -0000 --0016e6d785433bc9f1048bd599e7 Content-Type: text/plain; charset=ISO-8859-1 +1 - I'd vote for some sort of application layer specific options (I think the value of doing this in HTTP has proved its worth) On Tue, Jul 20, 2010 at 12:15 PM, Peter Bigot wrote: > Can/should we reserve a block of option types for application use, as with > link-extension fields in the resource description? If I find a situation > where my application needs such a feature (e.g., an option providing > application-specific authentication information), I'd rather not have to > worry that IANA will come along and use the same type code for something > else. > > --0016e6d785433bc9f1048bd599e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 - I'd vote for some sort of application layer specific options (I th= ink the value of doing this in HTTP has proved its worth)

On Tue, Jul 20, 2010 at 12:15 PM, Peter Bigot <pab@peoplepowerco.com> wrote:
Can/should we reserve a block of option typ= es for=20 application use, as with link-extension fields in the resource=20 description?=A0 If I find a situation where my application needs such a=20 feature (e.g., an option providing application-specific authentication=20 information), I'd rather not have to worry that IANA will come along an= d use the same type code for something else.

--0016e6d785433bc9f1048bd599e7-- From pab@peoplepowerco.com Tue Jul 20 11:38:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F0B3A6C1C for ; Tue, 20 Jul 2010 11:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVRjofhylzI8 for ; Tue, 20 Jul 2010 11:38:09 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id C1AB23A686C for ; Tue, 20 Jul 2010 11:38:02 -0700 (PDT) Received: by gwj19 with SMTP id 19so3338625gwj.31 for ; Tue, 20 Jul 2010 11:37:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.47.39 with SMTP id u39mr836652ybu.144.1279651064064; Tue, 20 Jul 2010 11:37:44 -0700 (PDT) Received: by 10.231.209.74 with HTTP; Tue, 20 Jul 2010 11:37:43 -0700 (PDT) Date: Tue, 20 Jul 2010 13:37:43 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=000e0cd70aa61c2a83048bd5fb6b Cc: core Subject: [core] What is an end-point (was: URI splitting (was: Re: explicit option for URI query part)) 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 Jul 2010 18:38:28 -0000 --000e0cd70aa61c2a83048bd5fb6b Content-Type: text/plain; charset=ISO-8859-1 OK, we've moved to a question I'd avoided, so I've changed the subject for this thread. To wit, what is an end-point? And, once we figure that out, how does end-point relate to a URI-reference that identifies a resource at that end-point? Section 2.1 of coap-01 states: ...Machine-to-machine interactions typically result in a CoAP implementation acting in both client and server roles (called an end-point). The plural "roles" and singular particle "an" make this text imprecise. Are the two roles considered distinct end-points? Or is the single implementation one end-point with both roles? If an implementation accepts messages on multiple interfaces or ports, is each a separate end-point? For example, when monitoring multiple UDP sockets, one bound to the (TBD) IANA registered COAP port and another bound to a port in the RFC4944-specified (private) compressed UDP port space. Text in section 4.4 implies these are distinct end-points. What about multicast? A received multicast message has to be delivered to an end-point, right? For the end-point to send ACKs over UDP, it has to be bound to a non-multicast address (unless it's supposed to multicast the ACKs, which seems wrong). Is that end-point required to accept messages addressed to its non-multicast address? Or is it that ACKs and RSTs should not be considered as coming from an end-point, even though they're generated in response to a message received by an end-point? In an asynchronous response, is the server obliged to transmit the response message from the same end-point as received the original request? Or could it use the asynchronous response specifically to change the end-point (a sort of implicit redirect)? My conclusion had been: - Each end-point is bound to exactly one non-multicast (i.e., unicast or link-local) IP address and port. - Each end-point can additionally receive messages on zero or more multicast addresses and ports. - A transaction response message must be sent from the unicast or link-local IP address and port associated with the end-point that received the transaction request. > Then the reconstructed URI is different on each recipient. That would > introduce an issue with recognizing an asynchronous response. > > Not so sure about that. If f::0:0 tells me their /bar is 14, that may be > exactly what I want to know. > >From your comment, it appears that a resource identified by a multicast address continues to be identified by multicast. I can see that use, though it wasn't the first that came to mind. I had assumed that I would send a GET request for a URI with an unspecified authority to a multicast address in order to identify the end-points to which I could subsequently send direct requests. For that use, I would either have to be able to examine the envelope information (the address provided via recvfrom(2)), or assume I could reconstruct the resource URI at the responding end-point from option headers. For example, I think this is how I would have to do resource discovery with a URI like "/.well-known/r?name=temperature": multicast it to all-hosts, then somehow extract from the responses the addresses of the end-points that can provide temperatures. How do I do that extraction? All this is assuming end-points are defined by one or more UDP "end-point"s. Angelo Castellani suggested on 31 May that end-point in REST referred to something that retained state, so a resource to which a subscription existed necessitated creation of a new end-point that held the knowledge of that subscription. > I propose making Uri-Authority have no default, rather than an empty > string default: an empty string doesn't conform to the ABNF for authority in > section 3.2 of RFC3986. > > Really? Page 18: > Hah. Once, just once, I decide to wing it and get work done instead of tracing the references all the way back to Genesis, and I get bit. You're absolutely right; I was mis-generalizing from the http scheme. I still think it's worth being able to distinguish a missing authority from an empty one, though, so we can precisely recreate the text of the original URI without assuming the specific scheme treats them as equivalent. Peter --000e0cd70aa61c2a83048bd5fb6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, we've moved to a question I'd avoided, so I've changed the = subject for this thread.=A0 To wit, what is an end-point?=A0 And, once we f= igure that out, how does end-point relate to a URI-reference that identifie= s a resource at that end-point?

Section 2.1 of coap-01 states:

=A0=A0 ...Machine-to-machine inte= ractions typically result in a CoAP
=A0=A0 implementation acting in both= client and server roles (called an
=A0=A0 end-point).

The plural= "roles" and singular particle "an" make this text impr= ecise.=A0 Are the two roles considered distinct end-points?=A0 Or is the si= ngle implementation one end-point with both roles?

If an implementation accepts messages on multiple interfaces or ports, = is each a separate end-point?=A0 For example, when monitoring multiple UDP = sockets, one bound to the (TBD) IANA registered COAP port and another bound= to a port in the RFC4944-specified (private) compressed UDP port space.=A0= Text in section 4.4 implies these are distinct end-points.

What about multicast?=A0 A received multicast message has to be deliver= ed to an end-point, right?=A0 For the end-point to send ACKs over UDP, it h= as to be bound to a non-multicast address (unless it's supposed to mult= icast the ACKs, which seems wrong).=A0 Is that end-point required to accept= messages addressed to its non-multicast address?=A0 Or is it that ACKs and= RSTs should not be considered as coming from an end-point, even though the= y're generated in response to a message received by an end-point?

In an asynchronous response, is the server obliged to transmit the resp= onse message from the same end-point as received the original request?=A0 O= r could it use the asynchronous response specifically to change the end-poi= nt (a sort of implicit redirect)?

My conclusion had been:

- Each end-point is bound to exactly one= non-multicast (i.e., unicast or link-local) IP address and port.

- = Each end-point can additionally receive messages on zero or more multicast = addresses and ports.

- A transaction response message must be sent from the unicast or link-= local IP address and port associated with the end-point that received the t= ransaction request.

> Then the reconstructed URI is different on each recipient. =A0That=20 would introduce an issue with recognizing an asynchronous response.

Not so sure about that. =A0If f::0:0 tells me their /bar is 14, that may be exactly what I want to know.

From your comment,= it appears that a resource identified by a multicast address continues to = be identified by multicast.=A0 I can see that use, though it wasn't the= first that came to mind.

I had assumed that I would send a GET request for a URI with an unspeci= fied authority to a multicast address in order to identify the end-points t= o which I could subsequently send direct requests.=A0 For that use, I would= either have to be able to examine the envelope information (the address pr= ovided via recvfrom(2)), or assume I could reconstruct the resource URI at = the responding end-point from option headers.

For example, I think this is how I would have to do resource discovery = with a URI like "/.well-known/r?name=3Dtemperature": multicast it= to all-hosts, then somehow extract from the responses the addresses of the= end-points that can provide temperatures.=A0 How do I do that extraction?<= br>
All this is assuming end-points are defined by one or more UDP "en= d-point"s.=A0 Angelo Castellani suggested on 31 May that end-point in = REST referred to something that retained state, so a resource to which a su= bscription existed necessitated creation of a new end-point that held the k= nowledge of that subscription.

> I propose making Uri-Authority have no default, rather than an empty s= tring default: an empty string doesn't conform to the ABNF for authorit= y in section 3.2 of RFC3986.

Really? =A0Page 18:

Hah.=A0 Once, just once,= I decide to wing it and get work done instead of tracing the references al= l the way back to Genesis, and I get bit.=A0 You're absolutely right; I= was mis-generalizing from the http scheme.

I still think it's worth being able to distinguish a missing author= ity from an empty one, though, so we can precisely recreate the text of the= original URI without assuming the specific scheme treats them as equivalen= t.

Peter

--000e0cd70aa61c2a83048bd5fb6b-- From hariharasudhan.tce@gmail.com Wed Jul 21 01:53: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 98C593A6855 for ; Wed, 21 Jul 2010 01:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 T2H+FxNtbWgM for ; Wed, 21 Jul 2010 01:53:15 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C6E063A67BD for ; Wed, 21 Jul 2010 01:53:15 -0700 (PDT) Received: by iwn38 with SMTP id 38so7312808iwn.31 for ; Wed, 21 Jul 2010 01:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=1itbBVD1ZLO1PLeVbPOMBC3w1nX2jz4GyNi3sIaHvM8=; b=nN6sRSLTtvLWIc+PZKhNUkJZTcXIKNW3x3i8xJmVV4IjHwXyRd8q9F3FQVIvcfuJuK T/NhbYnqsXECKyqxE5DfF+Gi24GDaR4NZCYe5NP8IU+wEfIU9IpCeAo6BI7aVOKUgwdH oOffAg86c3HKqQcZrl+LLTC05AnWBN74cIcf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=eTr/JK5RKHqsvYjvpbdhl4Jn6AZ6M8iySzz8Y7suelBQfO3kJVj37SDj52p16HFueT fUPMYvG1Cw1jBUhhIwImfki4nvvyZCqEBVPNKvsWJJ9+0zP170Z9OgZtM44tgtiotJF2 EEfbLlTkhJGz7obH8TXCkxWxyqzFCIzjj09sE= MIME-Version: 1.0 Received: by 10.231.154.75 with SMTP id n11mr9077596ibw.40.1279702411808; Wed, 21 Jul 2010 01:53:31 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Wed, 21 Jul 2010 01:53:31 -0700 (PDT) Date: Wed, 21 Jul 2010 14:23:31 +0530 Message-ID: From: Hari Hara Sudhan R To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] option header in COAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 08:53:16 -0000 Hi all, COAP specifications mention some default values for options. If the application doesnt provide some of these options then COAP implementation will add the default values to the message and send it. Is that right? Thanks and Regards, Hari From pab@peoplepowerco.com Wed Jul 21 11:58:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2689C3A6A72 for ; Wed, 21 Jul 2010 11:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T3ZVL6MmN-G for ; Wed, 21 Jul 2010 11:58:46 -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 2EADF3A69F1 for ; Wed, 21 Jul 2010 11:58:46 -0700 (PDT) Received: by vws13 with SMTP id 13so2264312vws.31 for ; Wed, 21 Jul 2010 11:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.140 with SMTP id t12mr316030vch.54.1279738742223; Wed, 21 Jul 2010 11:59:02 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Wed, 21 Jul 2010 11:59:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 13:59:02 -0500 Message-ID: From: Peter Bigot To: Hari Hara Sudhan R Content-Type: multipart/alternative; boundary=e0cb4e887eb322b38a048bea6585 Cc: core@ietf.org Subject: Re: [core] option header in COAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:58:47 -0000 --e0cb4e887eb322b38a048bea6585 Content-Type: text/plain; charset=ISO-8859-1 My interpretation is that (a) the implementation need not encode the default value if the user did not provide one, and furthermore (b) the implementation is free to not transmit the user-provided value if it is equal to the default. (Another reason why I want absence of Uri-Authority to be different from presence with an empty value.) Peter On Wed, Jul 21, 2010 at 3:53 AM, Hari Hara Sudhan R < hariharasudhan.tce@gmail.com> wrote: > Hi all, > > COAP specifications mention some default values for options. > If the application doesnt provide some of these options then COAP > implementation will add the default values to the message and send it. > Is that right? > > Thanks and Regards, > Hari > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --e0cb4e887eb322b38a048bea6585 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My interpretation is that (a) the implementation need not encode the=20 default value if the user did not provide one, and furthermore (b) the=20 implementation is free to not transmit the user-provided value if it is=20 equal to the default.

(Another reason why I want absence of Uri-Auth= ority to be different from presence with an empty value.)

Peter
<= br>
On Wed, Jul 21, 2010 at 3:53 AM, Hari Hara Su= dhan R <hariharasudhan.tce@gmail.com> wrote:
Hi all,

COAP specifications mention some default values for options.
If the application doesnt provide some of these options then COAP
implementation will add the default values to the message and send it.
Is that right?

Thanks and Regards,
Hari
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--e0cb4e887eb322b38a048bea6585-- From pab@peoplepowerco.com Wed Jul 21 11:59: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 7919D3A6B04 for ; Wed, 21 Jul 2010 11:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQn+Nd632jmp for ; Wed, 21 Jul 2010 11:59:24 -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 8F8203A6A6B for ; Wed, 21 Jul 2010 11:59:24 -0700 (PDT) Received: by vws13 with SMTP id 13so2265005vws.31 for ; Wed, 21 Jul 2010 11:59:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.84.209 with SMTP id k17mr303558vcl.107.1279738779947; Wed, 21 Jul 2010 11:59:39 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Wed, 21 Jul 2010 11:59:39 -0700 (PDT) Date: Wed, 21 Jul 2010 13:59:39 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=0016e64bb906626459048bea6728 Subject: [core] proposal: header options may appear at most once 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 Jul 2010 18:59:25 -0000 --0016e64bb906626459048bea6728 Content-Type: text/plain; charset=ISO-8859-1 I don't see any discussion on whether it is permitted to repeat a header option with additional values (i.e., have option delta be zero). I propose that this be disallowed. In practice, I want this because I'm working on a Python developer API for CoAP, and I need a way to search a message instance for a particular option. It's easy to return either a null value (if the option is absent), or the option value (if it is present). If a given option could appear multiple times, I really need the generic get_option operation to return a sequence, which will in virtually all cases be either empty or contain a single element. Having to always dereference the sequence is an unpleasant user experience. But since unhappy Python users aren't really an IETF concern, I'll back up my desire with the following: - None of the currently defined header options are meaningful if repeated. The proposed Accepts option is, but multiple values can easily be encoded in one TLV element by providing a sequence of codes.4 - An HTTP header field-name can appear multiple times only if the field content admits a sequence, and the header content could have been represented by a single field with the catenated content. Thus, there is reason to believe that it is unnecessary to support encoding/decoding multiple instances of any option type. Peter --0016e64bb906626459048bea6728 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't see any discussion on whether it is permitted to repeat a heade= r option with additional values (i.e., have option delta be zero).=A0 I pro= pose that this be disallowed.

In practice, I want this because I'= ;m working on a Python developer API=20 for CoAP, and I need a way to search a message instance for a particular op= tion.=A0 It's easy to return either a null value (if the option is absent), or= =20 the option value (if it is present).=A0 If a given option could appear=20 multiple times, I really need the generic get_option operation to return a= =20 sequence, which will in virtually all cases be either empty or contain a si= ngle element.=A0 Having to always dereference the sequence is an unpleasant user experience.=A0 Bu= t since unhappy Python users aren't really an IETF concern, I'll ba= ck up my desire with the following:
  • None of the currently defined header options are meaningful if repe= ated.=A0 The proposed Accepts option is, but multiple values can easily be = encoded in one TLV element by providing a sequence of codes.4
  • An HTTP header field-name can appear multiple times only if the fie= ld content admits a sequence, and the header content could have been repres= ented by a single field with the catenated content.
Thus, there is= reason to believe that it is unnecessary to support encoding/decoding mult= iple instances of any option type.

Peter
--0016e64bb906626459048bea6728-- From cabocabo@gmail.com Wed Jul 21 12:17: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 CF53C3A69F1 for ; Wed, 21 Jul 2010 12:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ6I6+NPm0Eb for ; Wed, 21 Jul 2010 12:17:24 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A42A23A68C6 for ; Wed, 21 Jul 2010 12:17:23 -0700 (PDT) Received: by ewy22 with SMTP id 22so2869982ewy.31 for ; Wed, 21 Jul 2010 12:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=XcQdAfhMRb6U+Tm01snt570NVwyYhKMqyrICKG0A2gs=; b=oo+f1vvtIWu7FF843/H5pSdJN48uqpO37TwddqutMqOJ01LiIbow6003QBm+V/LYZt /LMNnjKidgjnwUA6q1cTRUcCslfBgKwd42cMrLzF3Kt2xCc0YJ0Lsqj4ibnlUJ6sd6zW AOoI36U6FH4fjIgThBQkiimkFOVR4wtEHMFDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TAD1gCStCC+BCC9O+CGwXFgQv5qL+7hmC791ZJ32xqHgz5qfRMYOzzINxtzycbsS51 ZAS/mkIprnXXe3dEXkl2QzZzWGZcKgKgw5ZZ6ZzPpJDluUsZ8zD2dKpGsf5m+Cv6e4RQ 1dWYZx53vwMEgywvwRK3WELhUX/0sRoMcUl+g= Received: by 10.216.81.139 with SMTP id m11mr665511wee.14.1279739859545; Wed, 21 Jul 2010 12:17:39 -0700 (PDT) Received: from [192.168.217.101] (p5489A687.dip.t-dialin.net [84.137.166.135]) by mx.google.com with ESMTPS id p82sm3585316weq.27.2010.07.21.12.17.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 12:17:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Wed, 21 Jul 2010 21:17:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 19:17:24 -0000 On Jul 21, 2010, at 20:59, Peter Bigot wrote: > I don't see any discussion on whether it is permitted to repeat a = header option with additional values (i.e., have option delta be zero). = I propose that this be disallowed. If we wanted to disallow that, we would encode the delta minus one, not = the delta. (Principle of making it impossible to speak what you don't want to have = said.) Indeed, the idea with encoding just the delta was to enable having = multiple options of the same type (cf. "repeated" in protobuf, = http://code.google.com/apis/protocolbuffers/docs/proto.html). > In practice, I want this because I'm working on a Python developer API = for CoAP, and I need a way to search a message instance for a particular = option. It's easy to return either a null value (if the option is = absent), or the option value (if it is present). If a given option = could appear multiple times, I really need the generic get_option = operation to return a sequence, which will in virtually all cases be = either empty or contain a single element. Having to always dereference = the sequence is an unpleasant user experience. But since unhappy Python = users aren't really an IETF concern, I'll back up my desire with the = following: > =95 None of the currently defined header options are meaningful = if repeated. The proposed Accepts option is, but multiple values can = easily be encoded in one TLV element by providing a sequence of codes.4 I think there was a suggestion using Content-Type repeatedly instead of = a single Accept option. But we haven't decided that yet. > =95 An HTTP header field-name can appear multiple times only if = the field content admits a sequence, and the header content could have = been represented by a single field with the catenated content. HTTP has commas there in its syntax. We don't want to have the same kind of commas, I strongly believe. > Thus, there is reason to believe that it is unnecessary to support = encoding/decoding multiple instances of any option type. We don't know that yet. For instance, if we go for that Uri-Query idea, we will have to allow = multiple instances. BTW, the obvious solution in your Python interface is to offer an Array = exactly when there are multiple instances of an option and the single = instance otherwise. (This is what I'll do in the Ruby version, if I = ever get any more time to work on that.) Gruesse, Carsten From pete.st.pierre@oracle.com Wed Jul 21 12:26: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 46B233A6B18 for ; Wed, 21 Jul 2010 12:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnJ3PdNgerBf for ; Wed, 21 Jul 2010 12:26:24 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 471693A6B09 for ; Wed, 21 Jul 2010 12:26:24 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6LJQc9L013369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jul 2010 19:26:39 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6LJQabC029734; Wed, 21 Jul 2010 19:26:36 GMT Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 446810281279740390; Wed, 21 Jul 2010 12:26:30 -0700 Received: from [192.168.1.56] (/99.57.137.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jul 2010 12:26:29 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-23-785477465 From: "Pete St. Pierre" In-Reply-To: Date: Wed, 21 Jul 2010 12:26:28 -0700 Message-Id: <0FBA7AD5-C812-46C6-BAAF-6D869B03F05C@oracle.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C4749ED.0309:SCFMA4539814,ss=1,fgs=0 Cc: core Subject: Re: [core] option header in COAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 19:26:25 -0000 --Apple-Mail-23-785477465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > My interpretation is that (a) the implementation need not encode the = default value if the user did not provide one, and furthermore (b) the = implementation is free to not transmit the user-provided value if it is = equal to the default. I'm only just beginning a CoAP implementation, but to this point I've = interpreted coap-01 this way as well. ...Pete > (Another reason why I want absence of Uri-Authority to be different = from presence with an empty value.) >=20 > Peter >=20 > On Wed, Jul 21, 2010 at 3:53 AM, Hari Hara Sudhan R = wrote: > Hi all, >=20 > COAP specifications mention some default values for options. > If the application doesnt provide some of these options then COAP > implementation will add the default values to the message and send it. > Is that right? >=20 > Thanks and Regards, > Hari > _______________________________________________ > 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 -- Pete St. Pierre Pete.St.Pierre@oracle.com Sun Labs Oracle=20 16 Network Circle Menlo Park, CA 94025 --Apple-Mail-23-785477465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
My interpretation is that (a) the implementation need not = encode the=20 default value if the user did not provide one, and furthermore (b) the=20= implementation is free to not transmit the user-provided value if it is=20= equal to the default.

I'm only just = beginning a CoAP implementation, but to this point I've interpreted = coap-01 this way as = well.

...Pete


=
--
Pete St. Pierre
Pete.St.Pierre@oracle.comSun Labs
Oracle 
16 Network Circle
Menlo Park, CA = 94025

= --Apple-Mail-23-785477465-- From pab@peoplepowerco.com Wed Jul 21 13:15: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 8E3283A6B2F for ; Wed, 21 Jul 2010 13:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_25=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 bSMpend5GnGY for ; Wed, 21 Jul 2010 13:15:36 -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 5D6463A6B3B for ; Wed, 21 Jul 2010 13:15:29 -0700 (PDT) Received: by wwj40 with SMTP id 40so2276717wwj.13 for ; Wed, 21 Jul 2010 13:15:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.153.3 with SMTP id i3mr680393wbw.171.1279743343893; Wed, 21 Jul 2010 13:15:43 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Wed, 21 Jul 2010 13:15:43 -0700 (PDT) In-Reply-To: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> Date: Wed, 21 Jul 2010 15:15:43 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016363ba7806a9b54048beb77f0 Cc: core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 20:15:39 -0000 --0016363ba7806a9b54048beb77f0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 21, 2010 at 2:17 PM, Carsten Bormann wrote= : > We don't know that yet. > For instance, if we go for that Uri-Query idea, we will have to allow > multiple instances. > FWIW, I would strongly object to a repeated Uri-Query option. A repeated Query-Param option makes sense, but a URI has at most one query part, and i= t does not necessarily encode a sequence of key/value pairs. > =95 An HTTP header field-name can appear multiple times only if the > field content admits a sequence, and the header content could have been > represented by a single field with the catenated content. > > HTTP has commas there in its syntax. > We don't want to have the same kind of commas, I strongly believe. > Sure, not as a general rule, but what's wrong with defining it for specific options? Certain options have meaning when repeated, and it makes sense to allow for that in their representation. For options that make no sense if repeated, the representation should disallow repetition. As you said: prevent the expression of nonsense. Everything's good. I see no reason why Query-Param could not itself encode its multiple values as a sequence of keys with optional values, with the number of such blocks determined implicitly or explicitly. In fact, to define it as a sequence o= f key/optional value blocks separated by ASCII ampersands would make it trivial to encode from a URI, while leaving a higher-level API free to spli= t it into its components for the application developers' convenience without affecting its interpretation. Disallowing option repetition also relieves some of the pressure on the siz= e of the num_options field. BTW, the obvious solution in your Python interface is to offer an Array > exactly when there are multiple instances of an option and the single > instance otherwise. (This is what I'll do in the Ruby version, if I ever > get any more time to work on that.) > As a developer my reaction is "No", but then I admit to a dislike for duck-typing. I don't want my code splattered with: ct =3D message.findOption(ContentType) if ct is None: # process as text/plain ContentType.Default.process(message) elif isinstance(ct, ContentType): # process as ct.value rv.process(message) else: # what the heck does this mean? for sub_ct in ct: sub_ct.process(message) Especially since I'd then have to introduce error-handling at every point-of-call for cases like Content-Type where it makes no sense for the option to be repeated. I can't have my server throw an uncaught exception attempting to invoke a method on a list just because somebody sent me a packet with decodable garbage and I didn't bother to check for the situation; nor do I care for top-level "Something bad happened somewhere"-style recovery. But that's getting towards religion and is off-topic, except to the extent that the same problem will occur in C where run-time type checking is not a= n option and I will be returning either a null pointer or a pointer to a single option value (which may have multiple elements, if appropriate). Peter --0016363ba7806a9b54048beb77f0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 21, 2010 at 2:17 PM, Carsten Bormann= <cabocabo@gmail= .com> wrote:
We don't know that yet.
For instance, if we go for that Uri-Query idea, we will have to allow multi= ple instances.

FWIW, I would strongly object to a = repeated Uri-Query option.=A0 A repeated Query-Param option makes sense, bu= t a URI has at most one query part, and it does not necessarily encode a se= quence of key/value pairs.

> =A0 =A0 =A0 = =95 An HTTP header field-name can appear multiple times only if the field content admits a sequence, and the header content could have=20 been represented by a single field with the catenated content.

HTTP has commas there in its syntax.
We don't want to have the same kind of commas, I strongly believe.

Sure, not as a general rule, but what's wrong with defining it= for specific options?=A0 Certain options have meaning when repeated, and i= t makes sense to allow=20 for that in their representation.=A0 For options that make no sense if repe= ated, the representation should disallow repetition.=A0 As you said: preven= t the expression of nonsense.=A0 Everything's good.

I see no reason why Query-Param could not itself encode its multiple va= lues as a sequence of keys with optional values, with the number of such bl= ocks determined implicitly or explicitly.=A0 In fact, to define it as a seq= uence of key/optional value blocks separated by ASCII ampersands would make= it trivial to encode from a URI, while leaving a higher-level API free to = split it into its components for the application developers' convenienc= e without affecting its interpretation.

Disallowing option repetition also relieves some of the pressure on the= size of the num_options field.

BTW, the obvious solution in your Python interface is to offer an Array exa= ctly when there are multiple instances of an option and the single instance= otherwise. =A0(This is what I'll do in the Ruby version, if I ever get= any more time to work on that.)

As a developer my reaction is "No", but the= n I admit to a dislike for duck-typing.=A0 I don't want my code splatte= red with:

=A0=A0= ct =3D message.findOption(ContentType)
=A0=A0 if ct is None:
=A0=A0=A0=A0 # process as text/plain=
=A0=A0=A0=A0 ContentTyp= e.Default.process(message)
=A0=A0 elif isi= nstance(ct, ContentType):
=A0=A0 =A0 # process as= ct.value
=A0=A0=A0=A0 rv.process(message)
=A0=A0 else:
=A0=A0=A0= =A0 # what the heck=20 does this mean?
=A0=A0 =A0 for sub_ct in ct:
=A0 =A0=A0=A0= =A0 sub_ct.process(message)

Especially since I= 9;d then have to introduce error-handling at every point-of-call for cases = like Content-Type where it makes no sense for the option to be repeated.=A0= I can't have my server throw an uncaught exception attempting to invok= e a method on a list just because somebody sent me a packet with decodable = garbage and I didn't bother to check for the situation; nor do I care f= or top-level "Something bad happened somewhere"-style recovery.
But that's getting towards religion and is off-topic, except to the= extent that the same problem will occur in C where run-time type checking = is not an option and I will be returning either a null pointer or a pointer= to a single option value (which may have multiple elements, if appropriate= ).

Peter
--0016363ba7806a9b54048beb77f0-- From brian.tridium@gmail.com Wed Jul 21 14:40: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 8BF173A6899 for ; Wed, 21 Jul 2010 14:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_25=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 yHGSfMjKwPbD for ; Wed, 21 Jul 2010 14:40:43 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3A1CF3A6863 for ; Wed, 21 Jul 2010 14:40:41 -0700 (PDT) Received: by bwz7 with SMTP id 7so574098bwz.31 for ; Wed, 21 Jul 2010 14:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GFucWsfimPnf3xwvhiphbKAOuACsO7oy/19HzcOCM/E=; b=i8edbiLNEPObfhGdSTl2xKca2mCu1kjoNF8xIFna43RCJMg4UnRv7nwBMCK9JQZ+ER j5L86K+vDSH9TDDegOhQ7/Afwxrso5HH6Y52+immKCzHiL1ksxCtlASsCY8M99Gmn9Dj DfjTnQjU0dz5GqeHIcVmieVr2n27dUVLJUGbA= 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=u7jqSMt8/yPqhAiVVIG1V99AzR+omMEEa0BVx0dkatn9TrM8YbMa7AO/WrV+LTLevd ITbFC3JO563yDROEJjMAI8OLWFByqmRksjrocxHQ0PmSYBKZEXGtxHlfZUuTCa56y/Bz JmVBs3aQivSQ4KpXdirUvS/hV0SnQ0r8puW3o= MIME-Version: 1.0 Received: by 10.204.179.19 with SMTP id bo19mr471348bkb.209.1279748453317; Wed, 21 Jul 2010 14:40:53 -0700 (PDT) Received: by 10.204.113.70 with HTTP; Wed, 21 Jul 2010 14:40:53 -0700 (PDT) In-Reply-To: References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> Date: Wed, 21 Jul 2010 17:40:53 -0400 Message-ID: From: Brian Frank To: Peter Bigot Content-Type: multipart/alternative; boundary=001636c5a93cf63f56048beca7c6 Cc: Carsten Bormann , core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 21:40:44 -0000 --001636c5a93cf63f56048beca7c6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think option headers should only appear once. So I like Carstens suggestion that the delta is encoded minus one (so that you can never have zero). Multiple options seems really confusing from a semantic perspective (especially given our current list of options such as Uri-Path, etc) On Wed, Jul 21, 2010 at 4:15 PM, Peter Bigot wrote: > On Wed, Jul 21, 2010 at 2:17 PM, Carsten Bormann wrot= e: > >> We don't know that yet. >> For instance, if we go for that Uri-Query idea, we will have to allow >> multiple instances. >> > > FWIW, I would strongly object to a repeated Uri-Query option. A repeated > Query-Param option makes sense, but a URI has at most one query part, and= it > does not necessarily encode a sequence of key/value pairs. > > > > =95 An HTTP header field-name can appear multiple times only if t= he >> field content admits a sequence, and the header content could have been >> represented by a single field with the catenated content. >> >> HTTP has commas there in its syntax. >> We don't want to have the same kind of commas, I strongly believe. >> > > Sure, not as a general rule, but what's wrong with defining it for specif= ic > options? Certain options have meaning when repeated, and it makes sense = to > allow for that in their representation. For options that make no sense i= f > repeated, the representation should disallow repetition. As you said: > prevent the expression of nonsense. Everything's good. > > I see no reason why Query-Param could not itself encode its multiple valu= es > as a sequence of keys with optional values, with the number of such block= s > determined implicitly or explicitly. In fact, to define it as a sequence= of > key/optional value blocks separated by ASCII ampersands would make it > trivial to encode from a URI, while leaving a higher-level API free to sp= lit > it into its components for the application developers' convenience withou= t > affecting its interpretation. > > Disallowing option repetition also relieves some of the pressure on the > size of the num_options field. > > BTW, the obvious solution in your Python interface is to offer an Array >> exactly when there are multiple instances of an option and the single >> instance otherwise. (This is what I'll do in the Ruby version, if I eve= r >> get any more time to work on that.) >> > > As a developer my reaction is "No", but then I admit to a dislike for > duck-typing. I don't want my code splattered with: > > ct =3D message.findOption(ContentType) > if ct is None: > # process as text/plain > ContentType.Default.process(message) > elif isinstance(ct, ContentType): > # process as ct.value > rv.process(message) > else: > # what the heck does this mean? > for sub_ct in ct: > sub_ct.process(message) > > Especially since I'd then have to introduce error-handling at every > point-of-call for cases like Content-Type where it makes no sense for the > option to be repeated. I can't have my server throw an uncaught exceptio= n > attempting to invoke a method on a list just because somebody sent me a > packet with decodable garbage and I didn't bother to check for the > situation; nor do I care for top-level "Something bad happened > somewhere"-style recovery. > > But that's getting towards religion and is off-topic, except to the exten= t > that the same problem will occur in C where run-time type checking is not= an > option and I will be returning either a null pointer or a pointer to a > single option value (which may have multiple elements, if appropriate). > > Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001636c5a93cf63f56048beca7c6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think option headers should only appear once. =A0So I like Carstens sugge= stion that the delta is encoded minus one (so that you can never have zero)= .

Multiple options seems really confusing from a semanti= c perspective (especially given our current list of options such as Uri-Pat= h, etc)

On Wed, Jul 21, 2010 at 4:15 PM, Peter Bigot= <pab@peoplep= owerco.com> wrote:
On Wed, Jul 21, 2010 at 2:17 P= M, Carsten Bormann <cabocabo@gmail.com> wrote:
We don't know that yet.
For instance, if we go for that Uri-Query idea, we will have to allow multi= ple instances.

FWIW, I would strongly object= to a repeated Uri-Query option.=A0 A repeated Query-Param option makes sen= se, but a URI has at most one query part, and it does not necessarily encod= e a sequence of key/value pairs.


> =A0 =A0 =A0 =95 An HTTP header field-name can appear multiple times only if the field content admits a sequence, and the header content could have=20 been represented by a single field with the catenated content.

HTTP has commas there in its syntax.
We don't want to have the same kind of commas, I strongly believe.

Sure, not as a general rule, but what's wrong with defin= ing it for specific options?=A0 Certain options have meaning when repeated,= and it makes sense to allow=20 for that in their representation.=A0 For options that make no sense if repe= ated, the representation should disallow repetition.=A0 As you said: preven= t the expression of nonsense.=A0 Everything's good.

I see no reason why Query-Param could not itself encode its multiple va= lues as a sequence of keys with optional values, with the number of such bl= ocks determined implicitly or explicitly.=A0 In fact, to define it as a seq= uence of key/optional value blocks separated by ASCII ampersands would make= it trivial to encode from a URI, while leaving a higher-level API free to = split it into its components for the application developers' convenienc= e without affecting its interpretation.

Disallowing option repetition also relieves some of the pressure on the= size of the num_options field.

BTW, the obvious solution in your Python interface is to offer an Array exa= ctly when there are multiple instances of an option and the single instance= otherwise. =A0(This is what I'll do in the Ruby version, if I ever get= any more time to work on that.)

As a developer my reaction is "No", b= ut then I admit to a dislike for duck-typing.=A0 I don't want my code s= plattered with:

= =A0=A0 ct =3D message.findOption(ContentType)
=A0=A0 if ct is None:
=A0=A0=A0=A0 # process as text/plain
=A0=A0=A0=A0 ContentType.= Default.process(message)
=A0=A0 elif isinstanc= e(ct, ContentType):
=A0=A0 =A0 # process as c= t.value
=A0=A0=A0=A0 rv.process(message)
=A0=A0 else:
=A0=A0=A0=A0= # what the heck=20 does this mean?
=A0=A0 =A0 for sub_ct in ct:
=A0 =A0=A0=A0=A0 = sub_ct.process(message)

Especially since I'd = then have to introduce error-handling at every point-of-call for cases like= Content-Type where it makes no sense for the option to be repeated.=A0 I c= an't have my server throw an uncaught exception attempting to invoke a = method on a list just because somebody sent me a packet with decodable garb= age and I didn't bother to check for the situation; nor do I care for t= op-level "Something bad happened somewhere"-style recovery.

But that's getting towards religion and is off-topic, except to the= extent that the same problem will occur in C where run-time type checking = is not an option and I will be returning either a null pointer or a pointer= to a single option value (which may have multiple elements, if appropriate= ).

Peter

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


--001636c5a93cf63f56048beca7c6-- From cabocabo@gmail.com Wed Jul 21 15:14: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 242043A696E for ; Wed, 21 Jul 2010 15:14:33 -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 UF2HSNGnZa3E for ; Wed, 21 Jul 2010 15:14:29 -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 969233A68F0 for ; Wed, 21 Jul 2010 15:14:28 -0700 (PDT) Received: by wwj40 with SMTP id 40so2355405wwj.13 for ; Wed, 21 Jul 2010 15:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=xksBiGAoflmVHBjy1wxujbP3x0MCyiD5S1utRBJG/ts=; b=gsSLV+lk9XPBJ94PtL13IB/DxYEfZFfaXuDzBw7/sBoVfQty+9sM3617ZyEt2KuF86 V07CyEqX+hTlS5rrm1IM06opLOSZ8eJcUPp9MrK+ZFWktkQevBC265IZdTLyXTNvmhUL huTjN/B6AauFgQEGeq+2kYJloC6iWHYMPawOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=h99Ez4D1Tsj9w8elpyhM8d2S3JiKDtJjC5/6p6WrMFOdaRMNjAT46X+IbAxSH6xoL+ IWjGYAXN+F4IogjXeYxv6BQbdQR1kyiKHlcu2nsXCQ7cyRpM6l4A8BI3gGj/t23NxN8F x8H8cn4SdSwKATtcqKvf0YcidMpnHrq9YzRl4= Received: by 10.227.7.212 with SMTP id e20mr876310wbe.44.1279750484740; Wed, 21 Jul 2010 15:14:44 -0700 (PDT) Received: from [192.168.217.101] (p5489A687.dip.t-dialin.net [84.137.166.135]) by mx.google.com with ESMTPS id p82sm3663142weq.27.2010.07.21.15.14.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 15:14:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2010 00:14:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 22:14:34 -0000 > code splattered with: > [...] error-handling at every point-of-call Well, this is not the list to discuss coding practices, but if you don't = want that, then don't do that. Do it once in the option parser then. In the C code for a simple device, the processing is likely to happen = inline instead through such an abstraction, so you know exactly what to = do (e.g., put a mask bit into a byte for each of the very few = content-types you actually support, and then match that against the ones = available for the resource that you want to deliver). But none of this discussion has much bearing on whether it is good = protocol practice to allow multiple-instance options. Not having them means that each time we need them we need to invent some = array notation inside the option instead. For Accept, that kind of worked once we made content-type = one-size-fits-all, so a fixed-size (one-byte) array works fine. (Unless we throw out Accept and replace it with Content-Type.) It didn't look so nice when we still had multi-byte content-types. So let's look at another example: what about Etags in requests? These are variable-length, and we are proposing you can send multiple to = allow a 304 response for any of them. (Of course, you can now argue you don't like that proposal, but that = would look like the encoding should determine what is possible = semantically.) Gruesse, Carsten From cabo@tzi.org Thu Jul 22 00:37: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 642F93A69C7 for ; Thu, 22 Jul 2010 00:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7nlBjOY2nYk for ; Thu, 22 Jul 2010 00:37:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 03F763A689E for ; Thu, 22 Jul 2010 00:37:05 -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 o6K8qeTN001928; Tue, 20 Jul 2010 10:52:40 +0200 (CEST) Received: from [192.168.217.101] (p5489E846.dip.t-dialin.net [84.137.232.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 58B03D27A; Tue, 20 Jul 2010 10:52:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 20 Jul 2010 10:52:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19A357D2-48CA-44A3-8112-9C6263E7E123@nokia.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-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: Thu, 22 Jul 2010 07:37:07 -0000 On Jun 24, 2010, at 12:00, Angelo P. Castellani wrote: > The server cannot directly know whether the sent response has been > received, how can responses partecipate to the Reno-like AIMD scheme > depicted in the document? (in my opinion a response can be considered > to be "correctly received" if the server doesn't receive in the > subsequent time window of X seconds a retransmission of the served > request) Two observations here. First, any TCP server has the same problem with the SYN ACK. Unless I have missed some recent work, we don't really know how to = congestion control initial responses. Yes, a CoAP response might be up to 20 times larger than a SYN ACK. This is maybe one area where a CC algorithm could change something:=20 The server could start sending smaller packets (using the block option). Second, any retransmission of the original request by the other party = will be subject to binary backoff. It is not clear to me how a server could add to that, except by sending = smaller packets (see above). Since retransmissions should be done by the peer by using the same TID, = a server can get a pretty good measurement of how many ACKs it needs to = send to get one through. This could go into per-peer or global CC = state, in turn influencing the default block size. Global state makes a lot of sense if the bottleneck is likely to be = close to the server. One other interesting observation: The way the block option is defined right now, we assume a constant = block size for all transactions in a transfer. This helps simplifying things a lot, but reduces the granularity of = adaptation possible in a packet-size adaptive CC algorithm. I'd still rather stick with a constant block size. Gruesse, Carsten From cabo@tzi.org Thu Jul 22 00:37: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 8880D3A69C9 for ; Thu, 22 Jul 2010 00:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 Fssa7s9OMfA1 for ; Thu, 22 Jul 2010 00:37:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 08F193A69C2 for ; Thu, 22 Jul 2010 00:37:06 -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 o6K7ZEug024312; Tue, 20 Jul 2010 09:35:14 +0200 (CEST) Received: from [192.168.217.101] (p5489E846.dip.t-dialin.net [84.137.232.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 39CA3D1C8; Tue, 20 Jul 2010 09:35:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 20 Jul 2010 09:35:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <017CAC3B-BD10-4112-81EC-CAEFF825E68A@tzi.org> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: [core] URI splitting (was: Re: explicit option for URI query part) 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 Jul 2010 07:37:09 -0000 On Jul 20, 2010, at 00:32, Peter Bigot wrote: > Uri-Query Interesting. That would be a critical option, so a node that does not want to = implement queries would reject them without any additional code. The split into scheme/authority/path could make simple nodes simpler, = because they only have to implement Uri-Path. On the other hand, accepting this implementation strategy means that = nodes should not send gratuitous Scheme/Authority options if the default = value is fine. (This is probably already a good idea for space reasons. But it does = mean a little more code for nodes that do need to send them sometimes.) Note that this would mean a quite different default URI parse strategy = than for HTTP, where sending a Host: header is mandatory. With a URI of coap://ns.tzi.org:61616 I certainly don't have to send the Uri-Scheme option (as the default = value is fine), but do I have to send the Uri-Authority header? If we support what is called "virtual hosts" in HTTP (multiple authority = values on one IP address), one would have to. How important are virtual hosts then on the CoAP side? (Less important on IPv6 than they were for HTTP on IPv4, but how much = less?) Gruesse, Carsten From pab@peoplepowerco.com Thu Jul 22 05:01:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686B83A685C for ; Thu, 22 Jul 2010 05:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu0+m1l0WTp1 for ; Thu, 22 Jul 2010 05:01:41 -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 317143A6403 for ; Thu, 22 Jul 2010 05:01:40 -0700 (PDT) Received: by vws10 with SMTP id 10so45884vws.31 for ; Thu, 22 Jul 2010 05:01:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.96.4 with SMTP id f4mr661337vcn.127.1279800117319; Thu, 22 Jul 2010 05:01:57 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Thu, 22 Jul 2010 05:01:57 -0700 (PDT) In-Reply-To: <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> Date: Thu, 22 Jul 2010 07:01:57 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e64714046059f4048bf8af79 Cc: core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 12:01:42 -0000 --0016e64714046059f4048bf8af79 Content-Type: text/plain; charset=ISO-8859-1 No, Etags is the first example where the same option appearing multiple times is clearly preferable to one option appearance that encodes multiple values. I can't assess whether the motivating use-case is valid, and leave that to those who are concerned with caching CoAP. Defining a mechanism for multiple values that is option-independent might ultimately be a better approach, but for now I withdraw the proposal. I request the following compensating clarifications in draft -02: - Each option definition should indicate whether the minimum number of occurrences is zero or one (optional or required); - Each option definition should indicate whether the maximum number of occurrences is one or unbounded; - Message recipients are not obligated to diagnose violation of multiplicity restrictions for any option (meaning, for example, that they can do whatever they want if they receive multiple Uri-Path options in a PUT or GET message). (Motivation for that last one: unless a node is obligated to recognize an option even if it doesn't support it, a requirement we don't currently have, it can't diagnose multiplicity violations. I sure hope this doesn't mean people will start to retrieve multiple documents with a single request by including multiple URIs....) Peter On Wed, Jul 21, 2010 at 5:14 PM, Carsten Bormann wrote: > ... > But none of this discussion has much bearing on whether it is good protocol > practice to allow multiple-instance options. > > Not having them means that each time we need them we need to invent some > array notation inside the option instead. > For Accept, that kind of worked once we made content-type > one-size-fits-all, so a fixed-size (one-byte) array works fine. > (Unless we throw out Accept and replace it with Content-Type.) > It didn't look so nice when we still had multi-byte content-types. > > So let's look at another example: what about Etags in requests? > These are variable-length, and we are proposing you can send multiple to > allow a 304 response for any of them. > (Of course, you can now argue you don't like that proposal, but that would > look like the encoding should determine what is possible semantically.) > > Gruesse, Carsten > > --0016e64714046059f4048bf8af79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, Etags is the first example where the same option appearing multiple tim= es is clearly preferable to one option appearance that encodes multiple val= ues.=A0 I can't assess whether the motivating use-case is valid, and le= ave that to those who are concerned with caching CoAP.

Defining a mechanism for multiple values that is=20 option-independent might ultimately be a better approach, but for now I wit= hdraw the proposal.=A0

I request the following compensating clarifi= cations in draft -02:
  • Each option definition should indicate whe= ther the minimum number of occurrences is zero or one (optional or required= );
  • Each option definition should indicate whether the maximum number of oc= currences is one or unbounded;
  • Message recipients are not obligated= to diagnose violation of multiplicity restrictions for any option (meaning= , for example, that they can do whatever they want if they receive multiple= Uri-Path options in a PUT or GET message).
(Motivation for that last one: unless a node is obligated to recognize= an option even if it doesn't support it, a requirement we don't cu= rrently have, it can't diagnose multiplicity violations.=A0 I sure hope= this doesn't mean people will start to retrieve multiple documents wit= h a single request by including multiple URIs....)

Peter

On Wed, Jul 21, 2010 at 5:14 PM= , Carsten Bormann <cabocabo@gmail.com> wrote:
...
But none of this discussion has much bearing on whether it is good proto= col practice to allow multiple-instance options.

Not having them means that each time we need them we need to invent some ar= ray notation inside the option instead.
For Accept, that kind of worked once we made content-type one-size-fits-all= , so a fixed-size (one-byte) array works fine.
(Unless we throw out Accept and replace it with Content-Type.)
It didn't look so nice when we still had multi-byte content-types.

So let's look at another example: what about Etags in requests?
These are variable-length, and we are proposing you can send multiple to al= low a 304 response for any of them.
(Of course, you can now argue you don't like that proposal, but that wo= uld look like the encoding should determine what is possible semantically.)=

Gruesse, Carsten


--0016e64714046059f4048bf8af79-- From angelo.castellani@gmail.com Thu Jul 22 05:22:02 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 C87FB3A69F4 for ; Thu, 22 Jul 2010 05:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 egDnNjVKolHb for ; Thu, 22 Jul 2010 05:21:59 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2830A3A6A12 for ; Thu, 22 Jul 2010 05:21:56 -0700 (PDT) Received: by bwz7 with SMTP id 7so955160bwz.31 for ; Thu, 22 Jul 2010 05:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=BpvI1NjETJK9w2lCWXSaqlVUARCAafsPV8KnLAcJ2+A=; b=NwWuoF1HpuONBtNWbxAn9zTOSVhi+Q6lHsnn2B0YleoPNWTSEDNJIQy3EZUFwPhH/Z M5E6bXzPtqrN7LqM0JK7spSD+gQG3wutodc1khNOgZ8zfbwHEGIzMoHfhx5jVroN+XMu uClm6006gBQJPum0WW3YPJIjEggsixuLKHiV4= 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; b=byhmt3kAoCo9X+ECMFMMtyuaSVsaG3OC0zwCI6WKo/prGVRBCiDYCQNFs14YRAjarH ORR79YnADYB76UuU67h6Tj1CkHsHHbA0YBjNHSOyHMrX98xphp3364+WPTTqb6d7AufD MY78QWz+4X3dxkYdG4FMGW/8ZVOdw9e6blNYI= Received: by 10.204.127.65 with SMTP id f1mr1425226bks.55.1279801333163; Thu, 22 Jul 2010 05:22:13 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.204.24.13 with HTTP; Thu, 22 Jul 2010 05:21:53 -0700 (PDT) In-Reply-To: References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> From: "Angelo P. Castellani" Date: Thu, 22 Jul 2010 14:21:53 +0200 X-Google-Sender-Auth: RcevTPZdLCTU1G3ilwGBzk3GhD4 Message-ID: To: Peter Bigot Content-Type: text/plain; charset=ISO-8859-1 Cc: Carsten Bormann , core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 12:22:02 -0000 On Thu, Jul 22, 2010 at 14:01, Peter Bigot wrote: > multiple Uri-Path options in a PUT or GET In my opinion this is clearly a very useful use-case for multiple options... GET /sensor/temperature /sensor/humidity /system/threshold etc. etc. we can GET multiple resources with a single message.. Angelo From hariharasudhan.tce@gmail.com Thu Jul 22 05:38: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 70A873A67B8 for ; Thu, 22 Jul 2010 05:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 OiKTyp7JZxVs for ; Thu, 22 Jul 2010 05:38:06 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 5CCC03A657C for ; Thu, 22 Jul 2010 05:38:06 -0700 (PDT) Received: by gxk1 with SMTP id 1so4864058gxk.31 for ; Thu, 22 Jul 2010 05:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ymaDu8WPS2IP37IYtrHm0uYeD3WWXPNKaHLTt1RhYZw=; b=fwwnDukMdx9YPhws0cHlVITMMidSXV1yUC5WyvvNUXLdde2foekIpCWFyc8t5QWxT9 LlR2+wUyaBMgANQyLOx0D8dxoUblYZjXh2kmIHiOBySp0XWnqtObDt+D1cPipw7xTdDW eFTAwGxTjt3pBdi6swUdyhUKvehOvwZe2Fliw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FNqyaNSCeQij5LQLquc9B5JA1rPHNwm8735ZF+IEOPjZ6ZWbuVI6qc+VmLfiwAOQEy gb0htZhxrXdwtSogvcnQ/W5jZv8RXKv2Ngf8WzxuqMEmJ0qCQlV6/0Gv0O8kB2HUJkKj zkiBDsHRkouIuiBleUx6UaHpTanNRKKs4otD8= MIME-Version: 1.0 Received: by 10.150.66.11 with SMTP id o11mr942831yba.432.1279802303326; Thu, 22 Jul 2010 05:38:23 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Thu, 22 Jul 2010 05:38:23 -0700 (PDT) Date: Thu, 22 Jul 2010 18:08:23 +0530 Message-ID: From: Hari Hara Sudhan R To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Clarification regarding the length field mentioned for options in COAP Specification 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 Jul 2010 12:38:08 -0000 Hi, I have a doubt regarding the length field mentioned for options in COAP specification. I feel that TLV format mentioned for header options is not clear. So please consider giving some example for this in the future versions. To validate my understanding I have provided an example. Please let me know whether my understanding is correct Example: Suppose app want to send URI-SCHEME option as first and only option and if the the length of option value is say 200 My option header would be some thing like this. +---+---+---+---+---+---+ | 4 | 14| data(1 to 15) | +---+---+---+---+---+---+ for 15..270: +---+---+---+---+---+---+---+ | 0 | 185 | data(16-200) | +---+---+---+---+---+---+---+ Thanks and Regards, Hari Hara Sudhan From cabocabo@gmail.com Thu Jul 22 08:05: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 CC3B73A6B63 for ; Thu, 22 Jul 2010 08:05: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=[AWL=0.000, 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 sTcCtqr2kihR for ; Thu, 22 Jul 2010 08:05:31 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A78373A6B7C for ; Thu, 22 Jul 2010 08:05:30 -0700 (PDT) Received: by bwz7 with SMTP id 7so1079319bwz.31 for ; Thu, 22 Jul 2010 08:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=UpaSbeVgG0PbKm/53v0SNhiDWsmcdjzmnyG7EJ57IK0=; b=Lde1y/Mb8cOH8esaO29rquz19Y6Xu7TfaYu9VwZscjV0eXo0P4W5Iu/gJobywUBdEX ffRBlKWjZKWirLjNJODvtSPpTnVnFGXTCLt5CLWJDAfu+Ko+bfmDYa+h1c7jcXVSu8fQ ez+Jekxx5OJHiWX4f2wUVLbXeKQ9QvdHbmsFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=sgyR4ntkqm39CSQPj4a39rTi8eNyjbqtnb570++WUCGCJoHimUqY76iZlpSBJO16YP 8xvbKbh9m6svuJPeErjxdaDejtHJ1FGapip+VTSslkMHQX7VDr/V/+Su6kvcJA8grW+7 IW5w9GaAUcZgoME+0ePaHFQfGf07daI79iAvY= Received: by 10.204.34.2 with SMTP id j2mr1573289bkd.21.1279811147342; Thu, 22 Jul 2010 08:05:47 -0700 (PDT) Received: from [192.168.217.101] (p5489AD20.dip.t-dialin.net [84.137.173.32]) by mx.google.com with ESMTPS id x19sm30300646bkv.9.2010.07.22.08.05.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 08:05:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2010 17:05:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 15:05:31 -0000 On Jul 22, 2010, at 14:21, Angelo P. Castellani wrote: > we can GET multiple resources with a single message.. I'd rather do this with payload-length (coap-misc-05) and multiple = messages in one packet. There is too much infrastructure that would be needed to carry multiple = GETs in one message. Gruesse, Carsten From pab@peoplepowerco.com Thu Jul 22 08:28: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 7A3233A6BC5 for ; Thu, 22 Jul 2010 08:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T2Fkir60gjx for ; Thu, 22 Jul 2010 08:28:38 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4B7FF3A6B91 for ; Thu, 22 Jul 2010 08:28:38 -0700 (PDT) Received: by bwz7 with SMTP id 7so1102190bwz.31 for ; Thu, 22 Jul 2010 08:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.8.7 with SMTP id l7mr685212mui.32.1279812529390; Thu, 22 Jul 2010 08:28:49 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Thu, 22 Jul 2010 08:28:48 -0700 (PDT) In-Reply-To: References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> Date: Thu, 22 Jul 2010 10:28:48 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016364267ab32c673048bfb9341 Cc: core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 15:28:39 -0000 --0016364267ab32c673048bfb9341 Content-Type: text/plain; charset=ISO-8859-1 Agreed. For the specific case, I'd simple GET /sensor and have the implementation bundle its subcomponents appropriately. The thought of returning the values for /.well-known/r, /sensor, and /firmware.img in one response body makes me shudder. Peter On Thu, Jul 22, 2010 at 10:05 AM, Carsten Bormann wrote: > On Jul 22, 2010, at 14:21, Angelo P. Castellani wrote: > > > we can GET multiple resources with a single message.. > > I'd rather do this with payload-length (coap-misc-05) and multiple messages > in one packet. > There is too much infrastructure that would be needed to carry multiple > GETs in one message. > > Gruesse, Carsten > > --0016364267ab32c673048bfb9341 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed.=A0 For the specific case, I'd simple GET /sensor and have the i= mplementation bundle its subcomponents appropriately.=A0 The thought of ret= urning the values for /.well-known/r, /sensor, and /firmware.img in one res= ponse body makes me shudder.

Peter

On Thu, Jul 22, 2010 at 10:05 A= M, Carsten Bormann <cabocabo@gmail.com> wrote:
On Jul 22, 2010, at 14:21, Angelo P. Castellani wrote:
> we can GET multiple resources with a single message..

I'd rather do this with payload-length (coap-misc-05) and multipl= e messages in one packet.
There is too much infrastructure that would be needed to carry multiple GET= s in one message.

Gruesse, Carsten


--0016364267ab32c673048bfb9341-- From pab@peoplepowerco.com Thu Jul 22 08:51: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 B24853A69F6 for ; Thu, 22 Jul 2010 08:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, WEIRD_PORT=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 VVDhwqtx7h3D for ; Thu, 22 Jul 2010 08:51:02 -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 0F2633A67AF for ; Thu, 22 Jul 2010 08:51:01 -0700 (PDT) Received: by vws10 with SMTP id 10so302231vws.31 for ; Thu, 22 Jul 2010 08:51:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.88.199 with SMTP id b7mr757186vcm.223.1279813878537; Thu, 22 Jul 2010 08:51:18 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Thu, 22 Jul 2010 08:51:18 -0700 (PDT) In-Reply-To: <07F51D76-85C1-4328-95AE-1BDC6A4874AD@gmail.com> References: <80746C37-A1D4-44D8-BAAF-F85B5408DFEE@oracle.com> <07F51D76-85C1-4328-95AE-1BDC6A4874AD@gmail.com> Date: Thu, 22 Jul 2010 10:51:18 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016362851529be0d1048bfbe366 Cc: "Pete St. Pierre" , core Subject: Re: [core] private option type codes 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 Jul 2010 15:51:03 -0000 --0016362851529be0d1048bfbe366 Content-Type: text/plain; charset=ISO-8859-1 Whether the option type is encoded as deltas or values is a subject for a different post. In any case, it seems 8 bits is considered enough for the option type. Rather than use just the low bit for critical/elective, I'd suggest two bits to partition the space into IANA-controlled critical (64 values), IANA-controlled elective (128 values), and private (64 values). If delta-encoding is used, the least significant bits would be the best choice; otherwise the most significant bits would be more natural. Other balances could be argued as long as the three categories are maintained; I'm not committed to 64/128/64. I don't think observations from the test server in the first few weeks of prototype implementation provide much evidence regarding what the use of options will be once we understand what's required to use CoAP in industrial situations. I expect we're going to find that things like Uri-Authority aren't as optional as they first appear. For example, see section 6.3.2.1 in http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3, which highlights the problems inferring URI components from envelope information gave to HTTP. Since Uri-Authority is not optional if the server is a proxy, making it optional would require a client to know whether it's talking directly to the authoritative server, a situation which requires external knowledge and which might change over time without a change to the URI itself. Peter On Tue, Jul 20, 2010 at 12:34 PM, Carsten Bormann wrote: > On Jul 20, 2010, at 18:45, Pete St. Pierre wrote: > > > This is a really good question. I'm curious if we're really using the > Option Code field in the most efficient manner right now. [...] > > Out of curiousity, in the original options code creation, how many IANA > approved options were we really expecting? It is expected to be an even > split between "criticial" options and "elective" options? > > Right now, we have more critical than elective ones. I expect that to > change a bit when people start thinking up real "options" though. > > How critical (pun intended) is it to have an even split? We would have > wasted a bit on the critical/elective decision anyway, and using it for the > option type as well is prudent. > > I think the interesting observation is that in nearly all messages that > came to coap://ns.tzi.org:61616 so far, *all* option headers (the things > in front of option values) were exactly one byte. Longer takes too much > space, shorter is a pain to process. So I think we are *exactly* where we > want to be. > > Gruesse, Carsten > > --0016362851529be0d1048bfbe366 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Whether the option type is encoded as deltas or values is a subject for a d= ifferent post.=A0 In any case, it seems 8 bits is considered enough for the= option type.=A0 Rather than use just the low bit for critical/elective, I'd suggest two bits to partition the space into IANA-controlled critic= al (64 values), IANA-controlled elective (128 values), and private (64 valu= es).=A0 If delta-encoding is used, the least significant bits would be the = best choice; otherwise the most significant bits would be more natural.=A0 = Other balances could be argued as long as the three categories are maintain= ed; I'm not committed to 64/128/64.

I don't think observations from the test server in the first few we= eks of prototype implementation provide much evidence regarding what the us= e of options will be once we understand what's required to use CoAP in = industrial situations.=A0 I expect we're going to find that things like= Uri-Authority aren't as optional as they first appear.=A0 For example,= see section 6.3.2.1 in http://www.ics.uci.edu/~fielding/pubs/di= ssertation/evaluation.htm#sec_6_3, which highlights the problems inferr= ing URI components from envelope information gave to HTTP.=A0 Since Uri-Aut= hority is not optional if the server is a proxy, making it optional would r= equire a client to know whether it's talking directly to the authoritat= ive server, a situation which requires external knowledge and which might c= hange over time without a change to the URI itself.

Peter

On Tue, Jul 20, 2010 at 12:34 P= M, Carsten Bormann <cabocabo@gmail.com> wrote:
On Jul 20, 2010, at 18:45, Pete St. Pierre wrote:

> This is a really good question. I'm curious if we're really us= ing the Option Code field in the most efficient manner right now. [...]
> Out of curiousity, in the original options code crea= tion, how many IANA approved options were we really expecting? =A0It is exp= ected to be an even split between "criticial" options and "e= lective" options?

Right now, we have more critical than elective ones. =A0I expect that= to change a bit when people start thinking up real "options" tho= ugh.

How critical (pun intended) is it to have an even split? =A0We would have w= asted a bit on the critical/elective decision anyway, and using it for the = option type as well is prudent.

I think the interesting observation is that in nearly all messages that cam= e to coap://ns.tzi.or= g:61616 so far, *all* option headers (the things in front of option val= ues) were exactly one byte. =A0Longer takes too much space, shorter is a pa= in to process. =A0So I think we are *exactly* where we want to be.

Gruesse, Carsten


--0016362851529be0d1048bfbe366-- From pab@peoplepowerco.com Thu Jul 22 08:54: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 0973B3A6BAF for ; Thu, 22 Jul 2010 08:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[AWL=-1.102, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 rXyJRh1gZo2w for ; Thu, 22 Jul 2010 08:54:55 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8454C3A6B67 for ; Thu, 22 Jul 2010 08:54:54 -0700 (PDT) Received: by bwz7 with SMTP id 7so1128212bwz.31 for ; Thu, 22 Jul 2010 08:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.192.20 with SMTP id u20mr723818mup.46.1279814111107; Thu, 22 Jul 2010 08:55:11 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Thu, 22 Jul 2010 08:55:11 -0700 (PDT) Date: Thu, 22 Jul 2010 10:55:11 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/mixed; boundary=001636a7d85e78b5b1048bfbf172 Subject: [core] header option encoding 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 Jul 2010 15:54:56 -0000 --001636a7d85e78b5b1048bfbf172 Content-Type: multipart/alternative; boundary=001636a7d85e78b5aa048bfbf170 --001636a7d85e78b5aa048bfbf170 Content-Type: text/plain; charset=ISO-8859-1 Out of curiosity, I just wrote stub C routines to encode and decode options and measured the size of space-optimized MSP430 object code. Between delta management, fencepost processing for large deltas, and variable option lengths, the code sizes are 66 bytes to process the options, and 190 to encode them. In contrast, an encoding that uses one byte for the option code, one byte for the length, and the value requires 28 bytes to process and 44 bytes to encode them. Of course, this is strongly affected by what "process" means: for the purposes of this test I simply summed the observed option types and lengths, to ensure the values were correctly decoded. My code may be poor or wrong, since I only compiled it and didn't run it; attached for anybody who wants to optimize it. Are we locked to the current option encoding? OK if we are, but a 135% space penalty for decoding and a 330% penalty for encoding is high for something that saves at most one byte per encoded option per message. 00000000 g F .text 0000003e process_options 00000086 g F .text 000000be encode_option 0000003e g F .text 0000001c alt_process_options 0000005a g F .text 0000002c alt_encode_option Peter --001636a7d85e78b5aa048bfbf170 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Out of curiosity, I just wrote stub C routines to encode and decode options= and measured the size of space-optimized MSP430 object code.

Betwee= n delta management, fencepost processing for large deltas, and variable opt= ion lengths, the code sizes are 66 bytes to process the options, and 190 to= encode them.

In contrast, an encoding that uses one byte for the option code, one by= te for the length, and the value requires 28 bytes to process and 44 bytes = to
encode them.

Of course, this is strongly affected by what &quo= t;process" means: for the purposes of this test I simply summed the ob= served option types and lengths,
to ensure the values were correctly decoded.=A0 My code may be poor or wron= g, since I only compiled it and didn't run it; attached for anybody who= wants to optimize it.

Are we locked to the current option encoding?= =A0 OK if we are, but a 135% space penalty for decoding and a 330% penalty = for encoding is high for
something that saves at most one byte per encoded option per message.
00000000 g=A0=A0=A0=A0 F .text=A0 0000003e process_options
00000086 g= =A0=A0=A0=A0 F .text=A0 000000be encode_option
0000003e g=A0=A0=A0=A0 F = .text=A0 0000001c alt_process_options
0000005a g=A0=A0=A0=A0 F .text=A0 0000002c alt_encode_option

Peter
--001636a7d85e78b5aa048bfbf170-- --001636a7d85e78b5b1048bfbf172 Content-Type: text/x-csrc; charset=US-ASCII; name="coapopt.c" Content-Disposition: attachment; filename="coapopt.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbxs5rgs0 I2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8c3RkaW50Lmg+CiNpbmNsdWRlIDxzdHJpbmcu aD4KCi8qIFVucmVhbGlzdGljIGJ1dCBjb21tb24gb3B0aW9uIHByb2Nlc3NpbmcgdG8gZW5zdXJl IHR5cGUgYW5kIGxlbmd0aAogKiBhcmUgY2FsY3VsYXRlZDogc3VtIG9ic2VydmVkIHR5cGVzLCBz dW0gdG90YWwgb3B0aW9uIGxlbmd0aCAqLwp1aW50OF90IG9wdGlvbl90eXBlczsKdWludDE2X3Qg b3B0aW9uX2xlbmd0aHM7Cgp2b2lkIHByb2Nlc3Nfb3B0aW9ucyAodWludDhfdCBudW1fb3B0aW9u cywKICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHVpbnQ4X3QqIG9wKQp7CiAgdWludDhfdCB0 eXBlX3ZhbCA9IDA7CgogIHdoaWxlIChudW1fb3B0aW9ucy0tKSB7CiAgICB1aW50OF90IGRlbHRh ID0gKm9wID4+IDQ7CiAgICB1aW50MTZfdCBsZW5ndGggPSAqb3ArKyAmIDB4MEY7CgogICAgaWYg KDE1ID09IGxlbmd0aCkgewogICAgICBsZW5ndGggKz0gKm9wKys7CiAgICB9CiAgICB0eXBlX3Zh bCArPSBkZWx0YTsKICAgIG9wdGlvbl90eXBlcyArPSB0eXBlX3ZhbDsKICAgIG9wdGlvbl9sZW5n dGhzICs9IGxlbmd0aDsKICAgIG9wICs9IGxlbmd0aDsKICB9Cn0KCnZvaWQgYWx0X3Byb2Nlc3Nf b3B0aW9ucyAodWludDhfdCBudW1fb3B0aW9ucywKICAgICAgICAgICAgICAgICAgICAgICAgICBj b25zdCB1aW50OF90KiBvcCkKewogIHdoaWxlIChudW1fb3B0aW9ucy0tKSB7CiAgICBvcHRpb25f dHlwZXMgKz0gb3BbMF07CiAgICBvcHRpb25fbGVuZ3RocyArPSBvcFsxXTsKICAgIG9wICs9IDIg KyBvcFsxXTsKICB9Cn0KCgp1aW50OF90IGN1cnJlbnRfb3B0aW9uOwp1aW50OF90IG9wdGlvbl9i dWZmZXJbMjU2XTsKdWludDhfdCogb29wID0gb3B0aW9uX2J1ZmZlcjsKdm9pZCBlbmNvZGVfb3B0 aW9uICh1aW50OF90IG9wdCwKICAgICAgICAgICAgICAgICAgICB1aW50MTZfdCBvcHRfbGVuLAog ICAgICAgICAgICAgICAgICAgIGNvbnN0IHVpbnQ4X3QqIG9wdF92YWwpCnsKICB1aW50OF90IG9w dF9kZWx0YSA9IChvcHQgLSBjdXJyZW50X29wdGlvbik7CgogIHdoaWxlICgxNSA8IG9wdF9kZWx0 YSkgewogICAgdWludDhfdCBmcF9vcHQgPSAxNCAqICgoY3VycmVudF9vcHRpb24gKyAxNSkgLyAx NCk7CiAgICB1aW50OF90IGZwX2RlbHRhID0gKGZwX29wdCAtIGN1cnJlbnRfb3B0aW9uKTsKICAg ICpvb3ArKyA9IGZwX2RlbHRhIDw8IDQ7CiAgICBjdXJyZW50X29wdGlvbiArPSBmcF9kZWx0YTsK ICAgIG9wdF9kZWx0YSA9IG9wdCAtIGN1cnJlbnRfb3B0aW9uOwogIH0KICBpZiAoMHgwZiA8PSBv cHRfbGVuKSB7CiAgICAqb29wKysgPSAob3B0X2RlbHRhIDw8IDQpICsgMHgwZjsKICAgICpvb3Ar KyA9IG9wdF9sZW4gLSAweDBmOwogIH0gZWxzZSB7CiAgICAqb29wKysgPSAob3B0X2RlbHRhIDw8 IDQpICsgb3B0X2xlbjsKICB9CiAgbWVtY3B5KG9vcCwgb3B0X3ZhbCwgb3B0X2xlbik7CiAgb29w ICs9IG9wdF9sZW47Cn0KCnZvaWQgYWx0X2VuY29kZV9vcHRpb24gKHVpbnQ4X3Qgb3B0LAogICAg ICAgICAgICAgICAgICAgICAgICB1aW50OF90IG9wdF9sZW4sCiAgICAgICAgICAgICAgICAgICAg ICAgIGNvbnN0IHVpbnQ4X3QqIG9wdF92YWwpCnsKICAqb29wKysgPSBvcHQ7CiAgKm9vcCsrID0g b3B0X2xlbjsKICBtZW1jcHkob29wLCBvcHRfdmFsLCBvcHRfbGVuKTsKICBvb3AgKz0gb3B0X2xl bjsKfQo= --001636a7d85e78b5b1048bfbf172-- From cabocabo@gmail.com Thu Jul 22 08:55:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16313A6BAA for ; Thu, 22 Jul 2010 08:55:58 -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 gsoVpBUvg21U for ; Thu, 22 Jul 2010 08:55:57 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5E8CC3A6889 for ; Thu, 22 Jul 2010 08:55:57 -0700 (PDT) Received: by bwz7 with SMTP id 7so1129508bwz.31 for ; Thu, 22 Jul 2010 08:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=1mduI1C/Tnet1IP15EhtL0ToYuWJUFnKut3g55O2l4U=; b=WeGS64JYqXnzNAHZl8Ku79dCIoL+5+DwkogkSFLgft746EsFUTfPmnt7f8Pm2wHIyP V/JCBHxib9ejrUp9ABputxwCWNkRRLu21hb6A9L3uJ66DmS8ZHaE9t/X4efYOVvqztyK 1Elo9xyTP01+ZPhzKEcVMPUIUzijcnqwfmRPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ZCJgEQFFX/1XMY0LU5/kTQmkRMOqALp6mzUJ3uPNacaFwNu0poUjwZSkhsSyvRLcFm JhpBkXnk1YcXNiFmtKHIDrsJJD7ek6QpbQlQov04As46Uhya4eY/zt+q65LwlWMoSDII G45CpIzc1I5NYcmMndrQ5L3qN2SUmX3/aDTVc= Received: by 10.204.126.92 with SMTP id b28mr1635819bks.47.1279814174173; Thu, 22 Jul 2010 08:56:14 -0700 (PDT) Received: from [192.168.217.101] (p5489AD20.dip.t-dialin.net [84.137.173.32]) by mx.google.com with ESMTPS id x19sm30341889bkv.9.2010.07.22.08.56.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 08:56:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2010 17:56:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E46410F-19F7-4286-B99A-4AF29385E1D1@gmail.com> References: <80746C37-A1D4-44D8-BAAF-F85B5408DFEE@oracle.com> <07F51D76-85C1-4328-95AE-1BDC6A4874AD@gmail.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: "Pete St. Pierre" , core Subject: Re: [core] private option type codes 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 Jul 2010 15:55:58 -0000 Private options could be put into a "private options" option that works = like the "options" option I described except that it is not exclusive. Alternatively, there might be a "private option" option that can be = repeated. In both cases, the start of the option (first byte?) would indicate more = about what the option is. There you have your 8 bits :-) I nominate option numer 14 for either of these. Gruesse, Carsten From cabocabo@gmail.com Thu Jul 22 09:03:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248363A67B3 for ; Thu, 22 Jul 2010 09:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 mKmyqTgAt0Y1 for ; Thu, 22 Jul 2010 09:03:20 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 26C8C3A6B20 for ; Thu, 22 Jul 2010 09:03:19 -0700 (PDT) Received: by bwz7 with SMTP id 7so1136942bwz.31 for ; Thu, 22 Jul 2010 09:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=dGI7FjapIXOzXw1G5UA2tTtQrTE0FPjJAgOKrvuEfMk=; b=QiFZYz2xuhzE9VWU5wVRfldj8t4uFPU++LNSk1X+OCDKw0K6rNYUhK8TElEfnQZChQ TZeCya/uxqViZ4kIelLnnXWoMLoeMyU/sDxLwavxQ6vdLC8jtxEFtDLhlyzxU/AFkAC/ Soqa98sApnpd3zb2ezYoIO/0RlLtZuwWpQDco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=eR34EiA2/rt4nrULprjnEWG8rZfONYatNY4PspNMIFS5NOislD25MHcxpLKtQeJKUN i6Xwtu4N1jsLCwcnyJJQNukHCnZybzJX71SPBVLinxWV7qAIi6MnytF3Gjix1Vux52oI ZqJSAlXc2ZjjpuQg4lGVsY4UPABgOTRmJZv30= Received: by 10.204.126.153 with SMTP id c25mr1698379bks.27.1279814616371; Thu, 22 Jul 2010 09:03:36 -0700 (PDT) Received: from [192.168.217.101] (p5489AD20.dip.t-dialin.net [84.137.173.32]) by mx.google.com with ESMTPS id y27sm30331799bkw.14.2010.07.22.09.03.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 09:03:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2010 18:03:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] header option encoding 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 Jul 2010 16:03:21 -0000 Peter, this is great input! Nice to have a number on that. Spending 184 bytes of code to save a couple bytes per message sounds = like a good tradeoff to me. 6LoWPAN HC-07 is probably more expensive :-) (In simple nodes, the number will be slightly smaller as you don't need = to do fencepost processing.) Gruesse, Carsten From pab@peoplepowerco.com Thu Jul 22 09:22: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 6B4673A69B1 for ; Thu, 22 Jul 2010 09:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d3jajQbVj6O for ; Thu, 22 Jul 2010 09:22:30 -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 7953C3A6873 for ; Thu, 22 Jul 2010 09:22:30 -0700 (PDT) Received: by vws10 with SMTP id 10so335649vws.31 for ; Thu, 22 Jul 2010 09:22:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.122.1 with SMTP id j1mr764556vcr.262.1279815767203; Thu, 22 Jul 2010 09:22:47 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Thu, 22 Jul 2010 09:22:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Jul 2010 11:22:46 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e68ee0032ea0b4048bfc5410 Cc: core Subject: Re: [core] header option encoding 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 Jul 2010 16:22:31 -0000 --0016e68ee0032ea0b4048bfc5410 Content-Type: text/plain; charset=ISO-8859-1 Why do you think small devices won't need to do fencepost processing? Doesn't that depend on the options they need to process, and what's in the packets they get sent? Peter On Thu, Jul 22, 2010 at 11:03 AM, Carsten Bormann wrote: > Peter, > > this is great input! > > Nice to have a number on that. > > Spending 184 bytes of code to save a couple bytes per message sounds like a > good tradeoff to me. > 6LoWPAN HC-07 is probably more expensive :-) > (In simple nodes, the number will be slightly smaller as you don't need to > do fencepost processing.) > > Gruesse, Carsten > > --0016e68ee0032ea0b4048bfc5410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why do you think small devices won't need to do fencepost processing?= =A0 Doesn't that depend on the options they need to process, and what&#= 39;s in the packets they get sent?

Peter

On Thu, Jul 22, 2010 at 11:03 AM, Carsten Bormann <cabocabo@gmail.com> wrote:=
Peter,

this is great input!

Nice to have a number on that.

Spending 184 bytes of code to save a couple bytes per message sounds like a= good tradeoff to me.
6LoWPAN HC-07 is probably more expensive :-)
(In simple nodes, the number will be slightly smaller as you don't need= to do fencepost processing.)

Gruesse, Carsten


--0016e68ee0032ea0b4048bfc5410-- From cabocabo@gmail.com Thu Jul 22 09:34: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 365FA3A6B20 for ; Thu, 22 Jul 2010 09:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 mbLdZJGGrGlQ for ; Thu, 22 Jul 2010 09:34:32 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 09A6B3A6959 for ; Thu, 22 Jul 2010 09:34:31 -0700 (PDT) Received: by bwz7 with SMTP id 7so1165137bwz.31 for ; Thu, 22 Jul 2010 09:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Y7EL+ObRfYQycGE+hm1Aoxf0GUZEAt5mZHLvNf8dvYI=; b=yBggb+ST2cCSRuyHBAJAKNtlJbsx01L1CEmHBPPe75bIoLE5ymIGRmjxUJjWwbNY1u TseJ3RnLk7lJdzgiIlIHxYvoBsL3CdGaI3iml7C6aBoPDXeGeorIR7JIsLb1JRIkn4Nx af+VOHzeDIQ6lC8OENE2O+3cHw/6hEKH3FHgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=J4YcMneIaJ0AGbrCjkaPm2UXNcODT7r0h54e2ZuPGl2WEzQS4roCKVx3cusb9BY74v XqJWwAPCar/wPCmStDAfRarD4M1yQLz1uDVxOthUvwpINaI3vQCwSzryj0VOpuboKtYF b4gHjgYMA/zyvfWnZ+Ds5d9V/BF7Zvd26WLcY= Received: by 10.204.82.206 with SMTP id c14mr1484144bkl.145.1279816488518; Thu, 22 Jul 2010 09:34:48 -0700 (PDT) Received: from [192.168.217.101] (p5489AD20.dip.t-dialin.net [84.137.173.32]) by mx.google.com with ESMTPS id o20sm30357743bkw.15.2010.07.22.09.34.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 09:34:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2010 18:34:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8234CB8B-2FDF-400C-9EFB-F1836AE31589@gmail.com> References: To: Hari Hara Sudhan R X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Clarification regarding the length field mentioned for options in COAP Specification 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 Jul 2010 16:34:34 -0000 Hi Hari, it would help the editors if you could indicate what sections/what = phrases are unclear. > Suppose app want to send URI-SCHEME option as first and only option = and > if the the length of option value is say 200 Uri-Scheme has option number 3, so the left-most nibble would be 3 = (given that this is the only option and you are starting at 0, see 3.2 = first paragraph). The next nibble would be 15 (0b1111), to indicate that the length is = larger than 14. In summary, the first byte of the option would have a value of 63 = (0x3F). The next byte would indeed be 185 (0xB9), i.e. 200-15. The next 200 bytes are then the option value (as there are 200 bytes of = Uri-Scheme). (Note that there are no 200-byte URI scheme names and I hope there never = will be, but let's ignore that for now.) Gruesse, Carsten From cabocabo@gmail.com Thu Jul 22 09:39:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463C53A69C6 for ; Thu, 22 Jul 2010 09:39:06 -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 PtdGRI4FNQP6 for ; Thu, 22 Jul 2010 09:39:04 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8BE953A6950 for ; Thu, 22 Jul 2010 09:39:03 -0700 (PDT) Received: by bwz7 with SMTP id 7so1168446bwz.31 for ; Thu, 22 Jul 2010 09:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=CZ3pEwuNtXf9dXfgnAWCWXz7kVuW8IMV7W/cbhDUIow=; b=pUJBxbal8cUglsGnByJRy6DJkjKO7Aci2MFgoSliTn0hH8eIFCgwCfX5mIG1llz/NO xHb2PcYoliFkfsLYERn6mbrni02biYgmqx02DVUbntc5zp75aLntaKSRSoMOvCceQTYe W0iu9Bt2z4IF7sA8CZLqgIY0E99EGtZvJO21I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=SFCBFhKWFTatMwb9IImQs4yfSJ0LJM4zyfHcf4eMb8oOq3Gk7uakvX1feghwfcN78I ebFKpY7NMYC3//2mTvRRsTkcRWdtyG97E7biTKXD4YecNXVW2BpNCv/K0TAyLRBpVXbK 6H2w27/b7KZVg0bpnkpDInip3BIyH7vHJGdxo= Received: by 10.204.73.130 with SMTP id q2mr1504132bkj.137.1279816760088; Thu, 22 Jul 2010 09:39:20 -0700 (PDT) Received: from [192.168.217.101] (p5489AD20.dip.t-dialin.net [84.137.173.32]) by mx.google.com with ESMTPS id f10sm30349066bkl.17.2010.07.22.09.39.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 09:39:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2010 18:39:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] header option encoding 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 Jul 2010 16:39:06 -0000 On Jul 22, 2010, at 18:22, Peter Bigot wrote: > Why do you think small devices won't need to do fencepost processing? =20= Because all the options they need to send will be numbered 15 or less. > Doesn't that depend on the options they need to process, and what's in = the packets they get sent? Yes (for sending). No (for receiving, as 14/28/etc. are just elective options that are = ignored, so the fencepost processing is zero code on reception). Gruesse, Carsten From cabocabo@gmail.com Thu Jul 22 09:59: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 72A103A676A for ; Thu, 22 Jul 2010 09:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2srEOyi5Ow7X for ; Thu, 22 Jul 2010 09:59:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 473513A67B3 for ; Thu, 22 Jul 2010 09:59:14 -0700 (PDT) Received: by bwz7 with SMTP id 7so1185621bwz.31 for ; Thu, 22 Jul 2010 09:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=sJaG5b7hOnQw/gOUpdsI7plfZNnqXJPLofDT3oYRa8Q=; b=u3R055j/0hti90Qb3Si0WHVEjN5evUqesllUSgp/54FrsmyFV871z7rAkKH+eSQRAK GIyGcfHjuP11gHJ3tM2umeIjfRkSfOxAew0RvCeH9OTSRp3GumWVCtlgMOKaUh24gwOH mu9WX/ZNaiDgGPma3zaiIsI+dJF2REVkQfV/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=jDLDBb+pF+kNAD+CQPxJV+Z3GIttNGez8NgjxIRI3Fh/QSDMY1gUnidq3qyZMGk3cv OqriRbHUEtW6We4FCzY9t5Tdwns9NuxoyXuTvRa+PKj1e4t0nHC6T6MS2W7hCLmxCs2/ TvVSjqCt1cUyw1GC6om7xP1VoT3Gmg0wTMov0= Received: by 10.204.85.90 with SMTP id n26mr1635888bkl.109.1279817969923; Thu, 22 Jul 2010 09:59:29 -0700 (PDT) Received: from [192.168.217.101] (p5489AD20.dip.t-dialin.net [84.137.173.32]) by mx.google.com with ESMTPS id o20sm30377385bkw.15.2010.07.22.09.59.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 09:59:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2010 18:59:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3EA7B0C8-E64C-407A-BEE2-C38798CA3641@gmail.com> References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] proposal: header options may appear at most once 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 Jul 2010 16:59:15 -0000 > =95 Each option definition should indicate whether the minimum = number of occurrences is zero or one (optional or required); Sounds good. Actually, the answer would always be "optional", as we = don't have any required options. (I.e., a 4-byte CoAP message with oc=3D0 and meaningful ttype/code is a = good message.) > =95 Each option definition should indicate whether the maximum = number of occurrences is one or unbounded; An option definition must definitely say what it actually means to have = multiple occurrences, if that is to be allowed. (And the summary table could indeed have a column that indicates whether = the option is "repeatable".) > =95 Message recipients are not obligated to diagnose violation = of multiplicity restrictions for any option (meaning, for example, that = they can do whatever they want if they receive multiple Uri-Path options = in a PUT or GET message). "Be liberal in what you accept". (But this is also the road to tag-soup = hell.) Still, I agree there should be no requirement on a node to detect and = reject all violations of message syntax. (My demo implementation certainly doesn't.) But an implementation also shouldn't go out of its way to process = invalid messages. > (Motivation for that last one: unless a node is obligated to recognize = an option even if it doesn't support it, Elective options can always be safely ignored by definition. Requiring to detect violations in an option you don't understand would = indeed be absurd. Gruesse, Carsten From pab@peoplepowerco.com Thu Jul 22 13:29:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476AF3A6901 for ; Thu, 22 Jul 2010 13:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzzEqE5tW1EM for ; Thu, 22 Jul 2010 13:29:18 -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 4494C3A6927 for ; Thu, 22 Jul 2010 13:29:18 -0700 (PDT) Received: by vws10 with SMTP id 10so597940vws.31 for ; Thu, 22 Jul 2010 13:29:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.198 with SMTP id l6mr992889vcs.219.1279830575307; Thu, 22 Jul 2010 13:29:35 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Thu, 22 Jul 2010 13:29:35 -0700 (PDT) Date: Thu, 22 Jul 2010 15:29:35 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=e0cb4e887e71d05bbe048bffc6a7 Subject: [core] python coap implementation available 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 Jul 2010 20:29:19 -0000 --e0cb4e887e71d05bbe048bffc6a7 Content-Type: text/plain; charset=ISO-8859-1 I've made a Python CoAP implementation available at http://coapy.sourceforge.net. That site contains mostly automatically-generated API documentation; the initial release version 0.0.2 can be downloaded from the project page at http://sourceforge.net/projects/coapy; or you can just clone the git repository with: git clone git://coapy.git.sourceforge.net/gitroot/coapy/coapy All the standard options plus block are implemented. Retransmission seems to work. No multicast support until my endpoint questions get resolved. It's enough to interact with the test server (retrieve all the non-secret resources, store something in the sink) and there's a demonstration server you can run that isn't too horrible to extend. See the examples subdirectory. I'm not sure if I'll be able to open up my firewalls enough to run this during the plugfest, but if there's interest I'll try. In any case, feel free to download it and play with it locally. Please send any problems or questions to me directly rather than bother everybody on this list. Or, better, raise them on the Open Discussion forum on the SourceForge page. Peter --e0cb4e887e71d05bbe048bffc6a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've made a Python CoAP implementation available at http://coapy.sourceforge.net.=A0 That site contai= ns mostly automatically-generated API documentation; the initial release ve= rsion 0.0.2 can be downloaded from the project page at http://sourceforge.net/projects/coapy; or= you can just clone the git repository with:

=A0 git clone git://coapy.git.sourceforge.net/gitroot/coapy/coapy

All = the standard options plus block are implemented.=A0 Retransmission seems to= work.=A0 No multicast support until my endpoint questions get resolved.=A0= It's enough to interact with the test server (retrieve all the non-sec= ret resources, store something in the sink) and there's a demonstration= server you can run that isn't too horrible to extend.=A0 See the examp= les subdirectory.

I'm not sure if I'll be able to open up my firewalls enough to = run this during the plugfest, but if there's interest I'll try.=A0 = In any case, feel free to download it and play with it locally.

Plea= se send any problems or questions to me directly rather than bother everybo= dy on this list.=A0 Or, better, raise them on the Open Discussion forum on = the SourceForge page.

Peter

--e0cb4e887e71d05bbe048bffc6a7-- From pab@peoplepowerco.com Fri Jul 23 05:36: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 885133A6405 for ; Fri, 23 Jul 2010 05:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbvJgroh3Fwc for ; Fri, 23 Jul 2010 05:36:44 -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 DA6E33A6403 for ; Fri, 23 Jul 2010 05:36:43 -0700 (PDT) Received: by vws10 with SMTP id 10so170953vws.31 for ; Fri, 23 Jul 2010 05:37:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.201 with SMTP id y9mr1630476vch.80.1279888620706; Fri, 23 Jul 2010 05:37:00 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Fri, 23 Jul 2010 05:37:00 -0700 (PDT) Date: Fri, 23 Jul 2010 07:37:00 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=e0cb4e887e9196daf8048c0d4ac9 Subject: [core] asynchronous responses 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, 23 Jul 2010 12:36:45 -0000 --e0cb4e887e9196daf8048c0d4ac9 Content-Type: text/plain; charset=ISO-8859-1 I've updated coapy's git repository with server and client support for IPv6, and added a service that uses asynchronous responses. (No new release, it's only in the repository but you can fetch it.) Based on this, the following clarifications are needed (some of which are in my endpoint-questions mail): * It is unclear how to indicate that the response will be asynchronous; the text references whether the ACK "carries the REST response". I interpret a header code value of zero to indicate absence of REST content in the message (section 3.1 is insufficiently clear about this). Based on this it should also be made more clear that the payload belongs to the REST part of the message, and is absent if the message carries no REST content. The options, on the other hand, are not part of the REST message. (Or, if all that's not true, whatever is truth needs to be documented.) * Where does the server send the asynchronous response? I sent it to the originating sender's envelope source address, where the synchronous response went. * From what local address does the server send the response? I sent it from the endpoint on which the request was received. Natural in this case, but is it required? * How does a client that has requests for the same URI out to multiple servers disambiguate? Presumably that's the Token option from coap-misc. * What options must be copied from the request to the asynchronous response? Section 2.1.2 says "the URI (and possibly token)". This would be Uri-Scheme, Uri-Authority, and Uri-Path, for now? I just copied Uri-Path; I don't have Token yet, and the others I'd ignore anyway. If Query-Param is added, it'll have to go too. This is getting ugly: like multiplicity, there should be a defined feature of each option that indicates whether it needs to be copied to an asynchronous response. Behavior for options not recognized by receiver? * What options must be copied from the request to a synchronous response? Is Token one of them, or do we assume the transaction ID is sufficient and no options that are not relevant to the REST response need to be copied? (Are any options relevant to the REST message, or are they all part of the transaction? See first point above.) Peter --e0cb4e887e9196daf8048c0d4ac9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've updated coapy's git repository with server and client support = for IPv6,
and added a service that uses asynchronous responses.=A0 (No n= ew release, it's
only in the repository but you can fetch it.)
Based on this, the following clarifications are needed (some of which are i= n
my endpoint-questions mail):

* It is unclear how to indicate th= at the response will be asynchronous; the
=A0 text references whether th= e ACK "carries the REST response".=A0 I interpret
=A0 a header code value of zero to indicate absence of REST content in the<= br>=A0 message (section 3.1 is insufficiently clear about this).

=A0= Based on this it should also be made more clear that the payload belongs =A0 to the REST part of the message, and is absent if the message carries n= o
=A0 REST content.=A0 The options, on the other hand, are not part of t= he REST
=A0 message.=A0 (Or, if all that's not true, whatever is tru= th needs to be
=A0 documented.)

* Where does the server send the asynchronous respo= nse?=A0 I sent it to the
=A0 originating sender's envelope source ad= dress, where the synchronous
=A0 response went.

* From what local= address does the server send the response?=A0 I sent it from
=A0 the endpoint on which the request was received.=A0 Natural in this case= , but
=A0 is it required?

* How does a client that has requests f= or the same URI out to multiple
=A0 servers disambiguate?=A0 Presumably = that's the Token option from coap-misc.

* What options must be copied from the request to the asynchronous resp= onse?
=A0 Section 2.1.2 says "the URI (and possibly token)".= =A0 This would be
=A0 Uri-Scheme, Uri-Authority, and Uri-Path, for now?= =A0 I just copied Uri-Path;
=A0 I don't have Token yet, and the others I'd ignore anyway.=A0 If= Query-Param
=A0 is added, it'll have to go too.

=A0 This is = getting ugly: like multiplicity, there should be a defined feature
=A0 o= f each option that indicates whether it needs to be copied to an
=A0 asynchronous response.=A0 Behavior for options not recognized by receiv= er?

* What options must be copied from the request to a synchronous = response?
=A0 Is Token one of them, or do we assume the transaction ID i= s sufficient and
=A0 no options that are not relevant to the REST response need to be copied= ?
=A0 (Are any options relevant to the REST message, or are they all par= t of the
=A0 transaction?=A0 See first point above.)

Peter
--e0cb4e887e9196daf8048c0d4ac9-- From cabocabo@gmail.com Fri Jul 23 06:17: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 1C9893A688E for ; Fri, 23 Jul 2010 06:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 qRvecB-Tpq2j for ; Fri, 23 Jul 2010 06:17:39 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 43E9D3A66B4 for ; Fri, 23 Jul 2010 06:17:38 -0700 (PDT) Received: by bwz7 with SMTP id 7so1824939bwz.31 for ; Fri, 23 Jul 2010 06:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=wDSn6YQ9OtZAG3kEihf1zq3lKgiCVusRG5T4oo1CZCI=; b=Pi+ZmIJVDKDLhApjuQkXlxjQDlhWSrYFDJS5RQud25/7FZIz/tmj28Vez42PMtq/Sc wvDOjE8Df8FW/ooBe3km8zaBM7rWOoWFxZCvsBaRMOZUG7Rd4sx6pgZLhE6uxiNG2xDc r/ET9hr1zw+XOIRRk1fnMkFJcFpRZkmM5OtQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=SCuda8o4R3wjVwsMFjKNgLaxeTaVS4ZGrc6DXQcqZIap0KMwWN2pNHEBXno9iQCBh8 nCn2+TZ2+aQQyl1OH4cQkHwtvuUWPETWaQLkatzuXd8xjdr93gSxkQF/HmaLypoaG632 0GjV7qwYsC50RazyKHnCVqfptKnLlA57NlhCY= Received: by 10.204.51.145 with SMTP id d17mr2531074bkg.20.1279891027539; Fri, 23 Jul 2010 06:17:07 -0700 (PDT) Received: from [134.102.2.188] ([134.102.2.188]) by mx.google.com with ESMTPS id a11sm217798bkc.0.2010.07.23.06.17.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 06:17:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Fri, 23 Jul 2010 15:17:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30AEB432-CE5B-423B-914C-0F8EB46CB981@gmail.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] asynchronous responses 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, 23 Jul 2010 13:17:40 -0000 Hi Peter, I believe these observations are great material for coap-02. Let me pick some that might need some discussion. > Based on this it should also be made more clear that the payload = belongs > to the REST part of the message, and is absent if the message = carries no > REST content. The options, on the other hand, are not part of the = REST > message. (Or, if all that's not true, whatever is truth needs to be > documented.) So far, we tried to avoid imposing one form of strict layering here. It is not clear to me that we have to define exactly which options are = transaction layer and which ones are REST layer. If I had to choose, all would be REST layer. But maybe you have a different idea of what "REST layer" means here = (maybe there are three layers?). > * Where does the server send the asynchronous response? I sent it to = the > originating sender's envelope source address, where the synchronous > response went. Yes, that's the intention. > * =46rom what local address does the server send the response? I sent = it from > the endpoint on which the request was received. Natural in this = case, but > is it required? We have to define that. I would propose strictly requiring the same transport address, but = occasionally people tell me they need more freedom. > * How does a client that has requests for the same URI out to multiple > servers disambiguate? Presumably that's the Token option from = coap-misc. The idea was that the transport address of the server (source address of = response) also goes into the comparison. A client can (and probably should) also use different TIDs for different = requests. > * What options must be copied from the request to the asynchronous = response? > Section 2.1.2 says "the URI (and possibly token)". This would be > Uri-Scheme, Uri-Authority, and Uri-Path, for now? I just copied = Uri-Path; > I don't have Token yet, and the others I'd ignore anyway. If = Query-Param > is added, it'll have to go too. >=20 > This is getting ugly: like multiplicity, there should be a defined = feature > of each option that indicates whether it needs to be copied to an > asynchronous response. =20 Yes! > Behavior for options not recognized by receiver? Ignore, I'd say. (Elective ones.) > * What options must be copied from the request to a synchronous = response? > Is Token one of them, or do we assume the transaction ID is = sufficient and > no options that are not relevant to the REST response need to be = copied? > (Are any options relevant to the REST message, or are they all part = of the > transaction? See first point above.) Token was meant to be implied from the transaction (i.e., you only echo = it in an asynchronous response), like the URI components. Gruesse, Carsten From pab@peoplepowerco.com Fri Jul 23 07:16: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 80CA43A69CB for ; Fri, 23 Jul 2010 07:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHcizyioyny7 for ; Fri, 23 Jul 2010 07:16:09 -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 3BA4F3A6957 for ; Fri, 23 Jul 2010 07:16:04 -0700 (PDT) Received: by vws10 with SMTP id 10so278493vws.31 for ; Fri, 23 Jul 2010 07:16:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.193 with SMTP id r1mr1821270vcn.89.1279894581315; Fri, 23 Jul 2010 07:16:21 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Fri, 23 Jul 2010 07:16:21 -0700 (PDT) In-Reply-To: <30AEB432-CE5B-423B-914C-0F8EB46CB981@gmail.com> References: <30AEB432-CE5B-423B-914C-0F8EB46CB981@gmail.com> Date: Fri, 23 Jul 2010 09:16:21 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e646a41cde8c45048c0ead0d Cc: core Subject: Re: [core] asynchronous responses 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, 23 Jul 2010 14:16:10 -0000 --0016e646a41cde8c45048c0ead0d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 23, 2010 at 8:17 AM, Carsten Bormann wrote: > Hi Peter, > > I believe these observations are great material for coap-02. > > Let me pick some that might need some discussion. > > > Based on this it should also be made more clear that the payload > belongs > > to the REST part of the message, and is absent if the message carries > no > > REST content. The options, on the other hand, are not part of the REST > > message. (Or, if all that's not true, whatever is truth needs to be > > documented.) > > So far, we tried to avoid imposing one form of strict layering here. > It is not clear to me that we have to define exactly which options are > transaction layer and which ones are REST layer. > If I had to choose, all would be REST layer. > But maybe you have a different idea of what "REST layer" means here (maybe > there are three layers?). > I think there are all kinds of layers. - The transport layer is below CoAP completely, and is for the purposes of CoAP assumed to be UDP. - The transaction layer is the one that interprets the transaction type (CON, NON, ACK, RST) and transaction id, and carries the code. - The REST layer is identified by the code, and carries the options and the payload. I think you're right that all the options belong at the REST layer not the transaction layer. This makes things simple, and we just have to make sure that we can keep that distinction as reality intrudes. There are two problems. First, that I conceptualized a transaction-layer relation between the request and the asynchronous response. Now, I think that was a mistake. See below regarding synchronous responses for a related issue where REST and transaction interrelate. Second is the URI. Uri-Authority is a huge problem, since it couples the REST layer with the transport layer, bypassing the transaction layer. This is the issue that HTTP/1.1 tried to get away from by making Host a required keyword, so that the complete URI would still be available at the REST layer. I don't think we can get away from that: I think Uri-Authority has to be required whenever a URI is present. On the other hand, I'm afraid of having to interpret Uri-Authority on a CoAP node. (Similarly, why don't we just get rid of Uri-Scheme? It'll be "coap", always. A URI that refers to any other scheme is data, not part of a REST exchange supported by a CoAP server. This is, I believe, entirely consistent with how HTTP treats the scheme.) > * Where does the server send the asynchronous response? I sent it to the > > originating sender's envelope source address, where the synchronous > > response went. > > Yes, that's the intention. > > > * From what local address does the server send the response? I sent it > from > > the endpoint on which the request was received. Natural in this case, > but > > is it required? > > We have to define that. > I would propose strictly requiring the same transport address, but > occasionally people tell me they need more freedom. > > > * How does a client that has requests for the same URI out to multiple > > servers disambiguate? Presumably that's the Token option from > coap-misc. > > The idea was that the transport address of the server (source address of > response) also goes into the comparison. > Multicast destroys this. The server really shouldn't send its response using the multicast address as the source address, if it even can (it's so perverse even I haven't tried it). The client who multicast a request (e.g., same Uri-Path to two distinct multicast groups) won't recognize asynchronous responses. Ideally, correlation of REST messages should be achievable solely at the REST layer, with a possible exception to leverage transaction ID from the transaction-layer for synchronous responses. I believe requiring information from the transport layer to correlate REST messages would be a mistake. > A client can (and probably should) also use different TIDs for different > requests. > > > * What options must be copied from the request to the asynchronous > response? > > Section 2.1.2 says "the URI (and possibly token)". This would be > > Uri-Scheme, Uri-Authority, and Uri-Path, for now? I just copied > Uri-Path; > > I don't have Token yet, and the others I'd ignore anyway. If > Query-Param > > is added, it'll have to go too. > > > > This is getting ugly: like multiplicity, there should be a defined > feature > > of each option that indicates whether it needs to be copied to an > > asynchronous response. > > Yes! > > > Behavior for options not recognized by receiver? > > Ignore, I'd say. > (Elective ones.) > > > * What options must be copied from the request to a synchronous response? > > Is Token one of them, or do we assume the transaction ID is sufficient > and > > no options that are not relevant to the REST response need to be > copied? > > (Are any options relevant to the REST message, or are they all part of > the > > transaction? See first point above.) > > Token was meant to be implied from the transaction (i.e., you only echo it > in an asynchronous response), like the URI components. > So: - Options are REST features - Consequently, in an asynchronous response the transaction should carry all and only those options that are relevant to the REST message that serves as the response. - In a synchronous response, we can optimize this by skipping any options from the REST message where the value is identical to that of the same option in the request transaction. In other words, the concept of a "default value" for an option in a transaction response incorporates the provided values of those options in the transaction request. It's a little tricky to understand, but on the whole I think it's a clean conceptualization. Will it work? > Gruesse, Carsten > > --0016e646a41cde8c45048c0ead0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jul 23, 2010 at 8:17 AM, Carsten Bormann <cabocabo@gmail.com> wrote:<= br>
Hi Peter,

I believe these observations are great material for coap-02.

Let me pick some that might need some discussion.

> =A0 Based on this it should also be made more clear that the payload b= elongs
> =A0 to the REST part of the message, and is absent if the message carr= ies no
> =A0 REST content. =A0The options, on the other hand, are not part of t= he REST
> =A0 message. =A0(Or, if all that's not true, whatever is truth nee= ds to be
> =A0 documented.)

So far, we tried to avoid imposing one form of strict layering here.<= br> It is not clear to me that we have to define exactly which options are tran= saction layer and which ones are REST layer.
If I had to choose, all would be REST layer.
But maybe you have a different idea of what "REST layer" means he= re (maybe there are three layers?).

=A0I think the= re are all kinds of layers.
  • The transport layer is below CoAP co= mpletely, and is for the purposes of CoAP assumed to be UDP.
  • The transaction layer is the one that interprets the transaction type (= CON, NON, ACK, RST) and transaction id, and carries the code.
  • The R= EST layer is identified by the code, and carries the options and the payloa= d.
I think you're right that all the options belong at the REST laye= r not the transaction layer.=A0 This makes things simple, and we just have = to make sure that we can keep that distinction as reality intrudes.

There are two problems.=A0 First, that I conceptualized a transaction-layer= relation between the request and the asynchronous response.=A0 Now, I thin= k that was a mistake.=A0 See below regarding synchronous responses for a re= lated issue where REST and transaction interrelate.

Second is the URI.=A0 Uri-Authority is a huge problem, since it couples= the REST layer with the transport layer, bypassing the transaction layer.= =A0 This is the issue that HTTP/1.1 tried to get away from by making Host a= required keyword, so that the complete URI would still be available at the= REST layer.=A0 I don't think we can get away from that: I think Uri-Au= thority has to be required whenever a URI is present.=A0 On the other hand,= I'm afraid of having to interpret Uri-Authority on a CoAP node.

(Similarly, why don't we just get rid of Uri-Scheme?=A0 It'll b= e "coap", always.=A0 A URI that refers to any other scheme is dat= a, not part of a REST exchange supported by a CoAP server.=A0 This is, I be= lieve, entirely consistent with how HTTP treats the scheme.)

> * Where does the server send the asynchronous response? =A0I sent it t= o the
> =A0 originating sender's envelope source address, where the synchr= onous
> =A0 response went.

Yes, that's the intention.

> * From what local address does the server send the response? =A0I sent= it from
> =A0 the endpoint on which the request was received. =A0Natural in this= case, but
> =A0 is it required?

We have to define that.
I would propose strictly requiring the same transport address, but occasion= ally people tell me they need more freedom.

> * How does a client that has requests for the same URI out to multiple=
> =A0 servers disambiguate? =A0Presumably that's the Token option fr= om coap-misc.

The idea was that the transport address of the server (source address= of response) also goes into the comparison.

Multi= cast destroys this.=A0 The server really shouldn't send its response us= ing the multicast address as the source address, if it even can (it's s= o perverse even I haven't tried it).=A0 The client who multicast a requ= est (e.g., same Uri-Path to two distinct multicast groups) won't recogn= ize asynchronous responses.

Ideally, correlation of REST messages should be achievable solely at th= e REST layer, with a possible exception to leverage transaction ID from the= =A0 transaction-layer for synchronous responses.=A0 I believe requiring inf= ormation from the transport layer to correlate REST messages would be a mis= take.
=A0
A client can (and probably should) also use different TIDs for different re= quests.

> * What options must be copied from the request to the asynchronous res= ponse?
> =A0 Section 2.1.2 says "the URI (and possibly token)". =A0Th= is would be
> =A0 Uri-Scheme, Uri-Authority, and Uri-Path, for now? =A0I just copied= Uri-Path;
> =A0 I don't have Token yet, and the others I'd ignore anyway. = =A0If Query-Param
> =A0 is added, it'll have to go too.
>
> =A0 This is getting ugly: like multiplicity, there should be a defined= feature
> =A0 of each option that indicates whether it needs to be copied to an<= br> > =A0 asynchronous response.

Yes!

> Behavior for options not recognized by receiver?

Ignore, I'd say.
(Elective ones.)

> * What options must be copied from the request to a synchronous respon= se?
> =A0 Is Token one of them, or do we assume the transaction ID is suffic= ient and
> =A0 no options that are not relevant to the REST response need to be c= opied?
> =A0 (Are any options relevant to the REST message, or are they all par= t of the
> =A0 transaction? =A0See first point above.)

Token was meant to be implied from the transaction (i.e., you only ec= ho it in an asynchronous response), like the URI components.

=A0So:
  • Options are REST features
  • Consequently= , in an asynchronous response the transaction should carry all and only tho= se options that are relevant to the REST message that serves as the respons= e.
  • In a synchronous response, we can optimize this by skipping any op= tions from the REST message where the value is identical to that of the sam= e option in the request transaction.=A0 In other words, the concept of a &q= uot;default value" for an option in a transaction response incorporate= s the provided values of those options in the transaction request.
It's a little tricky to understand, but on the whole I think it= 9;s a clean conceptualization.=A0 Will it work?


Gruesse, Carsten


--0016e646a41cde8c45048c0ead0d-- From kerlyn2001@gmail.com Fri Jul 23 07:19: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 091D13A657C for ; Fri, 23 Jul 2010 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_15=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 aFRbD-Vi47gH for ; Fri, 23 Jul 2010 07:19:49 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 42F073A6784 for ; Fri, 23 Jul 2010 07:19:49 -0700 (PDT) Received: by ywa8 with SMTP id 8so44244ywa.31 for ; Fri, 23 Jul 2010 07:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AExx82EYirDxW3QaROUltV1AL7kcc2PF0LwST7DaKPs=; b=Lc1aDsrC8FU5n/hEpWWQ7eQAKcesKatFmEwZm+U6dGH8UIW+Z300jOY9cKG+bOioHy xoNKsTihPK57m0uGoW4oQljQJBvz6cPp/vODM8WSuqmR279HcgtdhENEDDJF3PMMFICd jmAZHIWaoTgotnT2Nitx++0lUxe2+ewVDP3ck= 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=E59LexkD5BP+VAAFq6BRzPL7+X+YwnlgzNoWSSWmP4QzDHMxNWfBUaduBE5xDYrWbx 8B6/ieP36dYid7wNkEJqjFYRCOoIWeSGRXzlKHea4jcHvtbQdhEWX6TBSQSHw/J/SEdO 5Bb0m8EK1DO9Igx/R7e1liolcXqA7LiJEauks= MIME-Version: 1.0 Received: by 10.90.91.4 with SMTP id o4mr3586546agb.168.1279894803030; Fri, 23 Jul 2010 07:20:03 -0700 (PDT) Received: by 10.90.97.15 with HTTP; Fri, 23 Jul 2010 07:20:02 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Jul 2010 10:20:02 -0400 Message-ID: From: Kerry Lynn To: Peter Bigot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , core Subject: Re: [core] What is an end-point (was: URI splitting (was: Re: explicit option for URI query part)) 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, 23 Jul 2010 14:19:51 -0000 Hi Peter, I'll rush in where angels fear to tread... On Tue, Jul 20, 2010 at 2:37 PM, Peter Bigot wrote: > OK, we've moved to a question I'd avoided, so I've changed the subject fo= r > this thread.=A0 To wit, what is an end-point?=A0 And, once we figure that= out, > how does end-point relate to a URI-reference that identifies a resource a= t > that end-point? > > Section 2.1 of coap-01 states: > > =A0=A0 ...Machine-to-machine interactions typically result in a CoAP > =A0=A0 implementation acting in both client and server roles (called an > =A0=A0 end-point). > > The plural "roles" and singular particle "an" make this text imprecise.= =A0 Are > the two roles considered distinct end-points?=A0 Or is the single > implementation one end-point with both roles? > My interpretation (in the absence of greater specificity) is that an "end-p= oint" is what might be termed a "service access point" in other context. That is= , an end-point is a triple consisting of: a host (in the RFC 3986 sense), plu= s a (possibly default) port, plus a protocol (CoAP). I imagine there is a sing= le CoAP instance per host, which can (and does) operate in peer-to-peer mode. This view is supported by the following text in section 6 of the CoAP draft= : CoAP makes the assumption that all CoAP servers host an end-point on the default CoAP port (see Section 4.4) hosting a well-known discovery resource, or otherwise have been configured or discovered using some general service discovery mechanism such as [I-D.cheshire-dnsext-dns-sd]. This language might be interpreted to mean that several CoAP servers could be demux'd through a single end-point (as in the case of a proxy). OTOH, the meaning might be that EACH server hosts an end-point on the default CoAP port, which would imply one server per host. In draft-vanderstok-core-bc we take the position that the CoAP end-point is fully specified by the scheme and authority parts of the URI, and that dereferencing these elements is the function of service discovery. Quoting from section 6.2: Whereas service discovery is used to find the IP address, port and protocol of an unknown service, resource discovery is a fine-grained discovery of resource URIs within a web service. and again from section 6: This section assumes that... service discovery has already been performed a priori, if needed. So, in general, it would seem that service discovery has occurred upstream of any path/query processing at the end-point. For example, in figure 9 of the CoAP draft some form of service discovery must have occurred before unicast resource discovery can proceed. >From a practical standpoint the question might also boil down to "what value goes in the source port" for CONs from an end-point, or in response to multicast CONs. My vote would be [IANA_TBD_PORT] for the latter (and that should also be the destination port used in the multicast), but MAY be a dynamic port in the 61616-61631 range for the unicast case (see below). > If an implementation accepts messages on multiple interfaces or ports, is > each a separate end-point?=A0 For example, when monitoring multiple UDP > sockets, one bound to the (TBD) IANA registered COAP port and another bou= nd > to a port in the RFC4944-specified (private) compressed UDP port space. > Text in section 4.4 implies these are distinct end-points. > You raise several questions here. First, are constrained devices likely to= be multi-homed? More generally, can multiple URIs locate the same resource? If so, this would seem to admit multiple relative URI-references for the sa= me resource at the same end-point. For example, a namespace path schema might coexist with an unstructured schema to access the same resource. But I digress... As a meta-issue, I think one objective of CoRE should be to capture a consensus regarding the meaning of constrained. That is, what degrees of freedom are we willing to limit? Multi-homing might be an example. Regarding multiple ports, I think this is a very important question. We us= e host names as persistent references because they are durable compared to IP addresses. If it should be the consensus that coap://host:portX/path locates a different resource than coap://host:portY/path, then there are so= me implications: - End-points using dynamic ports should always use the same port. If not, then any cached (persistent) URIs might become invalid. - To the extent that different end-points may use different dynamic ports, = this makes multicast messages to a group of end-points problematic. A simple solution might be to stipulate that there is only one CoAP end-poi= nt per host but that it might be reached on multiple ports. For example, the = first GET that a client makes to a new server might be via the [IANA_TBD_PORT] but the response might be returned by way of a dynamic port, which would be used by the client for all subsequent requests to that server. That wou= ld necessitate changing the text in section 4.4 to "...MUST be supported for providing access to other resources." The canonical end-point is thus defined as the {canonical host IP address, IANA_TBD_PORT, CoAP} triple. > What about multicast?=A0 A received multicast message has to be delivered= to > an end-point, right?=A0 For the end-point to send ACKs over UDP, it has t= o be > bound to a non-multicast address (unless it's supposed to multicast the > ACKs, which seems wrong).=A0 Is that end-point required to accept message= s > addressed to its non-multicast address?=A0 Or is it that ACKs and RSTs sh= ould > not be considered as coming from an end-point, even though they're genera= ted > in response to a message received by an end-point? > By the proposal above, any multicast response to [IANA_TBD_PORT] arrives at the end-point. Any unicast to [IANA_TBD_PORT] or the server's (optiona= l) dynamic port in the compressed UDP range arrives at the end-point. > In an asynchronous response, is the server obliged to transmit the respon= se > message from the same end-point as received the original request?=A0 Or c= ould > it use the asynchronous response specifically to change the end-point (a > sort of implicit redirect)? > By the proposal above, the server MUST accept a unicast request to [IANA_TBD_PORT] and SHOULD accept a unicast request on its dynamic port, if one is bound. If the latter, then it would respond via the dynamic port. > My conclusion had been: > > - Each end-point is bound to exactly one non-multicast (i.e., unicast or > link-local) IP address and port. > Concur, but it seems there may be more than one end-point per host. > - Each end-point can additionally receive messages on zero or more multic= ast > addresses and ports. > I believe this must be "one or more", otherwise how is multicast resource discovery accomplished? Without multicast resource discovery, (and its side effect of quasi service discovery) an external service discovery method is required. If selecting a default service discovery mechanism is outside the charter, that leads to t= he conclusion that groups of CoAP end-points may not be able to find each other. My own personal opinion is that mDNS/DNS-SD should be used for service discove= ry, but that's another email. > - A transaction response message must be sent from the unicast or link-lo= cal > IP address and port associated with the end-point that received the > transaction request. > >> > Then the reconstructed URI is different on each recipient. =A0That wou= ld >> > introduce an issue with recognizing an asynchronous response. >> >> Not so sure about that. =A0If f::0:0 tells me their /bar is 14, that may= be >> exactly what I want to know. > > From your comment, it appears that a resource identified by a multicast > address continues to be identified by multicast.=A0 I can see that use, t= hough > it wasn't the first that came to mind. > > I had assumed that I would send a GET request for a URI with an unspecifi= ed > authority to a multicast address in order to identify the end-points to > which I could subsequently send direct requests.=A0 For that use, I would > either have to be able to examine the envelope information (the address > provided via recvfrom(2)), or assume I could reconstruct the resource URI= at > the responding end-point from option headers. > Dunno how the latter approach will help unless you have a DNS client and can resolve the authority. > For example, I think this is how I would have to do resource discovery wi= th > a URI like "/.well-known/r?name=3Dtemperature": multicast it to all-hosts= , > then somehow extract from the responses the addresses of the end-points t= hat > can provide temperatures.=A0 How do I do that extraction? > If all you have is UDP and CoAP, then recvfrom(). Note that n=3DLight, as = in figures 9 & 10 of the draft, is a *resource* name and not a service (end-po= int) name. DNS-SD has little to do with browsing resources (except what might be derived from examining the service subtype or contents of its TXT record= ) and shouldn't be used as a resource registry. Again, that's another email. > All this is assuming end-points are defined by one or more UDP > "end-point"s.=A0 Angelo Castellani suggested on 31 May that end-point in = REST > referred to something that retained state, so a resource to which a > subscription existed necessitated creation of a new end-point that held t= he > knowledge of that subscription. > Why not represent that knowledge as a resource at the existing end-point? >> > I propose making Uri-Authority have no default, rather than an empty >> > string default: an empty string doesn't conform to the ABNF for author= ity in >> > section 3.2 of RFC3986. >> >> Really? =A0Page 18: > > Hah.=A0 Once, just once, I decide to wing it and get work done instead of > tracing the references all the way back to Genesis, and I get bit.=A0 You= 're > absolutely right; I was mis-generalizing from the http scheme. > > I still think it's worth being able to distinguish a missing authority fr= om > an empty one, though, so we can precisely recreate the text of the origin= al > URI without assuming the specific scheme treats them as equivalent. > > Peter > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > Regards, -K- From kerlyn2001@gmail.com Fri Jul 23 07:31:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915C03A68B6 for ; Fri, 23 Jul 2010 07:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 JC4UEu6vG5xu for ; Fri, 23 Jul 2010 07:31:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 2135A3A687E for ; Fri, 23 Jul 2010 07:31:34 -0700 (PDT) Received: by gyg8 with SMTP id 8so120510gyg.31 for ; Fri, 23 Jul 2010 07:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MY7h62EOB/Sp91cG3le4yxyo49dcPMLT4OHRNO7BPxc=; b=uEky47NJi31T8+veXx0AqqKmcJpHhRstPakfHzvyKq3Q5S8IufUyT5ZSI7esqSHvQU esQf0UAZ+Dy3tni/+thHVPoFn55isI1qC/m97/OEqFHHarJOIODMOuaH3358tWfpMGNC kcFaJ4xSHFRkzfrDn3wik1WJIbUSJLm2Zwly0= 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=EMOuibkTVqroUUj1VDRqTp3ikL58SDpFDZoodkN/MTieeFtGXef4psf3iMUfoUnvQE X7rT/Nn30AUUFf8nY4ToYvP0WPZLwitKRBWO2Xudp3iz97XA5FDeSdcpTcD0ZLvD7xFG FuAbU9YOvLLNUGxN1ExJYkkLoUT2O8qmLgZPM= MIME-Version: 1.0 Received: by 10.90.56.16 with SMTP id e16mr3381936aga.188.1279895505020; Fri, 23 Jul 2010 07:31:45 -0700 (PDT) Received: by 10.90.97.15 with HTTP; Fri, 23 Jul 2010 07:31:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Jul 2010 10:31:44 -0400 Message-ID: From: Kerry Lynn To: Peter Bigot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , core Subject: Re: [core] What is an end-point (was: URI splitting (was: Re: explicit option for URI query part)) 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, 23 Jul 2010 14:31:38 -0000 A few corrections... On Fri, Jul 23, 2010 at 10:20 AM, Kerry Lynn wrote: > Hi Peter, > > I'll rush in where angels fear to tread... > I meant "any multicast *request* to [IANA_TBD_PORT] arrives at the end-point." > By the proposal above, any multicast response to [IANA_TBD_PORT] arrives > at the end-point. =A0Any unicast to [IANA_TBD_PORT] =A0or the server's (o= ptional) > dynamic port in the compressed UDP range arrives at the end-point. > > >> In an asynchronous response, is the server obliged to transmit the respo= nse >> message from the same end-point as received the original request?=A0 Or = could >> it use the asynchronous response specifically to change the end-point (a >> sort of implicit redirect)? >> And here it could be that a unicast request arrives via the [IANA_TDB_PORT] but the async response is sent from the dyamic port, if there is one... > By the proposal above, the server MUST accept a unicast request to > [IANA_TBD_PORT] and SHOULD accept a unicast request on its dynamic > port, if one is bound. =A0If the latter, then it would respond via the > dynamic port. > > Regards, -K- > From cabo@tzi.org Sat Jul 24 04:28:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5AC3A6802 for ; Sat, 24 Jul 2010 04:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guEzDN2rPeK2 for ; Sat, 24 Jul 2010 04:28:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 7607D3A6907 for ; Sat, 24 Jul 2010 04:28:04 -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 o6N98OlW000845; Fri, 23 Jul 2010 11:08:24 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 34BBDD0C1; Fri, 23 Jul 2010 11:08:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <29FD2178-FAF2-4122-B571-362F8ADF3324@cisco.com> Date: Fri, 23 Jul 2010 11:08:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCDE7E3-0B35-42B0-9A02-ACC2BA40CDDA@tzi.org> References: <29FD2178-FAF2-4122-B571-362F8ADF3324@cisco.com> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] Draft Agenda for IETF 78 CORE WG 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, 24 Jul 2010 11:28:06 -0000 I would like to ask presenters to send me their slides as early as = possible. Getting them by Sunday morning CEST, allows the chairs to look at them = during/around the CoAP plugfest, which might help us allocating the time = properly (i.e., thinly veiled threat: no early slides, less time). These Sunday slides need not be final, but they should be mostly = complete and indicate the general direction of the discussion desired. If the slides are not indicative of what you will be saying, please add = some presenter notes. I would like to have a final set of slides on the meetings material = manager on Monday, in order that non-native English speakers have time = to look at them before the meeting. I'll take last-minute changes until = Wed 0800, but these should be minor changes. We would like to take the meeting time for discussion, not for laptop = swapping, so all presentation will be from one laptop. Into this slide set, I can integrate slides in ppt/pptx/key best. (odp = might work too, but why don't you do the exporting...) PDF is fine, too, but increases setup time during the meeting a bit. If possible, please cut down on slide backgrounds (white works best), = animations unless they really illustrate something, logos etc. Gruesse, Carsten > Draft Agenda v1=20 >=20 > This agenda is likely to change as we figure out how to devote more = time to the key topics. You will note the times below add up to much = more time than we have.=20 >=20 >=20 > Status Update & Administrative - 10 min (Chairs)=20 >=20 >=20 > Base CoAP Protocol - 40 min (Zach) > draft-ietf-core-coap-01.txt >=20 >=20 > Subscriptions Options - 30 min (Klaus) > draft-hartke-coap-observe-01 >=20 >=20 > CoAP Miscellaneous Changes - 20 min (Carsten) > draft-bormann-coap-misc-05 >=20 >=20 > Congestion Control - 20 min (Lars) > draft-eggert-core-congestion-control-00 >=20 >=20 > HTTP Mapping - 15 min (Zach) > No draft on this >=20 >=20 > Sleeping Nodes - 15 min (Akbar) > draft-rahman-core-sleeping-00 >=20 >=20 > Bootstrap Approach - 15 min (Colin) > draft-oflynn-core-bootstrapping-01 >=20 >=20 > CoAP Usage - 20 min (TBD 1 or 2 people)=20 > draft-vanderstok-core-bc-01 > draft-braun-core-compressed-ipfix-01 >=20 From bergmann@tzi.org Sat Jul 24 06:31: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 EBA683A693E for ; Sat, 24 Jul 2010 06:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, WEIRD_PORT=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 Cx9-xx1KvTDJ for ; Sat, 24 Jul 2010 06:31:25 -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 287303A681F for ; Sat, 24 Jul 2010 06:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from aung.localdomain.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6ODVUhl001842; Sat, 24 Jul 2010 15:31:35 +0200 (CEST) From: Olaf Bergmann To: Peter Bigot Date: Sat, 24 Jul 2010 15:27:32 +0200 References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Message-ID: <87bp9xngzx.fsf@aung.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: [core] coapy/IPv6 also on ns.tzi.org:61617 for plugfest (Was: Re: asynchronous responses) 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, 24 Jul 2010 13:31:28 -0000 Peter, Peter Bigot writes: > I've updated coapy's git repository with server and client support for IP= v6, > and added a service that uses asynchronous responses.=A0 (No new release,= it's > only in the repository but you can fetch it.) Thanks. This now runs on coap://ns.tzi.org:61617/ as well. Gruesse, Olaf From bergmann@tzi.org Sat Jul 24 06:41: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 BD45B3A67B6 for ; Sat, 24 Jul 2010 06:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, WEIRD_PORT=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 73Jw4wdTDvLV for ; Sat, 24 Jul 2010 06:41:02 -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 3D67B3A67ED for ; Sat, 24 Jul 2010 06:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from aung.localdomain.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6ODf7lY004411 for ; Sat, 24 Jul 2010 15:41:13 +0200 (CEST) From: Olaf Bergmann To: core@ietf.org Date: Sat, 24 Jul 2010 15:41:07 +0200 Message-ID: <87aaphm1zg.fsf@aung.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [core] another coap server on ns.tzi.org:61618 up for testing 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, 24 Jul 2010 13:41:03 -0000 To prepare for the plugfest, I have started my server on coap://ns.tzi.org:61618 It provides hardly more than the minimal server configuration required for the plugfest + block option + draft-hartke-coap-observe, and accepts PUT for /filestorage (as a no-op, unfortunately). Gruesse, Olaf From pab@peoplepowerco.com Sun Jul 25 11:58:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4665B3A68EC for ; Sun, 25 Jul 2010 11:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQXqRYllN1W2 for ; Sun, 25 Jul 2010 11:58:10 -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 DFBC83A6947 for ; Sun, 25 Jul 2010 11:58:09 -0700 (PDT) Received: by vws10 with SMTP id 10so1918787vws.31 for ; Sun, 25 Jul 2010 11:58:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.5 with SMTP id v5mr3485485vch.81.1280084309258; Sun, 25 Jul 2010 11:58:29 -0700 (PDT) Received: by 10.220.162.8 with HTTP; Sun, 25 Jul 2010 11:58:29 -0700 (PDT) Date: Sun, 25 Jul 2010 13:58:29 -0500 Message-ID: From: Peter Bigot To: Kerry Lynn Content-Type: multipart/alternative; boundary=e0cb4e887ee989334d048c3adabf Cc: Carsten Bormann , core Subject: [core] Multicast in resource identification (was: Re: What is an end-point) 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, 25 Jul 2010 18:58:11 -0000 --e0cb4e887ee989334d048c3adabf Content-Type: text/plain; charset=ISO-8859-1 I like using the term "service access point" instead of "end-point". That allows us to assess requirements and behavior by deferring to a (reasonably) well-understood concept. It makes sense that a service access point is in one-to-one correspondence with scheme and authority from a URI, where authority for coap incorporates the host and port, but not the userinfo. My fundamental problem with end-points/SAPs is how to correlate URIs, unicast addresses, and multicast addresses with a SAP. At this point, I get wrapped around the axle by a fundamental issue: I can find no existing practice where multicast addresses are used as the host part of a URI authority to name a resource in a REST-style interaction. What, exactly, does it mean when the resource is an aggregate of independent, individually addressable resources that are not guaranteed to be identical? For example, when I send a non-confirmable "on" command to blue-lights.bu036.floor1, I get no response, which seems unhelpful. If I send it confirmable, I get back acks from the ones that turned on. By limiting responses for CON multicasts to those that produce a 2xx response code, the protocol itself is preventing me from getting the most useful information: which ones heard me but did *not* turn on. Unless tricks are performed, even inverting the response state wouldn't help because how do I get the (unicast) resource names for the ones that didn't turn on? This is not the problem domain REST and URIs were designed to support. REST can be made to work for CoAP when dealing with unicast resources. I have no mental model that tells me how to deal with resources identified by multicast. A quick read of the CoRE charter failed to reveal anything that requires naming groups of resources in the way that multicast works. If we eliminate the use of multicast in addressing resources, I understand what an end-point is, and can easily answer all those other questions. Service discovery and resource discovery are easy too. I suspect, though, that there are a lot of people who anticipate using CoAP in the way suggested in draft-vanderstok-coap-bc. I just don't see how it can work. Peter On Fri, Jul 23, 2010 at 9:31 AM, Kerry Lynn wrote: > A few corrections... > > On Fri, Jul 23, 2010 at 10:20 AM, Kerry Lynn wrote: > > Hi Peter, > > > > I'll rush in where angels fear to tread... > > > > I meant "any multicast *request* to [IANA_TBD_PORT] arrives > at the end-point." > > > By the proposal above, any multicast response to [IANA_TBD_PORT] arrives > > at the end-point. Any unicast to [IANA_TBD_PORT] or the server's > (optional) > > dynamic port in the compressed UDP range arrives at the end-point. > > > > > >> In an asynchronous response, is the server obliged to transmit the > response > >> message from the same end-point as received the original request? Or > could > >> it use the asynchronous response specifically to change the end-point (a > >> sort of implicit redirect)? > >> > > And here it could be that a unicast request arrives via the [IANA_TDB_PORT] > but the async response is sent from the dyamic port, if there is one... > > > By the proposal above, the server MUST accept a unicast request to > > [IANA_TBD_PORT] and SHOULD accept a unicast request on its dynamic > > port, if one is bound. If the latter, then it would respond via the > > dynamic port. > > > > > Regards, -K- > > > --e0cb4e887ee989334d048c3adabf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I like using the term "service access point" instead of "end= -point".=A0 That allows us to assess requirements and behavior by defe= rring to a (reasonably) well-understood concept.

It makes sense that= a service access point is in one-to-one correspondence with scheme and aut= hority from a URI, where authority for coap incorporates the host and port,= but not the userinfo.

My fundamental problem with end-points/SAPs is how to correlate URIs, u= nicast addresses, and multicast addresses with a SAP.=A0 At this point, I g= et wrapped around the axle by a fundamental issue:

I can find no exi= sting practice where multicast addresses are used as the host part of a URI= authority to name a resource in a REST-style interaction.

What, exactly, does it mean when the resource is an aggregate of indepe= ndent, individually addressable resources that are not guaranteed to be ide= ntical?=A0 For example, when I send a non-confirmable "on" comman= d to blue-lights.bu036.floor1, I get no response, which seems unhelpful.=A0= If I send it confirmable, I get back acks from the ones that turned on.=A0= By limiting responses for CON multicasts to those that produce a 2xx respo= nse code, the protocol itself is preventing me from getting the most useful= information: which ones heard me but did *not* turn on.=A0 Unless tricks a= re performed, even inverting the response state wouldn't help because h= ow do I get the (unicast) resource names for the ones that didn't turn = on?

This is not the problem domain REST and URIs were designed to support.= =A0 REST can be made to work for CoAP when dealing with unicast resources.= =A0 I have no mental model that tells me how to deal with resources identif= ied by multicast.

A quick read of the CoRE charter failed to reveal anything that require= s naming groups of resources in the way that multicast works.=A0 If we elimi= nate the use of multicast in addressing resources, I=20 understand what an end-point is, and can easily answer all those other=20 questions.=A0 Service discovery and resource discovery are easy too.=A0 I s= uspect, though, that there are a lot of people who anticipate using CoAP in= the way suggested in draft-vanderstok-coap-bc.

I just don't see= how it can work.

Peter

On Fri, Jul 23, 2010 at 9:31 AM= , Kerry Lynn <= kerlyn2001@gmail.com> wrote:
A few corrections...

On Fri, Jul 23, 2010 at 10:20 AM, Kerry Lynn <kerlyn2001@gmail.com> wrote:
> Hi Peter,
>
> I'll rush in where angels fear to tread...
> <snip>

I meant "any multicast *request* to [IANA_TBD_PORT] arrives
at the end-point."

> By the proposal above, any multicast response to [IANA_TBD_PORT] arriv= es
> at the end-point. =A0Any unicast to [IANA_TBD_PORT] =A0or the server&#= 39;s (optional)
> dynamic port in the compressed UDP range arrives at the end-point.
>
>
>> In an asynchronous response, is the server obliged to transmit the= response
>> message from the same end-point as received the original request?= =A0 Or could
>> it use the asynchronous response specifically to change the end-po= int (a
>> sort of implicit redirect)?
>>

And here it could be that a unicast request arrives via the [IANA_TDB= _PORT]
but the async response is sent from the dyamic port, if there is one...

> By the proposal above, the server MUST accept a unicast request to
> [IANA_TBD_PORT] and SHOULD accept a unicast request on its dynamic
> port, if one is bound. =A0If the latter, then it would respond via the=
> dynamic port.

>
> Regards, -K-
>

--e0cb4e887ee989334d048c3adabf-- From pab@peoplepowerco.com Mon Jul 26 08:19: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 49CA63A686E for ; Mon, 26 Jul 2010 08:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hobtLp04PHKA for ; Mon, 26 Jul 2010 08:19:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 440DD3A6816 for ; Mon, 26 Jul 2010 08:19:26 -0700 (PDT) Received: by eyb7 with SMTP id 7so587904eyb.31 for ; Mon, 26 Jul 2010 08:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.82.11 with SMTP id z11mr3655863ebk.29.1280157565385; Mon, 26 Jul 2010 08:19:25 -0700 (PDT) Received: by 10.220.179.134 with HTTP; Mon, 26 Jul 2010 08:19:24 -0700 (PDT) Date: Mon, 26 Jul 2010 10:19:24 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=00c09f8a54adf4aef6048c4be815 Subject: [core] REST, URIs, and constrained devices 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 Jul 2010 15:19:28 -0000 --00c09f8a54adf4aef6048c4be815 Content-Type: text/plain; charset=ISO-8859-1 After an impromptu telecon with Kerry this morning (very effective), I have a better understanding for my own concerns about CoAP's compability with basic REST principles. 1) URI Reconstruction A key feature of REST is self-contained messages: this is what enables caching and gateways to be transparent. Anything that requires access to non-REST layers to obtain complete information interferes with this. >From Fielding's dissertation(section 6.3.2.1): One of the worst mistakes in the early HTTP design was the decision not to send the complete URI that is the target of a request message, but rather send only those portions that were not used in setting up the connection. The assumption was that a server would know its own naming authority based on the IP address and TCP port of the connection. However, this failed to anticipate that multiple naming authorities might exist on a single server, which became a critical problem as the Web grew at an exponential rate and new domain names (the basis for naming authority within the http URL namespace) far exceeded the availability of new IP addresses. HTTP/1.0 provided the scheme, path, query, and fragment parts, but addition of Host was required in HTTP/1.1 because it was not possible to adequately reconstruct the URI authority from available envelope information. (Note that constrained nodes may be unable to identify the name used to resolve their unicast address, let alone the name used to locate a multicast address they listen to.) CoAP must clearly define how it intends to solve the same problem of URI reconstruction. It is CoAP's responsibility to translate the authority part of a URI into the address and port to which messages should be sent, and to reconstruct from address, port, and other envelope information sufficient information to provide the REST level with the URI to which the message pertains, both at servers to which requests are sent and at clients to which responses are sent (synchronously or asynchronously). In a REST-ful system, I may not know whether a specific URI identifies a proxy or an origin server. If the transaction layer requires this in order to determine whether it is necessary to include Uri-Authority and other options, or to address the message to a different host and port than is implied by the authority, CoAP must define how this is done. 2) Groups of resources on distributed devices A second key feature of REST is that it describes a client-server model where addressable resources are transferred through a representation of their state. If CoRE wants to extend the concept of URI to denote a distributed resource which is an aggregation of independently managed state, it must define the processes by which (a) the state representation in a request is distributed, and (b) the state representations gathered from responses are combined to return to the REST client a meaningful representation of the state of the distributed resource. In particular, this is necessary for any access to constrained devices through an HTTP gateway, as implied by the "HTTP REST based API" requirement in the CoRE charter. An HTTP client will not accept multiple responses to a single request. Peter --00c09f8a54adf4aef6048c4be815 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After an impromptu telecon with Kerry this morning (very effective), I have= a better understanding for my own concerns about CoAP's compability wi= th basic REST principles.

1) URI Reconstruction

A key feature= of REST is self-contained messages: this is what enables caching and gatew= ays to be transparent.=A0 Anything that requires access to non-REST layers = to obtain complete information interferes with this.=A0 From F= ielding's dissertation (section 6.3.2.1):
=A0
One of the worst mistakes in the e= arly HTTP design was the decision not=20 to send the complete URI that is the target of a request message, but=20 rather send only those portions that were not used in setting up the=20 connection. The assumption was that a server would know its own naming=20 authority based on the IP address and TCP port of the connection.=20 However, this failed to anticipate that multiple naming authorities=20 might exist on a single server, which became a critical problem as the=20 Web grew at an exponential rate and new domain names (the basis for=20 naming authority within the http URL namespace) far exceeded the=20 availability of new IP addresses.

HTTP/1.0 provided the = scheme, path, query, and fragment parts, but addition of Host was required = in HTTP/1.1 because it was not possible to adequately reconstruct the URI a= uthority from available envelope information.=A0 (Note that constrained nod= es may be unable to identify the name used to=20 resolve their unicast address, let alone the name used to=20 locate a multicast address they listen to.)

CoAP must clearly define how it intends to solve the same problem of UR= I reconstruction.

It is CoAP's responsibility to translate the a= uthority part of a URI into the address and port to which messages should b= e sent, and to reconstruct from address, port, and other envelope informati= on sufficient information to provide the REST level with the URI to which t= he message pertains, both at servers to which requests are sent and at clie= nts to which responses are sent (synchronously or asynchronously).

In a REST-ful system, I may not know whether a specific URI identifies = a proxy or an origin server.=A0 If the transaction layer requires this in o= rder to determine whether it is necessary to include Uri-Authority and othe= r options, or to address the message to a different host and port than is i= mplied by the authority, CoAP must define how this is done.

2) Groups of resources on distributed devices

A second key featu= re of REST is that it describes a client-server model where addressable res= ources are transferred through a representation of their state.

If CoRE wants to extend the concept of URI to denote a distributed resource= which is an aggregation of independently managed state, it must define the= processes by which (a) the state representation in a request is distribute= d, and (b) the state representations gathered from responses are combined t= o return to the REST client a meaningful representation of the state of the= distributed resource.

In particular, this is necessary for any access to constrained devices = through an HTTP gateway, as implied by the "HTTP REST based API" = requirement in the CoRE charter.=A0 An HTTP client will not accept multiple= responses to a single request.

Peter

--00c09f8a54adf4aef6048c4be815-- From angelo.castellani@gmail.com Mon Jul 26 09:04: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 863E83A6C39 for ; Mon, 26 Jul 2010 09:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_05=-1.11, 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 nfWKEZNKcIef for ; Mon, 26 Jul 2010 09:04:24 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 171D63A67FE for ; Mon, 26 Jul 2010 09:04:23 -0700 (PDT) Received: by bwz7 with SMTP id 7so3404702bwz.31 for ; Mon, 26 Jul 2010 09:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=bUN1GRDxZPVLR3oZhW1OCvBQg6Ca3uA2pOiG2b7/06A=; b=Tbzlh4mKEkcg/xxNwH2suq//v+EMOcivBK3VYZygLGGluqmkJQTQVa0vFsRLldzGDc +74t8dqzmKs5LzbQIVTH483ksRIbQV479KosCyyBEWx0lh30QzdqWbCQVR8tVlt181hj +F0Q3aPLD8P5RE+JN9OnZrOfgK1m1kVsm5rhU= 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=WfFX52kww5VKwPb6LNocZu2x5qz1WMlCadVvRqz+Lzo0yj+S4hTuwuDOycNDDihwaI jRLUIhDwHo0Hlsf98OHmVJn6pLjFzEf6wa7ReU0HsKQaX6Q/4ESFPWqf48QrrqIWPZHD PS6y2DuDU6CXghWO6pSHBYDPcE1f+A1CWa6RA= Received: by 10.204.103.136 with SMTP id k8mr5792095bko.37.1280160281371; Mon, 26 Jul 2010 09:04:41 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.204.24.13 with HTTP; Mon, 26 Jul 2010 09:04:21 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Mon, 26 Jul 2010 18:04:21 +0200 X-Google-Sender-Auth: BmGuIxdtw8J9itewzm1car4ecZY Message-ID: To: Peter Bigot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] REST, URIs, and constrained devices 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 Jul 2010 16:04:25 -0000 +1 On Mon, Jul 26, 2010 at 17:19, Peter Bigot wrote: > After an impromptu telecon with Kerry this morning (very effective), I ha= ve > a better understanding for my own concerns about CoAP's compability with > basic REST principles. > > 1) URI Reconstruction > > A key feature of REST is self-contained messages: this is what enables > caching and gateways to be transparent.=A0 Anything that requires access = to > non-REST layers to obtain complete information interferes with this.=A0 F= rom > Fielding's dissertation (section 6.3.2.1): > > One of the worst mistakes in the early HTTP design was the decision not t= o > send the complete URI that is the target of a request message, but rather > send only those portions that were not used in setting up the connection. > The assumption was that a server would know its own naming authority base= d > on the IP address and TCP port of the connection. However, this failed to > anticipate that multiple naming authorities might exist on a single serve= r, > which became a critical problem as the Web grew at an exponential rate an= d > new domain names (the basis for naming authority within the http URL > namespace) far exceeded the availability of new IP addresses. > > HTTP/1.0 provided the scheme, path, query, and fragment parts, but additi= on > of Host was required in HTTP/1.1 because it was not possible to adequatel= y > reconstruct the URI authority from available envelope information.=A0 (No= te > that constrained nodes may be unable to identify the name used to resolve > their unicast address, let alone the name used to locate a multicast addr= ess > they listen to.) > > CoAP must clearly define how it intends to solve the same problem of URI > reconstruction. > > It is CoAP's responsibility to translate the authority part of a URI into > the address and port to which messages should be sent, and to reconstruct > from address, port, and other envelope information sufficient information= to > provide the REST level with the URI to which the message pertains, both a= t > servers to which requests are sent and at clients to which responses are > sent (synchronously or asynchronously). > > In a REST-ful system, I may not know whether a specific URI identifies a > proxy or an origin server.=A0 If the transaction layer requires this in o= rder > to determine whether it is necessary to include Uri-Authority and other > options, or to address the message to a different host and port than is > implied by the authority, CoAP must define how this is done. > > 2) Groups of resources on distributed devices > > A second key feature of REST is that it describes a client-server model > where addressable resources are transferred through a representation of > their state. > > If CoRE wants to extend the concept of URI to denote a distributed resour= ce > which is an aggregation of independently managed state, it must define th= e > processes by which (a) the state representation in a request is distribut= ed, > and (b) the state representations gathered from responses are combined to > return to the REST client a meaningful representation of the state of the > distributed resource. > > In particular, this is necessary for any access to constrained devices > through an HTTP gateway, as implied by the "HTTP REST based API" requirem= ent > in the CoRE charter.=A0 An HTTP client will not accept multiple responses= to a > single request. > > Peter > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From cabocabo@gmail.com Mon Jul 26 09:32:02 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 51D8C3A67B6 for ; Mon, 26 Jul 2010 09:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GHRDRaNlcRRy for ; Mon, 26 Jul 2010 09:31:58 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B1D323A6C3C for ; Mon, 26 Jul 2010 09:31:57 -0700 (PDT) Received: by ewy22 with SMTP id 22so1043609ewy.31 for ; Mon, 26 Jul 2010 09:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=1mfVNsyC8GJxaVPLymwDN/O4mMpjh0jO/L0MgnEOlFs=; b=pVALIaioX5I8UUUCjcRwoxe3ykHe//nLho8jkRgVvOhYElqnahSPIdxl3BYPhdpmze BePbJkkDoZZF9XrHHzzq1DEas/dnSy2ZzsyFSLbMQtf6iEc7pLeL/81ZuSy+9dsI1R6V wjYeDLx8HHKMBTnTUfkxC4HHBniQ9ck6PIjdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=uSLWbbB+FfyIDXJ8GhrYYKIB3jBKEgHQI7goQYWMBhdbSuxQT9cFzyrZ/eE8V6GPYv eGyg/Mk5IsllzASeqzjKV2Hq1XHvK1Cub+EE5fFEq6OHeim3neozyNObINJkcGosljxf WwWklPbPSKavjR9Iz1xLFHQgfHx5Ej7NkaMDg= Received: by 10.213.19.67 with SMTP id z3mr3849747eba.87.1280161938146; Mon, 26 Jul 2010 09:32:18 -0700 (PDT) Received: from dhcp-97f9.meeting.ietf.org (dhcp-97f9.meeting.ietf.org [130.129.151.249]) by mx.google.com with ESMTPS id v8sm5953853eeh.14.2010.07.26.09.32.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Jul 2010 09:32:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 26 Jul 2010 18:32:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13B8B557-8113-498A-A474-4B23DEC50B66@gmail.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] REST, URIs, and constrained devices 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 Jul 2010 16:32:02 -0000 On Jul 26, 2010, at 17:19, Peter Bigot copied from Roy Fielding's = dissertation: > One of the worst mistakes in the early HTTP design was the decision = not to send the complete URI that is the target of a request message, = but rather send only those portions that were not used in setting up the = connection. The assumption was that a server would know its own naming = authority based on the IP address and TCP port of the connection. = However, this failed to anticipate that multiple naming authorities = might exist on a single server, which became a critical problem as the = Web grew at an exponential rate and new domain names (the basis for = naming authority within the http URL namespace) far exceeded the = availability of new IP addresses This is referring to the common practice of hosting multiple "virtual = servers" or "virtual hosts" behind one IPv4 address. An analogue in the world of constrained nodes might be an A/D converter = with multiple inputs that mean completely different things (e.g., = temperature in room X and airflow in room Y) and are therefore addressed = under a different authority. There are several differences between HTTP and CoAP that may make the = solution look different than the one that would have been optimal for = HTTP. -- Many applications of CoAP will use an IPv6 address as the authority. =20= Running "virtual servers" in this case requires multiple IPv6 = addresses. -- It is much easier to put multiple IPv6 addresses on a host than = multiple IPv4 addresses. -- Sending the IPv6 address twice in a packet (destination address, = authority) is a much higher expense in constrained networks than with = the 500 byte HTTP headers we are used to. Using some form of compression (as I proposed in = http://www.tzi.org/~cabo/draft-bormann-6lowpan-ghc-00pre.txt for other = uses in 6LoWPAN) would solve the latter problem (if we have a binary = representation, such as the Uri-Authority-Binary in coap-misc). But can't we do that optimization at the CoAP level? Can't the default = value for Uri-Authority be the destination (transport) address of the = packet? Such a default value would still require simple nodes to process the = option if present. We could go one step further and disallow sending = the option with a value that coincides with the destination transport = address. That might be part of a solution for using IPv6 addresses as authority. = We still need a way to efficiently handle DNS names as the authority -- = of course, there is no way to apply the default proposed above, and to = make simple nodes simple (i.e., not requiring support of DNS names on = them). Gruesse, Carsten From zach@sensinode.com Tue Jul 27 02:12: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 F17463A6BB5 for ; Tue, 27 Jul 2010 02:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_102=0.6, J_CHICKENPOX_25=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 mCALxqkxnnUk for ; Tue, 27 Jul 2010 02:11:57 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4806F3A6BB8 for ; Tue, 27 Jul 2010 02:11:53 -0700 (PDT) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6R9C84l028663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Jul 2010 12:12:10 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: Date: Mon, 26 Jul 2010 23:02:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05AB60D7-039D-4479-9D6A-3588521950D7@sensinode.com> References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> To: Brian Frank X-Mailer: Apple Mail (2.1081) Cc: Carsten Bormann , core Subject: Re: [core] proposal: header options may appear at most once 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, 27 Jul 2010 09:12:05 -0000 +1. On Jul 21, 2010, at 11:40 PM, Brian Frank wrote: > I think option headers should only appear once. So I like Carstens = suggestion that the delta is encoded minus one (so that you can never = have zero). >=20 > Multiple options seems really confusing from a semantic perspective = (especially given our current list of options such as Uri-Path, etc) >=20 > On Wed, Jul 21, 2010 at 4:15 PM, Peter Bigot = wrote: > On Wed, Jul 21, 2010 at 2:17 PM, Carsten Bormann = wrote: > We don't know that yet. > For instance, if we go for that Uri-Query idea, we will have to allow = multiple instances. >=20 > FWIW, I would strongly object to a repeated Uri-Query option. A = repeated Query-Param option makes sense, but a URI has at most one query = part, and it does not necessarily encode a sequence of key/value pairs. >=20 >=20 > > =95 An HTTP header field-name can appear multiple times only = if the field content admits a sequence, and the header content could = have been represented by a single field with the catenated content. >=20 > HTTP has commas there in its syntax. > We don't want to have the same kind of commas, I strongly believe. >=20 > Sure, not as a general rule, but what's wrong with defining it for = specific options? Certain options have meaning when repeated, and it = makes sense to allow for that in their representation. For options that = make no sense if repeated, the representation should disallow = repetition. As you said: prevent the expression of nonsense. = Everything's good. >=20 > I see no reason why Query-Param could not itself encode its multiple = values as a sequence of keys with optional values, with the number of = such blocks determined implicitly or explicitly. In fact, to define it = as a sequence of key/optional value blocks separated by ASCII ampersands = would make it trivial to encode from a URI, while leaving a higher-level = API free to split it into its components for the application developers' = convenience without affecting its interpretation. >=20 > Disallowing option repetition also relieves some of the pressure on = the size of the num_options field. >=20 > BTW, the obvious solution in your Python interface is to offer an = Array exactly when there are multiple instances of an option and the = single instance otherwise. (This is what I'll do in the Ruby version, = if I ever get any more time to work on that.) >=20 > As a developer my reaction is "No", but then I admit to a dislike for = duck-typing. I don't want my code splattered with: >=20 > ct =3D message.findOption(ContentType) > if ct is None: > # process as text/plain > ContentType.Default.process(message) > elif isinstance(ct, ContentType): > # process as ct.value > rv.process(message) > else: > # what the heck does this mean? > for sub_ct in ct: > sub_ct.process(message) >=20 > Especially since I'd then have to introduce error-handling at every = point-of-call for cases like Content-Type where it makes no sense for = the option to be repeated. I can't have my server throw an uncaught = exception attempting to invoke a method on a list just because somebody = sent me a packet with decodable garbage and I didn't bother to check for = the situation; nor do I care for top-level "Something bad happened = somewhere"-style recovery. >=20 > But that's getting towards religion and is off-topic, except to the = extent that the same problem will occur in C where run-time type = checking is not an option and I will be returning either a null pointer = or a pointer to a single option value (which may have multiple elements, = if appropriate). >=20 > Peter >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Tue Jul 27 02:12: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 088CF3A6BC6 for ; Tue, 27 Jul 2010 02:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 U6+04XYxbdoq for ; Tue, 27 Jul 2010 02:12: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 7BEB33A6BAB for ; Tue, 27 Jul 2010 02:12:04 -0700 (PDT) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6R9C84m028663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Jul 2010 12:12:18 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <3EA7B0C8-E64C-407A-BEE2-C38798CA3641@gmail.com> Date: Mon, 26 Jul 2010 23:13:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CCAEDAB-3E0F-48C8-A339-E6FB8B266C56@sensinode.com> References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> <3EA7B0C8-E64C-407A-BEE2-C38798CA3641@gmail.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] proposal: header options may appear at most once 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, 27 Jul 2010 09:12:16 -0000 On Jul 22, 2010, at 6:59 PM, Carsten Bormann wrote: >> =95 Each option definition should indicate whether the minimum = number of occurrences is zero or one (optional or required); >=20 > Sounds good. Actually, the answer would always be "optional", as we = don't have any required options. > (I.e., a 4-byte CoAP message with oc=3D0 and meaningful ttype/code is = a good message.) >=20 >> =95 Each option definition should indicate whether the maximum = number of occurrences is one or unbounded; >=20 > An option definition must definitely say what it actually means to = have multiple occurrences, if that is to be allowed. > (And the summary table could indeed have a column that indicates = whether the option is "repeatable".) Yep, we should do this. >=20 >> =95 Message recipients are not obligated to diagnose violation = of multiplicity restrictions for any option (meaning, for example, that = they can do whatever they want if they receive multiple Uri-Path options = in a PUT or GET message). >=20 > "Be liberal in what you accept". (But this is also the road to = tag-soup hell.) > Still, I agree there should be no requirement on a node to detect and = reject all violations of message syntax. > (My demo implementation certainly doesn't.) > But an implementation also shouldn't go out of its way to process = invalid messages. Agreed (except for the multiple Uri-Path options ides....). >=20 >> (Motivation for that last one: unless a node is obligated to = recognize an option even if it doesn't support it, >=20 > Elective options can always be safely ignored by definition. > Requiring to detect violations in an option you don't understand would = indeed be absurd. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pab@peoplepowerco.com Tue Jul 27 05:46: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 011863A6B86 for ; Tue, 27 Jul 2010 05:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljcZk4+WjeO3 for ; Tue, 27 Jul 2010 05:46:08 -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 979D23A699E for ; Tue, 27 Jul 2010 05:46:08 -0700 (PDT) Received: by vws10 with SMTP id 10so3769568vws.31 for ; Tue, 27 Jul 2010 05:46:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.49.204 with SMTP id w12mr5072284vcf.243.1280234789923; Tue, 27 Jul 2010 05:46:29 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Tue, 27 Jul 2010 05:46:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Jul 2010 07:46:29 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e6469ae0e1eb27048c5de347 Cc: core Subject: Re: [core] header option encoding 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, 27 Jul 2010 12:46:10 -0000 --0016e6469ae0e1eb27048c5de347 Content-Type: text/plain; charset=ISO-8859-1 I've seen no argument that supports the position that all options needed by small device will be numbered 15 or less. We have not yet defined all options, and have not yet formalized the need for application-specific options which will probably not be within this range. Peter On Thu, Jul 22, 2010 at 11:39 AM, Carsten Bormann wrote: > On Jul 22, 2010, at 18:22, Peter Bigot wrote: > > > Why do you think small devices won't need to do fencepost processing? > > Because all the options they need to send will be numbered 15 or less. > > > Doesn't that depend on the options they need to process, and what's in > the packets they get sent? > > Yes (for sending). > No (for receiving, as 14/28/etc. are just elective options that are > ignored, so the fencepost processing is zero code on reception). > > Gruesse, Carsten > > --0016e6469ae0e1eb27048c5de347 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've seen no argument that supports the position that all options neede= d by small device will be numbered 15 or less.=A0 We have not yet defined a= ll options, and have not yet formalized the need for application-specific o= ptions which will probably not be within this range.

Peter

On Thu, Jul 22, 2010 at 11:39 A= M, Carsten Bormann <cabocabo@gmail.com> wrote:
On Jul 22, 2010, at 18:22, Peter Bigot wrote:

> Why do you think small devices won't need to do fencepost processi= ng?

Because all the options they need to send will be numbered 15 or less= .

> Doesn't that depend on the options they need to process, and what&= #39;s in the packets they get sent?

Yes (for sending).
No (for receiving, as 14/28/etc. are just elective options that are ignored= , so the fencepost processing is zero code on reception).

Gruesse, Carsten


--0016e6469ae0e1eb27048c5de347-- From pab@peoplepowerco.com Tue Jul 27 05:46: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 16CF73A68D4 for ; Tue, 27 Jul 2010 05:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajjRdhzpjDSa for ; Tue, 27 Jul 2010 05:46:14 -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 CE8AC3A6BB4 for ; Tue, 27 Jul 2010 05:46:12 -0700 (PDT) Received: by mail-vw0-f44.google.com with SMTP id 10so3769568vws.31 for ; Tue, 27 Jul 2010 05:46:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.199 with SMTP id u7mr5059617vch.140.1280234794767; Tue, 27 Jul 2010 05:46:34 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Tue, 27 Jul 2010 05:46:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Jul 2010 07:46:34 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=e0cb4e88759d2bd45e048c5de47c Subject: Re: [core] header option encoding 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, 27 Jul 2010 12:46:18 -0000 --e0cb4e88759d2bd45e048c5de47c Content-Type: text/plain; charset=ISO-8859-1 So far, only Carsten and I have weighed in on this publicly, and I've been re-sensitized to the presence of what I believe to be unnecessary complexity in CoAP as currently drafted. I'd like a consensus measure on the question of whether options should be encoded as: - a single octet encoding a delta and a length, with longer lengths indicated by a flag value; - two octets encoding the option value and the length Comments in the WG, or a hum measure at the CoAP session (accepting the disenfranchisement of those who cannot be physically present: chime in here if so), would help settle the question. Peter On Thu, Jul 22, 2010 at 10:55 AM, Peter Bigot wrote: > Out of curiosity, I just wrote stub C routines to encode and decode options > and measured the size of space-optimized MSP430 object code. > > Between delta management, fencepost processing for large deltas, and > variable option lengths, the code sizes are 66 bytes to process the options, > and 190 to encode them. > > In contrast, an encoding that uses one byte for the option code, one byte > for the length, and the value requires 28 bytes to process and 44 bytes to > encode them. > > Of course, this is strongly affected by what "process" means: for the > purposes of this test I simply summed the observed option types and lengths, > to ensure the values were correctly decoded. My code may be poor or wrong, > since I only compiled it and didn't run it; attached for anybody who wants > to optimize it. > > Are we locked to the current option encoding? OK if we are, but a 135% > space penalty for decoding and a 330% penalty for encoding is high for > something that saves at most one byte per encoded option per message. > > 00000000 g F .text 0000003e process_options > 00000086 g F .text 000000be encode_option > 0000003e g F .text 0000001c alt_process_options > 0000005a g F .text 0000002c alt_encode_option > > Peter > > --e0cb4e88759d2bd45e048c5de47c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So far, only Carsten and I have weighed in on this publicly, and I've= =20 been re-sensitized to the presence of what I believe to be unnecessary=20 complexity in CoAP as currently drafted.=A0 I'd like a consensus measur= e=20 on the question of whether options should be encoded as:
  • a single octet encoding a delta and a length, with longer lengths i= ndicated by a flag value;
  • two octets encoding the option value and = the length
Comments in the WG, or a hum measure at the CoAP session (accepting the=20 disenfranchisement of those who cannot be physically present: chime in=20 here if so), would help settle the question.

Peter

On Thu, Jul 22, 2010 at 10:55 AM, Peter Bigot <pab@peoplepowerco.com> wrote:
Out of curiosity,= I just wrote stub C routines to encode and decode options and measured the= size of space-optimized MSP430 object code.

Between delta management, fencepost processing for large deltas, and va= riable option lengths, the code sizes are 66 bytes to process the options, = and 190 to encode them.

In contrast, an encoding that uses one byte for the option code, one by= te for the length, and the value requires 28 bytes to process and 44 bytes = to
encode them.

Of course, this is strongly affected by what &quo= t;process" means: for the purposes of this test I simply summed the ob= served option types and lengths,
to ensure the values were correctly decoded.=A0 My code may be poor or wron= g, since I only compiled it and didn't run it; attached for anybody who= wants to optimize it.

Are we locked to the current option encoding?= =A0 OK if we are, but a 135% space penalty for decoding and a 330% penalty = for encoding is high for
something that saves at most one byte per encoded option per message.
00000000 g=A0=A0=A0=A0 F .text=A0 0000003e process_options
00000086 g= =A0=A0=A0=A0 F .text=A0 000000be encode_option
0000003e g=A0=A0=A0=A0 F = .text=A0 0000001c alt_process_options
0000005a g=A0=A0=A0=A0 F .text=A0 0000002c alt_encode_option

Peter


--e0cb4e88759d2bd45e048c5de47c-- From pab@peoplepowerco.com Tue Jul 27 05:48:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5B43A6A49 for ; Tue, 27 Jul 2010 05:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMCdjdZRMHOr for ; Tue, 27 Jul 2010 05:48:37 -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 49E023A680A for ; Tue, 27 Jul 2010 05:48:37 -0700 (PDT) Received: by vws10 with SMTP id 10so3772323vws.31 for ; Tue, 27 Jul 2010 05:48:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.49.204 with SMTP id w12mr5074258vcf.243.1280234938879; Tue, 27 Jul 2010 05:48:58 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Tue, 27 Jul 2010 05:48:58 -0700 (PDT) In-Reply-To: <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> Date: Tue, 27 Jul 2010 07:48:58 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e6469ae0c2d16a048c5dec8f Cc: core Subject: Re: [core] proposal: header options may appear at most once 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, 27 Jul 2010 12:48:38 -0000 --0016e6469ae0c2d16a048c5dec8f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 21, 2010 at 5:14 PM, Carsten Bormann wrote: > So let's look at another example: what about Etags in requests? > These are variable-length, and we are proposing you can send multiple to > allow a 304 response for any of them. > (Of course, you can now argue you don't like that proposal, but that would > look like the encoding should determine what is possible semantically.) > I admitted the value of multiple options for Etags but said I couldn't assess whether the motivating use-case for multiple Etags was valid. If it's the situation in section 3 of hartke-coap-observe I call "bogus". For that to be useful the following conditions have to hold: - The use case requires that a message be sent anyway; the Etag only permits transfer of the etag instead of the whole state. Therefore, the size of a state representation has to be sufficiently larger than the etag value that it's worth conveying the state as an etag. - The server must consistently use the same etag for the same representation. Rules out one-up counters, the obvious etag on a constrained environment. - The set of expected representations has to be so small that it's reasonable to cache them all. In this case, why wouldn't the representation be a label for the state, hence small? - All clients would need to use the Etags caching; any client that doesn't declare itself in possession of the cached value would still need to be sent the full state representation Remembering that we're talking about constrained devices, this all seems extremely unlikely. Unless a compelling use case can be found, I re-assert my support for options appearing at most once, with those few options for which multiple values make sense represented either in an option-specific encoding (as with the proposed Accepts) or by developing a generic LV or separator-based representation. Peter --0016e6469ae0c2d16a048c5dec8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 21, 2010 at 5:14 PM, Carsten Bormann= <cabocabo@gmail.com> wrote:
So let's look at another example: what about Etags in requests?
These are variable-length, and we are proposing you can send multiple to al= low a 304 response for any of them.
(Of course, you can now argue you don't like that proposal, but that wo= uld look like the encoding should determine what is possible semantically.)=

I admitted the value of multiple options for Etag= s but said I couldn't assess whether the motivating use-case for multip= le Etags was valid. If it's the situation in section 3 of hartke-coap-o= bserve I call "bogus".

For that to be useful the following conditions have to hold:
    The use case requires that a message be sent anyway; the Etag only permits= transfer of the etag instead of the whole state.=A0 Therefore, the size of= a state representation has to be sufficiently larger than the etag value t= hat it's worth conveying the state as an etag.
  • The server must consistently use the same etag for the same representat= ion.=A0 Rules out one-up counters, the obvious etag on a constrained enviro= nment.
  • The set of expected representations has to be so small that = it's reasonable to cache them all.=A0 In this case, why wouldn't th= e representation be a label for the state, hence small?
  • All clients would need to use the Etags caching; any client that doesn&= #39;t declare itself in possession of the cached value would still need to = be sent the full state representation
Remembering that we'= re talking about constrained devices, this all seems extremely unlikely.
Unless a compelling use case can be found, I re-assert my support for o= ptions appearing at most once, with those few options for which multiple va= lues make sense represented either in an option-specific encoding (as with = the proposed Accepts) or by developing a generic LV or separator-based repr= esentation.

Peter
--0016e6469ae0c2d16a048c5dec8f-- From pab@peoplepowerco.com Tue Jul 27 06:03: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 85AF23A687A for ; Tue, 27 Jul 2010 06:03:35 -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=[AWL=-0.774, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE4QWkiE9Why for ; Tue, 27 Jul 2010 06:03:34 -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 6CFAE3A6829 for ; Tue, 27 Jul 2010 06:03:33 -0700 (PDT) Received: by vws10 with SMTP id 10so3787219vws.31 for ; Tue, 27 Jul 2010 06:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.168.12 with SMTP id s12mr5197583vcy.100.1280235834875; Tue, 27 Jul 2010 06:03:54 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Tue, 27 Jul 2010 06:03:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Jul 2010 08:03:54 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=001485e9a65c2a9ee1048c5e2258 Subject: Re: [core] header option encoding 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, 27 Jul 2010 13:03:36 -0000 --001485e9a65c2a9ee1048c5e2258 Content-Type: text/plain; charset=ISO-8859-1 That for consensus; for "running code" I'll undertake to provide, later today, a variant of my Python system which supports the alternative option encoding. I'll also add support for larger option type codes, so others can evaluate the fencepost processing and other issues. I suspect that hasn't been adequately tested. Peter On Tue, Jul 27, 2010 at 7:46 AM, Peter Bigot wrote: > So far, only Carsten and I have weighed in on this publicly, and I've been > re-sensitized to the presence of what I believe to be unnecessary complexity > in CoAP as currently drafted. I'd like a consensus measure on the question > of whether options should be encoded as: > > - a single octet encoding a delta and a length, with longer lengths > indicated by a flag value; > - two octets encoding the option value and the length > > Comments in the WG, or a hum measure at the CoAP session (accepting the > disenfranchisement of those who cannot be physically present: chime in here > if so), would help settle the question. > > Peter > > > On Thu, Jul 22, 2010 at 10:55 AM, Peter Bigot wrote: > >> Out of curiosity, I just wrote stub C routines to encode and decode >> options and measured the size of space-optimized MSP430 object code. >> >> Between delta management, fencepost processing for large deltas, and >> variable option lengths, the code sizes are 66 bytes to process the options, >> and 190 to encode them. >> >> In contrast, an encoding that uses one byte for the option code, one byte >> for the length, and the value requires 28 bytes to process and 44 bytes to >> encode them. >> >> Of course, this is strongly affected by what "process" means: for the >> purposes of this test I simply summed the observed option types and lengths, >> to ensure the values were correctly decoded. My code may be poor or >> wrong, since I only compiled it and didn't run it; attached for anybody who >> wants to optimize it. >> >> Are we locked to the current option encoding? OK if we are, but a 135% >> space penalty for decoding and a 330% penalty for encoding is high for >> something that saves at most one byte per encoded option per message. >> >> 00000000 g F .text 0000003e process_options >> 00000086 g F .text 000000be encode_option >> 0000003e g F .text 0000001c alt_process_options >> 0000005a g F .text 0000002c alt_encode_option >> >> Peter >> >> > --001485e9a65c2a9ee1048c5e2258 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That for consensus; for "running code" I'll undertake to prov= ide, later today, a variant of my Python system which supports the alternat= ive option encoding.=A0 I'll also add support for larger option type co= des, so others can evaluate the fencepost processing and other issues.=A0 I= suspect that hasn't been adequately tested.

Peter

On Tue, Jul 27, 2010 at 7:46 AM= , Peter Bigot <pab@peoplepowerco.com> wrote:
So far, only Carsten and I have weighed in on this publicly, and I've= =20 been re-sensitized to the presence of what I believe to be unnecessary=20 complexity in CoAP as currently drafted.=A0 I'd like a consensus measur= e=20 on the question of whether options should be encoded as:
  • a single octet encoding a delta and a length, with longer lengths i= ndicated by a flag value;
  • two octets encoding the option value and = the length
Comments in the WG, or a hum measure at the CoAP session (accepting the=20 disenfranchisement of those who cannot be physically present: chime in=20 here if so), would help settle the question.
Peter


On Thu, Jul 22, 2010 at 10:55 AM, Peter Bigot <= pab@peoplepowerc= o.com> wrote:
Out of curiosity,= I just wrote stub C routines to encode and decode options and measured the= size of space-optimized MSP430 object code.

Between delta management, fencepost processing for large deltas, and va= riable option lengths, the code sizes are 66 bytes to process the options, = and 190 to encode them.

In contrast, an encoding that uses one byte for the option code, one by= te for the length, and the value requires 28 bytes to process and 44 bytes = to
encode them.

Of course, this is strongly affected by what &quo= t;process" means: for the purposes of this test I simply summed the ob= served option types and lengths,
to ensure the values were correctly decoded.=A0 My code may be poor or wron= g, since I only compiled it and didn't run it; attached for anybody who= wants to optimize it.

Are we locked to the current option encoding?= =A0 OK if we are, but a 135% space penalty for decoding and a 330% penalty = for encoding is high for
something that saves at most one byte per encoded option per message.
00000000 g=A0=A0=A0=A0 F .text=A0 0000003e process_options
00000086 g= =A0=A0=A0=A0 F .text=A0 000000be encode_option
0000003e g=A0=A0=A0=A0 F = .text=A0 0000001c alt_process_options
0000005a g=A0=A0=A0=A0 F .text=A0 0000002c alt_encode_option

Peter



--001485e9a65c2a9ee1048c5e2258-- From zach@sensinode.com Tue Jul 27 06:03:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16D53A69E8 for ; Tue, 27 Jul 2010 06:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=0.408, 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 XEgJWoNCKtQL for ; Tue, 27 Jul 2010 06:03:52 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E8EFF3A6907 for ; Tue, 27 Jul 2010 06:03:50 -0700 (PDT) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6RD48ec011839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 27 Jul 2010 16:04:09 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jul 2010 15:04:09 +0200 Message-Id: <066C6C97-27A9-431A-84B7-364F847E6F1D@sensinode.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Slides for Wednesday 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, 27 Jul 2010 13:03:59 -0000 Hi Everyone, Saturday I returned (landed straight into the IETF) from 2 weeks of = vacation, and am finally up to speed on the core mailing list. I am now = finishing the slides for Wednesday's WG meeting on = draft-ietf-core-coap-01. I'll do my best to capture the main issues to = be discussed in the WG meeting and will send my slides to the chairs = later today. When they are on-line feel free to take a look and tell me = if I missed anything before the WG meeting. Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Tue Jul 27 06:10: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 DE00C3A680A for ; Tue, 27 Jul 2010 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.326, 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 F-xdLjqE-Jg9 for ; Tue, 27 Jul 2010 06:10:48 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 12E253A6802 for ; Tue, 27 Jul 2010 06:10:47 -0700 (PDT) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6RDB37q012179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Jul 2010 16:11:04 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Tue, 27 Jul 2010 15:11:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41C2327B-7117-4C0E-B05E-1C7213737E60@sensinode.com> References: <3C69F26A-9784-4479-A43E-2F58B9D8BE94@gmail.com> <297A17C5-3801-4DDA-876C-F8E41D5D6C4A@gmail.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: Carsten Bormann , core Subject: Re: [core] proposal: header options may appear at most once 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, 27 Jul 2010 13:10:52 -0000 On Jul 27, 2010, at 2:48 PM, Peter Bigot wrote: > Unless a compelling use case can be found, I re-assert my support for = options appearing at most once, with those few options for which = multiple values make sense represented either in an option-specific = encoding (as with the proposed Accepts) or by developing a generic LV or = separator-based representation. I would also like to see us take this path. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From bergmann@tzi.org Tue Jul 27 06:42: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 96CD63A6802 for ; Tue, 27 Jul 2010 06:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] 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 YuVPJhrrqk1B for ; Tue, 27 Jul 2010 06:42:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 3A3693A6901 for ; Tue, 27 Jul 2010 06:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from aung.localdomain.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6RDgbg2018707 for ; Tue, 27 Jul 2010 15:42:42 +0200 (CEST) From: Olaf Bergmann To: core@ietf.org Date: Tue, 27 Jul 2010 15:42:37 +0200 Message-ID: <87ocdtqbw2.fsf@aung.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [core] client implementations available? 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, 27 Jul 2010 13:42:30 -0000 Hi all, As follow-up of the plugfest last Sunday, Carsten asked me to collect a list of client implementations that are around. Can you please drop me a line if you have a client implementation that has been tested during or after the plugfest against one or more of the server's listed on http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest. And please note if you or your comapany do/does not want to be mentioned. Anyway, the number of implementations is important, so don't be shy... Thanks, Olaf From pab@peoplepowerco.com Tue Jul 27 06:43: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 56FFE3A6AB5 for ; Tue, 27 Jul 2010 06:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJNJ--uq3mH8 for ; Tue, 27 Jul 2010 06:43:15 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 8E9743A6A8C for ; Tue, 27 Jul 2010 06:43:15 -0700 (PDT) Received: by pzk6 with SMTP id 6so1842958pzk.31 for ; Tue, 27 Jul 2010 06:43:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.156.14 with SMTP id d14mr10348479wfe.86.1280238217589; Tue, 27 Jul 2010 06:43:37 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Tue, 27 Jul 2010 06:43:37 -0700 (PDT) Date: Tue, 27 Jul 2010 08:43:37 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=000e0cd181622ff63e048c5eb0e8 Subject: [core] proposal: drop HTTP Resource Discovery 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, 27 Jul 2010 13:43:16 -0000 --000e0cd181622ff63e048c5eb0e8 Content-Type: text/plain; charset=ISO-8859-1 After my unfortunate encounter with the axle of multicast URI authorities, I held back a long email related to similar issues. Here's one of the still-relevant pieces: I propose that section 6.4 be dropped completely. A protocol designed for interaction with constrained devices should not be attempting to supply HTTP with a resource discovery mechanism. Peter --000e0cd181622ff63e048c5eb0e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After my unfortunate encounter with the axle of multicast URI authorities, = I held back a long email related to similar issues.=A0 Here's one of th= e
still-relevant pieces:

I propose that section 6.4 be dropped co= mpletely.=A0 A protocol designed for interaction with constrained devices s= hould not be attempting to supply=A0 HTTP with a resource discovery mechani= sm.

Peter

--000e0cd181622ff63e048c5eb0e8-- From d.sturek@att.net Tue Jul 27 06:47:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A753A6995 for ; Tue, 27 Jul 2010 06:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.451 X-Spam-Level: * X-Spam-Status: No, score=1.451 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HTML_MESSAGE=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 72Tbxspo+C7u for ; Tue, 27 Jul 2010 06:47:28 -0700 (PDT) Received: from smtp104.sbc.mail.re3.yahoo.com (smtp104.sbc.mail.re3.yahoo.com [66.196.96.80]) by core3.amsl.com (Postfix) with SMTP id 65F5A3A6994 for ; Tue, 27 Jul 2010 06:47:28 -0700 (PDT) Received: (qmail 40736 invoked from network); 27 Jul 2010 13:47:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1280238467; bh=BdQO4A6xtRVBoy9jlXACcNUybUo5fNGNKpxvYJSmGRA=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=K0ZgMplxfaXUriEmFTW+3SdxcXoxn3StQdIA3mew7xtzz0Dyf1bAAXGZnTRRFFP8QW/vLZr7yU6lFWhWeaykH2iKsH/Rx9ikM4VQ4f/gb+zJD1DwIlEaWM3pfKBfK7UfMA8ko5bOTx8a5RLTQl8ODKXopycWbABz9bDNFjk/q8g= Received: from Studio (d.sturek@130.129.117.162 with login) by smtp104.sbc.mail.re3.yahoo.com with SMTP; 27 Jul 2010 06:47:47 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: tcrVggsVM1ltcc9.59eRlsvv9WkDhBrH_NIVMTHqXIIVbcY Ax95bqvQDytOScCkHxpal5pZsMeigN2y9TgzDTWVIwUh5APOZXQp8xfHk8bd bQYgmNcar.G6eN4zl9n.lDsfnGS.T6VGLEzYK7eosjUjpJ2IBdjr8QJf8bgC 5mG2_c8yww8j.DymBRnVt6.AyYcnIT0tMgTr73_WFUNerWueFp.2yieHigdT Tql.UmB5FR2CTZhCgvE0RaJWNaAbNqoyurtUrq1ou.4TR7p4ZRu2PEeKdpKm GmVheHBoaxIwq_ALhK9fgpob3b9OGTyxTdCnUJQJAzqtFkqXvXOBxgAN5Fdh KUKridcdjejAR5tLyjw6j0GT.R0spItVCcRiy2XU5ubUN1dxP1MQAfrI3b5C H X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Peter Bigot'" , "'core'" References: In-Reply-To: Date: Tue, 27 Jul 2010 06:47:44 -0700 Message-ID: <008101cb2d92$4b0a9150$e11fb3f0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01CB2D57.9EABB950" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcstkbiNRS8ffxp0RfWOhd0d8t/ZDwAADWIw Content-Language: en-us Subject: Re: [core] proposal: drop HTTP Resource Discovery 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: Tue, 27 Jul 2010 13:47:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0082_01CB2D57.9EABB950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HI Peter, If we drop Section 6.4, then I think CoAP will not really gain traction unless the intent is to align behind an existing resource discovery solution like DNS-SD which can work for both HTTP and CoAP. I think in an M2M setting, resource discovery is a MUST. Don From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Peter Bigot Sent: Tuesday, July 27, 2010 6:44 AM To: core Subject: [core] proposal: drop HTTP Resource Discovery After my unfortunate encounter with the axle of multicast URI authorities, I held back a long email related to similar issues. Here's one of the still-relevant pieces: I propose that section 6.4 be dropped completely. A protocol designed for interaction with constrained devices should not be attempting to supply HTTP with a resource discovery mechanism. Peter ------=_NextPart_000_0082_01CB2D57.9EABB950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI Peter,

If we drop Section 6.4, then I think CoAP will not really = gain traction unless the intent is to align behind an existing resource = discovery solution like DNS-SD which can work for both HTTP and = CoAP.

 

I think in an M2M setting, resource discovery is a = MUST.


Don

 

 

From:= core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Peter Bigot
Sent: Tuesday, July 27, 2010 6:44 AM
To: core
Subject: [core] proposal: drop HTTP Resource = Discovery

 

After my unfortunate = encounter with the axle of multicast URI authorities, I held back a long email = related to similar issues.  Here's one of the
still-relevant pieces:

I propose that section 6.4 be dropped completely.  A protocol = designed for interaction with constrained devices should not be attempting to = supply  HTTP with a resource discovery mechanism.

Peter

------=_NextPart_000_0082_01CB2D57.9EABB950-- From pab@peoplepowerco.com Tue Jul 27 06:48: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 29A883A6994 for ; Tue, 27 Jul 2010 06:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dujCrNM0Q3df for ; Tue, 27 Jul 2010 06:48:09 -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 12BA53A6995 for ; Tue, 27 Jul 2010 06:48:08 -0700 (PDT) Received: by vws10 with SMTP id 10so3834086vws.31 for ; Tue, 27 Jul 2010 06:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.5 with SMTP id v5mr5063409vch.244.1280238510306; Tue, 27 Jul 2010 06:48:30 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Tue, 27 Jul 2010 06:48:30 -0700 (PDT) Date: Tue, 27 Jul 2010 08:48:30 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=e0cb4e887ee9a27730048c5ec148 Subject: [core] proposal: remove required support for resource discovery 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, 27 Jul 2010 13:48:10 -0000 --e0cb4e887ee9a27730048c5ec148 Content-Type: text/plain; charset=ISO-8859-1 After my unfortunate encounter with the axle of multicast URI authorities, I held back a long email related to similar issues. Here's one of the still-relevant pieces: Section 6 currently requires that a node support "/.well-known/r" as a resource. But section 6 imposes no requirements on what resources must be described by the node. (I thought it interesting that in the test servers I probed the other day nobody included "/.well-known/r" in the list of resources provided by that very URI, though any requirement for completeness would have mandated its inclusion.) In my case, I know my infrastructure requires external traffic to come through a gateway that can provide an external mechanism for any authenticated client to obtain resource information; it could also provide this function via "/.well-known/r" in CoAP. But I should not be obliged by CoAP to add to each internal node an end-point on the well-known port with its only responsibility being to send an empty string in response to a request for "/.well-known/r", when all the real work is done over a different end-point that is accessed via 6lowpan using a compressed port. I question the value of a MUST requirement for a feature that is not itself required to do anything. If this requirement is removed, the motivation behind requiring presence of an end-point that listens on IANA_TBD_PORT is also gone, changing the MUST in section 4.4 to at best a SHOULD. Peter --e0cb4e887ee9a27730048c5ec148 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After my unfortunate encounter with the axle of multicast URI authorities, = I held back a long email related to similar issues.=A0 Here's one of th= e
still-relevant pieces:

Section 6 currently requires that a node= support "/.well-known/r" as a resource.=A0 But section 6 imposes= no requirements on what resources must be described by the node.=A0 (I tho= ught it interesting that in the test servers I probed the other day nobody = included "/.well-known/r" in the list of resources provided by th= at very URI, though any requirement for completeness would have mandated it= s inclusion.)

In my case, I know my infrastructure requires external traffic to come = through a gateway that can provide an external mechanism for any authentica= ted client to obtain resource information; it could also provide this funct= ion via "/.well-known/r" in CoAP.=A0 But I should not be obliged = by CoAP to add to each internal node an end-point on the well-known port wi= th its only responsibility being to send an empty string in response to a r= equest for "/.well-known/r", when all the real work is done over = a different end-point that is accessed via 6lowpan using a compressed port.=

I question the value of a MUST requirement for a feature that is not it= self required to do anything.

If this requirement is removed, the mo= tivation behind requiring presence of an end-point that listens on IANA_TBD= _PORT is also gone, changing the MUST in section 4.4 to at best a SHOULD.
Peter
--e0cb4e887ee9a27730048c5ec148-- From zach@sensinode.com Tue Jul 27 06:56:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0F33A6A98 for ; Tue, 27 Jul 2010 06:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 egB7ZJyfBXsA for ; Tue, 27 Jul 2010 06:56:36 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 709763A6995 for ; Tue, 27 Jul 2010 06:56:36 -0700 (PDT) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6RDuqO6014212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Jul 2010 16:56:54 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Tue, 27 Jul 2010 15:56:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3D5DB00E-8CE2-426E-B485-BAA262A9FB85@sensinode.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] proposal: remove required support for resource discovery 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, 27 Jul 2010 13:56:38 -0000 Peter, On Jul 27, 2010, at 3:48 PM, Peter Bigot wrote: > Section 6 currently requires that a node support "/.well-known/r" as a = resource. But section 6 imposes no requirements on what resources must = be described by the node. (I thought it interesting that in the test = servers I probed the other day nobody included "/.well-known/r" in the = list of resources provided by that very URI, though any requirement for = completeness would have mandated its inclusion.) That is because there is no requirement for a node to advertise all its = resources as you noted. It doesn't make sense to describe /.well-known/r = in a resource description as you just requested that resource, and it is = anyways well-known. Now e.g. /.well-known/r/sensors is a different = story.=20 > In my case, I know my infrastructure requires external traffic to come = through a gateway that can provide an external mechanism for any = authenticated client to obtain resource information; it could also = provide this function via "/.well-known/r" in CoAP. But I should not be = obliged by CoAP to add to each internal node an end-point on the = well-known port with its only responsibility being to send an empty = string in response to a request for "/.well-known/r", when all the real = work is done over a different end-point that is accessed via 6lowpan = using a compressed port. True, we have been considering if this is a MUST or SHOULD earlier. You = are correct, if a node has nothing there it should not respond.=20 > I question the value of a MUST requirement for a feature that is not = itself required to do anything. >=20 > If this requirement is removed, the motivation behind requiring = presence of an end-point that listens on IANA_TBD_PORT is also gone, = changing the MUST in section 4.4 to at best a SHOULD. I would have no problem with this, but we need to hear more thoughts = from the WG. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From skip.ashton@ember.com Tue Jul 27 07:01:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5A93A6AD2 for ; Tue, 27 Jul 2010 07:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[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 PV0yfBy+0E24 for ; Tue, 27 Jul 2010 07:01:18 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 7108C3A6AE5 for ; Tue, 27 Jul 2010 07:01:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2D94.3C1B2826" Date: Tue, 27 Jul 2010 10:01:38 -0400 Message-ID: In-Reply-To: <008101cb2d92$4b0a9150$e11fb3f0$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] proposal: drop HTTP Resource Discovery Thread-Index: AcstkbiNRS8ffxp0RfWOhd0d8t/ZDwAADWIwAACNiXA= References: <008101cb2d92$4b0a9150$e11fb3f0$@sturek@att.net> From: "Skip Ashton" To: , "Peter Bigot" , "core" Subject: Re: [core] proposal: drop HTTP Resource Discovery 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, 27 Jul 2010 14:01:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2D94.3C1B2826 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I agree with Don - for unattended and unassisted devices, resource discovery to allow them to set themselves up is critical market need. =20 Skip ________________________________ From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Don Sturek Sent: Tuesday, July 27, 2010 9:48 AM To: 'Peter Bigot'; 'core' Subject: Re: [core] proposal: drop HTTP Resource Discovery HI Peter, If we drop Section 6.4, then I think CoAP will not really gain traction unless the intent is to align behind an existing resource discovery solution like DNS-SD which can work for both HTTP and CoAP. =20 I think in an M2M setting, resource discovery is a MUST. Don =20 =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Peter Bigot Sent: Tuesday, July 27, 2010 6:44 AM To: core Subject: [core] proposal: drop HTTP Resource Discovery =20 After my unfortunate encounter with the axle of multicast URI authorities, I held back a long email related to similar issues. Here's one of the still-relevant pieces: I propose that section 6.4 be dropped completely. A protocol designed for interaction with constrained devices should not be attempting to supply HTTP with a resource discovery mechanism. Peter ------_=_NextPart_001_01CB2D94.3C1B2826 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I agree with Don - for unattended and = unassisted devices,=20 resource discovery to allow them to set themselves up is critical market = need.
 
Skip

From: core-bounces@ietf.org=20 [mailto:core-bounces@ietf.org] On Behalf Of Don = Sturek
Sent:=20 Tuesday, July 27, 2010 9:48 AM
To: 'Peter Bigot';=20 'core'
Subject: Re: [core] proposal: drop HTTP Resource=20 Discovery

HI=20 Peter,

If=20 we drop Section 6.4, then I think CoAP will not really gain traction = unless the=20 intent is to align behind an existing resource discovery solution like = DNS-SD=20 which can work for both HTTP and CoAP.

 

I=20 think in an M2M setting, resource discovery is a = MUST.


Don

 

 

From:=20 core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Peter=20 Bigot
Sent: Tuesday, July 27, 2010 6:44 AM
To:=20 core
Subject: [core] proposal: drop HTTP Resource=20 Discovery

 

After my unfortunate = encounter=20 with the axle of multicast URI authorities, I held back a long email = related to=20 similar issues.  Here's one of the
still-relevant = pieces:

I=20 propose that section 6.4 be dropped completely.  A protocol = designed for=20 interaction with constrained devices should not be attempting to = supply =20 HTTP with a resource discovery=20 mechanism.

Peter

------_=_NextPart_001_01CB2D94.3C1B2826-- From guido.moritz@uni-rostock.de Tue Jul 27 07:36:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5674F3A6BD7 for ; Tue, 27 Jul 2010 07:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gs8IJ0atXv4 for ; Tue, 27 Jul 2010 07:36:14 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 002D03A6BD4 for ; Tue, 27 Jul 2010 07:36:12 -0700 (PDT) Received: from email1.uni-rostock.de (139.30.8.208) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Jul 2010 16:36:22 +0200 Received: from Schlappi (130.129.116.163) by email1.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Jul 2010 16:36:21 +0200 From: Guido Moritz To: References: <008101cb2d92$4b0a9150$e11fb3f0$@sturek@att.net> In-Reply-To: <008101cb2d92$4b0a9150$e11fb3f0$@sturek@att.net> Date: Tue, 27 Jul 2010 16:36:24 +0200 Message-ID: <002b01cb2d99$171db460$45591d20$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CB2DA9.DAA68460" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcstkbiNRS8ffxp0RfWOhd0d8t/ZDwAADWIwAAHI2iA= Content-Language: de Cc: 'core' Subject: Re: [core] proposal: drop HTTP Resource Discovery 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, 27 Jul 2010 14:36:16 -0000 ------=_NextPart_000_002C_01CB2DA9.DAA68460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >I think in an M2M setting, resource discovery is a MUST. Jep, discovery is a main mechanism/functionality of most (all I get into my mind within 10 seconds) M2M protocols and even some H2M. Guido Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Don Sturek Gesendet: Dienstag, 27. Juli 2010 15:48 An: 'Peter Bigot'; 'core' Betreff: Re: [core] proposal: drop HTTP Resource Discovery HI Peter, If we drop Section 6.4, then I think CoAP will not really gain traction unless the intent is to align behind an existing resource discovery solution like DNS-SD which can work for both HTTP and CoAP. I think in an M2M setting, resource discovery is a MUST. Don From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Peter Bigot Sent: Tuesday, July 27, 2010 6:44 AM To: core Subject: [core] proposal: drop HTTP Resource Discovery After my unfortunate encounter with the axle of multicast URI authorities, I held back a long email related to similar issues. Here's one of the still-relevant pieces: I propose that section 6.4 be dropped completely. A protocol designed for interaction with constrained devices should not be attempting to supply HTTP with a resource discovery mechanism. Peter ------=_NextPart_000_002C_01CB2DA9.DAA68460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>I think in an M2M setting, resource discovery is a = MUST.

Jep, discovery is a main mechanism/functionality of most = (all I get into my mind within 10 seconds) M2M protocols and even some = H2M.

 

Guido

 

 

Von:<= /b> core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von = Don Sturek
Gesendet: Dienstag, 27. Juli 2010 15:48
An: 'Peter Bigot'; 'core'
Betreff: Re: [core] proposal: drop HTTP Resource = Discovery

 

HI Peter,

If we drop Section 6.4, then I think CoAP will not really = gain traction unless the intent is to align behind an existing resource = discovery solution like DNS-SD which can work for both HTTP and = CoAP.

 

I think in an M2M setting, resource discovery is a = MUST.


Don

 

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Peter Bigot
Sent: Tuesday, July 27, 2010 6:44 AM
To: core
Subject: [core] proposal: drop HTTP Resource = Discovery

 

After my unfortunate encounter with the axle of multicast URI authorities, I held = back a long email related to similar issues.  Here's one of the
still-relevant pieces:

I propose that section 6.4 be dropped completely.  A protocol = designed for interaction with constrained devices should not be attempting to = supply  HTTP with a resource discovery mechanism.

Peter

------=_NextPart_000_002C_01CB2DA9.DAA68460-- From pab@peoplepowerco.com Tue Jul 27 09:55:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200583A6B88 for ; Tue, 27 Jul 2010 09:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur7IdPzhutBx for ; Tue, 27 Jul 2010 09:55:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 880CC3A688D for ; Tue, 27 Jul 2010 09:55:25 -0700 (PDT) Received: by fxm1 with SMTP id 1so830799fxm.31 for ; Tue, 27 Jul 2010 09:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.40.11 with SMTP id s11mr1213294muj.112.1280249746966; Tue, 27 Jul 2010 09:55:46 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Tue, 27 Jul 2010 09:55:45 -0700 (PDT) In-Reply-To: <-3084466236067637910@unknownmsgid> References: <-3084466236067637910@unknownmsgid> Date: Tue, 27 Jul 2010 11:55:45 -0500 Message-ID: From: Peter Bigot To: Guido Moritz Content-Type: multipart/alternative; boundary=0016e65875326448fe048c615fc3 Cc: core Subject: Re: [core] proposal: drop HTTP Resource Discovery 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, 27 Jul 2010 16:55:27 -0000 --0016e65875326448fe048c615fc3 Content-Type: text/plain; charset=ISO-8859-1 Section 6.4 specifically proposes that CoAP provide resource discovery for HTTP, not for CoAP. I believe this is out of scope. Does anybody disagree with that assessment? I fully support the need for both service-discovery and resource-discovery for CoAP nodes. My other email proposed removing the requirement that every CoAP node provide a resource discovery service that currently is not required to list any resources. After a telecon this morning I believe we have a resolution to the problems I have with that service as described, and that it will be straightforward to provide both (basic) service and (complete) resource discovery within CoAP. However, I still feel it is asking too much that every constrained device be required to support the service as described in section 6. I will follow up later today with some details on a workable solution. After that, if you believe it should be a requirement on every node that it directly support a resource discovery service, please reply on that thread. Peter On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz wrote: > >I think in an M2M setting, resource discovery is a MUST. > > Jep, discovery is a main mechanism/functionality of most (all I get into my > mind within 10 seconds) M2M protocols and even some H2M. > > > > Guido > > > > > > *Von:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *Im Auftrag > von *Don Sturek > *Gesendet:* Dienstag, 27. Juli 2010 15:48 > *An:* 'Peter Bigot'; 'core' > *Betreff:* Re: [core] proposal: drop HTTP Resource Discovery > > > > HI Peter, > > If we drop Section 6.4, then I think CoAP will not really gain traction > unless the intent is to align behind an existing resource discovery solution > like DNS-SD which can work for both HTTP and CoAP. > > > > I think in an M2M setting, resource discovery is a MUST. > > > Don > > > > > > *From:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf Of > *Peter Bigot > *Sent:* Tuesday, July 27, 2010 6:44 AM > *To:* core > *Subject:* [core] proposal: drop HTTP Resource Discovery > > > > After my unfortunate encounter with the axle of multicast URI authorities, > I held back a long email related to similar issues. Here's one of the > > still-relevant pieces: > > I propose that section 6.4 be dropped completely. A protocol designed for > interaction with constrained devices should not be attempting to supply > HTTP with a resource discovery mechanism. > > Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --0016e65875326448fe048c615fc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Section 6.4 specifically proposes that CoAP provide resource discovery for = HTTP, not for CoAP.=A0 I believe this is out of scope.=A0 Does anybody disa= gree with that assessment?

I fully support the need for both service= -discovery and resource-discovery for CoAP nodes.

My other email proposed removing the requirement that every CoAP node p= rovide a resource discovery service that currently is not required to list = any resources.=A0 After a telecon this morning I believe we have a resoluti= on to the problems I have with that service as described, and that it will = be straightforward to provide both (basic) service and (complete) resource = discovery within CoAP.=A0 However, I still feel it is asking too much that = every constrained device be required to support the service as described in= section 6.

I will follow up later today with some details on a workable solution.= =A0 After that, if you believe it should be a requirement on every node tha= t it directly support a resource discovery service, please reply on that th= read.

Peter

On Tue, Jul 27, 2010 at 9:36 AM= , Guido Moritz <guido.moritz@uni-rostock.de> wrote= :

>I think in an M2M setting, resource discovery is a= MUST.

Jep, discovery is a main mechanism/functionality= of most (all I get into my mind within 10 seconds) M2M protocols and even some H2M.=

=A0

Guido

=A0

=A0

Von:<= span style=3D"font-size: 10pt;"> core-bounces@iet= f.org [mailto:core-bounces@ietf.org] Im Auftrag von Don Sturek
Gesendet: Dienstag, 27. Juli 2010 15:48
An: 'Peter Bigot'; 'core'
Betreff: Re: [core] proposal: drop HTTP Resource Discovery

=A0

HI Peter,

If we drop Section 6.4, then I think CoAP will not rea= lly gain traction unless the intent is to align behind an existing resource discover= y solution like DNS-SD which can work for both HTTP and CoAP.

=A0

I think in an M2M setting, resource discovery is a MUS= T.


Don

=A0

=A0

F= rom: core-bounces@ietf.org [mailto:core-bou= nces@ietf.org] On Behalf Of Peter Bigot
Sent: Tuesday, July 27, 2010 6:44 AM
To: core
Subject: [core] proposal: drop HTTP Resource Discovery

=A0

After my unfortunate encounter with the axle of multicast URI authorities, I held ba= ck a long email related to similar issues.=A0 Here's one of the


still-relevant pieces:

I propose that section 6.4 be dropped completely.=A0 A protocol designed fo= r interaction with constrained devices should not be attempting to supply=A0 HTTP with a resource discovery mechanism.

Peter


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


--0016e65875326448fe048c615fc3-- From pab@peoplepowerco.com Tue Jul 27 19:53:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77773A69A0 for ; Tue, 27 Jul 2010 19:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C73ZPOLco3IJ for ; Tue, 27 Jul 2010 19:53:49 -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 0EAB93A699F for ; Tue, 27 Jul 2010 19:53:48 -0700 (PDT) Received: by vws10 with SMTP id 10so4302226vws.31 for ; Tue, 27 Jul 2010 19:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.201 with SMTP id y9mr5527482vch.80.1280285650697; Tue, 27 Jul 2010 19:54:10 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Tue, 27 Jul 2010 19:54:10 -0700 (PDT) In-Reply-To: References: <-3084466236067637910@unknownmsgid> Date: Tue, 27 Jul 2010 21:54:10 -0500 Message-ID: From: Peter Bigot To: Guido Moritz Content-Type: multipart/alternative; boundary=e0cb4e887e916bc41c048c69bb0f Cc: core Subject: Re: [core] proposal: drop HTTP Resource Discovery 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, 28 Jul 2010 02:53:50 -0000 --e0cb4e887e916bc41c048c69bb0f Content-Type: text/plain; charset=ISO-8859-1 My starting point: I want to avoid use of multicast addresses in REST messages, for reasons I've explained before. (If you believe it's unnecessary to avoid this, please respond to point 2 in my email titled "REST, URIs, and constrained devices".) Here's how we can do service and resource discovery without requiring multicast in REST. Instead we use multicast in the transaction layer of CoAP, without a REST message. Thanks to Zack on this morning's telecon for the clue that makes this possible. Service discovery is the act of finding the address and port of nodes that provide CoAP control of resources. In the current draft, the term "end-point" refers to the service that is discovered. Service discovery can be accomplished by sending a CoAP CON message with zero-valued code and no options to the link all-hosts multicast address on the IANA_TBD_PORT. Such a message does not incorporate a REST transaction. Nodes that participate in service discovery are obliged to listen on the all-hosts multicast address and the IANA_TBD_PORT, even if this is not their normal end-point. They respond to CoAP messages with a zero-valued code with either an ACK or a RST depending on whether the WG decides whether such a message has any meaning. The discoverable node must transmit this ACK or RST using the unicast source address and port of the end-point on which it listens. The original node receives unicast responses from all CoAP end-points on the local link. It can subsequently send a CON message to GET the "/.well-known/r" from each node using the end-point address and port provided by the response. Code to support service and resource discovery in this manner, and an example script that identifies the end-points on the local link and retrieves their resource directories, even when the end-points are not running on the default port, has been added to coapy. The example is ugly, but it does prove this approach works. Pull from the git repository. Peter On Tue, Jul 27, 2010 at 11:55 AM, Peter Bigot wrote: > Section 6.4 specifically proposes that CoAP provide resource discovery for > HTTP, not for CoAP. I believe this is out of scope. Does anybody disagree > with that assessment? > > I fully support the need for both service-discovery and resource-discovery > for CoAP nodes. > > My other email proposed removing the requirement that every CoAP node > provide a resource discovery service that currently is not required to list > any resources. After a telecon this morning I believe we have a resolution > to the problems I have with that service as described, and that it will be > straightforward to provide both (basic) service and (complete) resource > discovery within CoAP. However, I still feel it is asking too much that > every constrained device be required to support the service as described in > section 6. > > I will follow up later today with some details on a workable solution. > After that, if you believe it should be a requirement on every node that it > directly support a resource discovery service, please reply on that thread. > > Peter > > On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz > wrote: > >> >I think in an M2M setting, resource discovery is a MUST. >> >> Jep, discovery is a main mechanism/functionality of most (all I get into >> my mind within 10 seconds) M2M protocols and even some H2M. >> >> >> >> Guido >> >> >> >> >> >> *Von:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *Im Auftrag >> von *Don Sturek >> *Gesendet:* Dienstag, 27. Juli 2010 15:48 >> *An:* 'Peter Bigot'; 'core' >> *Betreff:* Re: [core] proposal: drop HTTP Resource Discovery >> >> >> >> HI Peter, >> >> If we drop Section 6.4, then I think CoAP will not really gain traction >> unless the intent is to align behind an existing resource discovery solution >> like DNS-SD which can work for both HTTP and CoAP. >> >> >> >> I think in an M2M setting, resource discovery is a MUST. >> >> >> Don >> >> >> >> >> >> *From:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf >> Of *Peter Bigot >> *Sent:* Tuesday, July 27, 2010 6:44 AM >> *To:* core >> *Subject:* [core] proposal: drop HTTP Resource Discovery >> >> >> >> After my unfortunate encounter with the axle of multicast URI authorities, >> I held back a long email related to similar issues. Here's one of the >> >> still-relevant pieces: >> >> I propose that section 6.4 be dropped completely. A protocol designed for >> interaction with constrained devices should not be attempting to supply >> HTTP with a resource discovery mechanism. >> >> Peter >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > --e0cb4e887e916bc41c048c69bb0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My starting point: I want to avoid use of multicast addresses in REST messa= ges, for reasons I've explained before.=A0 (If you believe it's unn= ecessary to avoid this, please respond to point 2 in my email titled "= REST, URIs, and constrained devices".)

Here's how we can do service and resource discovery without requiri= ng multicast in REST.=A0 Instead we use multicast in the transaction layer = of CoAP, without a REST message.=A0 Thanks to Zack on this morning's te= lecon for the clue that makes this possible.

Service discovery is the act of finding the address and port of nodes t= hat provide CoAP control of resources.=A0 In the current draft, the term &q= uot;end-point" refers to the service that is discovered.

Servic= e discovery can be accomplished by sending a CoAP CON message with zero-val= ued code and no options to the link all-hosts multicast address on the IANA= _TBD_PORT.=A0 Such a message does not incorporate a REST transaction.

Nodes that participate in service discovery are obliged to listen on th= e all-hosts multicast address and the IANA_TBD_PORT, even if this is not th= eir normal end-point.=A0 They respond to CoAP messages with a zero-valued c= ode with either an ACK or a RST depending on whether the WG decides whether= such a message has any meaning.=A0 The discoverable node must transmit thi= s ACK or RST using the unicast source address and port of the end-point on = which it listens.

The original node receives unicast responses from all CoAP end-points o= n the local link.=A0 It can subsequently send a CON message to GET the &quo= t;/.well-known/r" from each node using the end-point address and port = provided by the response.

Code to support service and resource discovery in this manner, and an e= xample script that identifies the end-points on the local link and retrieve= s their resource directories, even when the end-points are not running on t= he default port, has been added to coapy.=A0 The example is ugly, but it do= es prove this approach works.=A0 Pull from the git repository.

Peter

On Tue, Jul 27, 2010 at 11:55 A= M, Peter Bigot <pab@peoplepowerco.com> wrote:
Section 6.4 specifically proposes that CoAP provide resource discovery for = HTTP, not for CoAP.=A0 I believe this is out of scope.=A0 Does anybody disa= gree with that assessment?

I fully support the need for both service= -discovery and resource-discovery for CoAP nodes.

My other email proposed removing the requirement that every CoAP node p= rovide a resource discovery service that currently is not required to list = any resources.=A0 After a telecon this morning I believe we have a resoluti= on to the problems I have with that service as described, and that it will = be straightforward to provide both (basic) service and (complete) resource = discovery within CoAP.=A0 However, I still feel it is asking too much that = every constrained device be required to support the service as described in= section 6.

I will follow up later today with some details on a workable solution.= =A0 After that, if you believe it should be a requirement on every node tha= t it directly support a resource discovery service, please reply on that th= read.

Peter

On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz <guido.moritz@u= ni-rostock.de> wrote:
=

>I think in an M2M setting, resource discovery is a= MUST.

Jep, discovery is a main mechanism/functionality= of most (all I get into my mind within 10 seconds) M2M protocols and even some H2M.=

=A0

Guido

=A0

=A0

Von:<= span style=3D"font-size: 10pt;"> core-bounces@iet= f.org [mailto:core-bounces@ietf.org] Im Auftrag von Don Sturek
Gesendet: Dienstag, 27. Juli 2010 15:48
An: 'Peter Bigot'; 'core'
Betreff: Re: [core] proposal: drop HTTP Resource Discovery

=A0

HI Peter,

If we drop Section 6.4, then I think CoAP will not rea= lly gain traction unless the intent is to align behind an existing resource discover= y solution like DNS-SD which can work for both HTTP and CoAP.

=A0

I think in an M2M setting, resource discovery is a MUS= T.


Don

=A0

=A0

F= rom: core-bounces@ietf.org [mailto:core-bou= nces@ietf.org] On Behalf Of Peter Bigot
Sent: Tuesday, July 27, 2010 6:44 AM
To: core
Subject: [core] proposal: drop HTTP Resource Discovery

=A0

After my unfortunate encounter with the axle of multicast URI authorities, I held ba= ck a long email related to similar issues.=A0 Here's one of the


still-relevant pieces:

I propose that section 6.4 be dropped completely.=A0 A protocol designed fo= r interaction with constrained devices should not be attempting to supply=A0 HTTP with a resource discovery mechanism.

Peter


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



--e0cb4e887e916bc41c048c69bb0f-- From guido.moritz@uni-rostock.de Tue Jul 27 23:28:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D143A6898 for ; Tue, 27 Jul 2010 23:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JDy1XZAOkyd for ; Tue, 27 Jul 2010 23:28:36 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 151A33A683C for ; Tue, 27 Jul 2010 23:28:36 -0700 (PDT) Received: from email1.uni-rostock.de (139.30.8.208) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Jul 2010 08:28:58 +0200 Received: from Schlappi (130.129.116.163) by email1.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Jul 2010 08:28:56 +0200 From: Guido Moritz To: 'core' References: <-3084466236067637910@unknownmsgid> In-Reply-To: Date: Wed, 28 Jul 2010 08:29:00 +0200 Message-ID: <000601cb2e1e$2ae2bbf0$80a833d0$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CB2E2E.EE6B8BF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcstrJJ/6NF8cL4pTLOlRwykEjq95AAcUIJw Content-Language: de Subject: Re: [core] proposal: drop HTTP Resource Discovery 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, 28 Jul 2010 06:28:42 -0000 ------=_NextPart_000_0007_01CB2E2E.EE6B8BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just to clarify, you mean implementing Discovery on a CoAP node hast o be something different then a "MUST"? Agree, CoAP must define a mechanism but it might be optional. Guido Von: Peter Bigot [mailto:pab@peoplepowerco.com] Gesendet: Dienstag, 27. Juli 2010 18:56 An: Guido Moritz Cc: d.sturek@att.net; core Betreff: Re: [core] proposal: drop HTTP Resource Discovery Section 6.4 specifically proposes that CoAP provide resource discovery for HTTP, not for CoAP. I believe this is out of scope. Does anybody disagree with that assessment? I fully support the need for both service-discovery and resource-discovery for CoAP nodes. My other email proposed removing the requirement that every CoAP node provide a resource discovery service that currently is not required to list any resources. After a telecon this morning I believe we have a resolution to the problems I have with that service as described, and that it will be straightforward to provide both (basic) service and (complete) resource discovery within CoAP. However, I still feel it is asking too much that every constrained device be required to support the service as described in section 6. I will follow up later today with some details on a workable solution. After that, if you believe it should be a requirement on every node that it directly support a resource discovery service, please reply on that thread. Peter On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz wrote: >I think in an M2M setting, resource discovery is a MUST. Jep, discovery is a main mechanism/functionality of most (all I get into my mind within 10 seconds) M2M protocols and even some H2M. Guido Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Don Sturek Gesendet: Dienstag, 27. Juli 2010 15:48 An: 'Peter Bigot'; 'core' Betreff: Re: [core] proposal: drop HTTP Resource Discovery HI Peter, If we drop Section 6.4, then I think CoAP will not really gain traction unless the intent is to align behind an existing resource discovery solution like DNS-SD which can work for both HTTP and CoAP. I think in an M2M setting, resource discovery is a MUST. Don From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Peter Bigot Sent: Tuesday, July 27, 2010 6:44 AM To: core Subject: [core] proposal: drop HTTP Resource Discovery After my unfortunate encounter with the axle of multicast URI authorities, I held back a long email related to similar issues. Here's one of the still-relevant pieces: I propose that section 6.4 be dropped completely. A protocol designed for interaction with constrained devices should not be attempting to supply HTTP with a resource discovery mechanism. Peter _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0007_01CB2E2E.EE6B8BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just to clarify, you mean implementing Discovery on a = CoAP node hast o be something different then a “MUST”? Agree, CoAP must = define a mechanism but it might be optional.

 

Guido

 

Von:<= /b> Peter = Bigot [mailto:pab@peoplepowerco.com]
Gesendet: Dienstag, 27. Juli 2010 18:56
An: Guido Moritz
Cc: d.sturek@att.net; core
Betreff: Re: [core] proposal: drop HTTP Resource = Discovery

 

Section 6.4 = specifically proposes that CoAP provide resource discovery for HTTP, not for = CoAP.  I believe this is out of scope.  Does anybody disagree with that = assessment?

I fully support the need for both service-discovery and = resource-discovery for CoAP nodes.

My other email proposed removing the requirement that every CoAP node = provide a resource discovery service that currently is not required to list any resources.  After a telecon this morning I believe we have a = resolution to the problems I have with that service as described, and that it will be straightforward to provide both (basic) service and (complete) resource discovery within CoAP.  However, I still feel it is asking too much = that every constrained device be required to support the service as described = in section 6.

I will follow up later today with some details on a workable = solution.  After that, if you believe it should be a requirement on every node that = it directly support a resource discovery service, please reply on that = thread.

Peter

On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz = <guido.moritz@uni-rostock.de> wrote:

>I think in an = M2M setting, resource discovery is a MUST.

Jep, discovery is = a main mechanism/functionality of most (all I get into my mind within 10 = seconds) M2M protocols and even some H2M.

 

Guido

 

 

Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Don Sturek
Gesendet: Dienstag, 27. Juli 2010 15:48
An: 'Peter Bigot'; 'core'
Betreff: Re: [core] proposal: drop HTTP Resource = Discovery

 <= /o:p>

HI = Peter,

If we drop Section = 6.4, then I think CoAP will not really gain traction unless the intent is to align = behind an existing resource discovery solution like DNS-SD which can work for = both HTTP and CoAP.

 

I think in an M2M = setting, resource discovery is a MUST.


Don

 

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Peter Bigot
Sent: Tuesday, July 27, 2010 6:44 AM
To: core
Subject: [core] proposal: drop HTTP Resource = Discovery

 

After my unfortunate encounter with the axle of multicast = URI authorities, I held back a long email related to similar issues.  = Here's one of the


still-relevant pieces:

I propose that section 6.4 be dropped completely.  A protocol = designed for interaction with constrained devices should not be attempting to = supply  HTTP with a resource discovery mechanism.

Peter


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

 

------=_NextPart_000_0007_01CB2E2E.EE6B8BF0-- From fluffy@cisco.com Wed Jul 28 01:05: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 E42DE3A699C for ; Wed, 28 Jul 2010 01:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.461 X-Spam-Level: X-Spam-Status: No, score=-110.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdrzS7-RC1s3 for ; Wed, 28 Jul 2010 01:05:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E2E6F28C10A for ; Wed, 28 Jul 2010 01:05:36 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIIAFiBT0xAZnwN/2dsb2JhbAAen01xpGObD4U2BIhu X-IronPort-AV: E=Sophos;i="4.55,272,1278288000"; d="scan'208";a="140108643" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2010 08:05:59 +0000 Received: from dhcp-10-55-87-11.cisco.com (dhcp-10-55-87-11.cisco.com [10.55.87.11]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6S85wFf003867 for ; Wed, 28 Jul 2010 08:05:59 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Jul 2010 10:05:58 +0200 Message-Id: <5923AEDE-855E-4002-BAD2-EA41214CDA5D@cisco.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Draft on host meta 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, 28 Jul 2010 08:05:38 -0000 People interested in host meta should have a read of http://tools.ietf.org/html/draft-hammer-hostmeta From zach@sensinode.com Wed Jul 28 02:03: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 AB6D43A69B9 for ; Wed, 28 Jul 2010 02:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 1veG3DV28Rpm for ; Wed, 28 Jul 2010 02:03:12 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B70B33A687D for ; Wed, 28 Jul 2010 02:03:08 -0700 (PDT) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6S93RxU018068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Jul 2010 12:03:27 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 28 Jul 2010 11:03:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <695D52B2-D510-400D-B171-9AC64FD40868@sensinode.com> References: <-3084466236067637910@unknownmsgid> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] proposal: drop HTTP Resource Discovery 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, 28 Jul 2010 09:03:20 -0000 On Jul 27, 2010, at 6:55 PM, Peter Bigot wrote: > Section 6.4 specifically proposes that CoAP provide resource discovery = for HTTP, not for CoAP. I believe this is out of scope. Does anybody = disagree with that assessment? I brought that up in the CoAP presentation this morning and will open up = a ticket for that. Personally, I have no problem removing that = subsection. I understand that it may be confusing. > I fully support the need for both service-discovery and = resource-discovery for CoAP nodes. >=20 > My other email proposed removing the requirement that every CoAP node = provide a resource discovery service that currently is not required to = list any resources. After a telecon this morning I believe we have a = resolution to the problems I have with that service as described, and = that it will be straightforward to provide both (basic) service and = (complete) resource discovery within CoAP. However, I still feel it is = asking too much that every constrained device be required to support the = service as described in section 6. >=20 > I will follow up later today with some details on a workable solution. = After that, if you believe it should be a requirement on every node = that it directly support a resource discovery service, please reply on = that thread. Presented the basic ideas (a couple bullet points) in the presentation = this morning, thanks for working on the details!=20 Zach >=20 > Peter >=20 > On Tue, Jul 27, 2010 at 9:36 AM, Guido Moritz = wrote: > >I think in an M2M setting, resource discovery is a MUST. >=20 > Jep, discovery is a main mechanism/functionality of most (all I get = into my mind within 10 seconds) M2M protocols and even some H2M. >=20 > =20 > Guido >=20 > =20 > =20 > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von Don Sturek > Gesendet: Dienstag, 27. Juli 2010 15:48 > An: 'Peter Bigot'; 'core' > Betreff: Re: [core] proposal: drop HTTP Resource Discovery >=20 > =20 > HI Peter, >=20 > If we drop Section 6.4, then I think CoAP will not really gain = traction unless the intent is to align behind an existing resource = discovery solution like DNS-SD which can work for both HTTP and CoAP. >=20 > =20 > I think in an M2M setting, resource discovery is a MUST. >=20 >=20 > Don >=20 > =20 > =20 > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Peter Bigot > Sent: Tuesday, July 27, 2010 6:44 AM > To: core > Subject: [core] proposal: drop HTTP Resource Discovery >=20 > =20 > After my unfortunate encounter with the axle of multicast URI = authorities, I held back a long email related to similar issues. Here's = one of the >=20 >=20 > still-relevant pieces: >=20 > I propose that section 6.4 be dropped completely. A protocol designed = for interaction with constrained devices should not be attempting to = supply HTTP with a resource discovery mechanism. >=20 > Peter >=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 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From adam@nostrum.com Wed Jul 28 02:22: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 6FBAC3A6878 for ; Wed, 28 Jul 2010 02:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 p-RoMeMMF-7o for ; Wed, 28 Jul 2010 02:22:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 39C6928C0F2 for ; Wed, 28 Jul 2010 02:22:51 -0700 (PDT) Received: from dhcp-23f3.meeting.ietf.org (dhcp-23f3.meeting.ietf.org [130.129.35.243]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6S9NCI1076362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Jul 2010 04:23:13 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4FF700.9000609@nostrum.com> Date: Wed, 28 Jul 2010 11:23:12 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "CORE (Constrained RESTful Environments) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.35.243 is authenticated by a trusted mechanism) Subject: [core] Subscriptions and policy 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, 28 Jul 2010 09:22:53 -0000 At the meeting, I pointed out that some of the subscription models under discussion -- such as those that use multicast and those that use an intermediary for fan-out of requests -- preclude the use of any policy that returns different values to different users (based, e.g., on identity, address, etc). Carsten indicated that he believes that such an approach is inconsistent with REST in general. This isn't immediately obvious to me -- as long as the view of a resource is consistent from the perspective of any single user, it seems completely in line with what REST attempts to achieve. In terms of the potential uses for this kind of differentiation, I'll go for the hard but obvious one first: location. Imagine a mobile-data-enabled, gps-enabled tracking device that implements CORE for retrieving location information. It is quite sensible to imagine that it would want to vary the precision of the delivered location based on who is asking. More in the roundhouse of what people are thinking about for typical CORE usage: imagine a CORE-attached residential alarm system, with sensors on external windows and doors, and on a number of internal motion sensors. The information about individual sensors can be very sensitive, and something I probably want to put tight controls on when, for example, the alarm monitoring service asks. When I ask, though, I would want a complete picture about what is going on. Now, there's nothing in baseline CORE that prevents this behavior. I would hate to lose this ability by the selection of a model for subscriptions that does. /a From rgm@labs.htt-consult.com Wed Jul 28 02:26:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2C33A6A2A for ; Wed, 28 Jul 2010 02:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 Hj3xZ+hVbKfI for ; Wed, 28 Jul 2010 02:26:53 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 91BB83A6A26 for ; Wed, 28 Jul 2010 02:26:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9F94168B27 for ; Wed, 28 Jul 2010 09:18:06 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ3tI8fLD3d4 for ; Wed, 28 Jul 2010 05:17:57 -0400 (EDT) Received: from nc2400.htt-consult.com (dhcp-60fb.meeting.ietf.org [130.129.96.251]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 2324168A8E for ; Wed, 28 Jul 2010 05:17:56 -0400 (EDT) Message-ID: <4C4FF7E4.9010400@labs.htt-consult.com> Date: Wed, 28 Jul 2010 11:27:00 +0200 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: core Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Comments on Bootstrapping 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, 28 Jul 2010 09:26:54 -0000 I suspect we will NOT have time to comment on Bootstrapping, so I will put SOME comments here. I HAVE read draft-oflynn-core-bootstrapping-01; during the beginning of this session :) Organization: talk about MAC and IPv6 bootstapping, or IPv6 only. Perhaps a nod to OTHERS like USB. Security: Well I have opinions and contributions here. One thing is that Security is NOT state-free, unless you are willing to pay the price for Public Key operations on EVERY packet. But then there ARE other pieces of state below the application, like wireless Association, so perhaps this is 'understood'. I was asked in my 6lowpan presentation on HIP-DEX if it could work within TLS. I got 2 minutes of Rescorla's time this morning and confirmed a few things I figured out. A quick approach is via RFC 4279 with pre-shared keys for TLS, there are a few things to specify like how to know if there is HIP SA already in place and to get the Pair-wise SA information, and how to trigger a HIP rekey when needed, or learn that HIP WAS rekeyed under you. For 802.15.4 devices (and 802.11 and some others), there is a need to define an AES-CCM cipher for TLS, including the size of the MAC (and any AAD). The last part would be a HIP Parameter similar to ESP_TRANSFORM in RFC 5202; perhaps like TLS_TRANSFORM. There are other aspects of security within bootstrap that I can help frame. From pab@peoplepowerco.com Wed Jul 28 02:48:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D783A6A95 for ; Wed, 28 Jul 2010 02:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, WEIRD_PORT=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 TrR9uHWD-s9t for ; Wed, 28 Jul 2010 02:48:28 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id D98B63A6A56 for ; Wed, 28 Jul 2010 02:48:23 -0700 (PDT) Received: by qyk1 with SMTP id 1so3434334qyk.10 for ; Wed, 28 Jul 2010 02:48:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.37.145 with SMTP id x17mr8614821qad.178.1280310486328; Wed, 28 Jul 2010 02:48:06 -0700 (PDT) Received: by 10.220.181.8 with HTTP; Wed, 28 Jul 2010 02:48:06 -0700 (PDT) Date: Wed, 28 Jul 2010 04:48:06 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=0015175cb23cbd7317048c6f838f Subject: [core] coapy available for plugfest 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, 28 Jul 2010 09:48:32 -0000 --0015175cb23cbd7317048c6f838f Content-Type: text/plain; charset=ISO-8859-1 I've re-enabled the one on pabigot.net:61616. It'll only be up until the end of the test. I didn't get a chance to provide an alternative options implementation, and it doesn't sound like there's enough interest to warrant the effort. Peter --0015175cb23cbd7317048c6f838f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've re-enabled the one on pabigot= .net:61616.=A0 It'll only be up until the end of the test.=A0 I did= n't get a chance to provide an alternative options implementation, and = it doesn't sound like there's enough interest to warrant the effort= .

Peter
--0015175cb23cbd7317048c6f838f-- From paduffy@cisco.com Wed Jul 28 09:24:00 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 DFD383A68DD for ; Wed, 28 Jul 2010 09:24:00 -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 VnwRXBa+uHJy for ; Wed, 28 Jul 2010 09:24:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1C4BE3A6807 for ; Wed, 28 Jul 2010 09:24:00 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH72T0xAZnwN/2dsb2JhbACfbnGmYIIICwGZCoU2BIhx X-IronPort-AV: E=Sophos;i="4.55,275,1278288000"; d="scan'208";a="140313487" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2010 16:24:22 +0000 Received: from [161.44.65.103] ([161.44.65.103]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6SGOME2028073; Wed, 28 Jul 2010 16:24:22 GMT Message-ID: <4C5059B6.1070901@cisco.com> Date: Wed, 28 Jul 2010 12:24:22 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Robert Moskowitz References: <4C4FF7E4.9010400@labs.htt-consult.com> In-Reply-To: <4C4FF7E4.9010400@labs.htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core Subject: Re: [core] Comments on Bootstrapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 16:24:01 -0000 > > For 802.15.4 devices (and 802.11 and some others), there is a need to > define an AES-CCM cipher for TLS, including the size of the MAC (and > any AAD). FYI already in progress ... http://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-00 From rgm@labs.htt-consult.com Wed Jul 28 11:56:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03263A68AB for ; Wed, 28 Jul 2010 11:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 q2uLzqjH6yiT for ; Wed, 28 Jul 2010 11:56:48 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id B72EE3A683A for ; Wed, 28 Jul 2010 11:56:48 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 06E3B68B66; Wed, 28 Jul 2010 18:47:25 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMag57SogOKF; Wed, 28 Jul 2010 14:47:15 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [130.129.80.30]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 8A82568B21; Wed, 28 Jul 2010 14:47:14 -0400 (EDT) Message-ID: <4C507D53.4030901@labs.htt-consult.com> Date: Wed, 28 Jul 2010 20:56:19 +0200 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: paduffy@cisco.com References: <4C4FF7E4.9010400@labs.htt-consult.com> <4C5059B6.1070901@cisco.com> In-Reply-To: <4C5059B6.1070901@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core Subject: Re: [core] Comments on Bootstrapping 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, 28 Jul 2010 18:56:50 -0000 On 07/28/2010 06:24 PM, Paul Duffy wrote: > >> >> For 802.15.4 devices (and 802.11 and some others), there is a need to >> define an AES-CCM cipher for TLS, including the size of the MAC (and >> any AAD). > > FYI already in progress ... > http://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-00 Yes, I just found this out from the security ADs this evening. Come to the TLS meeting, the same time as ROLL, and put in words for support. Of course this is ccm, NOT ccm*. How much of an issue will that be? From pab@peoplepowerco.com Thu Jul 29 05:08: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 A7E7F3A69F7 for ; Thu, 29 Jul 2010 05:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c37UyGD1t9BS for ; Thu, 29 Jul 2010 05:08: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 E30E93A69F6 for ; Thu, 29 Jul 2010 05:08:42 -0700 (PDT) Received: by pvd12 with SMTP id 12so78360pvd.31 for ; Thu, 29 Jul 2010 05:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.155.12 with SMTP id h12mr1919327wfo.333.1280405346404; Thu, 29 Jul 2010 05:09:06 -0700 (PDT) Received: by 10.220.187.141 with HTTP; Thu, 29 Jul 2010 05:09:04 -0700 (PDT) Date: Thu, 29 Jul 2010 07:09:04 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=001636e9091bd74d1f048c85993f Subject: [core] missed (?) open issue 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, 29 Jul 2010 12:08:43 -0000 --001636e9091bd74d1f048c85993f Content-Type: text/plain; charset=ISO-8859-1 Since header options provide information relevant to the REST transaction, there should be a mechanism for user-defined (vice protocol-defined) header options. Like HTTP's extension-headers. I thought I once saw a comment from somebody else supporting this, but can't find it now, so if this is just me still hung up on options, ignore it. Peter --001636e9091bd74d1f048c85993f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since header options provide information relevant to the REST transaction, = there should be a mechanism for user-defined (vice protocol-defined) header= options.=A0 Like HTTP's extension-headers.

I thought I once saw= a comment from somebody else supporting this, but can't find it now, s= o if this is just me still hung up on options, ignore it.

Peter
--001636e9091bd74d1f048c85993f-- From zach@sensinode.com Thu Jul 29 05:34: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 BBDA628C1F0 for ; Thu, 29 Jul 2010 05:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 48HU1ytT20mE for ; Thu, 29 Jul 2010 05:34:07 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CF3BD28C1F9 for ; Thu, 29 Jul 2010 05:33:50 -0700 (PDT) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6TCY67f021097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Jul 2010 15:34:07 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Thu, 29 Jul 2010 14:34:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69427535-083D-4A74-A8DA-991C723D3C64@sensinode.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] missed (?) open issue 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, 29 Jul 2010 12:34:33 -0000 Hi Peter, We didn't miss this - it is on my list of issues to open a ticket on.=20 For the current delta header option design it makes most sense to create = a priori an elective "User Defined Option" in which one or more custom = fields can be placed in the value. I propose that we first explore this = approach (add it to -misc, try it out).=20 If a 2-byte header would be used then it would make more sense to = reserve a chunk of the type space for custom use. But we didn't hear = interest in changing the current design in the WG meeting.=20 Zach=20 On Jul 29, 2010, at 2:09 PM, Peter Bigot wrote: > Since header options provide information relevant to the REST = transaction, there should be a mechanism for user-defined (vice = protocol-defined) header options. Like HTTP's extension-headers. >=20 > I thought I once saw a comment from somebody else supporting this, but = can't find it now, so if this is just me still hung up on options, = ignore it. >=20 > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Thu Jul 29 05:40: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 CCC8A28C141 for ; Thu, 29 Jul 2010 05:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CLU6BICvjCz for ; Thu, 29 Jul 2010 05:40:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 5749828C1DF for ; Thu, 29 Jul 2010 05:40:24 -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 o6TCeXWv020281; Thu, 29 Jul 2010 14:40:33 +0200 (CEST) Received: from dhcp-97f9.meeting.ietf.org (dhcp-97f9.meeting.ietf.org [130.129.151.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 0381DD1EC; Thu, 29 Jul 2010 14:40:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <69427535-083D-4A74-A8DA-991C723D3C64@sensinode.com> Date: Thu, 29 Jul 2010 14:40:32 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6056080D-DB44-4105-A10F-5DAFDA7F3B6B@tzi.org> References: <69427535-083D-4A74-A8DA-991C723D3C64@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] missed (?) open issue 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, 29 Jul 2010 12:40:45 -0000 On Jul 29, 2010, at 14:34, Zach Shelby wrote: > add it to -misc Good point. Will do for -06. Gruesse, Carsten From adam@nostrum.com Thu Jul 29 07:05:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE9328C14A for ; Thu, 29 Jul 2010 07:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 Q9lE4-B1pvRc for ; Thu, 29 Jul 2010 07:05:20 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A10A03A6831 for ; Thu, 29 Jul 2010 07:05:19 -0700 (PDT) Received: from dhcp-23f3.meeting.ietf.org (dhcp-23f3.meeting.ietf.org [130.129.35.243]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6TE5eaY030310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jul 2010 09:05:41 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C518AB2.5040705@nostrum.com> Date: Thu, 29 Jul 2010 16:05:38 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Olaf Bergmann References: <4C4FF700.9000609@nostrum.com> <87eiemu0n3.fsf@aung.localdomain> In-Reply-To: <87eiemu0n3.fsf@aung.localdomain> Content-Type: multipart/alternative; boundary="------------080007050008010407090605" Received-SPF: pass (nostrum.com: 130.129.35.243 is authenticated by a trusted mechanism) Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Subscriptions and policy 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, 29 Jul 2010 14:05:21 -0000 This is a multi-part message in MIME format. --------------080007050008010407090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/29/10 10:56 AM, Olaf Bergmann wrote: > Adam, > > Adam Roach writes: > > [...differentiation of data that presented to a subscriber...] > >> More in the roundhouse of what people are thinking about for typical >> CORE usage: imagine a CORE-attached residential alarm system, with >> sensors on external windows and doors, and on a number of internal >> motion sensors. The information about individual sensors can be very >> sensitive, and something I probably want to put tight controls on >> when, for example, the alarm monitoring service asks. When I ask, >> though, I would want a complete picture about what is going on. >> >> Now, there's nothing in baseline CORE that prevents this behavior. I >> would hate to lose this ability by the selection of a model for >> subscriptions that does. > Apart from the question if this fits the REST model I'm pretty certain it does. REST clearly allows the ability to convey alternate representations of a resource state. Examples include tailoring response MIME types to match the expressed capability of the client, choosing different encodings (UTF-8 vs. ISO-8859-1), and returning a different language (English versus French) according to expressed user preferences. So, in general, I think allegations that altering the body based on characteristics of the requestor are in violation of the REST model need to be backed up with some description of the REST property being violated. This reference may help: . In short, the mandatory characteristics of a RESTful system are: 1. Client-Server Architecture 2. Stateless Transactions 3. Cacheability 4. Uniform Interfaces 5. Layered System If you persist in asserting that what I'm describing is not consistent with REST, please cite one of these five properties in your assertions. > I wonder if this > scenario is in line with the intended use for a protocol such as CoAP. > I do not think that it is reasonable to subscribe each single sensor > node but instead have a sort of home gateway that does this for you and > that you can query for your home's overall status from outside using > HTTP or subscribe to alarms, etc. with a presence protocol of your > choice. Wait -- if CoAP is meant only for the kind of use case you describe, why are we messing with IP addresses for enrollment? Wouldn't it be much easier to use physical addresses, such as MACs? For that matter, if this is intended only for HANs, why is the work being done here instead of some place like IEEE? Oh, wait. I know why. Because it's not meant for only this kind of use case. From the charter (elisions mine): "CoAP will be designed for use... between Devices and general nodes on the Internet...." > We should not attempt to design another presence protocol here. But as that's what draft-hartke-coap-observe-01 effectively proposes to do, I'd like to make sure it's done correctly. /a --------------080007050008010407090605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit  On 7/29/10 10:56 AM, Olaf Bergmann wrote: 
Adam,

Adam Roach <adam@nostrum.com> writes:

[...differentiation of data that presented to a subscriber...]


More in the roundhouse of what people are thinking about for typical
CORE usage: imagine a CORE-attached residential alarm system, with
sensors on external windows and doors, and on a number of internal
motion sensors. The information about individual sensors can be very
sensitive, and something I probably want to put tight controls on
when, for example, the alarm monitoring service asks. When I ask,
though, I would want a complete picture about what is going on.

Now, there's nothing in baseline CORE that prevents this behavior. I
would hate to lose this ability by the selection of a model for
subscriptions that does.

Apart from the question if this fits the REST model

I'm pretty certain it does. REST clearly allows the ability to convey alternate representations of a resource state. Examples include tailoring response MIME types to match the expressed capability of the client, choosing different encodings (UTF-8 vs. ISO-8859-1), and returning a different language (English versus French) according to expressed user preferences.

So, in general, I think allegations that altering the body based on characteristics of the requestor are in violation of the REST model need to be backed up with some description of the REST property being violated. This reference may help: <http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>. In short, the mandatory characteristics of a RESTful system are:

  1. Client-Server Architecture
  2. Stateless Transactions
  3. Cacheability
  4. Uniform Interfaces
  5. Layered System

If you persist in asserting that what I'm describing is not consistent with REST, please cite one of these five properties in your assertions.


I wonder if this
scenario is in line with the intended use for a protocol such as CoAP.
I do not think that it is reasonable to subscribe each single sensor
node but instead have a sort of home gateway that does this for you and
that you can query for your home's overall status from outside using
HTTP or subscribe to alarms, etc. with a presence protocol of your
choice.

Wait -- if CoAP is meant only for the kind of use case you describe, why are we messing with IP addresses for enrollment? Wouldn't it be much easier to use physical addresses, such as MACs? For that matter, if this is intended only for HANs, why is the work being done here instead of some place like IEEE?

Oh, wait. I know why. Because it's not meant for only this kind of use case. From the charter (elisions mine):

"CoAP will be designed for use... between Devices and general nodes on the Internet...."

We should not attempt to design another presence protocol here.

But as that's what draft-hartke-coap-observe-01 effectively proposes to do, I'd like to make sure it's done correctly.

/a
--------------080007050008010407090605-- From cabo@tzi.org Thu Jul 29 08:06: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 4842A3A6A0D for ; Thu, 29 Jul 2010 08:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+W1Vo2rGU2R for ; Thu, 29 Jul 2010 08:06:48 -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 719513A69E8 for ; Thu, 29 Jul 2010 08:06:47 -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 o6TCcj1e019129; Thu, 29 Jul 2010 14:38:45 +0200 (CEST) Received: from dhcp-97f9.meeting.ietf.org (dhcp-97f9.meeting.ietf.org [130.129.151.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 65DA3D1E9; Thu, 29 Jul 2010 14:38:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 29 Jul 2010 14:38:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38E68EF4-32EA-44A2-9152-DAEF4600D4D6@tzi.org> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] missed (?) open issue 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, 29 Jul 2010 15:06:51 -0000 On Jul 29, 2010, at 14:09, Peter Bigot wrote: > Since header options provide information relevant to the REST = transaction, there should be a mechanism for user-defined (vice = protocol-defined) header options. Like HTTP's extension-headers. >=20 > I thought I once saw a comment from somebody else supporting this, Yes, me: http://www.ietf.org/mail-archive/web/core/current/msg00592.html Out of the choices I proposed there, I'd prefer the repeatable option = 14. The initial bytes of the option value would distinguish different kinds = of private options. (If it *has* to be globally unique, get an enterprise number and send = the SDNV of that as a start: (14) = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ | delta | length|1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| private opt-id| = value... | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ SDNV of enterprise number But, of course, that doesn't have to be.) Of course, you can stuff a lot of what you would consider "options" into = that value, so you don't have to make use of a repeatable option if all = user-defined options are from one org. Gruesse, Carsten From bergmann@tzi.org Thu Jul 29 08:06: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 F418E3A6A0F for ; Thu, 29 Jul 2010 08:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.183 X-Spam-Level: X-Spam-Status: No, score=-1.183 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] 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 NPR0pPTa2DdT for ; Thu, 29 Jul 2010 08:06:51 -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 7CB053A6A00 for ; Thu, 29 Jul 2010 08:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from aung.localdomain.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6T8uW4d009962; Thu, 29 Jul 2010 10:56:38 +0200 (CEST) From: Olaf Bergmann To: Adam Roach References: <4C4FF700.9000609@nostrum.com> Date: Thu, 29 Jul 2010 10:56:32 +0200 In-Reply-To: <4C4FF700.9000609@nostrum.com> (Adam Roach's message of "Wed, 28 Jul 2010 11:23:12 +0200") Message-ID: <87eiemu0n3.fsf@aung.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "CORE \(Constrained RESTful Environments\) WG" Subject: Re: [core] Subscriptions and policy 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, 29 Jul 2010 15:06:52 -0000 Adam, Adam Roach writes: [...differentiation of data that presented to a subscriber...] > More in the roundhouse of what people are thinking about for typical > CORE usage: imagine a CORE-attached residential alarm system, with > sensors on external windows and doors, and on a number of internal > motion sensors. The information about individual sensors can be very > sensitive, and something I probably want to put tight controls on > when, for example, the alarm monitoring service asks. When I ask, > though, I would want a complete picture about what is going on. > > Now, there's nothing in baseline CORE that prevents this behavior. I > would hate to lose this ability by the selection of a model for > subscriptions that does. Apart from the question if this fits the REST model, I wonder if this scenario is in line with the intended use for a protocol such as CoAP. I do not think that it is reasonable to subscribe each single sensor node but instead have a sort of home gateway that does this for you and that you can query for your home's overall status from outside using HTTP or subscribe to alarms, etc. with a presence protocol of your choice. We should not attempt to design another presence protocol here. Gruesse, Olaf From bergmann@tzi.org Fri Jul 30 05:55: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 9503B3A69AA for ; Fri, 30 Jul 2010 05:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611] 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 XX95vZqVu9Zz for ; Fri, 30 Jul 2010 05:55:39 -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 333303A67E3 for ; Fri, 30 Jul 2010 05:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from aung.localdomain.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6UCtl6f015397; Fri, 30 Jul 2010 14:55:53 +0200 (CEST) From: Olaf Bergmann To: core@ietf.org Date: Fri, 30 Jul 2010 14:55:46 +0200 Message-ID: <87r5il163x.fsf@aung.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: brian@skyfoundry.com Subject: [core] POST vs PUT in I-D coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:55:40 -0000 Hi, During the plugfest on Wednesday, I found that the text on the methods POST and PUT in sections 2.3.2 and 2.3.3 is somewhat ambiguous (at least to me). I read this as POST is the method to create new resources that are identified by the given request URI while PUT is used specifically for modifying existing resources (as the creation of new resources is a MAY in section 2.3.3). I suppose the intention of POST and PUT is the very same as in sections 9.5 and 9.6 of RFC 2616? Thanks, Olaf From cabo@tzi.org Fri Jul 30 06:18:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9203A69BF for ; Fri, 30 Jul 2010 06:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNbiRW34keTk for ; Fri, 30 Jul 2010 06:18:08 -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 F2FC83A69CD for ; Fri, 30 Jul 2010 06:18:07 -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 o6UDIPj9024326; Fri, 30 Jul 2010 15:18:25 +0200 (CEST) Received: from dhcp-97f9.meeting.ietf.org (dhcp-97f9.meeting.ietf.org [130.129.151.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 7D1D7D76A; Fri, 30 Jul 2010 15:18:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <87r5il163x.fsf@aung.localdomain> Date: Fri, 30 Jul 2010 15:18:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0409EB55-1670-4442-8AA6-9D51AC544263@tzi.org> References: <87r5il163x.fsf@aung.localdomain> To: Olaf Bergmann X-Mailer: Apple Mail (2.1081) Cc: brian@skyfoundry.com, core@ietf.org Subject: Re: [core] POST vs PUT in I-D coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 13:18:11 -0000 On Jul 30, 2010, at 14:55, Olaf Bergmann wrote: > I suppose the intention of POST and PUT is the very same as in = sections > 9.5 and 9.6 of RFC 2616? It is my (personal) impression that we want to be compatible with that = intention, except that we might want to listen to any insights that come = out of the HTTPBIS process. However, we should look at the places where HTTP is *not* well-defined = and consider if we can make a more specific (and thus simpler to = implement) decision here. We do *not* have to support the full = generality of HTTP here. To me, the distinction between PUT and POST is this: 1) PUT can "update" an existing resource known by URI. 2) PUT can "create" a new resource where the client gets to choose the = URI. (To make this operation idempotent, 2 and 1 are the same operation = PUT.) 3) POST can "create" a new resource where the server gets to choose the = URI, based on the URI given by the client that identifies the resource = that is performing this creation. 4) POST can also be used to do random undefined RESTful and RESTless = stuff. I think 1 and 2 are pretty much well-understood. The questions in my mind are: a) how much do we need to support 4? =20 We need reasonable usecases for the cases we do want to support to = make sure we have made the right decisions. b) how to best support 3, given that this operation is not idempotent? E.g., One aspect that came up in the meeting was the support of the = block protocol in POST. c) in case 3, how is the chosen URI communicated? (Assume: option like = HTTP: Location:) Gruesse, Carsten From robby.simpson@ge.com Fri Jul 30 09:09:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3733A688A for ; Fri, 30 Jul 2010 09:09:21 -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 QeI70BF94w+i for ; Fri, 30 Jul 2010 09:09:20 -0700 (PDT) Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by core3.amsl.com (Postfix) with ESMTP id 31DC63A687F for ; Fri, 30 Jul 2010 09:09:20 -0700 (PDT) Received: from source ([12.43.191.1]) (using TLSv1) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKTFL5SAV9zhCNVBW4vESf+9FQZZWrenqV@postini.com; Fri, 30 Jul 2010 09:09:45 PDT Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by Alpmlip04.e2k.ad.ge.com with ESMTP; 30 Jul 2010 12:09:43 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.50]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 12:09:33 -0400 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: Fri, 30 Jul 2010 12:09:03 -0400 Message-ID: In-Reply-To: <87r5il163x.fsf@aung.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] POST vs PUT in I-D coap-01 Thread-Index: Acsv5pTAHkF6PkkSQRuJlezxjCx8SAAGvG+i From: "Simpson, Robby (GE Energy Services)" To: , X-OriginalArrivalTime: 30 Jul 2010 16:09:33.0743 (UTC) FILETIME=[996E3BF0:01CB3001] Cc: brian@skyfoundry.com Subject: Re: [core] POST vs PUT in I-D coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 16:09:21 -0000 I would strongly recommend using the same semantics as 2616, but only = the bits applicable to a RESTful interface (for instance, I think we = could leave out the POST functionality for forms).=20 In short, PUT for modifying a resource or creating at a specific URI and = POST for creating a subordinate resource for a given URI or adding to a = "list" at a given URI.=20 - Robby ------------ Sent from my BlackBerry - thus the tpyos and brvty ----- Original Message ----- From: core-bounces@ietf.org To: core@ietf.org Cc: brian@skyfoundry.com Sent: Fri Jul 30 08:55:46 2010 Subject: [core] POST vs PUT in I-D coap-01 Hi, During the plugfest on Wednesday, I found that the text on the methods POST and PUT in sections 2.3.2 and 2.3.3 is somewhat ambiguous (at least to me). I read this as POST is the method to create new resources that are identified by the given request URI while PUT is used specifically for modifying existing resources (as the creation of new resources is a MAY in section 2.3.3). I suppose the intention of POST and PUT is the very same as in sections 9.5 and 9.6 of RFC 2616? Thanks, Olaf _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core