From sarikaya2012@gmail.com Wed Aug 1 18:16:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6D911E812E for ; Wed, 1 Aug 2012 18:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSCPRV4xBZGW for ; Wed, 1 Aug 2012 18:16:29 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C429D11E811D for ; Wed, 1 Aug 2012 18:16:29 -0700 (PDT) Received: by yenq13 with SMTP id q13so8679058yen.31 for ; Wed, 01 Aug 2012 18:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=PqiY/LORJhLIxBZw8Gd6ozpZNg1WY24eMpQgntVASso=; b=g4h2wj9LwDRCwceVeoC7qzMbltncp/zX3Zx+QoXb3X0TXkEwqgDNHBY0EkyX9Xg5ez 43TQMEAo0H0vuv1NAYPYzMpdgpoPJ8LQu0GWqOtOLpOWVc4LqcgIEFJmV3Jz8hmNu3rc g72TkCn211oIZSRf56pWQ9rGAEfrxRaYgcYbmn4tnkgpYDY9mH0dSg3FreOOoIcVUV6+ h/l6kdR3IY6QiRGL9ElG3VCUARNovED5e2IPegY0JeQzK4yHy3FjfDFlrANQ2648Q+PI joBJ5prGurbvuBXoPfYvSHY/gupWWh4ioUWiuyVERKAntbfScmtXP+E45bVO0bnGzugK C4aQ== MIME-Version: 1.0 Received: by 10.50.170.3 with SMTP id ai3mr251853igc.9.1343870189122; Wed, 01 Aug 2012 18:16:29 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Wed, 1 Aug 2012 18:16:28 -0700 (PDT) Date: Wed, 1 Aug 2012 20:16:28 -0500 Message-ID: From: Behcet Sarikaya To: core WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Light switch authentication issue X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:16:30 -0000 Dear all, Today in the session someone asked about why a light switch needs to be authenticated after my presentation of draft-sarikaya-core-sbootstrapping-05. I would like ask if the light switch would have an IP stack? If not of course no issue. Then CoAP would also be not applicable. So it is fair to assume an IPv6 stack then the first step in getting into IP network is secure bootstrapping which involves authentication. This is what we address in the draft. I hope that the person who asked this question can clarify his point. Behcet From sarikaya2012@gmail.com Wed Aug 1 18:24:06 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F57911E8136 for ; Wed, 1 Aug 2012 18:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2THdNiJcZYm for ; Wed, 1 Aug 2012 18:24:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF5111E811D for ; Wed, 1 Aug 2012 18:24:05 -0700 (PDT) Received: by yenq13 with SMTP id q13so8686364yen.31 for ; Wed, 01 Aug 2012 18:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=RRDCvL1Hq/djtLDyMO/ivdCM4nGvaR1g/SRguN4okKY=; b=sQYXqakjz/uk9GDgk6f8lYUG9DoKFx5zNiN7cHS92+ZeOK0RwEG3q63CoaZaeaDgya n7EZrhorzDoeqHtIFLlwMRUHu5vI0u9gWWLi2Djv1zyyiNiIxC734Kk2C+tpuNBcqtYR gDMoElOIfGI52VD+UPmuVaNGafkBCEBvccjpSLIZ5RGT+RKMI9/QSQHyYAgJspYP6cSY gSD1NIXNqO63NyutMf3+twfHKlnyKbF9nbWzQ/wYAuMPL4+V3bl4pkXbHlheQz9+cDL/ UTEwfSL6UdR9O2wlO+0+IytNUGVTxOOorZGXB5JTiABc/aQBdcz7llS9kWuHmgkoVccp QoBQ== MIME-Version: 1.0 Received: by 10.42.76.147 with SMTP id e19mr1174210ick.17.1343870644898; Wed, 01 Aug 2012 18:24:04 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Wed, 1 Aug 2012 18:24:04 -0700 (PDT) Date: Wed, 1 Aug 2012 20:24:04 -0500 Message-ID: From: Behcet Sarikaya To: core WG , Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] DTLS Authentication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:24:06 -0000 Hi Zach, DTLS is not an authentication protocol. DTLS is used to secure UDP (or datagram) communication on top of which CoAP application is built. We explained the relationship of authentication with DTLS in Appendix C.1 2. Use of EAP for bootstrapping higher-layer security. I hope this clarifies and also suggests that you please read the draft which is going to help you understand the difference between secure bootstrapping and DTLS. Regards, Behcet From cabo@tzi.org Wed Aug 1 18:29:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A5111E815E for ; Wed, 1 Aug 2012 18:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.467 X-Spam-Level: X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjxhagFDYFbU for ; Wed, 1 Aug 2012 18:29:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3979811E8156 for ; Wed, 1 Aug 2012 18:29:34 -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 q721TNC9029559; Thu, 2 Aug 2012 03:29:23 +0200 (CEST) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C0AFBD2E; Thu, 2 Aug 2012 03:29:22 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 1 Aug 2012 18:29:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8DCA1483-E9C0-44E3-85BA-72B14F1F5270@tzi.org> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1485) Cc: core WG Subject: Re: [core] Light switch authentication issue X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:29:36 -0000 In Paris, we held a workshop that addressed some of the relevant issues. You can find papers and slides at: = http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/#h.th5igs8wmy= 9s E.g., position papers 21 or 27 may be a good source of ideas about = different kinds of bootstrapping. Here, generally the idea is to do bootstrapping even before secure = network access is established (because that requires bootstrapping -- = that is the reason for using this term...). There is also a nice overview of the issues in: http://tools.ietf.org/html/draft-garcia-core-security-04 (cf. also the workshop's position paper 6). These are only highlights, there's more. Gr=FC=DFe, Carsten From sarikaya2012@gmail.com Wed Aug 1 18:33:53 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5041911E815F for ; Wed, 1 Aug 2012 18:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ow-mJXK8cs9 for ; Wed, 1 Aug 2012 18:33:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8217111E8138 for ; Wed, 1 Aug 2012 18:33:52 -0700 (PDT) Received: by yenq13 with SMTP id q13so8695342yen.31 for ; Wed, 01 Aug 2012 18:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=S/YQo7Fi66YIrbHtaavY8fN48ySurMEwVBHdhaI4fCg=; b=xP7dgxmY3xyjj2RRq5/21f5mcuFBwmCzZP2bI+p3GAiwy6hAXonC5BhagMZwITt/Ty CzglwLCkzdircJ/MeC2jyXfOjrrDtY2mSTFFrHhEJ/GoTXoAl3eFVFCTcOKgAKaxOkso mxSOkTt1r/KbApyXyoUdjelJGfMBEFesRfh9CC3jxw5G9AIFfbiNj99lBL1ftZleVPB4 qeh3wlXfOCgD474czCo8S45COt4/hobZ93MZCzbCrTIrJX00Oo2wwp1xQwP9+8Y6zyLL UvqI8JHSaV7xFJWyl9Yrjh/Oa8Fez+W9OxlRKLHUx9cAMa55wVLKRT2haP4fphTANiDr i+ag== MIME-Version: 1.0 Received: by 10.42.18.130 with SMTP id x2mr1227578ica.5.1343871228025; Wed, 01 Aug 2012 18:33:48 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Wed, 1 Aug 2012 18:33:47 -0700 (PDT) In-Reply-To: <8DCA1483-E9C0-44E3-85BA-72B14F1F5270@tzi.org> References: <8DCA1483-E9C0-44E3-85BA-72B14F1F5270@tzi.org> Date: Wed, 1 Aug 2012 20:33:47 -0500 Message-ID: From: Behcet Sarikaya To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core WG Subject: Re: [core] Light switch authentication issue X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:33:53 -0000 On Wed, Aug 1, 2012 at 8:29 PM, Carsten Bormann wrote: > In Paris, we held a workshop that addressed some of the relevant issues. > You can find papers and slides at: > > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/#h.th5igs8wm= y9s > > E.g., position papers 21 or 27 may be a good source of ideas about differ= ent kinds of bootstrapping. > > Here, generally the idea is to do bootstrapping even before secure networ= k access is established (because that requires bootstrapping -- that is the= reason for using this term...). > > There is also a nice overview of the issues in: > > http://tools.ietf.org/html/draft-garcia-core-security-04 > > (cf. also the workshop's position paper 6). > > These are only highlights, there's more. Yes, they are referenced in draft-sarikaya-core-sbootstrapping-05 :-) Gr=FC=DFe, Behcet > From ari.keranen@nomadiclab.com Wed Aug 1 19:07:10 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC911E8188; Wed, 1 Aug 2012 19:07:10 -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=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-hbhobpA4Kf; Wed, 1 Aug 2012 19:07:10 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7710611E811D; Wed, 1 Aug 2012 19:07:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B5FAE4E6EB; Thu, 2 Aug 2012 05:07:08 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83dswAjAUQ5G; Thu, 2 Aug 2012 05:07:07 +0300 (EEST) Received: from dhcp-4320.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 7122D4E6E4; Thu, 2 Aug 2012 05:07:06 +0300 (EEST) Message-ID: <5019E0C8.4050301@nomadiclab.com> Date: Wed, 01 Aug 2012 19:07:04 -0700 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Zhen Cao References: <20120709113756.5118.82222.idtracker@ietfa.amsl.com> <4FFAC3D8.8090407@piuha.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "lwip@ietf.org" , core , Anders Eriksson E Subject: Re: [core] draft-arkko-core-cellular X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 02:07:10 -0000 Hi, Thanks for the review and comments. On 7/29/12 12:12 AM, Zhen Cao wrote: [...] > I like the style of section 3, the analysis of the link layer > implications for energy-efficient application development. Some > questions and comments are listed separately as below. > - Public network. Is it just used as the adverse of “private network”? Yes, but especially a network that is not built just for the purpose of a particular application. > - Point to point link. As analyzed in the draft, this is a normal case > for cellular connection, no way and no need to consider third party > devices. As to achieve energy efficient is always contradictory of > handling multicast/broadcast packets, it is relatively easier to be > efficient with PPP link. Or shall we make such recommendations? Makes sense to mention this. > - Radio technology. Radio proved to be the most energy consuming part, > and L2 mechanisms are most efficient in the optimization space. I > turned to believe that there is no need to optimize the upper layers > before I encounter the idea of message coordination. That is to reduce > the frequency of trigger link up by coordinating the send/recv > behavior of different protocols. For example, 6LOWPAN-ND advertises > sometime and wake the radio, and then radio/MAC layer optimization > turns it off before COAP protocol triggers a groupcomm afterwards. If > these send/recv of different protocols can be coordinated, I guess the > situation will be much better. Yes, the message coordination and model can have a big impact on the energy consumption; we briefly discuss the topic in this draft, but there's more about it in draft-arkko-core-sleepy-sensors. Maybe some more cellular specific text could be added to this draft too. > Section 7 on the “Real-time reachable device”. For cellular devices, > there is one characterize to utilize: they are always reachable from > the circuit-switch side. Take the CoAP protocol as an example, if it > is difficult to reach the device (as a CoAP server, or to initiate the > observe mode) from the packet side, we can trigger it via a SMS > message and let it behave as a client. This is a rather special case > for cellular devices that developers can take advantage of. I heard > of some usage in this regards. With GSM, SMS can indeed be useful for triggering, but if you don't have CS side, the situation gets a bit different. > Again, I believe the description and analysis in this document is > useful for the cellular M2M devices. Guidelines for CoAP and other > IETF protocols can be derived from it. Thanks! Cheers, Ari > Best regards, > CZ > > On Mon, Jul 9, 2012 at 4:43 AM, Jari Arkko wrote: >> Hi, >> >> We have written a draft that talks about how to apply CoAP in smart objects >> attached to the Internet via the cellular networks. >> >> Comments appreciated. >> >> Jari >> >> On 09.07.2012 14:37, internet-drafts@ietf.org wrote: >>> >>> A new version of I-D, draft-arkko-core-cellular-00.txt >>> has been successfully submitted by Jari Arkko and posted to the >>> IETF repository. >>> >>> Filename: draft-arkko-core-cellular >>> Revision: 00 >>> Title: Building Power-Efficient CoAP Devices for Cellular >>> Networks >>> Creation date: 2012-07-09 >>> WG ID: Individual Submission >>> Number of pages: 17 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-arkko-core-cellular-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-arkko-core-cellular >>> Htmlized: http://tools.ietf.org/html/draft-arkko-core-cellular-00 >>> >>> >>> Abstract: >>> This memo discusses the use of the Constrained Application Protocol >>> (CoAP) protocol in building sensors and other devices that employ >>> cellular networks as a communications medium. Building communicating >>> devices that employ these networks is obviously well known, but this >>> memo focuses specifically on techniques necessary to minimize power >>> consumption. >>> >>> >>> >>> The IETF Secretariat >>> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From sye.loong.keoh@philips.com Thu Aug 2 09:38:04 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4246711E8107 for ; Thu, 2 Aug 2012 09:38:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlUkBhGBAeVq for ; Thu, 2 Aug 2012 09:38:03 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4D311E8104 for ; Thu, 2 Aug 2012 09:38:03 -0700 (PDT) Received: from mail43-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 16:38:01 +0000 Received: from mail43-am1 (localhost [127.0.0.1]) by mail43-am1-R.bigfish.com (Postfix) with ESMTP id E5A44602C3; Thu, 2 Aug 2012 16:38:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251Jc89bh542Mzz1202hzz1033IL8275dhz2dh2a8h668h839hd25hf0ah107ah) Received: from mail43-am1 (localhost.localdomain [127.0.0.1]) by mail43-am1 (MessageSwitch) id 1343925479766032_30554; Thu, 2 Aug 2012 16:37:59 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.246]) by mail43-am1.bigfish.com (Postfix) with ESMTP id AC4B240049; Thu, 2 Aug 2012 16:37:59 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 16:37:58 +0000 Received: from 011-DB3MMR1-014.MGDPHG.emi.philips.com (10.128.28.98) by 011-DB3MMR1-010.MGDPHG.emi.philips.com (10.128.28.49) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 2 Aug 2012 17:38:28 +0100 Received: from 011-DB3MPN1-031.MGDPHG.emi.philips.com ([169.254.1.189]) by 011-DB3MMR1-014.MGDPHG.emi.philips.com ([10.128.28.98]) with mapi id 14.02.0309.003; Thu, 2 Aug 2012 17:37:57 +0100 From: "Keoh, Sye Loong" To: core WG Thread-Topic: [core] Light switch authentication issue Thread-Index: AQHNcEx2qYLLNP8/OUuEXuxe6kWcaJdFqx0AgAELYKA= Date: Thu, 2 Aug 2012 16:37:57 +0000 Message-ID: References: <8DCA1483-E9C0-44E3-85BA-72B14F1F5270@tzi.org> In-Reply-To: <8DCA1483-E9C0-44E3-85BA-72B14F1F5270@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.23.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Light switch authentication issue X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:38:04 -0000 Dear all, My impression of the workshop in Paris was that there are various security = issues that need to be addressed. Bootstrapping is definitely one of them, = and it was concluded that it's a difficult problem to solve. Another highlights of the workshop was whether existing security mechanisms= such as DTLS, public-key cryptography can fit on Class 1 devices, and what= sort of optimization is needed. It was 'sort of concluded' that some of th= ese implementation issues discussed in the LWIG. However, what I am missing here still is that, now we have all these securi= ty issues related to smart objects, where is the right place to address/dis= cuss them if not in CoRE? Maybe in ROLL? Cheers Sye Loong -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: donderdag 2 augustus 2012 3:29 To: sarikaya@ieee.org Cc: core WG Subject: Re: [core] Light switch authentication issue In Paris, we held a workshop that addressed some of the relevant issues. You can find papers and slides at: http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/#h.th5igs8wmy9= s E.g., position papers 21 or 27 may be a good source of ideas about differen= t kinds of bootstrapping. Here, generally the idea is to do bootstrapping even before secure network = access is established (because that requires bootstrapping -- that is the r= eason for using this term...). There is also a nice overview of the issues in: http://tools.ietf.org/html/draft-garcia-core-security-04 (cf. also the workshop's position paper 6). These are only highlights, there's more. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Thu Aug 2 09:51:53 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9845011E8153 for ; Thu, 2 Aug 2012 09:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.43 X-Spam-Level: X-Spam-Status: No, score=-106.43 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6gtB+1yjwif for ; Thu, 2 Aug 2012 09:51:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 52B4B11E8104 for ; Thu, 2 Aug 2012 09:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q72GpZjb011792; Thu, 2 Aug 2012 18:51:36 +0200 (CEST) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D695D143; Thu, 2 Aug 2012 18:51:34 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 2 Aug 2012 09:51:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0467981B-13F7-4F47-86DB-5AA829BE3570@tzi.org> References: <8DCA1483-E9C0-44E3-85BA-72B14F1F5270@tzi.org> To: "Keoh, Sye Loong" X-Mailer: Apple Mail (2.1485) Cc: core WG Subject: Re: [core] Light switch authentication issue X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:51:53 -0000 Hi Sye, indeed, what *is* the right place! We will have a discussion of this at the end of Friday's ROLL meeting. ROLL is another group that really needs a security environment to base = their security on. The working groups in this space have spent about half of a decade = pointing at each other and either saying "you have to solve our problem" = or saying "you have to swallow what we think is the right solution to = your problem". Neither works, and we need an actual architecture to put the required = elements in. Sye, as a co-author of draft-garcia-core-security-04.txt (and I think = the only one present here), can you say a few words about Figure 1 in = the ROLL meeting? We won't have much time, but I think this figure is important as a = lead-in to that discussion. Gr=FC=DFe, Carsten On Aug 2, 2012, at 09:37, "Keoh, Sye Loong" = wrote: > Dear all, >=20 > My impression of the workshop in Paris was that there are various = security issues that need to be addressed. Bootstrapping is definitely = one of them, and it was concluded that it's a difficult problem to = solve. > Another highlights of the workshop was whether existing security = mechanisms such as DTLS, public-key cryptography can fit on Class 1 = devices, and what sort of optimization is needed. It was 'sort of = concluded' that some of these implementation issues discussed in the = LWIG. >=20 > However, what I am missing here still is that, now we have all these = security issues related to smart objects, where is the right place to = address/discuss them if not in CoRE? Maybe in ROLL? >=20 > Cheers > Sye Loong >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Carsten Bormann > Sent: donderdag 2 augustus 2012 3:29 > To: sarikaya@ieee.org > Cc: core WG > Subject: Re: [core] Light switch authentication issue >=20 > In Paris, we held a workshop that addressed some of the relevant = issues. > You can find papers and slides at: >=20 > = http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/#h.th5igs8wmy= 9s >=20 > E.g., position papers 21 or 27 may be a good source of ideas about = different kinds of bootstrapping. >=20 > Here, generally the idea is to do bootstrapping even before secure = network access is established (because that requires bootstrapping -- = that is the reason for using this term...). >=20 > There is also a nice overview of the issues in: >=20 > http://tools.ietf.org/html/draft-garcia-core-security-04 >=20 > (cf. also the workshop's position paper 6). >=20 > These are only highlights, there's more. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ________________________________ > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. From sye.loong.keoh@philips.com Thu Aug 2 09:59:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAFC21E80E0 for ; Thu, 2 Aug 2012 09:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaGFhv4ukhW6 for ; Thu, 2 Aug 2012 09:59:35 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id E84E921E80D2 for ; Thu, 2 Aug 2012 09:59:34 -0700 (PDT) Received: from mail59-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 16:59:34 +0000 Received: from mail59-co1 (localhost [127.0.0.1]) by mail59-co1-R.bigfish.com (Postfix) with ESMTP id 23FA18802D0; Thu, 2 Aug 2012 16:59:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -40 X-BigFish: VPS-40(zz217bL98dI15d6O9251Jc89bh542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah) Received: from mail59-co1 (localhost.localdomain [127.0.0.1]) by mail59-co1 (MessageSwitch) id 1343926772268839_22570; Thu, 2 Aug 2012 16:59:32 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.228]) by mail59-co1.bigfish.com (Postfix) with ESMTP id 3E8CA400055; Thu, 2 Aug 2012 16:59:32 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 16:59:31 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 2 Aug 2012 17:59:30 +0100 Received: from 011-DB3MPN1-031.MGDPHG.emi.philips.com ([169.254.1.189]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.02.0309.003; Thu, 2 Aug 2012 17:59:30 +0100 From: "Keoh, Sye Loong" To: Carsten Bormann Thread-Topic: [core] Light switch authentication issue Thread-Index: AQHNcEx2qYLLNP8/OUuEXuxe6kWcaJdFqx0AgAELYKD///ZLgIAAEmow Date: Thu, 2 Aug 2012 16:59:29 +0000 Message-ID: References: <8DCA1483-E9C0-44E3-85BA-72B14F1F5270@tzi.org> <0467981B-13F7-4F47-86DB-5AA829BE3570@tzi.org> In-Reply-To: <0467981B-13F7-4F47-86DB-5AA829BE3570@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.23.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core WG Subject: Re: [core] Light switch authentication issue X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:59:36 -0000 Hi Carsten, Yes, I would be happy to say a few words about the figure: "The lifecycle o= f a thing in the Internet of Things" to kick-start the discussion in ROLL s= ecurity. Cheers Sye Loong -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: donderdag 2 augustus 2012 18:52 To: Keoh, Sye Loong Cc: core WG; sarikaya@ieee.org Subject: Re: [core] Light switch authentication issue Hi Sye, indeed, what *is* the right place! We will have a discussion of this at the end of Friday's ROLL meeting. ROLL is another group that really needs a security environment to base thei= r security on. The working groups in this space have spent about half of a decade pointing= at each other and either saying "you have to solve our problem" or saying = "you have to swallow what we think is the right solution to your problem". Neither works, and we need an actual architecture to put the required eleme= nts in. Sye, as a co-author of draft-garcia-core-security-04.txt (and I think the o= nly one present here), can you say a few words about Figure 1 in the ROLL m= eeting? We won't have much time, but I think this figure is important as a lead-in = to that discussion. Gr=FC=DFe, Carsten On Aug 2, 2012, at 09:37, "Keoh, Sye Loong" wr= ote: > Dear all, >=20 > My impression of the workshop in Paris was that there are various securit= y issues that need to be addressed. Bootstrapping is definitely one of them= , and it was concluded that it's a difficult problem to solve. > Another highlights of the workshop was whether existing security mechanis= ms such as DTLS, public-key cryptography can fit on Class 1 devices, and wh= at sort of optimization is needed. It was 'sort of concluded' that some of = these implementation issues discussed in the LWIG. >=20 > However, what I am missing here still is that, now we have all these secu= rity issues related to smart objects, where is the right place to address/d= iscuss them if not in CoRE? Maybe in ROLL? >=20 > Cheers > Sye Loong >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of C= arsten Bormann > Sent: donderdag 2 augustus 2012 3:29 > To: sarikaya@ieee.org > Cc: core WG > Subject: Re: [core] Light switch authentication issue >=20 > In Paris, we held a workshop that addressed some of the relevant issues. > You can find papers and slides at: >=20 > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/#h.th5igs8wm= y9s >=20 > E.g., position papers 21 or 27 may be a good source of ideas about differ= ent kinds of bootstrapping. >=20 > Here, generally the idea is to do bootstrapping even before secure networ= k access is established (because that requires bootstrapping -- that is the= reason for using this term...). >=20 > There is also a nice overview of the issues in: >=20 > http://tools.ietf.org/html/draft-garcia-core-security-04 >=20 > (cf. also the workshop's position paper 6). >=20 > These are only highlights, there's more. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. From sarikaya2012@gmail.com Thu Aug 2 10:46:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E98511E81AD for ; Thu, 2 Aug 2012 10:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKCrsbVMtBcL for ; Thu, 2 Aug 2012 10:46:17 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC9FB11E81B0 for ; Thu, 2 Aug 2012 10:46:16 -0700 (PDT) Received: by ggnc4 with SMTP id c4so9733797ggn.31 for ; Thu, 02 Aug 2012 10:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=UP+XWq2meiL05lGqnL5rTHKetj5RHGwco1CLC7m1I3M=; b=oB7Ucb+mCEmwelduwaI1AAbXGC7uL1/lsSC/LeC3F/Pm+KWTh4vESfMwXXCsyrbZFk DhmFD9j/6nsQimGQXlKKGqzNEUNZVCEpXnZFgFw8+11BiBA9n0Cloa7C+vLWaQKhFsa+ uvxCUW2vDMWfO/GUS+u44RvEpeUvqJgQ7hqaG/x9xEcPvzgR2jOn5FMPW2QQ81mEawLP cMtALi96L053dZd5rdp+x1OSb81Gww/+mlraX6y4QPQkP3Zk0kz2zlK4rb63mJfF4HTR eEMk217lFFUDccSuQUwITcrTb12WpvO2q54rMvGtQAouMygrzYx0+azD+MJ5c0rtdxF3 y9mg== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr4998662igc.63.1343929576041; Thu, 02 Aug 2012 10:46:16 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Thu, 2 Aug 2012 10:46:15 -0700 (PDT) In-Reply-To: References: <8DCA1483-E9C0-44E3-85BA-72B14F1F5270@tzi.org> <0467981B-13F7-4F47-86DB-5AA829BE3570@tzi.org> Date: Thu, 2 Aug 2012 12:46:15 -0500 Message-ID: From: Behcet Sarikaya To: "Keoh, Sye Loong" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core WG Subject: Re: [core] Light switch authentication issue X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:46:18 -0000 Carsten, Sye, Well, we can discuss where to do this work, OK. But my presentation yesterday in Core has shown how illiterate people are in Core on this topic. I got the impression that most people are thinking that CoAP runs in some other world where nothing else (IPv6 stack, transport layer, etc.) is needed. People are so happy dealing with the details of CoAP features and completely forget what is going on underneath. IMHO this would be avoided if Core accepted our secure bootstrapping draft in November 2010 Beijing meeting. In that meeting we had a very informed set of attendees, they were interested on the subject and had given so many good feedback. Sigh :-). Behcet On Thu, Aug 2, 2012 at 11:59 AM, Keoh, Sye Loong wrote: > Hi Carsten, > > Yes, I would be happy to say a few words about the figure: "The lifecycle= of a thing in the Internet of Things" to kick-start the discussion in ROLL= security. > > Cheers > Sye Loong > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: donderdag 2 augustus 2012 18:52 > To: Keoh, Sye Loong > Cc: core WG; sarikaya@ieee.org > Subject: Re: [core] Light switch authentication issue > > Hi Sye, > > indeed, what *is* the right place! > We will have a discussion of this at the end of Friday's ROLL meeting. > ROLL is another group that really needs a security environment to base th= eir security on. > The working groups in this space have spent about half of a decade pointi= ng at each other and either saying "you have to solve our problem" or sayin= g "you have to swallow what we think is the right solution to your problem"= . > Neither works, and we need an actual architecture to put the required ele= ments in. > > Sye, as a co-author of draft-garcia-core-security-04.txt (and I think the= only one present here), can you say a few words about Figure 1 in the ROLL= meeting? > We won't have much time, but I think this figure is important as a lead-i= n to that discussion. > > Gr=FC=DFe, Carsten > > > On Aug 2, 2012, at 09:37, "Keoh, Sye Loong" = wrote: > >> Dear all, >> >> My impression of the workshop in Paris was that there are various securi= ty issues that need to be addressed. Bootstrapping is definitely one of the= m, and it was concluded that it's a difficult problem to solve. >> Another highlights of the workshop was whether existing security mechani= sms such as DTLS, public-key cryptography can fit on Class 1 devices, and w= hat sort of optimization is needed. It was 'sort of concluded' that some of= these implementation issues discussed in the LWIG. >> >> However, what I am missing here still is that, now we have all these sec= urity issues related to smart objects, where is the right place to address/= discuss them if not in CoRE? Maybe in ROLL? >> >> Cheers >> Sye Loong >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Carsten Bormann >> Sent: donderdag 2 augustus 2012 3:29 >> To: sarikaya@ieee.org >> Cc: core WG >> Subject: Re: [core] Light switch authentication issue >> >> In Paris, we held a workshop that addressed some of the relevant issues. >> You can find papers and slides at: >> >> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/#h.th5igs8w= my9s >> >> E.g., position papers 21 or 27 may be a good source of ideas about diffe= rent kinds of bootstrapping. >> >> Here, generally the idea is to do bootstrapping even before secure netwo= rk access is established (because that requires bootstrapping -- that is th= e reason for using this term...). >> >> There is also a nice overview of the issues in: >> >> http://tools.ietf.org/html/draft-garcia-core-security-04 >> >> (cf. also the workshop's position paper 6). >> >> These are only highlights, there's more. >> >> Gr=FC=DFe, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> ________________________________ >> The information contained in this message may be confidential and legall= y protected under applicable law. The message is intended solely for the ad= dressee(s). If you are not the intended recipient, you are hereby notified = that any use, forwarding, dissemination, or reproduction of this message is= strictly prohibited and may be unlawful. If you are not the intended recip= ient, please contact the sender by return e-mail and destroy all copies of = the original message. > > From sakane@tanu.org Fri Aug 3 10:55:39 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA16A21F8D3A for ; Fri, 3 Aug 2012 10:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0ZR1kGZfLHr for ; Fri, 3 Aug 2012 10:55:39 -0700 (PDT) Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by ietfa.amsl.com (Postfix) with ESMTP id 19C4321F8C9E for ; Fri, 3 Aug 2012 10:55:39 -0700 (PDT) Received: from mactanu.local (128-107-239-233.cisco.com [128.107.239.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id CD79016B16; Sat, 4 Aug 2012 02:55:40 +0900 (JST) Message-ID: <501C1095.2010200@tanu.org> Date: Sat, 04 Aug 2012 02:55:33 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Rahman, Akbar" , core@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] FW: New Version Notification for draft-ietf-core-groupcomm-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:55:40 -0000 I don't know whether there was same discussion before. If you allow DELETE method, you should allow POST method. why don't you allow to use POST method in the current draft ? Shoichi From fluffy@cisco.com Fri Aug 3 11:33:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5F311E8097 for ; Fri, 3 Aug 2012 11:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.371 X-Spam-Level: X-Spam-Status: No, score=-110.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvK9-q7mMU6f for ; Fri, 3 Aug 2012 11:33:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6552611E808D for ; Fri, 3 Aug 2012 11:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5533; q=dns/txt; s=iport; t=1344018812; x=1345228412; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=7EhnG8Ejj+d6/QNeDlkrdasmpuokE1k+lwJvhg7NQUA=; b=TcvlRgnwZHOTq6dC9AB1OkkGx2uniPqCO0Rz+rPWDsVdvyXbMsURv8pg cOsRiKsIZZhUZkwg2McyHXjs22HX5+jFuNtCwxBQrfIqy/3Y7lV/PgH0b wtG700tRdSE51DvkxW1FURxtps2QLHxgey3kWY4J+iUNClaRjd14GbCrI E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFoYHFCtJXG9/2dsb2JhbABFuS+BB4InEgEnNAsSAT5CJwQBDSAHh2ucc6Adi00PB4YJYAOVSo4ngWaCX4FWBw X-IronPort-AV: E=Sophos;i="4.77,707,1336348800"; d="scan'208";a="105288313" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 03 Aug 2012 18:33:31 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q73IXVb1006499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 18:33:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.237]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 13:33:30 -0500 From: "Cullen Jennings (fluffy)" To: core WG , "Cullen Jennings (fluffy)" Thread-Topic: Cullen Notes from CORE IETF84 meeting #2 Thread-Index: AQHNcaZ6uWAVq6Du6ECoUBUxaFKkMg== Date: Fri, 3 Aug 2012 18:33:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.114.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--34.153000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8AE1124158955240B97279BFF912B2C1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] Cullen Notes from CORE IETF84 meeting #2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:33:33 -0000 These are my random notes from the congestion portion of the meeting. They = were mostly meant for me but thought I would send them to the list.=20 minute takers for meeting are : Andrew McGregor & Dominique Barthel=20 David black: see RFC 5405=20 don't compare to TCP because not doing enough packets to cover this Sal: Key problem is lots of nodes sending little, not one node sending lots= =20 On the topic of collapse. For example earth quake and many sensory react at= same time.=20 David Black=20 Need to think about a RTT estimator. Look hard and see what you can do with= RTT. Problem is we are using fixed RTT.=20 Lars - obviously there are situation we will have congestion collapse. The = question is does it work in the operating region we want to be in. Drafts n= eed to say something about what region they can work in - like bandwidth an= d number of nodes.=20 Lars - if you can't do RTT, should not do more than 1 outstanding transacti= on.=20 David - packet size matter expect when it does not. We have resources that = congest on per packet, not on number of bytes.=20 Michael Scharf - need to separate out confirmable and non conferrable behav= ior.=20 Lars - pushed back on no room for minimal congestion state Ekr - for example, seem like we could have space for crude for RTT estimato= r=20 Jari - we can add a simple RTO implementation relatively easy. Need to deal= with what happen when sending to multiple locations. For example is one lo= cation is down, don't want to block sending to other locations.=20 David Black - bought up flash mob effect where all 3 milling sensors talk a= t same time Jari - not sure endpoint is right answer=20 David - we should do the solution that has the best "do no harm" type solut= ion. We might be able to serrate flash mob case vs normal reporting case.=20 on topic of delaying non confinable at 7B/s Michael - pushed on not having state to do this and argued=20 Black - if you don't want to RTT estimator, then stuck with 1 outstanding p= ackets.=20 On the topic of multicast reposes dithering stuff=20 Lars - is you use 2.5 seconds estimate to start, but you need a way to slow= this down. So restarted in at 2.5 scones again after a transaction had fai= led would not be ok Don't want to be in state pealing batteries out of device to get million se= nsors to stop the collapse.=20 -------------------------- On to what can we do. Lars - limited bandwidth, if few nodes can send lots, if lots of nodes very= hard=20 - can you overhear packets send by others? Can tell how busy the channel is= ? Is there link layer information ?=20 ??? 1) unlike wired network, don't want to assume every loss is due to congest= ion.=20 2) if we have 2 or more classes of devices, what mix of theses causes thing= s to fail. If all the automation systems in a building, and if you had a ma= ssive power outage, could be bad. Congestion nightmare.=20 David Black - possible the flash mob problem can be separated out and dealt= with much like multicast dithering. If you can be on network that is all s= oap traffic, self fair more important in theses case that TFRC.=20 Andrew - Go read Tim ? PHD Thesis. Very good on congestion on wireless mesh= .=20 Michael - important thing is congestion avoidance. And if we have congestio= n, we have to react.=20 Lars - can view this as an energy management problem. Don't want to do=20 Lars - What we do complete no state? very hard. But with very little state.= If we are talking 10 of bytes of total state and times, we can come up wit= h something reasonable.=20 Richard Calsen? - if you are running DTLS, just do RTT. Convinced RTT is ri= ght thing to do. Our ram and flash get used up by "just a little bit". Sort= of by the argument here but scared of =20 David black - on the confirmable. We get and RTT. And we get an ack locking= . We should think about expanding the dither. If we have way to extend diff= er, can help deal with accidental synchronization. Do something fairly simp= le and tightly constrained, and allow people to do more if they do more.=20 ??? - we are wireless nodes that fluctuate lots so saving state does not he= lp much. Lars - do your link layers deliver corrupted packets?=20 David Black - a course RTT estimator can help a lot. The difference of deal= ing with 1/2 second vs 5 second RTT is huge.=20 Andrew McGregor - any previous estimate tends to be better than just using = a default. Lars - for non confinable, very hard if they are bulk of the traffic=20 Andrew - require that certain small faction of non confirmable are conferra= ble - between 1 and 12 % of time ?=20 Zach - would be fine with requiring percentage of confirables. You are conc= erned that some of data is getting there.=20 Folks working on congestion plan: Carsten, Lars, David, Andrew, Bert, Mich= ael Do we have test beds or simulators ? ---------------------- Groupcom=20 Jorg - brought up issues you often can't tell if received packet came on mu= lticast or not.=20 Lars - Multicast issues. Responses have to fall under the other congestion = budget.=20 Zach - need to deal with not getting 404 back from half the group=20 ------------ AD - don't want work gin groups presentation of 30 drafts. Priortize on mai= ling list then perhaps talk about top few =20 From fluffy@iii.ca Fri Aug 3 11:39:16 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA51221E804A for ; Fri, 3 Aug 2012 11:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8dJ82EUrKRW for ; Fri, 3 Aug 2012 11:39:16 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 46F7221E8049 for ; Fri, 3 Aug 2012 11:39:16 -0700 (PDT) Received: from sjc-vpn2-740.cisco.com (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C66A2509B4 for ; Fri, 3 Aug 2012 14:39:09 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Aug 2012 11:39:06 -0700 Message-Id: <90054066-03DA-40B9-9B9B-79FC76E66CBF@iii.ca> To: core WG Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [core] ticket #227 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:39:16 -0000 perhaps could rephrase along the lines of=20 MUST keep transmitting until either got error (including time out), or = there is a new state change, or successfully delivered From fluffy@iii.ca Fri Aug 3 11:57:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D004921F8DAD for ; Fri, 3 Aug 2012 11:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qtZEZnFlr0A for ; Fri, 3 Aug 2012 11:57:56 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3021F8D57 for ; Fri, 3 Aug 2012 11:57:56 -0700 (PDT) Received: from sjc-vpn2-740.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E2E5F22E259 for ; Fri, 3 Aug 2012 14:57:49 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Aug 2012 11:57:47 -0700 Message-Id: <8455A202-71E5-43F5-92AD-37B79C409745@iii.ca> To: core WG Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [core] Comments on option numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:57:56 -0000 This with my individual contributor hat on=20 I think we should split up the space into roughly three categories. I = think they should be =20 1) Standards Track=20 - this is for very low numbers that very desirable and to make sure that = other stuff does not use up all the super prime realestate that future = revisions of the key RFC may need. This should be very small.=20 2) IETF Review=20 This is pretty easy and lots of stuff would fall in here. Note that many = IETF standards Track RFC might choose to use a code point out of this = space if they do not need the optimization of space 1.=20 3) Expert Review with Specification Required=20 This is "almost" first come first serve. But I think we want to try and = avoid completely duplicated of code points that mean that do the same = thing. We also need to check that things like the interactions with = proxies was correctly considered. To do this, the lightest weight thing = we can do is have expert review. And the expert needs to have something = to review. This can be just a company web page, and internet draft, or = pretty much anything.=20 4) Unallocated Future RFCs can define how these will be used but this just reserves = some space that we can decide later how to allocate it. If we find out = we ran out too quickly of one of the above spaces, we pull more out of = this block.=20 I don't know how large each block should be but as a very rough straw = man, how about=20 1) is 1 to 50 with well spaced items so that many requests can get past = 64 without long jump 2) is 100 to to 500 3) is 1000 to 5000 4) is the rest of the space so 51 to 99, 501 to 999, and 5001 to 2^16-1=20= I really have not put much thought into if theses numbers look good or = not but you get the basic idea of how we might slice it up. The storage = increment means it might be better to make the unallocated space = something like all the even numbers.=20 I can imagine a future with several hundred headers registered, and the = average messages using say 4 or them other than the very basic stuff. It = seems likely that all 4 of the non basic ones may end of need a long = jump. In a future like that, I'd love to see how much saving we got from = this differential coding scheme.=20 =20 From wwwrun@rfc-editor.org Mon Aug 6 22:44:07 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DB721F8647; Mon, 6 Aug 2012 22:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.986 X-Spam-Level: X-Spam-Status: No, score=-101.986 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzfrgYclU0si; Mon, 6 Aug 2012 22:44:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BC67521F8543; Mon, 6 Aug 2012 22:44:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F11FA62188; Mon, 6 Aug 2012 22:43:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120807054308.F11FA62188@rfc-editor.org> Date: Mon, 6 Aug 2012 22:43:08 -0700 (PDT) Cc: core@ietf.org, rfc-editor@rfc-editor.org Subject: [core] RFC 6690 on Constrained RESTful Environments (CoRE) Link Format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 05:44:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6690 Title: Constrained RESTful Environments (CoRE) Link Format Author: Z. Shelby Status: Standards Track Stream: IETF Date: August 2012 Mailbox: zach@sensinode.com Pages: 22 Characters: 47720 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-core-link-format-14.txt URL: http://www.rfc-editor.org/rfc/rfc6690.txt This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Bert.Greevenbosch@huawei.com Tue Aug 7 19:27:31 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CAF11E8109 for ; Tue, 7 Aug 2012 19:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LHosqEqLAHS for ; Tue, 7 Aug 2012 19:27:30 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 536B611E80F1 for ; Tue, 7 Aug 2012 19:27:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AIZ41744; Tue, 07 Aug 2012 18:27:02 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 19:24:36 -0700 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 19:24:34 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Wed, 8 Aug 2012 10:24:29 +0800 From: Bert Greevenbosch To: Cullen Jennings , core WG Thread-Topic: [core] Comments on option numbers Thread-Index: AQHNcanwpdLc1I2w5k+qtxkC5HQGJJdPM5vg Date: Wed, 8 Aug 2012 02:24:29 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB62907F303@szxeml509-mbs> References: <8455A202-71E5-43F5-92AD-37B79C409745@iii.ca> In-Reply-To: <8455A202-71E5-43F5-92AD-37B79C409745@iii.ca> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Comments on option numbers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 02:27:31 -0000 Hi Cullen, Interesting option numbering scheme. I think that reserving option numbers = for future use (i.e. category 4 below) certainly makes sense. I have a question about the proposed gaps 51-99 and 501-999: If at some point in time we want to expand category 1, we will likely use g= ap 51-99, whereas if we want to expand category 2 we will likely prefer gap= 501-999 over 51-99 (as using 51-99 for category 2 would reduce the expansi= on space for category 1). But then why not allocate 51-99 to category 1 now= ? Do you think there may be a future Category 5 that would benefit from low o= ption numbers? Since 51-99 can be considered as "valuable option numbers", maybe it is bet= ter to reserve higher option numbers for future use? Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cul= len Jennings Sent: 04 August 2012 02:58 To: core WG Subject: [core] Comments on option numbers This with my individual contributor hat on=20 I think we should split up the space into roughly three categories. I think= they should be =20 1) Standards Track=20 - this is for very low numbers that very desirable and to make sure that ot= her stuff does not use up all the super prime realestate that future revisi= ons of the key RFC may need. This should be very small.=20 2) IETF Review=20 This is pretty easy and lots of stuff would fall in here. Note that many IE= TF standards Track RFC might choose to use a code point out of this space i= f they do not need the optimization of space 1.=20 3) Expert Review with Specification Required=20 This is "almost" first come first serve. But I think we want to try and avo= id completely duplicated of code points that mean that do the same thing. W= e also need to check that things like the interactions with proxies was cor= rectly considered. To do this, the lightest weight thing we can do is have = expert review. And the expert needs to have something to review. This can b= e just a company web page, and internet draft, or pretty much anything.=20 4) Unallocated Future RFCs can define how these will be used but this just reserves some s= pace that we can decide later how to allocate it. If we find out we ran out= too quickly of one of the above spaces, we pull more out of this block.=20 I don't know how large each block should be but as a very rough straw man, = how about=20 1) is 1 to 50 with well spaced items so that many requests can get past 64 = without long jump 2) is 100 to to 500 3) is 1000 to 5000 4) is the rest of the space so 51 to 99, 501 to 999, and 5001 to 2^16-1=20 I really have not put much thought into if theses numbers look good or not = but you get the basic idea of how we might slice it up. The storage increme= nt means it might be better to make the unallocated space something like al= l the even numbers.=20 I can imagine a future with several hundred headers registered, and the ave= rage messages using say 4 or them other than the very basic stuff. It seems= likely that all 4 of the non basic ones may end of need a long jump. In a = future like that, I'd love to see how much saving we got from this differen= tial coding scheme.=20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From yusuke.doi@toshiba.co.jp Wed Aug 8 19:54:07 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED4511E80DE for ; Wed, 8 Aug 2012 19:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.16 X-Spam-Level: X-Spam-Status: No, score=-5.16 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrHfjBoaGRGi for ; Wed, 8 Aug 2012 19:54:07 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 98D0C21F855E for ; Wed, 8 Aug 2012 19:54:06 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q792s4al001070 for ; Thu, 9 Aug 2012 11:54:04 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q792s4QT005569 for core@ietf.org; Thu, 9 Aug 2012 11:54:04 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id MAA05567; Thu, 9 Aug 2012 11:54:04 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q792s461010329 for ; Thu, 9 Aug 2012 11:54:04 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q792s3b5029009; Thu, 9 Aug 2012 11:54:03 +0900 (JST) Received: from [133.196.16.79] (ncg-dhcp79.isl.rdc.toshiba.co.jp [133.196.16.79]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 9A27297CC2 for ; Thu, 9 Aug 2012 11:54:03 +0900 (JST) Message-ID: <5023264B.6040300@toshiba.co.jp> Date: Thu, 09 Aug 2012 11:54:03 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 02:54:07 -0000 Dear all, As I spoke up to mic on vancouver, I have interest on option handling in CoAP. In SEP2, we had to make 'schema negotiaton' on (schema-informed) EXI communication, and used content type parameters as follows: Accept: sep-exi;level=[schema version] I think current CoAP cannot carry such parameters, and I need it to use schema-informed EXI over CoAP. (Note: SEP2 is just an example. I cannot say anything on the use of CoAP on future SEP2) Is there any reasonable way to carry such parameters? For example, creating 'parameter' option to add parameter on option is acceptable? Such as: Option 'Parameter' (elective, proxy-safe) option value: (uint)option index, (string)parameter key, (string)parameter value describes given parameter (key-value) on the option at the given option index on the packet order. Example: CON GET Uri-Port: ["/some-url"] Accept: ["some-exi"] Parameter: [1]["level"]["1"] The first argument of Parameter option mean this parameter is for 1st (0-origin) option. This request corresponds to HTTP equivalent: GET /some-url Accept: some-exi;level=1 Please let me know your feelings on my idea. Regards, // Yusuke DOI Corporate R&D Center, TOSHIBA Corp. From cabo@tzi.org Thu Aug 9 03:01:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980B421F86B5 for ; Thu, 9 Aug 2012 03:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.346 X-Spam-Level: X-Spam-Status: No, score=-106.346 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uphesfs2aKkt for ; Thu, 9 Aug 2012 03:01:25 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AB48321F8683 for ; Thu, 9 Aug 2012 03:01: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 q79A1G3c029038; Thu, 9 Aug 2012 12:01:16 +0200 (CEST) Received: from [192.168.217.105] (p548945C1.dip.t-dialin.net [84.137.69.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5E5AA4DF; Thu, 9 Aug 2012 12:01:16 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <5023264B.6040300@toshiba.co.jp> Date: Thu, 9 Aug 2012 12:01:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81E26E52-54F1-48DC-ACDB-35C41D75A8EA@tzi.org> References: <5023264B.6040300@toshiba.co.jp> To: Yusuke DOI X-Mailer: Apple Mail (2.1485) Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 10:01:25 -0000 On Aug 9, 2012, at 04:54, Yusuke DOI wrote: > Is there any reasonable way to carry such parameters? As of today, you would have to register a new content-type number for = each value of the parameter. E.g., for text/plain; charset=3Dutf-8 we registered ct=3D0. If we needed any other charset (heaven forbid, no we don't), we'd have = to register another ct value. If there is a strong use case for being able to supply an arbitrary = parameter to a media type, then the solution you suggested makes a lot = of sense. So if we were to register audio/rtp-midi (RFC 6295), we might register a = ct value for: audio/rtp-midi; rate=3D*; j_sec=3D* or some such, and the first parameter option would then set the rate, = and the second one the j_sec. Doing this at the full generality, we'd probably arrive at a language = not unlike URI templates... Or we'd simple have a parameter option that has both parameter name and = value, and set the first one to "rate=3D32500", and the second one to = "j_sec=3Drecj". Of course, Accept can be repeated, and it is not quite clear where to = put the parameters for each, which might call for an envelope option... Lots of complexity, so we'd need a really good usecase to motivate this. So: Would the basic scheme (registering a separate content-type number for = each level you need) work in your use case? Gr=FC=DFe, Carsten From yusuke.doi@toshiba.co.jp Sun Aug 12 02:10:46 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05D621F8460 for ; Sun, 12 Aug 2012 02:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41H+9M2dE+7W for ; Sun, 12 Aug 2012 02:10:46 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id F0CB621F845E for ; Sun, 12 Aug 2012 02:10:45 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7C9AhiL013580 for ; Sun, 12 Aug 2012 18:10:43 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7C9AhVH026240 for core@ietf.org; Sun, 12 Aug 2012 18:10:43 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA26239; Sun, 12 Aug 2012 18:10:43 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7C9Ahac014515 for ; Sun, 12 Aug 2012 18:10:43 +0900 (JST) Received: by toshiba.co.jp id q7C9Agqd024107; Sun, 12 Aug 2012 18:10:42 +0900 (JST) Date: Sun, 12 Aug 2012 18:10:42 +0900 (JST) Message-Id: <201208120910.q7C9Agqd024107@toshiba.co.jp> To: cabo@tzi.org From: DOI Yusuke In-Reply-To: <81E26E52-54F1-48DC-ACDB-35C41D75A8EA@tzi.org> References: <5023264B.6040300@toshiba.co.jp> <81E26E52-54F1-48DC-ACDB-35C41D75A8EA@tzi.org> X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 09:10:47 -0000 Carsten, > Would the basic scheme (registering a separate content-type number fo= r each level you need) work in your use case? I guess this scheme may work for me, as far as anybody can register/find every content-type number at his/her needs. In this case, I guess the problem is cost-benefit comparison between 'a new open registry management about content type number' vs. 'a new option to add arbitrary parameter with inefficient ASCII/UTF-8/whatever codings'. There may be another application (maybe with HTTP-CoAP Proxy) which want to make use of arbitrary parameters on HTTP option. I'm not sure CoAP {should|doesn't need to} be prepared to such application. > Of course, Accept can be repeated, and it is not quite clear where to= put the parameters for each, which might call for an envelope option..= .= My idea is use of option index in packet order. If there are one URI Path option and two Accept options, index [0][1][2] should point each option clearly. // Yusuke DOI , TOSHIBA R&D Center From: Carsten Bormann Subject: Re: [core] A question on handling of option parameters defined= in HTTP Date: Thu, 9 Aug 2012 12:01:15 +0200 > On Aug 9, 2012, at 04:54, Yusuke DOI wrote= : > = > > Is there any reasonable way to carry such parameters? > = > As of today, you would have to register a new content-type number for= each value of the parameter. > = > E.g., for text/plain; charset=3Dutf-8 we registered ct=3D0. > If we needed any other charset (heaven forbid, no we don't), we'd hav= e to register another ct value. > = > If there is a strong use case for being able to supply an arbitrary p= arameter to a media type, then the solution you suggested makes a lot o= f sense. > = > So if we were to register audio/rtp-midi (RFC 6295), we might registe= r a ct value for: > = > audio/rtp-midi; rate=3D*; j_sec=3D* > = > or some such, and the first parameter option would then set the rate,= and the second one the j_sec. > Doing this at the full generality, we'd probably arrive at a language= not unlike URI templates... > = > Or we'd simple have a parameter option that has both parameter name a= nd value, and set the first one to "rate=3D32500", and the second one t= o "j_sec=3Drecj". > = > Of course, Accept can be repeated, and it is not quite clear where to= put the parameters for each, which might call for an envelope option..= .= > = > Lots of complexity, so we'd need a really good usecase to motivate th= is. > = > So: > = > Would the basic scheme (registering a separate content-type number fo= r each level you need) work in your use case? > = > Gr=FC=DFe, Carsten > = From cabo@tzi.org Sun Aug 12 04:22:11 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0154C21F8533 for ; Sun, 12 Aug 2012 04:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.337 X-Spam-Level: X-Spam-Status: No, score=-106.337 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCKd5j94bxEy for ; Sun, 12 Aug 2012 04:22:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFEC21F84CF for ; Sun, 12 Aug 2012 04:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q7CBM1TP022297; Sun, 12 Aug 2012 13:22:01 +0200 (CEST) Received: from [192.168.217.105] (p54894979.dip.t-dialin.net [84.137.73.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 01E13ABD; Sun, 12 Aug 2012 13:22:00 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <201208120910.q7C9Agx4021028@toshiba.co.jp> Date: Sun, 12 Aug 2012 13:22:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5023264B.6040300@toshiba.co.jp> <81E26E52-54F1-48DC-ACDB-35C41D75A8EA@tzi.org> <201208120910.q7C9Agx4021028@toshiba.co.jp> To: DOI Yusuke X-Mailer: Apple Mail (2.1485) Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 11:22:11 -0000 Hi Yusuke, >> Would the basic scheme (registering a separate content-type number = for each level you need) work in your use case? >=20 > I guess this scheme may work for me, as far as anybody can > register/find every content-type number at his/her needs. coap-11 section 12.3 says (about the CoAP media type registry): The IANA policy for additions in the range 256-65535 inclusive is "First Come First Served" as described in [RFC5226]. So we already have the wide-open policy in place that would enable this. > In this > case, I guess the problem is cost-benefit comparison between 'a new > open registry management about content type number' vs. 'a new option > to add arbitrary parameter with inefficient ASCII/UTF-8/whatever > codings'. Indeed. Here is my attempt at this comparison: Registering new numbers for each new level of the XML profile does = require (1) a little bit of clerical work and (2) that the number gets = inserted into implementations. But implementations already need to be = changed if they want to handle the new profile, so that cost is = relatively small. A new CoAP Option requires new code, new interop testing, and is another = source of bugs. So, based on the information I have, I think I would prefer to handle = this specific use case using the wide-open registration policy of CoAP = content-type numbers. > There may be another application (maybe with HTTP-CoAP Proxy) which > want to make use of arbitrary parameters on HTTP option. I'm not sure > CoAP {should|doesn't need to} be prepared to such application. I'm not sure either. For now, I think "YAGNI" applies ("you ain't gonna need it"; don't add = complexity for a potential future use case if (1) you don't know whether = you will actually ever need it and (2) you will have a chance to add the = necessary complexity later, at a time when you know more about the = actual properties of the use case -- I think both conditions are = satisfied). >> Of course, Accept can be repeated, and it is not quite clear where to = put the parameters for each, which might call for an envelope option... >=20 > My idea is use of option index in packet order. If there are one URI > Path option and two Accept options, index [0][1][2] should point each > option clearly. Ah, I see. I'd prefer to use some form of nesting to indicate such a = relationship. =20 But, from the above, it seems we aren't defining this option yet. Gr=FC=DFe, Carsten From yusuke.doi@toshiba.co.jp Sun Aug 12 22:22:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CBF21F86D7 for ; Sun, 12 Aug 2012 22:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRU5uhNdwPz5 for ; Sun, 12 Aug 2012 22:22:24 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8188321F8582 for ; Sun, 12 Aug 2012 22:22:23 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7D5MMvm012249 for ; Mon, 13 Aug 2012 14:22:22 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7D5MMEd021790 for core@ietf.org; Mon, 13 Aug 2012 14:22:22 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id QAA21789; Mon, 13 Aug 2012 14:22:22 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7D5MLX3010806 for ; Mon, 13 Aug 2012 14:22:21 +0900 (JST) Received: by toshiba.co.jp id q7D5MLLT025726; Mon, 13 Aug 2012 14:22:21 +0900 (JST) Date: Mon, 13 Aug 2012 14:22:20 +0900 (JST) Message-Id: <201208130522.q7D5MLLT025726@toshiba.co.jp> To: cabo@tzi.org From: DOI Yusuke In-Reply-To: References: <81E26E52-54F1-48DC-ACDB-35C41D75A8EA@tzi.org> <201208120910.q7C9Agx4021028@toshiba.co.jp> X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 05:22:25 -0000 Hi Carsten, Thank you for your insights. Then, my question is very simple. Is 16 bit space enough or not for parameterized content types? > coap-11 section 12.3 says (about the CoAP media type registry): > = > The IANA > policy for additions in the range 256-65535 inclusive is "First Co= me > First Served" as described in [RFC5226]. > = > So we already have the wide-open policy in place that would enable th= is. For content type, it's enough values. But for parameters, I'm not sure 16 bit (minus 256) is enough or not. 60 thousands seems to be big enough for now, but I feel anxious if it's enough for every parameterized content types. My use case needs a new ct number for every version of XML schema used in EXI communication (including proprietary ones). If I'm going to be selfish, I may register (not-yet-existing) 1000 versions of schema ID before it runs out. As we may need them per application per clients at maximum, 1000 is a large but not *unrealistic* value we need in my guess. = Then, the ct value space only serves 60+ companies/groups with similar requirements. > A new CoAP Option requires new code, new interop testing, and is anot= her source of bugs. Yes I agree. If requirement benefit does not outweigh the cost, we shouldn't do that. On the other hand, I think content-type ID space is precious (costy) to consume them for every combination of content-type parameters. Yusuke From: Carsten Bormann Subject: Re: [core] A question on handling of option parameters defined= in HTTP Date: Sun, 12 Aug 2012 13:22:00 +0200 > Hi Yusuke, > = > >> Would the basic scheme (registering a separate content-type number= for each level you need) work in your use case? > > = > > I guess this scheme may work for me, as far as anybody can > > register/find every content-type number at his/her needs. > = > coap-11 section 12.3 says (about the CoAP media type registry): > = > The IANA > policy for additions in the range 256-65535 inclusive is "First Co= me > First Served" as described in [RFC5226]. > = > So we already have the wide-open policy in place that would enable th= is. > = > > In this > > case, I guess the problem is cost-benefit comparison between 'a new= > > open registry management about content type number' vs. 'a new opti= on > > to add arbitrary parameter with inefficient ASCII/UTF-8/whatever > > codings'. > = > Indeed. Here is my attempt at this comparison: > Registering new numbers for each new level of the XML profile does re= quire (1) a little bit of clerical work and (2) that the number gets in= serted into implementations. But implementations already need to be ch= anged if they want to handle the new profile, so that cost is relativel= y small. > A new CoAP Option requires new code, new interop testing, and is anot= her source of bugs. > = > So, based on the information I have, I think I would prefer to handle= this specific use case using the wide-open registration policy of CoAP= content-type numbers. > = > > There may be another application (maybe with HTTP-CoAP Proxy) which= > > want to make use of arbitrary parameters on HTTP option. I'm not su= re > > CoAP {should|doesn't need to} be prepared to such application. > = > I'm not sure either. > For now, I think "YAGNI" applies ("you ain't gonna need it"; don't ad= d complexity for a potential future use case if (1) you don't know whet= her you will actually ever need it and (2) you will have a chance to ad= d the necessary complexity later, at a time when you know more about th= e actual properties of the use case -- I think both conditions are sati= sfied). > = > >> Of course, Accept can be repeated, and it is not quite clear where= to put the parameters for each, which might call for an envelope optio= n... > > = > > My idea is use of option index in packet order. If there are one UR= I > > Path option and two Accept options, index [0][1][2] should point ea= ch > > option clearly. > = > Ah, I see. I'd prefer to use some form of nesting to indicate such a= relationship. = > But, from the above, it seems we aren't defining this option yet. > = > Gr=FC=DFe, Carsten > = From cabo@tzi.org Sun Aug 12 23:10:55 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA84411E8072 for ; Sun, 12 Aug 2012 23:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.33 X-Spam-Level: X-Spam-Status: No, score=-106.33 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UESAppN7kqU for ; Sun, 12 Aug 2012 23:10:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6B611E8097 for ; Sun, 12 Aug 2012 23:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q7D6Ai5K008455; Mon, 13 Aug 2012 08:10:44 +0200 (CEST) Received: from [192.168.217.105] (p5489298A.dip.t-dialin.net [84.137.41.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 04B7CBB6; Mon, 13 Aug 2012 08:10:43 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <201208130522.q7D5MLmk021041@toshiba.co.jp> Date: Mon, 13 Aug 2012 08:10:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81E26E52-54F1-48DC-ACDB-35C41D75A8EA@tzi.org> <201208120910.q7C9Agx4021028@toshiba.co.jp> <201208130522.q7D5MLmk021041@toshiba.co.jp> To: DOI Yusuke X-Mailer: Apple Mail (2.1485) Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 06:10:55 -0000 On Aug 13, 2012, at 07:22, DOI Yusuke wrote: > Is 16 bit space enough or not for > parameterized content types? Good question. There is no strong reason to stay within 16 bits, so if we foresee a = strong demand we could extend this to, say, 3 bytes. (We also may want to reserve some space to continue the experiment under = http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt if people find that = useful.) There is also a question how well IANA will be able to handle such a = large registry. AFAIK, so far the largest registry is = http://www.iana.org/assignments/enterprise-numbers with some 40000 = entries. But the media type registry would likely be allocated in chunks, so it = might be less onerous. Gr=FC=DFe, Carsten From yusuke.doi@toshiba.co.jp Mon Aug 13 02:55:49 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD65C21F845E for ; Mon, 13 Aug 2012 02:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STQbE3gaGwJO for ; Mon, 13 Aug 2012 02:55:49 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 82A6F21F853B for ; Mon, 13 Aug 2012 02:55:48 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7D9tkOn008456 for ; Mon, 13 Aug 2012 18:55:46 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7D9tkJE001267 for core@ietf.org; Mon, 13 Aug 2012 18:55:46 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA01266; Mon, 13 Aug 2012 18:55:46 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7D9tkCs021634 for ; Mon, 13 Aug 2012 18:55:46 +0900 (JST) Received: by toshiba.co.jp id q7D9tkSE016137; Mon, 13 Aug 2012 18:55:46 +0900 (JST) Date: Mon, 13 Aug 2012 18:55:45 +0900 (JST) Message-Id: <201208130955.q7D9tkSE016137@toshiba.co.jp> To: cabo@tzi.org From: DOI Yusuke In-Reply-To: References: <201208130522.q7D5MLmk021041@toshiba.co.jp> X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 09:55:50 -0000 Carsten, 3 or 4 bytes seems to be enough in this case. I can agree on your idea to loosen the 16-bit length limit of content type id. I guess the assignment could be something like IP address prefix assignment. Then ct registry could be something like this: ... - application-example.net-exi 0x00f3.1000-0x00f3.1fff - application-example.org-exi 0x00f3.2000-0x00f3.2fff ... - application-very.large.example.com-exi 0xf000.0000-0xf000.ffff In terms of fairness and efficiency, I guess block assignment should be done on some larger number (not from 256). My idea is to assign larger block on larger number zone, smaller block on smaller number zone (as shown above). Selfish bulk assign request should pay cost for (slightly) larger packet, isn't it? // Yusuke DOI , TOSHIBA R&D Center From: Carsten Bormann Subject: Re: [core] A question on handling of option parameters defined= in HTTP Date: Mon, 13 Aug 2012 08:10:42 +0200 > On Aug 13, 2012, at 07:22, DOI Yusuke wrot= e: > = > > Is 16 bit space enough or not for > > parameterized content types? > = > Good question. > There is no strong reason to stay within 16 bits, so if we foresee a = strong demand we could extend this to, say, 3 bytes. > (We also may want to reserve some space to continue the experiment un= der http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt if people find= that useful.) > = > There is also a question how well IANA will be able to handle such a = large registry. > AFAIK, so far the largest registry is http://www.iana.org/assignments= /enterprise-numbers with some 40000 entries. > But the media type registry would likely be allocated in chunks, so i= t might be less onerous. > = > Gr=FC=DFe, Carsten > = From cabo@tzi.org Mon Aug 13 09:58:40 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153D221F8703 for ; Mon, 13 Aug 2012 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.329 X-Spam-Level: X-Spam-Status: No, score=-106.329 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACxyUkDzcHNh for ; Mon, 13 Aug 2012 09:58:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA0121F86B3 for ; Mon, 13 Aug 2012 09:58:39 -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 q7DGwTbO001540 for ; Mon, 13 Aug 2012 18:58:29 +0200 (CEST) Received: from [192.168.217.117] (p54892C72.dip.t-dialin.net [84.137.44.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 98A77F30; Mon, 13 Aug 2012 18:58:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Aug 2012 18:58:28 +0200 To: "core@ietf.org WG" Message-Id: <6CCFD8D5-FDB4-4128-B50F-F13D3D9188FD@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Subject: [core] IETF84 CoRE minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 16:58:40 -0000 I have uploaded a first cut of the minutes. http://www.ietf.org/proceedings/84/minutes/minutes-84-core There were lots of really valuable nuggets of wisdom in this meeting, = and I hope my edit of the various notes I got does not distort them too = much. I'm also waiting for another set of notes from the Friday part. I'm going to be mostly offline till Sep 1. But please do comment about the minutes to the list; I'll pick up the = comments when I'm back. Gr=FC=DFe, Carsten From cabo@tzi.org Mon Aug 13 13:24:52 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808A421F863B for ; Mon, 13 Aug 2012 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.327 X-Spam-Level: X-Spam-Status: No, score=-106.327 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zol57ypTlkW1 for ; Mon, 13 Aug 2012 13:24:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9518121F84E2 for ; Mon, 13 Aug 2012 13:24: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 q7DKOgi6020966 for ; Mon, 13 Aug 2012 22:24:42 +0200 (CEST) Received: from [192.168.217.117] (p54892C72.dip.t-dialin.net [84.137.44.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 02B3FF81; Mon, 13 Aug 2012 22:24:41 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Aug 2012 22:24:35 +0200 To: "core@ietf.org WG" Message-Id: <9AF810CA-2D47-41DD-B673-A9595DCC05A5@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Subject: [core] CoCoA: Strawman draft congestion control/advanced X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 20:24:52 -0000 In Vancouver, we had extensive discussions about the congestion behavior = of CoAP. We decided to play it safe and have only a very basic sequential = lock-step behavior in the base CoAP specification that should be mostly = risk-free. This leaves an opening for advanced congestion control mechanism that we = might want to use in addition to basic CoAP once that spec is done. I have written a very simple initial draft for one such "advanced" = congestion control mechanism, which I called "Simple CoCoA". This mainly specifies an RTO estimator that should work with CoAP. It also shows one way such an RTO estimator could be used to pace = non-confirmables out of an -observe-capable server. This is all very rough in -00. But I wanted to have a draft out so = people can start experimenting while I'm on vacation... I'm also interested in feedback if this looks like the RTT/RTO = estimators that people had in mind in Vancouver. Filename: draft-bormann-core-cocoa Title: CoAP Simple Congestion Control/Advanced Creation date: 2012-08-13 Htmlized: http://tools.ietf.org/html/draft-bormann-core-cocoa-00 Abstract: The CoAP protocol needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines some simple advanced CoRE Congestion Control mechanisms, Simple CoCoA. In the present version -00, it is mainly a straw-man document to gauge the implementation effort required, with a view towards simplifying it further. Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Mon Aug 13 18:02:35 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686E521F8742 for ; Mon, 13 Aug 2012 18:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWnEKI0hdIGq for ; Mon, 13 Aug 2012 18:02:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7F79821F84F9 for ; Mon, 13 Aug 2012 18:02:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIV64705; Mon, 13 Aug 2012 17:02:34 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 18:00:02 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 18:00:03 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 14 Aug 2012 08:59:59 +0800 From: Bert Greevenbosch To: DOI Yusuke , "cabo@tzi.org" Thread-Topic: [core] A question on handling of option parameters defined in HTTP Thread-Index: AQHNeTnnblA4XGEiTUCT4BegHDkeXpdYdhLw Date: Tue, 14 Aug 2012 00:59:58 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> References: <201208130522.q7D5MLmk021041@toshiba.co.jp> <201208130955.q7D9tkSE016137@toshiba.co.jp> In-Reply-To: <201208130955.q7D9tkSE016137@toshiba.co.jp> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 01:02:35 -0000 Hi Yuseke, Carsten, all, I can see some value of having a larger content type id space, with a suffi= x mechanism for application specific parameters. I guess extending the valu= e space is easily done by allowing more bytes in the Content-Type option an= d adjusting the description of the "ct" attribute. I think we need to be careful about bulk assignments though, as it should n= ot be easy to occupy large blocks that afterwards remain unused. So if we g= o this way, we should consider some IANA guidelines and extra requirements = for bulk assignments. Another question is if the client and server can remain oblivious of the di= stinction between the base content type and the parameters. One of the main= usages of the content type is the "accept" option, where the client indica= tes the acceptable content types to the server. Currently, if the client ca= n accept multiple content types, it will include one option for each conten= t type. But if we allow to split the content type in base and parameters an= d bulk assignment, do we also need to adjust the semantics of the "accept" = option to allow bulk acceptance? B.T.W. in the current version of CoAP, the content type and media type seem= to be the same thing. Is there a reason to use two different terms? Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of DOI= Yusuke Sent: 13 August 2012 17:56 To: cabo@tzi.org Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in = HTTP Carsten, 3 or 4 bytes seems to be enough in this case. I can agree on your idea to loosen the 16-bit length limit of content type id. I guess the assignment could be something like IP address prefix assignment. Then ct registry could be something like this: ... - application-example.net-exi 0x00f3.1000-0x00f3.1fff - application-example.org-exi 0x00f3.2000-0x00f3.2fff ... - application-very.large.example.com-exi 0xf000.0000-0xf000.ffff In terms of fairness and efficiency, I guess block assignment should be done on some larger number (not from 256). My idea is to assign larger block on larger number zone, smaller block on smaller number zone (as shown above). Selfish bulk assign request should pay cost for (slightly) larger packet, isn't it? // Yusuke DOI , TOSHIBA R&D Center From: Carsten Bormann Subject: Re: [core] A question on handling of option parameters defined in = HTTP Date: Mon, 13 Aug 2012 08:10:42 +0200 > On Aug 13, 2012, at 07:22, DOI Yusuke wrote: >=20 > > Is 16 bit space enough or not for > > parameterized content types? >=20 > Good question. > There is no strong reason to stay within 16 bits, so if we foresee a stro= ng demand we could extend this to, say, 3 bytes. > (We also may want to reserve some space to continue the experiment under = http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt if people find that us= eful.) >=20 > There is also a question how well IANA will be able to handle such a larg= e registry. > AFAIK, so far the largest registry is http://www.iana.org/assignments/ent= erprise-numbers with some 40000 entries. > But the media type registry would likely be allocated in chunks, so it mi= ght be less onerous. >=20 > Gr=FC=DFe, Carsten >=20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Tue Aug 14 00:07:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5370511E8098 for ; Tue, 14 Aug 2012 00:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.326 X-Spam-Level: X-Spam-Status: No, score=-106.326 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMZurpCjGb5g for ; Tue, 14 Aug 2012 00:07:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9310611E808D for ; Tue, 14 Aug 2012 00:07:32 -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 q7E77GD0026219; Tue, 14 Aug 2012 09:07:16 +0200 (CEST) Received: from [192.168.217.105] (p54892C72.dip.t-dialin.net [84.137.44.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 965EDFF2; Tue, 14 Aug 2012 09:07:15 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> Date: Tue, 14 Aug 2012 09:07:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201208130522.q7D5MLmk021041@toshiba.co.jp> <201208130955.q7D9tkSE016137@toshiba.co.jp> <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1485) Cc: "core@ietf.org" Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 07:07:33 -0000 On Aug 14, 2012, at 02:59, Bert Greevenbosch = wrote: > B.T.W. in the current version of CoAP, the content type and media type = seem to be the same thing. Is there a reason to use two different terms? Hi Bert, let me try to answer this specific item: In coap-09, we added a column to the registry that specifies the = content-encoding. So a CoAP content-type number stands not just for the Media Type, but = for the Content-Coding, too. (So far that is always the identity encoding, but that might change for = additional registrations.) We probably should change the name of the registry to make this more = obvious. Gr=FC=DFe, Carsten From internet-drafts@ietf.org Tue Aug 14 15:58:45 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346DA21F86F7; Tue, 14 Aug 2012 15:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6LLRG-Re6I8; Tue, 14 Aug 2012 15:58:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB60521F86F9; Tue, 14 Aug 2012 15:58:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120814225844.3705.31337.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2012 15:58:44 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 22:58:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-09.txt Pages : 30 Date : 2012-08-14 Abstract: CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-block-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Tue Aug 14 16:10:27 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35F221E80A5 for ; Tue, 14 Aug 2012 16:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.324 X-Spam-Level: X-Spam-Status: No, score=-106.324 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6Xkx8RyanIH for ; Tue, 14 Aug 2012 16:10:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1924D21E80A4 for ; Tue, 14 Aug 2012 16:10:26 -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 q7ENAGk3024335 for ; Wed, 15 Aug 2012 01:10:17 +0200 (CEST) Received: from [192.168.217.105] (p54892C67.dip.t-dialin.net [84.137.44.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AD334417; Wed, 15 Aug 2012 01:10:16 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Carsten Bormann In-Reply-To: <20120814225844.3705.31337.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2012 01:10:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120814225844.3705.31337.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1485) Subject: Re: [core] I-D Action: draft-ietf-core-block-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 23:10:28 -0000 As you know, while we are finishing -coap and -observe, -block is sitting in its corner and waiting for its great editorial rewrite. This isn't it, as I'm going on vacation in a couple of hours. I have essentially resubmitted the draft, with some of the most egregious errors fixed along the lines of the existing post-Paris tickets. Htmlized: http://tools.ietf.org/html/draft-ietf-core-block-09 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-09 So -block is returning to its corner, waiting for the actual rewrite, which will happen when I'm back in Germany. If you want to move things forward a bit while I'm relaxing :-), one obvious thing is to try out Simple CoCoA (or another advanced congestion control scheme of your liking). We don't have to finish these schemes next week, but we want to make sure we have a credible story how this=20 will evolve, at the time we send the base draft on to the IESG (i.e., soon). N=E4eme varsti, Carsten From esko.dijk@philips.com Wed Aug 15 06:17:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4F521F881C for ; Wed, 15 Aug 2012 06:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZMbT9jXECKt for ; Wed, 15 Aug 2012 06:17:42 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0D76421F8802 for ; Wed, 15 Aug 2012 06:17:38 -0700 (PDT) Received: from mail98-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 13:17:37 +0000 Received: from mail98-co1 (localhost [127.0.0.1]) by mail98-co1-R.bigfish.com (Postfix) with ESMTP id C3FCF840119; Wed, 15 Aug 2012 13:17:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VPS-39(zz217bL15d6O9251J542M1418Izz1202hzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah107ah) Received: from mail98-co1 (localhost.localdomain [127.0.0.1]) by mail98-co1 (MessageSwitch) id 1345036655642443_4225; Wed, 15 Aug 2012 13:17:35 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.248]) by mail98-co1.bigfish.com (Postfix) with ESMTP id 998ED80044; Wed, 15 Aug 2012 13:17:35 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 13:17:35 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.25]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.02.0309.003; Wed, 15 Aug 2012 14:17:33 +0100 From: "Dijk, Esko" To: Shoichi Sakane , "Rahman, Akbar" , "core@ietf.org" Thread-Topic: [core] FW: New Version Notification for draft-ietf-core-groupcomm-02.txt Thread-Index: Ac1epFkEWWNOn5zNT9uG5wCp0J4v3QAx6tkwBIsx0oACU3uKIA== Date: Wed, 15 Aug 2012 13:17:32 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618ABFE3B@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <501C1095.2010200@tanu.org> In-Reply-To: <501C1095.2010200@tanu.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] FW: New Version Notification for draft-ietf-core-groupcomm-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 13:17:42 -0000 Hello Shoichi, The reason indicated in the draft is that POST is non-idempotent. (DELETE i= s idempotent.) However the reason why non-idempotent requests are not allowed, is not ment= ioned. It has to do with the fact that not all group members are guaranteed to receive the multicast request; and the client (sender) ca= n not readily find out which group members did get it and which not. Any discussion input is welcome here. I think that under certain conditions= , use of POST in CoAP multicast can be allowed. E.g. if it's ok that only a part of the group receive the request. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Sho= ichi Sakane Sent: Friday 3 August 2012 19:56 To: Rahman, Akbar; core@ietf.org Subject: Re: [core] FW: New Version Notification for draft-ietf-core-groupc= omm-02.txt I don't know whether there was same discussion before. If you allow DELETE method, you should allow POST method. why don't you allow to use POST method in the current draft ? Shoichi _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From yusuke.doi@toshiba.co.jp Wed Aug 15 20:13:47 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF1C21F85A7 for ; Wed, 15 Aug 2012 20:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.624 X-Spam-Level: X-Spam-Status: No, score=-6.624 tagged_above=-999 required=5 tests=[AWL=1.465, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 553AaD9QyjXy for ; Wed, 15 Aug 2012 20:13:46 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id A2E1321F85A2 for ; Wed, 15 Aug 2012 20:13:43 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q7G3Dgvr001560 for ; Thu, 16 Aug 2012 12:13:42 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q7G3Dgl8010497 for core@ietf.org; Thu, 16 Aug 2012 12:13:42 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id NAA10492; Thu, 16 Aug 2012 12:13:42 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q7G3Dfit006265 for ; Thu, 16 Aug 2012 12:13:42 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q7G3DfwX019494; Thu, 16 Aug 2012 12:13:41 +0900 (JST) Received: from [133.196.16.100] (ncg-dhcp100.isl.rdc.toshiba.co.jp [133.196.16.100]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id D8B4C97CCA; Thu, 16 Aug 2012 12:13:41 +0900 (JST) Message-ID: <502C6564.1060400@toshiba.co.jp> Date: Thu, 16 Aug 2012 12:13:40 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bert Greevenbosch References: <201208130522.q7D5MLmk021041@toshiba.co.jp> <201208130955.q7D9tkSE016137@toshiba.co.jp> <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> In-Reply-To: <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "core@ietf.org" Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 03:13:47 -0000 Dear Bart, Thanks for the comments. I feel anxous again about 'ct number per content-type and any parameter combination' approach. > I think we need to be careful about bulk assignments though, as it should not be easy to occupy large blocks that afterwards remain unused. So if we go this way, we should consider some IANA guidelines and extra requirements for bulk assignments. As the space is for content-type parameters and combination of parameters (it may corresponds to anything), it may not be observable how many combinations are actually used. > Another question is if the client and server can remain oblivious of the distinction between the base content type and the parameters. One of the main usages of the content type is the "accept" option, where the client indicates the acceptable content types to the server. Currently, if the client can accept multiple content types, it will include one option for each content type. But if we allow to split the content type in base and parameters and bulk assignment, do we also need to adjust the semantics of the "accept" option to allow bulk acceptance? Ouch. I don't think this should happen. Because parameters could be anything, I think it's too difficult to define a general behavior to distinct generic ct and specific ct. If it's not too late, I'll write up some proposal draft(s) for arbtrary parameter option (by number and by string). Yusuke (2012-08-14 09:59), Bert Greevenbosch wrote: > Hi Yuseke, Carsten, all, > > I can see some value of having a larger content type id space, with a suffix mechanism for application specific parameters. I guess extending the value space is easily done by allowing more bytes in the Content-Type option and adjusting the description of the "ct" attribute. > > I think we need to be careful about bulk assignments though, as it should not be easy to occupy large blocks that afterwards remain unused. So if we go this way, we should consider some IANA guidelines and extra requirements for bulk assignments. > > Another question is if the client and server can remain oblivious of the distinction between the base content type and the parameters. One of the main usages of the content type is the "accept" option, where the client indicates the acceptable content types to the server. Currently, if the client can accept multiple content types, it will include one option for each content type. But if we allow to split the content type in base and parameters and bulk assignment, do we also need to adjust the semantics of the "accept" option to allow bulk acceptance? > > B.T.W. in the current version of CoAP, the content type and media type seem to be the same thing. Is there a reason to use two different terms? > > Best regards, > Bert > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of DOI Yusuke > Sent: 13 August 2012 17:56 > To: cabo@tzi.org > Cc: core@ietf.org > Subject: Re: [core] A question on handling of option parameters defined in HTTP > > Carsten, > > 3 or 4 bytes seems to be enough in this case. I can agree on your > idea to loosen the 16-bit length limit of content type id. > > I guess the assignment could be something like IP address prefix > assignment. Then ct registry could be something like this: > > ... > - application-example.net-exi 0x00f3.1000-0x00f3.1fff > - application-example.org-exi 0x00f3.2000-0x00f3.2fff > ... > - application-very.large.example.com-exi 0xf000.0000-0xf000.ffff > > In terms of fairness and efficiency, I guess block assignment should > be done on some larger number (not from 256). My idea is to assign > larger block on larger number zone, smaller block on smaller number > zone (as shown above). Selfish bulk assign request should pay cost for > (slightly) larger packet, isn't it? > > // Yusuke DOI , TOSHIBA R&D Center > > From: Carsten Bormann > Subject: Re: [core] A question on handling of option parameters defined in HTTP > Date: Mon, 13 Aug 2012 08:10:42 +0200 > >> On Aug 13, 2012, at 07:22, DOI Yusuke wrote: >> >>> Is 16 bit space enough or not for >>> parameterized content types? >> >> Good question. >> There is no strong reason to stay within 16 bits, so if we foresee a strong demand we could extend this to, say, 3 bytes. >> (We also may want to reserve some space to continue the experiment under http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt if people find that useful.) >> >> There is also a question how well IANA will be able to handle such a large registry. >> AFAIK, so far the largest registry is http://www.iana.org/assignments/enterprise-numbers with some 40000 entries. >> But the media type registry would likely be allocated in chunks, so it might be less onerous. >> >> Grüße, Carsten >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From Berta.Carballido@cit.ie Fri Aug 17 09:08:12 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1738B11E80D1 for ; Fri, 17 Aug 2012 09:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzmSP4-i7nf1 for ; Fri, 17 Aug 2012 09:08:11 -0700 (PDT) Received: from mx-1.cit.ie (mx-1.cit.ie [157.190.3.45]) by ietfa.amsl.com (Postfix) with ESMTP id A24BC11E80A5 for ; Fri, 17 Aug 2012 09:08:10 -0700 (PDT) X-ASG-Debug-ID: 1345219684-019f28081d20cdd0001-aa7cYp Received: from CITMAIL.cit.ie ([157.190.22.71]) by mx-1.cit.ie with ESMTP id qMoi839yPkqlKlTl for ; Fri, 17 Aug 2012 17:08:04 +0100 (IST) X-Barracuda-Envelope-From: Berta.Carballido@cit.ie X-Barracuda-Apparent-Source-IP: 157.190.22.71 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, 17 Aug 2012 17:08:00 +0100 X-ASG-Orig-Subj: Question filtering Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question filtering Thread-Index: Ac18kckkhDMYgCnhSRq7VHdJF0pdZQ== From: "Berta Carballido" To: X-Barracuda-Connect: UNKNOWN[157.190.22.71] X-Barracuda-Start-Time: 1345219684 X-Barracuda-URL: http://157.190.3.45:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cit.ie X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.105921 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Subject: [core] Question filtering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:08:12 -0000 Dear all, I was reading the main coap draft to find out how to correctly interpret = an ampersand in a query and I am still in doubt. Should the ampersand be treated as AND or OR? Thanks, Berta. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Yusuke DOI Sent: 16 August 2012 04:14 To: Bert Greevenbosch Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined = in HTTP Dear Bart, Thanks for the comments. I feel anxous again about 'ct number per = content-type and any parameter combination' approach. > I think we need to be careful about bulk assignments though, as it = should not be easy to occupy large blocks that afterwards remain unused. = So if we go this way, we should consider some IANA guidelines and extra = requirements for bulk assignments. As the space is for content-type parameters and combination of = parameters (it may corresponds to anything), it may not be observable = how many combinations are actually used. > Another question is if the client and server can remain oblivious of = the distinction between the base content type and the parameters. One of = the main usages of the content type is the "accept" option, where the = client indicates the acceptable content types to the server. Currently, = if the client can accept multiple content types, it will include one = option for each content type. But if we allow to split the content type = in base and parameters and bulk assignment, do we also need to adjust = the semantics of the "accept" option to allow bulk acceptance? Ouch. I don't think this should happen. Because parameters could be = anything, I think it's too difficult to define a general behavior to = distinct generic ct and specific ct. If it's not too late, I'll write up some proposal draft(s) for arbtrary = parameter option (by number and by string). Yusuke (2012-08-14 09:59), Bert Greevenbosch wrote: > Hi Yuseke, Carsten, all, > > I can see some value of having a larger content type id space, with a = suffix mechanism for application specific parameters. I guess extending = the value space is easily done by allowing more bytes in the = Content-Type option and adjusting the description of the "ct" attribute. > > I think we need to be careful about bulk assignments though, as it = should not be easy to occupy large blocks that afterwards remain unused. = So if we go this way, we should consider some IANA guidelines and extra = requirements for bulk assignments. > > Another question is if the client and server can remain oblivious of = the distinction between the base content type and the parameters. One of = the main usages of the content type is the "accept" option, where the = client indicates the acceptable content types to the server. Currently, = if the client can accept multiple content types, it will include one = option for each content type. But if we allow to split the content type = in base and parameters and bulk assignment, do we also need to adjust = the semantics of the "accept" option to allow bulk acceptance? > > B.T.W. in the current version of CoAP, the content type and media type = seem to be the same thing. Is there a reason to use two different terms? > > Best regards, > Bert > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf=20 > Of DOI Yusuke > Sent: 13 August 2012 17:56 > To: cabo@tzi.org > Cc: core@ietf.org > Subject: Re: [core] A question on handling of option parameters=20 > defined in HTTP > > Carsten, > > 3 or 4 bytes seems to be enough in this case. I can agree on your=20 > idea to loosen the 16-bit length limit of content type id. > > I guess the assignment could be something like IP address prefix=20 > assignment. Then ct registry could be something like this: > > ... > - application-example.net-exi 0x00f3.1000-0x00f3.1fff > - application-example.org-exi 0x00f3.2000-0x00f3.2fff > ... > - application-very.large.example.com-exi 0xf000.0000-0xf000.ffff > > In terms of fairness and efficiency, I guess block assignment should=20 > be done on some larger number (not from 256). My idea is to assign=20 > larger block on larger number zone, smaller block on smaller number=20 > zone (as shown above). Selfish bulk assign request should pay cost for > (slightly) larger packet, isn't it? > > // Yusuke DOI , TOSHIBA R&D Center > > From: Carsten Bormann > Subject: Re: [core] A question on handling of option parameters=20 > defined in HTTP > Date: Mon, 13 Aug 2012 08:10:42 +0200 > >> On Aug 13, 2012, at 07:22, DOI Yusuke = wrote: >> >>> Is 16 bit space enough or not for >>> parameterized content types? >> >> Good question. >> There is no strong reason to stay within 16 bits, so if we foresee a = strong demand we could extend this to, say, 3 bytes. >> (We also may want to reserve some space to continue the experiment=20 >> under http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt if people=20 >> find that useful.) >> >> There is also a question how well IANA will be able to handle such a = large registry. >> AFAIK, so far the largest registry is = http://www.iana.org/assignments/enterprise-numbers with some 40000 = entries. >> But the media type registry would likely be allocated in chunks, so = it might be less onerous. >> >> Gr=FC=DFe, Carsten >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Fri Aug 17 09:38:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC3721F859A for ; Fri, 17 Aug 2012 09:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y4rgpEzRQ9Z for ; Fri, 17 Aug 2012 09:38:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8E21221F8584 for ; Fri, 17 Aug 2012 09:38:32 -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 q7HGcOAq004143 for ; Fri, 17 Aug 2012 18:38:25 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2A015F21 for ; Fri, 17 Aug 2012 18:38:23 +0200 (CEST) Received: by pbbrr4 with SMTP id rr4so3672917pbb.31 for ; Fri, 17 Aug 2012 09:38:21 -0700 (PDT) Received: by 10.68.235.236 with SMTP id up12mr12757049pbc.79.1345221501931; Fri, 17 Aug 2012 09:38:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.16.42 with HTTP; Fri, 17 Aug 2012 09:38:00 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Fri, 17 Aug 2012 19:38:00 +0300 Message-ID: To: Berta Carballido Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] Question filtering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:38:33 -0000 Hi Berta, Berta Carballido wrote: > I was reading the main coap draft to find out how to correctly interpret an ampersand in a query and I am still in doubt. > > Should the ampersand be treated as AND or OR? If you are referring to filtering .well-known/core, then RFC6690 says that there must be only one name/value pair in the query string (section 4.1). If you are referring to query strings in coap: URIs in general, then there are no filtering semantics attached to them. The ampersand just separates the arguments that parametrise the resource. It's up to the resource what representation is returned for different arguments and the order in which they appear. Klaus From hartke@tzi.org Mon Aug 20 02:34:45 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390DA21F86E2 for ; Mon, 20 Aug 2012 02:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC0B8Rgp8TAy for ; Mon, 20 Aug 2012 02:34:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4F721F86DF for ; Mon, 20 Aug 2012 02:34:44 -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 q7K9YXdH012554 for ; Mon, 20 Aug 2012 11:34:36 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 431EF283 for ; Mon, 20 Aug 2012 11:34:33 +0200 (CEST) Received: by pbbrr4 with SMTP id rr4so7011998pbb.31 for ; Mon, 20 Aug 2012 02:34:31 -0700 (PDT) Received: by 10.68.238.166 with SMTP id vl6mr32401560pbc.96.1345455271270; Mon, 20 Aug 2012 02:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.16.42 with HTTP; Mon, 20 Aug 2012 02:34:11 -0700 (PDT) In-Reply-To: <502C6564.1060400@toshiba.co.jp> References: <201208130522.q7D5MLmk021041@toshiba.co.jp> <201208130955.q7D9tkSE016137@toshiba.co.jp> <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> <502C6564.1060400@toshiba.co.jp> From: Klaus Hartke Date: Mon, 20 Aug 2012 12:34:11 +0300 Message-ID: To: Yusuke DOI Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org" Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 09:34:45 -0000 Yusuke DOI wrote: > If it's not too late, I'll write up some proposal draft(s) for arbtrary > parameter option (by number and by string). I think it would be a good idea to explore this a bit. Maybe don't go into details yet, just describe the the problem, give a few motivating examples, and outline your solution. Doesn't have to be a draft if it's not too long. Klaus From mcr@sandelman.ca Mon Aug 20 07:09:47 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A047D21F867A for ; Mon, 20 Aug 2012 07:09:47 -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.973, BAYES_20=-0.74, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiIuXq6BoHwU for ; Mon, 20 Aug 2012 07:09:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0A72F21F8678 for ; Mon, 20 Aug 2012 07:09:41 -0700 (PDT) Received: from sandelman.ca (24-139-16-154.eastlink.ca [24.139.16.154]) by relay.sandelman.ca (Postfix) with ESMTPS id 387D58658 for ; Mon, 20 Aug 2012 10:04:33 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BC3EACA0D0 for ; Mon, 20 Aug 2012 09:58:24 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 20 Aug 2012 09:58:24 -0400 Message-ID: <2905.1345471104@sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Mon, 20 Aug 2012 08:02:22 -0700 Subject: [core] Blockwise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 14:09:47 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I was reading draft-borman-core-coap-block-08. I find that I'm having difficulty understanding the why of this. A claim is made that this protocol reduces all server state (and I guess, moves this to the client). The argument is made that this is useful for things like firmware updates. I'm trying to understand this: for this to be useful, the machine being updated (receiving the new firmware) would have to be the server. I'm trying to understand coap-block in comparison to a) running TCP with minimal window-size (which Contiki does just fine) b) TFTP It seems to me that the major advantage of CoAP block protocol is that it reuses the CoAP code, but how much? What I'm wondering is, if TCP does not fit, does the CoAP block mode client side state fit? For the firmware upload use case situation, where all the complexity is on the maintenance machine doing the upload (a laptop or other non-constrained gateway), and the sensor has enough ram and/or flash to double buffer the upload. and CRC/check-signature the entire amount.. this method, seems to work just fine. But all the machines I've worked on recently that had the double-buffer space for firmware uploads, did just fine with an HTTP POST over TCP... The examples include a POST to /soap, with a multi-packet reply. (some implication that SOAP might be in use...) =2D-=20 Michael Richardson =2Dat the cottage- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQMkJ/AAoJEKD0KQ7Gj3P2KeYH/RSwlUOppetuI4bHiri25kyh 4pm3cMCRkgVvZxDn9fp2tCAB3gIUVRcWvg4p7otkFpGQt55ibYsdf4yZYS9yK9E1 zI1lbjcjdcCg57CUvkviLI1tPp2/DtHOpqHNNifXOnJkfp6uxhMHHTtG2D5sPWhm aIr7EBceYrAfciqdv87fDz9jCWPbhylIWiv8GLaQ+UJKB9VGRz4MNc5hwlENfTJk cRL6Fc5Ff3IN3X1bYC6HV36KNoUMfzDGL7X9ttRl5e/RIoSWeeZNU89+KUhoL8zB IDqxFrZddErDa7qEp1Ccn3R6w/TKMCfrQrnUZGvGn9gQzXUmIa1lmOdBskpZK3Y= =71W2 -----END PGP SIGNATURE----- --=-=-=-- From cabo@tzi.org Mon Aug 20 08:15:13 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA23F21F8646 for ; Mon, 20 Aug 2012 08:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNJf4cGVF6b6 for ; Mon, 20 Aug 2012 08:15:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 12D7A21F85D5 for ; Mon, 20 Aug 2012 08:15:12 -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 q7KFExSx023810; Mon, 20 Aug 2012 17:15:00 +0200 (CEST) Received: from [192.168.20.20] (m83-178-86-12.cust.tele2.lt [83.178.86.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9AE494AF; Mon, 20 Aug 2012 17:14:59 +0200 (CEST) References: <2905.1345471104@sandelman.ca> In-Reply-To: <2905.1345471104@sandelman.ca> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPod Mail (9B206) From: Carsten Bormann Date: Mon, 20 Aug 2012 18:14:55 +0300 To: Michael Richardson Cc: "core@ietf.org" Subject: Re: [core] Blockwise transfers in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 15:15:14 -0000 The reduction in server state is most pronounced for blockwise access to lar= ge resources via GET. The main application for class-1 devices is likely to= be enabling access to the resource description. Block1 (the support for PU= T/POST) is mostly there for symmetry; I'd expect this to be implemented less= than Block2 (GET support); but there even is a stateless PUT if you need it= . I trust you haven't looked at TFTP too recently; this is a terrible proto= col. Most of what you say points out that, indeed, the editorial rewrite is n= eeded. Sent from Mobile On 20.08.2012, at 16:58, Michael Richardson wrote: >=20 > I was reading draft-borman-core-coap-block-08. > I find that I'm having difficulty understanding the why of this. >=20 > A claim is made that this protocol reduces all server state (and I > guess, moves this to the client). The argument is made that this is > useful for things like firmware updates. >=20 > I'm trying to understand this: for this to be useful, the machine > being updated (receiving the new firmware) would have to be the > server. >=20 > I'm trying to understand coap-block in comparison to > a) running TCP with minimal window-size (which Contiki > does just fine) > b) TFTP >=20 > It seems to me that the major advantage of CoAP block protocol is that > it reuses the CoAP code, but how much? What I'm wondering is, if > TCP does not fit, does the CoAP block mode client side state fit? >=20 > For the firmware upload use case situation, where all the complexity is > on the maintenance machine doing the upload (a laptop or other > non-constrained gateway), and the sensor has enough ram and/or flash to > double buffer the upload. and CRC/check-signature the entire amount.. > this method, seems to work just fine. But all the machines I've worked > on recently that had the double-buffer space for firmware uploads, > did just fine with an HTTP POST over TCP... >=20 > The examples include a POST to /soap, with a multi-packet reply. > (some implication that SOAP might be in use...) >=20 > --=20 > Michael Richardson > -at the cottage- > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From yusuke.doi@toshiba.co.jp Tue Aug 21 21:48:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8651021F853E for ; Tue, 21 Aug 2012 21:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXwrPxFgP5Hy for ; Tue, 21 Aug 2012 21:48:23 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFFF21F853A for ; Tue, 21 Aug 2012 21:48:22 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7M4mKBU017139 for ; Wed, 22 Aug 2012 13:48:20 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7M4mKDY005305 for core@ietf.org; Wed, 22 Aug 2012 13:48:20 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id PAA05304; Wed, 22 Aug 2012 13:48:20 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7M4mJb8015388 for ; Wed, 22 Aug 2012 13:48:20 +0900 (JST) Received: by toshiba.co.jp id q7M4mJct004238; Wed, 22 Aug 2012 13:48:19 +0900 (JST) Date: Wed, 22 Aug 2012 13:48:19 +0900 (JST) Message-Id: <201208220448.q7M4mJct004238@toshiba.co.jp> To: hartke@tzi.org From: DOI Yusuke In-Reply-To: References: <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> <502C6564.1060400@toshiba.co.jp> X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 04:48:24 -0000 Hi Klaus, and all, As a weekend work, I wrote a draft and just submitted as proposal to solve parameter problem in some use cases. (including my EXI content/schema negotiation) > Title : CoAP Option Parameter Option > Author(s) : Yusuke Doi > Filename : draft-doi-core-parameter-option-00.txt > Pages : 7 > Date : 2012-08-21 Any comments are appriciated. A trick is to make three options with identical functionarity (Parameter-Option 1, 2, 3). This is because parameter options need index to another option, and calculation of option index could be dirty code if the parameter option is before the other option. I think there was rough agreement to make three partitions of option number in the last F2F, I made a parameter option per partition. A concern is to have complex data type (1-octet integer, 2-octet integer, string). I don't know other options with complex type. Is there any reason to avoid it? Regards, // Yusuke DOI , TOSHIBA R&D Center From: Klaus Hartke Subject: Re: [core] A question on handling of option parameters defined in HTTP Date: Mon, 20 Aug 2012 12:34:11 +0300 > Yusuke DOI wrote: > > If it's not too late, I'll write up some proposal draft(s) for arbtrary > > parameter option (by number and by string). > > I think it would be a good idea to explore this a bit. Maybe don't go > into details yet, just describe the the problem, give a few motivating > examples, and outline your solution. Doesn't have to be a draft if > it's not too long. > > > Klaus From esko.dijk@philips.com Wed Aug 22 02:55:58 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0E221F854F for ; Wed, 22 Aug 2012 02:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU7twsdgGR1o for ; Wed, 22 Aug 2012 02:55:54 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6C18521F854C for ; Wed, 22 Aug 2012 02:55:54 -0700 (PDT) Received: from mail113-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 Aug 2012 09:55:53 +0000 Received: from mail113-ch1 (localhost [127.0.0.1]) by mail113-ch1-R.bigfish.com (Postfix) with ESMTP id 80E494600E0; Wed, 22 Aug 2012 09:55:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -40 X-BigFish: VPS-40(zz217bL15d6O9251J542M1dbaI14ffIzz1202hzz1033IL8275dhz2dh2a8h668h839hd25hf0ah107ah) Received: from mail113-ch1 (localhost.localdomain [127.0.0.1]) by mail113-ch1 (MessageSwitch) id 1345629351695946_15312; Wed, 22 Aug 2012 09:55:51 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail113-ch1.bigfish.com (Postfix) with ESMTP id A7A9C140062; Wed, 22 Aug 2012 09:55:51 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 Aug 2012 09:55:51 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 22 Aug 2012 10:55:28 +0100 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.194]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.02.0309.003; Wed, 22 Aug 2012 10:55:28 +0100 From: "Dijk, Esko" To: Bert Greevenbosch Thread-Topic: Upload of draft for "BlockMinimumTime" option Thread-Index: Ac1dlXIgejAMynRjREWUOXSbOxYSAACbF9TAAMc+kbAHS0690A== Date: Wed, 22 Aug 2012 09:55:27 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AD5957@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB62905EDFF@szxeml509-mbs> <031DD135F9160444ABBE3B0C36CED618A9D191@011-DB3MPN2-082.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB62906EC0C@szxeml509-mbs> In-Reply-To: <46A1DF3F04371240B504290A071B4DB62906EC0C@szxeml509-mbs> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Upload of draft for "BlockMinimumTime" option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 09:55:58 -0000 Thanks Bert, this motivation would be useful to have in the draft; it's clear to me. Esko -----Original Message----- From: Bert Greevenbosch [mailto:Bert.Greevenbosch@huawei.com]=20 Sent: Monday 16 July 2012 9:20 To: Dijk, Esko; core@ietf.org Subject: RE: Upload of draft for "BlockMinimumTime" option Hello Esko, Thank you for your comments. > I miss a motivation (or use cases) in this draft why BlockMinimumTime is = needed and why other approaches are not good enough. > E.g., the server can just wait 200 or 300 ms (times from Examples section= 7) before sending its response to the client achieving similar congestion = control and overload prevention. I think the main use case is for the server to be able to control the amoun= t of requests it receives within a time period, thereby achieving better us= age of its internal resources (memory, processor load, message buffers, etc= .) and increasing reliability in responding to requests. I think the server should perform open work as quickly as it can. That mean= s, that if it has a response to a request available, it should send that re= sponse as soon as feasible. Waiting 200 or 300ms to slow down the client re= quires the server to maintain that response for 200 to 300ms, occupying res= ources that could have been used to handle requests from other clients inst= ead. So although the delayed response solution indeed reduces the client's = speed, it only does a partial job in resolving server overload congestion. If however the server can explicitly signal the client's speed, then it doe= s not to keep track of its own minimum time to respond to each request, and= can handle requests as soon as possible, releasing its resources for other= tasks sooner. This will benefit the whole system, as all clients have a be= tter probability that their requests get handled and receive responses, whe= reas the server can fine-tune the requests to optimally use its resources. What do you think? Best regards, Bert From: Dijk, Esko [mailto:esko.dijk@philips.com]=20 Sent: 12 July 2012 15:47 To: Bert Greevenbosch; core@ietf.org Subject: RE: Upload of draft for "BlockMinimumTime" option Hello Bert, =A0 I miss a motivation (or use cases) in this draft why BlockMinimumTime is ne= eded and why other approaches are not good enough. E.g., the server can just wait 200 or 300 ms (times from Examples section 7= ) before sending its response to the client achieving similar congestion co= ntrol and overload prevention. =A0 regards, Esko =A0 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ber= t Greevenbosch Sent: Monday 9 July 2012 7:41 To: core@ietf.org Subject: [core] Upload of draft for "BlockMinimumTime" option =A0 Hello all, =A0 I have just upload a draft that defines the "BlockMinimumTime" option: http://datatracker.ietf.org/doc/draft-greevenbosch-core-block-minimum-time =A0 The option allows the server and client to negotiate the speed in which the= client sends requests in a block transaction. =A0 Comments are welcome! =A0 Best regards, Bert ________________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From Bert.Greevenbosch@huawei.com Wed Aug 22 18:38:04 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7579421F84E2 for ; Wed, 22 Aug 2012 18:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI998iAn1hxj for ; Wed, 22 Aug 2012 18:38:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7753621F84D3 for ; Wed, 22 Aug 2012 18:38:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJW01112; Wed, 22 Aug 2012 17:38:00 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 18:31:28 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 18:31:26 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 23 Aug 2012 09:31:20 +0800 From: Bert Greevenbosch To: DOI Yusuke , "hartke@tzi.org" Thread-Topic: [core] A question on handling of option parameters defined in HTTP Thread-Index: AQHNgCFoaRd9iaGmXUO6VLgG8V5NDJdmlvqQ Date: Thu, 23 Aug 2012 01:31:19 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB6290BAE52@szxeml509-mbs> References: <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> <502C6564.1060400@toshiba.co.jp> <201208220448.q7M4mJct004238@toshiba.co.jp> In-Reply-To: <201208220448.q7M4mJct004238@toshiba.co.jp> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 01:38:04 -0000 Hi Yuseke, all, I have reviewed your "draft-doi-core-parameter-option" document. I realise = that this idea still needs to ripen, so I hope the following questions can = help getting a clearer view on the proposed mechanism: (1) In section 2.2, the server can accept any rate, whereas the client chos= e the rate 32500 and signals it through the content-type. How did the serve= r indicate the acceptable rates to the client? (2) In the other direction, how can the client indicate acceptable paramete= rs to the server? (3) What is the rationale behind the "oid" field? I understand that it is f= or indexing the option-parameters. Does that mean that a content-type "some= /content-type;par1=3D8;par2=3D9" would have two "Option-Parameter" options,= in which the one for par1 has "oidx=3D0" and par2 "oix=3D1"? (4) For the "value" field, I guess you propose to use a text string with th= e same content as the "value" field from RFC 2045? (5) Why do you define 3 "Option-Parameter" options? What is the related imp= lementation complexity, and how does having three separate options resolve = it? (6) To avoid confusion with CoAP options, would it be helpful to rename "Op= tion-Parameter" to "ContentType-Parameter"? I see value in content type parameters, especially as HTTP already supports= a similar mechanism. So I look forward to discuss more about how this coul= d be reflected by CoAP. Best regards, Bert --- Bert Greevenbosch M.Sc. Senior Research and Standardisation Engineer email: bert.greevenbosch@huawei.com telephone: +86-755-28978760 HUAWEI TECHNOLOGIES CO.,LTD. Building F1 / Floor 8 Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China ***************************************************************************= **** This email and its attachments contain confidential information from HUAWEI= , which is intended only for the person or entity whose address is listed a= bove. Any use of the information contained here in any way (including, but = not limited to, total or partial disclosure, reproduction, or dissemination= ) by persons other than the intended recipient(s) is prohibited. If you rec= eive this email in error, please notify the sender by phone or email immedi= ately and delete it! ***************************************************************************= *** -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of DOI= Yusuke Sent: 22 August 2012 12:48 To: hartke@tzi.org Cc: core@ietf.org Subject: Re: [core] A question on handling of option parameters defined in = HTTP Hi Klaus, and all, As a weekend work, I wrote a draft and just submitted as proposal to solve parameter problem in some use cases. (including my EXI content/schema negotiation) > Title : CoAP Option Parameter Option > Author(s) : Yusuke Doi > Filename : draft-doi-core-parameter-option-00.txt > Pages : 7 > Date : 2012-08-21 Any comments are appriciated.=20 A trick is to make three options with identical functionarity (Parameter-Option 1, 2, 3). This is because parameter options need index to another option, and calculation of option index could be dirty code if the parameter option is before the other option. I think there was rough agreement to make three partitions of option number in the last F2F, I made a parameter option per partition. A concern is to have complex data type (1-octet integer, 2-octet integer, string). I don't know other options with complex type. Is there any reason to avoid it? Regards, // Yusuke DOI , TOSHIBA R&D Center From: Klaus Hartke Subject: Re: [core] A question on handling of option parameters defined in = HTTP Date: Mon, 20 Aug 2012 12:34:11 +0300 > Yusuke DOI wrote: > > If it's not too late, I'll write up some proposal draft(s) for arbtrary > > parameter option (by number and by string). >=20 > I think it would be a good idea to explore this a bit. Maybe don't go > into details yet, just describe the the problem, give a few motivating > examples, and outline your solution. Doesn't have to be a draft if > it's not too long. >=20 >=20 > Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From yusuke.doi@toshiba.co.jp Thu Aug 23 00:21:38 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA0C11E80C5 for ; Thu, 23 Aug 2012 00:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=-1.324, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAyair2BF28O for ; Thu, 23 Aug 2012 00:21:37 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 78F0C11E808A for ; Thu, 23 Aug 2012 00:21:37 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7N7Latf019037 for ; Thu, 23 Aug 2012 16:21:36 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7N7LZMR004888 for core@ietf.org; Thu, 23 Aug 2012 16:21:35 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id SAA04886; Thu, 23 Aug 2012 16:21:35 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7N7LZxo002657 for ; Thu, 23 Aug 2012 16:21:35 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q7N7LZkb014026; Thu, 23 Aug 2012 16:21:35 +0900 (JST) Received: from [133.196.16.83] (ncg-dhcp83.isl.rdc.toshiba.co.jp [133.196.16.83]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 79E4B97CE7; Thu, 23 Aug 2012 16:21:35 +0900 (JST) Message-ID: <5035D9FE.4050602@toshiba.co.jp> Date: Thu, 23 Aug 2012 16:21:34 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bert Greevenbosch , "core@ietf.org" References: <46A1DF3F04371240B504290A071B4DB62908135F@szxeml509-mbs> <502C6564.1060400@toshiba.co.jp> <201208220448.q7M4mJct004238@toshiba.co.jp> <46A1DF3F04371240B504290A071B4DB6290BAE52@szxeml509-mbs> In-Reply-To: <46A1DF3F04371240B504290A071B4DB6290BAE52@szxeml509-mbs> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] A question on handling of option parameters defined in HTTP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 07:21:38 -0000 Hi Bert, Thanks for your review. > (1) In section 2.2, the server can accept any rate, whereas the client chose the rate 32500 and signals it through the content-type. How did the server indicate the acceptable rates to the client? This (server-to-client node/resource capability notification) is beyond the scope of this document. In (only) HTTP, I guess no standard way is defined. The client may try to POST rate 32500 anyway to find it is acceptable or not. If an application uses DNS-SD, the TXT RR could be good place to describe server capability. In CoAP, I guess it could be done with the link format. I've heard Kerry is working on the issue (draft-lynn-core-discovery-mapping). > (2) In the other direction, how can the client indicate acceptable parameters to the server? Client can send Accept option with appropriate parameteras it sends GET request to the server. > (3) What is the rationale behind the "oid" field? I understand that it is for indexing the option-parameters. Does that mean that a content-type "some/content-type;par1=8;par2=9" would have two "Option-Parameter" options, in which the one for par1 has "oidx=0" and par2 "oix=1"? It's index of the option in the CoAP message. A CoAP message may have the following options: CON GET [0]Uri-Host: "example.org" [1]Uri-Port: 15683 [2]Uri-Path: "example.exi" [3]Accept: example-exi (is an imagenary content-type for an example application with schema-informed EXI encoding) [4]Accept: example+json (same as above, with JSON) [5]Option-Parameter1: 3,9,"5" (aid=9 means "level") [6]Option-Parameter1: 4,2,"0.8" (aid=2 means "version") In the first Option-Parameter1, its oidx=3. This parameter is for the option with index [3]. This is Accept: example-exi;level=5 The second one is Accept: example+json;version=0.8 Since this index is fragile to option add/remove, this is not a proxy-safe option. > (4) For the "value" field, I guess you propose to use a text string with the same content as the "value" field from RFC 2045? I guess UTF-8 should be 'modern way'. I have no strong opinion on it. It could be RFC2045-style, UTF-8 string, and opaque octets. (let me change the order of your question) > (6) To avoid confusion with CoAP options, would it be helpful to rename "Option-Parameter" to "ContentType-Parameter"? I agree. At first, I have been thinking the parameter is also usable for other options. But while thinking through your review, I noticed it's confusing to have generic option parameters because the same semantics could be expressed in different manner in CoAP options. For example, content preference among multiple Accept-able content type is described by the order of options. It may be harmful to have "q" parameter (the same semantics in HTTP) to CoAP. > (5) Why do you define 3 "Option-Parameter" options? What is the related implementation complexity, and how does having three separate options resolve it? This is because I didn't want adding a parameter BEFORE its target. The oidx of Option-Parameter points another option ('target') by the order in the packet. If I need to put parameter options before the target, I need to wait for the header building process to decide the oidx field. However, as I agreed on (6), if this option only points to Content-Type and Accept header, a option number larger than Accept option is enough. Or, separate option for parameter of Content-Type and parameter of Accept could be a good idea because Content-Type does not need oidx. Regards, // Yusuke DOI Corporate R&D Center, TOSHIBA Corp. (2012-08-23 10:31), Bert Greevenbosch wrote: > Hi Yuseke, all, > > I have reviewed your "draft-doi-core-parameter-option" document. I realise that this idea still needs to ripen, so I hope the following questions can help getting a clearer view on the proposed mechanism: > > (1) In section 2.2, the server can accept any rate, whereas the client chose the rate 32500 and signals it through the content-type. How did the server indicate the acceptable rates to the client? > > (2) In the other direction, how can the client indicate acceptable parameters to the server? > > (3) What is the rationale behind the "oid" field? I understand that it is for indexing the option-parameters. Does that mean that a content-type "some/content-type;par1=8;par2=9" would have two "Option-Parameter" options, in which the one for par1 has "oidx=0" and par2 "oix=1"? > > (4) For the "value" field, I guess you propose to use a text string with the same content as the "value" field from RFC 2045? > > (5) Why do you define 3 "Option-Parameter" options? What is the related implementation complexity, and how does having three separate options resolve it? > > (6) To avoid confusion with CoAP options, would it be helpful to rename "Option-Parameter" to "ContentType-Parameter"? > > I see value in content type parameters, especially as HTTP already supports a similar mechanism. So I look forward to discuss more about how this could be reflected by CoAP. > > Best regards, > Bert > > --- > Bert Greevenbosch M.Sc. > Senior Research and Standardisation Engineer > > email: bert.greevenbosch@huawei.com > telephone: +86-755-28978760 > > HUAWEI TECHNOLOGIES CO.,LTD. > Building F1 / Floor 8 > Huawei Industrial Base > Bantian, Longgang District > Shenzhen 518129 > P.R. China > > ******************************************************************************* > This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! > ****************************************************************************** > > From edashkov@ee.oulu.fi Sun Aug 26 11:31:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD7A21F8516 for ; Sun, 26 Aug 2012 11:31:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnCM5XJfAIHR for ; Sun, 26 Aug 2012 11:31:20 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by ietfa.amsl.com (Postfix) with ESMTP id CA03921F8517 for ; Sun, 26 Aug 2012 11:31:19 -0700 (PDT) Received: from FRUCTKatia (221.119.smolenka.rednet.ru [77.223.119.221] (may be forged)) (authenticated bits=0) by ee.oulu.fi (8.14.4/8.14.4) with ESMTP id q7QIVCxY011517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 26 Aug 2012 21:31:14 +0300 From: "Ekaterina Dashkova" To: Date: Sun, 26 Aug 2012 21:31:10 +0300 Message-ID: <003101cd83b8$f8bd9e90$ea38dbb0$@ee.oulu.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CD83D2.1E0E0AE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2DZfGcMhsW+BP3T4aySeOLuw6aNw== Content-Language: ru Subject: [core] Draft (C. Bormann): CoAP Simple Congestion Control/Advanced X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 18:31:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0032_01CD83D2.1E0E0AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Thank you for the draft, but I would like to propose a number of questions/comments for discussion: 1) I have difficulties to understand sentence: "A client that has arrived at a RTT estimate much shorter than the 2 to 3 s used as a default SHOULD therefore not expend all of its retransmissions in the shorter estimated timescale" - Should it be ". has received a packet ." instead of ". has arrived ." - In part ". RTT estimate much shorter than the 2 to 3 s ." - If we say "much shorter" then just 2s boundary is important for the statement. So I would propose to replace it by just ". much shorter than 2 s ." - Most important - I had difficulties to understand the main point of this sentence. Now it sounds as a self-evident statement, or some important message is missing (i.e., I haven't get it). 2) I had a lot of difficulties to understand proposal on blind RTO estimation, i.e. in the sentence "Up to four (4) exchanges to an endpoint can be started in parallel. If only the initial RTO estimate is available, the RTO estimate for each exchange started in parallel to other exchanges is set to the highest binary multiple of the parallel exchanges, e.g., if another exchange is already running and is into its second retransmission, the RTO estimate for the additional exchange is 8 seconds." - The provided description is a bit fuzzy (e.g. could we take the number itself as a highest multiplier, as formally mathematically it can be the case), so I would propose to replace the description by formula and set of formal rules. Also there is a number of small spelling errors. Could we agree a process to report such issues? Best wishes, Ekaterina Dashkova ------=_NextPart_000_0032_01CD83D2.1E0E0AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

  Thank you for the draft, but I would like to propose = a number of questions/comments for discussion:

1)      = I have difficulties to = understand sentence: “A client that has arrived at a RTT estimate = much shorter = than the 2 to 3 s used as a default SHOULD therefore not expend all of its retransmissions in = the shorter estimated timescale” = 

-   =
Should it =
be “… has received a packet …” instead of =
“… has arrived …”
-   =
In part =
“… RTT estimate much shorter than the 2 to 3 s =
…” - If we say “much shorter” then just 2s =
boundary is important for the statement. So I would propose to replace =
it by just “… much shorter than 2 s =
…”
-   =
Most =
important – I had difficulties to understand the main point of =
this sentence. Now it sounds as a self-evident statement, or some =
important message is missing (i.e., I haven’t get =
it).
 =

2)      =
I had a =
lot of difficulties to understand proposal on blind RTO estimation, i.e. =
in the sentence “Up to four (4) exchanges to an endpoint can be =
started in parallel. If only the initial RTO estimate is available, the =
RTO estimate for each exchange started in parallel to other exchanges is =
set to the highest binary multiple of the parallel exchanges, e.g., if =
another exchange is already running and is into its second =
retransmission, the RTO estimate for the additional exchange is 8 =
seconds.”
-   =
The =
provided description is a bit fuzzy (e.g. could we take the number =
itself as a highest multiplier, as formally mathematically it can be the =
case), so I would propose to replace the description by formula and set =
of formal rules.
 =

  =
;   Also there is a number of small spelling errors. Could we =
agree a process to report such issues?
 =

Best =
wishes,
Ekaterina =
Dashkova
------=_NextPart_000_0032_01CD83D2.1E0E0AE0-- From esko.dijk@philips.com Thu Aug 30 03:28:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7366921F84D6 for ; Thu, 30 Aug 2012 03:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q89TOY+oAPeZ for ; Thu, 30 Aug 2012 03:28:32 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 19CCD21F84C8 for ; Thu, 30 Aug 2012 03:28:31 -0700 (PDT) Received: from mail120-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 Aug 2012 10:28:30 +0000 Received: from mail120-am1 (localhost [127.0.0.1]) by mail120-am1-R.bigfish.com (Postfix) with ESMTP id AA8521E00D4; Thu, 30 Aug 2012 10:28:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -13 X-BigFish: VPS-13(zz217bL15d6O9251Jc85fhzz1202hzzz2dh2a8h668h839hd25hf0ah107ah1155h) Received: from mail120-am1 (localhost.localdomain [127.0.0.1]) by mail120-am1 (MessageSwitch) id 1346322508961802_5499; Thu, 30 Aug 2012 10:28:28 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.246]) by mail120-am1.bigfish.com (Postfix) with ESMTP id E903A1C0047; Thu, 30 Aug 2012 10:28:28 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 Aug 2012 10:28:26 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 30 Aug 2012 11:28:25 +0100 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.216]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.02.0309.003; Thu, 30 Aug 2012 11:28:25 +0100 From: "Dijk, Esko" To: "core@ietf.org" , Zach Shelby Thread-Topic: draft-shelby-core-resource-directory-04: unclear 'rt' parameter in Update Thread-Index: Ac2Gmi9tY1ioNDD2T6iNoxoWh8Qu2Q== Date: Thu, 30 Aug 2012 10:28:24 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AE2066@011-DB3MPN2-081.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618AE2066011DB3MPN2081MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] draft-shelby-core-resource-directory-04: unclear 'rt' parameter in Update X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 10:28:33 -0000 --_000_031DD135F9160444ABBE3B0C36CED618AE2066011DB3MPN2081MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Zach, all, in section 5.3 (Update) the 'rt' parameter can be specified when doing a PU= T update of registration to Resource Directory. To me it's not clear what t= his parameter would do. The resource types of each resource that is updated= , would be already included in the payload as "rt=3D....." link-format para= meters. I assume it should be removed from the allowed query parameters in = section 5.3? regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618AE2066011DB3MPN2081MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Zach, all,

 

in section 5.3 (Update) the ‘rt’ paramet= er can be specified when doing a PUT update of registration to Resource Dir= ectory. To me it’s not clear what this parameter would do. The resour= ce types of each resource that is updated, would be already included in the payload as “rt=3D.....” link-format pa= rameters. I assume it should be removed from the allowed query parameters i= n section 5.3?

 

regards,

Esko


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618AE2066011DB3MPN2081MGDP_--