From zehn.cao@gmail.com Fri Oct 1 06:07:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52533A6EC2 for ; Fri, 1 Oct 2010 06:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcP1ZPdr7OcX for ; Fri, 1 Oct 2010 06:07:06 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E6D623A6EC8 for ; Fri, 1 Oct 2010 06:07:05 -0700 (PDT) Received: by bwz9 with SMTP id 9so2840929bwz.31 for ; Fri, 01 Oct 2010 06:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G+ErmHmZst6tTLxwR44PMJ73Z/DBM/br4H2pYX5JEsk=; b=rQvqIfFjwy8TOUm/VFtAy4D7ZumlDTHhkUyCEMNQRwX23XJ0HqFvwXiVzaTikWwTG4 IyM+6K4qPltmf9A+IWhn7CHKLBtw9mkK3RSKeuaCxwB1fRooXKkFes+746xMMA3pp7TM EO6sISBAmMa3bfOPU0TIYq/wV5cySRGIRiNJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fnaMNb2ToH0n2zmAPB3BCWBKdTxR7pNmhcGQCmcFq0aqesA793IaVzhqS/qbq7Iio0 vtU0sCsPU5P8+pgg2w6l1acjAlXncp8jCDZeJi7ADWb78ONsSmIQiLFNL1q1Vn5CLG+i tICCzTA80rYGfgNcv3hB8tayZM4Mk8rbTD+Io= MIME-Version: 1.0 Received: by 10.204.124.14 with SMTP id s14mr4085081bkr.21.1285938471992; Fri, 01 Oct 2010 06:07:51 -0700 (PDT) Received: by 10.204.57.8 with HTTP; Fri, 1 Oct 2010 06:07:51 -0700 (PDT) In-Reply-To: <4CA3BB54.8050706@gmail.com> References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> Date: Fri, 1 Oct 2010 21:07:51 +0800 Message-ID: From: Zhen Cao To: Rene Struik Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Fwd: Wed 29, 1500 UTC (Fwd: Meeting invitation: CORE WG) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 13:07:07 -0000 Excuse me to jump into the discussion. I am also interested in HIP/Diet-HIP protocol. In my mind, HIP offers authenticated key exchange via the use of signatures, i.e., the DH exchange is signed and thus authenticated. After the exchange, IPSEC ESP is established and data authentication is achieved via the IPSEC SA. Thanks, Zhen On Thu, Sep 30, 2010 at 6:19 AM, Rene Struik wrote: > Hi Carsten: > > Thanks for the minutes. I just had a quick look and somehow seemed to hav= e > missed during the conf call your reference to the HIP protocol. Could you > elaborate a little bit more? To my knowledge, HIP essentially does epheme= ral > Diffie-Hellman key agreement, thus not offering authenticated key agreeme= nt. > In my mind, authenticated key agreement is essential to trigger data > authentication tied to a unique identifier and allow trust lifecycle > management to be reduced to management of device identities (via use of > certificates). See also the brief summary below. > > Perhaps, we should discuss this somewhat more early next week. > > Best regards, > > Rene > > [summary of old proposal of mine on trust lifecycle management that could= be > used with bootstrapping document] > =A71 Proposal summary > > The proposal encompasses an intuitive, yet secure approach to provisionin= g > and configuration of sensor networks. The approach hides security details > from the user, thus allowing ease of device and network setup and > flexibility of trust lifecycle management, while doing away with security > hassles that have plagued more conventional approaches. > > =A0The proposal uses public-key cryptography, a security technology that > allows reduction of trust lifecycle management to the management of trust= ed > device identities (via so-called certificates), and security policy > enforcement techniques based on lifecycle management of device roles. > > From a user=92s perspective, this results in a system where trusted lifec= ycle > management appears to be the same as that of an unsecured network: it sim= ply > comes down to proper identification of devices (e.g., reading off a label= of > a physical module) and proper management of device roles (e.g., adding th= ese > to, resp. removing these from a white list, e.g., via a workstation GUI).= No > secret information is disclosed at any lifecycle stage of a device or a > system, nor needs to be, since management relies completely on handling o= f > public information. This greatly reduces the complexity of lifecycle > management and, thereby, training requirements for operational personnel. > Moreover, it virtually removes trust dependencies between different entit= ies > involved in the value chain, whether OEM, vendor, system integrator, > installer, or user. Lastly, the approach has the benefit of allowing > enforcement of standards compliance (by only issuing a certificate to > devices from vendors that passed conformance testing). > > > > On 29/09/2010 5:36 PM, Carsten Bormann wrote: > > On Sep 29, 2010, at 15:33, Carsten Bormann wrote: > > http://6lowapp.net/2010-09-29/ > > ... and the minutes are now also up there. > Please tell me if I have misrepresented anyone. > > At 90 minutes, this was a short and sweet meeting. Thanks to everyone wh= o > participated, and in particular to Markus Becker who at very short notice > volunteered to take notes (all errors in the massaged version are of cour= se > mine). > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > -- > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From rstruik.ext@gmail.com Fri Oct 1 06:57:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7D73A6C9E for ; Fri, 1 Oct 2010 06:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.049 X-Spam-Level: X-Spam-Status: No, score=-4.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtASmMhIKrba for ; Fri, 1 Oct 2010 06:57:20 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 466A83A6C38 for ; Fri, 1 Oct 2010 06:57:20 -0700 (PDT) Received: by yxl31 with SMTP id 31so1391963yxl.31 for ; Fri, 01 Oct 2010 06:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4OdcWz48Moz1bzHFBRTnzZDt+mZoyet7THa3md2KDLI=; b=YrQ2yJjqs1bdeCCR7g1dANC6e7L26w3O2FU+j1Y27G9wLsm1J57IP9kS6oudoATiF0 YhCztwN1T9zETRr6cQCENqBuy2Uz+UPf9m+FP5GziAZiTmCfcTaAmmL31vjXRz88Asvo GFNFbEml3FjnA3xyyi8bdAr6vGAmRTrMMb8DM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MbPCqqKIy/b3c8RsqZFmXAbCTYR6isMwXF6fh0nVMr8AJZmIOlJy8moQKEmt1lP3pN HEpuTz0TDMv1EoIEmaKE3jT2QF29t5d2om1tWdvy7FeIYGv2EfZE83GdAAPtwz9kFXHv 4gYCKCelugh+iGEj4sJeNNpbyC5oRYYyN4zmE= Received: by 10.100.6.2 with SMTP id 2mr520869anf.75.1285941488039; Fri, 01 Oct 2010 06:58:08 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id u14sm1889849ann.20.2010.10.01.06.58.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 Oct 2010 06:58:02 -0700 (PDT) Message-ID: <4CA5E8E0.4030503@gmail.com> Date: Fri, 01 Oct 2010 09:57:52 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Zhen Cao References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: core Subject: Re: [core] Fwd: Wed 29, 1500 UTC (Fwd: Meeting invitation: CORE WG) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 13:57:22 -0000 Hi Zhen: To my knowledge (cf. also Slides 48-51 inter alia of IETF-78 6lowpan slide deck), the HIP-DEX protocol only provides evidence that the communicating parties involved with the key agreement scheme had access to the long-term private key (i.e., key possession), not of their identity. These properties are essentially those offered by the ephemeral Diffie-Hellman (DH) key agreement scheme (which does not provide for authentication of either party involved with the protocol); hence, my reference hereto. Please note that those slides refer to NIST SP 800-56a (Para 6.3.2, Para 6.3.3), which describes C(0,2), i.e., DH using static keys, where key derivation includes use of nonce provided by the initiating party. As such, this does not include the use of signatures. As final notes: (a) the C(0,2) scheme assumes that public keys are tied to identities (cf. Para 6.3.3, l. 1); (b) the scheme does not provide forward secrecy (i.e., compromise of a device may compromise past secrets established with that device [in my mind, an undesirable property for internet of things type devices, which cannot be assumed to have physical protection and may be placed out in the open (e.g., screwed on a garage or street lamp post)]). Best regards, Rene On 01/10/2010 9:07 AM, Zhen Cao wrote: > Excuse me to jump into the discussion. I am also interested in > HIP/Diet-HIP protocol. > > In my mind, HIP offers authenticated key exchange via the use of > signatures, i.e., the DH exchange is signed and thus authenticated. > After the exchange, IPSEC ESP is established and data authentication > is achieved via the IPSEC SA. > > Thanks, > Zhen > > On Thu, Sep 30, 2010 at 6:19 AM, Rene Struik wrote: >> Hi Carsten: >> >> Thanks for the minutes. I just had a quick look and somehow seemed to have >> missed during the conf call your reference to the HIP protocol. Could you >> elaborate a little bit more? To my knowledge, HIP essentially does ephemeral >> Diffie-Hellman key agreement, thus not offering authenticated key agreement. >> In my mind, authenticated key agreement is essential to trigger data >> authentication tied to a unique identifier and allow trust lifecycle >> management to be reduced to management of device identities (via use of >> certificates). See also the brief summary below. >> >> Perhaps, we should discuss this somewhat more early next week. >> >> Best regards, >> >> Rene >> >> [summary of old proposal of mine on trust lifecycle management that could be >> used with bootstrapping document] >> §1 Proposal summary >> >> The proposal encompasses an intuitive, yet secure approach to provisioning >> and configuration of sensor networks. The approach hides security details >> from the user, thus allowing ease of device and network setup and >> flexibility of trust lifecycle management, while doing away with security >> hassles that have plagued more conventional approaches. >> >> The proposal uses public-key cryptography, a security technology that >> allows reduction of trust lifecycle management to the management of trusted >> device identities (via so-called certificates), and security policy >> enforcement techniques based on lifecycle management of device roles. >> >> From a user’s perspective, this results in a system where trusted lifecycle >> management appears to be the same as that of an unsecured network: it simply >> comes down to proper identification of devices (e.g., reading off a label of >> a physical module) and proper management of device roles (e.g., adding these >> to, resp. removing these from a white list, e.g., via a workstation GUI). No >> secret information is disclosed at any lifecycle stage of a device or a >> system, nor needs to be, since management relies completely on handling of >> public information. This greatly reduces the complexity of lifecycle >> management and, thereby, training requirements for operational personnel. >> Moreover, it virtually removes trust dependencies between different entities >> involved in the value chain, whether OEM, vendor, system integrator, >> installer, or user. Lastly, the approach has the benefit of allowing >> enforcement of standards compliance (by only issuing a certificate to >> devices from vendors that passed conformance testing). >> >> >> >> On 29/09/2010 5:36 PM, Carsten Bormann wrote: >> >> On Sep 29, 2010, at 15:33, Carsten Bormann wrote: >> >> http://6lowapp.net/2010-09-29/ >> >> ... and the minutes are now also up there. >> Please tell me if I have misrepresented anyone. >> >> At 90 minutes, this was a short and sweet meeting. Thanks to everyone who >> participated, and in particular to Markus Becker who at very short notice >> volunteered to take notes (all errors in the massaged version are of course >> mine). >> >> Gruesse, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> -- >> email: rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From zehn.cao@gmail.com Fri Oct 1 07:58:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71553A6DF8 for ; Fri, 1 Oct 2010 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GOlO+v1BvRZ for ; Fri, 1 Oct 2010 07:58:27 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8B0B23A6F17 for ; Fri, 1 Oct 2010 07:58:26 -0700 (PDT) Received: by bwz9 with SMTP id 9so2948469bwz.31 for ; Fri, 01 Oct 2010 07:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8lSEWEJlm7eC/Yj1qVYOE3sTeAADPBo/c7hrItkobOQ=; b=fW6VMVA4jxSnkXJP/EBXPwMARXKYUQzQTwJiefpwsfBJeyJAD24BVEaXL+c718a2n2 d3b975/TPB49dzmUYeRKFQ+8mQ0LVMDpjtH67gyJ4iQoUDhE7PBUqZLFKKzupSm6fU7s g/pK6s0wSrw8SmJfArGgfVdbNnmOs+j4LAAXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ldVQ7e5n5SxU6GYWdtGYg9OY0VVKV7140MT4PYpzKDHbgDsXTctDQiFI0ZWi3ofNLN 98CyET0myHuRwckoLbA9mwdguDzM21i51DPYC2hMxtjaRj/ZxBv+LhTMc8Jh1iaZhPCt sOdfTDT2VVuK6eKakh7kmBGh81JJPIe8Ck01o= MIME-Version: 1.0 Received: by 10.204.127.141 with SMTP id g13mr4123641bks.54.1285945152615; Fri, 01 Oct 2010 07:59:12 -0700 (PDT) Received: by 10.204.57.8 with HTTP; Fri, 1 Oct 2010 07:59:12 -0700 (PDT) In-Reply-To: <4CA5E8E0.4030503@gmail.com> References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> Date: Fri, 1 Oct 2010 22:59:12 +0800 Message-ID: From: Zhen Cao To: Rene Struik Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Fwd: Wed 29, 1500 UTC (Fwd: Meeting invitation: CORE WG) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 14:58:30 -0000 On Fri, Oct 1, 2010 at 9:57 PM, Rene Struik wrote: > =A0Hi Zhen: > > To my knowledge (cf. also Slides 48-51 inter alia of IETF-78 6lowpan slid= e > deck), the HIP-DEX protocol only provides evidence that the communicating > parties involved with the key agreement scheme had access to the long-ter= m > private key (i.e., key possession), not of their identity. These properti= es > are essentially those offered by the ephemeral Diffie-Hellman (DH) key > agreement scheme (which does not provide for authentication of either par= ty > involved with the protocol); hence, my reference hereto. I was based on draft-moskowitz-hip-rg-dex-02, section 4.1. On page 8, the HIP diet exchange I2 and R2 include a computed MAC, I think it is used for authentication of either party. The full capability HIP is able to do the authenticated key exchange, your concern is that current Diet-HIP cannot do that? If so, we can input this as a requirement for Diet-HIP while it is not so closed to an RFC. Thanks, Zhen > > Please note that those slides refer to NIST SP 800-56a (Para 6.3.2, Para > 6.3.3), which describes C(0,2), i.e., DH using static keys, where key > derivation includes use of nonce provided by the initiating party. As suc= h, > this does not include the use of signatures. As final notes: (a) the C(0,= 2) > scheme assumes that public keys are tied to identities (cf. Para 6.3.3, l= . > 1); (b) the scheme does not provide forward secrecy (i.e., compromise of = a > device may compromise past secrets established with that device [in my mi= nd, > an undesirable property for internet of things type devices, which cannot= be > assumed to have physical protection and may be placed out in the open (e.= g., > screwed on a garage or street lamp post)]). I will check with the NIST document and come back soon. > > Best regards, Rene > > > On 01/10/2010 9:07 AM, Zhen Cao wrote: >> >> Excuse me to jump into the discussion. I am also interested in >> HIP/Diet-HIP protocol. >> >> In my mind, HIP offers authenticated key exchange via the use of >> signatures, i.e., the DH exchange is signed and thus authenticated. >> After the exchange, IPSEC ESP is established and data authentication >> is achieved via the IPSEC SA. >> >> Thanks, >> Zhen >> >> On Thu, Sep 30, 2010 at 6:19 AM, Rene Struik >> =A0wrote: >>> >>> Hi Carsten: >>> >>> Thanks for the minutes. I just had a quick look and somehow seemed to >>> have >>> missed during the conf call your reference to the HIP protocol. Could y= ou >>> elaborate a little bit more? To my knowledge, HIP essentially does >>> ephemeral >>> Diffie-Hellman key agreement, thus not offering authenticated key >>> agreement. >>> In my mind, authenticated key agreement is essential to trigger data >>> authentication tied to a unique identifier and allow trust lifecycle >>> management to be reduced to management of device identities (via use of >>> certificates). See also the brief summary below. >>> >>> Perhaps, we should discuss this somewhat more early next week. >>> >>> Best regards, >>> >>> Rene >>> >>> [summary of old proposal of mine on trust lifecycle management that cou= ld >>> be >>> used with bootstrapping document] >>> =A71 Proposal summary >>> >>> The proposal encompasses an intuitive, yet secure approach to >>> provisioning >>> and configuration of sensor networks. The approach hides security detai= ls >>> from the user, thus allowing ease of device and network setup and >>> flexibility of trust lifecycle management, while doing away with securi= ty >>> hassles that have plagued more conventional approaches. >>> >>> =A0The proposal uses public-key cryptography, a security technology tha= t >>> allows reduction of trust lifecycle management to the management of >>> trusted >>> device identities (via so-called certificates), and security policy >>> enforcement techniques based on lifecycle management of device roles. >>> >>> =A0From a user=92s perspective, this results in a system where trusted >>> lifecycle >>> management appears to be the same as that of an unsecured network: it >>> simply >>> comes down to proper identification of devices (e.g., reading off a lab= el >>> of >>> a physical module) and proper management of device roles (e.g., adding >>> these >>> to, resp. removing these from a white list, e.g., via a workstation GUI= ). >>> No >>> secret information is disclosed at any lifecycle stage of a device or a >>> system, nor needs to be, since management relies completely on handling >>> of >>> public information. This greatly reduces the complexity of lifecycle >>> management and, thereby, training requirements for operational personne= l. >>> Moreover, it virtually removes trust dependencies between different >>> entities >>> involved in the value chain, whether OEM, vendor, system integrator, >>> installer, or user. Lastly, the approach has the benefit of allowing >>> enforcement of standards compliance (by only issuing a certificate to >>> devices from vendors that passed conformance testing). >>> >>> >>> >>> On 29/09/2010 5:36 PM, Carsten Bormann wrote: >>> >>> On Sep 29, 2010, at 15:33, Carsten Bormann wrote: >>> >>> =A0 =A0 =A0http://6lowapp.net/2010-09-29/ >>> >>> ... and the minutes are now also up there. >>> Please tell me if I have misrepresented anyone. >>> >>> At 90 minutes, this was a short and sweet meeting. =A0Thanks to everyon= e >>> who >>> participated, and in particular to Markus Becker who at very short noti= ce >>> volunteered to take notes (all errors in the massaged version are of >>> course >>> mine). >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> -- >>> email: rstruik.ext@gmail.com >>> Skype: rstruik >>> cell: +1 (647) 867-5658 >>> USA Google voice: +1 (415) 690-7363 >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> > > > -- > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > From rstruik.ext@gmail.com Fri Oct 1 09:16:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF2D3A6DAC for ; Fri, 1 Oct 2010 09:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDnMdOtBXYg1 for ; Fri, 1 Oct 2010 09:15:58 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 1B95F3A6F28 for ; Fri, 1 Oct 2010 09:15:58 -0700 (PDT) Received: by qyk2 with SMTP id 2so4053014qyk.10 for ; Fri, 01 Oct 2010 09:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=AucjGPwGfSeQqThkRzVGCEnFgaWD3NIkCJ60hPlv5KQ=; b=pWzC/SBVuRw/hE0Qe3ok3MVmWZVZu9oCa4vyMcL6sX5L7ffgnSHAABHEbcHcuTFW5z PfrFbCZnI9EqWzfSG86RN6GcpW/Fd8NPx5X03R2DgJl4wzA7ljglC2rWT3WMkqeY/Ty5 dQX+aPly7PkhF83GKU97BBp5V0zS5Lvy4DEyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WRUKe4g0VpUqtbFiSKB77goCnferFYvvUs0hL5nhJVSTrFhDMik3qBmlV1fOaPrdlg L72xTcfbCHsDbQsdG4mnDr+0s4MhlsrOsg+vYs/2HwyaW1ueIiipxxXtvNTldIgWkV0p XIXDJLecvhZQAcJMnCQBmwrqhODtJMI5UA3z0= Received: by 10.220.125.38 with SMTP id w38mr1274925vcr.93.1285949805853; Fri, 01 Oct 2010 09:16:45 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id m4sm1032650vbp.16.2010.10.01.09.16.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 Oct 2010 09:16:44 -0700 (PDT) Message-ID: <4CA6095F.6040403@gmail.com> Date: Fri, 01 Oct 2010 12:16:31 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Zhen Cao References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: core Subject: Re: [core] Fwd: Wed 29, 1500 UTC (Fwd: Meeting invitation: CORE WG) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 16:16:00 -0000 Hi Zhen: I have some trouble understanding the internet draft draft-moskowitz-hip-rg-dex-02 that you refer to, perhaps due to my difficulty in separating presumed cryptographic steps in the key agreement scheme from "puzzle element" steps presumably aimed at thwarting Denial of Service attacks. From what I do understand, though, identities are a function of the long-term public key (witness also Section 3.2 of draft-ietf-hip-rfc5201-bis-02, which forementioned HIP-DEX draft presumes familiarity with). If so, pragmatically, identities are public keys and, thereby, would change depending on key lifecycle considerations. In my mind, this seems a no-go to get mass-scale deployment from the ground. BTW (not relevant to authentication topic) - It is not immediately clear whether the "puzzle" presented from responder to initiator (Puzzle is to compute J so that x:=CMAC_I ( Id_A || Id_B || J) has a pre-fixed pattern on K bit positions) does not allow for "shortcuts", thus allowing its solution with expenditure of far less than 2^K trial-and-error computing rounds. Can't one do a meet-in-the-middle type of attack here? Anyway, not directly relevant to the authentication question at hand (although perhaps adding to confusion). To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help! In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.). Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines). Rene On 01/10/2010 10:59 AM, Zhen Cao wrote: > On Fri, Oct 1, 2010 at 9:57 PM, Rene Struik wrote: >> Hi Zhen: >> >> To my knowledge (cf. also Slides 48-51 inter alia of IETF-78 6lowpan slide >> deck), the HIP-DEX protocol only provides evidence that the communicating >> parties involved with the key agreement scheme had access to the long-term >> private key (i.e., key possession), not of their identity. These properties >> are essentially those offered by the ephemeral Diffie-Hellman (DH) key >> agreement scheme (which does not provide for authentication of either party >> involved with the protocol); hence, my reference hereto. > I was based on draft-moskowitz-hip-rg-dex-02, section 4.1. On page 8, > the HIP diet exchange I2 and R2 include a computed MAC, I think it is > used for authentication of either party. > > The full capability HIP is able to do the authenticated key exchange, > your concern is that current Diet-HIP cannot do that? If so, we can > input this as a requirement for Diet-HIP while it is not so closed to > an RFC. > > Thanks, > Zhen > >> Please note that those slides refer to NIST SP 800-56a (Para 6.3.2, Para >> 6.3.3), which describes C(0,2), i.e., DH using static keys, where key >> derivation includes use of nonce provided by the initiating party. As such, >> this does not include the use of signatures. As final notes: (a) the C(0,2) >> scheme assumes that public keys are tied to identities (cf. Para 6.3.3, l. >> 1); (b) the scheme does not provide forward secrecy (i.e., compromise of a >> device may compromise past secrets established with that device [in my mind, >> an undesirable property for internet of things type devices, which cannot be >> assumed to have physical protection and may be placed out in the open (e.g., >> screwed on a garage or street lamp post)]). > I will check with the NIST document and come back soon. > >> Best regards, Rene >> >> >> On 01/10/2010 9:07 AM, Zhen Cao wrote: >>> Excuse me to jump into the discussion. I am also interested in >>> HIP/Diet-HIP protocol. >>> >>> In my mind, HIP offers authenticated key exchange via the use of >>> signatures, i.e., the DH exchange is signed and thus authenticated. >>> After the exchange, IPSEC ESP is established and data authentication >>> is achieved via the IPSEC SA. >>> >>> Thanks, >>> Zhen >>> >>> On Thu, Sep 30, 2010 at 6:19 AM, Rene Struik >>> wrote: >>>> Hi Carsten: >>>> >>>> Thanks for the minutes. I just had a quick look and somehow seemed to >>>> have >>>> missed during the conf call your reference to the HIP protocol. Could you >>>> elaborate a little bit more? To my knowledge, HIP essentially does >>>> ephemeral >>>> Diffie-Hellman key agreement, thus not offering authenticated key >>>> agreement. >>>> In my mind, authenticated key agreement is essential to trigger data >>>> authentication tied to a unique identifier and allow trust lifecycle >>>> management to be reduced to management of device identities (via use of >>>> certificates). See also the brief summary below. >>>> >>>> Perhaps, we should discuss this somewhat more early next week. >>>> >>>> Best regards, >>>> >>>> Rene >>>> >>>> [summary of old proposal of mine on trust lifecycle management that could >>>> be >>>> used with bootstrapping document] >>>> §1 Proposal summary >>>> >>>> The proposal encompasses an intuitive, yet secure approach to >>>> provisioning >>>> and configuration of sensor networks. The approach hides security details >>>> from the user, thus allowing ease of device and network setup and >>>> flexibility of trust lifecycle management, while doing away with security >>>> hassles that have plagued more conventional approaches. >>>> >>>> The proposal uses public-key cryptography, a security technology that >>>> allows reduction of trust lifecycle management to the management of >>>> trusted >>>> device identities (via so-called certificates), and security policy >>>> enforcement techniques based on lifecycle management of device roles. >>>> >>>> From a user’s perspective, this results in a system where trusted >>>> lifecycle >>>> management appears to be the same as that of an unsecured network: it >>>> simply >>>> comes down to proper identification of devices (e.g., reading off a label >>>> of >>>> a physical module) and proper management of device roles (e.g., adding >>>> these >>>> to, resp. removing these from a white list, e.g., via a workstation GUI). >>>> No >>>> secret information is disclosed at any lifecycle stage of a device or a >>>> system, nor needs to be, since management relies completely on handling >>>> of >>>> public information. This greatly reduces the complexity of lifecycle >>>> management and, thereby, training requirements for operational personnel. >>>> Moreover, it virtually removes trust dependencies between different >>>> entities >>>> involved in the value chain, whether OEM, vendor, system integrator, >>>> installer, or user. Lastly, the approach has the benefit of allowing >>>> enforcement of standards compliance (by only issuing a certificate to >>>> devices from vendors that passed conformance testing). >>>> >>>> >>>> >>>> On 29/09/2010 5:36 PM, Carsten Bormann wrote: >>>> >>>> On Sep 29, 2010, at 15:33, Carsten Bormann wrote: >>>> >>>> http://6lowapp.net/2010-09-29/ >>>> >>>> ... and the minutes are now also up there. >>>> Please tell me if I have misrepresented anyone. >>>> >>>> At 90 minutes, this was a short and sweet meeting. Thanks to everyone >>>> who >>>> participated, and in particular to Markus Becker who at very short notice >>>> volunteered to take notes (all errors in the massaged version are of >>>> course >>>> mine). >>>> >>>> Gruesse, Carsten >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> >>>> -- >>>> email: rstruik.ext@gmail.com >>>> Skype: rstruik >>>> cell: +1 (647) 867-5658 >>>> USA Google voice: +1 (415) 690-7363 >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> >> >> -- >> email: rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >> >> -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From fluffy@cisco.com Fri Oct 1 09:39:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4F23A6F34 for ; Fri, 1 Oct 2010 09:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.396 X-Spam-Level: X-Spam-Status: No, score=-110.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgoBkejenP1Y for ; Fri, 1 Oct 2010 09:39:04 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2D48F3A6D8C for ; Fri, 1 Oct 2010 09:38:30 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkGAMqrpUyrRN+K/2dsb2JhbACUMI4HcatFnD2FRASEUYVrgwI X-IronPort-AV: E=Sophos;i="4.57,267,1283731200"; d="scan'208";a="263396272" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 01 Oct 2010 16:38:23 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o91GcNr1028495 for ; Fri, 1 Oct 2010 16:38:23 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 1 Oct 2010 10:38:22 -0600 References: <20101001155604.BEAA83A6C5B@core3.amsl.com> To: core@ietf.org Message-Id: <8F33685C-3878-41DB-8D71-331EEEBA81D7@cisco.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Meeting time for IETF 79 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 16:39:05 -0000 This is just the tentative times and these times could change but as FYI ... CORE Session 1 (2 hours) Monday, Afternoon Session II 1510-1610 Room Name: Pearl ---------------------------------------------- CORE Session 2 (1 hour) Wednesday, Morning Session I 0900-1130 Room Name: Pearl ---------------------------------------------- From cabo@tzi.org Fri Oct 1 10:16:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B893A6BEB; Fri, 1 Oct 2010 10:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clvHFMx5Oy56; Fri, 1 Oct 2010 10:16:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id CA0E03A6918; Fri, 1 Oct 2010 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o91HHS7l008442; Fri, 1 Oct 2010 19:17:28 +0200 (CEST) Received: from [192.168.217.101] (p5489FC08.dip.t-dialin.net [84.137.252.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9EAEA8BE; Fri, 1 Oct 2010 19:17:27 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2010 19:17:26 +0200 To: 6lowpan 6lowpan <6lowpan@ietf.org>, core , ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Constrained network/node cluster at IETF 79 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 17:16:49 -0000 As usual, the IETF agenda planning has just begun, so please do not make = the below the basis for your travel planning. For your planning convenience, this is a set of WG meetings at IETF79 = that I've informally referring to as the "constrained network/node = cluster". Of course, there are a lot of additional WG meetings relevant = to that cluster. Gruesse, Carsten * MONDAY, November 8, 2010 1510-1610 Afternoon Session II Pearl APP core Constrained RESTful = Environments WG * TUESDAY, November 9, 2010 0900-1130 Morning Session I Valley Ballroom B INT 6man IPv6 Maintenance WG Emerald IRTF HIPRG Host Identity Protocol=20= 1300-1500 Afternoon Session I Valley Ballroom B RTG roll Routing Over Low power = and Lossy networks WG 1520-1810 Afternoon Session II/III Valley Ballroom A INT 6lowpan IPv6 over Low power WPAN = WG * WEDNESDAY, November 10, 2010 0900-1130 Morning Session I Pearl APP core Constrained RESTful = Environments WG 1510-1610 Afternoon Session II Valley Ballroom A INT lwip Light-Weight IP Protocol = Design BOF From stpeter@stpeter.im Tue Oct 5 14:49:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01DF3A6E09 for ; Tue, 5 Oct 2010 14:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRRCiIQtk-Xk for ; Tue, 5 Oct 2010 14:49:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8AA623A6E40 for ; Tue, 5 Oct 2010 14:49:49 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4DF3340074 for ; Tue, 5 Oct 2010 15:56:53 -0600 (MDT) Message-ID: <4CAB9DB3.6070604@stpeter.im> Date: Tue, 05 Oct 2010 15:50:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: core@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [core] draft-ietf-roll-rpl X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Oct 2010 21:49:50 -0000 Just curious: has anyone here looked at draft-ietf-roll-rpl? I notice that it completed IETF Last Call and I'm wondering if folks have considered its impact (if any) on the application layer of constrained networks. I see Zach's name in the acknowledgements so I take that as a good sign. :) Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From heer@informatik.rwth-aachen.de Thu Oct 7 02:35:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79883A6EF5 for ; Thu, 7 Oct 2010 02:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[AWL=1.526, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k89Li0lbHJGj for ; Thu, 7 Oct 2010 02:35:19 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id C3CDE3A6F67 for ; Thu, 7 Oct 2010 02:35:18 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L9W009N2YO5NNA0@mta-1.ms.rz.RWTH-Aachen.de> for core@ietf.org; Thu, 07 Oct 2010 11:36:05 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,296,1283724000"; d="scan'208";a="40174630" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 07 Oct 2010 11:36:05 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L9W00LJBYO47080@relay-auth-2.ms.rz.rwth-aachen.de> for core@ietf.org; Thu, 07 Oct 2010 11:36:04 +0200 (CEST) From: Tobias Heer In-reply-to: <4CA6095F.6040403@gmail.com> Date: Thu, 07 Oct 2010 11:36:05 +0200 Content-transfer-encoding: quoted-printable Message-id: References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1081) Cc: core Subject: [core] HIP identities and puzzle (was: Fwd: Wed 29, 1500 UTC (Fwd: Meeting invitation: CORE WG)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 09:35:24 -0000 Hi Rene,=20 =46rom discussions with Robert in the HIP RG and from his presentations = I take that DEX/Diet HIP is an initial offer from Bob in which he tries = to cut down the computational cost of the crypto-primitives and = implementation cost of HIP as low as possible while still maintaining = its key features. =46rom your mail and some offline discussions I take = that this cut might have been too low for some people and that the use = of non-cryptographic names bound via certificates might be an enabler = for some scenarios. In this regard, the list of security and operational = requirements in the end of your e-mail might help Bob and other authors = a lot because they can test their work against such list. I'll try to address some of your questions in line. Am 01.10.2010 um 18:16 schrieb Rene Struik: > Hi Zhen: >=20 [...] >=20 > =46rom what I do understand, though, identities are a function of the = long-term public key (witness also Section 3.2 of = draft-ietf-hip-rfc5201-bis-02, which forementioned HIP-DEX draft = presumes familiarity with). If so, pragmatically, identities are public = keys and, thereby, would change depending on key lifecycle = considerations. In my mind, this seems a no-go to get mass-scale = deployment from the ground. >=20 Your concerns got me thinking and I came up with something that might = solve your problem (or rather the problem of HIP) here. I'll briefly try = to explain the idea. Right now we are making the concept of the Host ID (HI) and the Host = Identity Tag (HIT) (the IPv6-like identity that is visible to most = applications) more flexible in HIPv2[1]. This change, which originally = aimed at providing improved crypto agility, can be used to create a kind = of non cryptographic HITs that are bound to HIs via certificates instead = of using simple hashing. Such HIs/HITs could be used in scenarios which = require more sophisticated identity management while traditional = HIs/HITs could be used in scenarios that can live with simpler = approaches.=20 Let me illustrate this with a little bit of ascii art. I'll use the = following abbreviations and notations to keep the lines short: I enumerated the mappings in HIP/DEX with m1..m3. The arrows = <--mx:mapping_name-- signify the mappings. PK is a public key for a = signature algorithm, PKDH is the public key for an ephemeral Diffie = Hellman, PKSDH is the public key for a static Diffie Hellman exchange. = SK is a symmetric session key.=20 Right now we have the following mappings between HIs and the security = associations that HIP and DEX set up: For HIP we have: HIT <--m1:Hash-- PK(HI) <--m2:Signature-- PKDH <--m3:DH_exchange--SK AFAIK for DEX it looks like this: HIT <--m1:truncate-- PKSDH <--m2:DH_exchange--SK These two or three mappings in HIP/DEX make sure that the session key is = related to the HIT. If one wanted the HIT to be independent of the cryptographic keys, it = would be simple to define a new kind of HIT/HI for which the mapping = would look like this: HIT <--m1:hash/truncate-- String <--m2:certificate-- PKSDH = <--m3:DH_exchange-- SK This means that the HIT is generated from an arbitrary string (e.g., = node ID, vendor ID, node function or a service name - anything). This = string is hashed to get it into IPv6 like form so that it can be used = just as the HIT. The actual Host ID would be a certificate (issued by a trusted third = party) that binds this string to a static DH public key. The process of = generating a HI could be like this. 1. Pick node string (e.g., = "Node222:Temperature sensor"), 2. generate static DH public key, 3. = generate certificate covering string and DH public key, 4. give DH = public/private key pair and certificate to the node. This would mean that (provided that there is a trusted third party) one = could use descriptive strings in HIP in the same way that cryptographic = names are used. The way that applications deal with HITs and the actual = HIP handshake would stay almost the same. The only difference is that = the peers use the third-party certificates to verify mapping m2. This is just a first sketch without proper specification. However, = adding such certificate-based host identities to HIP shouldn't be hard = and won't break anything. Ren=E9 Hummen agreed to provide a draft that = fleshes out this approach if CORE or HIPRG/WG deem it interesting. > BTW (not relevant to authentication topic) - It is not immediately = clear whether the "puzzle" presented from responder to initiator (Puzzle = is to compute J so that x:=3DCMAC_I ( Id_A || Id_B || J) has a = pre-fixed pattern on K bit positions) does not allow for "shortcuts", = thus allowing its solution with expenditure of far less than 2^K = trial-and-error computing rounds. Can't one do a meet-in-the-middle type = of attack here? Anyway, not directly relevant to the authentication = question at hand (although perhaps adding to confusion). I see your point here. If cmac is particularly susceptive to a = meet-on-the-middle attack one could slightly modify the puzzle so that = instead of requiring a certain length of 0 bits in the beginning of the = solution, a match with a random/pseudorandom string is required. The = pseudorandom string should not be known to the Initiator before the = connection attempt and could be connection specific or could cycle. This = would make it hard to precompute the second step of the = meet-in-the-middle attack because this step will be different for each = puzzle. > To aid clarity and succinct discussions, it would help to have a clear = description of desired security services to be offered by an = authenticated key agreement scheme and see whether a candidate scheme = (such as, who knows, HIP) satisfies these. If you could provide a = succinct description of the HIP protocol itself, so that this is easy to = understand, and could provide what properties it has, that would be of = great help! >=20 > In my mind, properties of suitable authenticated key agreement schemes = should include (a) key establishment; (b) implicit key authentication; = (c) key confirmation; (d) mutual entity authentication; (e) forward = secrecy; (f) {perhaps} some more esoteric properties (key compromise = impersonation resilience, etc.). >=20 Is this list valid for all targeted use cases? If yes, it is a very = handy list to check against. However, (e) forward secrecy seems to rule = a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) = and might not be relevant to all use cases (especially small setups). = However, I am not absolutely firm with the envisaged scenarios in CORE. > Moreover, the "name space" (device identifiers) and the "cryptographic = space" (public keys, etc.) should be independent, so that this would = allow trust lifecycle management to be reduced to proper management of = device identifiers (i.e., *no* entanglement of concepts from different = disciplines). =20 Does the "*no* entanglement of concepts from different disciplines" also = mean that a concept like the id/loc split should be used to avoid = entanglement of routing and naming? BR, Tobias [1] draft-ietf-hip-rfc5201-bis-02: = http://www.ietf.org/id/draft-ietf-hip-rfc5201-bis-02.txt > On 01/10/2010 10:59 AM, Zhen Cao wrote: >> On Fri, Oct 1, 2010 at 9:57 PM, Rene Struik = wrote: >>> Hi Zhen: >>>=20 >>> To my knowledge (cf. also Slides 48-51 inter alia of IETF-78 6lowpan = slide >>> deck), the HIP-DEX protocol only provides evidence that the = communicating >>> parties involved with the key agreement scheme had access to the = long-term >>> private key (i.e., key possession), not of their identity. These = properties >>> are essentially those offered by the ephemeral Diffie-Hellman (DH) = key >>> agreement scheme (which does not provide for authentication of = either party >>> involved with the protocol); hence, my reference hereto. >> I was based on draft-moskowitz-hip-rg-dex-02, section 4.1. On page = 8, >> the HIP diet exchange I2 and R2 include a computed MAC, I think it is >> used for authentication of either party. >>=20 >> The full capability HIP is able to do the authenticated key exchange, >> your concern is that current Diet-HIP cannot do that? If so, we can >> input this as a requirement for Diet-HIP while it is not so closed to >> an RFC. >>=20 >> Thanks, >> Zhen >>=20 >>> Please note that those slides refer to NIST SP 800-56a (Para 6.3.2, = Para >>> 6.3.3), which describes C(0,2), i.e., DH using static keys, where = key >>> derivation includes use of nonce provided by the initiating party. = As such, >>> this does not include the use of signatures. As final notes: (a) the = C(0,2) >>> scheme assumes that public keys are tied to identities (cf. Para = 6.3.3, l. >>> 1); (b) the scheme does not provide forward secrecy (i.e., = compromise of a >>> device may compromise past secrets established with that device [in = my mind, >>> an undesirable property for internet of things type devices, which = cannot be >>> assumed to have physical protection and may be placed out in the = open (e.g., >>> screwed on a garage or street lamp post)]). >> I will check with the NIST document and come back soon. >>=20 >>> Best regards, Rene >>>=20 >>>=20 >>> On 01/10/2010 9:07 AM, Zhen Cao wrote: >>>> Excuse me to jump into the discussion. I am also interested in >>>> HIP/Diet-HIP protocol. >>>>=20 >>>> In my mind, HIP offers authenticated key exchange via the use of >>>> signatures, i.e., the DH exchange is signed and thus authenticated. >>>> After the exchange, IPSEC ESP is established and data = authentication >>>> is achieved via the IPSEC SA. >>>>=20 >>>> Thanks, >>>> Zhen >>>>=20 >>>> On Thu, Sep 30, 2010 at 6:19 AM, Rene Struik >>>> wrote: >>>>> Hi Carsten: >>>>>=20 >>>>> Thanks for the minutes. I just had a quick look and somehow seemed = to >>>>> have >>>>> missed during the conf call your reference to the HIP protocol. = Could you >>>>> elaborate a little bit more? To my knowledge, HIP essentially does >>>>> ephemeral >>>>> Diffie-Hellman key agreement, thus not offering authenticated key >>>>> agreement. >>>>> In my mind, authenticated key agreement is essential to trigger = data >>>>> authentication tied to a unique identifier and allow trust = lifecycle >>>>> management to be reduced to management of device identities (via = use of >>>>> certificates). See also the brief summary below. >>>>>=20 >>>>> Perhaps, we should discuss this somewhat more early next week. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Rene >>>>>=20 >>>>> [summary of old proposal of mine on trust lifecycle management = that could >>>>> be >>>>> used with bootstrapping document] >>>>> =A71 Proposal summary >>>>>=20 >>>>> The proposal encompasses an intuitive, yet secure approach to >>>>> provisioning >>>>> and configuration of sensor networks. The approach hides security = details >>>>> from the user, thus allowing ease of device and network setup and >>>>> flexibility of trust lifecycle management, while doing away with = security >>>>> hassles that have plagued more conventional approaches. >>>>>=20 >>>>> The proposal uses public-key cryptography, a security technology = that >>>>> allows reduction of trust lifecycle management to the management = of >>>>> trusted >>>>> device identities (via so-called certificates), and security = policy >>>>> enforcement techniques based on lifecycle management of device = roles. >>>>>=20 >>>>> =46rom a user=92s perspective, this results in a system where = trusted >>>>> lifecycle >>>>> management appears to be the same as that of an unsecured network: = it >>>>> simply >>>>> comes down to proper identification of devices (e.g., reading off = a label >>>>> of >>>>> a physical module) and proper management of device roles (e.g., = adding >>>>> these >>>>> to, resp. removing these from a white list, e.g., via a = workstation GUI). >>>>> No >>>>> secret information is disclosed at any lifecycle stage of a device = or a >>>>> system, nor needs to be, since management relies completely on = handling >>>>> of >>>>> public information. This greatly reduces the complexity of = lifecycle >>>>> management and, thereby, training requirements for operational = personnel. >>>>> Moreover, it virtually removes trust dependencies between = different >>>>> entities >>>>> involved in the value chain, whether OEM, vendor, system = integrator, >>>>> installer, or user. Lastly, the approach has the benefit of = allowing >>>>> enforcement of standards compliance (by only issuing a certificate = to >>>>> devices from vendors that passed conformance testing). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 29/09/2010 5:36 PM, Carsten Bormann wrote: >>>>>=20 >>>>> On Sep 29, 2010, at 15:33, Carsten Bormann wrote: >>>>>=20 >>>>> http://6lowapp.net/2010-09-29/ >>>>>=20 >>>>> ... and the minutes are now also up there. >>>>> Please tell me if I have misrepresented anyone. >>>>>=20 >>>>> At 90 minutes, this was a short and sweet meeting. Thanks to = everyone >>>>> who >>>>> participated, and in particular to Markus Becker who at very short = notice >>>>> volunteered to take notes (all errors in the massaged version are = of >>>>> course >>>>> mine). >>>>>=20 >>>>> Gruesse, Carsten >>>>>=20 >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>>=20 >>>>>=20 >>>>> -- >>>>> email: rstruik.ext@gmail.com >>>>> Skype: rstruik >>>>> cell: +1 (647) 867-5658 >>>>> USA Google voice: +1 (415) 690-7363 >>>>>=20 >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>>=20 >>>>>=20 >>>=20 >>> -- >>> email: rstruik.ext@gmail.com >>> Skype: rstruik >>> cell: +1 (647) 867-5658 >>> USA Google voice: +1 (415) 690-7363 >>>=20 >>>=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From darco@deepdarc.com Thu Oct 7 14:09:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D639C3A6FF3 for ; Thu, 7 Oct 2010 14:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmn5oM0-SZDN for ; Thu, 7 Oct 2010 14:09:37 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id EBDF33A7127 for ; Thu, 7 Oct 2010 14:09:34 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 50D6CB4891F0; Thu, 7 Oct 2010 14:10:38 -0700 (PDT) X-AuditID: 11807130-b7b53ae0000049b6-84-4cae374ee78d Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id F8.B4.18870.E473EAC4; Thu, 7 Oct 2010 14:10:38 -0700 (PDT) From: Robert Quattlebaum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Oct 2010 14:10:37 -0700 To: core Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: [core] Header suggestion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Oct 2010 21:09:39 -0000 I just wanted to suggest two new headers to help deal with handling = requests with responses which are large, such as when listing the = contents of a folder with a large (or even undefined) number of items. = The headers are "More" (elective) and "Next" (critical). While the initial goal of these headers was to facilitate returning the = contents of folders with a large (or undefined, in the one-wire case) = number of items, this mechanism could be applied to other content types = just as easily.=20 Quick overview: The 'More' header is used by the server when there is = additional content available that is not included in the response. If = supported by the client, the client would then send another request = containing a 'Next' header to retrieve additional content. The server = responds with the additional content and possibly another "More" header. = This cycle continues until the client receives a response without a = 'Next' header, indicating the end of the content. The value of the "More" header may blank or it may contain a unique = identifier of an unspecified length. If the "More" header contained a = value, then this value is used for the "Next" header in the subsequent = request. If the "More" header contains no value, then the "Next" header = is filled with the last line of the content from the previous response. = In any case, the server uses the value of the "Next" header to determine = where it should continue from. This mechanism is superior to using "page indexes" because it allows the = current state of the traversal to be included with the requests. This is = useful in cases where the server is returning a list of items when it = does not immediately know how many are present. For example, lets say that we have a 1Wire-to-CoAP bridge. There could = be thousands of devices attached on the one-wire bus, so storing a list = of the connected one-wire devices is not scalable. When a client first = requests a list of the connected one-wire devices, the bridge would = begin performing the one-wire device discovery traversal. Once the = bridge fills up the content of the response, the current state of the = one-wire discovery traversal is stored as the value of the "More" = header, and the response is sent. The client receives the response, = notices the "More" header, and sends another query with a "Next" header = containing the value of the previous "More" header. When the server = receives this request, it notices the "More" header and uses that to = initialize the state of the one-wire device discovery traversal. The = server then continues performing one-wire discovery from where it left = off. It may even be possible to reconstruct the state of the one-wire = traversal from the value of the last device discovered. In this case, = the value of the "More" header is empty, and when the client sees it in = the response it sends another query using the last line of the previous = content as the value. If "page indexes" were used(eg: the value of the 'Next' header is simply = the number of packets that have been fetched in the request so far), the = device would have to start the one-wire device discovery traversal over = from scratch to determine where the start of the given page would be. = This is not scalable to large numbers of 1Wire devices. In the simple case where the device simply has an array of items that is = too large for a single packet, it can use a simple index as the value of = the "More" field. Since the value of the "More" and "Next" fields is = opaque to everyone except the server that generated it, the server = implementation has a lot of flexibility of how to implement large = queries. In the event that the server state has changed in such a way that an = incoming request with a "Next" field is no longer relevant, a reset = response should be sent to the server. Please let me know your thoughts. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From cabo@tzi.org Thu Oct 7 14:41:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F153A6F1A for ; Thu, 7 Oct 2010 14:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.155 X-Spam-Level: X-Spam-Status: No, score=-106.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccmcekGc2fUl for ; Thu, 7 Oct 2010 14:41:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2932B3A6E44 for ; Thu, 7 Oct 2010 14:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o97LgL8L014525; Thu, 7 Oct 2010 23:42:23 +0200 (CEST) Received: from [192.168.217.101] (p5489E408.dip.t-dialin.net [84.137.228.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E2801DFE; Thu, 7 Oct 2010 23:42:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 7 Oct 2010 23:42:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E516169-CBA9-474E-8987-CD407CE94AD7@tzi.org> References: To: Robert Quattlebaum X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Header suggestion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Oct 2010 21:41:38 -0000 Interesting. A couple of quick comments: -- 'More' cannot really be elective, as a client not understanding this = option would think it has received the whole resource when it only = received a part of the data. Alternatively, 'More' could be part of the = data (i.e., the resource representation is complete in its own right = because it contains the pointer to its continuation via an embedded = link). -- 'Next' may not really be needed as an option since the client can = simply use a different URI for the next request (e.g., by adding a = query). In the most RESTful case, 'More' gave the client just that URI. What's missing for a general mechanism is a way for the client to = reconstruct the entire resource from the parts received (is it just = binary concatenation of the representations?). The answer might depend = on the media type of the resource. I think having an option that acts like an HTTP Link: header, with the = right relationship type, might be another approach (and might have = synergy with the way we use the Link header syntax for discovery). I like grounding this discussion in specific examples. Can you provide = more details of the 1wire example you have in mind? Gruesse, Carsten From darco@deepdarc.com Thu Oct 7 19:01:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800F23A67A3 for ; Thu, 7 Oct 2010 19:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oba9x3Av3tv1 for ; Thu, 7 Oct 2010 19:01:33 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 000353A679F for ; Thu, 7 Oct 2010 19:01:31 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 46B20B496E20; Thu, 7 Oct 2010 19:02:35 -0700 (PDT) X-AuditID: 11807136-b7b3aae0000033cc-b9-4cae7bbb0b42 Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 90.D9.13260.BBB7EAC4; Thu, 7 Oct 2010 19:02:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: <8E516169-CBA9-474E-8987-CD407CE94AD7@tzi.org> Date: Thu, 7 Oct 2010 19:02:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F0BFF23-C818-4E00-BD14-9B11350B3CAA@deepdarc.com> References: <8E516169-CBA9-474E-8987-CD407CE94AD7@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core Subject: Re: [core] Header suggestion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Oct 2010 02:01:35 -0000 Hello Carsten! On Oct 7, 2010, at 2:42 PM, Carsten Bormann wrote: > -- 'More' cannot really be elective, as a client not understanding = this option would think it has received the whole resource when it only = received a part of the data. =20 Fair enough. I was thinking more or less about the directory listing = case, in which I figured understanding the first few items was better = than not understanding anything. > Alternatively, 'More' could be part of the data (i.e., the resource = representation is complete in its own right because it contains the = pointer to its continuation via an embedded link). I think I'd rather make "More" be critical. Making the "More" mechanism = a part of the data itself sounds like it would make things more complex. > -- 'Next' may not really be needed as an option since the client can = simply use a different URI for the next request (e.g., by adding a = query). In the most RESTful case, 'More' gave the client just that URI. What if the original URL already had a query component? Specifying a URI in the "More" field (even if it is just a path and not = a full URI) could increase the packet size of the responses = significantly, when they are already being clipped by this mechanism. = Also, all subsequent requests via the "Next" header are conceptually = just an additional part of the original request. Large responses would be stored in a CoAP cache as a single cached = item---it would combine all of the content form multiple requests and = store the entire content. When requested by a client, the cache would = break up the request itself. I think this approach would be better than = caching individual responses. This concept would also scale well to an = HTTP-CoAP gateway. > What's missing for a general mechanism is a way for the client to = reconstruct the entire resource from the parts received (is it just = binary concatenation of the representations?). The answer might depend = on the media type of the resource. I think simple binary concatenation is the way to go, no matter what = content-type is being used. Anything else would be problematic, IMHO. However, one thing that I think *should* be dependent on content-type is = where in the content you can break it into multiple packets. For = example, when requesting a directory listing, each response must only = contain full entries. A partial entry at the end of one response which = would be continued from the next response would not be allowed for that = content type. Without this, my rule "if More is empty, use the last line = of the content for Next" wouldn't make any sense. Other content-types = (maybe text/csv) may have similar rules, but in any case the client only = has to do one thing: concatenate. > I think having an option that acts like an HTTP Link: header, with the = right relationship type, might be another approach (and might have = synergy with the way we use the Link header syntax for discovery). This breaks the idea that this is really just one big request, and would = make caching and HTTP proxies more complicated, IMHO. > I like grounding this discussion in specific examples. Can you = provide more details of the 1wire example you have in mind? I'm not sure exactly what part to elaborate on, so if I don't cover what = you were interested in let me know and I'll be happy to go into more = detail. I'm a big fan of the 1wire bus. It has a lot of great features such as a = practically unbounded limit of devices on a single bus, device = discovery, and alarm discovery. For example, you could put hundreds of = temperature sensors on a single 1wire bus, each with their own high and = low temperature alarm values stored in non-volatile memory. You could = periodically scan the bus for temperature changes and alarm conditions, = with the only state being what action to take for a given device. What I'm imagining is a stateless 1wire-CoAP bridge that has a = completely dynamic file structure. When you query the devices folder, = the device starts doing a "Search ROM" procedure on the 1wire bus to = start enumerating the devices. Each device would appear to be a = directory, named by the unique device id. When you get the contents of = the directory, items are automatically generated and returned based on = what type of 1wire device it is. For example, when you do a GET request = for , it = will start attempting to read the temperature from device = 0123456789abcdef on the 1wire bus. Adding more temperature sensors, or = switches, or digital-pots, or A/D converters, is as simple as adding the = appropriate device to the 1wire bus. In order to keep things stateless, I tried to make the More/Next = mechanism as flexible as possible without making things excessively = complex. Starting the traversal over from scratch every time a next = request came in seemed very wasteful, so being able to carry around the = state of the traversal inside of the message itself is essential. The = bridge never really knows how many devices are connected to the 1-wire = bus at any given moment, and it doesn't need to.=20 IMHO, the most important case that this mechanism allows is cases where = you have a large number of items to return in response to listing the = contents of a folder. Using this for retrieving other content types may = be useful, but I think we should avoid any urge to turn this into some = sort of general case for large transactions. (eg: This mechanism does = not address a way to make large PUTs, nor do I think that would be a = good idea) Let me know if you would like any additional clarification. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From cabo@tzi.org Sun Oct 10 12:21:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFAA3A67F8 for ; Sun, 10 Oct 2010 12:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.158 X-Spam-Level: X-Spam-Status: No, score=-106.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxTNJBlWUaHE for ; Sun, 10 Oct 2010 12:21:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2327E3A67E1 for ; Sun, 10 Oct 2010 12:21:36 -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 o9AJMWei018103; Sun, 10 Oct 2010 21:22:33 +0200 (CEST) Received: from [192.168.217.101] (p5489B51F.dip.t-dialin.net [84.137.181.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 30211350; Sun, 10 Oct 2010 21:22:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4F0BFF23-C818-4E00-BD14-9B11350B3CAA@deepdarc.com> Date: Sun, 10 Oct 2010 21:22:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E516169-CBA9-474E-8987-CD407CE94AD7@tzi.org> <4F0BFF23-C818-4E00-BD14-9B11350B3CAA@deepdarc.com> To: Robert Quattlebaum X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Header suggestion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Oct 2010 19:21:38 -0000 > I'm a big fan of the 1wire bus. Actually, I think you will find quite a few 1-wire fans in the IETF... I unfortunately don't know much about 1-wire, but let me speculate a = bit. The enumeration only tells you about the existence of the devices (and their type), not what they actually do/are sensing -- is the sensor measuring the refrigerator or the outdoor temperature? So I'd assume you will do an enumeration only during commissioning/bootstrap, i.e., relatively infrequently. I'm therefore happy with something that is not extremely efficient (but of course has to be reasonable, i.e. still in the same order of magnitude a very efficient version would be). If the problem is just sending responses larger than you are comfortable with in one packet (MTU, delivery probability of adaptation-layer-fragmented packets, etc.), then the block option gives you a quite efficient way of doing this -- the total overhead is two bytes (three bytes if there are many blocks). Note that, for GET requests, there is never a need to keep per-client state at the server. But I think you are interested in *semantic* fragmentation. That needs to be discussed in the context of the specific semantics. So how would the enumeration access look like? CoAP has /.well-known/core for discovery, which is pretty much what enumeration would be about here. So I'd expect a stateless, minimal 1-wire/CoAP Gateway to have a /.well-known/core that looks approximately like: ;type=3D"application/1wire";n=3D"HU10", ;type=3D"application/1wire", ;rel=3D"section";type=3D"application/link-format" ;type=3D"application/1wire", = ;rel=3D"section";type=3D"appli= cation/link-format" (Of course, there may be other useful metadata here -- I know too little about 1-wire to fill this in properly. And we might have a numeric ct for application/1wire, if that is even a meaningful concept.) /77000000023CEC12 points to a 1-wire switch, which again can be queried for its description (it itself is represented by another link-format document). The last link, /.well-known/core?after=3D78cdd38e7ab74e39, is pretty much what your "more" option would be, except that it is on a semantic level in the resource representation. Note that the *server* decides how this link looks like -- there is no "link arithmetic" in REST. Yes, this approach needs more bits than an optimized one. What you gain is more flexibility. I'm not going to do the "Hypermedia as the Engine of Application State" spiel here right now, but this is a powerful concept that we might want to make use of. Gruesse, Carsten From darco@deepdarc.com Sun Oct 10 15:24:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893FE3A6856 for ; Sun, 10 Oct 2010 15:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVcV-qSJ8lrG for ; Sun, 10 Oct 2010 15:24:20 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 7FBBA3A6860 for ; Sun, 10 Oct 2010 15:24:17 -0700 (PDT) Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:35471 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P54Kd-0006EL-Gw; Sun, 10 Oct 2010 18:25:27 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1--795320276 From: Robert Quattlebaum In-Reply-To: Date: Sun, 10 Oct 2010 15:25:24 -0700 Message-Id: <28F2BCC2-A9CA-4D3A-81C4-740090168538@deepdarc.com> References: <8E516169-CBA9-474E-8987-CD407CE94AD7@tzi.org> <4F0BFF23-C818-4E00-BD14-9B11350B3CAA@deepdarc.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: core Subject: Re: [core] Header suggestion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Oct 2010 22:24:25 -0000 --Apple-Mail-1--795320276 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Carsten! On Oct 10, 2010, at 12:22 PM, Carsten Bormann wrote: >> I'm a big fan of the 1wire bus. >=20 > Actually, I think you will find quite a few 1-wire fans in the IETF... Good to hear. It's a clever protocol. Too bad Dallas-Semiconductor/Maxim = own it, but it's just too useful to ignore. > I unfortunately don't know much about 1-wire, but let me speculate a = bit. >=20 > The enumeration only tells you about the existence of the devices (and > their type), not what they actually do/are sensing -- is the sensor > measuring the refrigerator or the outdoor temperature? =20 You are correct: the type of the sensor is encoded as a part of it's = 64-bit ID, so what the device is and how to use it is discoverable. You = could also perform discovery for specific classes of devices. For = example, you could have a folder for temperature sensors, a folder for = ADCs, a folder for digital switches, a folder for real-time clocks, etc. As for attaching specific human-readable labels (like "Bedroom temp", or = "Basement temp"), yes, you would need a separate database to look up = what the names of the devices are. But I think such functionality is not = necessarily a requirement. > So I'd assume > you will do an enumeration only during commissioning/bootstrap, i.e., > relatively infrequently. I'm therefore happy with something that is > not extremely efficient (but of course has to be reasonable, > i.e. still in the same order of magnitude a very efficient > version would be). It is true that in general you don't need to list devices very often. = More often they will be referenced directly. In terms of big-O notation, the efficient traversal would be O(n), = whereas a traversal which would require that the "Search ROM" process = start over from scratch would be O(N^2). > If the problem is just sending responses larger than you are > comfortable with in one packet (MTU, delivery probability of > adaptation-layer-fragmented packets, etc.), then the block option > gives you a quite efficient way of doing this -- the total overhead is > two bytes (three bytes if there are many blocks). Note that, for GET > requests, there is never a need to keep per-client state at the = server. My concern is partially packet size, but it is also the ability to parse = larger amounts of data at layer 7. If we let Layer 3 (IP) or Layer 2 = (802.15.4+6LoWPAN) do the fragmentation, then we need to have enough RAM = to hold a single large packet. Using the method I was describing, = processing can be performed on large amounts of data (much larger than = 64k, the packet size limit for non-jumbo IPv6) incrementally by = constrained devices with little RAM at whatever pace they can work at. > But I think you are interested in *semantic* fragmentation. That > needs to be discussed in the context of the specific semantics. So > how would the enumeration access look like? CoAP has > /.well-known/core for discovery, which is pretty much what enumeration > would be about here. >=20 > So I'd expect a stateless, minimal 1-wire/CoAP Gateway to have a > /.well-known/core that looks approximately like: >=20 > ;type=3D"application/1wire";n=3D"HU10", > ;type=3D"application/1wire", > ;rel=3D"section";type=3D"application/link-format" > ;type=3D"application/1wire", > = ;rel=3D"section";type=3D"appli= cation/link-format" >=20 > (Of course, there may be other useful metadata here -- I know too > little about 1-wire to fill this in properly. And we might have a > numeric ct for application/1wire, if that is even a meaningful > concept.) >=20 > /77000000023CEC12 points to a 1-wire switch, which again can be > queried for its description (it itself is represented by another > link-format document). I would imagine that all 1wire devices would be of type = "application/link-format", with specific attributes enumerated therein. = At least, that's how I'm building it right now. Overall what you are = describing looks reasonable, except for the last entry, which I will = elaborate on below. :) > The last link, /.well-known/core?after=3D78cdd38e7ab74e39, is pretty > much what your "more" option would be, except that it is on a semantic > level in the resource representation. Note that the *server* decides > how this link looks like -- there is no "link arithmetic" in REST. >=20 > Yes, this approach needs more bits than an optimized one. What you > gain is more flexibility. I'm not going to do the "Hypermedia as the > Engine of Application State" spiel here right now, but this is a > powerful concept that we might want to make use of. It actually seems less flexible to me, because it only works for the = "application/link-format" content-type. Support using other = content-types would have to be implemented specifically for that = content-type. The More/Next headers I am suggesting works transparently = with every content-type, uses less bits, and gives a large amount of = implementation flexibility. For what it's worth, I'm using them right = now in my test implementation, and they work great. The More/Next headers don't break REST. Caches would fetch and cache an = entire document and break it up into chunks when queried. CoAP-only = proxies can ignore the headers entirely. CoAP-HTTP proxies also have a = clear way to work: For HTTP->CoAP: you make an HTTP request and the proxy sends out a CoAP = request. It notices a More header, sends out the content to the HTTP = connection (but doesn't close it), and then sends out another CoAP = request with the Next header. This process would continue until the = entire content is retrieved, after which the connection is closed. To = the HTTP client it appeared to be a single request which loaded = gradually. For CoAP->HTTP: the proxy would receive the CoAP request and translate = that into an HTTP request. As the content comes in from the HTTP = response, the CoAP content buffer fills up and a CoAP response is sent, = along with a More header containing an Id to reference the current = connection. When the HTTP proxy receives the CoAP request with the = appropriate Next header, it dumps more http response content into the = CoAP response and sends that back to the CoAP client, including another = More header if necessary. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-1--795320276 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I'm a big fan of the 1wire = bus.

Actually, I think you will find quite a few = 1-wire fans in the = IETF...

Good to hear. It's a = clever protocol. Too bad Dallas-Semiconductor/Maxim own it, but it's = just too useful to ignore.

I = unfortunately don't know much about 1-wire, but let me speculate a = bit.

The enumeration only tells you about the existence of the = devices (and
their type), not what they actually do/are sensing -- is = the sensor
measuring the refrigerator or the outdoor temperature? =  

You are correct: the type = of the sensor is encoded as a part of it's 64-bit ID, so what the device = is and how to use it is discoverable. You could also perform discovery = for specific classes of devices. For example, you could have a folder = for temperature sensors, a folder for ADCs, a folder for digital = switches, a folder for real-time clocks, = etc.

As for attaching specific human-readable = labels (like "Bedroom temp", or "Basement temp"), yes, you would need a = separate database to look up what the names of the devices are. But I = think such functionality is not necessarily a = requirement.

So I'd = assume
you will do an enumeration only during = commissioning/bootstrap, i.e.,
relatively infrequently.  I'm = therefore happy with something that is
not extremely efficient (but = of course has to be reasonable,
i.e. still in the same order of = magnitude a very efficient
version would = be).

It is true that in general you = don't need to list devices very often. More often they will be = referenced directly.

In terms of big-O = notation, the efficient traversal would be O(n), whereas a traversal = which would require that the "Search ROM" process start over from = scratch would be O(N^2).

If the problem is just sending responses larger than = you are
comfortable with in one packet (MTU, delivery probability = of
adaptation-layer-fragmented packets, etc.), then the block = option
gives you a quite efficient way of doing this -- the total = overhead is
two bytes (three bytes if there are many blocks). =  Note that, for GET
requests, there is never a need to keep = per-client state at the = server.

My concern is = partially packet size, but it is also the ability to parse larger = amounts of data at layer 7. If we let Layer 3 (IP) or Layer 2 = (802.15.4+6LoWPAN) do the fragmentation, then we need to have enough RAM = to hold a single large packet. Using the method I was describing, = processing can be performed on large amounts of data (much larger than = 64k, the packet size limit for non-jumbo IPv6) incrementally by = constrained devices with little RAM at whatever pace they can work = at.

But I think you = are interested in *semantic* fragmentation.  That
needs to be = discussed in the context of the specific semantics.  So
how = would the enumeration access look like?  CoAP = has
/.well-known/core for discovery, which is pretty much what = enumeration
would be about here.

So I'd expect a stateless, = minimal 1-wire/CoAP Gateway to have a
/.well-known/core that looks = approximately = like:

</0699127fb0e66679>;type=3D"application/1wire";n=3D"HU1= 0",
</4633d965cc03b08b>;type=3D"application/1wire",
</77000= 000023CEC12>;rel=3D"section";type=3D"application/link-format"
</7= 8cdd38e7ab74e39>;type=3D"application/1wire",
</.well-known/core?a= fter=3D78cdd38e7ab74e39>;rel=3D"section";type=3D"application/link-forma= t"

(Of course, there may be other useful metadata here -- I know = too
little about 1-wire to fill this in properly.  And we might = have a
numeric ct for application/1wire, if that is even a = meaningful
concept.)

/77000000023CEC12 points to a 1-wire = switch, which again can be
queried for its description (it itself is = represented by another
link-format = document).

I would imagine = that all 1wire devices would be of type "application/link-format", with = specific attributes enumerated therein. At least, that's how I'm = building it right now. Overall what you are describing looks reasonable, = except for the last entry, which I will elaborate on below. = :)

The last link, = /.well-known/core?after=3D78cdd38e7ab74e39, is pretty
much what your = "more" option would be, except that it is on a semantic
level in the = resource representation.  Note that the *server* decides
how = this link looks like -- there is no "link arithmetic" in = REST.

Yes, this approach needs more bits than an optimized one. =  What you
gain is more flexibility.  I'm not going to do = the "Hypermedia as the
Engine of Application State" spiel here right = now, but this is a
powerful concept that we might want to make use = of.

It actually seems = less flexible to me, because it only works for the = "application/link-format" content-type. Support using other = content-types would have to be implemented specifically for that = content-type. The More/Next headers I am suggesting works transparently = with every content-type, uses less bits, and gives a large = amount of implementation flexibility. For what it's worth, I'm using = them right now in my test implementation, and they work = great.

The More/Next headers don't break REST. = Caches would fetch and cache an entire document and break it up into = chunks when queried. CoAP-only proxies can ignore the headers entirely. = CoAP-HTTP proxies also have a clear way to = work:

For HTTP->CoAP: you make an HTTP = request and the proxy sends out a CoAP request. It notices a More = header, sends out the content to the HTTP connection (but doesn't close = it), and then sends out another CoAP request with the Next header. This = process would continue until the entire content is retrieved, after = which the connection is closed. To the HTTP client it appeared to be a = single request which loaded gradually.

For = CoAP->HTTP: the proxy would receive the CoAP request and translate = that into an HTTP request. As the content comes in from the HTTP = response, the CoAP content buffer fills up and a CoAP response is sent, = along with a More header containing an Id to reference the current = connection. When the HTTP proxy receives the CoAP request with the = appropriate Next header, it dumps more http response content into the = CoAP response and sends that back to the CoAP client, including another = More header if necessary.



= --Apple-Mail-1--795320276-- From cabo@tzi.org Sun Oct 10 16:03:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421613A687E for ; Sun, 10 Oct 2010 16:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccBpJQ8MX3Ld for ; Sun, 10 Oct 2010 16:03:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id BA2E93A6862 for ; Sun, 10 Oct 2010 16:03: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 o9AN49Ej002052; Mon, 11 Oct 2010 01:04:10 +0200 (CEST) Received: from [192.168.217.101] (p5489B51F.dip.t-dialin.net [84.137.181.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4302837A; Mon, 11 Oct 2010 01:04:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <28F2BCC2-A9CA-4D3A-81C4-740090168538@deepdarc.com> Date: Mon, 11 Oct 2010 01:04:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B60650D-2645-4EA4-B538-67DCC3186BA1@tzi.org> References: <8E516169-CBA9-474E-8987-CD407CE94AD7@tzi.org> <4F0BFF23-C818-4E00-BD14-9B11350B3CAA@deepdarc.com> <28F2BCC2-A9CA-4D3A-81C4-740090168538@deepdarc.com> To: Robert Quattlebaum X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Header suggestion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Oct 2010 23:03:14 -0000 >> If the problem is just sending responses larger than you are >> comfortable with in one packet (MTU, delivery probability of >> adaptation-layer-fragmented packets, etc.), then the block option >> gives you a quite efficient way of doing this -- the total overhead = is >> two bytes (three bytes if there are many blocks). Note that, for GET >> requests, there is never a need to keep per-client state at the = server. >=20 > My concern is partially packet size, but it is also the ability to = parse larger amounts of data at layer 7. If we let Layer 3 (IP) or Layer = 2 (802.15.4+6LoWPAN) do the fragmentation, then we need to have enough = RAM to hold a single large packet. Using the method I was describing, = processing can be performed on large amounts of data (much larger than = 64k, the packet size limit for non-jumbo IPv6) incrementally by = constrained devices with little RAM at whatever pace they can work at. Yes, that is one of the reasons the block option was invented (have you = looked at draft-bormann-core-coap-block-00.txt?), which works on slices = of resource representations, not on packets. Semantic fragmentation may or may not simplify the handling of the = boundaries between the fragments; that depends a lot on a common = understanding of what good boundaries would be between client and = server. In the end you need a media type specification if you want that = agreement. > It actually seems less flexible to me, because it only works for the = "application/link-format" content-type. The intention is certainly not that link-format is the only type that = carries links, so I don't understand why we would have that limitation. = XML/EXI and JSON certainly can carry links. Any new format you invent = can, too. > Support using other content-types would have to be implemented = specifically for that content-type. Yes, that's kind of implied if you really want *semantic* fragmentation. > The More/Next headers don't break REST. Caches would fetch and cache = an entire document and break it up into chunks when queried. That is certainly the intention with the block option. > CoAP-only proxies can ignore the headers entirely. CoAP-HTTP proxies = also have a clear way to work: >=20 > For HTTP->CoAP: you make an HTTP request and the proxy sends out a = CoAP request. It notices a More header, sends out the content to the = HTTP connection (but doesn't close it), and then sends out another CoAP = request with the Next header. This process would continue until the = entire content is retrieved, after which the connection is closed. To = the HTTP client it appeared to be a single request which loaded = gradually. The proxy would need to understand how to aggregate the semantic = fragments into a larger representation. I don't know how to do this in the general case (although I might be = able to cook up rules that work in certain cases for XML/EXI and JSON). > For CoAP->HTTP: the proxy would receive the CoAP request and translate = that into an HTTP request. As the content comes in from the HTTP = response, the CoAP content buffer fills up and a CoAP response is sent, = along with a More header containing an Id to reference the current = connection. When the HTTP proxy receives the CoAP request with the = appropriate Next header, it dumps more http response content into the = CoAP response and sends that back to the CoAP client, including another = More header if necessary. All this is done nicely on a sequence-of-bytes level by the block = option. (Again, I don't know how to do this on a semantic level without = interpretation of the media type by the proxy.) I think some of the disconnect here is that you seem to have a very = specific idea of the media types that you want to handle (e.g., there is = no concept of "lines" in JSON or EXI, so I wouldn't even know what = "More" would mean). Maybe we need to look into this interesting class of media types some = more and see how CoAP could support them better. Gruesse, Carsten From darco@deepdarc.com Sun Oct 10 17:09:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBD63A68BC for ; Sun, 10 Oct 2010 17:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+uLgMLdjfux for ; Sun, 10 Oct 2010 17:09:04 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 54A5E3A68AF for ; Sun, 10 Oct 2010 17:08:59 -0700 (PDT) Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:45248 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P55xx-0003h0-7W; Sun, 10 Oct 2010 20:10:09 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2--789038135 From: Robert Quattlebaum In-Reply-To: <0B60650D-2645-4EA4-B538-67DCC3186BA1@tzi.org> Date: Sun, 10 Oct 2010 17:10:07 -0700 Message-Id: <68FE4B67-3058-4F10-BCAD-C98F8AC2A154@deepdarc.com> References: <8E516169-CBA9-474E-8987-CD407CE94AD7@tzi.org> <4F0BFF23-C818-4E00-BD14-9B11350B3CAA@deepdarc.com> <28F2BCC2-A9CA-4D3A-81C4-740090168538@deepdarc.com> <0B60650D-2645-4EA4-B538-67DCC3186BA1@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: core Subject: Re: [core] Header suggestion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Oct 2010 00:09:06 -0000 --Apple-Mail-2--789038135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 10, 2010, at 4:04 PM, Carsten Bormann wrote: >> My concern is partially packet size, but it is also the ability to = parse larger amounts of data at layer 7. If we let Layer 3 (IP) or Layer = 2 (802.15.4+6LoWPAN) do the fragmentation, then we need to have enough = RAM to hold a single large packet. Using the method I was describing, = processing can be performed on large amounts of data (much larger than = 64k, the packet size limit for non-jumbo IPv6) incrementally by = constrained devices with little RAM at whatever pace they can work at. >=20 > Yes, that is one of the reasons the block option was invented (have = you looked at draft-bormann-core-coap-block-00.txt?), which works on = slices of resource representations, not on packets. I was not previously aware of draft-bormann-core-coap-block-00.txt. I've = had a look, and it looks like it is trying to solve the same problem, = but going about it in a different way. The block spec assumes that the = resource being requested can be accessed in a random-access fashion. = This would require a stateless 1wire traversal to be O(N^2) instead of = the more optimal O(N). My More/Next headers would allow parsing of a = 1wire traversal with O(n), but does not allow for random access. Both = mechanisms avoid creating conversation state on the server.=20 I'll examine the block spec in more detail, thanks for bringing it to my = attention. Perhaps there is some synergy in the approaches. > Semantic fragmentation may or may not simplify the handling of the = boundaries between the fragments; that depends a lot on a common = understanding of what good boundaries would be between client and = server. > In the end you need a media type specification if you want that = agreement. My hope was to avoid any changes at all to the actual content. As for = where to break up the original content, I suggest (for text formats) the = closest newline prior to the end of max size of content, and for binary = formats simply anywhere convenient. But even if we dropped the whole = "break things up by newlines" concept and go with simple = break-on-max-size, it would still be very useful. >> It actually seems less flexible to me, because it only works for the = "application/link-format" content-type. >=20 > The intention is certainly not that link-format is the only type that = carries links, so I don't understand why we would have that limitation. = XML/EXI and JSON certainly can carry links. Any new format you invent = can, too. What about formats already invented? What about images, or other = pre-existing binary formats? (Granted, the "Block" attribute is just as = suitable for images) >> CoAP-only proxies can ignore the headers entirely. CoAP-HTTP proxies = also have a clear way to work: >>=20 >> For HTTP->CoAP: you make an HTTP request and the proxy sends out a = CoAP request. It notices a More header, sends out the content to the = HTTP connection (but doesn't close it), and then sends out another CoAP = request with the Next header. This process would continue until the = entire content is retrieved, after which the connection is closed. To = the HTTP client it appeared to be a single request which loaded = gradually. >=20 > The proxy would need to understand how to aggregate the semantic = fragments into a larger representation. > I don't know how to do this in the general case (although I might be = able to cook up rules that work in certain cases for XML/EXI and JSON). With More/Next headers, aggregating the fragments into a larger = representation is easy: simple binary concatenation. Works for all = content-types. The only question is where do you define the boundaries = to be for splitting up large content. Originally my thought was to use = newlines for text files, and use the nearest byte boundary for binary = files. A single fragment doesn't need to be individually parsable = because you would never get an individual fragment without having parsed = all of the fragments before it.=20 >> For CoAP->HTTP: the proxy would receive the CoAP request and = translate that into an HTTP request. As the content comes in from the = HTTP response, the CoAP content buffer fills up and a CoAP response is = sent, along with a More header containing an Id to reference the current = connection. When the HTTP proxy receives the CoAP request with the = appropriate Next header, it dumps more http response content into the = CoAP response and sends that back to the CoAP client, including another = More header if necessary. >=20 > All this is done nicely on a sequence-of-bytes level by the block = option. > (Again, I don't know how to do this on a semantic level without = interpretation of the media type by the proxy.) >=20 > I think some of the disconnect here is that you seem to have a very = specific idea of the media types that you want to handle (e.g., there is = no concept of "lines" in JSON or EXI, so I wouldn't even know what = "More" would mean). "More" in that case would always have a defined value by the server and = would never be empty. The case where the "More" header is empty is an = optimization that the server may or may not choose to use, and it would = only use it if it made sense for the given content type. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-2--789038135 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
My concern is partially = packet size, but it is also the ability to parse larger amounts of data = at layer 7. If we let Layer 3 (IP) or Layer 2 (802.15.4+6LoWPAN) do the = fragmentation, then we need to have enough RAM to hold a single large = packet. Using the method I was describing, processing can be performed = on large amounts of data (much larger than 64k, the packet size limit = for non-jumbo IPv6) incrementally by constrained devices with little RAM = at whatever pace they can work at.

Yes, that is one = of the reasons the block option was invented (have you looked at = draft-bormann-core-coap-block-00.txt?), which works on slices of = resource representations, not on = packets.

I was not previously = aware of draft-bormann-core-coap-block-00.txt. I've had a look, and = it looks like it is trying to solve the same problem, but going about it = in a different way. The block spec assumes that the resource being = requested can be accessed in a random-access fashion. This would require = a stateless 1wire traversal to be O(N^2) instead of the more optimal = O(N). My More/Next headers would allow parsing of a 1wire traversal with = O(n), but does not allow for random access. Both mechanisms avoid = creating conversation state on the = server. 

I'll examine the block spec in = more detail, thanks for bringing it to my attention. Perhaps there is = some synergy in the approaches.

Semantic fragmentation may or may not simplify the = handling of the boundaries between the fragments; that depends a lot on = a common understanding of what good boundaries would be between client = and server.
In the end you need a media type specification if you = want that agreement.

My hope = was to avoid any changes at all to the actual content. As for where to = break up the original content, I suggest (for text formats) the closest = newline prior to the end of max size of content, and for binary formats = simply anywhere convenient. But even if we dropped the whole "break = things up by newlines" concept and go with simple break-on-max-size, it = would still be very useful.

It actually seems less = flexible to me, because it only works for the "application/link-format" = content-type.

The intention is certainly not that = link-format is the only type that carries links, so I don't understand = why we would have that limitation.  XML/EXI and JSON certainly can = carry links.  Any new format you invent can, = too.

What about formats = already invented? What about images, or other pre-existing binary = formats? (Granted, the "Block" attribute is just as suitable for = images)

CoAP-only proxies can ignore the headers entirely. = CoAP-HTTP proxies also have a clear way to = work:

For = HTTP->CoAP: you make an HTTP request and the proxy sends out a CoAP = request. It notices a More header, sends out the content to the HTTP = connection (but doesn't close it), and then sends out another CoAP = request with the Next header. This process would continue until the = entire content is retrieved, after which the connection is closed. To = the HTTP client it appeared to be a single request which loaded = gradually.

The proxy would need to understand how to = aggregate the semantic fragments into a larger representation.
I = don't know how to do this in the general case (although I might be able = to cook up rules that work in certain cases for XML/EXI and = JSON).

With More/Next headers, = aggregating the fragments into a larger representation is easy: simple = binary concatenation. Works for all content-types. The only question is = where do you define the boundaries to be for splitting up large content. = Originally my thought was to use newlines for text files, and use the = nearest byte boundary for binary files. A single fragment doesn't need = to be individually parsable because you would never get an individual = fragment without having parsed all of the fragments before = it. 

For CoAP->HTTP: the proxy would receive the CoAP = request and translate that into an HTTP request. As the content comes in = from the HTTP response, the CoAP content buffer fills up and a CoAP = response is sent, along with a More header containing an Id to reference = the current connection. When the HTTP proxy receives the CoAP request = with the appropriate Next header, it dumps more http response content = into the CoAP response and sends that back to the CoAP client, including = another More header if necessary.

All this is done = nicely on a sequence-of-bytes level by the block option.
(Again, I = don't know how to do this on a semantic level without interpretation of = the media type by the proxy.)

I think some of the disconnect here = is that you seem to have a very specific idea of the media types that = you want to handle (e.g., there is no concept of "lines" in JSON or EXI, = so I wouldn't even know what "More" would = mean).

"More" in that case = would always have a defined value by the server and would never be = empty. The case where the "More" header is empty is an optimization that = the server may or may not choose to use, and it would only use it if it = made sense for the given content type.



= --Apple-Mail-2--789038135-- From darco@deepdarc.com Mon Oct 11 12:01:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280883A6B66 for ; Mon, 11 Oct 2010 12:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulP8IhTpOy9r for ; Mon, 11 Oct 2010 12:01:02 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 488F63A6B73 for ; Mon, 11 Oct 2010 12:00:50 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id B897EB53DA4C; Mon, 11 Oct 2010 12:02:02 -0700 (PDT) X-AuditID: 11807137-b7b12ae000001ea3-86-4cb35f2abc67 Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id C5.CF.07843.A2F53BC4; Mon, 11 Oct 2010 12:02:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Robert Quattlebaum In-Reply-To: <68FE4B67-3058-4F10-BCAD-C98F8AC2A154@deepdarc.com> Date: Mon, 11 Oct 2010 12:02:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <795D570B-6921-48BC-BF86-847C7F81AA71@deepdarc.com> References: <8E516169-CBA9-474E-8987-CD407CE94AD7@tzi.org> <4F0BFF23-C818-4E00-BD14-9B11350B3CAA@deepdarc.com> <28F2BCC2-A9CA-4D3A-81C4-740090168538@deepdarc.com> <0B60650D-2645-4EA4-B538-67DCC3186BA1@tzi.org> <68FE4B67-3058-4F10-BCAD-C98F8AC2A154@deepdarc.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core Subject: [core] Feedback on draft-bormann-core-coap-block-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 19:01:04 -0000 So I've taken a closer look at draft-bormann-core-coap-block-00, and I = have some observations. It would appear that both the Block header and my More/Next proposal(1) = have the same goals, but have different strengths and weaknesses. The = key differences are: =95 draft-bormann-core-coap-block-00 has only one header, = whereas my More/Next proposal used two. (Although the More/Next = mechanism could easily be changed to require only one) =95 draft-bormann-core-coap-block-00 has strictly defined block = sizes, whereas my More/Next proposal does not (it is up to the server to = decide). =95 draft-bormann-core-coap-block-00 appears to have an upper = limit on the size of a single transfer, whereas my More/Next proposal = does not. =95 draft-bormann-core-coap-block-00 would appear to allow for = random access, although this is not covered or even mentioned in the = internet-draft. My More/Next proposal does not allow random access. =95 My More/Next proposal allows the server to store some = client-opaque state in the messages itself, freeing it from possibly = needing to store (or restore) state on the server. = draft-bormann-core-coap-block-00 does not allow this. Unless random access is an important feature, it seems like a more = flexible approach for dealing with result messages with large amounts of = content would be for the value of the block header to be entirely opaque = to the client. It's presence would indicate the existence of additional = content, and to retrieve that content an additional request containing = the block header and value from the previous response would be sent. = This approach would: =95 Allow for unbounded content-sizes. =95 Marginally simplify client implementation. =95 Give maximum flexibility to the server implementation. =95 Allow traversal state to be stored inside of the requests = themselves. (e.g.,this allows for O(n) 1-wire discovery; compared to = O(n^2) for the current block proposal) =95 Allow for arbitrary block sizes, at the discretion of the = server implementation. If random access turns out to be desirable for certain applications, = perhaps we could implement a "Range" header, analogous to that specified = in (2), specifically for the purpose of allowing random access. Thoughts? (1) : = [core] Header Suggestion (2) : = HTTP/1.1 Header Field Definitions, Sec 14.35 Range __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From rstruik.ext@gmail.com Tue Oct 12 09:22:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E43B3A6968 for ; Tue, 12 Oct 2010 09:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVx4r5IA-9hr for ; Tue, 12 Oct 2010 09:22:55 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DD4613A6976 for ; Tue, 12 Oct 2010 09:22:54 -0700 (PDT) Received: by gyc15 with SMTP id 15so926801gyc.31 for ; Tue, 12 Oct 2010 09:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=u2lRm58m0ILVrHaOmICyu66zo9M0m9Z935I0xB+WBZI=; b=Pq12XpPtA4fcroPsh88aPb05Liqm9Vcp5BpWK05+MH3GeJmf/qXhU0VrpIAzIDSh1T Dxls1RpUL+HPAV5h0HqrSxJ/AuxIiGdX9fNAbQ+rhZt/+Cvcw4m8pFI8uSS4HM2+Er+7 yuTMi+i6yjNZHb4JdnIZoLbUYZ/TwL8ZvXPwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=rk6zrQN/PjwqKMMtO7AtSU+LwWWYW2h2UU7r+KPSr1dX/n+4YeXXy43IX7JJD6jAi3 jWZ8UGSfU5pLrL/j5iM/5DA10ZQkjuDtUsMNI3IWOD/hMLOyHzCJ1o6rKMiiuXOPdUrV ayJkYifxQzbQNTfIuoRMd/YMNIzaeV1UroGE4= Received: by 10.150.181.18 with SMTP id d18mr3407196ybf.135.1286900647378; Tue, 12 Oct 2010 09:24:07 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id v34sm3971513yba.19.2010.10.12.09.24.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Oct 2010 09:24:06 -0700 (PDT) Message-ID: <4CB48B9B.9010206@gmail.com> Date: Tue, 12 Oct 2010 12:23:55 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Tobias Heer References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com> <4CA5E8E0.4030503@gmail.com> <4CA6095F.6040403@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050400040508070402040307" Cc: core Subject: Re: [core] HIP identities and puzzle X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Oct 2010 16:22:58 -0000 This is a multi-part message in MIME format. --------------050400040508070402040307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Tobias: Thanks for your note. Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing); (b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/ personalization stage? Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so, this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g., NIST? As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired" functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.) It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic properties. I would be happy to give this a look and review. Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list. Best regards, Rene [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT] To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help! > > In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.). > Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE. > > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would > allow trust lifecycle management to be reduced to proper management of device identifiers (i.e.,*no* entanglement of concepts from different > disciplines). Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming? On 07/10/2010 5:36 AM, Tobias Heer wrote: >> To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help! >> > >> > In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.). >> > > Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE. > >> > Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e.,*no* entanglement of concepts from different disciplines). > > Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming? > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------050400040508070402040307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit 
Hi Tobias:

Thanks for your note. 

Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing); 
(b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would 
correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/
personalization stage?

Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,
this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the 
difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g., 
NIST?

As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp 
post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper 
resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of
symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired" 
functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that
matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of
draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)

It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic
properties. I would be happy to give this a look and review. 

Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list.

Best regards, Rene


[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT]

To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated 
key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of 
the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; 
(c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise 
impersonation resilience, etc.).
>
Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to 
rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small 
setups). However, I am not absolutely firm with the envisaged scenarios in CORE.

> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would 
allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different 
disciplines).

 
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid 
entanglement of routing and naming?




On 07/10/2010 5:36 AM, Tobias Heer wrote: 
To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).
> 

Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.


> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).

 
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?




-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------050400040508070402040307-- From Akbar.Rahman@InterDigital.com Thu Oct 14 13:57:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C537A3A6B94 for ; Thu, 14 Oct 2010 13:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zelnu0HWoMGy for ; Thu, 14 Oct 2010 13:57:06 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id C95C73A6B9D for ; Thu, 14 Oct 2010 13:57:05 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 16:58:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 16:57:51 -0400 Message-ID: In-Reply-To: <20101014204502.278153A69A8@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft for Group Communication for CoAP Thread-Index: Actr4PDoI/rmJl1KQem2WBSbkySVOwAAPf7A References: <20101014204502.278153A69A8@core3.amsl.com> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 14 Oct 2010 20:58:24.0564 (UTC) FILETIME=[8ACCA740:01CB6BE2] Cc: core@ietf.org Subject: [core] Draft for Group Communication for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 20:57:06 -0000 Hi Carsten, Here is the draft on Group Communications for CoAP as per our action from the previous CORE Webex call. We look forward to comments from you and the rest of the WG. I acted as the editor for the document but got most of the technical input from all the people who contributed to the document as listed in the Acknowledgements section. I especially would like to thank Kerry Lynn who devoted a lot of time and energy in helping me put together this draft. Sincerely, Akbar -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, October 14, 2010 4:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-rahman-core-groupcomm-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Group Communication for CoAP Author(s) : A. Rahman Filename : draft-rahman-core-groupcomm-00.txt Pages : 14 Date : 2010-10-14 This is a working document intended to trigger discussion and develop draft language for the CoAP protocol specification in the area of group communication (including multicast functionality). Engineering tradeoffs become more challenging in constrained environments, therefore group communication is considered within the context of adjacent topics that may impact or be impacted by design choices in the subject area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rahman-core-groupcomm-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From fluffy@cisco.com Thu Oct 14 14:11:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7723D3A6BAA for ; Thu, 14 Oct 2010 14:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.436 X-Spam-Level: X-Spam-Status: No, score=-110.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kpXILS+G92l for ; Thu, 14 Oct 2010 14:11:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0F6593A6A3E for ; Thu, 14 Oct 2010 14:11:33 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcFAP4Ot0yrRN+K/2dsb2JhbACTJo18caUVnHyFSASEU4VzgwM X-IronPort-AV: E=Sophos;i="4.57,332,1283731200"; d="scan'208";a="269738380" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2010 21:12:29 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9ELCSQp006184 for ; Thu, 14 Oct 2010 21:12:28 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 15:12:28 -0600 Message-Id: <99F3C966-4A6C-4B84-BDBB-B72153C979A4@cisco.com> To: core@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Adoption of WG drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Oct 2010 21:11:39 -0000 My apologies for being late on this email. There are three drafts that = look ready for adoption as WG drafts. Unless I hear objections, I plan = to adopt the following drafts as working group documents.=20 draft-shelby-core-link-format with Zach Shelby as editor draft-hartke-coap-observe with Zach Shelby and Klaus Hartke as editors=20= draft-bormann-core-coap-block with Zach Shelby as editor I realize that there are ongoing discussions of changes to these, = particularly draft-bormann-core-coap-block, but these discussions can = continue as the documents proceed thought the working group. All we are = doing is choosing by adopting a working group draft is choosing an an = initial starting point. They can still be many significant changes made = to the draft before the working group agrees to it.=20 Please get back to me before 19:00 UTC on monday if you have = significant objections to adoption of these. I realize this is shorter = than typical but given the draft deadline and the currently discussion = of these at the last conference call, I believe this is the best path = forward.=20 Cullen From Gerald.Paprocki@us.elster.com Fri Oct 15 12:13:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5BD3A6A2B for ; Fri, 15 Oct 2010 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtR8hy6pMM-5 for ; Fri, 15 Oct 2010 12:13:49 -0700 (PDT) Received: from mail196.messagelabs.com (mail196.messagelabs.com [216.82.254.67]) by core3.amsl.com (Postfix) with SMTP id 5A35F3A693E for ; Fri, 15 Oct 2010 12:13:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-12.tower-196.messagelabs.com!1287170113!40115501!5 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 23391 invoked from network); 15 Oct 2010 19:15:15 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-12.tower-196.messagelabs.com with SMTP; 15 Oct 2010 19:15:15 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: core@ietf.org Message-ID: Date: Fri, 15 Oct 2010 15:15:10 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 10/15/2010 03:09:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [core] AUTO: Gerald Paprocki is out of the office (returning 10/18/2010) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Oct 2010 19:13:51 -0000 I am out of the office until 10/18/2010. I will be out of the office starting Wednesday 10/13 and returning to the office Monday 10/18. While I am away I will not have access to my email or phone messages. If you need immediate assistance please contact: Dana Merrill at 919-250-5484 or by e-mail at Dana.Merrill@us.elster.com. Note: This is an automated response to your message "core Digest, Vol 9, Issue 9" sent on 10/15/2010 3:00:09 PM. This is the only notification you will receive while this person is away. From j.schoenwaelder@jacobs-university.de Fri Oct 15 14:43:36 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96BB73A6B4D for ; Fri, 15 Oct 2010 14:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.769 X-Spam-Level: X-Spam-Status: No, score=-100.769 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_20=-0.74, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxTVTr6VP8JR for ; Fri, 15 Oct 2010 14:43:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AE6E53A68E0 for ; Fri, 15 Oct 2010 14:43:35 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85E04C0007 for ; Fri, 15 Oct 2010 23:44:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BBaAwPQyPWq0; Fri, 15 Oct 2010 23:44:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D27E4C0006; Fri, 15 Oct 2010 23:44:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 534B61532ACC; Fri, 15 Oct 2010 23:44:14 +0200 (CEST) Date: Fri, 15 Oct 2010 23:44:14 +0200 From: Juergen Schoenwaelder To: core@ietf.org Message-ID: <20101015214414.GA4737@elstar.local> Mail-Followup-To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 21:43:36 -0000 Hi, I recently read the CoAP document and I have a question that was already discussed here in July. The question is: How can I reliably match the responses to asynchronous requests? It seems that there is a missing identifier for the request/response transactions on the upper CoAP layer. The text says that the URI is echoed back, which however may not be sufficient and it is relatively expensive in terms of the number of octets needed. Did you consider other approaches, e.g. using option in the first ACK that carries a upper transaction identifier (utid) and that will also be shipped with the following CON message? Client Server | | | CON tid=48 | | code=GET http://n.. | +-------------------->| | | | ACK tid=48 | | code=000 [etid=42] | |<--------------------+ | | ... Time Passes ... | | | CON tid=783 | | code=200 [etid=42] | |<--------------------+ | | | ACK tid=783 | | code=000 [etid=42] | +-------------------->| | | I just saw that something similar has been suggested in coap-misc-06. However, the text in coap-misc-06 seems to suggest that the client invoking the method needs to send the token; since the client does not control whether a request is processed in synchronous or asynchronous mode, it seems better to let the server generate a token when needed. (This also saves space in the request that has to carry the URI.) /js PS: I changed the style of the figure, trying to make it clearer that both the method and the response code are carried in the same field, also putting options in brackets. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cabo@tzi.org Fri Oct 15 22:32:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642D33A6A98; Fri, 15 Oct 2010 22:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.167 X-Spam-Level: X-Spam-Status: No, score=-106.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-85fBSlHTkU; Fri, 15 Oct 2010 22:32:31 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 92F233A69EE; Fri, 15 Oct 2010 22:32: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 o9G5XZcp022925; Sat, 16 Oct 2010 07:33:35 +0200 (CEST) Received: from [192.168.217.101] (p5489FB26.dip.t-dialin.net [84.137.251.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F28E5948; Sat, 16 Oct 2010 07:33:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sat, 16 Oct 2010 07:33:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: 6lowpan 6lowpan <6lowpan@ietf.org>, core , ROLL WG X-Mailer: Apple Mail (2.1081) Subject: [core] (Update:) Constrained node/network cluster at IETF 79 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 05:32:46 -0000 The "final" agenda for IETF79 has been posted. Note that ROLL has moved to Thursday. As usual, even "final" IETF agenda may still change, so please do not = make the below the basis for your travel planning. For your planning convenience, this is a set of WG meetings at IETF79 = that I've informally referring to as the "constrained node/network = cluster". Of course, there are a lot of additional WG meetings relevant = to that cluster. Gruesse, Carsten * MONDAY, November 8, 2010 1510-1610 Afternoon Session II Emerald APP core Constrained RESTful = Environments WG * TUESDAY, November 9, 2010 0900-1130 Morning Session I Valley Ballroom B INT 6man IPv6 Maintenance WG Garden Ballroom 1 IRTF HIPRG Host Identity Protocol=20= 1520-1810 Afternoon Session II/III Valley Ballroom A INT 6lowpan IPv6 over Low power WPAN = WG * WEDNESDAY, November 10, 2010 0900-1130 Morning Session I Emerald APP core Constrained RESTful = Environments WG 1510-1610 Afternoon Session II Valley Ballroom A INT lwip Light-Weight IP Protocol = Design BOF * THURSDAY, November 11, 2010 1300-1500 Afternoon Session I Valley Ballroom A RTG roll Routing Over Low power = and Lossy networks WG From darco@deepdarc.com Sun Oct 17 11:46:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1743A6BB3 for ; Sun, 17 Oct 2010 11:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoCTcc66fEFB for ; Sun, 17 Oct 2010 11:46:41 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id EFE1F3A6B02 for ; Sun, 17 Oct 2010 11:46:40 -0700 (PDT) Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:43848 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P7YH6-0004P3-G5; Sun, 17 Oct 2010 14:48:04 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-17--203562530 From: Robert Quattlebaum In-Reply-To: <20101015214414.GA4737@elstar.local> Date: Sun, 17 Oct 2010 11:48:02 -0700 Message-Id: <83946E3D-F141-4C70-B69E-30A355D54163@deepdarc.com> References: <20101015214414.GA4737@elstar.local> To: core X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Subject: Re: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 18:46:42 -0000 --Apple-Mail-17--203562530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Juergen! On Oct 15, 2010, at 2:44 PM, Juergen Schoenwaelder wrote: > I recently read the CoAP document and I have a question that was > already discussed here in July. The question is: >=20 > How can I reliably match the responses to asynchronous requests? I was just about to start a new thread to discuss this (and a possible = solution), but since you started this one I'll go ahead and talk about = that here. :) In my opinion the current answer to your question is simple: You = can't---at least not reliably, or easily, or efficiently. Obviously this is a problem.=20 > It seems that there is a missing identifier for the request/response > transactions on the upper CoAP layer. The text says that the URI is > echoed back, which however may not be sufficient and it is relatively > expensive in terms of the number of octets needed. >=20 > Did you consider other approaches, e.g. using option in the first ACK > that carries a upper transaction identifier (utid) and that will also > be shipped with the following CON message? Using the same TID as the first transaction isn't a good enough solution = though: Think about the case where a device is sending a CoAP request to = itself and some of the packets are dropped. Confusion ensues. There are = likely other subtle issues that are not immediately obvious. As Carsten = once mentioned to me off-list, these types of things are unfortunately = non-trivial.=20 Another alternative, which you mentioned, involves clients adding a = Token option to every request transaction they send (because you can't = predict ahead of time which responses will be asynchronous), but that is = obviously wasteful---if effectively adds another three bytes to the CoAP = minimal overhead. But... I have come up with what I believe to be an optimal solution to this = problem, requiring minimal changes to the CoAP spec: Instead of using an arbitrary TID for the async response transaction, we = should define the TID of the second transaction to be the one's = complement (bitwise invert) of the original request TID. This would make = it easy to correlate async responses to the original requests without = using the same numeric TID for both transactions. This fixes the = talking-to-yourself problem and would probably rectify other issues as = well.=20 For all I know something like this may have been suggested before and = dismissed for a good (but not obvious) reason. However, it seems to, at = least superficially, address everyone's concerns. I would love to hear some thoughts about this suggestion. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-17--203562530 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = recently read the CoAP document and I have a question that = was
already discussed here in July. The question is:

 How = can I reliably match the responses to asynchronous = requests?

I was just about to start = a new thread to discuss this (and a possible solution), but since you = started this one I'll go ahead and talk about that here. = :)

In my opinion the current answer to your question = is simple: You can't---at least not reliably, or easily, or = efficiently.

Obviously this is a = problem. 

It = seems that there is a missing identifier for the = request/response
transactions on the upper CoAP layer. The text says = that the URI is
echoed back, which however may not be sufficient and = it is relatively
expensive in terms of the number of octets = needed.

Did you consider other approaches, e.g. using option in = the first ACK
that carries a upper transaction identifier (utid) and = that will also
be shipped with the following CON = message?

Using the same = TID as the first transaction isn't a good enough solution though: Think = about the case where a device is sending a CoAP request to itself and = some of the packets are dropped. Confusion ensues. There are likely = other subtle issues that are not immediately obvious. As Carsten once = mentioned to me off-list, these types of things are unfortunately = non-trivial. 

Another alternative, which = you mentioned, involves clients adding a Token option to every request = transaction they send (because you can't predict ahead of time which = responses will be asynchronous), but that is obviously wasteful---if = effectively adds another three bytes to the CoAP minimal = overhead.

But...

I = have come up with what I believe to be an optimal solution to this = problem, requiring minimal changes to the CoAP = spec:

Instead of using an arbitrary TID for = the async response transaction, we should define the TID of the second = transaction to be the one's complement (bitwise invert) of the original = request TID. This would make it easy to correlate async responses to = the original requests without using the same numeric TID for both = transactions. This fixes the talking-to-yourself problem and would = probably rectify other issues as = well. 

For all I know something like this = may have been suggested before and dismissed for a good (but not = obvious) reason. However, it seems to, at least superficially, address = everyone's concerns.

I would love to hear some = thoughts about this suggestion.



= --Apple-Mail-17--203562530-- From j.schoenwaelder@jacobs-university.de Sun Oct 17 13:50:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FA13A6BF2 for ; Sun, 17 Oct 2010 13:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.693 X-Spam-Level: X-Spam-Status: No, score=-100.693 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_50=0.001, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76DPf5UMbxZ9 for ; Sun, 17 Oct 2010 13:50:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BB3963A6BFB for ; Sun, 17 Oct 2010 13:50:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6402C001A; Sun, 17 Oct 2010 22:51:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gsHX2Qjcz2gn; Sun, 17 Oct 2010 22:51:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC0D0C0002; Sun, 17 Oct 2010 22:51:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A5F331562FB9; Sun, 17 Oct 2010 22:50:52 +0200 (CEST) Date: Sun, 17 Oct 2010 22:50:52 +0200 From: Juergen Schoenwaelder To: Robert Quattlebaum Message-ID: <20101017205051.GA14937@elstar.local> Mail-Followup-To: Robert Quattlebaum , core References: <20101015214414.GA4737@elstar.local> <83946E3D-F141-4C70-B69E-30A355D54163@deepdarc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83946E3D-F141-4C70-B69E-30A355D54163@deepdarc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: core Subject: Re: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 20:50:43 -0000 On Sun, Oct 17, 2010 at 11:48:02AM -0700, Robert Quattlebaum wrote: > > It seems that there is a missing identifier for the request/response > > transactions on the upper CoAP layer. The text says that the URI is > > echoed back, which however may not be sufficient and it is relatively > > expensive in terms of the number of octets needed. > > > > Did you consider other approaches, e.g. using option in the first ACK > > that carries a upper transaction identifier (utid) and that will also > > be shipped with the following CON message? > > > Using the same TID as the first transaction isn't a good enough solution though: Think about the case where a device is sending a CoAP request to itself and some of the packets are dropped. Confusion ensues. There are likely other subtle issues that are not immediately obvious. As Carsten once mentioned to me off-list, these types of things are unfortunately non-trivial. > > Another alternative, which you mentioned, involves clients adding a Token option to every request transaction they send (because you can't predict ahead of time which responses will be asynchronous), but that is obviously wasteful---if effectively adds another three bytes to the CoAP minimal overhead. I did not propose to use the same TID nor did I propose that the client sends a token in every CON. I thought my proposal was clear, but apparently not. (I even included a figure in my original post.) > Instead of using an arbitrary TID for the async response transaction, we should define the TID of the second transaction to be the one's complement (bitwise invert) of the original request TID. This would make it easy to correlate async responses to the original requests without using the same numeric TID for both transactions. This fixes the talking-to-yourself problem and would probably rectify other issues as well. I doubt this works since the TIDs other clients may use in the future are unpredictable and so I run into rare but possible conflicts with TIDs I have been using to talk with clients and TIDs clients want me to use in asynchronous responses. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From darco@deepdarc.com Sun Oct 17 15:07:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3533A6C13 for ; Sun, 17 Oct 2010 15:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNLo-qkJ8KQ2 for ; Sun, 17 Oct 2010 15:07:22 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 2B5373A6C12 for ; Sun, 17 Oct 2010 15:07:21 -0700 (PDT) Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:38265 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P7bPL-00085t-0a; Sun, 17 Oct 2010 18:08:47 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-18--191519982 From: Robert Quattlebaum In-Reply-To: <20101017205051.GA14937@elstar.local> Date: Sun, 17 Oct 2010 15:08:45 -0700 Message-Id: <7A26777C-8F24-4549-9B6E-95F6548F2F54@deepdarc.com> References: <20101015214414.GA4737@elstar.local> <83946E3D-F141-4C70-B69E-30A355D54163@deepdarc.com> <20101017205051.GA14937@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: core Subject: Re: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 22:07:23 -0000 --Apple-Mail-18--191519982 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Juergen! On Oct 17, 2010, at 1:50 PM, Juergen Schoenwaelder wrote: > On Sun, Oct 17, 2010 at 11:48:02AM -0700, Robert Quattlebaum wrote: >=20 > I did not propose to use the same TID nor did I propose that the > client sends a token in every CON. I thought my proposal was clear, > but apparently not. (I even included a figure in my original post.) Sorry, for some reason when I first looked at the diagram I thought I = saw TID's that were the same for the original request and the async = response. Looking at it again, it is quite clear that they are not. I = must have gotten my eyes crossed. I apologize for my misunderstanding, = I'll make an attempt to read more carefully in the future. >> Instead of using an arbitrary TID for the async response transaction, = we should define the TID of the second transaction to be the one's = complement (bitwise invert) of the original request TID. This would make = it easy to correlate async responses to the original requests without = using the same numeric TID for both transactions. This fixes the = talking-to-yourself problem and would probably rectify other issues as = well.=20 >=20 > I doubt this works since the TIDs other clients may use in the future > are unpredictable and so I run into rare but possible conflicts with > TIDs I have been using to talk with clients and TIDs clients want me > to use in asynchronous responses. Good point. This can be fixed by also defining that the MSB of the TID = of a synchronous request must always be set to 0. Then there would never = be such a conflict, because the TID of the async response would always = have the MSB set (and, thus, it is always a value that would never be = chosen by that client otherwise).=20 In any case, I agree that some sort of solution (whether yours, mine, or = something else) is needed. Async responses are incredibly awkward to use = otherwise.=20 __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-18--191519982 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Sun, Oct 17, 2010 at 11:48:02AM -0700, Robert Quattlebaum = wrote:

I = did not propose to use the same TID nor did I propose that the
client = sends a token in every CON. I thought my proposal was clear,
but = apparently not. (I even included a figure in my original = post.)

Sorry, for some reason = when I first looked at the diagram I thought I saw TID's that were the = same for the original request and the async response. Looking at it = again, it is quite clear that they are not. I must have gotten my eyes = crossed. I apologize for my misunderstanding, I'll make an attempt to = read more carefully in the future.

Instead of using an = arbitrary TID for the async response transaction, we should define the = TID of the second transaction to be the one's complement (bitwise = invert) of the original request TID. This would make it easy to = correlate async responses to the original requests without using the = same numeric TID for both transactions. This fixes the = talking-to-yourself problem and would probably rectify other issues as = well.

I doubt this works since the TIDs other = clients may use in the future
are unpredictable and so I run into = rare but possible conflicts with
TIDs I have been using to talk with = clients and TIDs clients want me
to use in asynchronous = responses.

Good point. = This can be fixed by also defining that the MSB of the TID of a = synchronous request must always be set to 0. Then there would never be = such a conflict, because the TID of the async response would always have = the MSB set (and, thus, it is always a value that would never be chosen = by that client otherwise). 

In any case, I = agree that some sort of solution (whether yours, mine, or something = else) is needed. Async responses are incredibly awkward to use = otherwise. 



= --Apple-Mail-18--191519982-- From darco@deepdarc.com Sun Oct 17 15:17:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86B13A6C17 for ; Sun, 17 Oct 2010 15:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, GB_ABOUTYOU=0.5, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+4o6p8JZdEv for ; Sun, 17 Oct 2010 15:17:30 -0700 (PDT) Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id AB0DF3A6C16 for ; Sun, 17 Oct 2010 15:17:30 -0700 (PDT) Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:37488 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P7bZA-0000HY-6k; Sun, 17 Oct 2010 18:18:56 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: <20101015214414.GA4737@elstar.local> Date: Sun, 17 Oct 2010 15:18:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30FAC23C-F611-429B-B823-DD2F862A2244@deepdarc.com> References: <20101015214414.GA4737@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spider.nocdirect.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deepdarc.com Cc: core@ietf.org Subject: Re: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 22:17:32 -0000 I just wanted to address some individual observations about your = original message.=20 On Oct 15, 2010, at 2:44 PM, Juergen Schoenwaelder wrote: > Did you consider other approaches, e.g. using option in the first ACK > that carries a upper transaction identifier (utid) and that will also > be shipped with the following CON message? >=20 > Client Server > | | > | CON tid=3D48 | > | code=3DGET http://n.. | > +-------------------->| > | | > | ACK tid=3D48 | > | code=3D000 [etid=3D42] | > |<--------------------+ > | | > ... Time Passes ... > | | > | CON tid=3D783 | > | code=3D200 [etid=3D42] | > |<--------------------+ > | | > | ACK tid=3D783 | > | code=3D000 [etid=3D42] | > +-------------------->| > | | I'm not sure if this was considered or not, but this sounds like a much = more reasonable approach than relying solely on the URI-path parameter. = Including the URI-path option is probably still useful for certain = applications, but alone it seems problematic. I would like to make a small suggestion. Might it be easier to simply = use the original TID as the value of your etid/utid option, instead of = an entirely new identifier? The resulting timeline would then look like = this: Client Server | | | CON tid=3D48 | | code=3DGET http://n.. | +-------------------->| | | | ACK tid=3D48 | | code=3D000 | |<--------------------+ | | ... Time Passes ... | | | CON tid=3D783 | | code=3D200 [etid=3D48] | |<--------------------+ | | | ACK tid=3D783 | | code=3D000 | +-------------------->| | | > I just saw that something similar has been suggested in coap-misc-06. > However, the text in coap-misc-06 seems to suggest that the client > invoking the method needs to send the token; since the client does not > control whether a request is processed in synchronous or asynchronous > mode, it seems better to let the server generate a token when needed. > (This also saves space in the request that has to carry the URI.) I agree entirely with this sentiment. > PS: I changed the style of the figure, trying to make it clearer that > both the method and the response code are carried in the same > field, also putting options in brackets. Again, I apologize for my misunderstanding earlier. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From cabo@tzi.org Sun Oct 17 16:26:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AA33A6C32 for ; Sun, 17 Oct 2010 16:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.168 X-Spam-Level: X-Spam-Status: No, score=-106.168 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIIGa5RVdNmn for ; Sun, 17 Oct 2010 16:26:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A4F723A6A6A for ; Sun, 17 Oct 2010 16:25:59 -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 o9HNRI55009651; Mon, 18 Oct 2010 01:27:19 +0200 (CEST) Received: from [192.168.217.101] (p5489BCCF.dip.t-dialin.net [84.137.188.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 862F0AD1; Mon, 18 Oct 2010 01:27:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <20101015214414.GA4737@elstar.local> Date: Mon, 18 Oct 2010 01:27:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101015214414.GA4737@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 23:26:01 -0000 On Oct 15, 2010, at 23:44, Juergen Schoenwaelder wrote: > How can I reliably match the responses to asynchronous requests? I don't have time right now to do a detailed response, but my question = would be: Why do you want to? (If you indeed need to, that's what the token was meant for. And yes, = the idea of a server-supplied token/ticket/promise/... is interesting, = so we should discuss this. But for now I'd like to understand what = specific motivation you have for wanting the binding.) One of the interesting properties of asynchronous responses is that they = are self-describing. They could be sent by multicast and would still = work. So what do we gain by binding them to a specific request? (Yes, I'm focusing on GET requests here.) One of the nice things about CoAP is that it is not trying to be a = generic transaction protocol with a REST protocol layered on top, but a = REST protocol with a transaction protocol purpose-built to serve just = the REST protocol. Gruesse, Carsten From zach@sensinode.com Mon Oct 18 06:11:48 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3727C3A6DE6 for ; Mon, 18 Oct 2010 06:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU+wegvrhu5g for ; Mon, 18 Oct 2010 06:11:42 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DE4AF3A6DBD for ; Mon, 18 Oct 2010 06:10:40 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9IDC3qo009722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 18 Oct 2010 16:12:04 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-1871--137318752; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 18 Oct 2010 16:12:06 +0300 References: <20101018130806.3E4F23A6DC2@core3.amsl.com> To: core Message-Id: <9E276E07-2377-48FA-A528-438D43642F07@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Fwd: New Version Notification for draft-shelby-core-coap-req-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 13:11:48 -0000 --Apple-Mail-1871--137318752 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii http://www.ietf.org/internet-drafts/draft-shelby-core-coap-req-02.txt As requested from some people in the WG, I re-submitted this document so = that it stays active while we are working on this charter. Read through = it quickly but didn't find any need to make technical changes. As = currently stands there is no plan to publish this as an RFC, it is more = for reference as we work on protocol design. =20 Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: October 18, 2010 4:08:06 PM GMT+03:00 > To: zach@sensinode.com > Cc: = Michael.Stuber@itron.com,d.sturek@att.net,brian.tridium@gmail.com,richard.= kelsey@ember.com > Subject: New Version Notification for draft-shelby-core-coap-req-02=20 >=20 >=20 > A new version of I-D, draft-shelby-core-coap-req-02.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-coap-req > Revision: 02 > Title: CoAP Requirements and Features > Creation_date: 2010-10-18 > WG ID: Independent Submission > Number_of_pages: 10 >=20 > Abstract: > This document considers the requirements for the design of the > Constrained Application Protocol (CoAP). The goal of the document is > to provide a basis for protocol design and related discussion. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-1871--137318752 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxODEzMTIw NlowIwYJKoZIhvcNAQkEMRYEFKzKhguIHRHRdAvBRRlspB+ZEr7mMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAB7arSIgFRFwKaLB2KKio/6vgKVQhf//vVXZdZ/tsXgUoI6PlNllN1dy GIJF3MQ/IWiJc3fHUoEJhCiRnQK38ypl/ATw5ZDKYWZ4WXHzTH+DKYDllXNCIZfroJgPBUi/97EE GrfwLA0ympXAkg+jNW+tLo55aDpGi++bRIqFivEMJ3jtY7ZUX4Qg7XqRVDIAuaDEh2c17WdDxiZH DW4o6y8bYU7mY+yz4tK4yaQPc3VMD4EhL5hwJ2WjzTa9Dgo+UBPt2RI8pT/UdkYY81BwpN8jB27U aieD4ZJp8wyvIQ0OMeTjSWZ4WvvG0BnzWhbsdSscSJ2Pabt4N/u6NSuQhloAAAAAAAA= --Apple-Mail-1871--137318752-- From zach@sensinode.com Mon Oct 18 07:43:02 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C931F3A6D4B for ; Mon, 18 Oct 2010 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K02dDI4YrjVN for ; Mon, 18 Oct 2010 07:42:56 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7B5E13A6CF9 for ; Mon, 18 Oct 2010 07:42:52 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9IEiGBk018252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Oct 2010 17:44:17 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-1881--131785806; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 18 Oct 2010 17:44:19 +0300 Message-Id: References: <20101015214414.GA4737@elstar.local> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 14:43:02 -0000 --Apple-Mail-1881--131785806 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd like to add to this discussion that we actually have two types of = asynchronous responses: 1. Delayed response to a request like in Section 2.1.2 of coap-02. 2. Repeated responses to a subscription as in hartke-coap-observe-02. = This already discuses the possible use of Tokens. In cases of a delayed GET response or a notification to a subscription, = the URI is enough for most use cases. For example when a proxy is using = subscriptions to update a cache, which then serves HTTP clients via = polling, identification using the URI makes the most sense. I do see how = optionally including a Token saves space and makes more sense for = certain applications. So leave it up to the client to include a Token in = a request. If a Token is present in a request, the server simply = includes that instead of a URI.=20 For delayed responses to POST, PUT, DELETE, it might make more sense to = always use a Token. Here we can either require a client to always = include a Token (might now make sense), or for the server to generate a = Token in the ACK to a request that can't be answered. The same Token is = then expected by the client in the delayed response. The same would = obviously apply to delayed GET.=20 So I agree with Carsten, for GET cases we don't need to require a Token, = but might want to use it in some cases. For delayed responses in general = it might make sense to let the server generate the Token in the ACK as = the client doesn't know if the response will be delayed or not. Zach =20 On Oct 18, 2010, at 2:27 AM, Carsten Bormann wrote: > On Oct 15, 2010, at 23:44, Juergen Schoenwaelder wrote: >=20 >> How can I reliably match the responses to asynchronous requests? >=20 > I don't have time right now to do a detailed response, but my question = would be: > Why do you want to? >=20 > (If you indeed need to, that's what the token was meant for. And yes, = the idea of a server-supplied token/ticket/promise/... is interesting, = so we should discuss this. But for now I'd like to understand what = specific motivation you have for wanting the binding.) >=20 > One of the interesting properties of asynchronous responses is that = they are self-describing. They could be sent by multicast and would = still work. >=20 > So what do we gain by binding them to a specific request? > (Yes, I'm focusing on GET requests here.) >=20 > One of the nice things about CoAP is that it is not trying to be a = generic transaction protocol with a REST protocol layered on top, but a = REST protocol with a transaction protocol purpose-built to serve just = the REST protocol. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-1881--131785806 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxODE0NDQx OVowIwYJKoZIhvcNAQkEMRYEFNjMeJYV9CqNTxcXmpz6my7I2KDAMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAA7lfBvRPeJ0ORI5y4qXVBFVLbeVSOmOkyaNn+OITYapHdYndn1TmO3z MLGFZUeB6A0GBJn2ciIuo85fuT4xcqIEJjhJyIXFj/z1UCdJaJrcM4Ddz8M/2W5khdhswbFAYjMp ghiLTbyFH+eC1UYSsxjGvkxh6wIUI9BSXHHGjLa/KaXAWHmVLI5Eqg1sHDByZgVv35YIP/1QeSQu hDiO7TO7gUTIBmEjyRrIkY/1x9hcrIw+LEcX+Cho+Kqzqz2oS3Mi5BlpOjXjio/XiNk+7DCbyR/r jIaYGS77DdzWWQnDEqxfm+MJMVdzN/wDyQaD4KikbpE55KNWA6BOYal0pb4AAAAAAAA= --Apple-Mail-1881--131785806-- From trac@tools.ietf.org Mon Oct 18 07:53:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4983A6CB7 for ; Mon, 18 Oct 2010 07:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9ox+XE9ScOe for ; Mon, 18 Oct 2010 07:53:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2B8B23A6CDE for ; Mon, 18 Oct 2010 07:53:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P7r6x-00014I-Op; Mon, 18 Oct 2010 07:54:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Mon, 18 Oct 2010 14:54:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/25#comment:1 Message-ID: <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> References: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #25 (new): Token option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 14:53:29 -0000 #25: Token option Comment(by zach@…): Based on the discussions on the mailing list showing interest in developing and testing the Token option further, I suggest that we do add the Token option to coap-03 as Option ID 11 (Critical) as per coap-misc-06 (ok, this draft doesn't say much about it...). Simple rules: 1. If a Token Option is included in a request, the response (and any subsequent delayed responses) MUST include the same value in a Token Option. 2. If a Token Option is included in a request, any resulting delayed response SHOULD NOT include the URI option (for sake of efficiency) as the Token is sufficient for matching it with the request. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: minor | Milestone: coap-03 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From zach@sensinode.com Mon Oct 18 07:57:26 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C89C3A6CB7 for ; Mon, 18 Oct 2010 07:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1SM2hFWxIQs for ; Mon, 18 Oct 2010 07:57:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9A1433A6D93 for ; Mon, 18 Oct 2010 07:55:35 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9IEux2Z018903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Oct 2010 17:57:00 +0300 From: Zach Shelby Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-1882--131022663; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 18 Oct 2010 17:57:02 +0300 In-Reply-To: <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> To: Carsten Bormann , core References: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> Message-Id: <144592F1-DA1E-4A32-95FE-0E7EB18A1B1D@sensinode.com> X-Mailer: Apple Mail (2.1081) Subject: Re: [core] coap #25 (new): Token option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 14:57:26 -0000 --Apple-Mail-1882--131022663 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is just to remind everyone that we do have a ticket open for the WG = to consider adding the Token Option to coap-03. Since the cutoff for = that is next Monday better to get started now. Below are a couple simple = rules for doing this to get started with. The goal would be to gain some = more implementation experience on this in the Beijing plug-fest, = although quite many of us are already using tokens (and did so in the = last plugfest already). Thoughts? Zach On Oct 18, 2010, at 5:54 PM, core issue tracker wrote: > #25: Token option >=20 >=20 > Comment(by zach@=85): >=20 > Based on the discussions on the mailing list showing interest in > developing and testing the Token option further, I suggest that we do = add > the Token option to coap-03 as Option ID 11 (Critical) as per = coap-misc-06 > (ok, this draft doesn't say much about it...). >=20 > Simple rules: >=20 > 1. If a Token Option is included in a request, the response (and any > subsequent delayed responses) MUST include the same value in a Token > Option. >=20 > 2. If a Token Option is included in a request, any resulting delayed > response SHOULD NOT include the URI option (for sake of efficiency) as = the > Token is sufficient for matching it with the request. >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: zach@=85 | Owner: cabo@=85 =20 > Type: enhancement | Status: new =20 > Priority: minor | Milestone: coap-03 =20 > Component: coap | Version: =20 > Severity: - | Keywords: =20 > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: = > core >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-1882--131022663 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxODE0NTcw MlowIwYJKoZIhvcNAQkEMRYEFKbNstePRfOf8QLiCcLsRF0z30pEMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAKIEXuuHe6zSYYkVj6cBV6u/zBlDe92sI7Ia2Zm3SvbAqJSwd0zuarq6 3RmIxUhJoSGNGd1rcNX/cPKz6qd6b3k+RTtdE0mx9ZMKXjiX60E+ZseFVFdAtdJboDC9WJ7yWw+F h5AMpGH4Nbg3kPZTFrGUJ1QOFxzQQW20L4UN/wvk2I6mHSVFWQ0v/PMfl3IRpucP3uKw3s0LBOlB MyMbKPhVBGaj9Wc9tyrIxBWnYshcNNESSJzh/VbLnXzJQo315ZGDMF7em7jrP0vo9ZgpSqcXk6Et vaHknY8ajgoNuojJk995/EedMgKZCiXbS4uF9vWJAM+dFrc/dB6toF/rgN4AAAAAAAA= --Apple-Mail-1882--131022663-- From pab@peoplepowerco.com Mon Oct 18 07:57:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E293A6CAF for ; Mon, 18 Oct 2010 07:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKLz1ttqDNbR for ; Mon, 18 Oct 2010 07:57:50 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 7BAAF3A6C77 for ; Mon, 18 Oct 2010 07:57:50 -0700 (PDT) Received: by vws12 with SMTP id 12so515828vws.31 for ; Mon, 18 Oct 2010 07:59:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.226.8 with SMTP id d8mr2463570mur.125.1287413957745; Mon, 18 Oct 2010 07:59:17 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Mon, 18 Oct 2010 07:59:17 -0700 (PDT) In-Reply-To: References: <20101015214414.GA4737@elstar.local> Date: Mon, 18 Oct 2010 09:59:17 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e6dd8be3a162120492e56b5e Cc: core@ietf.org Subject: Re: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 14:57:52 -0000 --0016e6dd8be3a162120492e56b5e Content-Type: text/plain; charset=ISO-8859-1 The problem is that an asynchronous response is a new CoAP transaction which provides the ReST response in a ReST transaction where the request was a previous, now completed, CoAP transaction. The transaction ID is irrelevant to the ReST level, so should not be relied upon to do the correlation, but something does need to indicate that an incoming message is the response component of a specific ReST transaction. The Token option seems to satisfy this requirement adequately. I would argue that, if a server cannot provide a response in the transaction acknowledgement, and was not provided a Token to use to couple its eventual response to the original request, the request must be rejected because there is no facility to correlate the response to the request. Another error code is required. Robert's alternative of an XOR'd transaction ID would eliminate this requirement, though we'd have to reserve a bit as always zero in origin TIDs to ensure an origin server doesn't end up using the same TID "too soon" for two transactions (one originating with it, and one mandated by a response to a client). Probably also have to relax the requirement on increasing TIDs from an endpoint. Messy, but doable. I'd use the Token: some clients may not be able to support asynchronous responses (can't hold the pending state while other transactions occur), and leaving it up to the client to control their use simplifies their implementation. Carsten, it sounds like you're proposing use of a split ReST transaction mechanism. This is an interesting approach that might provide a solution for reconciling multicast at the transport level with ReST. If all CoAP transactions destined for a multicast address were treated as asynchronous, and the responses were new ReST transactions, consistency could be maintained. But I don't think it works without a lot more detail. Unless you want CON to become a ReST operation like GET, which I think has a lot of consequences. It may be too late to work those out. Or if you accept the premise that a ReST GET can legitimately elicit multiple state representations in response. I still don't, but won't bother arguing about it any more. Peter On Sun, Oct 17, 2010 at 6:27 PM, Carsten Bormann wrote: > On Oct 15, 2010, at 23:44, Juergen Schoenwaelder wrote: > > > How can I reliably match the responses to asynchronous requests? > > I don't have time right now to do a detailed response, but my question > would be: > Why do you want to? > > (If you indeed need to, that's what the token was meant for. And yes, the > idea of a server-supplied token/ticket/promise/... is interesting, so we > should discuss this. But for now I'd like to understand what specific > motivation you have for wanting the binding.) > > One of the interesting properties of asynchronous responses is that they > are self-describing. They could be sent by multicast and would still work. > > So what do we gain by binding them to a specific request? > (Yes, I'm focusing on GET requests here.) > > One of the nice things about CoAP is that it is not trying to be a generic > transaction protocol with a REST protocol layered on top, but a REST > protocol with a transaction protocol purpose-built to serve just the REST > protocol. > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0016e6dd8be3a162120492e56b5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The problem is that an asynchronous response is a new CoAP transaction whic= h provides the ReST response in a ReST transaction where the request was a = previous, now completed, CoAP transaction.=A0 The transaction ID is irrelev= ant to the ReST level, so should not be relied upon to do the correlation, = but something does need to indicate that an incoming message is the respons= e component of a specific ReST transaction.

The Token option seems to satisfy this requirement adequately.=A0 I wou= ld argue that, if a server cannot provide a response in the transaction ack= nowledgement, and was not provided a Token to use to couple its eventual re= sponse to the original request, the request must be rejected because there = is no facility to correlate the response to the request.=A0 Another error c= ode is required.

Robert's alternative of an XOR'd transaction ID would eliminate= this requirement, though we'd have to reserve a bit as always zero in = origin TIDs to ensure an origin server doesn't end up using the same TI= D "too soon" for two transactions (one originating with it, and o= ne mandated by a response to a client).=A0 Probably also have to relax the = requirement on increasing TIDs from an endpoint.=A0 Messy, but doable.=A0 I= 'd use the Token: some clients may not be able to support asynchronous = responses (can't hold the pending state while other transactions occur)= , and leaving it up to the client to control their use simplifies their imp= lementation.

Carsten, it sounds like you're proposing use of a split ReST transa= ction mechanism.=A0 This is an interesting approach that might provide a so= lution for reconciling multicast at the transport level with ReST.=A0 If al= l CoAP transactions destined for a multicast address were treated as asynch= ronous, and the responses were new ReST transactions, consistency could be = maintained.=A0 But I don't think it works without a lot more detail.
Unless you want CON to become a ReST operation like GET, which I think = has a lot of consequences.=A0 It may be too late to work those out.

= Or if you accept the premise that a ReST GET can legitimately elicit multip= le state representations in response.=A0 I still don't, but won't b= other arguing about it any more.

Peter

On Sun, Oct 17, 2010 at 6:27 PM= , Carsten Bormann <cab= o@tzi.org> wrote:
On Oct 15, 2010, at 23:44, Juergen Schoenwaelder wrote:
> =A0How can I reliably match the responses to asynchronous requests?
I don't have time right now to do a detailed response, but my que= stion would be:
Why do you want to?

(If you indeed need to, that's what the token was meant for. =A0And yes= , the idea of a server-supplied token/ticket/promise/... is interesting, so= we should discuss this. =A0But for now I'd like to understand what spe= cific motivation you have for wanting the binding.)

One of the interesting properties of asynchronous responses is that they ar= e self-describing. =A0They could be sent by multicast and would still work.=

So what do we gain by binding them to a specific request?
(Yes, I'm focusing on GET requests here.)

One of the nice things about CoAP is that it is not trying to be a generic = transaction protocol with a REST protocol layered on top, but a REST protoc= ol with a transaction protocol purpose-built to serve just the REST protoco= l.

Gruesse, Carsten

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

--0016e6dd8be3a162120492e56b5e-- From pab@peoplepowerco.com Mon Oct 18 08:04:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CF53A6CD2 for ; Mon, 18 Oct 2010 08:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl1eX2VFNLx7 for ; Mon, 18 Oct 2010 08:04:06 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 300343A6CCA for ; Mon, 18 Oct 2010 08:04:06 -0700 (PDT) Received: by pwj8 with SMTP id 8so216060pwj.31 for ; Mon, 18 Oct 2010 08:05:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.221.5 with SMTP id y5mr1405091muq.134.1287414324396; Mon, 18 Oct 2010 08:05:24 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Mon, 18 Oct 2010 08:05:24 -0700 (PDT) In-Reply-To: <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> References: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> Date: Mon, 18 Oct 2010 10:05:24 -0500 Message-ID: From: Peter Bigot To: core issue tracker Content-Type: multipart/alternative; boundary=0016367659eb7cefa00492e581c3 Cc: core@ietf.org Subject: Re: [core] coap #25 (new): Token option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 15:04:07 -0000 --0016367659eb7cefa00492e581c3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Based on my argument that some clients would benefit from being able to control whether asynchronous responses are acceptable to them, I propose adding: 3. If a request does not include a Token option, the server MUST provide its ReST response within the transaction response. In the absence of this simplicity, we need text defining which ReST operations can be executed asynchronously without a Token, and how that is accomplished. Peter On Mon, Oct 18, 2010 at 9:54 AM, core issue tracker wr= ote: > #25: Token option > > > Comment(by zach@=85): > > Based on the discussions on the mailing list showing interest in > developing and testing the Token option further, I suggest that we do ad= d > the Token option to coap-03 as Option ID 11 (Critical) as per coap-misc-= 06 > (ok, this draft doesn't say much about it...). > > Simple rules: > > 1. If a Token Option is included in a request, the response (and any > subsequent delayed responses) MUST include the same value in a Token > Option. > > 2. If a Token Option is included in a request, any resulting delayed > response SHOULD NOT include the URI option (for sake of efficiency) as t= he > Token is sufficient for matching it with the request. > > -- > > --------------------------------+----------------------------------------= --- > Reporter: zach@=85 | Owner: cabo@=85 > Type: enhancement | Status: new > Priority: minor | Milestone: coap-03 > Component: coap | Version: > Severity: - | Keywords: > > --------------------------------+----------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0016367659eb7cefa00492e581c3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Based on my argument that some clients would benefit from being able to con= trol whether asynchronous responses are acceptable to them, I propose addin= g:

3.=A0 If a request does not include a Token option, the server MU= ST provide its ReST response within the transaction response.

In the absence of this simplicity, we need text defining which ReST ope= rations can be executed asynchronously without a Token, and how that is acc= omplished.

Peter

On Mon, Oct 18, 2= 010 at 9:54 AM, core issue tracker <trac@tools.ietf.org> wrote:
#25: Token option=


Comment(by zach@=85):

=A0Based on the discussions on the mailing list showing interest in
=A0developing and testing the Token option further, I suggest that we do ad= d
=A0the Token option to coap-03 as Option ID 11 (Critical) as per coap-misc-= 06
=A0(ok, this draft doesn't say much about it...).

=A0Simple rules:

=A01. If a Token Option is included in a request, the response (and any
=A0subsequent delayed responses) MUST include the same value in a Token
=A0Option.

=A02. If a Token Option is included in a request, any resulting delayed
=A0response SHOULD NOT include the URI option (for sake of efficiency) as t= he
=A0Token is sufficient for matching it with the request.

--
--------------------------------+------------------------------------------= -
=A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: = =A0cabo@=85
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: =A0coap-= 03
Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords: --------------------------------+------------------------------------------= -

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/tick= et/25#comment:1>
core <http://t= ools.ietf.org/core/>

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

--0016367659eb7cefa00492e581c3-- From pab@peoplepowerco.com Mon Oct 18 08:19:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECA13A6E0D for ; Mon, 18 Oct 2010 08:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AzzDxAbzq1u for ; Mon, 18 Oct 2010 08:19:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E542B3A6E0C for ; Mon, 18 Oct 2010 08:19:41 -0700 (PDT) Received: by qwc9 with SMTP id 9so702326qwc.31 for ; Mon, 18 Oct 2010 08:21:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.246.19 with SMTP id y19mr2512697mur.87.1287415263413; Mon, 18 Oct 2010 08:21:03 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Mon, 18 Oct 2010 08:21:03 -0700 (PDT) In-Reply-To: References: <20101014204502.278153A69A8@core3.amsl.com> Date: Mon, 18 Oct 2010 10:21:03 -0500 Message-ID: From: Peter Bigot To: "Rahman, Akbar" Content-Type: multipart/alternative; boundary=0016369fa27474b4490492e5b9c8 Cc: core@ietf.org Subject: Re: [core] Draft for Group Communication for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 15:19:43 -0000 --0016369fa27474b4490492e5b9c8 Content-Type: text/plain; charset=ISO-8859-1 I'll read the draft in detail and provide comments, but at first view it appears that this proposes to use the CoAP transaction protocol with multicast addresses, and does not make any claims that such use conforms to ReST transactions. This is a reasonable approach that should satisfy anybody who doesn't insist that CoAP must be 100% ReST. It works for me. It also allows the translation between ReST transactions expressed in HTTP and those expressed in CoAP to be more that mere mechanical transliterations, simplifying the bridging problem too. One HTTP ReST transaction may become an unspecified number of CoAP transactions, and the translation can be responsible for combining resource representations into the single response supported by HTTP. Peter On Thu, Oct 14, 2010 at 3:57 PM, Rahman, Akbar < Akbar.Rahman@interdigital.com> wrote: > Hi Carsten, > > > Here is the draft on Group Communications for CoAP as per our action > from the previous CORE Webex call. We look forward to comments from you > and the rest of the WG. > > I acted as the editor for the document but got most of the technical > input from all the people who contributed to the document as listed in > the Acknowledgements section. I especially would like to thank Kerry > Lynn who devoted a lot of time and energy in helping me put together > this draft. > > > Sincerely, > > > Akbar > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, October 14, 2010 4:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-rahman-core-groupcomm-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Group Communication for CoAP > Author(s) : A. Rahman > Filename : draft-rahman-core-groupcomm-00.txt > Pages : 14 > Date : 2010-10-14 > > This is a working document intended to trigger discussion and develop > draft language for the CoAP protocol specification in the area of group > communication (including multicast functionality). Engineering > tradeoffs become more challenging in constrained environments, therefore > group communication is considered within the context of adjacent topics > that may impact or be impacted by design choices in the subject area. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rahman-core-groupcomm-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0016369fa27474b4490492e5b9c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll read the draft in detail and provide comments, but at first view i= t appears that this proposes to use the CoAP transaction protocol with mult= icast addresses, and does not make any claims that such use conforms to ReS= T transactions.

This is a reasonable approach that should satisfy anybody who doesn'= ;t insist that CoAP must be 100% ReST.=A0 It works for me.

It also a= llows the translation between ReST transactions expressed in HTTP and those= expressed in CoAP to be more that mere mechanical transliterations, simpli= fying the bridging problem too.=A0 One HTTP ReST transaction may become an = unspecified number of CoAP transactions, and the translation can be respons= ible for combining resource representations into the single response suppor= ted by HTTP.

Peter

On Thu, Oct 14, 2010 at 3:57 PM= , Rahman, Akbar <Akbar.Rahman@interdigital.com> wrote:
Hi Carsten,


Here is the draft on Group Communications for CoAP as per our action
from the previous CORE Webex call. =A0We look forward to comments from you<= br> and the rest of the WG.

I acted as the editor for the document but got most of the technical
input from all the people who contributed to the document as listed in
the Acknowledgements section. =A0I especially would like to thank Kerry
Lynn who devoted a lot of time and energy in helping me put together
this draft.


Sincerely,


Akbar


-----Original Message-----
From: i-d-announce-bounces= @ietf.org
[mailto:i-d-announce-bounc= es@ietf.org] On Behalf Of
Internet-Drafts@ietf.org Sent: Thursday, October 14, 2010 4:45 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-rahman-core-groupcomm-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Group Communication for CoAP =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : A. Rahman
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-rahman-core-groupcomm-00.tx= t
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 14
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-10-14

This is a working document intended to trigger discussion and develop
draft language for the CoAP protocol specification in the area of group
communication (including multicast functionality). =A0Engineering
tradeoffs become more challenging in constrained environments, therefore group communication is considered within the context of adjacent topics
that may impact or be impacted by design choices in the subject area.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rahman-= core-groupcomm-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--0016369fa27474b4490492e5b9c8-- From kerlyn2001@gmail.com Mon Oct 18 08:59:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 355923A6BDB for ; Mon, 18 Oct 2010 08:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0PsH27QYBi1 for ; Mon, 18 Oct 2010 08:59:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 23BEC3A697C for ; Mon, 18 Oct 2010 08:59:33 -0700 (PDT) Received: by bwz14 with SMTP id 14so865429bwz.31 for ; Mon, 18 Oct 2010 09:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oxU0wCeFedbz1cNsl/QhpBAz/aA3lCAZZWO17TrMIHU=; b=wI6D9sFyNH6XZDoyMKGYMY3hsp8F++x9vQQQ24hXAsg1lVAV9XDQqgvdTzzrU6bPKw uqmpMOxy8D+WKzOnU9yUUDoZJX/RWHhArdpvkfUQb8iEuLsQGuNAC0/k7MLf8fhCZdsC TMvamCYvegwRVGVrG+loS3svE3DzlBczz9d1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hWwE20SLTWB7T2myG1bDbjAFS8A0KKsiZiljsgjdrnN3lxl9vH7KVKZZss+rBySAK9 tkFDqsE3oFFxWW5KW5qfsIA+eJTf6mVveMSSDZIGIT7jdeLUQBiV7BMPsanz5Tm+AQzA ZGLLv7L1KqKenceRWwNGiDzh5Tv9WFU0ELXks= MIME-Version: 1.0 Received: by 10.204.117.195 with SMTP id s3mr1604843bkq.203.1287417661698; Mon, 18 Oct 2010 09:01:01 -0700 (PDT) Received: by 10.204.103.72 with HTTP; Mon, 18 Oct 2010 09:01:01 -0700 (PDT) In-Reply-To: References: <20101014204502.278153A69A8@core3.amsl.com> Date: Mon, 18 Oct 2010 12:01:01 -0400 Message-ID: From: Kerry Lynn To: Peter Bigot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Draft for Group Communication for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 15:59:37 -0000 Peter, Your comments would be greatly appreciated. Keep in mind that this is -00 and has many gaps. I think a worthy goal for -01 would be to sketch out enough detail that *some* level of interop might be implemented and tested in Beijing. I expect this might be at the proxy level as described in [STUDY1]. Regards, -K- On Mon, Oct 18, 2010 at 11:21 AM, Peter Bigot wrote= : > I'll read the draft in detail and provide comments, but at first view it > appears that this proposes to use the CoAP transaction protocol with > multicast addresses, and does not make any claims that such use conforms = to > ReST transactions. > > This is a reasonable approach that should satisfy anybody who doesn't ins= ist > that CoAP must be 100% ReST.=A0 It works for me. > > It also allows the translation between ReST transactions expressed in HTT= P > and those expressed in CoAP to be more that mere mechanical > transliterations, simplifying the bridging problem too.=A0 One HTTP ReST > transaction may become an unspecified number of CoAP transactions, and th= e > translation can be responsible for combining resource representations int= o > the single response supported by HTTP. > > Peter > > On Thu, Oct 14, 2010 at 3:57 PM, Rahman, Akbar > wrote: >> >> Hi Carsten, >> >> >> Here is the draft on Group Communications for CoAP as per our action >> from the previous CORE Webex call. =A0We look forward to comments from y= ou >> and the rest of the WG. >> >> I acted as the editor for the document but got most of the technical >> input from all the people who contributed to the document as listed in >> the Acknowledgements section. =A0I especially would like to thank Kerry >> Lynn who devoted a lot of time and energy in helping me put together >> this draft. >> >> >> Sincerely, >> >> >> Akbar >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Thursday, October 14, 2010 4:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-rahman-core-groupcomm-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Group Communication for CoAP >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : A. Rahman >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-rahman-core-groupcomm-00.= txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 14 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-10-14 >> >> This is a working document intended to trigger discussion and develop >> draft language for the CoAP protocol specification in the area of group >> communication (including multicast functionality). =A0Engineering >> tradeoffs become more challenging in constrained environments, therefore >> group communication is considered within the context of adjacent topics >> that may impact or be impacted by design choices in the subject area. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-rahman-core-groupcomm-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> 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 cabo@tzi.org Mon Oct 18 09:04:00 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB6D3A6DB7 for ; Mon, 18 Oct 2010 09:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.169 X-Spam-Level: X-Spam-Status: No, score=-106.169 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkm7yOFuFlfD for ; Mon, 18 Oct 2010 09:03:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id DCFE33A6A09 for ; Mon, 18 Oct 2010 09:03:56 -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 o9IG5HUh027777; Mon, 18 Oct 2010 18:05:18 +0200 (CEST) Received: from [192.168.217.101] (p5489FCF2.dip.t-dialin.net [84.137.252.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 89547E7C; Mon, 18 Oct 2010 18:05:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 18 Oct 2010 18:05:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <927D6F9D-1331-4245-834F-0F68EABEE823@tzi.org> References: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #25 (new): Token option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 16:04:00 -0000 On Oct 18, 2010, at 17:05, Peter Bigot wrote: > Based on my argument that some clients would benefit from being able = to control whether asynchronous responses are acceptable to them, I = propose adding: >=20 > 3. If a request does not include a Token option, the server MUST = provide its ReST response within the transaction response. Well, we can't just say MUST; we need to provide an error code for the = case where the server can't. Also, for a GET request, I like the current situation (no option needed) = much better. Gruesse, Carsten From darco@deepdarc.com Mon Oct 18 10:51:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565A03A6B97 for ; Mon, 18 Oct 2010 10:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PMLi-8sO2Vz for ; Mon, 18 Oct 2010 10:51:27 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 7ABA93A6DE9 for ; Mon, 18 Oct 2010 10:51:26 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 3AD09B68D4D6; Mon, 18 Oct 2010 10:52:55 -0700 (PDT) X-AuditID: 1180711d-b7c86ae000000247-95-4cbc89777b11 Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 47.59.00583.7798CBC4; Mon, 18 Oct 2010 10:52:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-25--120470249 From: Robert Quattlebaum In-Reply-To: Date: Mon, 18 Oct 2010 10:52:54 -0700 Message-Id: <44223541-D85B-46FA-8ED0-8A75B66077B8@deepdarc.com> References: <20101015214414.GA4737@elstar.local> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: core@ietf.org Subject: Re: [core] asynchronous responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 17:51:28 -0000 --Apple-Mail-25--120470249 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Carsten! On Oct 17, 2010, at 4:27 PM, Carsten Bormann wrote: > One of the interesting properties of asynchronous responses is that = they are self-describing. They could be sent by multicast and would = still work. I did some more thinking about this case. Originally I did not like that = idea at all, but you mentioning this has made me consider something I = hadn't thought of before. I'll elaborate here for the sake of others. Only using the URI options for correlating allows you to implement a = device that only has data at discrete moments in time. In such a case, a = GET request becomes a "one-time subscription" request. The response = could even be multicasted, allowing the server to not even keep state = about pending requests. It would work as follows: A client sends a GET request for something to a server device. The = server device ALWAYS returns an ACK response with a code of zero. Many = devices could do this all at once, and the server would respond to all = of them with simple ACK and a response code of zero. When the device = actually has data available, it then multicasts a response which all of = the devices which requested the resource earlier will receive. You can't = do this if all of the devices are expecting the response to be tailored = to their specific client-defined token. But Juergen's suggestion would still work great in this case, because = the server generates the identifier which is used to relate the = requests. In this case, the server would simply always return the same = identifier (etid, in Jeurgen's suggestion) in the ACK for the original = request. It would make client implementations easier without preventing = the above mentioned scenario. (Although there may be security = implications) I now like Juergen's concept better than my own suggestions now. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-25--120470249 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Carsten!

On Oct 17, 2010, at 4:27 PM, Carsten Bormann = wrote:

One of the interesting properties of asynchronous = responses is that they are self-describing.  They could be sent by = multicast and would still = work.

I did some = more thinking about this case. Originally I did not like that idea at = all, but you mentioning this has made me consider something I hadn't = thought of before. I'll elaborate here for the sake of = others.

Only using the URI options for = correlating allows you to implement a device that only has data at = discrete moments in time. In such a case, a GET request becomes a = "one-time subscription" request. The response could even be multicasted, = allowing the server to not even keep state about pending requests. It = would work as follows:

A client sends a GET = request for something to a server device. The server device ALWAYS = returns an ACK response with a code of zero. Many devices could do this = all at once, and the server would respond to all of them with simple ACK = and a response code of zero. When the device actually has data = available, it then multicasts a response which all of the devices which = requested the resource earlier will receive. You can't do this if all of = the devices are expecting the response to be tailored to their specific = client-defined token.

But Juergen's suggestion = would still work great in this case, because the server generates the = identifier which is used to relate the requests. In this case, the = server would simply always return the same identifier (etid, in = Jeurgen's suggestion) in the ACK for the original request. It would make = client implementations easier without preventing the above mentioned = scenario. (Although there may be security = implications)

I now like Juergen's concept = better than my own suggestions now.



= --Apple-Mail-25--120470249-- From pab@peoplepowerco.com Mon Oct 18 11:14:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9853A6B97 for ; Mon, 18 Oct 2010 11:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3n4Yl7Rztj4 for ; Mon, 18 Oct 2010 11:14:55 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8555C3A6B90 for ; Mon, 18 Oct 2010 11:14:55 -0700 (PDT) Received: by qwc9 with SMTP id 9so870213qwc.31 for ; Mon, 18 Oct 2010 11:16:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.221.12 with SMTP id y12mr2866916muq.109.1287425783095; Mon, 18 Oct 2010 11:16:23 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Mon, 18 Oct 2010 11:16:22 -0700 (PDT) In-Reply-To: <927D6F9D-1331-4245-834F-0F68EABEE823@tzi.org> References: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> <927D6F9D-1331-4245-834F-0F68EABEE823@tzi.org> Date: Mon, 18 Oct 2010 13:16:22 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016367ed5f67a02e70492e82c51 Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #25 (new): Token option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 18:14:57 -0000 --0016367ed5f67a02e70492e82c51 Content-Type: text/plain; charset=ISO-8859-1 Then make it: 3. If a request does not include a Token option, the server MUST provide its ReST response within the transaction response. If it cannot do so (i.e., can only satisfy the request through an asynchronous response), it MUST respond with error 400 "Bad Request (TBD) Replace 400 with some more informative code (I thought we had a ticket related to extending the error codes in another context, but I don't recognize it from the titles). I prefer this wording to making an exception for GET. Two reasons: consistency, and support for clients that are unable to accommodate asynchronous responses. Nothing prevents a client from sending the GET without a token, and retransmitting it (and future GETs to the same authority and/or resource) with one if the server indicates it needs to send asynchronous responses. This same pattern is used in my proposal some border-case failures in the block option. Other viewpoints on this, please? BTW: The reason I don't like server-created tokens is that it's the client, not the server, that needs to disambiguate, and it can't if two servers it talks to both decide to use the same token to indicate their eventual response. Peter On Mon, Oct 18, 2010 at 11:05 AM, Carsten Bormann wrote: > On Oct 18, 2010, at 17:05, Peter Bigot wrote: > > > Based on my argument that some clients would benefit from being able to > control whether asynchronous responses are acceptable to them, I propose > adding: > > > > 3. If a request does not include a Token option, the server MUST provide > its ReST response within the transaction response. > > Well, we can't just say MUST; we need to provide an error code for the case > where the server can't. > > Also, for a GET request, I like the current situation (no option needed) > much better. > > Gruesse, Carsten > > --0016367ed5f67a02e70492e82c51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Then make it:

3. If a request does not include a Token option, the s= erver MUST provide its ReST response within the transaction response.=A0 If= it cannot do so (i.e., can only satisfy the request through an asynchronou= s response), it MUST respond with error 400 "Bad Request (TBD)

Replace 400 with some more informative code (I thought we had a ticket = related to extending the error codes in another context, but I don't re= cognize it from the titles).

I prefer this wording to making an exce= ption for GET.=A0 Two reasons: consistency, and support for clients that ar= e unable to accommodate asynchronous responses.=A0 Nothing prevents a clien= t from sending the GET without a token, and retransmitting it (and future G= ETs to the same authority and/or resource) with one if the server indicates= it needs to send asynchronous responses.=A0 This same pattern is used in m= y proposal some border-case failures in the block option.

Other viewpoints on this, please?

BTW: The reason I don't li= ke server-created tokens is that it's the client, not the server, that = needs to disambiguate, and it can't if two servers it talks to both dec= ide to use the same token to indicate their eventual response.

Peter

On Mon, Oct 18, 2010 at 11:05 A= M, Carsten Bormann <ca= bo@tzi.org> wrote:
On Oct 18, 2010, at 17:05, Peter Bigot wrote:

> Based on my argument that some clients would benefit from being able t= o control whether asynchronous responses are acceptable to them, I propose = adding:
>
> 3. =A0If a request does not include a Token option, the server MUST pr= ovide its ReST response within the transaction response.

Well, we can't just say MUST; we need to provide an error code fo= r the case where the server can't.

Also, for a GET request, I like the current situation (no option needed) mu= ch better.

Gruesse, Carsten


--0016367ed5f67a02e70492e82c51-- From zach@sensinode.com Mon Oct 18 11:21:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C82C3A6E2C for ; Mon, 18 Oct 2010 11:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTSjb-c8GuNc for ; Mon, 18 Oct 2010 11:21:57 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 67E3A3A6E01 for ; Mon, 18 Oct 2010 11:21:55 -0700 (PDT) Received: from [192.168.1.3] (line-7533.dyn.kponet.fi [85.29.75.201]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9IINGxN026778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Oct 2010 21:23:17 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-1888--118645749; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 18 Oct 2010 21:23:19 +0300 Message-Id: <5980BDE6-EA7F-4004-9006-24AFC3B1E395@sensinode.com> References: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> <927D6F9D-1331-4245-834F-0F68EABEE823@tzi.org> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #25 (new): Token option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 18:21:58 -0000 --Apple-Mail-1888--118645749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Personally, I like this addition, thanks Peter. I do agree that it is = clearer for the implementor of a client to know if an asynchronous = response may come or not, and safer to avoid server generated tokens.=20 Yes, we should have a ticket for expanding our error codes to make them = useful, but I forgot to do that. Will make one soon... Zach On Oct 18, 2010, at 9:16 PM, Peter Bigot wrote: > Then make it: >=20 > 3. If a request does not include a Token option, the server MUST = provide its ReST response within the transaction response. If it cannot = do so (i.e., can only satisfy the request through an asynchronous = response), it MUST respond with error 400 "Bad Request (TBD) >=20 > Replace 400 with some more informative code (I thought we had a ticket = related to extending the error codes in another context, but I don't = recognize it from the titles). >=20 > I prefer this wording to making an exception for GET. Two reasons: = consistency, and support for clients that are unable to accommodate = asynchronous responses. Nothing prevents a client from sending the GET = without a token, and retransmitting it (and future GETs to the same = authority and/or resource) with one if the server indicates it needs to = send asynchronous responses. This same pattern is used in my proposal = some border-case failures in the block option. >=20 > Other viewpoints on this, please? >=20 > BTW: The reason I don't like server-created tokens is that it's the = client, not the server, that needs to disambiguate, and it can't if two = servers it talks to both decide to use the same token to indicate their = eventual response. >=20 > Peter >=20 > On Mon, Oct 18, 2010 at 11:05 AM, Carsten Bormann = wrote: > On Oct 18, 2010, at 17:05, Peter Bigot wrote: >=20 > > Based on my argument that some clients would benefit from being able = to control whether asynchronous responses are acceptable to them, I = propose adding: > > > > 3. If a request does not include a Token option, the server MUST = provide its ReST response within the transaction response. >=20 > Well, we can't just say MUST; we need to provide an error code for the = case where the server can't. >=20 > Also, for a GET request, I like the current situation (no option = needed) much better. >=20 > Gruesse, Carsten >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-1888--118645749 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxODE4MjMx OVowIwYJKoZIhvcNAQkEMRYEFPfSFSsM3Q31DJIlMVkUoBdHUlIYMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADQldX1KjlLjUIGBpVAA3Yy1Zxo9W6T+7ikX9R8rH7o0lGpoqLJuIyrS nZEJVH8NCyf74rDtNPGYLmAOw2ftQ2ATRtTLleYPBtuf5b8q30Bgsz1OWg40DqRUy/tm1GXx/l+L 0EucRykANLrwsFQuLTw5ZOyYb6gV8WVcAyVq7KzZRnkXxO4djFNP28vDwdOo2b1Z5AdDRwHCF2/7 fpF2Y0QBZf3868lC8DYxOCjEa8UECTzNwSfEJQYeH7hy71eMnSFx8Hlrd2mFc3XI+QT3BzXg4Lgt yLhzjsTUmdPWKvZDlRc21ZYKExwHM9ODTJl9Te5uZdZTS7q2PGLqGe/fxiQAAAAAAAA= --Apple-Mail-1888--118645749-- From root@core3.amsl.com Mon Oct 18 12:15:03 2010 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 036EC3A6E4B; Mon, 18 Oct 2010 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101018191503.036EC3A6E4B@core3.amsl.com> Date: Mon, 18 Oct 2010 12:15:02 -0700 (PDT) Cc: core@ietf.org Subject: [core] I-D Action:draft-ietf-core-block-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 19:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Z. Shelby, C. Bormann Filename : draft-ietf-core-block-00.txt Pages : 13 Date : 2010-10-18 CoAP is a RESTful transfer protocol for constrained nodes and networks. CoAP is based on datagram transport, which limits the maximum size of resource representations that can be transferred without too much fragmentation. The Block option provides a minimal way to transfer larger representations in a block-wise fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-block-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-core-block-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18120152.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 18 12:15:04 2010 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 927533A6E3D; Mon, 18 Oct 2010 12:15:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101018191503.927533A6E3D@core3.amsl.com> Date: Mon, 18 Oct 2010 12:15:03 -0700 (PDT) Cc: core@ietf.org Subject: [core] I-D Action:draft-ietf-core-observe-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 19:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Observing Resources in CoAP Author(s) : K. Hartke, Z. Shelby Filename : draft-ietf-core-observe-00.txt Pages : 12 Date : 2010-10-18 The state of a resource can change over time. We want to give clients of the CoRE WG CoAP protocol the ability to observe this change. This short I-D provides a design for such an addition to CoAP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-observe-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-core-observe-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18120207.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 18 12:15:04 2010 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 817733A6E4C; Mon, 18 Oct 2010 12:15:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101018191504.817733A6E4C@core3.amsl.com> Date: Mon, 18 Oct 2010 12:15:03 -0700 (PDT) Cc: core@ietf.org Subject: [core] I-D Action:draft-ietf-core-link-format-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 19:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : CoRE Link Format Author(s) : Z. Shelby Filename : draft-ietf-core-link-format-00.txt Pages : 11 Date : 2010-10-18 This document defines a link format for use by constrained CoAP web servers to describe URIs of resources offered along with other attributes. Based on the HTTP Link Header format, the CoRE link format is carried as a payload and is assigned an Internet media type. A well-known URI is defined as a default entry-point for requesting the list of links to resources hosted by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-core-link-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18120234.I-D@ietf.org> --NextPart-- From trac@tools.ietf.org Tue Oct 19 00:39:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E8A3A6A8C for ; Tue, 19 Oct 2010 00:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfgme1s+qH80 for ; Tue, 19 Oct 2010 00:39:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 31BDF3A6A87 for ; Tue, 19 Oct 2010 00:39:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P86oJ-00074r-9W; Tue, 19 Oct 2010 00:40:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 19 Oct 2010 07:40:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/26 Message-ID: <057.2e09eba29a7e1fcfc1016f2c09b38552@tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #26 (new): Expand error code space X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 07:39:28 -0000 #26: Expand error code space CoAP is having a problem with useful error codes for special cases. Returning a 400 every time something happens tells us very little. This ticket is to consider expanding the error space with more useful codes for special cases. Examples include: * Error: Token Option required by server * Error: URI Authority required by server * Error: Critical Option not supported To avoid collisions with HTTP 40x codes, it has been suggested that CoRE reserves its own code space in the Section 11.1 table for CoAP-specific error codes in the 240-255 range. These errors would be converted to e.g. an HTTP 400 in a proxy. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: coap-03 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From matthieu.vial@fr.non.schneider-electric.com Tue Oct 19 01:13:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF103A6A96; Tue, 19 Oct 2010 01:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naEUOZjH6pOi; Tue, 19 Oct 2010 01:13:04 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id E60653A6A65; Tue, 19 Oct 2010 01:13:03 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2010101910014149-140262 ; Tue, 19 Oct 2010 10:01:41 +0200 In-Reply-To: To: Peter Bigot X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Tue, 19 Oct 2010 10:14:28 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 19/10/2010 10:14:27, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 19/10/2010 10:01:41, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 19/10/2010 10:01:42 Content-type: multipart/related; Boundary="0__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C" Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] coap #25 (new): Token option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Oct 2010 08:13:06 -0000 --0__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C Content-type: multipart/alternative; Boundary="1__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C" --1__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi Peter I also like the idea an optional implementation of the asynchronous mod= e. I think we definitively need a simple way to match a response to a requ= est. Comparing ((authority option OR source address) AND path option) seems = too complex compared to a simple token comparison. But I'm a bit afraid of all the bad request error codes that force the client to reformulate its request. First the authority option, now the token option, then... It involves more and more transactions to get a valid response If a cli= ent must try all of them one by one. What should be the default rules for clients that support asynchronous responses ? They should always include a token option to avoid an error= code or only include it on demand and cache the result to try to save bandwith ? Matthieu = Peter Bigot = = A Envoy=E9 par : Carsten Bormann = core-bounces@ietf = cc .org core issue tracker = , = core@ietf.org = 18/10/2010 20:16 Ob= jet Re: [core] coap #25 (new): Token= option = = = = = = = Then make it: 3. If a request does not include a Token option, the server MUST provid= e its ReST response within the transaction response.=A0 If it cannot do s= o (i.e., can only satisfy the request through an asynchronous response), = it MUST respond with error 400 "Bad Request (TBD) Replace 400 with some more informative code (I thought we had a ticket related to extending the error codes in another context, but I don't recognize it from the titles). I prefer this wording to making an exception for GET.=A0 Two reasons: consistency, and support for clients that are unable to accommodate asynchronous responses.=A0 Nothing prevents a client from sending the G= ET without a token, and retransmitting it (and future GETs to the same authority and/or resource) with one if the server indicates it needs to= send asynchronous responses.=A0 This same pattern is used in my proposa= l some border-case failures in the block option. Other viewpoints on this, please? BTW: The reason I don't like server-created tokens is that it's the cli= ent, not the server, that needs to disambiguate, and it can't if two servers= it talks to both decide to use the same token to indicate their eventual response. Peter On Mon, Oct 18, 2010 at 11:05 AM, Carsten Bormann wrote:= On Oct 18, 2010, at 17:05, Peter Bigot wrote: > Based on my argument that some clients would benefit from being= able to control whether asynchronous responses are acceptable to them, I propose adding: > > 3. =A0If a request does not include a Token option, the server = MUST provide its ReST response within the transaction response. Well, we can't just say MUST; we need to provide an error code fo= r the case where the server can't. Also, for a GET request, I like the current situation (no option needed) much better. Gruesse, Carsten ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core = --1__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Hi Peter

I also like the idea an optional implementation of the asynchronous mod= e.
I think we definitively need a simple way to match a response to a requ= est. Comparing ((authority option OR source address) AND path option) s= eems too complex compared to a simple token comparison.

But I'm a bit afraid of all the bad request error codes that force the = client to reformulate its request.
First the authority option, now the token option, then...
It involves more and more transactions to get a valid response If a cli= ent must try all of them one by one.
What should be the default rules for clients that support asynchronous = responses ? They should always include a token option to avoid an error= code or only include it on demand and cache the result to try to save = bandwith ?

Matthieu

3D"InactivePeter Bigot <pab@peoplepowerco= .com>




=
          Peter Bigot <pab@peoplepowerco.com>
          Envoy=E9 par : core-bounces@ietf.org

          18/10/2010 20:16

 =
3D=
A
3D""
Carsten Bormann <cabo@tzi.org>
3D=
cc
3D""
core issue tracker <trac@tools.ietf.org>, core@i= etf.org
3D=
Objet
3D""
Re: [core] coap #25 (new): Token option
3D=3D""

Then make it:

3. If a request does not include a Token option, the server MUST provid= e its ReST response within the transaction response.=A0 If it cannot do= so (i.e., can only satisfy the request through an asynchronous respons= e), it MUST respond with error 400 "Bad Request (TBD)

Replace 400 with some more informative code (I thought we had a ticket = related to extending the error codes in another context, but I don't re= cognize it from the titles).

I prefer this wording to making an exception for GET.=A0 Two reasons: c= onsistency, and support for clients that are unable to accommodate asyn= chronous responses.=A0 Nothing prevents a client from sending the GET w= ithout a token, and retransmitting it (and future GETs to the same auth= ority and/or resource) with one if the server indicates it needs to sen= d asynchronous responses.=A0 This same pattern is used in my proposal s= ome border-case failures in the block option.

Other viewpoints on this, please?

BTW: The reason I don't like server-created tokens is that it's the cli= ent, not the server, that needs to disambiguate, and it can't if two se= rvers it talks to both decide to use the same token to indicate their e= ventual response.

Peter

On Mon, Oct 18, 2010 at 11:05 AM, Carsten Bormann <= cabo@tzi.org> wrote:

      On Oct 18, 2010, at 17:05, Peter Bigot wrote:

      > Based on my argument that some clients would benefit from being ab= le to control whether asynchronous responses are acceptable to them, I = propose adding:
      >
      > 3. =A0If a request does not include a Token option, the server MUS= T provide its ReST response within the transaction response.

      Well, we can't just say MUST; we need to provide an er= ror code for the case where the server can't.

      Also, for a GET request, I like the current situation (no option needed= ) much better.

      Gruesse, Carsten


______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= /font>_______________________________________________
core mailing list
core@ietf.org
https:/= /www.ietf.org/mailman/listinfo/core

= --1__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C-- --0__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFD52DFB9158C8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C Content-type: image/gif; name="pic11023.gif" Content-Disposition: inline; filename="pic11023.gif" Content-ID: <2__=4EBBFD52DFB9158C8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFD52DFB9158C8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFD52DFB9158C8f9e8a93df938690918c4EBBFD52DFB9158C-- From pab@peoplepowerco.com Tue Oct 19 05:55:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573CE3A67FA for ; Tue, 19 Oct 2010 05:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmSxdmfubizu for ; Tue, 19 Oct 2010 05:55:36 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 756D63A67B2 for ; Tue, 19 Oct 2010 05:55:36 -0700 (PDT) Received: by fxm17 with SMTP id 17so1730365fxm.31 for ; Tue, 19 Oct 2010 05:57:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.191.11 with SMTP id t11mr4270646mup.2.1287493026444; Tue, 19 Oct 2010 05:57:06 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Tue, 19 Oct 2010 05:57:06 -0700 (PDT) Date: Tue, 19 Oct 2010 07:57:06 -0500 Message-ID: From: Peter Bigot To: matthieu.vial@fr.non.schneider-electric.com Content-Type: multipart/alternative; boundary=0016e65b411c7df9d50492f7d424 Cc: core@ietf.org Subject: [core] Client default rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Oct 2010 12:55:38 -0000 --0016e65b411c7df9d50492f7d424 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 19, 2010 at 3:14 AM, < matthieu.vial@fr.non.schneider-electric.com> wrote: > But I'm a bit afraid of all the bad request error codes that force the > client to reformulate its request. > First the authority option, now the token option, then... > It involves more and more transactions to get a valid response If a client > must try all of them one by one. > What should be the default rules for clients that support asynchronous > responses ? They should always include a token option to avoid an error code > or only include it on demand and cache the result to try to save bandwith ? > I don't think there's a simple answer to that question. ReST as an architectural style requires uniformity of interface, regardless of protocol and transport. The limited resources of the platforms on which CoAP will be used require trade-offs that introduce variation points. Network bandwidth limitations, latency, processing power, and the applications themselves all impact the selection of alternatives in CoAP. I'll outline my current thinking for two implementation environments I'll be supporting, after first reviewing the variation points that come to mind: - URI-Authority can be omitted from a request to save space in the CoAP message. Doing so risks rejection of the ReST transaction if an intervening server requires the authority to identify the resource. - Token can be added if the client is capable of accepting asynchronous responses. Doing so increases the size of each message (though probably only by 3 octets, much less impact than adding URI-Authority). - Block can be added if the client is capable of accepting large representations in chunks. I have two target implementations: - CoAPy is a Python library which is assumed to run on a non-constrained node, and will almost uniformly be used in clients that interact with arbitrary CoAP servers. Its server capability would mostly be used for value-added proxies, including integration into ReST architectures. It will abstract three layers: a pure ReST layer that should be one-to-one mappable to ReST as implemented in HTTP; a pseudo-ReST layer that uses CoAP transactions for observation and multicast actions; and the CoAP transaction layer. - OSIAN is a TinyOS extension supporting a POSIX-style IPv6 network stack. It's not tied to specific hardware, but the initial platform uses the Texas Instruments CC430 microcontroller+ISM-band radio, which has 4kB of RAM and 32 kB of ROM. CoAP endpoints in this environment will uniformly be servers, responding to clients outside the radio network. If clients are needed within the network, they can be assumed to be talking to OSIAN servers. Code size dictates what features will be supported, and it's likely that the layers will be collapsed to make things fit. Within reason, reduced code size is more important than reduced message size. A CoAP (ReST-style) proxy on a less constrained gateway node can help hide the variation from external clients. CoAPy will by default include the URI-Authority, to simplify composition of services (which is a likely application for CoAPy). At worst, use of URI-Authority will result in a path MTU overrun and failure to access the server, so the application should have the option to inhibit it. Whether the server will require the authority will probably be an application configuration decision, but implemented at the pseudo-ReST layer. OSIAN will probably ignore URI-Authority at the server, and assume the client addressed the message correctly. If client support is added to OSIAN, it will not include the URI-Authority since the servers won't look at it anyway. CoAPy will support asynchronous transactions. The Token option will automatically be added at the pseudo-ReST layer, and will never appear at the pure ReST layer, as asynchrony is irrelevant to the ReST transaction. For completeness there will be an option to inhibit adding Token, again to reduce the message size when its presence causes problems with a particular server. OSIAN: I'm not sure yet. Because TinyOS's run-to-completion task structure encourages split-phase architectures, I expect that if any request must be made asynchronous, every request will be made asynchronous, to eliminate the code required to support both. If so, a client that omits the option will have to retransmit with it added. As the application domain assumes clients that have more resources than the servers, transferring the burden to the client is defensible. CoAPy will support the block option, but my current belief is that the block option is best viewed as transport-level syntactic sugar for use of the fragment part of a URI (with a query-part to define the block size). As such, it will not appear at the pure ReST layer, and will be an explicit part of the pseudo-ReST layer interface. OSIAN will support the block option, but only for specific resources. Attempts to use it on others are likely to be rejected. (I'll have to check the spec to make sure this is permitted: if a resource representation is 24-bytes, I do not want to have to waste code space with block support for it just because somebody wants to retrieve it in 16-byte chunks. However, a 1500-byte high-resolution sample sequence will have to be retrieved in pieces.) So: no answers, but maybe some things to think about. Peter --0016e65b411c7df9d50492f7d424 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 19, 2010 at 3:14 AM, <matt= hieu.vial@fr.non.schneider-electric.com> wrote:

But I'm a bit afraid of all the bad request error codes that force t= he client to reformulate its request.
First the authority option, now the token option, then...
It involves more and more transactions to get a valid response If a client = must try all of them one by one.
What should be the default rules for clients that support asynchronous resp= onses ? They should always include a token option to avoid an error code or= only include it on demand and cache the result to try to save bandwith ?

I don't think there's a simple answer t= o that question.

ReST as an architectural style requires uniformity = of interface, regardless of protocol and transport.=A0 The limited resource= s of the platforms on which CoAP will be used require trade-offs that intro= duce variation points.=A0 Network bandwidth limitations, latency, processin= g power, and the applications themselves all impact the selection of altern= atives in CoAP.

I'll outline my current thinking for two implementation environment= s I'll be supporting, after first reviewing the variation points that c= ome to mind:
  • URI-Authority can be omitted from a request to save= space in the CoAP message.=A0 Doing so risks rejection of the ReST transac= tion if an intervening server requires the authority to identify the resour= ce.
  • Token can be added if the client is capable of accepting asynchronous r= esponses.=A0 Doing so increases the size of each message (though probably o= nly by 3 octets, much less impact than adding URI-Authority).
  • Block= can be added if the client is capable of accepting large representations i= n chunks.
=A0I have two target implementations:
  • CoAPy is a Pytho= n library which is assumed to run on a non-constrained node, and will almos= t uniformly be used in clients that interact with arbitrary CoAP servers.= =A0 Its server capability would mostly be used for value-added proxies, inc= luding integration into ReST architectures.=A0 It will abstract three layer= s:=A0 a pure ReST layer that should be one-to-one mappable to ReST as imple= mented in HTTP; a pseudo-ReST layer that uses CoAP transactions for observa= tion and multicast actions; and the CoAP transaction layer.
  • OSIAN is a TinyOS extension supporting a POSIX-style IPv6 network = stack.=A0 It's not tied to specific hardware, but the initial platform = uses the Texas Instruments CC430 microcontroller+ISM-band radio, which has = 4kB of RAM and 32 kB of ROM.=A0 CoAP endpoints in this environment will uni= formly be servers, responding to clients outside the radio network.=A0 If c= lients are needed within the network, they can be assumed to be talking to = OSIAN servers.=A0 Code size dictates what features will be supported, and i= t's likely that the layers will be collapsed to make things fit.=A0 Wit= hin reason, reduced code size is more important than reduced message size.= =A0 A CoAP (ReST-style) proxy on a less constrained gateway node can help h= ide the variation from external clients.
CoAPy will by default include the URI-Authority, to simplify comp= osition of services (which is a likely application for CoAPy).=A0 At worst,= use of URI-Authority will result in a path MTU overrun and failure to acce= ss the server, so the application should have the option to inhibit it.=A0 = Whether the server will require the authority will probably be an applicati= on configuration decision, but implemented at the pseudo-ReST layer.

OSIAN will probably ignore URI-Authority at the server, and assume the = client addressed the message correctly.=A0 If client support is added to OS= IAN, it will not include the URI-Authority since the servers won't look= at it anyway.

CoAPy will support asynchronous transactions.=A0 The Token = option will automatically be added at the pseudo-ReST layer, and will never= appear at the pure ReST layer, as asynchrony is irrelevant to the ReST tra= nsaction.=A0 For completeness there will be an option to inhibit adding Tok= en, again to reduce the message size when its presence causes problems with= a particular server.

OSIAN: I'm not sure yet.=A0 Because TinyOS's run-to-completion = task structure encourages split-phase architectures, I expect that if any r= equest must be made asynchronous, every request will be made asynchronous, = to eliminate the code required to support both.=A0 If so, a client that omi= ts the option will have to retransmit with it added.=A0 As the application = domain assumes clients that have more resources than the servers, transferr= ing the burden to the client is defensible.

CoAPy will support the block option, but my current belief is that the = block option is best viewed as transport-level syntactic sugar for use of t= he fragment part of a URI (with a query-part to define the block size).=A0 = As such, it will not appear at the pure ReST layer, and will be an explicit= part of the pseudo-ReST layer interface.

OSIAN will support the block option, but only for specific resources.= =A0 Attempts to use it on others are likely to be rejected.=A0 (I'll ha= ve to check the spec to make sure this is permitted: if a resource represen= tation is 24-bytes, I do not want to have to waste code space with block su= pport for it just because somebody wants to retrieve it in 16-byte chunks.= =A0 However, a 1500-byte high-resolution sample sequence will have to be re= trieved in pieces.)

So: no answers, but maybe some things to think about.

Peter
<= div style=3D"visibility: hidden; display: inline;" id=3D"avg_ls_inline_popu= p"> --0016e65b411c7df9d50492f7d424-- From zach@sensinode.com Tue Oct 19 06:49:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366853A682F for ; Tue, 19 Oct 2010 06:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhsjvxgWVQ73 for ; Tue, 19 Oct 2010 06:49:37 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 54B7D3A6813 for ; Tue, 19 Oct 2010 06:49:36 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9JDp3AH021211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 Oct 2010 16:51:04 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-5--48579444; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 19 Oct 2010 16:51:05 +0300 Message-Id: <73224E51-B5F2-4134-B9C8-7D99F34C98CC@sensinode.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Plugfest in Beijing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Oct 2010 13:49:39 -0000 --Apple-Mail-5--48579444 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I updated the CoRE Wiki about the upcoming plugfest in Beijing.=20 http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest The format will be similar to last time, we will have an all-day event = on Sunday (time and room TBD) and then a shorter follow-up sometime = during the week in the terminal room. The goal is to test all of the = working group documents. This time we should plan some testing groups or = stages for testers of certain features, with well-defined test setups. = Like last time you will also be able to participate via IRC remotely. The "CoAP test servers already on-line" part of the Wiki should list = servers that are available already for testing before and during the = event. Carsten's little CoAP server is up and running, and we will have = the SENSEI server, gateway and resource directory up again later this = week. If you have a CoAP server running on the Internet, please edit the = Wiki and add the URL (or drop me an e-mail and I'll do it).=20 Some notes about the specifications to be tested: - We plan on testing draft-ietf-core-coap-03, which will be submitted by = next Monday. The main changes will be the addition of the Token Option, = which many have already implemented, along with some new error codes.=20 - The CoRE Link Format is very close to that of coap-02, however there = are quotes around more fields and the URL is now ./well-known/core. = Please update accordingly. - The Block Option (draft-ietf-core-block-00) and Subscription Option = (draft-ietf-core-observe-00) are the same as were tested in the last = interop by a few people. Now it would be great to test those more widely = along with the Token Option considerations.=20 Of course we are open to testing experimental features and ideas from = individual drafts. How about CoAP over DTLS? Welcome! Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-5--48579444 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxOTEzNTEw NlowIwYJKoZIhvcNAQkEMRYEFFeYMt7AMGkQKOviKliLrYep5UsjMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAA0Umscirutrdp7rcFLzpMvCpxCTO6vGDyjCl1cS26xJEyHCtXn2f1gm A9U0/hmetDXRLxsMipXq3mRbQJf1lyjN8hyXpIVTpwmNotFyL3Qp1y2fXssNtsFmyp5all/gCM3n IFICrkFAjib34pllFq9wRNWwQk5G2MWWFYQUF0xw/Wn2VJXrEQlkv0O6TxvdwCwX1fbUgfcgKT4E GKDkZPkmyih0fPTiIPkE+ktJlNkq/u65MpdE1peNjIg1DpV4PqXPIMbQy74QI3gxS5a+glNBQVbU lB6CftBvpaic+sHQSM0V2oHnyPGZ0mus0wYgDC8rg0CKpgDMsHDJCim9PiIAAAAAAAA= --Apple-Mail-5--48579444-- From behcetsarikaya@yahoo.com Tue Oct 19 07:42:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBBE3A681F for ; Tue, 19 Oct 2010 07:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD3+g9ZCFRlH for ; Tue, 19 Oct 2010 07:42:30 -0700 (PDT) Received: from nm9-vm1.bullet.mail.sp2.yahoo.com (nm9-vm1.bullet.mail.sp2.yahoo.com [98.139.91.197]) by core3.amsl.com (Postfix) with SMTP id 539E43A6800 for ; Tue, 19 Oct 2010 07:42:30 -0700 (PDT) Received: from [98.139.91.62] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 19 Oct 2010 14:43:58 -0000 Received: from [98.139.91.25] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 19 Oct 2010 14:43:58 -0000 Received: from [127.0.0.1] by omp1025.mail.sp2.yahoo.com with NNFMP; 19 Oct 2010 14:43:58 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 465815.4228.bm@omp1025.mail.sp2.yahoo.com Received: (qmail 28874 invoked by uid 60001); 19 Oct 2010 14:37:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1287499037; bh=SyT83OFEiyIIUfnkjlMdNda++d0IFGg3ba0SSHer3Og=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=5ByJvFxBpR3hfxlSBpkVa5JGRDADTcwEZi2/Folvm1pfbqRYGP1q3h1YAulvrt+iYNumGA6Q+cgFyFqwGhv3I8ybJC0DnqoLa2w+nzPqaeWoChxxi0CoYcJRM/7Quy49NxwbDOAVvjlTFit/LDERnL6pNhLWU6v2YwqJ2JTP4i8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=AUCSItXJQG6xDipWXsAOzY6KAzBEfSCR51pC5EGscvv3zzR/0XULQeOwePDTYXLbslaTgxlh5sAD3UYvukr2Orrh1xyczzqITpaOIeGjrpa72Zc66P3vCD+gbidW9M2Ct5ERmtIFXfZmfhGeBvLLaeE2ddcrK5CS+7G8XsdZqZA=; Message-ID: <415089.24048.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: FPuOvk0VM1nGIPEeP9CZShprO0rpbc1Frvqp23hFfPVdJgr 6sSVNnH2YssLP3QUK0B6CL5JkqIVv_ZiQ0K1kij3a98gxOC8JfV_FazgcK4. 00yfit803PSy2Fqw0mLtHzRtEURPufpHeBsyLU.uNNLb9rOPZXe_v_TKLYRp tZbqTB0w0JNhyZa1mVB6aiuRtya3fFATzOdXJh1B86CUctRSTH.Nnpojv3_9 smYdqeLtpURi2wI5dBnH..Fmg61OW4gQm3w_Jk_R7n.EUF4yi4gm_NVm7LlV FBk_CvmqY1MXrLItxLz5NhjxZxWenv2b2AJgSgLQRxbAAPOdeAXgAAL3VM43 seOi9BDnP5D_RYiui8e8t1NrkInQPU5PIbgs- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Tue, 19 Oct 2010 07:37:17 PDT X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 Date: Tue, 19 Oct 2010 07:37:17 -0700 (PDT) From: Behcet Sarikaya To: core MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [core] Fw: New Version Notification for draft-oflynn-core-bootstrapping-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:42:31 -0000 ----- Forwarded Message ---- > From: IETF I-D Submission Tool > To: sarikaya@ieee.org > Cc: yoshihiro.ohba@toshiba.co.jp; caozhen@chinamobile.com; >robert.cragie@gridmerge.com > Sent: Tue, October 19, 2010 9:34:20 AM > Subject: New Version Notification for draft-oflynn-core-bootstrapping-02 > > > A new version of I-D, draft-oflynn-core-bootstrapping-02.txt has been >successfully submitted by Behcet Sarikaya and posted to the IETF repository. > > Filename: draft-oflynn-core-bootstrapping > Revision: 02 > Title: Security Bootstrapping of Resource-Constrained Devices > Creation_date: 2010-10-19 > WG ID: Independent Submission > Number_of_pages: 23 > > Abstract: > The Internet of Things is marching its way towards completion. Nodes > can use standards from the 6LoWPAN and ROLL WG to achieve IP > connectivity. IEEE Standards ensure connectivity at lower layers for > resource-constrained devices. Yet a central problem remains at a > more basic layer without a suitable answer: how to initially > configure the network. Without configuration the network never > advances beyond a large box of nodes. Current solutions tend to be > specific to a certain vendor, node type, or application. > > This document outlines exactly what problems are faced in solving > this problem. General problems faced in any low-power wireless > network are outlined first; followed by how these apply to > bootstrapping. A selection of currently proposed techniques is > presented. From these a more generic approach is presented, which > can solve the problem for a wide range of situations. > > An emphasis is on performing this bootstrapping in a secure manner. > This document does not cover operation of the network securely. This > document does provide the basis for allowing the network to operate > securely however, by providing standard methods for key exchanges and > authentication. > > > > > > The IETF Secretariat. > > > From pab@peoplepowerco.com Wed Oct 20 07:42:48 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14943A69F8 for ; Wed, 20 Oct 2010 07:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JHG6cgLEXwy for ; Wed, 20 Oct 2010 07:42:45 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 50BD93A69ED for ; Wed, 20 Oct 2010 07:39:43 -0700 (PDT) Received: by ywa6 with SMTP id 6so2216183ywa.31 for ; Wed, 20 Oct 2010 07:38:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.213.10 with SMTP id p10mr5782904muq.7.1287585293682; Wed, 20 Oct 2010 07:34:53 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 07:34:53 -0700 (PDT) In-Reply-To: <5980BDE6-EA7F-4004-9006-24AFC3B1E395@sensinode.com> References: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> <066.ccdf64683d98090ab4a3693a95dadc1c@tools.ietf.org> <927D6F9D-1331-4245-834F-0F68EABEE823@tzi.org> <5980BDE6-EA7F-4004-9006-24AFC3B1E395@sensinode.com> Date: Wed, 20 Oct 2010 09:34:53 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=001636c5b2440f7d1c04930d5008 Cc: core issue tracker , core@ietf.org Subject: Re: [core] coap #25 (new): Token option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 14:42:48 -0000 --001636c5b2440f7d1c04930d5008 Content-Type: text/plain; charset=ISO-8859-1 As I catch up on my reviewing, I'm glad Token is going into CoAP-03 as a critical option. I think the combination of these three rules simplifies things a lot, and is the right solution for several problems. Token should be thought of as a client-created identifier that associates CoAP transaction messages with a single REST transaction. It is the pseudo-REST-level analogue to the CoAP-level transaction ID. With the addition of Token, there is never a need for URI-related options to appear in any response message. Immediate responses are identified by transaction ID; delayed responses are identified by Token. This fixes a problem with the Location option's use in redirects: redirects to a different authority or scheme could not be supported in an asynchronous response because the URI component options would be required along with Uri-Path for correlation with the original request. Not any more. Token should also become mandatory for use in CoAP-Observe, again because it's how the multiple responses get correlated with a subscription request. In the case of CoAP-Block, I suspect the token SHOULD be the same for every request associated with a multi-block transfer, simply to preserve its semantics as being associated with a single REST transaction. Peter On Mon, Oct 18, 2010 at 1:23 PM, Zach Shelby wrote: > Personally, I like this addition, thanks Peter. I do agree that it is > clearer for the implementor of a client to know if an asynchronous response > may come or not, and safer to avoid server generated tokens. > > Yes, we should have a ticket for expanding our error codes to make them > useful, but I forgot to do that. Will make one soon... > > Zach > > On Oct 18, 2010, at 9:16 PM, Peter Bigot wrote: > > > Then make it: > > > > 3. If a request does not include a Token option, the server MUST provide > its ReST response within the transaction response. If it cannot do so > (i.e., can only satisfy the request through an asynchronous response), it > MUST respond with error 400 "Bad Request (TBD) > > > > Replace 400 with some more informative code (I thought we had a ticket > related to extending the error codes in another context, but I don't > recognize it from the titles). > > > > I prefer this wording to making an exception for GET. Two reasons: > consistency, and support for clients that are unable to accommodate > asynchronous responses. Nothing prevents a client from sending the GET > without a token, and retransmitting it (and future GETs to the same > authority and/or resource) with one if the server indicates it needs to send > asynchronous responses. This same pattern is used in my proposal some > border-case failures in the block option. > > > > Other viewpoints on this, please? > > > > BTW: The reason I don't like server-created tokens is that it's the > client, not the server, that needs to disambiguate, and it can't if two > servers it talks to both decide to use the same token to indicate their > eventual response. > > > > Peter > > > > On Mon, Oct 18, 2010 at 11:05 AM, Carsten Bormann wrote: > > On Oct 18, 2010, at 17:05, Peter Bigot wrote: > > > > > Based on my argument that some clients would benefit from being able to > control whether asynchronous responses are acceptable to them, I propose > adding: > > > > > > 3. If a request does not include a Token option, the server MUST > provide its ReST response within the transaction response. > > > > Well, we can't just say MUST; we need to provide an error code for the > case where the server can't. > > > > Also, for a GET request, I like the current situation (no option needed) > much better. > > > > Gruesse, Carsten > > > > > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > --001636c5b2440f7d1c04930d5008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As I catch up on my reviewing, I'm glad Token is going into CoAP-03 as = a critical option.=A0 I think the combination of these three rules simplifi= es things a lot, and is the right solution for several problems.=A0 Token s= hould be thought of as a client-created identifier that associates CoAP tra= nsaction messages with a single REST transaction.=A0 It is the pseudo-REST-= level analogue to the CoAP-level transaction ID.

With the addition of Token, there is never a need for URI-related optio= ns to appear in any response message.=A0 Immediate responses are identified= by transaction ID; delayed responses are identified by Token.

This = fixes a problem with the Location option's use in redirects: redirects = to a different authority or scheme could not be supported in an asynchronou= s response because the URI component options would be required along with U= ri-Path for correlation with the original request.=A0 Not any more.

Token should also become mandatory for use in CoAP-Observe, again becau= se it's how the multiple responses get correlated with a subscription r= equest.=A0 In the case of CoAP-Block, I suspect the token SHOULD be the sam= e for every request associated with a multi-block transfer, simply to prese= rve its semantics as being associated with a single REST transaction.

Peter

On Mon, Oct 18, 2010 at 1:23 PM= , Zach Shelby <z= ach@sensinode.com> wrote:
Personally, I like this addition, thanks Peter. I do agree that it is clear= er for the implementor of a client to know if an asynchronous response may = come or not, and safer to avoid server generated tokens.

Yes, we should have a ticket for expanding our error codes to make them use= ful, but I forgot to do that. Will make one soon...

Zach

On Oct 18, 2010, at 9:16 PM, Peter Bigot wrote:

> Then make it:
>
> 3. If a request does not include a Token option, the server MUST provi= de its ReST response within the transaction response. =A0If it cannot do so= (i.e., can only satisfy the request through an asynchronous response), it = MUST respond with error 400 "Bad Request (TBD)
>
> Replace 400 with some more informative code (I thought we had a ticket= related to extending the error codes in another context, but I don't r= ecognize it from the titles).
>
> I prefer this wording to making an exception for GET. =A0Two reasons: = consistency, and support for clients that are unable to accommodate asynchr= onous responses. =A0Nothing prevents a client from sending the GET without = a token, and retransmitting it (and future GETs to the same authority and/o= r resource) with one if the server indicates it needs to send asynchronous = responses. =A0This same pattern is used in my proposal some border-case fai= lures in the block option.
>
> Other viewpoints on this, please?
>
> BTW: The reason I don't like server-created tokens is that it'= s the client, not the server, that needs to disambiguate, and it can't = if two servers it talks to both decide to use the same token to indicate th= eir eventual response.
>
> Peter
>
> On Mon, Oct 18, 2010 at 11:05 AM, Carsten Bormann <cabo@tzi.org> wrote:
> On Oct 18, 2010, at 17:05, Peter Bigot wrote:
>
> > Based on my argument that some clients would benefit from being a= ble to control whether asynchronous responses are acceptable to them, I pro= pose adding:
> >
> > 3. =A0If a request does not include a Token option, the server MU= ST provide its ReST response within the transaction response.
>
> Well, we can't just say MUST; we need to provide an error code for= the case where the server can't.
>
> Also, for a GET request, I like the current situation (no option neede= d) much better.
>
> Gruesse, Carsten
>
>

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


--001636c5b2440f7d1c04930d5008-- From pab@peoplepowerco.com Wed Oct 20 07:46:41 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886983A67EF for ; Wed, 20 Oct 2010 07:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcEJbDDFS7Ql for ; Wed, 20 Oct 2010 07:46:40 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 5AA983A69E5 for ; Wed, 20 Oct 2010 07:43:07 -0700 (PDT) Received: by gxk8 with SMTP id 8so2237404gxk.31 for ; Wed, 20 Oct 2010 07:42:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.121.20 with SMTP id y20mr5982408mum.5.1287585774807; Wed, 20 Oct 2010 07:42:54 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 07:42:54 -0700 (PDT) In-Reply-To: <057.2e09eba29a7e1fcfc1016f2c09b38552@tools.ietf.org> References: <057.2e09eba29a7e1fcfc1016f2c09b38552@tools.ietf.org> Date: Wed, 20 Oct 2010 09:42:54 -0500 Message-ID: From: Peter Bigot To: core issue tracker Content-Type: multipart/alternative; boundary=001636c5b18fb9a9eb04930d6c59 Cc: core@ietf.org Subject: Re: [core] coap #26 (new): Expand error code space X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 14:46:41 -0000 --001636c5b18fb9a9eb04930d6c59 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable To help keep a list of what codes are needed under this topic: Other examples will be from coap-block section 2.2. Not sure how many ther= e should be, but some include: * Incomplete message (block missing from put/post when last block received) * Too large (insufficient resources to store pending multi-block representation) The text implies these would be the same error code. That the server is allowed to select a smaller block size than was requeste= d by the client eliminates the need for a "Path MTU too large" error suggeste= d in a previous discussion. Peter On Tue, Oct 19, 2010 at 2:40 AM, core issue tracker wr= ote: > #26: Expand error code space > > CoAP is having a problem with useful error codes for special cases. > Returning a 400 every time something happens tells us very little. This > ticket is to consider expanding the error space with more useful codes f= or > special cases. Examples include: > > * Error: Token Option required by server > * Error: URI Authority required by server > * Error: Critical Option not supported > > To avoid collisions with HTTP 40x codes, it has been suggested that CoRE > reserves its own code space in the Section 11.1 table for CoAP-specific > error codes in the 240-255 range. These errors would be converted to e.g= . > an HTTP 400 in a proxy. > > -- > > --------------------------------+----------------------------------------= --- > Reporter: zach@=85 | Owner: zach@=85 > Type: enhancement | Status: new > Priority: minor | Milestone: coap-03 > Component: coap | Version: > Severity: - | Keywords: > > --------------------------------+----------------------------------------= --- > > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001636c5b18fb9a9eb04930d6c59 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable To help keep a list of what codes are needed under this topic:

Other= examples will be from coap-block section 2.2.=A0 Not sure how many there s= hould be, but some include:

* Incomplete message (block missing from= put/post when last block received)
* Too large (insufficient resources to store pending multi-block representa= tion)

The text implies these would be the same error code.

Th= at the server is allowed to select a smaller block size than was requested = by the client eliminates the need for a "Path MTU too large" erro= r suggested in a previous discussion.

Peter

On Tue, Oct 19, 2010 at 2:40 AM= , core issue tracker <trac@tools.ietf.org> wrote:
#26: Expand error code space

=A0CoAP is having a problem with useful error codes for special cases.
=A0Returning a 400 every time something happens tells us very little. This<= br> =A0ticket is to consider expanding the error space with more useful codes f= or
=A0special cases. Examples include:

=A0* Error: Token Option required by server
=A0* Error: URI Authority required by server
=A0* Error: Critical Option not supported

=A0To avoid collisions with HTTP 40x codes, it has been suggested that CoRE=
=A0reserves its own code space in the Section 11.1 table for CoAP-specific<= br> =A0error codes in the 240-255 range. These errors would be converted to e.g= .
=A0an HTTP 400 in a proxy.

--
--------------------------------+------------------------------------------= -
=A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: = =A0zach@=85
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: =A0coap-= 03
Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords: --------------------------------+------------------------------------------= -

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/26&= gt;
core <http://t= ools.ietf.org/core/>

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

--001636c5b18fb9a9eb04930d6c59-- From pab@peoplepowerco.com Wed Oct 20 08:20:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84F93A6800 for ; Wed, 20 Oct 2010 08:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cA+qyNXUV+Q for ; Wed, 20 Oct 2010 08:20:28 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B310B3A67D3 for ; Wed, 20 Oct 2010 08:20:28 -0700 (PDT) Received: by gyc15 with SMTP id 15so2289280gyc.31 for ; Wed, 20 Oct 2010 08:22:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with SMTP id z15mr1081798muo.42.1287588120387; Wed, 20 Oct 2010 08:22:00 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 08:22:00 -0700 (PDT) Date: Wed, 20 Oct 2010 10:22:00 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=00163642663d887d8704930df8a5 Subject: [core] CoAP-02 section 2.5.2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 15:20:29 -0000 --00163642663d887d8704930df8a5 Content-Type: text/plain; charset=ISO-8859-1 A clarification of something which threw me off track for a little while: Section 2.5.2 starts: The Universal Resource Identifier (URI) [RFC3986] is an important feature of the web architecture, where the relative part of the URI indicates the resource being manipulated. This is not quite correct. It conflates URI references with (hierarchical) URIs, and may have been a source of confusion within the working group, including leading to some mistaken assumptions about how URIs with multicast addresses might work. A hierarchical URI comprises a scheme, a hier-part, and optionally query and fragment parts. I believe the text above is intended to reflect the general position in REST that it is solely the hier-part (comprising authority and path) that identifies the resource; the scheme and any query and fragment parts do not contribute to this identification. (The scheme tells you how to talk to the resource owner; the fragment identifies elements internal to the resource; I would say the query-part conveys metadata associated with the REST operation to be performed.) There is no such thing as a "relative part" of a URI. There is a relative URI reference, defined at http://tools.ietf.org/html/rfc3986#section-4.2, which includes at most the authority and path parts. But it must be combined with a base URI to produce an actual URI. In short, when determining the resource identified by a URI you need a full URI not a relative URI reference. You can ignore the scheme and any query or fragment parts, but you can't ignore the authority or path. If I was the only one who ever mis-read that, never mind. Peter --00163642663d887d8704930df8a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A clarification of something which threw me off track for a little while:= =A0 Section 2.5.2 starts:

=A0=A0 The Universal Resource Identifier (= URI) [RFC3986] is an important
=A0=A0 feature of the web architecture, w= here the relative part of the URI
=A0=A0 indicates the resource being manipulated.

This is not quite c= orrect.=A0 It conflates URI references with (hierarchical) URIs, and may ha= ve been a source of confusion within the working group, including leading t= o some mistaken assumptions about how URIs with multicast addresses might w= ork.

A hierarchical= URI comprises a scheme, a hier-part, and optionally query and fragment= parts.=A0 I believe the text above is intended to reflect the general posi= tion in REST that it is solely the hier-part (comprising authority and path= ) that identifies the resource; the scheme and any query and fragment parts= do not contribute to this identification.=A0 (The scheme tells you how to = talk to the resource owner; the fragment identifies elements internal to th= e resource; I would say the query-part conveys metadata associated with the= REST operation to be performed.)

There is no such thing as a "relative part" of a URI.=A0 Ther= e is a relative URI reference, defined at http://tools.ietf.org/html/rfc3986#section-4.2, which includes at most the authority and path parts.=A0 But it must be c= ombined with a base URI to produce an actual URI.

In short, when determining the resource identified by a URI you need a = full URI not a relative URI reference.=A0 You can ignore the scheme and any= query or fragment parts, but you can't ignore the authority or path.
If I was the only one who ever mis-read that, never mind.

Peter<= br>
--00163642663d887d8704930df8a5-- From pab@peoplepowerco.com Wed Oct 20 09:04:41 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05513A6875 for ; Wed, 20 Oct 2010 09:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4HRolVoavLr for ; Wed, 20 Oct 2010 09:04:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5D10D3A684D for ; Wed, 20 Oct 2010 09:04:40 -0700 (PDT) Received: by vws12 with SMTP id 12so2236312vws.31 for ; Wed, 20 Oct 2010 09:06:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.219.16 with SMTP id w16mr5715976muq.81.1287590772421; Wed, 20 Oct 2010 09:06:12 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 09:06:12 -0700 (PDT) Date: Wed, 20 Oct 2010 11:06:12 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=0016364d22ab9b38b204930e961c Subject: [core] Options: Uri-Query and Uri-Scheme X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 16:04:41 -0000 --0016364d22ab9b38b204930e961c Content-Type: text/plain; charset=ISO-8859-1 Two option issues: I think I suggested long ago that scheme be removed because it was always coap, but I meant to be speaking of its use in resource discovery. For CoAP as a whole, I think it needs to be put back: possibly in support of the potential for using a different scheme for multicast CoAP as discussed on the last working group telecon, but certainly because without it you can't redirect responses to a resource in a different scheme (such as HTTP). Also, we need a separate option for Uri-Query, per previous discussion on this list. Currently the only place for the query-part is within the Uri-Path option, which is not consistent with URI syntax. Absence indicates no query-part in the URI; presence provides the text following the hook in the reconstructed URI. Related to that, the text in 2.5.2 has: CoAP splits the URI up into its three parts with the default coap:// scheme, Uri-Authority and Uri-Path Options. The full URI can be created by concatenating those parts (or their defaults if not present). This is inaccurate. Reconstruction of a full URI is done relative to a CoAP message header, and is done by catenating: Uri-Scheme "://" Uri-Authority "/" Uri-Path ( "?" Uri-Query ) if Uri-Query is present Where reference to an option is replaced by the value of that option if the option is in the header, and the default value for the option if it is not present. The default value for Uri-Scheme is "coap". The default value for Uri-Authority and Uri-Path is the empty string. Uri-Query has no default value. Not sure how to format that in the text. The same reconstruction is required for getting the full URI for the target of a redirection response, except that the Location option is used instead of the Uri-Path option. Peter --0016364d22ab9b38b204930e961c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Two option issues:=A0 I think I suggested long ago that scheme be removed b= ecause it was always coap, but I meant to be speaking of its use in resourc= e discovery.=A0 For CoAP as a whole, I think it needs to be put back: possi= bly in support of the potential for using a different scheme for multicast = CoAP as discussed on the last working group telecon, but certainly because = without it you can't redirect responses to a resource in a different sc= heme (such as HTTP).

Also, we need a separate option for Uri-Query, per previous discussion = on this list.=A0 Currently the only place for the query-part is within the = Uri-Path option, which is not consistent with URI syntax.=A0 Absence indica= tes no query-part in the URI; presence provides the text following the hook= in the reconstructed URI.=A0

Related to that, the text in 2.5.2 has:
   Co=
AP splits the URI up into its three parts with the default coap://
   scheme, Uri-Authority and Uri-Path Options.  The full URI can be
   created by concatenating those parts (or their defaults if not
   present).
This is inaccurate.=A0 Reconstruction of a full URI is do= ne relative to a CoAP message header, and is done by catenating:

=A0= =A0 Uri-Scheme
=A0=A0 "://"
=A0=A0 Uri-Authority
=A0=A0 = "/"
=A0=A0 Uri-Path
=A0=A0 ( "?"=A0 Uri-Query ) if Uri-Query is pr= esent

Where reference to an option is replaced by the value of that = option if the option is in the header, and the default value for the option= if it is not present.=A0 The default value for Uri-Scheme is "coap&qu= ot;.=A0 The default value for Uri-Authority and Uri-Path is the empty strin= g.=A0 Uri-Query has no default value.

Not sure how to format that in the text.

The same reconstruction= is required for getting the full URI for the target of a redirection respo= nse, except that the Location option is used instead of the Uri-Path option= .

Peter
--0016364d22ab9b38b204930e961c-- From pab@peoplepowerco.com Wed Oct 20 09:18:20 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5319E3A6921 for ; Wed, 20 Oct 2010 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdLYElsz19dX for ; Wed, 20 Oct 2010 09:18:19 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 99FBE3A6879 for ; Wed, 20 Oct 2010 09:18:18 -0700 (PDT) Received: by vws12 with SMTP id 12so2250301vws.31 for ; Wed, 20 Oct 2010 09:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.219.16 with SMTP id w16mr5745297muq.81.1287591591422; Wed, 20 Oct 2010 09:19:51 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 09:19:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Oct 2010 11:19:51 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=0016364d22ab6c299304930ec786 Subject: Re: [core] Options: Uri-Query and Uri-Scheme X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 16:18:20 -0000 --0016364d22ab6c299304930ec786 Content-Type: text/plain; charset=ISO-8859-1 Need to correct this; reconstructing the URI should be: ( Uri-Scheme ":" ) ( "//" Uri-Authority ) only if Uri-Authority is present ( "/" Uri-Path ) ( "?" Uri-Query ) only if Uri-Query is present Note that this implicitly defines the syntax of strings valid for these options, to wit: Uri-Scheme conforms to the scheme rule in section 3.1 of RFC3986 Uri-Authority conforms to "host [ : port ]" (section 3.2 of RFC3986, excluding use of userinfo) Uri-Path confirms to the path-noscheme (path-rootless?) rule in section 3.3 of RFC3986 Uri-Query conforms to the query rule in section 3.4 of RFC3986 Delegation to existing definitions is the way to go. This eliminates the need for similar rules in section 5.3, which otherwise implicitly restrict the Uri-Authority syntax. There had been talk of an option for a binary encoding of Uri-Authority; I assume that would be a new, critical option, the presence of which would complicate this reconstruction a little. Peter --0016364d22ab6c299304930ec786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Need to correct this; reconstructing the URI should be:

=A0=A0 ( Uri-Scheme ":" )
=A0=A0 ( "//"= Uri-Authority ) only if Uri-Authority is present
=A0=A0 ( "/"= Uri-Path )
=A0=A0 ( "?"=A0 Uri-Query ) only if Uri-Query is p= resent

Note that this implicitly defines the syntax of strings valid for these opt= ions, to wit:

Uri-Scheme conforms to the scheme rule in section 3.1 = of RFC3986
Uri-Authority conforms to "host [ : port ]" (sectio= n 3.2 of RFC3986, excluding use of userinfo)
Uri-Path confirms to the path-noscheme (path-rootless?) rule in section 3.3= of RFC3986
Uri-Query conforms to the query rule in section 3.4 of RFC39= 86

Delegation to existing definitions is the way to go.=A0 This elim= inates the need for similar rules in section 5.3, which otherwise implicitl= y restrict the Uri-Authority syntax.

There had been talk of an option for a binary encoding of Uri-Authority= ; I assume that would be a new, critical option, the presence of which woul= d complicate this reconstruction a little.

Peter

--0016364d22ab6c299304930ec786-- From kerlyn2001@gmail.com Wed Oct 20 10:55:26 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52423A68C0 for ; Wed, 20 Oct 2010 10:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeTR1HDWkbhJ for ; Wed, 20 Oct 2010 10:55:25 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C34523A6879 for ; Wed, 20 Oct 2010 10:55:24 -0700 (PDT) Received: by bwz14 with SMTP id 14so3101537bwz.31 for ; Wed, 20 Oct 2010 10:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jM+O73lO1wVeHo2/ta+QgaXy6JbudT0VoIvh2wf892c=; b=tefuhZWHxJo//NOuoBWZuSIg1iBwE3ppti3FfN3aIcuNI5wqvIIlJ/9oRc6GN/OIJG STzpdM6oSAONPv3E1BZTbXfUDfbDJy19+2HMU9ZHVWDuYr95kqmqWw0xdR6vqaWiPvKj nGOBHi12/kWBQY+LpL2jGD63dDyn+aAot+5vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=p62g4/ALH1gwQKXAEkgylGGGIKMXruSOPaYVwTakmb0gn7VGNHJoVz9GLWn4ctd21R fVKXvvhGeTfpozxFiv9UO5xc26hwH/ShMtTmSCagF1q9lLpu35Yi61sKS1iO4SE2dpOU jAQa/2EGKj7DiZgCKN7+LSXqC3RG4X1mH4NhI= MIME-Version: 1.0 Received: by 10.204.113.65 with SMTP id z1mr7184080bkp.25.1287597416103; Wed, 20 Oct 2010 10:56:56 -0700 (PDT) Received: by 10.204.103.72 with HTTP; Wed, 20 Oct 2010 10:56:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Oct 2010 13:56:56 -0400 Message-ID: From: Kerry Lynn To: Peter Bigot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Options: Uri-Query and Uri-Scheme X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 17:55:26 -0000 Hi Peter, In light of your clarifications, I wonder if we can discuss some of the comments in your earlier email? > URI references... may have been a source of confusion within the > working group, including leading to some mistaken assumptions > about how URIs with multicast addresses might work. First, we're agreed that we're really talking about URLs, right? "As this URI is used purely as a locator, CoAP only supports Universal Resource Locator features of [RFC3986] although throughout the document we refer to URI." It believe there was a typo in the coap draft, as you pointed out. However, it seems that in the later descriptions relative URIs were everywhere disallowed by language such as "CoAP does not support "." or ".." in URIs" and "The leading slash is assumed and and MUST be omitted". Jumping around a bit, you said: > the scheme and any query and fragment parts do not contribute to > this identification I think from the perspective of a coap server this MIGHT be correct, but I'm not positive. The reason I'm agnostic is because I'm not sure yet how the coap-to-http mapping will work. >From outside the server, for location purposes, I don't agree. In the -bc draft, Peter van der Stok and I said that the scheme and authority parts could be used by e.g. DNS-SD to locate instances of the coap service. IOW, you expect that a query for "http://foo.example.com" would give a different result than "coap://foo.example.com" in terms of returned port and other answers. Before returning to group resource locators, I'd like to vet an idea related to multi-function devices. I think there's been an implicit assumption that "functionality" (e.g. an object model) may be located at any interior node in a URI hierarchy, and may be optionally named by a short URI. This is the thrust of draft-ietf-core-link-format. But modern HTTP servers also implement the concept of name-based virtual hosts, in which multiple authorities can be mapped to the same IP address. Thus, http://foo.example.com and http://bar... might be located at the same IP & port. It seems to me that this would be a natural way to express multi-function devices (as a 1:1 mapping of "device" to DNS host name) as well as lead to shorter URIs. I think this might be especially useful when devising coap-to-foo legacy gateways. The implication is that the Uri- Authority Option would be used with some regularity in this case. The idea of authorities mapping to muticast addresses was introduced in -bc-01 and referenced in -groupcomm-00. In the latter, we say that a request directed to a group of nodes MUST be directed to a /.well-known/core/... Uri-Path. I was thinking that a name-based approach would apply here, since the server receiving such a request (and belonging to the IP group) could be considered as a server for the group authority as well as for any individual authorities it might serve. However, it seems the name-based approach might also create a problem for group resources in the case of multiple vhosts per interface, in that the /.well-known/core/... Uri-Path received in the request must be resolved to an individual Uri-Authority at that interface as well as a Uri-Path, and these would be returned in any response. How is this handled in the case where the same absolute path is found in more than one virtual host? I'd be very interested to hear other opinions about how group resource naming might work. Regards, -K- On Wed, Oct 20, 2010 at 12:19 PM, Peter Bigot wrote= : > Need to correct this; reconstructing the URI should be: > > =A0=A0 ( Uri-Scheme ":" ) > =A0=A0 ( "//" Uri-Authority ) only if Uri-Authority is present > =A0=A0 ( "/" Uri-Path ) > =A0=A0 ( "?"=A0 Uri-Query ) only if Uri-Query is present > > Note that this implicitly defines the syntax of strings valid for these > options, to wit: > > Uri-Scheme conforms to the scheme rule in section 3.1 of RFC3986 > Uri-Authority conforms to "host [ : port ]" (section 3.2 of RFC3986, > excluding use of userinfo) > Uri-Path confirms to the path-noscheme (path-rootless?) rule in section 3= .3 > of RFC3986 > Uri-Query conforms to the query rule in section 3.4 of RFC3986 > > Delegation to existing definitions is the way to go.=A0 This eliminates t= he > need for similar rules in section 5.3, which otherwise implicitly restric= t > the Uri-Authority syntax. > > There had been talk of an option for a binary encoding of Uri-Authority; = I > assume that would be a new, critical option, the presence of which would > complicate this reconstruction a little. > > Peter > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From pab@peoplepowerco.com Wed Oct 20 11:20:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5213A6847 for ; Wed, 20 Oct 2010 11:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SldAgjWnd6qb for ; Wed, 20 Oct 2010 11:20:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id DF43D3A681B for ; Wed, 20 Oct 2010 11:20:28 -0700 (PDT) Received: by ywa6 with SMTP id 6so2433332ywa.31 for ; Wed, 20 Oct 2010 11:22:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.221.5 with SMTP id y5mr6228098muq.134.1287598920812; Wed, 20 Oct 2010 11:22:00 -0700 (PDT) Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 11:22:00 -0700 (PDT) Date: Wed, 20 Oct 2010 13:22:00 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=0016367659eb49f0e00493107c9f Subject: [core] draft-ietf-core-block-00 comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 18:20:30 -0000 --0016367659eb49f0e00493107c9f Content-Type: text/plain; charset=ISO-8859-1 As discussed in the thread culminating in http://www.ietf.org/mail-archive/web/core/current/msg00716.html, for correctness in certain conditions the server must not respond with a Block option if the original request did not include a Block option, and must include an ETag option in every response message containing a Block option. Section 2.1: Based on the discussion referred to above, the Block option should have no default value. A client capable of processing multi-part responses and unsure whether this is necessary in a given request should always include a block option with a value of 0x07 (first block, 2048-byte payload), or a smaller number if it cannot accommodate a 2048-byte response. Section 2.2. Related to ticket #26, a new error code indicating "Representation Too Large" must be provided to indicate that the server knows it cannot provide the entire representation in a single message and that the client must indicate its willingness to perform multi-part transactions by resubmitting the request with a Block option in the header. (The text in this section allowing the server to select a transaction block size less than the size requested for the first block eliminates the need to use this error code if the server knows the path MTU is too small for the requested size, a concern in the previous discussion.) If the Block option is used by the requestor, all GET requests in a single transaction (except for the last one with the M bit not set) MUST ultimately use the same size. The server SHOULD use the block This paragraph needs to be reworked. I don't think the parenthetical remark concerning the M bit is relevant; certainly not for GET requests, since the client doesn't know whether there's more data, and not for the last response, where the block size is irrelevant. The rest of the paragraph implies that the size in the block option should be fixed in the first server response, taking into account the maximum size indicated by the client in the initial request, and that both the server and the client must continue to use this block size in all CoAP messages related to this REST transaction. Reference to GET requests throughout the paragraph makes this unclear, unless it is not intended to apply to PUT or POST as well, which might result in inconsistencies. resources. In the latter case, the Block option SHOULD be used in conjunction with the Etag option, to ensure that the blocks being reassembled are from the same version of the representation. When s/SHOULD/MUST/. See previous discussion thread. reassembler MUST compare Etag options. If the Etag options do not Shelby & Bormann Expires April 21, 2011 [Page 6] Internet-Draft CoAP-block October 2010 match in a GET transfer, the requestor has the option of attempting to retrieve fresh values for the blocks it retrieved first. To minimize the resulting inefficiency, the server MAY cache the current value of a representation for an ongoing sequence of requests, but there is no requirement for the server to establish any state. The client MAY facilitate identifying the sequence by using the Token option. Things are getting messy here. Assume I'm 50 blocks into receiving a representation, and the 51st block comes with a new ETag, invalidating everything I did before. The text above suggests I can go back and request the previous 50 blocks, using the new ETag. This implies that using the block option to randomly access fragments of the representation is valid, because here is a case where I'm not receiving the blocks in strict sequence starting at the beginning. It's also a case where I'm asking for block zero again, which normally would allow a change in block size, but maybe not in this case? Like I said, getting messy. It'd be a lot cleaner if use of the block option must be non-decreasing (once you request block N, you can't request any block less than N; if you can, we need an error code for when the server to use when it can no longer provide that part of the representation). Furthermore, the requests for non-initial blocks should include the ETag for the representation being constructed, and if the representation has changed an error response should say so, telling the client to start over, rather than expecting it to cache the Nth block then re-request the older stuff. There may not even be an Nth block in the new representation; what does the server do then? This does change what ETag means, specifically with respect to what a server does if a request includes it and the tagged representation is no longer available (proxies request a new one from upstream; servers in block mode send an error). It may be that a new option is required for block, to keep these behaviors separated. It also rules out parallel active requests for multiple blocks. I think that's a reasonable limitation for constrained devices. If multiple concurrently proceeding block-wise PUT or POST operations are possible, the requestor SHOULD use the Token option to clearly separate the different sequences. In this case, when reassembling Maybe. Token seems to be settling into an identifier for a specific REST transaction. Use of the block option is clearly described as splitting a single REST transaction into multiple CoAP transactions, so I would say that Token SHOULD be used in any block operation, and in fact the same Token SHOULD be used in every block request that's part of the same underlying REST transaction. Since Token is client-specified, the server must further distinguish these messages based on some other identifying information like message source IP address (i.e., if the text above was supposed to relieve the server of this obligation, it doesn't work). Any client that doesn't support asynchronous responses but does want to do simultaneous block requests related to the same resource has a problem, but I'll suggest the appropriate response is the good old "Don't do that". The more I dig into this, the more I really think that using RFC2348 and RFC1350 would be a lot simpler than trying to create an alternative like CoAP block. Now that I've found RFC2348, which allows TFTP packets to be less than 512 bytes, I may very well just go that way for my deployment environment. Peter --0016367659eb49f0e00493107c9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As discussed in the thread culminating in=20 http://www.ietf.org/mail-archive/web/core/current/msg00716.html, for= =20 correctness in certain conditions the server must not respond with a=20 Block option if the original request did not include a Block option, and must include an ETag option in every response message containing a=20 Block option.

Section 2.1:

Based on the discussion referred to above, the Bloc= k option should have no default value.=A0 A client capable of processing mu= lti-part responses and unsure whether this is necessary in a given request = should always include a block option with a value of 0x07 (first block, 204= 8-byte payload), or a smaller number if it cannot accommodate a 2048-byte r= esponse.

Section 2.2.

Related to ticket #26, a new error code indicating "Representation= Too=20 Large" must be provided to indicate that the server knows it cannot=20 provide the entire representation in a single message and that the=20 client must indicate its willingness to perform multi-part transactions=20 by resubmitting the request with a Block option in the header.=A0 (The text= in this section allowing the server to select a transaction block size=20 less than the size requested for the first block eliminates the need to use= this error code if the server knows the path MTU is too small for the requ= ested size, a concern in the previous discussion.)
   If the Block option is used by the requestor, all=
 GET requests in a
   single transaction (except for the last one with the M bit not set)
   MUST ultimately use the same size.  The server SHOULD use the block
This paragraph needs to be reworked.=A0 I don't think the parenth= etical remark concerning the M bit is relevant; certainly not for GET reque= sts, since the client doesn't know whether there's more data, and n= ot for the last response, where the block size is irrelevant.=A0 The rest o= f the paragraph implies that the size in the block option should be fixed i= n the first server response, taking into account the maximum size indicated= by the client in the initial request, and that both the server and the cli= ent must continue to use this block size in all CoAP messages related to th= is REST transaction.=A0 Reference to GET requests throughout the paragraph = makes this unclear, unless it is not intended to apply to PUT or POST as we= ll, which might result in inconsistencies.
=A0=A0 resources.  In the latter case, the Block opt=
ion SHOULD be used in
   conjunction with the Etag option, to ensure that the blocks being
   reassembled are from the same version of the representation.  When
s/SHOULD/MUST/.=A0 See previous discus=
sion thread.
  reassembler MUST compare Etag opti=
ons.  If the Etag options do not

Shelby & Bormann         Expires April 21, 2011                 [Page 6=
] 
Internet-Draft                 CoAP-block                   Octob=
er 2010

=A0=A0 match in a GET transfer, the requestor has the option of attempting
   to retrieve fresh values for the blocks it retrieved first.  To
   minimize the resulting inefficiency, the server MAY cache the current
   value of a representation for an ongoing sequence of requests, but
   there is no requirement for the server to establish any state.  The
   client MAY facilitate identifying the sequence by using the Token
   option.

Things are getting messy here.=A0 Assume I'm 50 blocks into recei=
ving a representation, and the 51st block comes with a new ETag, invalidati=
ng everything I did before.=A0 The text above suggests I can go back and re=
quest the previous 50 blocks, using the new ETag.


This implies that using the block option to randomly access fragments o=
f the representation is valid, because here is a case where I'm not rec=
eiving the blocks in strict sequence starting at the beginning.=A0 It's=
 also a case where I'm asking for block zero again, which normally woul=
d allow a change in block size, but maybe not in this case?=A0 Like I said,=
 getting messy.


It'd be a lot cleaner if use of the block option must be non-decrea=
sing (once you request block N, you can't request any block less than N=
; if you can, we need an error code for when the server to use when it can =
no longer provide that part of the representation).=A0 Furthermore, the req=
uests for non-initial blocks should include the ETag for the representation=
 being constructed, and if the representation has changed an error response=
 should say so, telling the client to start over, rather than expecting it =
to cache the Nth block then re-request the older stuff.=A0 There may not ev=
en be an Nth block in the new representation; what does the server do then?=



This does change what ETag means, specifically with respect to what a s=
erver does if a request includes it and the tagged representation is no lon=
ger available (proxies request a new one from upstream; servers in block mo=
de send an error).=A0 It may be that a new option is required for block, to=
 keep these behaviors separated.


It also rules out parallel active requests for multiple blocks.=A0 I th=
ink that's a reasonable limitation for constrained devices.
   If multiple concurrently proceeding block-wise PUT or POS=
T operations
   are possible, the requestor SHOULD use the Token option to clearly
   separate the different sequences.  In this case, when reassembling

Maybe.=A0 Token seems to be settling into an identifier for a specifi=
c REST transaction.=A0 Use of the block option is clearly described as spli=
tting a single REST transaction into multiple CoAP transactions, so I would=
 say that Token SHOULD be used in any block operation, and in fact the same=
 Token SHOULD be used in every block request that's part of the same un=
derlying REST transaction.=A0 Since Token is client-specified, the server m=
ust further distinguish these messages based on some other identifying info=
rmation like message source IP address (i.e., if the text above was suppose=
d to relieve the server of this obligation, it doesn't work).=A0 Any cl=
ient that doesn't support asynchronous responses but does want to do si=
multaneous block requests related to the same resource has a problem, but I=
'll suggest the appropriate response is the good old "Don't do=
 that".


The more I dig into this, the more I really think that using RFC2348 an=
d RFC1350 would be a lot simpler than trying to create an alternative like =
CoAP block.=A0 Now that I've found RFC2348, which allows TFTP packets t=
o be less than 512 bytes, I may very well just go that way for my deploymen=
t environment.


Peter


--0016367659eb49f0e00493107c9f--

From pab@peoplepowerco.com  Wed Oct 20 12:08:11 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220D53A67E1 for ; Wed, 20 Oct 2010 12:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.358,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHHVgowlMfvC for ; Wed, 20 Oct 2010 12:08:09 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 2AC913A67D9 for ; Wed, 20 Oct 2010 12:08:09 -0700 (PDT)
Received: by gyc15 with SMTP id 15so2508720gyc.31 for ; Wed, 20 Oct 2010 12:09:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.165.10 with SMTP id s10mr1841007muo.19.1287601781556; Wed, 20 Oct 2010 12:09:41 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 12:09:41 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 20 Oct 2010 14:09:41 -0500
Message-ID: 
From: Peter Bigot 
To: Kerry Lynn 
Content-Type: multipart/alternative; boundary=00163662e69bcd47c50493112683
Cc: core 
Subject: Re: [core] Options: Uri-Query and Uri-Scheme
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 20 Oct 2010 19:08:11 -0000

--00163662e69bcd47c50493112683
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 20, 2010 at 12:56 PM, Kerry Lynn  wrote:

> Hi Peter,
>
> In light of your clarifications, I wonder if we can discuss some of the
> comments in your earlier email?


Certainly.


> > URI references... may have been a source of confusion within the
> > working group, including leading to some mistaken assumptions
> > about how URIs with multicast addresses might work.
>
> First, we're agreed that we're really talking about URLs, right?
> "As this URI is used purely as a locator, CoAP only supports Universal
>  Resource Locator features of [RFC3986] although throughout the
>  document we refer to URI."
>

At the moment, yes.  However, I can think of no technical justification for
this restriction.  If an IP address and port for the owner of a resource
identified by a URN could be found elsewhere (e.g., hard-coding or LDAP or
DNS-SD), and CoAP added a way to pass that URN within the request message (a
Uri-Name option), URNs would work too.

As a general rule, my understanding is that IETF, per text in RFC3305,
prefers use of the term URI, because the cases where URL and URN must be
distinguished are so rare.  In fact, I don't think CoAP is one of those
cases.  CoAP does not mandate how the location of a resource (in the sense
of an IP address and port) is determined.  Nor does it strictly require that
the path part be interpreted hierarchically.  I think the text "As this URI
is used purely as a locator" should be removed.

It believe there was a typo in the coap draft, as you pointed out.
> However, it seems that in the later descriptions relative URIs
> were everywhere disallowed by language such as "CoAP does not
> support "." or ".." in URIs" and "The leading slash is assumed and
> and MUST be omitted".
>
> Jumping around a bit, you said:
> > the scheme and any query and fragment parts do not contribute to
> > this identification
>
> I think from the perspective of a coap server this MIGHT be correct,
> but I'm not positive.  The reason I'm agnostic is because I'm not
> sure yet how the coap-to-http mapping will work.
>
> From outside the server, for location purposes, I don't agree.  In the
> -bc draft, Peter van der Stok and I said that the scheme and authority
> parts could be used by e.g. DNS-SD to locate instances of the coap
> service.  IOW, you expect that a query for "http://foo.example.com"
> would give a different result than "coap://foo.example.com" in terms
> of returned port and other answers.
>

Yes.  Actually, this relates to a question you raised on both CoAP WG
telecons: whether http://server/path denotes the same resource as
https://server/path.  Everybody who spoke up, including me, said "no",
because from a web-server perspective the two reach completely different
implementations.

I think from the REST perspective the answer is "yes".  That you can
legitimately get different representations of the resource from the
different servers is because of metadata provided as a consequence of going
through the different protocol, but RESTfully whatever you get really should
be representations of the same resource.  Perhaps one has more detail than
the other, but if they are truly unrelated, it is a poorly-designed system.

I stand by my assertion that, in REST, the scheme is irrelevant to the
resource identification.  If I have to, I'll go dig up the reference from
Fielding that supports that position.

However, I don't think it matters, because what DNS-SD is providing is not
the address of the REST resource but the address to a server that can be
used to manipulate that resource using a specific protocol.  All is good.

>
> Before returning to group resource locators, I'd like to vet an idea
> related to multi-function devices.  I think there's been an implicit
> assumption that "functionality" (e.g. an object model) may be located
> at any interior node in a URI hierarchy, and may be optionally named
> by a short URI.  This is the thrust of draft-ietf-core-link-format.  But
> modern HTTP servers also implement the concept of name-based
> virtual hosts, in which multiple authorities can be mapped to the
> same IP address.  Thus, http://foo.example.com and http://bar...
> might be located at the same IP & port.  It seems to me that this
> would be a natural way to express multi-function devices (as a 1:1
> mapping of "device" to DNS host name) as well as lead to shorter
> URIs.  I think this might be especially useful when devising
> coap-to-foo legacy gateways.  The implication is that the Uri-
> Authority Option would be used with some regularity in this case.
>

Yes: this is exactly why I thought it so important to ensure Uri-Authority
was preserved end-to-end by CoAP-carried REST transactions.

The idea of authorities mapping to muticast addresses was
> introduced in -bc-01 and referenced in -groupcomm-00.  In the
> latter, we say that a request directed to a group of nodes MUST
> be directed to a /.well-known/core/... Uri-Path.  I was thinking
> that a name-based approach would apply here, since the server
> receiving such a request (and belonging to the IP group) could
> be considered as a server for the group authority as well as for
> any individual authorities it might serve.


Yes, the problem being that all receiving hosts would believe they were the
(single) server responsible for that resource.  Separate issue, ignore it
for now.


> However, it seems
> the name-based approach might also create a problem for
> group resources in the case of multiple vhosts per interface,
> in that the /.well-known/core/... Uri-Path received in the request
> must be resolved to an individual Uri-Authority at that interface
> as well as a Uri-Path, and these would be returned in any
> response.  How is this handled in the case where the same
> absolute path is found in more than one virtual host?
>

In HTTP, I don't think you'd even notice.  Each host has its own directory
namespace.  The authority (Host header) is not optional (though it can be
empty), so only one directory structure would be examined for a match to the
path part.  It would be there, or it wouldn't.  There would never be an
ambiguity.

Same thing in CoAP: if Uri-Authority is present, it's used to select which
of the directory namespaces hosted via CoAP on that server and port should
be used to resolve the path part.  If it's absent, there's got to be exactly
one default namespace that will be used.

I'd be very interested to hear other opinions about how group
> resource naming might work.
>

In my glance over the rahman draft I saw some potential approaches; I hope
to have comments on it sometime tomorrow.


>
> Regards, -K-
>
>
> On Wed, Oct 20, 2010 at 12:19 PM, Peter Bigot 
> wrote:
> > Need to correct this; reconstructing the URI should be:
> >
> >    ( Uri-Scheme ":" )
> >    ( "//" Uri-Authority ) only if Uri-Authority is present
> >    ( "/" Uri-Path )
> >    ( "?"  Uri-Query ) only if Uri-Query is present
> >
> > Note that this implicitly defines the syntax of strings valid for these
> > options, to wit:
> >
> > Uri-Scheme conforms to the scheme rule in section 3.1 of RFC3986
> > Uri-Authority conforms to "host [ : port ]" (section 3.2 of RFC3986,
> > excluding use of userinfo)
> > Uri-Path confirms to the path-noscheme (path-rootless?) rule in section
> 3.3
> > of RFC3986
> > Uri-Query conforms to the query rule in section 3.4 of RFC3986
> >
> > Delegation to existing definitions is the way to go.  This eliminates the
> > need for similar rules in section 5.3, which otherwise implicitly
> restrict
> > the Uri-Authority syntax.
> >
> > There had been talk of an option for a binary encoding of Uri-Authority;
> I
> > assume that would be a new, critical option, the presence of which would
> > complicate this reconstruction a little.
> >
> > Peter
> >
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> >
> >
>

--00163662e69bcd47c50493112683
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Oct 20, 2010 at 12:56 PM, Kerry Lynn <kerlyn2001@gmail=
.com> wrote:

Hi Peter,



In light of your clarifications, I wonder if we can discuss some of the

comments in your earlier email?
=A0
Certainly.=A0

> URI references... may have been a source of confusion within the

> working group, including leading to some mistaken assumptions

> about how URIs with multicast addresses might work.



First, we're agreed that we're really talking about URLs, right?
"As this URI is used purely as a locator, CoAP only supports Universal=


=A0Resource Locator features of [RFC3986] although throughout the

=A0document we refer to URI."

At the moment, =
yes.=A0 However, I can think of no technical justification for this restric=
tion.=A0 If an IP address and port for the owner of a resource identified b=
y a URN could be found elsewhere (e.g., hard-coding or LDAP or DNS-SD), and=
 CoAP added a way to pass that URN within the request message (a Uri-Name o=
ption), URNs would work too.


As a general rule, my understanding is that IETF, per text in RFC3305, =
prefers use of the term URI, because the cases where URL and URN must be di=
stinguished are so rare.=A0 In fact, I don't think CoAP is one of those=
 cases.=A0 CoAP does not mandate how the location of a resource (in the sen=
se of an
 IP address and port) is determined.=A0 Nor does it strictly require that=
=20
the path part be interpreted hierarchically.=A0 I think the text "As t=
his URI is used purely as a locator" should be removed.

<=
blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

It believe there was a typo in the coap draft, as you pointed out.

However, it seems that in the later descriptions relative URIs

were everywhere disallowed by language such as "CoAP does not

support "." or ".." in URIs" and "The leading=
 slash is assumed and

and MUST be omitted".



Jumping around a bit, you said:

> the scheme and any query and fragment parts do not contribute to

> this identification



I think from the perspective of a coap server this MIGHT be correct,

but I'm not positive. =A0The reason I'm agnostic is because I'm=
 not

sure yet how the coap-to-http mapping will work.



>From outside the server, for location purposes, I don't agree. =A0In th=
e

-bc draft, Peter van der Stok and I said that the scheme and authority

parts could be used by e.g. DNS-SD to locate instances of the coap

service. =A0IOW, you expect that a query for "http://foo.example.com"

would give a different result than "coap://foo.example.com" in terms

of returned port and other answers.

Yes.=A0 Actual=
ly, this relates to a question you raised on both CoAP WG telecons: whether=
 http://server/path denotes the same res=
ource as https://server/path.=A0 Everyb=
ody who spoke up, including me, said "no", because from a web-ser=
ver perspective the two reach completely different implementations.


I think from the REST perspective the answer is "yes".=A0 Tha=
t you can legitimately get different representations of the resource from t=
he different servers is because of metadata provided as a consequence of go=
ing through the different protocol, but RESTfully whatever you get really s=
hould be representations of the same resource.=A0 Perhaps one has more deta=
il than the other, but if they are truly unrelated, it is a poorly-designed=
 system.

=A0
I stand by my assertion that, in REST, the scheme is irrelevant to t=
he resource identification.=A0 If I have to, I'll go dig up the referen=
ce from Fielding that supports that position.

However, I don't t=
hink it matters, because what DNS-SD is providing is not the address of the=
 REST resource but the address to a server that can be used to manipulate t=
hat resource using a specific protocol.=A0 All is good.





Before returning to group resource locators, I'd like to vet an idea
related to multi-function devices. =A0I think there's been an implicit<=
br>
assumption that "functionality" (e.g. an object model) may be loc=
ated

at any interior node in a URI hierarchy, and may be optionally named

by a short URI. =A0This is the thrust of draft-ietf-core-link-format. =A0Bu=
t

modern HTTP servers also implement the concept of name-based

virtual hosts, in which multiple authorities can be mapped to the

same IP address. =A0Thus, http://foo.example.com and http://bar...

might be located at the same IP & port. =A0It seems to me that this

would be a natural way to express multi-function devices (as a 1:1

mapping of "device" to DNS host name) as well as lead to shorter<=
br>
URIs. =A0I think this might be especially useful when devising

coap-to-foo legacy gateways. =A0The implication is that the Uri-

Authority Option would be used with some regularity in this case.

Yes: this is exactly why I thought it so important to ensur=
e Uri-Authority was preserved end-to-end by CoAP-carried REST transactions.=




The idea of authorities mapping to muticast addresses was

introduced in -bc-01 and referenced in -groupcomm-00. =A0In the

latter, we say that a request directed to a group of nodes MUST

be directed to a /.well-known/core/... Uri-Path. =A0I was thinking

that a name-based approach would apply here, since the server

receiving such a request (and belonging to the IP group) could

be considered as a server for the group authority as well as for

any individual authorities it might serve.

Yes, the pr=
oblem being that all receiving hosts would believe they were the (single) s=
erver responsible for that resource.=A0 Separate issue, ignore it for now.<=
br>
=A0
Howe=
ver, it seems

the name-based approach might also create a problem for

group resources in the case of multiple vhosts per interface,

in that the /.well-known/core/... Uri-Path received in the request

must be resolved to an individual Uri-Authority at that interface

as well as a Uri-Path, and these would be returned in any

response. =A0How is this handled in the case where the same

absolute path is found in more than one virtual host?
=

In HTTP, I don't think you'd even notice.=A0 Each host has its =
own directory namespace.=A0 The authority (Host header) is not optional (th=
ough it can be empty), so only one directory structure would be examined fo=
r a match to the path part.=A0 It would be there, or it wouldn't.=A0 Th=
ere would never be an ambiguity.


Same thing in CoAP: if Uri-Authority is present, it's used to selec=
t which of the directory namespaces hosted via CoAP on that server and port=
 should be used to resolve the path part.=A0 If it's absent, there'=
s got to be exactly one default namespace that will be used.



I'd be very interested to hear other opinions about how group

resource naming might work.

In my glance over the =
rahman draft I saw some potential approaches; I hope to have comments on it=
 sometime tomorrow.
=A0




Regards, -K-






On Wed, Oct 20, 2010 at 12:19 PM, Peter Bigot <pab@peoplepowerco.com> wrote:

> Need to correct this; reconstructing the URI should be:

>

> =A0=A0 ( Uri-Scheme ":" )

> =A0=A0 ( "//" Uri-Authority ) only if Uri-Authority is prese=
nt

> =A0=A0 ( "/" Uri-Path )

> =A0=A0 ( "?"=A0 Uri-Query ) only if Uri-Query is present

>

> Note that this implicitly defines the syntax of strings valid for thes=
e

> options, to wit:

>

> Uri-Scheme conforms to the scheme rule in section 3.1 of RFC3986

> Uri-Authority conforms to "host [ : port ]" (section 3.2 of =
RFC3986,

> excluding use of userinfo)

> Uri-Path confirms to the path-noscheme (path-rootless?) rule in sectio=
n 3.3

> of RFC3986

> Uri-Query conforms to the query rule in section 3.4 of RFC3986

>

> Delegation to existing definitions is the way to go.=A0 This eliminate=
s the

> need for similar rules in section 5.3, which otherwise implicitly rest=
rict

> the Uri-Authority syntax.

>

> There had been talk of an option for a binary encoding of Uri-Authorit=
y; I

> assume that would be a new, critical option, the presence of which wou=
ld

> complicate this reconstruction a little.

>

> Peter

>

>


> _______________________________________________

> core mailing list

> core@ietf.org

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

>

>





--00163662e69bcd47c50493112683--

From cabo@tzi.org  Wed Oct 20 12:25:51 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FD83A680D for ; Wed, 20 Oct 2010 12:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.17
X-Spam-Level: 
X-Spam-Status: No, score=-106.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsTzecfRSFX9 for ; Wed, 20 Oct 2010 12:25:50 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 3836E3A67DF for ; Wed, 20 Oct 2010 12:25: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 o9KJRGVA001528; Wed, 20 Oct 2010 21:27:16 +0200 (CEST)
Received: from [192.168.217.101] (p5489CA48.dip.t-dialin.net [84.137.202.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9FC95871; Wed, 20 Oct 2010 21:27:15 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 20 Oct 2010 21:27:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 20 Oct 2010 19:25:51 -0000

Peter,

I think you are providing a lot of good input that will allow the new =
editor to develop editorial improvements of the document.

I do have a number of differences in philosophy, though, that lead me to =
different technical conclusions.

I'm going to address three points:
1) optionality of implementing block
2) resources that change during retrieval
3) random access
but not quite in this order.

First, block is not an option that is being designed into CoAP after the =
protocol has been out there for two years, so we maybe can use an =
approach to provide optionality that is less heavyweight than if we =
needed backwards-compatibility.

Sending an error code "too big" is always less preferable to sending =
back the first block.
If the client does have a preference for the block size, fine, it should =
have sent it in the request.
If it doesn't, not getting the data but having to rerequest it (hey, I =
really want it) is not making sense to me.
(Including the block option in every request, just in case, does not =
make sense in a constrained environment, either.)
If the client doesn't implement block but it somehow was configured to =
access a large resource, essentially something was misconfigured.
The presence of the block option in the response is as indicative of =
this misconfiguration as an error code would be.

ETag in responses is optional because there may be resources that don't =
ever change.
If I deploy a temp sensor, that may never change its /.well-known/core =
or a descriptive document referenced from that.
So why send an ETag?

The random-access issue is interesting.  To disallow random access, the =
server must have state.
So I think it is not meaningful to require the server to disallow access =
in other than sequential order.
But I think it would be a good change to indicate that clients should =
use sequential order.

If a resource is prone to change through its retrieval, block is not a =
very good mechanism to cope with that on its own.
But remember that we have REST available.
So a resource that is big and also changes a lot could redirect (by a =
link, or by a redirect mechanism we don't have yet) to a URI that =
provides a specific snapshot of it -- this would be a lot like the =
open(2) semantics of UNIX, where you get a file descriptor to a file =
that is still referring to the old one even if the file name link in the =
directory is replaced by a pointer to a new instance.
ETag is good enough to detect changes for rarely-changing resources =
where you don't want to have an open(2) style access.

Using the token to detect partial access to different versions of =
resources would require the server to keep (potentially unbounded) =
state, so I don't like that idea at all.

Block is using small integers to enumerate the slices of the resource =
representation for two reasons:
1) integers are small (at least for reasonably sized resource =
representations),
2) integers allow the server to be stateless, if it is able to provide =
indexed access into the binary form of the representation.
Robert Quattlebaum has this interesting usage example where the latter =
is not the case (1-wire enumeration), so he was proposing to be able to =
use non-numeric slice identifiers in a more/next protocol.
I can understand that, because it is a specific use case (and I would =
love to find a way to unify the advantages of block with his more/next =
protocol without increasing complexity).
I'd like to understand your use case, and in particular why you think =
TFTP's server side state identifiers (encoded in port numbers) are more =
appropriate for a REST protocol than the stateless block or more/next =
approach (i.e. to ping-pong the slice identifiers from server to client =
and back).

So my proposal would be to continue this discussion based on a specific =
usage example.

Gruesse, Carsten


From cabo@tzi.org  Wed Oct 20 12:59:50 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8AF3A67D9 for ; Wed, 20 Oct 2010 12:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.021
X-Spam-Level: 
X-Spam-Status: No, score=-105.021 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_HERE=2.3,  RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBe-nSmFoaNk for ; Wed, 20 Oct 2010 12:59:49 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A1EC53A67AB for ; Wed, 20 Oct 2010 12:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9KK1FXr012291; Wed, 20 Oct 2010 22:01:15 +0200 (CEST)
Received: from [192.168.217.101] (p5489CA48.dip.t-dialin.net [84.137.202.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8230D879; Wed, 20 Oct 2010 22:01:14 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 20 Oct 2010 22:01:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <39DC5A24-53E9-4548-A506-D347BA29E310@tzi.org>
References:    
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] Options: Uri-Query and Uri-Scheme
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 20 Oct 2010 19:59:50 -0000

A couple of random thoughts about this area:

I definitely agree that referring to the old ever so confusing "locator =
vs. name" discussion that is alluded to in section 1.1.3 of RFC 3986 =
does not really add value to the CoAP spec.  Let's talk about URIs only, =
and where we want to restrict them, about the specific restrictions we =
are making.

As with HTTP, we don't support the relative references "." and "..".
I think that is because we try to encode a URI, not a URI reference, =
i.e. section 5 of RFC3986 is performed at the client (if it needs to be =
performed at all), not at the server.

One discussion we have had is whether the authority should be sent when =
there isn't an expectation that the server is acting as a proxy.  The =
best choice may be different in HTTP because this is a constrained =
environment and authorities tend to be large, so there is more incentive =
to avoid them than there was in HTTP.

The Uri-Authority-Binary option proposed in section 3.2 of =
draft-bormann-coap-misc-06.txt mainly tries to make the case less =
heavyweight where the authority is already resolved to a transport =
address ([2001:...]:4711 is rather verbose).  Do we need that support?  =
I don't know.

We haven't defined yet how to translate the authority in a coap URI into =
the transport address used to contact the server.  There seems to be a =
common assumption between all current implementations that this goes =
through AAAA (and possibly A) records (and no SRV records) in the case =
of DNS names.  Virtual hosts only make sense if you have an indirection =
like DNS where several names can point to the same thing.

I completely agree that
	foo://he.re/it/is
is a different resource from
	bar://he.re/it/is
independent of whether foo/bar are http, https, or coap.

As with http and https, there *may* be an *intention* that resources =
that only differ in scheme may solve a similar problem (e.g., a http:// =
resource often just redirects to a related https:// resource and thus is =
completely different from that resource).

However, http://he.re:80/it/is may be completely different from =
http://he.re:81/it/is.  So which of these should =
coap://he.re:61616/it/is be similar to? coap://he.re:61617/it/is?
As a general idea, URIs are opaque identifiers; there is only very =
limited license a server gives to a client for deriving one URI from =
another one (e.g., by adding query parameters).

If we want to support something like coap://[ff02::1]/ (multicast =
authorities), we'll have to invent something -- so far REST doesn't have =
it.  The semantics may be moderately obvious for a PUT (but not for its =
response), and much less obvious for a GET.
A proxy translating a GET response from multicast back to unicast would =
have to combine all resource representations, probably indexed by =
something like a unicast URI somehow constructed from each source of a =
response (you want to know who sent the response and how to talk to that =
server).  Some kind of multipart/... media type, maybe.  Do we need to =
support that?  (I.e., what is the use case?)

Gruesse, Carsten


From pab@peoplepowerco.com  Wed Oct 20 13:45:23 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29DC3A68C2 for ; Wed, 20 Oct 2010 13:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Level: 
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.352,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YvxLX0EHRzQ for ; Wed, 20 Oct 2010 13:45:22 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9677B3A67A7 for ; Wed, 20 Oct 2010 13:45:21 -0700 (PDT)
Received: by gyc15 with SMTP id 15so2593410gyc.31 for ; Wed, 20 Oct 2010 13:46:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.24.15 with SMTP id b15mr1939115muj.39.1287607614331; Wed, 20 Oct 2010 13:46:54 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 13:46:54 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 20 Oct 2010 15:46:54 -0500
Message-ID: 
From: Peter Bigot 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=0016e65a0fbc765d24049312825d
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 20 Oct 2010 20:45:23 -0000

--0016e65a0fbc765d24049312825d
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 20, 2010 at 2:27 PM, Carsten Bormann  wrote:

> Peter,
>
> I think you are providing a lot of good input that will allow the new
> editor to develop editorial improvements of the document.
>
> I do have a number of differences in philosophy, though, that lead me to
> different technical conclusions.
>
> I'm going to address three points:
> 1) optionality of implementing block
> 2) resources that change during retrieval
> 3) random access
> but not quite in this order.
>
> First, block is not an option that is being designed into CoAP after the
> protocol has been out there for two years, so we maybe can use an approach
> to provide optionality that is less heavyweight than if we needed
> backwards-compatibility.
>
> Sending an error code "too big" is always less preferable to sending back
> the first block.
> If the client does have a preference for the block size, fine, it should
> have sent it in the request.
> If it doesn't, not getting the data but having to rerequest it (hey, I
> really want it) is not making sense to me.
> (Including the block option in every request, just in case, does not make
> sense in a constrained environment, either.)
> If the client doesn't implement block but it somehow was configured to
> access a large resource, essentially something was misconfigured.
> The presence of the block option in the response is as indicative of this
> misconfiguration as an error code would be.
>

See the referenced discussion from early September, which suggested that,
depending on network characteristics, pre-emptively sending a block response
when one was not requested could result in failures that the client cannot
diagnose and recover from, because it will never see the response.

On re-reading that thread myself, I see that because the default value of
the Block option is zero the server must send blocks that are 16-bytes long,
so it's pretty unlikely that the response will get dropped due to MTU
problems.  On the other hand, it's going to take a long time to get the data
that way, so my clients (on a network that supports 240-byte payloads) would
probably ignore that response and re-transmit the original request with an
explicit Block option specifying a larger block size.

The start of section 2.1 implies that the server is to switch to using Block
when the representation is "larger than can be comfortably[sic] transferred
in a single UDP datagram".  That size is 64kB, much larger than we
anticipate ever transferring, and certainly not an appropriate threshold.
What size should the server use as a cue that the representation is too
large?  Since the default Block option value has an encoded size of 16,
presumably a 20-byte representation technically should be converted to a
block transfer.  No?

So I don't see that you've saved anything by pre-emptively sending the first
16 bytes, instead of an error code warning the client that the resource
exceeds the server's estimation of the path MTU and it should be prepared
for that.  In the error response, you could even include an estimation of
the actual length, so a client with little memory wouldn't have to retrieve
a hundred pieces before finding out it couldn't accept the representation
anyway.

ETag in responses is optional because there may be resources that don't ever
> change.
>
If I deploy a temp sensor, that may never change its /.well-known/core or a
> descriptive document referenced from that.
> So why send an ETag?
>

So don't, for resources where the representation never changes.  The SHOULD
in that paragraph at the bottom of page 6 should still be changed to MUST,
since it refers to a GET of a resource for which the representation may
dynamically change.  Otherwise the client will unwittingly piece together an
invalid representation, and have no way of knowing it's done so.  Why would
we ever want to allow a server to enable this?

And again, what do we do if the representation changes and the client is
asking for a block that does not exist in the current representation because
it shrank?

The random-access issue is interesting.  To disallow random access, the
> server must have state.
>
So I think it is not meaningful to require the server to disallow access in
> other than sequential order.
> But I think it would be a good change to indicate that clients should use
> sequential order.
>

I didn't mean that the server would be obliged to diagnose non-decreasing
access; I meant that a client should not assume it can do so.  My point is
that the server may generate some resource representations incrementally and
destructively, and not be able to regenerate earlier chunks.  There should
be a way for the server to indicate this has happened.


> If a resource is prone to change through its retrieval, block is not a very
> good mechanism to cope with that on its own.
> But remember that we have REST available.
> So a resource that is big and also changes a lot could redirect (by a link,
> or by a redirect mechanism we don't have yet) to a URI that provides a
> specific snapshot of it -- this would be a lot like the open(2) semantics of
> UNIX, where you get a file descriptor to a file that is still referring to
> the old one even if the file name link in the directory is replaced by a
> pointer to a new instance.
> ETag is good enough to detect changes for rarely-changing resources where
> you don't want to have an open(2) style access.
>
> Using the token to detect partial access to different versions of resources
> would require the server to keep (potentially unbounded) state, so I don't
> like that idea at all.
>

That comment was in reference to a multi-part PUT/PUSH operation.  The
server's already keeping potentially-unbounded state.

Block is using small integers to enumerate the slices of the resource
> representation for two reasons:
> 1) integers are small (at least for reasonably sized resource
> representations),
> 2) integers allow the server to be stateless, if it is able to provide
> indexed access into the binary form of the representation.
> Robert Quattlebaum has this interesting usage example where the latter is
> not the case (1-wire enumeration), so he was proposing to be able to use
> non-numeric slice identifiers in a more/next protocol.
> I can understand that, because it is a specific use case (and I would love
> to find a way to unify the advantages of block with his more/next protocol
> without increasing complexity).
>

I would argue that more/next, as a meta-characteristic not encoded in the
resource identifier, is inherently non-RESTful.  It mandates server state be
associated with a client's view of a specific resource.  Block does not,
because each request tells the server the necessary state, which is how REST
should work in such a case.  (I still believe that, if treated as an
independent REST transaction, use of the block option is nothing more than
syntactic sugar for a URI where a query-part defines a block size and a
fragment identifier specifies the block.)

I'd like to understand your use case, and in particular why you think TFTP's
> server side state identifiers (encoded in port numbers) are more appropriate
> for a REST protocol than the stateless block or more/next approach (i.e. to
> ping-pong the slice identifiers from server to client and back).
>

What level of REST are we talking about?  It's a single REST transaction:
one tftp get. That at the network level it comprises multiple messages in
each direction and some server state is irrelevant.  A REST request via HTTP
usually comprises multiple IP packets and requires server-side TCP state.

If the goal is to have REST principles maintained in CoAP at the IP level in
all cases, I think that's unrealistic.  Block might work, but group
(multicast) operations don't, and the observe solution really isn't RESTful
either.  I don't see that this is a problem.  CoAP can be used in a RESTful
way, and can integrate with other REST architectures, which means it should
meet the requirements of the smart grid and similar driving applications.
Security, for example, is certainly going to involve per-client server
state, whether it's visible in CoAP or not.  That the charter for CoAP
presumed all its requirements could be met by a RESTful solution is, simply,
a mistake.  It could be done, but only by adding overhead that is not
appropriate for its target domain.

My main point is that (a) TFTP is an existing, proven solution to transfer
of data that cannot be accomplished in a single IP packet in cases where a
stream-oriented protocol is not available, and (b) attempting to define a
new solution to that problem is a mistake.  I would respond to a CoAP
request for a large representation by redirecting the client to a server
using a protocol designed for that purpose.

Peter


> So my proposal would be to continue this discussion based on a specific
> usage example.
>
> Gruesse, Carsten
>
>

--0016e65a0fbc765d24049312825d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Oct 20, 2010 at 2:27 PM, Carsten Bormann=
 <cabo@tzi.org>=
 wrote:

Peter,



I think you are providing a lot of good input that will allow the new edito=
r to develop editorial improvements of the document.



I do have a number of differences in philosophy, though, that lead me to di=
fferent technical conclusions.



I'm going to address three points:

1) optionality of implementing block

2) resources that change during retrieval

3) random access

but not quite in this order.



First, block is not an option that is being designed into CoAP after the pr=
otocol has been out there for two years, so we maybe can use an approach to=
 provide optionality that is less heavyweight than if we needed backwards-c=
ompatibility.




Sending an error code "too big" is always less preferable to send=
ing back the first block.

If the client does have a preference for the block size, fine, it should ha=
ve sent it in the request.

If it doesn't, not getting the data but having to rerequest it (hey, I =
really want it) is not making sense to me.

(Including the block option in every request, just in case, does not make s=
ense in a constrained environment, either.)

If the client doesn't implement block but it somehow was configured to =
access a large resource, essentially something was misconfigured.

The presence of the block option in the response is as indicative of this m=
isconfiguration as an error code would be.

See the=
 referenced discussion from early September, which suggested that, dependin=
g on network characteristics, pre-emptively sending a block response when o=
ne was not requested could result in failures that the client cannot diagno=
se and recover from, because it will never see the response.


On re-reading that thread myself, I see that because the default value =
of the Block option is zero the server must send blocks that are 16-bytes l=
ong, so it's pretty unlikely that the response will get dropped due to =
MTU problems.=A0 On the other hand, it's going to take a long time to g=
et the data that way, so my clients (on a network that supports 240-byte pa=
yloads) would probably ignore that response and re-transmit the original re=
quest with an explicit Block option specifying a larger block size.


The start of section 2.1 implies that the server is to switch to using=
=20
Block when the representation is "larger than can be comfortably[sic] =
transferred in a single UDP
 datagram".=A0 That size is 64kB, much larger than we anticipate ever=
=20
transferring, and certainly not an appropriate threshold.=A0 What size shou=
ld the server use as a cue that the=20
representation is too large?=A0 Since the default Block option value has=20
an encoded size of 16, presumably a 20-byte representation technically=20
should be converted to a block transfer.=A0 No?


So I don't see that you've saved anything by pre-emptively send=
ing the first 16 bytes, instead of an error code warning the client that th=
e resource exceeds the server's estimation of the path MTU and it shoul=
d be prepared for that.=A0 In the error response, you could even include an=
 estimation of the actual length, so a client with little memory wouldn'=
;t have to retrieve a hundred pieces before finding out it couldn't acc=
ept the representation anyway.


ETag in respo=
nses is optional because there may be resources that don't ever change.=





The random-access issue is interesting. =A0To disallow random access, the s=
erver must have state.


So I think it is not meaningful to require the server to disallow access in=
 other than sequential order.

But I think it would be a good change to indicate that clients should use s=
equential order.

I didn't mean that the server=
 would be obliged to diagnose non-decreasing access; I meant that a client =
should not assume it can do so.=A0 My point is that the server may generate=
 some resource representations incrementally and destructively, and not be =
able to regenerate earlier chunks.=A0 There should be a way for the server =
to indicate this has happened.

=A0


If a resource is prone to change through its retrieval, block is not a very=
 good mechanism to cope with that on its own.

But remember that we have REST available.

So a resource that is big and also changes a lot could redirect (by a link,=
 or by a redirect mechanism we don't have yet) to a URI that provides a=
 specific snapshot of it -- this would be a lot like the open(2) semantics =
of UNIX, where you get a file descriptor to a file that is still referring =
to the old one even if the file name link in the directory is replaced by a=
 pointer to a new instance.


ETag is good enough to detect changes for rarely-changing resources where y=
ou don't want to have an open(2) style access.



Using the token to detect partial access to different versions of resources=
 would require the server to keep (potentially unbounded) state, so I don&#=
39;t like that idea at all.

That comment was in re=
ference to a multi-part PUT/PUSH operation.=A0 The server's already kee=
ping potentially-unbounded state.



Block is using small integers to enumerate the slices of the resource repre=
sentation for two reasons:

1) integers are small (at least for reasonably sized resource representatio=
ns),

2) integers allow the server to be stateless, if it is able to provide inde=
xed access into the binary form of the representation.

Robert Quattlebaum has this interesting usage example where the latter is n=
ot the case (1-wire enumeration), so he was proposing to be able to use non=
-numeric slice identifiers in a more/next protocol.

I can understand that, because it is a specific use case (and I would love =
to find a way to unify the advantages of block with his more/next protocol =
without increasing complexity).

I would argue that=
 more/next, as a meta-characteristic not encoded in the resource identifier=
, is inherently non-RESTful.=A0 It mandates server state be associated with=
 a client's view of a specific resource.=A0 Block does not, because eac=
h request tells the server the necessary state, which is how REST should wo=
rk in such a case.=A0 (I still believe that, if treated as an independent R=
EST transaction, use of the block option is nothing more than syntactic sug=
ar for a URI where a query-part defines a block size and a fragment identif=
ier specifies the block.)



I'd like to understand your use case, and in particular why you think T=
FTP's server side state identifiers (encoded in port numbers) are more =
appropriate for a REST protocol than the stateless block or more/next appro=
ach (i.e. to ping-pong the slice identifiers from server to client and back=
).



What level of REST are we talking about?=A0 It's =
a single REST transaction: one tftp get. That at the network level it compr=
ises multiple messages in each direction and some server state is irrelevan=
t.=A0 A REST request via HTTP usually comprises multiple IP packets and req=
uires server-side TCP state.


If the goal is to have REST principles maintained in CoAP at the IP lev=
el in all cases, I think that's unrealistic.=A0 Block might work, but g=
roup (multicast) operations don't, and the observe solution really isn&=
#39;t RESTful either.=A0 I don't see that this is a problem.=A0 CoAP ca=
n be used in a RESTful way, and can integrate with other REST architectures=
, which means it should meet the requirements of the smart grid and similar=
 driving applications.=A0 Security, for example, is certainly going to invo=
lve per-client server state, whether it's visible in CoAP or not.=A0 Th=
at the charter for CoAP presumed all its requirements could be met by a RES=
Tful solution is, simply, a mistake.=A0 It could be done, but only by addin=
g overhead that is not appropriate for its target domain.


My main point is that (a) TFTP is an existing, proven solution to trans=
fer of data that cannot be accomplished in a single IP packet in cases wher=
e a stream-oriented protocol is not available, and (b) attempting to define=
 a new solution to that problem is a mistake.=A0 I would respond to a CoAP =
request for a large representation by redirecting the client to a server us=
ing a protocol designed for that purpose.


Peter
=A0


So my proposal would be to continue this discussion based on a specific usa=
ge example.



Gruesse, Carsten






--0016e65a0fbc765d24049312825d--

From pab@peoplepowerco.com  Wed Oct 20 13:47:54 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56053A6933 for ; Wed, 20 Oct 2010 13:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.479
X-Spam-Level: 
X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_HERE=2.3, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K71IJIuYZFR for ; Wed, 20 Oct 2010 13:47:52 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 295A33A67A7 for ; Wed, 20 Oct 2010 13:47:52 -0700 (PDT)
Received: by gyc15 with SMTP id 15so2595330gyc.31 for ; Wed, 20 Oct 2010 13:49:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.182.4 with SMTP id j4mr199259mup.133.1287607764245; Wed, 20 Oct 2010 13:49:24 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Wed, 20 Oct 2010 13:49:24 -0700 (PDT)
In-Reply-To: <39DC5A24-53E9-4548-A506-D347BA29E310@tzi.org>
References:     <39DC5A24-53E9-4548-A506-D347BA29E310@tzi.org>
Date: Wed, 20 Oct 2010 15:49:24 -0500
Message-ID: 
From: Peter Bigot 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=00163641711965dd350493128b00
Cc: core 
Subject: Re: [core] Options: Uri-Query and Uri-Scheme
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 20 Oct 2010 20:47:54 -0000

--00163641711965dd350493128b00
Content-Type: text/plain; charset=ISO-8859-1

Re whether scheme affects resource identification, see the first bullet
under:

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

The rest of his post helps explain why I believe it is a mistake to believe
that CoAP, which is designed for M2M communications between constrained
devices, should be expected to be 100% compatible with REST, which was
designed for distributed management of hypermedia on the Internet.

Peter

On Wed, Oct 20, 2010 at 3:01 PM, Carsten Bormann  wrote:

> A couple of random thoughts about this area:
>
> I definitely agree that referring to the old ever so confusing "locator vs.
> name" discussion that is alluded to in section 1.1.3 of RFC 3986 does not
> really add value to the CoAP spec.  Let's talk about URIs only, and where we
> want to restrict them, about the specific restrictions we are making.
>
> As with HTTP, we don't support the relative references "." and "..".
> I think that is because we try to encode a URI, not a URI reference, i.e.
> section 5 of RFC3986 is performed at the client (if it needs to be performed
> at all), not at the server.
>
> One discussion we have had is whether the authority should be sent when
> there isn't an expectation that the server is acting as a proxy.  The best
> choice may be different in HTTP because this is a constrained environment
> and authorities tend to be large, so there is more incentive to avoid them
> than there was in HTTP.
>
> The Uri-Authority-Binary option proposed in section 3.2 of
> draft-bormann-coap-misc-06.txt mainly tries to make the case less
> heavyweight where the authority is already resolved to a transport address
> ([2001:...]:4711 is rather verbose).  Do we need that support?  I don't
> know.
>
> We haven't defined yet how to translate the authority in a coap URI into
> the transport address used to contact the server.  There seems to be a
> common assumption between all current implementations that this goes through
> AAAA (and possibly A) records (and no SRV records) in the case of DNS names.
>  Virtual hosts only make sense if you have an indirection like DNS where
> several names can point to the same thing.
>
> I completely agree that
>        foo://he.re/it/is
> is a different resource from
>        bar://he.re/it/is
> independent of whether foo/bar are http, https, or coap.
>
> As with http and https, there *may* be an *intention* that resources that
> only differ in scheme may solve a similar problem (e.g., a http://resource often just redirects to a related https://resource and thus is completely different from that resource).
>
> However, http://he.re:80/it/is may be completely different from
> http://he.re:81/it/is.  So which of these should coap://he.re:61616/it/isbe similar to? coap://
> he.re:61617/it/is?
> As a general idea, URIs are opaque identifiers; there is only very limited
> license a server gives to a client for deriving one URI from another one
> (e.g., by adding query parameters).
>
> If we want to support something like coap://[ff02::1]/ (multicast
> authorities), we'll have to invent something -- so far REST doesn't have it.
>  The semantics may be moderately obvious for a PUT (but not for its
> response), and much less obvious for a GET.
> A proxy translating a GET response from multicast back to unicast would
> have to combine all resource representations, probably indexed by something
> like a unicast URI somehow constructed from each source of a response (you
> want to know who sent the response and how to talk to that server).  Some
> kind of multipart/... media type, maybe.  Do we need to support that?
>  (I.e., what is the use case?)
>
> Gruesse, Carsten
>
>

--00163641711965dd350493128b00
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Re whether scheme affects resource identification, see the first bullet und=
er:

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hype=
rtext-driven


The rest of his post helps explain why I believe it is a mistake to bel=
ieve that CoAP, which is designed for M2M communications between constraine=
d devices, should be expected to be 100% compatible with REST, which was de=
signed for distributed management of hypermedia on the Internet.


Peter

On Wed, Oct 20, 2010 at 3:01 PM=
, Carsten Bormann <cab=
o@tzi.org> wrote:

A couple of random thoughts about this area:



I definitely agree that referring to the old ever so confusing "locato=
r vs. name" discussion that is alluded to in section 1.1.3 of RFC 3986=
 does not really add value to the CoAP spec. =A0Let's talk about URIs o=
nly, and where we want to restrict them, about the specific restrictions we=
 are making.




As with HTTP, we don't support the relative references "." an=
d "..".

I think that is because we try to encode a URI, not a URI reference, i.e. s=
ection 5 of RFC3986 is performed at the client (if it needs to be performed=
 at all), not at the server.



One discussion we have had is whether the authority should be sent when the=
re isn't an expectation that the server is acting as a proxy. =A0The be=
st choice may be different in HTTP because this is a constrained environmen=
t and authorities tend to be large, so there is more incentive to avoid the=
m than there was in HTTP.




The Uri-Authority-Binary option proposed in section 3.2 of draft-bormann-co=
ap-misc-06.txt mainly tries to make the case less heavyweight where the aut=
hority is already resolved to a transport address ([2001:...]:4711 is rathe=
r verbose). =A0Do we need that support? =A0I don't know.




We haven't defined yet how to translate the authority in a coap URI int=
o the transport address used to contact the server. =A0There seems to be a =
common assumption between all current implementations that this goes throug=
h AAAA (and possibly A) records (and no SRV records) in the case of DNS nam=
es. =A0Virtual hosts only make sense if you have an indirection like DNS wh=
ere several names can point to the same thing.




I completely agree that

 =A0 =A0 =A0 =A0foo://he.r=
e/it/is

is a different resource from

 =A0 =A0 =A0 =A0bar://he.r=
e/it/is

independent of whether foo/bar are http, https, or coap.



As with http and https, there *may* be an *intention* that resources that o=
nly differ in scheme may solve a similar problem (e.g., a http:// resource =
often just redirects to a related https:// resource and thus is completely =
different from that resource).




However, http://he.re:8=
0/it/is may be completely different from http://he.re:81/it/is. =A0So which of these shoul=
d coap://he.re:61616=
/it/is be similar to? coap://he.re:61617/it/is?


As a general idea, URIs are opaque identifiers; there is only very limited =
license a server gives to a client for deriving one URI from another one (e=
.g., by adding query parameters).



If we want to support something like coap://[ff02::1]/ (multicast authoriti=
es), we'll have to invent something -- so far REST doesn't have it.=
 =A0The semantics may be moderately obvious for a PUT (but not for its resp=
onse), and much less obvious for a GET.


A proxy translating a GET response from multicast back to unicast would hav=
e to combine all resource representations, probably indexed by something li=
ke a unicast URI somehow constructed from each source of a response (you wa=
nt to know who sent the response and how to talk to that server). =A0Some k=
ind of multipart/... media type, maybe. =A0Do we need to support that? =A0(=
I.e., what is the use case?)




Gruesse, Carsten







--00163641711965dd350493128b00--

From darco@deepdarc.com  Wed Oct 20 22:50:28 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CC53A6840 for ; Wed, 20 Oct 2010 22:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level: 
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNQOj9kYsGgu for ; Wed, 20 Oct 2010 22:50:25 -0700 (PDT)
Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id D26BF3A6973 for ; Wed, 20 Oct 2010 22:50:19 -0700 (PDT)
Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:41787 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P8o42-0007o6-GO; Thu, 21 Oct 2010 01:51:46 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Quattlebaum 
In-Reply-To: 
Date: Wed, 20 Oct 2010 22:51:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: Peter Bigot 
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - spider.nocdirect.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - deepdarc.com
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 05:50:28 -0000

Hello Peter!

On Oct 20, 2010, at 1:46 PM, Peter Bigot wrote:

>> 2) integers allow the server to be stateless, if it is able to =
provide indexed access into the binary form of the representation.
>> Robert Quattlebaum has this interesting usage example where the =
latter is not the case (1-wire enumeration), so he was proposing to be =
able to use non-numeric slice identifiers in a more/next protocol.
>> I can understand that, because it is a specific use case (and I would =
love to find a way to unify the advantages of block with his more/next =
protocol without increasing complexity).
>=20
> I would argue that more/next, as a meta-characteristic not encoded in =
the resource identifier, is inherently non-RESTful.  It mandates server =
state be associated with a client's view of a specific resource. =20
> Block does not, because each request tells the server the necessary =
state, which is how REST should work in such a case.

Carsten and I have been discussing and developing my suggestion =
off-list. My proposal has changed pretty significantly since I first =
proposed it. I wanted to get more of Carsten's input before posting an =
updated proposal to the list. In light of this thread, I'll go ahead and =
clean up my proposal and post it to the list for wider discussion =
sometime tomorrow.

In the mean time, I'll just add that the whole point of the Next option =
is to allow the server to serve requests with large content responses as =
efficiently as possible for the server implementation. Sometimes you =
need more than just a block index to generate the requested content =
efficiently, but in cases where it can be done efficiently there is =
nothing stopping a server implementation from simply using the Next =
option to hold the same information the Block option would. The only =
difference in such a case between the Next option and the Block option =
would be that the client doesn't mutate the value of the Next option =
like would with the Block option.

More details later.

__________________
Robert Quattlebaum
Jabber: darco@deepdarc.com
eMail:  darco@deepdarc.com
www:    http://www.deepdarc.com/




From prvs=49100427F0=guido.moritz@uni-rostock.de  Thu Oct 21 01:54:00 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033703A6A10 for ; Thu, 21 Oct 2010 01:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQtWH4gUVN8y for ; Thu, 21 Oct 2010 01:53:56 -0700 (PDT)
Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id B65973A6A0B for ; Thu, 21 Oct 2010 01:53:55 -0700 (PDT)
From: Guido Moritz 
To: 'core' 
Date: Thu, 21 Oct 2010 10:55:28 +0200
Message-ID: <002001cb70fd$b5b3b000$211b1000$@uni-rostock.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Actw+4tCotyuCA1RQFiTOQm8cBPONw==
Content-Language: de
Subject: [core] CoRE Link Format 3.1
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 08:54:00 -0000

Dear Zach,

I am just working through the draft-ietf-core-link-format-00 and wondering
in section 3.1. about the sentence:
"Implementations not supporting filtering MUST simply  ignore the query
string and return the whole resource."

The I-D does not state if the mechanism is used only via unicast. In
multicast scenarios where I send out a multicast query to find all
temperature sensors (i.e. temperature resource) a client might use the query
filtering feature. But the client was not aware that in the network the
discovery message was dropped, massive of other nodes are online that not
support filtering. And suddenly instead of 10 temperature resources the
clients gets responses from 10.000 other resources as well.

Maybe it would be reasonable to change 3.1 that only if the request was send
unicast, the implementation may ignore the query string and return the whole
resource. 

BRGDs,
Guido Moritz



From prvs=291002B0BB=guido.moritz@uni-rostock.de  Thu Oct 21 02:35:37 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCB33A6821 for ; Thu, 21 Oct 2010 02:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhfqZ+jSj50P for ; Thu, 21 Oct 2010 02:35:36 -0700 (PDT)
Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id DF1A73A680E for ; Thu, 21 Oct 2010 02:35:35 -0700 (PDT)
From: Guido Moritz 
To: 'core' 
Date: Thu, 21 Oct 2010 11:37:14 +0200
Message-ID: <002d01cb7103$8b500970$a1f01c50$@uni-rostock.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: ActxAYv//kj4VNzVS3S+5CR6S9OSyw==
Content-Language: de
Subject: [core] CoAP observe
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 09:35:37 -0000

Dear Klaus,
Dear Zach,

sifting through the draft-ietf-core-observe-00 I am missing some negotiation
mechanisms for the notification endpoint. Is it assumed that the endpoint
for the notification is the origin address (IP+Port) of the subscription (I
think not realistic in all scenarios)? Moreover there are also scenarios
possible where notifications might be send out via multicast to avoid
multiple notifications to different subscribers on the same resource. 

The negotiation mechanism might be similar to that one for
content-type/encoding in HTTP. So a client says what it would like to have
(the notification endpoint), but a server is capable of denying the request
due to the address and/or proposes a different one (and/or includes the
multicast address the notifications might be to).

I guess this should be added in the "Open Issues" section?!

PS: Some time ago I also posted a hint to WS-Eventing about differentiation
of roles: http://www.ietf.org/mail-archive/web/core/current/msg00469.html .
This mechanism might be much too complex for CoAP/CoRE, but provide a
starting point. 

BRGDs,
Guido




From koo@comnets.uni-bremen.de  Thu Oct 21 02:44:41 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EDC3A6403 for ; Thu, 21 Oct 2010 02:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.492
X-Spam-Level: 
X-Spam-Status: No, score=-4.492 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_40=-0.185, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfNpKBDCS5cZ for ; Thu, 21 Oct 2010 02:44:34 -0700 (PDT)
Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id D22BD3A6834 for ; Thu, 21 Oct 2010 02:44:33 -0700 (PDT)
Received: from koojanalaptop (unknown [134.102.155.208]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id 5054CD406C7 for ; Thu, 21 Oct 2010 11:46:08 +0200 (CEST)
From: "Koojana Kuladinithi" 
To: "'core'" 
Date: Thu, 21 Oct 2010 11:46:08 +0200
Message-ID: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01CB7115.8D563480"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActxBMUsCQaDJGebRPmG/GfV3TivQw==
Content-Language: en-us
Subject: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 09:44:41 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01CB7115.8D563480
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

I have started looking at draft-ietf-core-coap-02. When reading section
2.1.2 on Asynchronous response, the following was not clear to me.

 

In case of a loss of an asynchronous response (CON tid=783 ..message in
figure 3) from the server, who will take an action on retransmission?

1.  Does the server send the CON message with data again after some xx time?

2.  Does the client send GET message again after some xx time?     

 

For asynchronous transmission as explained in figure 3, can't we do as
follows?

1.  The client sends CON GET to the server without knowing whether syn/asyn
txs.

2.  The server sends ACK as in Figure 3, but with a Processing-Delay option
if the response gets delayed. (the experiments we did here show that to get
temperature/humidity results from an embedded device, it takes about ~300
ms). This Processing-Delay can be decided by the server based on the type of
URI. This lets the client to compute the waiting time to get the
asynchronous response. Example, Waiting-Time = (Processing-Delay +  RTT + xx
delay). 

 

If the client does not receive any delayed response from the server within
this Waiting-Time, the client should send again CON GET message. I believe
this would be a simple way to solve the above mentioned issues.

 

 

Kind regards

 

Koojana

 

Koojana Kuladinithi

University of Bremen, FB1 - IKOM/TZI

Otto-Hahn Allee NW1, 28359, Bremen, Germany 

Tel. +49 421 218 62382, Fax. +49 421 218 3601,

www: http://www.comnets.uni-bremen.de/~koo

 


------=_NextPart_000_0015_01CB7115.8D563480
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hello,



 



I have started looking at draft-ietf-core-coap-02.
When reading section 2.1.2 on Asynchronous response, the following was =
not
clear to me.



 



In case of a loss of an asynchronous response =
(CON tid=3D783 ..message =
in figure
3) from the server, who will take an action on =
retransmission?



1.  =
Does the server =
send the CON
message with data again after some xx time?



2.  =
Does the client =
send GET
message again after some xx time?     



 



For asynchronous transmission as explained in =
figure
3, can’t we do as follows?



1.  =
The client sends =
CON GET to
the server without knowing whether syn/asyn txs.



2.  =
The server sends =
ACK as in
Figure 3, but with a Processing-Delay option if the response gets =
delayed. (the
experiments we did here show that to get temperature/humidity results =
from an
embedded device, it takes about ~300 ms). This Processing-Delay can be =
decided
by the server based on the type of URI. This lets the client to compute =
the
waiting time to get the asynchronous response. Example, Waiting-Time =3D =
(Processing-Delay
+  RTT + xx delay). 



 



If the client does not receive any delayed =
response
from the server within this Waiting-Time, the client should send again =
CON GET
message. I believe this would be a simple way to solve the above =
mentioned issues.



 



 



Kind
regards



 



Koojana



 



Koojana
Kuladinithi



University
of Bremen, FB1 - IKOM/TZI



Otto-Hahn
Allee NW1, 28359, Bremen, Germany 



Tel.
+49 421 218 62382, Fax. +49 421 218 3601,



www:
http://www.comnets.uni-bre=
men.de/~koo



 









------=_NextPart_000_0015_01CB7115.8D563480--


From sakane@tanu.org  Thu Oct 21 03:37:19 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17683A680D for ; Thu, 21 Oct 2010 03:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.073
X-Spam-Level: 
X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-2.350, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe+qCbnpQsUh for ; Thu, 21 Oct 2010 03:37:12 -0700 (PDT)
Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by core3.amsl.com (Postfix) with ESMTP id 8E2D23A6452 for ; Thu, 21 Oct 2010 03:37:11 -0700 (PDT)
Received: from dhcp-64-104-shinjuku-wlan-5-195.cisco.com (dhcp-64-104-shinjuku-wlan-5-195.cisco.com [64.104.5.195]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id DE3FC16B10 for ; Thu, 21 Oct 2010 19:38:44 +0900 (JST)
Message-ID: <4CC0194D.4040909@tanu.org>
Date: Thu, 21 Oct 2010 19:43:25 +0900
From: Shoichi Sakane 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: core@ietf.org
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Subject: [core] COAP dissector for wireshark
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 10:37:19 -0000

Hi, just for your interest.

The wireshark from svn 34601 or later has a dissector of COAP.
It supports
 * draft-ietf-core-coap-02.txt
 * draft-ietf-core-block-00.txt
 * draft-ietf-core-observe-00.txt

Any feedback would be appreciated.
I will join the interop at the meeting if I can.

Best,

Shoichi Sakane

From cabo@tzi.org  Thu Oct 21 05:11:54 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0436B3A6900 for ; Thu, 21 Oct 2010 05:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.213
X-Spam-Level: 
X-Spam-Status: No, score=-106.213 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6amWyuU7fbpv for ; Thu, 21 Oct 2010 05:11:52 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id CEC6F3A689F for ; Thu, 21 Oct 2010 05:11: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 o9LCDJf8027606; Thu, 21 Oct 2010 14:13:20 +0200 (CEST)
Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DBEBBB05; Thu, 21 Oct 2010 14:13:19 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 21 Oct 2010 10:49:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 12:11:54 -0000

On Oct 20, 2010, at 22:46, Peter Bigot wrote:

> because the default value of the Block option is zero the server must =
send blocks that are 16-bytes long

Section 2.1 says:

   The default value of the Block Option is zero, indicating
   that the current block is the first (block number 0) and only (M bit
   not set) block of the transfer; however, there is no explicit size
   implied by this default value.

The server is thus free to choose a size if a client does not indicate a =
preference.

(This may be a strange default, but there is never a need to provide an =
unspecified size except when the block number is also zero, so this is a =
good way not to spend bits for something that will be sent a lot.)

Gruesse, Carsten


From pab@peoplepowerco.com  Thu Oct 21 05:36:45 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7143F3A691A for ; Thu, 21 Oct 2010 05:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.617
X-Spam-Level: 
X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=0.359,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wam0rGquzp5 for ; Thu, 21 Oct 2010 05:36:43 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 62A153A68B9 for ; Thu, 21 Oct 2010 05:36:42 -0700 (PDT)
Received: by fxm17 with SMTP id 17so3942930fxm.31 for ; Thu, 21 Oct 2010 05:38:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.108.8 with SMTP id k8mr1102391mum.53.1287664691373; Thu, 21 Oct 2010 05:38:11 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 21 Oct 2010 05:38:11 -0700 (PDT)
In-Reply-To: 
References:    
Date: Thu, 21 Oct 2010 07:38:11 -0500
Message-ID: 
From: Peter Bigot 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=001636416d778550e904931fcc44
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 12:36:45 -0000

--001636416d778550e904931fcc44
Content-Type: text/plain; charset=ISO-8859-1

Good enough.  Then my objection that the protocol does not adequately
protect against network MTU characteristics stands.

I also raise a new objection that special-casing the interpretation of a
zero value when it is the default is unnecessarily confusing.  A better
solution would be to say there is no default value for the block option, but
the behavior when the representation is too large, the server supports the
Block option, but no Block option is present in the request should be (me)
reject the request or redirect to a different protocol (carsten) select a
block size and proceed with the first block.

BTW: "Core" CoAP would benefit from having available the error code
indicating that the server knows the representation is too big to be safely
carried in a packet addressed to the client requesting it.  Parameters to
that error response might include an estimate of the representation size,
and an alternative URI for retrieval by a different protocol.

Peter

On Thu, Oct 21, 2010 at 3:49 AM, Carsten Bormann  wrote:

> On Oct 20, 2010, at 22:46, Peter Bigot wrote:
>
> > because the default value of the Block option is zero the server must
> send blocks that are 16-bytes long
>
> Section 2.1 says:
>
>   The default value of the Block Option is zero, indicating
>   that the current block is the first (block number 0) and only (M bit
>   not set) block of the transfer; however, there is no explicit size
>   implied by this default value.
>
> The server is thus free to choose a size if a client does not indicate a
> preference.
>
> (This may be a strange default, but there is never a need to provide an
> unspecified size except when the block number is also zero, so this is a
> good way not to spend bits for something that will be sent a lot.)
>
> Gruesse, Carsten
>
>

--001636416d778550e904931fcc44
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Good enough.=A0 Then my objection that the protocol does not adequately pro=
tect against network MTU characteristics stands.

I also raise a new =
objection that special-casing the interpretation of a zero value when it is=
 the default is unnecessarily confusing.=A0 A better solution would be to s=
ay there is no default value for the block option, but the behavior when th=
e representation is too large, the server supports the Block option, but no=
 Block option is present in the request should be (me) reject the request o=
r redirect to a different protocol (carsten) select a block size and procee=
d with the first block.


BTW: "Core" CoAP would benefit from having available the erro=
r code indicating that the server knows the representation is too big to be=
 safely carried in a packet addressed to the client requesting it.=A0 Param=
eters to that error response might include an estimate of the representatio=
n size, and an alternative URI for retrieval by a different protocol.


Peter

On Thu, Oct 21, 2010 at 3:49 AM=
, Carsten Bormann <cab=
o@tzi.org> wrote:


On Oct 20, 2010, at 22:46, Peter Bigot wrote:



> because the default value of the Block option is zero the server must =
send blocks that are 16-bytes long




Section 2.1 says:



 =A0 The default value of the Block Option is zero, indicating

 =A0 that the current block is the first (block number 0) and only (M bit
 =A0 not set) block of the transfer; however, there is no explicit size

 =A0 implied by this default value.



The server is thus free to choose a size if a client does not indicate a pr=
eference.



(This may be a strange default, but there is never a need to provide an uns=
pecified size except when the block number is also zero, so this is a good =
way not to spend bits for something that will be sent a lot.)



Gruesse, Carsten







--001636416d778550e904931fcc44--

From cabo@tzi.org  Thu Oct 21 05:48:53 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EC53A67A6 for ; Thu, 21 Oct 2010 05:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.235
X-Spam-Level: 
X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SZppNMFdPmj for ; Thu, 21 Oct 2010 05:48:52 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 509593A67AE for ; Thu, 21 Oct 2010 05:48:52 -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 o9LCoJCP014898; Thu, 21 Oct 2010 14:50:19 +0200 (CEST)
Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 97704B3C; Thu, 21 Oct 2010 14:50:19 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de>
Date: Thu, 21 Oct 2010 14:50:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <336496E8-2D34-41A4-91E9-14F70E7D0634@tzi.org>
References: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de>
To: "Koojana Kuladinithi" 
X-Mailer: Apple Mail (2.1081)
Cc: 'core' 
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 12:48:53 -0000

> In case of a loss of an asynchronous response (CON tid=3D783 ..message =
in figure 3) from the server, who will take an action on retransmission?
> 1.  Does the server send the CON message with data again after some xx =
time?

Yes.

> 2.  Does the client send GET message again after some xx time?    =20
> =20
> For asynchronous transmission as explained in figure 3, can=92t we do =
as follows?
> 1.  The client sends CON GET to the server without knowing whether =
syn/asyn txs.
> 2.  The server sends ACK as in Figure 3, but with a Processing-Delay =
option if the response gets delayed.
> (the experiments we did here show that to get temperature/humidity =
results from an embedded device, it takes about ~300 ms).

Interesting data point.  300 ms should be comfortably within the 500 ms =
default retransmission timeout, though, unless the wireless media is =
congested.

> This Processing-Delay can be decided by the server based on the type =
of URI. This lets the client to compute the waiting time to get the =
asynchronous response. Example, Waiting-Time =3D (Processing-Delay +  =
RTT + xx delay).
> =20
> If the client does not receive any delayed response from the server =
within this Waiting-Time, the client should send again CON GET message. =
I believe this would be a simple way to solve the above mentioned =
issues.

This might work where the server has a deterministic processing delay.
A proxy may not be so lucky.  The result would be that we have a third =
kind of message exchange (one for immediate responses, one for =
deterministic responses, and one for non-deterministic responses).

Of course, at the REST level, a "try again in nnn ms" code might solve a =
similar problem.
Is the use case with a deterministic processing delay that does not fit =
in the default retransmission delay likely enough to warrant adding it?

Gruesse, Carsten


From cabo@tzi.org  Thu Oct 21 06:19:14 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E292C3A672F for ; Thu, 21 Oct 2010 06:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.236
X-Spam-Level: 
X-Spam-Status: No, score=-106.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap8nGIC-4uDU for ; Thu, 21 Oct 2010 06:19:10 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 198B93A67E6 for ; Thu, 21 Oct 2010 06:19: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 o9LDKbXl004554; Thu, 21 Oct 2010 15:20:37 +0200 (CEST)
Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 21D6BB6E; Thu, 21 Oct 2010 15:20:37 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 21 Oct 2010 15:20:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:     
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 13:19:15 -0000

On Oct 21, 2010, at 14:38, Peter Bigot wrote:

> network MTU characteristics

I must admit that I have mainly focused on IPv6 here, which has a =
reasonable-to-large (for constrained networks) minimum MTU.  For IPv4, =
the situation may be a bit more complicated, if you actually want to set =
DF.
I'm not sure we want to do a lot to make things more efficient for IPv4 =
with unusual (< 1280) MTUs.
Maybe sending IPv4 CoAP responses with DF set is just not that great an =
idea.
The remaining question is whether we want to do anything special to =
accommodate IPv4's small minimum MRU (576 bytes).
I still like the number 1152 as a guideline for a maximum CoAP message =
size in IPv6.
(Block can encode a 2048-byte slice size because there are three bits to =
indicate the size and less than 16 bytes does not make a lot of sense =
with all the header overhead either; 16*2^7=3D2048.)

(And I like the proposal to rephrase what the absence of the block =
option means -- the current language is probably pretty confusing =
indeed.)

Gruesse, Carsten


From pab@peoplepowerco.com  Thu Oct 21 06:28:51 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D353A69E8 for ; Thu, 21 Oct 2010 06:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Level: 
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.353,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWoxzWxoMPvy for ; Thu, 21 Oct 2010 06:28:49 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2364A3A69CA for ; Thu, 21 Oct 2010 06:28:48 -0700 (PDT)
Received: by fxm8 with SMTP id 8so36094fxm.31 for ; Thu, 21 Oct 2010 06:30:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.239.14 with SMTP id q14mr1185609mur.15.1287667778646; Thu, 21 Oct 2010 06:29:38 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 21 Oct 2010 06:29:37 -0700 (PDT)
In-Reply-To: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de>
References: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de>
Date: Thu, 21 Oct 2010 08:29:37 -0500
Message-ID: 
From: Peter Bigot 
To: Koojana Kuladinithi 
Content-Type: multipart/alternative; boundary=0016e6d7df7d89f4080493208424
Cc: core 
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 13:28:51 -0000

--0016e6d7df7d89f4080493208424
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

As Carsten notes, the defined behavior is your option 1 (server retransmits
con response message).

I agree there is some uncertainty resulting from the asynchronous response
not having a time limit, and I too would rather have it resolved so I don't
have to hold onto request state in the client for an unbounded period, in
hopes that eventually my answer will come.

I read what you're suggesting as an elective header option, to be placed in
the ACK that indicates an asynchronous response, providing an upper bound o=
n
how long the client should expect to wait for a response.

Further, we should give it a reasonable default.   31 seconds may elapse
between first CON transmission and last CON retransmission given the defaul=
t
settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which point the server
will give up.  A default of 60 allows about 29 seconds for the server to
create the response representation before risking the client giving up too
soon.

Then a client that has not received the response after that time plus a
fudge term for network delays can assume the message is lost and recover in
whatever way is appropriate (e.g., retransmit the GET or give up).

I like this.

BTW: We did all realize that servers supporting asynchronous responses
should keep hold of the TID for the original request in the client response
record, so that if the server ACK gets lost and the client retransmits it
isn't interpreted as a new request, right?  I don't think I've seen that
called out explicitly anywhere.

Peter

On Thu, Oct 21, 2010 at 4:46 AM, Koojana Kuladinithi <
koo@comnets.uni-bremen.de> wrote:

>  Hello,
>
>
>
> I have started looking at draft-ietf-core-coap-02. When reading section
> 2.1.2 on Asynchronous response, the following was not clear to me.
>
>
>
> In case of a loss of an asynchronous response (CON tid=3D783 ..message in
> figure 3) from the server, who will take an action on retransmission?
>
> 1.  Does the server send the CON message with data again after some xx
> time?
>
> 2.  Does the client send GET message again after some xx time?
>
>
>
> For asynchronous transmission as explained in figure 3, can=92t we do as
> follows?
>
> 1.  The client sends CON GET to the server without knowing whether
> syn/asyn txs.
>
> 2.  The server sends ACK as in Figure 3, but with a Processing-Delay
> option if the response gets delayed. (the experiments we did here show th=
at
> to get temperature/humidity results from an embedded device, it takes abo=
ut
> ~300 ms). This Processing-Delay can be decided by the server based on the
> type of URI. This lets the client to compute the waiting time to get the
> asynchronous response. Example, Waiting-Time =3D (Processing-Delay +  RTT=
 + xx
> delay).
>
>
>
> If the client does not receive any delayed response from the server withi=
n
> this Waiting-Time, the client should send again CON GET message. I believ=
e
> this would be a simple way to solve the above mentioned issues.
>
>
>
>
>
> Kind regards
>
>
>
> Koojana
>
>
>
> Koojana Kuladinithi
>
> University of Bremen, FB1 - IKOM/TZI
>
> Otto-Hahn Allee NW1, 28359, Bremen, Germany
>
> Tel. +49 421 218 62382, Fax. +49 421 218 3601,
>
> www: http://www.comnets.uni-bremen.de/~koo
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>

--0016e6d7df7d89f4080493208424
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

As Carsten notes, the defined behavior is your option 1 (server retransmits=
 con response message).

I agree there is some uncertainty resulting =
from the asynchronous response not having a time limit, and I too would rat=
her have it resolved so I don't have to hold onto request state in the =
client for an unbounded period, in hopes that eventually my answer will com=
e.


I read what you're suggesting as an elective header option, to be p=
laced in the ACK that indicates an asynchronous response, providing an uppe=
r bound on how long the client should expect to wait for a response.


Further, we should give it a reasonable default. =A0 31 seconds may ela=
pse between first CON transmission and last CON retransmission given the de=
fault settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which point the s=
erver will give up.=A0 A default of 60 allows about 29 seconds for the serv=
er to create the response representation before risking the client giving u=
p too soon.


Then a client that has not received the response after that time plus a=
 fudge term for network delays can assume the message is lost and recover i=
n whatever way is appropriate (e.g., retransmit the GET or give up).


I like this.

BTW: We did all realize that servers supporting asy=
nchronous responses should keep hold of the TID for the original request in=
 the client response record, so that if the server ACK gets lost and the cl=
ient retransmits it isn't interpreted as a new request, right?=A0 I don=
't think I've seen that called out explicitly anywhere.


Peter

On Thu, Oct 21, 2010 at 4:46 AM=
, Koojana Kuladinithi <koo@comnets.uni-bremen.de> wrote:

















Hello,



=A0



I have started looking at=
 draft-ietf-core-coap-02.
When reading section 2.1.2 on Asynchronous response, the following was not
clear to me.



=A0



In case of a loss of an a=
synchronous response (CON tid=3D783 ..message in figure
3) from the server, who will take an action on retransmission?



1.=A0 Does the server send the CON
message with data again after some xx time?



2.=A0 Does the client send GET
message again after some xx time? =A0=A0=A0=A0



=A0



For asynchronous transmis=
sion as explained in figure
3, can=92t we do as follows?



1.=A0 The client sends CON GET to
the server without knowing whether syn/asyn txs.



2.=A0 The server sends ACK as in
Figure 3, but with a Processing-Delay option if the response gets delayed. =
(the
experiments we did here show that to get temperature/humidity results from =
an
embedded device, it takes about ~300 ms). This Processing-Delay can be deci=
ded
by the server based on the type of URI. This lets the client to compute the
waiting time to get the asynchronous response. Example, Waiting-Time =3D (P=
rocessing-Delay
+ =A0RTT + xx delay). 



=
=A0<=
/span>



If the client does not re=
ceive any delayed response
from the server within this Waiting-Time, the client should send again CON =
GET
message. I believe this would be a simple way to solve the above mentioned =
issues.



=A0



=A0



Kind
regards



=A0



Koojana



=A0



Koojana
Kuladinithi



University
of Bremen, FB1 - IKOM/TZI



Otto-Hahn
Allee NW1, 28359, Bremen, Germany 



Tel.
+49 421 218 62382, Fax. +49 421 218 3601,



www:
http:=
//www.comnets.uni-bremen.de/~koo



=A0










_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--0016e6d7df7d89f4080493208424--

From cabo@tzi.org  Thu Oct 21 07:01:29 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5923A68B6 for ; Thu, 21 Oct 2010 07:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.236
X-Spam-Level: 
X-Spam-Status: No, score=-106.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQYmV7TQ5+r5 for ; Thu, 21 Oct 2010 07:01:28 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 5D4E73A68AD for ; Thu, 21 Oct 2010 07:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9LE2tbq027879; Thu, 21 Oct 2010 16:02:55 +0200 (CEST)
Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B1949BB2; Thu, 21 Oct 2010 16:02:55 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 21 Oct 2010 16:02:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BA0BE16-3F7F-4D04-8614-1A2C270BCA0D@tzi.org>
References: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de> 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 14:01:29 -0000

On Oct 21, 2010, at 15:29, Peter Bigot wrote:

> BTW: We did all realize that servers supporting asynchronous responses =
should keep hold of the TID for the original request in the client =
response record, so that if the server ACK gets lost and the client =
retransmits it isn't interpreted as a new request, right?  I don't think =
I've seen that called out explicitly anywhere.

I think keeping the TID for being able to do duplicate detection is a =
general rule for anything that is not both
-- idempotent (and cheap)
and
-- stateless.

Since the server needs to create (temporary) state to be able to send =
the async response later, it makes sense to include the TID in that =
state to combine any duplicates.

I think this is indeed an implementation consideration, but it may be =
worth a mention.
(More generally speaking, because many readers will be used to think in =
a strict transport/application layering, there are quite a number of =
things worth mentioning here.)

Gruesse, Carsten


From pab@peoplepowerco.com  Thu Oct 21 07:09:18 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A5A3A69F4 for ; Thu, 21 Oct 2010 07:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.628
X-Spam-Level: 
X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.348,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3O2Shj5zKmG for ; Thu, 21 Oct 2010 07:09:17 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 3BED33A68AD for ; Thu, 21 Oct 2010 07:09:17 -0700 (PDT)
Received: by gyc15 with SMTP id 15so3108262gyc.31 for ; Thu, 21 Oct 2010 07:10:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.49.6 with SMTP id b6mr1196252muk.118.1287670229762; Thu, 21 Oct 2010 07:10:29 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 21 Oct 2010 07:09:49 -0700 (PDT)
In-Reply-To: 
References:      
Date: Thu, 21 Oct 2010 09:09:49 -0500
Message-ID: 
From: Peter Bigot 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=0016364d1e07a34386049321168c
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 14:09:18 -0000

--0016364d1e07a34386049321168c
Content-Type: text/plain; charset=ISO-8859-1

Nothing requires reference to IPv4.

Assume a pure IPv6 network, with devices A and B on an 802.3 wired segment
configured for jumbo frames that supports an 8192-byte MTU, and device C on
an 802.15.4 network that patches together support for IPv6's required
1280-byte MTU by doing link-layer reassembly of 127-byte frames (something
we really would rather avoid, but what the heck, IPv6 requires it).

A 1600-byte resource representation can be retrieved from A by B using CoAP
in a single IP datagram.  Device C cannot retrieve this resource without
using the block extension or an alternative protocol.

As I read draft-ietf-core-block section 2, the intent would be that C should
retrieve the data with blocks that fit within the link MTU (127 bytes).  C's
guess at the appropriate block size is more likely to be useful than A's,
which is why I'd prefer to always have the client propose the
characteristics of a multi-part block transaction.  The server can always
select a smaller value if it knows something the client doesn't.

Peter

On Thu, Oct 21, 2010 at 8:20 AM, Carsten Bormann  wrote:

> On Oct 21, 2010, at 14:38, Peter Bigot wrote:
>
> > network MTU characteristics
>
> I must admit that I have mainly focused on IPv6 here, which has a
> reasonable-to-large (for constrained networks) minimum MTU.  For IPv4, the
> situation may be a bit more complicated, if you actually want to set DF.
> I'm not sure we want to do a lot to make things more efficient for IPv4
> with unusual (< 1280) MTUs.
> Maybe sending IPv4 CoAP responses with DF set is just not that great an
> idea.
> The remaining question is whether we want to do anything special to
> accommodate IPv4's small minimum MRU (576 bytes).
> I still like the number 1152 as a guideline for a maximum CoAP message size
> in IPv6.
> (Block can encode a 2048-byte slice size because there are three bits to
> indicate the size and less than 16 bytes does not make a lot of sense with
> all the header overhead either; 16*2^7=2048.)
>
> (And I like the proposal to rephrase what the absence of the block option
> means -- the current language is probably pretty confusing indeed.)
>
> Gruesse, Carsten
>
>

--0016364d1e07a34386049321168c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Nothing requires reference to IPv4.

Assume a pure IPv6 network, with=
 devices A and B on an 802.3 wired segment configured for jumbo frames that=
 supports an 8192-byte MTU, and device C on an 802.15.4 network that patche=
s together support for IPv6's required 1280-byte MTU by doing link-laye=
r reassembly of 127-byte frames (something we really would rather avoid, bu=
t what the heck, IPv6 requires it).


A 1600-byte resource representation can be retrieved from A by B using =
CoAP in a single IP datagram.=A0 Device C cannot retrieve this resource wit=
hout using the block extension or an alternative protocol.

As I read=
 draft-ietf-core-block section 2, the intent would be that C should retriev=
e the data with blocks that fit within the link MTU (127 bytes).=A0 C's=
 guess at the appropriate block size is more likely to be useful than A'=
;s, which is why I'd prefer to always have the client propose the chara=
cteristics of a multi-part block transaction.=A0 The server can always sele=
ct a smaller value if it knows something the client doesn't.


Peter

On Thu, Oct 21, 2010 at 8:20 AM=
, Carsten Bormann <cab=
o@tzi.org> wrote:

On Oct 21, 2010, at 14:38, Peter Bigot wrote:



> network MTU characteristics



I must admit that I have mainly focused on IPv6 here, which has a reasonabl=
e-to-large (for constrained networks) minimum MTU. =A0For IPv4, the situati=
on may be a bit more complicated, if you actually want to set DF.

I'm not sure we want to do a lot to make things more efficient for IPv4=
 with unusual (< 1280) MTUs.

Maybe sending IPv4 CoAP responses with DF set is just not that great an ide=
a.

The remaining question is whether we want to do anything special to accommo=
date IPv4's small minimum MRU (576 bytes).

I still like the number 1152 as a guideline for a maximum CoAP message size=
 in IPv6.

(Block can encode a 2048-byte slice size because there are three bits to in=
dicate the size and less than 16 bytes does not make a lot of sense with al=
l the header overhead either; 16*2^7=3D2048.)



(And I like the proposal to rephrase what the absence of the block option m=
eans -- the current language is probably pretty confusing indeed.)



Gruesse, Carsten







--0016364d1e07a34386049321168c--

From pab@peoplepowerco.com  Thu Oct 21 07:18:42 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4D03A6A22 for ; Thu, 21 Oct 2010 07:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.633
X-Spam-Level: 
X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.343,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhS7Ig4FcfB6 for ; Thu, 21 Oct 2010 07:18:41 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 371D03A6A21 for ; Thu, 21 Oct 2010 07:18:41 -0700 (PDT)
Received: by gxk26 with SMTP id 26so55045gxk.31 for ; Thu, 21 Oct 2010 07:20:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.227.3 with SMTP id e3mr1362271mur.89.1287670207232; Thu, 21 Oct 2010 07:10:07 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 21 Oct 2010 07:09:49 -0700 (PDT)
In-Reply-To: 
References:      
Date: Thu, 21 Oct 2010 09:09:49 -0500
Message-ID: 
From: Peter Bigot 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=001636b431024a3b9a0493211513
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 14:18:42 -0000

--001636b431024a3b9a0493211513
Content-Type: text/plain; charset=ISO-8859-1

Nothing requires reference to IPv4.

Assume a pure IPv6 network, with devices A and B on an 802.3 wired segment
configured for jumbo frames that supports an 8192-byte MTU, and device C on
an 802.15.4 network that patches together support for IPv6's required
1280-byte MTU by doing link-layer reassembly of 127-byte frames (something
we really would rather avoid, but what the heck, IPv6 requires it).

A 1600-byte resource representation can be retrieved from A by B using CoAP
in a single IP datagram.  Device C cannot retrieve this resource without
using the block extension or an alternative protocol.

As I read draft-ietf-core-block section 2, the intent would be that C should
retrieve the data with blocks that fit within the link MTU (127 bytes).  C's
guess at the appropriate block size is more likely to be useful than A's,
which is why I'd prefer to always have the client propose the
characteristics of a multi-part block transaction.  The server can always
select a smaller value if it knows something the client doesn't.

Peter

On Thu, Oct 21, 2010 at 8:20 AM, Carsten Bormann  wrote:

> On Oct 21, 2010, at 14:38, Peter Bigot wrote:
>
> > network MTU characteristics
>
> I must admit that I have mainly focused on IPv6 here, which has a
> reasonable-to-large (for constrained networks) minimum MTU.  For IPv4, the
> situation may be a bit more complicated, if you actually want to set DF.
> I'm not sure we want to do a lot to make things more efficient for IPv4
> with unusual (< 1280) MTUs.
> Maybe sending IPv4 CoAP responses with DF set is just not that great an
> idea.
> The remaining question is whether we want to do anything special to
> accommodate IPv4's small minimum MRU (576 bytes).
> I still like the number 1152 as a guideline for a maximum CoAP message size
> in IPv6.
> (Block can encode a 2048-byte slice size because there are three bits to
> indicate the size and less than 16 bytes does not make a lot of sense with
> all the header overhead either; 16*2^7=2048.)
>
> (And I like the proposal to rephrase what the absence of the block option
> means -- the current language is probably pretty confusing indeed.)
>
> Gruesse, Carsten
>
>

--001636b431024a3b9a0493211513
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Nothing requires reference to IPv4.

Assume a pure IPv6 network, with=
 devices A and B on an 802.3 wired segment configured for jumbo frames that=
 supports an 8192-byte MTU, and device C on an 802.15.4 network that patche=
s together support for IPv6's required 1280-byte MTU by doing link-laye=
r reassembly of 127-byte frames (something we really would rather avoid, bu=
t what the heck, IPv6 requires it).


A 1600-byte resource representation can be retrieved from A by B using =
CoAP in a single IP datagram.=A0 Device C cannot retrieve this resource wit=
hout using the block extension or an alternative protocol.

As I read=
 draft-ietf-core-block section 2, the intent would be that C should retriev=
e the data with blocks that fit within the link MTU (127 bytes).=A0 C's=
 guess at the appropriate block size is more likely to be useful than A'=
;s, which is why I'd prefer to always have the client propose the chara=
cteristics of a multi-part block transaction.=A0 The server can always sele=
ct a smaller value if it knows something the client doesn't.


Peter

On Thu, Oct 21, 2010 at 8:20 AM=
, Carsten Bormann <cab=
o@tzi.org> wrote:

On Oct 21, 2010, at 14:38, Peter Bigot wrote:



> network MTU characteristics



I must admit that I have mainly focused on IPv6 here, which has a reasonabl=
e-to-large (for constrained networks) minimum MTU. =A0For IPv4, the situati=
on may be a bit more complicated, if you actually want to set DF.

I'm not sure we want to do a lot to make things more efficient for IPv4=
 with unusual (< 1280) MTUs.

Maybe sending IPv4 CoAP responses with DF set is just not that great an ide=
a.

The remaining question is whether we want to do anything special to accommo=
date IPv4's small minimum MRU (576 bytes).

I still like the number 1152 as a guideline for a maximum CoAP message size=
 in IPv6.

(Block can encode a 2048-byte slice size because there are three bits to in=
dicate the size and less than 16 bytes does not make a lot of sense with al=
l the header overhead either; 16*2^7=3D2048.)



(And I like the proposal to rephrase what the absence of the block option m=
eans -- the current language is probably pretty confusing indeed.)



Gruesse, Carsten







--001636b431024a3b9a0493211513--

From cabo@tzi.org  Thu Oct 21 08:08:46 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FF63A69DA for ; Thu, 21 Oct 2010 08:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.237
X-Spam-Level: 
X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sKxJUUBTwgG for ; Thu, 21 Oct 2010 08:08:45 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 393143A6899 for ; Thu, 21 Oct 2010 08:08:43 -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 o9LFACor026961; Thu, 21 Oct 2010 17:10:12 +0200 (CEST)
Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C8B93C1E; Thu, 21 Oct 2010 17:10:12 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 21 Oct 2010 17:10:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <78B46C8B-1DE9-49F3-9ED1-3CC482200814@tzi.org>
References:       
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 15:08:46 -0000

I don't think CoAP messages should ever be larger than the IPv6 minimum =
MTU.
CoAP does not have a Path MTU discovery mechanism and probably shouldn't =
grow one.
I'm also assuming that all CoAP implementations do implement the IPv6 =
minimum MTU (at least nominally -- if a node never deals in information =
of that size, you won't find out).
So I think there is no interaction with *correctness* here -- the packet =
size discussion is all about *efficiency*.

One thing we should be discussing here is whether there should be a way =
for the endpoints to influence the slice size used for multi-slice =
transfers, and how common its usage will be.  The design of block-00 =
provides such a way, but assumes that clients most often don't want to =
influence the size -- that's why the initial block option is optional.

If we really think we should be sending a preferred response block size =
with most requests, we probably should find three bits in the base =
header where we can efficiently represent this information instead of =
sending it as another option with every request.

The granularity of the expression of slice size preference is mostly =
orthogonal to the rigidness of the actual slice sizes -- as Robert has =
pointed out, there are some applications where semantic fragmentation is =
more useful than slicing the representation up by number of bytes.  But =
maybe there is an important application where the slice size should be =
exactly 73 bytes; we would need to know about this application to =
accommodate it in the design.

Gruesse, Carsten


From mjohn.info@googlemail.com  Thu Oct 21 07:12:25 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60853A6A0F for ; Thu, 21 Oct 2010 07:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJnSjWUsM2hN for ; Thu, 21 Oct 2010 07:12:24 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DEF6A3A68AD for ; Thu, 21 Oct 2010 07:12:23 -0700 (PDT)
Received: by yxk30 with SMTP id 30so2694147yxk.31 for ; Thu, 21 Oct 2010 07:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YTN59uS4TOK+WXf33RQPWiIKO54VFUFIB5h7Vi+mQ6Q=; b=bz5xy12XLOVL2QPDHuHAHyyqstEzG5vuchNlrLL2HDu1bSHeyxdo2qqa64jU4aWQN4 G7h7cepjVXpesdF6fxg4TlaBjf4FUb01He10apk2LT1JefcE+KX+G+l12fdM+JNSc/zb MqdaEmiEYgvoVgT4aQzsSfmmc3Kx3xF/B9M9Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ku/CxLVEnmvKHeOvXtoLNLPBO+V/SWdAHFH3E9QEaesSRxfP9Lt6HuvKm1ULPziwve l0Xn/VhRSDuDsuvqvk81SoeuCBli3Wl2QsgIAqKQFTO6NPZCurMA2gECpB7RN5dUreT5 hm3+G4+LlvJkLY62NcKlLiiOP41A+T8zWDaSs=
MIME-Version: 1.0
Received: by 10.150.201.18 with SMTP id y18mr3685339ybf.329.1287670438951; Thu, 21 Oct 2010 07:13:58 -0700 (PDT)
Received: by 10.236.103.45 with HTTP; Thu, 21 Oct 2010 07:13:58 -0700 (PDT)
In-Reply-To: <4CC0194D.4040909@tanu.org>
References: <4CC0194D.4040909@tanu.org>
Date: Thu, 21 Oct 2010 16:13:58 +0200
Message-ID: 
From: Michael John 
To: Shoichi Sakane 
Content-Type: multipart/alternative; boundary=000e0cd519d219fb8c04932123c7
X-Mailman-Approved-At: Thu, 21 Oct 2010 08:10:12 -0700
Cc: core@ietf.org
Subject: Re: [core] COAP dissector for wireshark
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 14:12:25 -0000

--000e0cd519d219fb8c04932123c7
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Great! Could you also provide pcap files to play with?
Many thanks.

Best regards
Michael

2010/10/21 Shoichi Sakane 

> Hi, just for your interest.
>
> The wireshark from svn 34601 or later has a dissector of COAP.
> It supports
>  * draft-ietf-core-coap-02.txt
>  * draft-ietf-core-block-00.txt
>  * draft-ietf-core-observe-00.txt
>
> Any feedback would be appreciated.
> I will join the interop at the meeting if I can.
>
> Best,
>
> Shoichi Sakane
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--000e0cd519d219fb8c04932123c7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Great! Could you also provide pcap files to play with?
Many t=
hanks.

Best regards
Michael
2010/10/21 Shoichi Sakane <=
;sakane@tanu.org>


Hi, just for your=
 interest.



The wireshark from svn 34601 or later has a dissector of COAP.

It supports

=A0* draft-ietf-core-coap-02.txt

=A0* draft-ietf-core-block-00.txt

=A0* draft-ietf-core-observe-00.txt



Any feedback would be appreciated.

I will join the interop at the meeting if I can.



Best,



Shoichi Sakane

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--000e0cd519d219fb8c04932123c7--

From cabo@tzi.org  Thu Oct 21 08:17:42 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB0D3A6A5D; Thu, 21 Oct 2010 08:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.237
X-Spam-Level: 
X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SXfd3zhoAPA; Thu, 21 Oct 2010 08:17:40 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id C1B133A6A61; Thu, 21 Oct 2010 08:17: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 o9LFJ7xp000918; Thu, 21 Oct 2010 17:19:07 +0200 (CEST)
Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CE438C34; Thu, 21 Oct 2010 17:19:06 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 21 Oct 2010 17:19:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <22B2AAF1-2F9D-4BEB-8551-92DEAA661513@tzi.org>
References: <4CC0194D.4040909@tanu.org> 
To: Michael John 
X-Mailer: Apple Mail (2.1081)
Cc: "6lowpan@ietf.org 6lowpan" <6lowpan@ietf.org>, core 
Subject: Re: [core] COAP dissector for wireshark
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 15:17:42 -0000

On Oct 21, 2010, at 16:13, Michael John wrote:

> Hi,
>=20
> Great! Could you also provide pcap files to play with?

I have started to informally collect pcap files for 6lowpan and RPL in =
the 6lowpan repository, i.e.:

http://svn.tools.ietf.org/svn/wg/6lowpan/packets

This still needs work as these files have not been vetted -- we need to =
find out whether they actually are correct (and what version of the spec =
they are corresponding to).  For now, I'll just add as much information =
to the README file as I can get.

If you have pcap files plus some metadata, send them to me (or just add =
them to the svn and update the README).

Gruesse, Carsten


From pab@peoplepowerco.com  Thu Oct 21 08:49:32 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7C43A6A16 for ; Thu, 21 Oct 2010 08:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.638
X-Spam-Level: 
X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.338,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTKa+P58aoKV for ; Thu, 21 Oct 2010 08:49:31 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D160B3A680E for ; Thu, 21 Oct 2010 08:49:12 -0700 (PDT)
Received: by vws12 with SMTP id 12so2852636vws.31 for ; Thu, 21 Oct 2010 08:50:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.213.11 with SMTP id p11mr1641892muq.98.1287676045659; Thu, 21 Oct 2010 08:47:25 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 21 Oct 2010 08:47:25 -0700 (PDT)
In-Reply-To: <78B46C8B-1DE9-49F3-9ED1-3CC482200814@tzi.org>
References:        <78B46C8B-1DE9-49F3-9ED1-3CC482200814@tzi.org>
Date: Thu, 21 Oct 2010 10:47:25 -0500
Message-ID: 
From: Peter Bigot 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=0016364c44064ab2e5049322716e
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 15:49:33 -0000

--0016364c44064ab2e5049322716e
Content-Type: text/plain; charset=ISO-8859-1

CoAP is an IP protocol.  Not an IPv6 protocol.  It can assume the basics of
what's available in IP, generically.  Of course it shouldn't grow a PMTUD
mechanism; that's an optional part of IP, and some nodes may be able to
leverage it.

I don't believe it's acceptable for CoAP to impose IPv6-related assumptions
on the entire network path between nodes that communicate over CoAP.
Consequently, I believe CoAP must be robust in the presence of foreseeable
network issues like occasional restricted links along the route.  The block
option as currently defined does not meet this criterion.

I've said this before: I believe very few resources will require block
transfers.  There's no need to include information related to block in most
requests.  All I ask is, when a server determines that the representation is
too large to send to a client, that it tell the client this so the client
can determine how it wants to deal with the situation.  Pre-emptively
assuming that the client has implemented the block option and that the
server could determine the best block size to use to send to the client is
not just potentially inefficient.  The wrong decision (made without PMTUD)
means the client may never find out why it didn't get an answer to its
request.  In my world, given how easy it is to fix this at the protocol
level, that's correctness.

BTW: The payload length of a CoAP transaction message is fundamentally
determined by the datagram length.  I propose we change the concept of
"block" from being a fixed size to being a maximum size.  We've already
discussed situations that justify requiring clients to request the blocks in
order.  If individual elements are less than a full block size, and are
possibly different sizes, so what?  The REST resource representation is the
value resulting from concatenating the blocks in sequential order.  Robert
and others can use the block protocol as-is, as long as the block size
selected is at least the size of the largest record in the sequence.

Peter

On Thu, Oct 21, 2010 at 10:10 AM, Carsten Bormann  wrote:

> I don't think CoAP messages should ever be larger than the IPv6 minimum
> MTU.
> CoAP does not have a Path MTU discovery mechanism and probably shouldn't
> grow one.
> I'm also assuming that all CoAP implementations do implement the IPv6
> minimum MTU (at least nominally -- if a node never deals in information of
> that size, you won't find out).
> So I think there is no interaction with *correctness* here -- the packet
> size discussion is all about *efficiency*.
>
> One thing we should be discussing here is whether there should be a way for
> the endpoints to influence the slice size used for multi-slice transfers,
> and how common its usage will be.  The design of block-00 provides such a
> way, but assumes that clients most often don't want to influence the size --
> that's why the initial block option is optional.
>
> If we really think we should be sending a preferred response block size
> with most requests, we probably should find three bits in the base header
> where we can efficiently represent this information instead of sending it as
> another option with every request.
>
> The granularity of the expression of slice size preference is mostly
> orthogonal to the rigidness of the actual slice sizes -- as Robert has
> pointed out, there are some applications where semantic fragmentation is
> more useful than slicing the representation up by number of bytes.  But
> maybe there is an important application where the slice size should be
> exactly 73 bytes; we would need to know about this application to
> accommodate it in the design.
>
> Gruesse, Carsten
>
>

--0016364c44064ab2e5049322716e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

CoAP is an IP protocol.=A0 Not an IPv6 protocol.=A0 It can assume the basic=
s of what's available in IP, generically.=A0 Of course it shouldn't=
 grow a PMTUD mechanism; that's an optional part of IP, and some nodes =
may be able to leverage it.


I don't believe it's acceptable for CoAP to impose IPv6-related=
 assumptions on the entire network path between nodes that communicate over=
 CoAP.=A0 Consequently, I believe CoAP must be robust in the presence of fo=
reseeable network issues like occasional restricted links along the route.=
=A0 The block option as currently defined does not meet this criterion.


I've said this before: I believe very few resources will require bl=
ock transfers.=A0 There's no need to include information related to blo=
ck in most requests.=A0 All I ask is, when a server determines that the rep=
resentation is too large to send to a client, that it tell the client this =
so the client can determine how it wants to deal with the situation.=A0 Pre=
-emptively assuming that the client has implemented the block option and th=
at the server could determine the best block size to use to send to the cli=
ent is not just potentially inefficient.=A0 The wrong decision (made withou=
t PMTUD) means the client may never find out why it didn't get an answe=
r to its request.=A0 In my world, given how easy it is to fix this at the p=
rotocol level, that's correctness.


BTW: The payload length of a CoAP transaction message is fundamentally =
determined by the datagram length.=A0 I propose we change the concept of &q=
uot;block" from being a fixed size to being a maximum size.=A0 We'=
ve already discussed situations that justify requiring clients to request t=
he blocks in order.=A0 If individual elements are less than a full block si=
ze, and are possibly different sizes, so what?=A0 The REST resource represe=
ntation is the value resulting from concatenating the blocks in sequential =
order.=A0 Robert and others can use the block protocol as-is, as long as th=
e block size selected is at least the size of the largest record in the seq=
uence.


Peter

On Thu, Oct 21, 2010 at 10:10 A=
M, Carsten Bormann <ca=
bo@tzi.org> wrote:

I don't think CoAP messages should ever be larger than the IPv6 minimum=
 MTU.

CoAP does not have a Path MTU discovery mechanism and probably shouldn'=
t grow one.

I'm also assuming that all CoAP implementations do implement the IPv6 m=
inimum MTU (at least nominally -- if a node never deals in information of t=
hat size, you won't find out).

So I think there is no interaction with *correctness* here -- the packet si=
ze discussion is all about *efficiency*.



One thing we should be discussing here is whether there should be a way for=
 the endpoints to influence the slice size used for multi-slice transfers, =
and how common its usage will be. =A0The design of block-00 provides such a=
 way, but assumes that clients most often don't want to influence the s=
ize -- that's why the initial block option is optional.




If we really think we should be sending a preferred response block size wit=
h most requests, we probably should find three bits in the base header wher=
e we can efficiently represent this information instead of sending it as an=
other option with every request.




The granularity of the expression of slice size preference is mostly orthog=
onal to the rigidness of the actual slice sizes -- as Robert has pointed ou=
t, there are some applications where semantic fragmentation is more useful =
than slicing the representation up by number of bytes. =A0But maybe there i=
s an important application where the slice size should be exactly 73 bytes;=
 we would need to know about this application to accommodate it in the desi=
gn.




Gruesse, Carsten







--0016364c44064ab2e5049322716e--

From Akbar.Rahman@InterDigital.com  Thu Oct 21 09:17:15 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79DA3A6A28 for ; Thu, 21 Oct 2010 09:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.983
X-Spam-Level: 
X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.615,  BAYES_00=-2.599, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjbjzbnUb0UY for ; Thu, 21 Oct 2010 09:17:13 -0700 (PDT)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 3AE083A6A24 for ; Thu, 21 Oct 2010 09:17:13 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 21 Oct 2010 12:18:46 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 21 Oct 2010 12:18:46 -0400
Message-ID: 
In-Reply-To: <73224E51-B5F2-4134-B9C8-7D99F34C98CC@sensinode.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Plugfest in Beijing
Thread-Index: ActvlLN7QOEfMT0OQ76bKdDvgfvydwBpmNiQ
References: <73224E51-B5F2-4134-B9C8-7D99F34C98CC@sensinode.com>
From: "Rahman, Akbar" 
To: "Zach Shelby" , 
X-OriginalArrivalTime: 21 Oct 2010 16:18:46.0125 (UTC) FILETIME=[A2F649D0:01CB713B]
Cc: core 
Subject: Re: [core] Plugfest in Beijing
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 16:17:15 -0000

Hi Zach/Carsten,


I'm able to access Carsten's server, however I am not able to access
Szymon's SENSEI Java server (coap://sensei-dev1.grid.pub.ro:61618).  I
am able to successfully ping it, however I'm not able to reach the 61618
UDP port.  The server is returning an ICMP "port is not reachable"
message. =20

Just wondering if the server is indeed up and running.


Sincerely,

Akbar


-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
Zach Shelby
Sent: Tuesday, October 19, 2010 9:51 AM
To: core
Subject: [core] Plugfest in Beijing

Hi,

I updated the CoRE Wiki about the upcoming plugfest in Beijing.=20

http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest

The format will be similar to last time, we will have an all-day event
on Sunday (time and room TBD) and then a shorter follow-up sometime
during the week in the terminal room. The goal is to test all of the
working group documents. This time we should plan some testing groups or
stages for testers of certain features, with well-defined test setups.
Like last time you will also be able to participate via IRC remotely.

The "CoAP test servers already on-line" part of the Wiki should list
servers that are available already for testing before and during the
event. Carsten's little CoAP server is up and running, and we will have
the SENSEI server, gateway and resource directory up again later this
week. If you have a CoAP server running on the Internet, please edit the
Wiki and add the URL (or drop me an e-mail and I'll do it).=20

Some notes about the specifications to be tested:

- We plan on testing draft-ietf-core-coap-03, which will be submitted by
next Monday. The main changes will be the addition of the Token Option,
which many have already implemented, along with some new error codes.=20
- The CoRE Link Format is very close to that of coap-02, however there
are quotes around more fields and the URL is now ./well-known/core.
Please update accordingly.
- The Block Option (draft-ietf-core-block-00) and Subscription Option
(draft-ietf-core-observe-00) are the same as were tested in the last
interop by a few people. Now it would be great to test those more widely
along with the Token Option considerations.=20

Of course we are open to testing experimental features and ideas from
individual drafts. How about CoAP over DTLS?

Welcome!
Zach

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


From zach@sensinode.com  Thu Oct 21 09:50:18 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B581E3A6A3C for ; Thu, 21 Oct 2010 09:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.513
X-Spam-Level: 
X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x05aatwCMPfw for ; Thu, 21 Oct 2010 09:50:15 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 40DE43A6A3B for ; Thu, 21 Oct 2010 09:50:11 -0700 (PDT)
Received: from [192.168.1.3] (line-8458.dyn.kponet.fi [85.29.79.106]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9LGpgcp023916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Oct 2010 19:51:43 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-17-135058903; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Thu, 21 Oct 2010 19:51:44 +0300
Message-Id: 
References: <73224E51-B5F2-4134-B9C8-7D99F34C98CC@sensinode.com> 
To: "Rahman, Akbar" 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] Plugfest in Beijing
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 16:50:18 -0000

--Apple-Mail-17-135058903
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 21, 2010, at 7:18 PM, Rahman, Akbar wrote:

> Just wondering if the server is indeed up and running.


Our CoAP server, directory and gateway are not up and running right now =
- upgrading to the latest CoRE specs. I'll post to the list when they =
are.

Zach

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


--Apple-Mail-17-135058903
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMTE2NTE0
NFowIwYJKoZIhvcNAQkEMRYEFInrd2tp7+Nukf+AmuK00n/a8B4OMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAGwAwMHIBLtb4m78gKJ/vw1++1AtDecajh2fvX5fdp4HufI6lqdMd6Ga
Y0fsbH79e472kEMVi+XcapcAMXD484MUM7r1S4fNneWUwnmyjTxsCEpLhCvtEJth6YL1U7vebfcz
9p+h332POHYBUzSue75SP8sqm3eo4I/0tYM9bk1G5ZEFv6uSPwuh87BwQ9QwZeX/baC+IX75qBlr
pdr7iw4jseuc5yAn0ritKFYrj20B6qEleVebG9JGLtLoayuIOApGNPM/le7uc1JIgFwFv1Zlp9/n
X6VPMkDvZqMdsUuX6ybwOFeot1UsGHWrc5+fkg81XIR/xeAd2jLZLHxUsTwAAAAAAAA=

--Apple-Mail-17-135058903--

From Akbar.Rahman@InterDigital.com  Thu Oct 21 10:07:22 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22483A69FD for ; Thu, 21 Oct 2010 10:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5TDz3w7RbD2 for ; Thu, 21 Oct 2010 10:07:20 -0700 (PDT)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 2438E3A6A0C for ; Thu, 21 Oct 2010 10:07:19 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 21 Oct 2010 13:08:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 21 Oct 2010 13:08:55 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Plugfest in Beijing
Thread-Index: ActxQETni3q4oYGYTHuM63fmMXzl0AAAlYNg
References: <73224E51-B5F2-4134-B9C8-7D99F34C98CC@sensinode.com>  
From: "Rahman, Akbar" 
To: "Zach Shelby" 
X-OriginalArrivalTime: 21 Oct 2010 17:08:55.0247 (UTC) FILETIME=[A489DDF0:01CB7142]
Cc: core 
Subject: Re: [core] Plugfest in Beijing
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 17:07:22 -0000

Okay, thanks.


Akbar

-----Original Message-----
From: Zach Shelby [mailto:zach@sensinode.com]=20
Sent: Thursday, October 21, 2010 12:52 PM
To: Rahman, Akbar
Cc: cabo@tzi.org; core
Subject: Re: [core] Plugfest in Beijing

On Oct 21, 2010, at 7:18 PM, Rahman, Akbar wrote:

> Just wondering if the server is indeed up and running.


Our CoAP server, directory and gateway are not up and running right now
- upgrading to the latest CoRE specs. I'll post to the list when they
are.

Zach

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


From darco@deepdarc.com  Thu Oct 21 10:09:06 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D9D3A6A4B for ; Thu, 21 Oct 2010 10:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level: 
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YemUhWWYwM3H for ; Thu, 21 Oct 2010 10:09:05 -0700 (PDT)
Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 416673A6A1C for ; Thu, 21 Oct 2010 10:09:05 -0700 (PDT)
Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:37534 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P8yf6-0003zX-Fg; Thu, 21 Oct 2010 13:10:44 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Quattlebaum 
In-Reply-To: 
Date: Thu, 21 Oct 2010 10:10:37 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:       
To: Peter Bigot 
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - spider.nocdirect.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - deepdarc.com
Cc: core 
Subject: Re: [core] draft-ietf-core-block-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 17:09:06 -0000

Hello Peter!

On Oct 21, 2010, at 7:09 AM, Peter Bigot wrote:

> Assume a pure IPv6 network, with devices A and B on an 802.3 wired =
segment configured for jumbo frames that supports an 8192-byte MTU, and =
device C on an 802.15.4 network that patches together support for IPv6's =
required 1280-byte MTU by doing link-layer reassembly of 127-byte frames =
(something we really would rather avoid, but what the heck, IPv6 =
requires it).
>=20
> A 1600-byte resource representation can be retrieved from A by B using =
CoAP in a single IP datagram.  Device C cannot retrieve this resource =
without using the block extension or an alternative protocol.

Can we assume that the intermediate router which dropped the 1600 byte =
response would send back an ICMP "Packet Too Big" response? If so, then =
perhaps the server could use that ICMP response as an indication that =
the block option would be required, and re-send with the block option. =
However, it is likely only possible to send an error message in this =
case without the server keeping state.

__________________
Robert Quattlebaum
Jabber: darco@deepdarc.com
eMail:  darco@deepdarc.com
www:    http://www.deepdarc.com/




From darco@deepdarc.com  Thu Oct 21 10:39:46 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9863A6A22 for ; Thu, 21 Oct 2010 10:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.286
X-Spam-Level: 
X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_73=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21jqXE52mfGq for ; Thu, 21 Oct 2010 10:39:44 -0700 (PDT)
Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 82F2A3A699A for ; Thu, 21 Oct 2010 10:39:43 -0700 (PDT)
Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:34257 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P8z8l-00068t-5f; Thu, 21 Oct 2010 13:41:23 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Robert Quattlebaum 
Date: Thu, 21 Oct 2010 10:41:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
To: core 
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - spider.nocdirect.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - deepdarc.com
Subject: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 17:39:46 -0000

Below is an informal document I prepared as I was fleshing out the =
details of how exactly a Next option would work. My goal was to develop =
a chunking mechanism that had all of the benefits of the Block option =
without the serious drawbacks when serving dynamically generated =
content.

I am providing it here to add to the discussion about =
draft-ietf-core-block-00. Ultimately I would like to see =
draft-ietf-core-block adopt some or all of what I describe below because =
I believe that it is a more flexible mechanism and makes the minimum =
implementation easier to implement.

Feedback is welcome.

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

# Content Chunking and Random Access Header Options #

This informal document outlines a mechanism of chunking large CoAP =
content sizes into smaller more convenient sizes using an alternative =
method than described in draft-ietf-core-block-00.

## Header Options ##

This chunking mechanism introduces two new header options: Range and =
Next.

The "Next" option specifies an opaque server-defined token which is used =
for retrieving the next chunk of content from the server when the =
content was too large to fit in a previous request. It is a critical =
option.

Range specifies two integers: "max-requested-payload-size" and =
"requested-content-offset". It is an elective header, and not required =
to be handled or implemented by the server. The offset may be omitted, =
and if so is assumed to be zero. "max-requested-payload-size" is largely =
a suggestion that the server may or may not obey, depending on =
implementation constraints. (In the examples below, the value of the =
range option is represented by two numbers: the =
"max-requested-payload-size" and "requested-content-offset", =
respectively)

### Range Option Format ###

The exact wire format of the Range option is TBD, but the following =
description may be used as a starting point.

The contents of the Range header may contain one or two values. The =
first value is "max-requested-payload-size", and is bound to the range =
of [0,16383]. The second (optional) value, "requested-content-offset", =
is unbounded. Each value is encoded using the method described in =
.

### Why not use the Block option? ###

While the Block option is functionally similar to the Range option, the =
Block option has significant differences: 1) It is critical instead of =
elective, 2) it is much more coarse in terms of block sizes and offsets, =
and 3) it includes a mechanism for indicating the end of content.

It is important that the Range option be elective because the Range =
option can be used to indicate a "max-requested-payload-size" for =
chunked transfers. Since the "max-requested-payload-size" is simply a =
recommendation for the server and the default "requested-content-offset" =
is zero even without the Range header, the response will always be valid =
(but perhaps not polite, in the sense that the server may ignore the =
"max-requested-payload-size"). In cases where the =
"requested-content-offset" is non-zero, the client can easily determine =
from the response if the server supported the option or not from the =
response code: a server which supports the header would ALWAYS return =
206 (Partial Content) to such a request, and a server which doesn't =
would return 200 (OK).

The coarse nature of the Block option appears to make it somewhat =
incompatible with varying payload sizes. This is most clearly evident in =
the PUT and POST cases, described in a section below.

The mechanism for indicating the end of content is not necessary in the =
GET request case, as this condition is indicated by the absence of the =
Next header. For PUT and POST requests (as described in a section =
below), the content is terminated by the first empty payload.=20

## GET Requests ##

If at any time the server determines that the payload of a response is a =
subset of the entire content represented by the requested resource, it =
MUST reply with a 206 (Partial Content) response code. (A corollary of =
this is that if the Range header is present with a non-zero =
"requested-content-offset" that the correct positive response code will =
always be 206)

If there is additional content after what is included in the payload of =
the response, the server MUST include a Next option in the response =
containing an opaque token which the client would use to fetch the rest =
of the content in a subsequent request. If the payload in the response =
represents the end of the content, then a Next option MUST NOT be =
included in the response. The absence of a Next header in the response =
indicates the end of the content.

While the client MAY include a Range option for an initial request, =
subsequent requests to retrieve the rest of the content (which include a =
Next option) SHOULD NOT include a Range option. If the Range option is =
included, it MUST contain the exact same value as the Range option from =
the original request. The results of doing otherwise are undefined.

The client can influence the payload chunking threshold of the server by =
including a Range option in the initial request. In the presence of the =
Range option in the initial request, the server SHOULD make every =
attempt to keep payload sizes below the "max-requested-payload-size" =
specified by the option.

The presence of Range header in a 206 response from a server is =
optional, except in the case of an asynchronous 206 response---where it =
is required for correlation purposes.

Using the Range header with a non-zero "requested-content-offset" =
requires random-access support, which is OPTIONAL for the server to =
implement. In cases where clients make a request for a non-zero =
"requested-content-offset" to a server which does not support random =
access, the server MUST NOT respond with a 206 (Partial Content) =
response and SHOULD respond with a 501 (Not Implemented). A server =
response of 200 (OK) to such a request would indicate to the client that =
the Range option is not supported by the server.

While it would be possible for a client to implement a chunked download =
ignoring the Next header and using only the Range header, such an =
implementation is strongly NOT RECOMMENDED because it would only be =
successful with servers which support random access.

### Example 1 ###

Client is requesting example.txt, which is 192 bytes long. The internal =
server chunking threshold is 64 bytes.=20

Client -> Server, TT=3DCONF, TID=3D0001
	GET /example.txt

Server -> Client, TT=3DACK, TID=3D0001
	206 Partial Content
	Next: 0x01
	

Client -> Server, TT=3DCONF, TID=3D0002
	GET /example.txt
	Next: 0x01

Server -> Client, TT=3DACK, TID=3D0002
	206 Partial Content
	Next: 0x02
	

Client -> Server, TT=3DCONF, TID=3D0003
	GET /example.txt
	Next: 0x02

Server -> Client, TT=3DACK, TID=3D0003
	206 Partial Content
	

### Example 2 ###

Client is requesting example.txt, which is 192 bytes long. The client =
requests a chunk size of 32 bytes. Note that while this example includes =
the value of "max-requested-payload-size" in the Next option, the value =
of the Next option is implementation-specific to the server and may =
contain any value or no value.

Client -> Server, TT=3DCONF, TID=3D0001
	GET /example.txt
	Range: 32 0

Server -> Client, TT=3DACK, TID=3D0001
	206 Partial Content
	Next: 0x01 0x20
	

Client -> Server, TT=3DCONF, TID=3D0002
	GET /example.txt
	Next: 0x01 0x20

... snip ...

Server -> Client, TT=3DACK, TID=3D0005
	206 Partial Content
	Next: 0x05 0x20
	

Client -> Server, TT=3DCONF, TID=3D0006
	GET /example.txt
	Next: 0x05 0x20

Server -> Client, TT=3DACK, TID=3D0006
	206 Partial Content
	

### Example 3 ###

Client is requesting example.txt, which is 128 bytes long. The server =
responds with an asynchronous response.

Client -> Server, TT=3DCONF, TID=3D0001
	GET /example.txt

Server -> Client, TT=3DACK, TID=3D0001
	Code: 0

Server -> Client, TT=3DCONF, TID=3D3001
	206 Partial Content
	Next: 0x01
	Range: 64 0
	

Client -> Server, TT=3DACK, TID=3D3001
	Code: 0

Client -> Server, TT=3DCONF, TID=3D0002
	GET /example.txt
	Next: 0x01

Server -> Client, TT=3DACK, TID=3D0002
	Code: 0

Server -> Client, TT=3DCONF, TID=3D3002
	206 Partial Content
	Range: 64 64
	

Client -> Server, TT=3DACK, TID=3D3002
	Code: 0

### Example 5 ###

Client is requesting example.csv, which is dynamically populated by the =
server with rows from a database in a CSV format. The full generated =
content looks like this:

id, name, min, max, value
1, sensor01, 0.0, 1.0, 0.28
2, temp, -40, 80, 0
3, nil1, 0, 0, 0
4, nil2, 0, 0, 0
5, pressure05, 0.0, 20.0, 5.82
6, sensor02, 0.0, 1.0, 0.95

The server sends responses with a max chunk threshold of 64. The payload =
size of the response varies from request-to-request as the rows are =
retrieved.=20

Client -> Server, TT=3DCONF, TID=3D0001
	GET /example.csv

Server -> Client, TT=3DACK, TID=3D0001
	206 Partial Content
	Content-Type: text/csv
	Etag: 1
	Next: 0x02
	"id, name, min, max, value"
	"1, sensor01, 0.0, 1.0, 0.28"

Client -> Server, TT=3DCONF, TID=3D0002
	GET /example.csv
	Next: 0x02

Server -> Client, TT=3DACK, TID=3D0002
	206 Partial Content
	Content-Type: text/csv
	Etag: 1
	Next: 0x05
	"2, temp, -40, 80, 0"
	"3, nil1, 0, 0, 0"
	"4, nil2, 0, 0, 0"

Client -> Server, TT=3DCONF, TID=3D0003
	GET /example.csv
	Next: 0x05

Server -> Client, TT=3DACK, TID=3D0003
	206 Partial Content
	Etag: 1
	Content-Type: text/csv
	"5, pressure05, 0.0, 20.0, 5.82"
	"6, sensor02, 0.0, 1.0, 0.95"

## POST and PUT requests ##

POST and PUT require a slightly different process.

In the case where the client wants to send a request with a larger =
amount of data than it is comfortable fitting into a single CoAP =
payload, the client would send only a subset of the data to the server, =
along with both a Range option, describing what slice of the data in =
question is being sent. [TBD: perhaps we should also require that the =
initial request include an empty Next option to force a failure if =
chunked transfers are not supported by the server]

The payload size of the requests which make up the transfer is =
client-defined, and may vary from request-to-request.

The use of the Next header for POST and PUT requests is ultimately =
determined by the server implementation and is entirely optional.

If successful, the server would then respond with a response code of 100 =
(Continue), indicating that the client should send the next slice. The =
response would include a Range option describing the range of the data =
that was just received, and possibly a Next option. If the server =
response includes a "Next" option, that option and value should be =
included in the next request by the client.

The end of the content is signified by a request with a zero-length =
payload size, at which point the server MUST NOT respond with a 100 =
(Continue) response code. The final response from the server MUST NOT =
include a Range or Next option.

### Example 5 ###

Client is sending example.txt, which is 128 bytes long. Chunk size is 64 =
bytes.

Client -> Server, TT=3DCONF, TID=3D0001
	POST /example.txt
	Range: 64 0
	
=09
Server -> Client, TT=3DACK, TID=3D0001
	100 Continue
	Range: 64 0
	Next: 0x40

Client -> Server, TT=3DCONF, TID=3D0002
	POST /example.txt
	Range: 64 64
	Next: 0x40
	

Server -> Client, TT=3DCONF, TID=3D0002
	100 Continue
	Range: 64 64
	Next: 0x80

Client -> Server, TT=3DCONF, TID=3D0003
	POST /example.txt
	Range: 0 128
	Next: 0x80

Server -> Client, TT=3DCONF, TID=3D0003
	201 Created
	Etag: 1

## Proxies and Caches ##

In general, a chunked transaction should be treated as a single REST =
transaction by caches and proxies. An exception is a CoAP-CoAP proxy, in =
which case no special considerations are required.

Caches which implement this mechanism MUST cache the entire content of a =
chunked request. Caches do not need to respect the chunk boundaries used =
for fetching the original content, and may choose chunk boundaries based =
on whatever criteria is most convenient.


__________________
Robert Quattlebaum
Jabber: darco@deepdarc.com
eMail:  darco@deepdarc.com
www:    http://www.deepdarc.com/




From pab@peoplepowerco.com  Thu Oct 21 12:11:21 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90053A6A76 for ; Thu, 21 Oct 2010 12:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.343
X-Spam-Level: 
X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3q+5xUNFO8I for ; Thu, 21 Oct 2010 12:11:05 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B5A743A6802 for ; Thu, 21 Oct 2010 12:10:59 -0700 (PDT)
Received: by qwb7 with SMTP id 7so67638qwb.31 for ; Thu, 21 Oct 2010 12:12:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.102.83.1 with SMTP id g1mr2071188mub.47.1287688353607; Thu, 21 Oct 2010 12:12:33 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 21 Oct 2010 12:12:33 -0700 (PDT)
Date: Thu, 21 Oct 2010 14:12:33 -0500
Message-ID: 
From: Peter Bigot 
To: core 
Content-Type: multipart/alternative; boundary=001636416ed7e5f0630493254e44
Subject: [core] draft-ietf-core-link-format-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 19:11:21 -0000

--001636416ed7e5f0630493254e44
Content-Type: text/plain; charset=ISO-8859-1

Section 2:

   CoRE resource discovery extends the HTTP Link Header format specified
   in [I-D.nottingham-http-link-header
]
which is specified in Augmented
   Backus-Naur Form (ABNF) notation [RFC5234
].  The format does not

I-D.nottingham-http-link-header (RFC-to-be 5988) uses the ABNF notation of
RFC2616, not RFC5234.  RFC2616 defines its own syntax, and is not compatible
with that of RFC5234 or its predecessor RFC2234, which is what is used by
RFC3986 to define URI syntax.  This draft is indeed using the 2616, not
5234, syntax: witness the use of vertical bar instead of forward slash for
alternatives.

   The CoRE link format uses the ABNF description and associated rules
   in Section 5 of [I-D.nottingham-http-link-header
].
 The "Link:" text

It's probably worth noting, as I-D.nottingham-http-link-header does, that
the rules for URI, URI-reference (misspelled URI-Reference in nottingham),
and pchar (see far below) are taken from RFC3986.

      link-extension    = ( "d" "=" <"> URI <">)
      link-extension    = ( "sh" "=" <"> URI-Reference <">)
      link-extension    = ( "n" "=" ( quoted-string | URI ) )
      link-extension    = ( "ct" "=" integer )
      link-extension    = ( "id" "=" ( quoted-string | URI ) )
      integer           = 1*DIGIT

The reference to "URI" in "d" should probably be a URI-reference.

The reference to "URI-Reference" in "sh" should be a URI-reference.

The addition of URI as an alternative to quoted-string for "n" and "id"
results in syntactic ambiguities.  Like the other URI instances, these would
have to be enclosed in quotes, and therefore could not be distinguished from
quoted-string values.  The reference to URI in these rules should be
removed, or an alternative quoting character found to distinguish them from
quoted-string.  (Although a URI value for "n" makes sense, "id" is already
described as an opaque string with examples of a UUID or XRI; I suggest just
dropping URI from the syntax rules, and mentioning it in the descriptive
text if necessary.)

Section 2.1

2.1.  Target and context IRIs

The term IRI is undefined in this document.  As CoAP doesn't deal with
internationalization, make this URI?

   Each link description conveys one target URI as a URI-Reference
   inside angle brackets ("<>").  The context of a link conveyed in the
   description is by default the URI of the resource that returned the
   link-format representation (usually ./well-known/core).  Thus each

Although I-D.nottingham-http-link-header does refer to a "context IRI", the
term "base URI" is used in RFC3986, and may be more familiar to readers.  A
reference to section 5 of RFC3986 may be helpful to remind readers how URIs
are constructed from URI references.

"./well-known/core" is a URI reference, not a URI, and can't serve as the
base: it lacks the scheme and authority parts of the URI.  I suggest simply
removing the parenthetical remark.

   implementation can however choose to ignore such links.  It is not
   expected that most implementations will be able to derive useful from
   explicitly anchored links.

Insert "information" between "useful from"?

Section 2.5

   The resource name "n" attribute is used to assign eith a human
   readable or a semantically important name to a resource.  In the case

s/eith/either/

Section 3:

   descriptions) offered by that constrained server.  Well-known
   resources have a reserved base URI "/.well-known/" as specified in
   [RFC5785 ].  This document
defines a new well-known URI for CoRE
   discovery "/.well-known/core" Section 5.1
.
 A server implementing
   this specification MUST support this URI on the default port
   appropriate for the protocol for the purpose of resource discovery.

"./well-known/" is not a base URI.  The term used in RFC5785 is "path
prefix".  This should be rewritten as:

... Well-known resources have a path component that begins with
"/.well-known/" as specified in  [RFC5785]. This document defines a new
well-known path prefix for CoRE discovery "/.well-known/core"  [Section
5.1].  A server implementing this specification MUST support this path
prefix on the default port....

Section 3.1:

   A server implementing this document MAY support the query string
   /.well-known/core? with uri= corresponding to the link-value or any
   of the resource description attributes for the purpose of filtering a

Rephrase?  /.well-known/core? is not a query string, and in fact the syntax
for the query part of a URI does not insist on key=value elements.  If this
is to be included, full syntax for a query part of the URI within the
well-known path should be included.

   (if any).  Implementations supporting filtering MUST also support
   wildcard * endings.  If resource descriptions are organized

This assumes somebody knows what supporting wildcard * endings means.  I
could guess.

In the spirit of being helpful, perhaps:

A server implementing this document MAY recognize the query part of a
resource-discovery URI as a filter on the resources to be returned.  The
query part should conform to the following syntax:

  filter-query = resource-param "=" query-pattern
  resource-param = "uri" | "d" | "sh" | "n" | "id"
  query-pattern = 1*pchar [ "*" ]

The resource-param "uri" refers to the URI-reference between the "<" and ">"
characters of a link-value.  Other resource-param values refer to the link
attribute they name.  (TBD: Do we want to add the resource description
attributes that I excluded, or the standard link-param attributes from
I-D.nottingham-http-link-header?)  Filtering is performed by comparing the
query-pattern against the value of the attribute identified by the
resource-param for each link-value in the collection of resources identified
by the URI path.

If the decoded query-pattern does not end with "*", a link value matches the
query only if the value of the attribute or URI-reference denoted by the
resource-param is bytewise identical to the query-pattern.  If the decoded
query-pattern ends with "*", it is sufficient that the remainder of the
query-pattern be a prefix of the value denoted by the resource-param.

Not that I'm happy with this, but maybe it's a start?

(The legal characters for a query part of a URI are defined by RFC3986,
which does not use the same ABNF syntax as this document.  quoted-string
includes characters that cannot be part of a query, so I had to go with
1*pchar.  Understand that doing this introduces the concept of pct-encoded
characters, such as %22 to denote a double quote, or %20 for space.  Since
we will probably carry the Uri-Query option in its unencoded form, this may
not matter.  As usual, everything gets messy when you try to be formal and
start seeing the border cases.)

--001636416ed7e5f0630493254e44
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Section 2:
   CoRE resource discovery extends the=
 HTTP Link Header format specified
   in [I-D=
.nottingham-http-link-header] which is specified in Augmented
   Backus-Naur Form (ABNF) notation [   The CoRE link format uses the ABNF description an=
d associated rules
   in Section 5 of [I-D.nottingham-http-link-header].  The "Link:" text

It's probably worth noting, as I-D.nottingham-http-link-header do=
es, that the rules for URI, URI-reference (misspelled URI-Reference in nott=
ingham), and pchar (see far below) are taken from RFC3986.
=A0=A0=A0=A0=A0 link-extension    =3D ( "d" "=3D" <&=
quot;> URI <">)
      link-extension    =3D ( "sh" "=3D" <">=
 URI-Reference <">)
      link-extension    =3D ( "n" "=3D" ( quoted-string=
 | URI ) )
      link-extension    =3D ( "ct" "=3D" integer )
      link-extension    =3D ( "id" "=3D" ( quoted-strin=
g | URI ) )
      integer           =3D 1*DIGIT

The reference to "URI" in "d" should probably be =
a URI-reference.



The reference to "URI-Reference" in "sh" should be a UR=
I-reference.


The addition of URI as an alternative to quoted-string for "n"=
; and "id" results in syntactic ambiguities.=A0 Like the other UR=
I instances, these would have to be enclosed in quotes, and therefore could=
 not be distinguished from quoted-string values.=A0 The reference to URI in=
 these rules should be removed, or an alternative quoting character found t=
o distinguish them from quoted-string.=A0 (Although a URI value for "n=
" makes sense, "id" is already described as an opaque string=
 with examples of a UUID or XRI; I suggest just dropping URI from the synta=
x rules, and mentioning it in the descriptive text if necessary.)


Section 2.1
2.1.  Target and context IRIs
The term I=
RI is undefined in this document.=A0 As CoAP doesn't deal with internat=
ionalization, make this URI?


   Each link description conveys one target URI as a=
 URI-Reference
   inside angle brackets ("<>").  The context of a link con=
veyed in the
   description is by default the URI of the resource that returned the
   link-format representation (usually ./well-known/core).  Thus each

Although I-D.nottingham-http-link-header does refer to a "contex=
t IRI", the term "base URI" is used in RFC3986, and may be m=
ore familiar to readers.=A0 A reference to section 5 of RFC3986 may be help=
ful to remind readers how URIs are constructed from URI references.


"./well-known/core" is a URI reference, not a URI, and can=
9;t serve as the base: it lacks the scheme and authority parts of the URI.=
=A0 I suggest simply removing the parenthetical remark.
   implementation can however choose to ignore such links.  It is not
   expected that most implementations will be able to derive useful=A0from
   explicitly anchored links.
Insert "information" betwe=
en "useful from"?

Section 2.5
  =
 The resource name "n" attribute is used to assign eith a human
   readable or a semantically important name to a resource.  In the case
s/eith/either/

Section 3:
   descri=
ptions) offered by that constrained server.  Well-known
   resources have a reserved base URI "/.well-known/" as specifie=
d in
   [RFC5785].  This d=
ocument defines a new well-known URI for CoRE
   discovery "/.well-=
known/core" Section 5.1.  A server implementing

=A0=A0 this specification MUST support this URI on the default port
   appropriate for the protocol for the purpose of resource discovery.

"./well-known/" is not a base URI.=A0 The term used in RFC5=
785 is "path prefix".=A0 This should be rewritten as:

... Well-known resources have a path componen=
t that begins with "/.well-known/" as specified in=A0 [RFC5785]. =
 This document defines a new well-known path prefix for CoRE discovery &quo=
t;/.well-known/core"=A0 [Section 5.1].=A0 A server implementing this s=
pecification MUST support this path prefix on the default port....


Section 3.1:
   A server implementing t=
his document MAY support the query string
   /.well-known/core? with uri=3D corresponding to the link-value or any
   of the resource description attributes for the purpose of filtering a

Rephrase?=A0 /.well-known/core? is not a query string, and in fact th=
e syntax for the query part of a URI does not insist on key=3Dvalue element=
s.=A0 If this is to be included, full syntax for a query part of the URI wi=
thin the well-known path should be included.


   (if any).  Implementations supporting filtering M=
UST also support
   wildcard * endings.  If resource descriptions are organized

This assumes somebody knows what supporting wildcard * endings means.=
=A0 I could guess.

In the spirit of being helpful, perhaps:

<=
div style=3D"margin-left: 40px;">  A server implementing this document MAY =
recognize the query part of a resource-discovery URI as a filter on the res=
ources to be returned.=A0 The query part should conform to the following sy=
ntax:


=A0 filter-query =3D resource-param "=3D" query-pattern
=
=A0 resource-param =3D "uri" | "d" | "sh" | &=
quot;n" | "id"
=A0 query-pattern =3D 1*pchar [ "*&qu=
ot; ]


The resource-param "uri" refers to the URI-reference between the =
"<" and ">" characters of a link-value.=A0 Other =
resource-param values refer to the link attribute they name.=A0 (TBD: Do we=
 want to add the resource description attributes that I excluded, or the st=
andard link-param attributes from I-D.nottingham-http-link-header?)=A0 Filt=
ering is performed by comparing the query-pattern against the value of the =
attribute identified by the resource-param for each link-value in the colle=
ction of resources identified by the URI path.


If the decoded query-pattern does not end with "*", a link va=
lue matches the query only if the value of the attribute or URI-reference d=
enoted by the resource-param is bytewise identical to the query-pattern.=A0=
 If the decoded query-pattern ends with "*", it is sufficient tha=
t the remainder of the query-pattern be a prefix of the value denoted by th=
e resource-param.


Not that I'm happy with this, but maybe it's a start?
=

(The legal characters for a query part of a URI are defined by RFC3986,=
 which does not use the same ABNF syntax as this document.=A0 quoted-string=
 includes characters that cannot be part of a query, so I had to go with 1*=
pchar.=A0 Understand that doing this introduces the concept of pct-encoded =
characters, such as %22 to denote a double quote, or %20 for space.=A0 Sinc=
e we will probably carry the Uri-Query option in its unencoded form, this m=
ay not matter.=A0 As usual, everything gets messy when you try to be formal=
 and start seeing the border cases.)




--001636416ed7e5f0630493254e44--

From cabo@tzi.org  Thu Oct 21 15:20:42 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39503A63CA for ; Thu, 21 Oct 2010 15:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.156
X-Spam-Level: 
X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Nb-uHzPoiIY for ; Thu, 21 Oct 2010 15:20:40 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 4D5BC3A63D2 for ; Thu, 21 Oct 2010 15:20: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 o9LMM0bo004614; Fri, 22 Oct 2010 00:22:00 +0200 (CEST)
Received: from [192.168.217.101] (p5489F504.dip.t-dialin.net [84.137.245.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8A164D11; Fri, 22 Oct 2010 00:21:59 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Fri, 22 Oct 2010 00:21:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>
References: 
To: Robert Quattlebaum 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 22:20:42 -0000

Hi Robert,

thanks for making these thoughts available to the WG.

I don't want to do a detailed comment just yet, but I want to explain =
some of the thinking behind the block option and show how it is almost =
equivalent to yours.

The block option is a design that strives to be minimal while addressing =
the following requirements:
1) REST transfers can be chopped up into pieces without requiring a =
transport/transaction protocol that does segmentation/reassembly;
2) both sides get some say in how large these pieces are;
3) pieces are entirely self-describing, so there is never confusion =
about how to put them together again;
4) servers that have access to the entire binary representation can =
implement GET in a stateless fashion,
5) the encoding is extremely compact.

block does not try to address:
a) arbitrarily sized pieces
b) semantic fragmentation

It seemed easiest to achieve (5) and (4) in combination with (3) by =
using fixed, power-of-two-sized blocks (hence "block" option) together =
with an integer number pacing through these blocks.
The desire for self-describing packets led me to do the protocol =
progress by having the client perform arithmetic on the identifiers, =
which maybe is not the best way to do this.

An alternative would be to make slice identifiers opaque to the client.
A server could still use the compact representation used by current =
block if it wants to, or use some semantic mechanism.

Thought experiment: So how could "block" be changed to do this protocol?

-- the M bit would be deleted; the absence of a block option in a =
response (while a block option is present in the request) would indicate =
the last slice.
(This goes a bit against the self-describing aspect.)

-- in all but the first slice, the client would echo the block option it =
got from the server in the previous slice (i.e., instead of "I want =
block 1 now" it would say "I have block 0 now, give me the next").  The =
server would then increment the block number (or do whatever it needs to =
do).  This gives the server more freedom in the way it encloses the =
block size in the option value (if it wants to be stateless but still =
offer a slice size choice); the current encoding would simply become one =
of many implementation strategies.
(Again, the message is now less self-describing than block was.)

-- the slice size preferred by the client would be indicated outside the =
block option mechanism; we just had an exchange on that aspect.  (I'm =
not sure we want to conflate this with a range option, though.)

After this transformation, the block option is pretty much identical to =
your next option; the option value is now entirely opaque to the client.
Your proposal enhances this by modifying the response codes (which would =
probably need some more detail, as in contrast to HTTP we are not just =
using this for GET).

What do we gain?  A lot more flexibility.

What do we lose?  The simplicity we had because we didn't have the =
flexibility (only 1/2 :-) here).

Maybe, to facilitate debugging tools, the document could still describe =
an encoding of the opaque slice identifier that looks like the current =
block option (slice number + slice size, minus M bit) as a suggested =
format for those cases where it happens to fit.

Is this change worth it?  I'm not yet decided, but I like the fact that =
we have an existence proof now.

Gruesse, Carsten

PS.: Do we really want to have a range option?  I don't think so.  I =
think we'll need a really convincing usage scenario to make that case.

PPS.: An empty block option might be another way to indicate the last =
slice, so we don't feel a need to change response codes.


From trac@tools.ietf.org  Thu Oct 21 15:46:50 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899003A67A7 for ; Thu, 21 Oct 2010 15:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FFF588Vo+z6 for ; Thu, 21 Oct 2010 15:46:49 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1F9833A63CA for ; Thu, 21 Oct 2010 15:46:47 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P93vm-0005Vy-Vh; Thu, 21 Oct 2010 15:48:19 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: zach@sensinode.com, cabo@tzi.org
X-Trac-Project: core
Date: Thu, 21 Oct 2010 22:48:18 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/27
Message-ID: <051.b5aafdd48d95f827f4a809cf50d97982@tools.ietf.org>
X-Trac-Ticket-ID: 27
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core] coap #27 (new): Erroring out on unknown critical options should be a MUST, not a SHOULD
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 22:46:50 -0000

#27: Erroring out on unknown critical options should be a MUST, not a SHOULD

 Erroring out on unknown critical options should be a MUST, not a SHOULD.

 (suggested by Adam Roach)

 (The SHOULD language is probably ok for the specific error code and the
 option number in the payload.  There also needs to be an example for the
 latter.)

-- 
--------------------------------+-------------------------------------------
 Reporter:  cabo@…              |       Owner:  zach@…            
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:  coap-03           
Component:  coap                |     Version:                    
 Severity:  Active WG Document  |    Keywords:                    
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From sakane@tanu.org  Thu Oct 21 16:49:56 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED3D3A659A for ; Thu, 21 Oct 2010 16:49:56 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw3-xJOnbmZS for ; Thu, 21 Oct 2010 16:49:54 -0700 (PDT)
Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by core3.amsl.com (Postfix) with ESMTP id C39893A659C for ; Thu, 21 Oct 2010 16:49:49 -0700 (PDT)
Received: from shoichi-mac.local (unknown [10.1.0.205]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id BEDD116B19; Fri, 22 Oct 2010 08:51:23 +0900 (JST)
Message-ID: <4CC0D318.9020309@tanu.org>
Date: Fri, 22 Oct 2010 08:56:08 +0900
From: Shoichi Sakane 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5
MIME-Version: 1.0
To: Michael John 
References: <4CC0194D.4040909@tanu.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core@ietf.org
Subject: Re: [core] COAP dissector for wireshark
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 21 Oct 2010 23:49:56 -0000

Hi,

You can find it at the bugzilla database of the wireshark.
   https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5270

These files seem to have some incorrect stub.
Please take it at own your risk, don't trust them as you know.

If you want to have further correct data,
maybe you will find it at the Carsten's repository,
or you will get it at the interop.

Shoichi  Sakane

On 10/21/10 11:13 PM, Michael John wrote:
> Hi,
>
> Great! Could you also provide pcap files to play with?
> Many thanks.
>
> Best regards
> Michael
>
> 2010/10/21 Shoichi Sakane >
>
>     Hi, just for your interest.
>
>     The wireshark from svn 34601 or later has a dissector of COAP.
>     It supports
>       * draft-ietf-core-coap-02.txt
>       * draft-ietf-core-block-00.txt
>       * draft-ietf-core-observe-00.txt
>
>     Any feedback would be appreciated.
>     I will join the interop at the meeting if I can.
>
>     Best,
>
>     Shoichi Sakane
>     _______________________________________________
>     core mailing list
>     core@ietf.org 
>     https://www.ietf.org/mailman/listinfo/core
>
>

From darco@deepdarc.com  Thu Oct 21 17:38:35 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9478F3A67F8 for ; Thu, 21 Oct 2010 17:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KfuzKaR0A-X for ; Thu, 21 Oct 2010 17:38:32 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 652623A67DA for ; Thu, 21 Oct 2010 17:38:31 -0700 (PDT)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 019FAB750EC8; Thu, 21 Oct 2010 17:40:08 -0700 (PDT)
X-AuditID: 11807137-b7bf7ae000000f05-20-4cc0dd676cf0
Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 6A.AF.03845.76DD0CC4; Thu, 21 Oct 2010 17:40:07 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Quattlebaum 
In-Reply-To: <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>
Date: Thu, 21 Oct 2010 17:40:07 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Cc: core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 00:38:36 -0000

Hello Carsten!

On Oct 21, 2010, at 3:21 PM, Carsten Bormann wrote:

> Thought experiment: So how could "block" be changed to do this =
protocol?

Ultimately that was the goal with my previous email, but for clarity =
sake I was referring to my proposal as the "Next" option. In reality the =
name of the options is immaterial. It could just as easily be named the =
block option, but I felt referring to it as such might be confusing.

> -- the M bit would be deleted; the absence of a block option in a =
response (while a block option is present in the request) would indicate =
the last slice.
> (This goes a bit against the self-describing aspect.)

As long as the response code of the last response is 206 (Partial =
Content) instead of 200 (OK), the absence of the M bit doesn't make the =
protocol any less self-describing. If the response code were always 200, =
then there would be no way for the client to differentiate between a =
fully contained response and the last response of a chunked request. =
(e.g., 206 responses are always chunked, and the last chunk is denoted =
by the absence of a block option)

> -- in all but the first slice, the client would echo the block option =
it got from the server in the previous slice (i.e., instead of "I want =
block 1 now" it would say "I have block 0 now, give me the next").  The =
server would then increment the block number (or do whatever it needs to =
do).  This gives the server more freedom in the way it encloses the =
block size in the option value (if it wants to be stateless but still =
offer a slice size choice); the current encoding would simply become one =
of many implementation strategies.

Sounds great to me!

> (Again, the message is now less self-describing than block was.)

With the next option, all requests were self-describing as far as the =
server was concerned---but replies were not necessarily self-describing =
to the client. I anticipated that this wasn't a huge problem because if =
the client is keeping state then there is no longer a need for the =
response to be self-describing, as the TID would be adequate. (The TID =
is obviously not adequate in the case of an async response, which is why =
I required the range option to always be included for async responses)

However, if a stateless client really needs to the responses to be =
self-describing, there is already a facility to do so: the Token option. =
The client could simply use the Token option to store the number of =
bytes it has received so far in the transfer. This would make all =
responses that the client would receive self-describing, at least to the =
client.

> -- the slice size preferred by the client would be indicated outside =
the block option mechanism; we just had an exchange on that aspect.  =
(I'm not sure we want to conflate this with a range option, though.)

I just picked the name "Range" for the option because it seemed to be so =
similar. We could easily use a different name to describe a suitably =
similar mechanism. Originally I was just going to re-use the block =
option because it seems to be encoding similar information, but I =
decided against this for the reasons described in my proposal.

> After this transformation, the block option is pretty much identical =
to your next option; the option value is now entirely opaque to the =
client.

Again, sounds great! While I think the other aspects of my proposal are =
still important, having this alone would be a huge win, IMHO.=20

> Your proposal enhances this by modifying the response codes (which =
would probably need some more detail, as in contrast to HTTP we are not =
just using this for GET).

I added the use of the 206 (Partial Response) and 100 (Continue) =
response codes to avoid some ambiguities, as well as to encourage more =
"RESTful" thinking of these sorts of transactions. A 200 code implies =
(to me anyway) that the response of the entire REST transaction is =
self-contained, whereas the other response codes indicate an ongoing =
REST transaction. But that's just me.

> What do we gain?  A lot more flexibility.
>=20
> What do we lose?  The simplicity we had because we didn't have the =
flexibility (only 1/2 :-) here).

While the new mechanism would certainly be less strict (and more =
flexible), did we really loose any simplicity? It seems to me that doing =
this actually makes implementations *more* simple.

As you mentioned earlier, a server which implements the current =
mechanism could be very easily updated to support this new mechanism, =
likely by changing a single line. Zero additional complexity. The client =
would no longer be mutating the block option value before sending it =
back to the server, so this would make client implementations even more =
simple.

> Maybe, to facilitate debugging tools, the document could still =
describe an encoding of the opaque slice identifier that looks like the =
current block option (slice number + slice size, minus M bit) as a =
suggested format for those cases where it happens to fit.

This is effectively what the Range option contained, but with higher =
resolution.=20

> PS.: Do we really want to have a range option?  I don't think so.  I =
think we'll need a really convincing usage scenario to make that case.

As I said earlier, I named it "Range" because it seemed to be =
descriptive of what I was using it for, but the name isn't really =
important: what's important is what it does. Here was the goals I was =
trying to accomplish with the Range option:

	* Provide a way for the client to influence the chunking =
threshold that the server uses.
	* Provide a way for the client to associate an asynchronous =
response with the GET request.
	* Enable random access for GET requests, when supported by the =
server. (Kind of a bonus, as least as far as this spec is concerned)

In my proposal, the server would optionally include a range option in =
GET responses (except async responses, where they were required) for =
debugging purposes.

I used the option heavily in the PUT and POST cases, but this could be =
easily avoided by only using the "opaque" block option---since that =
alone would allow the server to keep track of the transfer in a =
stateless fashion and the client is most likely stateful anyway. If the =
client really does want to (somehow) be stateless in such a case, it can =
preserve its state using the Token option.

> PPS.: An empty block option might be another way to indicate the last =
slice, so we don't feel a need to change response codes.

Why avoid using more descriptive response codes, especially when they =
are codes which are already used for the same thing in HTTP?

__________________
Robert Quattlebaum
Jabber: darco@deepdarc.com
eMail:  darco@deepdarc.com
www:    http://www.deepdarc.com/




From pab@peoplepowerco.com  Fri Oct 22 02:53:10 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13BD73A6876 for ; Fri, 22 Oct 2010 02:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.644
X-Spam-Level: 
X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.332,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWvbkWr1+vYB for ; Fri, 22 Oct 2010 02:53:07 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 29FFA3A68C7 for ; Fri, 22 Oct 2010 02:53:05 -0700 (PDT)
Received: by fxm8 with SMTP id 8so531088fxm.31 for ; Fri, 22 Oct 2010 02:54:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.172.15 with SMTP id z15mr3047062muo.42.1287741279295; Fri, 22 Oct 2010 02:54:39 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Fri, 22 Oct 2010 02:54:39 -0700 (PDT)
In-Reply-To: 
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org> 
Date: Fri, 22 Oct 2010 04:54:39 -0500
Message-ID: 
From: Peter Bigot 
To: Robert Quattlebaum 
Content-Type: multipart/alternative; boundary=00163642663d83df16049331a199
Cc: core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 09:53:10 -0000

--00163642663d83df16049331a199
Content-Type: text/plain; charset=ISO-8859-1

How about the following to reconcile all this and restore both simplicity
and orthogonality?  There are two independent proposals here (separated by a
key concept), and both can be extensions to core CoAP.

Size management:

- Add an elective option MessageSize, which when used in a request encodes a
one or two byte unsigned integer representing the maximum size of the CoAP
(non-error) response message that should be sent to the client.  Give it a
default value of 1152 or whatever.  Servers use this to determine whether
the resource response can be sent in one message or needs to be chunked.
This use of the option appears only in requests.

- Add an error code TooLarge sent by the server when the representation to
be sent to the client exceeds the size it has specified (or defaulted) and
the server declines (for whatever reason) to pre-emptively chunk it.  The
response message would use MessageSize to convey the total resource size to
the client.  In this use, the value of the option might be larger than two
bytes, if we feel it's reasonable for any CoAP resource to ever have a
representation larger than 65535 bytes.

This eliminates the question of how the server determines whether it should
use any multi-part response like the block option, and provides a facility
for influencing chunking on inherently multi-part responses like Robert's
use cases.

A Comment on Symmetry:

Unlike HTTP, CoAP can assume that each endpoint is capable of being both a
server and a client.  This means we have the option of asymmetry: in
particular if we have a mechanism for GET that allows multi-part
transactions for large resource representations, we do not need to specify a
related mechanism for PUT or POST if doing so is difficult.  What we do
instead is define a content type representing a URI, and do a PUT/POST where
the body is the URI that the server must in turn retrieve in order to get
the actual content of the PUT/POST.  It might do so by sending an ACK to
make the client's transaction asynchronous, retrieving the content from the
client, then executing the operation.

Chunked Retrievals:

A requested resource may be larger than the client has requested, or may
have a content-type that naturally supports chunking.  In either case, the
server may choose to send the resource representation in pieces.

It does so following essentially Robert's process.  A 206 Partial Content
response messsage is sent, including an opaque PartialContentId option.  The
client retrieves the next chunk by re-submitting the request but adding the
PartialContentId option provided in the last chunk.  The final chunk
includes a PartialContentId option of length zero.  All pieces use the same
response code (206).  The value of the resource is the byte-wise catenation
of the individual responses.

Comments:

- Functionally, PartialContentId is similar to HTTP's Content-Range, but
does not reveal information other than whether the piece is the last chunk
of the representation (is the option value length zero or not).  I don't
think CoAP needs a Range option or anything that involves random access
internal to a resource description.  If the resource has internal structure,
provide a RESTful interface to it, e.g. sub-resources identified by the
hierarchical path.

- By accepting the asymmetry of chunking only for responses to GET, we
always leave it up to the client whether it is willing to use a multi-part
transaction, and to determine how large the chunks are.  If we push chunks
at a server, we need a way for the server to say "Too big" or to try to get
the client to stop.   CoAP's client/server symmetry makes that unnecessary.

Peter

On Thu, Oct 21, 2010 at 7:40 PM, Robert Quattlebaum wrote:

> Hello Carsten!
>
> On Oct 21, 2010, at 3:21 PM, Carsten Bormann wrote:
>
> > Thought experiment: So how could "block" be changed to do this protocol?
>
> Ultimately that was the goal with my previous email, but for clarity sake I
> was referring to my proposal as the "Next" option. In reality the name of
> the options is immaterial. It could just as easily be named the block
> option, but I felt referring to it as such might be confusing.
>
> > -- the M bit would be deleted; the absence of a block option in a
> response (while a block option is present in the request) would indicate the
> last slice.
> > (This goes a bit against the self-describing aspect.)
>
> As long as the response code of the last response is 206 (Partial Content)
> instead of 200 (OK), the absence of the M bit doesn't make the protocol any
> less self-describing. If the response code were always 200, then there would
> be no way for the client to differentiate between a fully contained response
> and the last response of a chunked request. (e.g., 206 responses are always
> chunked, and the last chunk is denoted by the absence of a block option)
>
> > -- in all but the first slice, the client would echo the block option it
> got from the server in the previous slice (i.e., instead of "I want block 1
> now" it would say "I have block 0 now, give me the next").  The server would
> then increment the block number (or do whatever it needs to do).  This gives
> the server more freedom in the way it encloses the block size in the option
> value (if it wants to be stateless but still offer a slice size choice); the
> current encoding would simply become one of many implementation strategies.
>
> Sounds great to me!
>
> > (Again, the message is now less self-describing than block was.)
>
> With the next option, all requests were self-describing as far as the
> server was concerned---but replies were not necessarily self-describing to
> the client. I anticipated that this wasn't a huge problem because if the
> client is keeping state then there is no longer a need for the response to
> be self-describing, as the TID would be adequate. (The TID is obviously not
> adequate in the case of an async response, which is why I required the range
> option to always be included for async responses)
>
> However, if a stateless client really needs to the responses to be
> self-describing, there is already a facility to do so: the Token option. The
> client could simply use the Token option to store the number of bytes it has
> received so far in the transfer. This would make all responses that the
> client would receive self-describing, at least to the client.
>
> > -- the slice size preferred by the client would be indicated outside the
> block option mechanism; we just had an exchange on that aspect.  (I'm not
> sure we want to conflate this with a range option, though.)
>
> I just picked the name "Range" for the option because it seemed to be so
> similar. We could easily use a different name to describe a suitably similar
> mechanism. Originally I was just going to re-use the block option because it
> seems to be encoding similar information, but I decided against this for the
> reasons described in my proposal.
>
> > After this transformation, the block option is pretty much identical to
> your next option; the option value is now entirely opaque to the client.
>
> Again, sounds great! While I think the other aspects of my proposal are
> still important, having this alone would be a huge win, IMHO.
>
> > Your proposal enhances this by modifying the response codes (which would
> probably need some more detail, as in contrast to HTTP we are not just using
> this for GET).
>
> I added the use of the 206 (Partial Response) and 100 (Continue) response
> codes to avoid some ambiguities, as well as to encourage more "RESTful"
> thinking of these sorts of transactions. A 200 code implies (to me anyway)
> that the response of the entire REST transaction is self-contained, whereas
> the other response codes indicate an ongoing REST transaction. But that's
> just me.
>
> > What do we gain?  A lot more flexibility.
> >
> > What do we lose?  The simplicity we had because we didn't have the
> flexibility (only 1/2 :-) here).
>
> While the new mechanism would certainly be less strict (and more flexible),
> did we really loose any simplicity? It seems to me that doing this actually
> makes implementations *more* simple.
>
> As you mentioned earlier, a server which implements the current mechanism
> could be very easily updated to support this new mechanism, likely by
> changing a single line. Zero additional complexity. The client would no
> longer be mutating the block option value before sending it back to the
> server, so this would make client implementations even more simple.
>
> > Maybe, to facilitate debugging tools, the document could still describe
> an encoding of the opaque slice identifier that looks like the current block
> option (slice number + slice size, minus M bit) as a suggested format for
> those cases where it happens to fit.
>
> This is effectively what the Range option contained, but with higher
> resolution.
>
> > PS.: Do we really want to have a range option?  I don't think so.  I
> think we'll need a really convincing usage scenario to make that case.
>
> As I said earlier, I named it "Range" because it seemed to be descriptive
> of what I was using it for, but the name isn't really important: what's
> important is what it does. Here was the goals I was trying to accomplish
> with the Range option:
>
>        * Provide a way for the client to influence the chunking threshold
> that the server uses.
>        * Provide a way for the client to associate an asynchronous response
> with the GET request.
>        * Enable random access for GET requests, when supported by the
> server. (Kind of a bonus, as least as far as this spec is concerned)
>
> In my proposal, the server would optionally include a range option in GET
> responses (except async responses, where they were required) for debugging
> purposes.
>
> I used the option heavily in the PUT and POST cases, but this could be
> easily avoided by only using the "opaque" block option---since that alone
> would allow the server to keep track of the transfer in a stateless fashion
> and the client is most likely stateful anyway. If the client really does
> want to (somehow) be stateless in such a case, it can preserve its state
> using the Token option.
>
> > PPS.: An empty block option might be another way to indicate the last
> slice, so we don't feel a need to change response codes.
>
> Why avoid using more descriptive response codes, especially when they are
> codes which are already used for the same thing in HTTP?
>
> __________________
> Robert Quattlebaum
> Jabber: darco@deepdarc.com
> eMail:  darco@deepdarc.com
> www:    http://www.deepdarc.com/
>
>
>
>

--00163642663d83df16049331a199
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

How about the following to reconcile all this and restore both simplicity a=
nd orthogonality?=A0 There are two independent proposals here (separated by=
 a key concept), and both can be extensions to core CoAP.

Size manag=
ement:


- Add an elective option MessageSize, which when used in a request enco=
des a one or two byte unsigned integer representing the maximum size of the=
 CoAP (non-error) response message that should be sent to the client.=A0 Gi=
ve it a default value of 1152 or whatever.=A0 Servers use this to determine=
 whether the resource response can be sent in one message or needs to be ch=
unked.=A0 This use of the option appears only in requests.


- Add an error code TooLarge sent by the server when the representation=
 to be sent to the client exceeds the size it has specified (or defaulted) =
and the server declines (for whatever reason) to pre-emptively chunk it.=A0=
 The response message would use MessageSize to convey the total resource si=
ze to the client.=A0 In this use, the value of the option might be larger t=
han two bytes, if we feel it's reasonable for any CoAP resource to ever=
 have a representation larger than 65535 bytes.


This eliminates the question of how the server determines whether it sh=
ould use any multi-part response like the block option, and provides a faci=
lity for influencing chunking on inherently multi-part responses like Rober=
t's use cases.


A Comment on Symmetry:

Unlike HTTP, CoAP can assume that each en=
dpoint is capable of being both a server and a client.=A0 This means we hav=
e the option of asymmetry: in particular if we have a mechanism for GET tha=
t allows multi-part transactions for large resource representations, we do =
not need to specify a related mechanism for PUT or POST if doing so is diff=
icult.=A0 What we do instead is define a content type representing a URI, a=
nd do a PUT/POST where the body is the URI that the server must in turn ret=
rieve in order to get the actual content of the PUT/POST.=A0 It might do so=
 by sending an ACK to make the client's transaction asynchronous, retri=
eving the content from the client, then executing the operation.


Chunked Retrievals:

A requested resource may be larger than the =
client has requested, or may have a content-type that naturally supports ch=
unking.=A0 In either case, the server may choose to send the resource repre=
sentation in pieces.


It does so following essentially Robert's process.=A0 A 206 Partial=
 Content response messsage is sent, including an opaque PartialContentId op=
tion.=A0 The client retrieves the next chunk by re-submitting the request b=
ut adding the PartialContentId option provided in the last chunk.=A0 The fi=
nal chunk includes a PartialContentId option of length zero.=A0 All pieces =
use the same response code (206).=A0 The value of the resource is the byte-=
wise catenation of the individual responses.


Comments:

- Functionally, PartialContentId is similar to HTTP=
9;s Content-Range, but does not reveal information other than whether the p=
iece is the last chunk of the representation (is the option value length ze=
ro or not).=A0 I don't think CoAP needs a Range option or anything that=
 involves random access internal to a resource description.=A0 If the resou=
rce has internal structure, provide a RESTful interface to it, e.g. sub-res=
ources identified by the hierarchical path.


- By accepting the asymmetry of chunking only for responses to GET, we =
always leave it up to the client whether it is willing to use a multi-part =
transaction, and to determine how large the chunks are.=A0 If we push chunk=
s at a server, we need a way for the server to say "Too big" or t=
o try to get the client to stop.=A0=A0 CoAP's client/server symmetry ma=
kes that unnecessary.


Peter

On Thu, Oct 21, 2010 at 7:40 PM=
, Robert Quattlebaum <darco@deepdarc.com> wrote:

Hello Carsten!




On Oct 21, 2010, at 3:21 PM, Carsten Bormann wrote:



> Thought experiment: So how could "block" be changed to do th=
is protocol?




Ultimately that was the goal with my previous email, but for clarity =
sake I was referring to my proposal as the "Next" option. In real=
ity the name of the options is immaterial. It could just as easily be named=
 the block option, but I felt referring to it as such might be confusing.




> -- the M bit would be deleted; the absence of a block option in a resp=
onse (while a block option is present in the request) would indicate the la=
st slice.

> (This goes a bit against the self-describing aspect.)




As long as the response code of the last response is 206 (Partial Con=
tent) instead of 200 (OK), the absence of the M bit doesn't make the pr=
otocol any less self-describing. If the response code were always 200, then=
 there would be no way for the client to differentiate between a fully cont=
ained response and the last response of a chunked request. (e.g., 206 respo=
nses are always chunked, and the last chunk is denoted by the absence of a =
block option)





> -- in all but the first slice, the client would echo the block option =
it got from the server in the previous slice (i.e., instead of "I want=
 block 1 now" it would say "I have block 0 now, give me the next&=
quot;). =A0The server would then increment the block number (or do whatever=
 it needs to do). =A0This gives the server more freedom in the way it enclo=
ses the block size in the option value (if it wants to be stateless but sti=
ll offer a slice size choice); the current encoding would simply become one=
 of many implementation strategies.





Sounds great to me!




> (Again, the message is now less self-describing than block was.)




With the next option, all requests were self-describing as far as the=
 server was concerned---but replies were not necessarily self-describing to=
 the client. I anticipated that this wasn't a huge problem because if t=
he client is keeping state then there is no longer a need for the response =
to be self-describing, as the TID would be adequate. (The TID is obviously =
not adequate in the case of an async response, which is why I required the =
range option to always be included for async responses)




However, if a stateless client really needs to the responses to be self-des=
cribing, there is already a facility to do so: the Token option. The client=
 could simply use the Token option to store the number of bytes it has rece=
ived so far in the transfer. This would make all responses that the client =
would receive self-describing, at least to the client.





> -- the slice size preferred by the client would be indicated outside t=
he block option mechanism; we just had an exchange on that aspect. =A0(I=
9;m not sure we want to conflate this with a range option, though.)




I just picked the name "Range" for the option because it se=
emed to be so similar. We could easily use a different name to describe a s=
uitably similar mechanism. Originally I was just going to re-use the block =
option because it seems to be encoding similar information, but I decided a=
gainst this for the reasons described in my proposal.





> After this transformation, the block option is pretty much identical t=
o your next option; the option value is now entirely opaque to the client.<=
br>



Again, sounds great! While I think the other aspects of my proposal a=
re still important, having this alone would be a huge win, IMHO.




> Your proposal enhances this by modifying the response codes (which wou=
ld probably need some more detail, as in contrast to HTTP we are not just u=
sing this for GET).




I added the use of the 206 (Partial Response) and 100 (Continue) resp=
onse codes to avoid some ambiguities, as well as to encourage more "RE=
STful" thinking of these sorts of transactions. A 200 code implies (to=
 me anyway) that the response of the entire REST transaction is self-contai=
ned, whereas the other response codes indicate an ongoing REST transaction.=
 But that's just me.





> What do we gain? =A0A lot more flexibility.

>

> What do we lose? =A0The simplicity we had because we didn't have t=
he flexibility (only 1/2 :-) here).




While the new mechanism would certainly be less strict (and more flex=
ible), did we really loose any simplicity? It seems to me that doing this a=
ctually makes implementations *more* simple.



As you mentioned earlier, a server which implements the current mechanism c=
ould be very easily updated to support this new mechanism, likely by changi=
ng a single line. Zero additional complexity. The client would no longer be=
 mutating the block option value before sending it back to the server, so t=
his would make client implementations even more simple.





> Maybe, to facilitate debugging tools, the document could still describ=
e an encoding of the opaque slice identifier that looks like the current bl=
ock option (slice number + slice size, minus M bit) as a suggested format f=
or those cases where it happens to fit.





This is effectively what the Range option contained, but with higher =
resolution.




> PS.: Do we really want to have a range option? =A0I don't think so=
. =A0I think we'll need a really convincing usage scenario to make that=
 case.




As I said earlier, I named it "Range" because it seemed to =
be descriptive of what I was using it for, but the name isn't really im=
portant: what's important is what it does. Here was the goals I was try=
ing to accomplish with the Range option:




 =A0 =A0 =A0 =A0* Provide a way for the client to influence the chunking th=
reshold that the server uses.

 =A0 =A0 =A0 =A0* Provide a way for the client to associate an asynchronous=
 response with the GET request.

 =A0 =A0 =A0 =A0* Enable random access for GET requests, when supported by =
the server. (Kind of a bonus, as least as far as this spec is concerned)


In my proposal, the server would optionally include a range option in GET r=
esponses (except async responses, where they were required) for debugging p=
urposes.



I used the option heavily in the PUT and POST cases, but this could be easi=
ly avoided by only using the "opaque" block option---since that a=
lone would allow the server to keep track of the transfer in a stateless fa=
shion and the client is most likely stateful anyway. If the client really d=
oes want to (somehow) be stateless in such a case, it can preserve its stat=
e using the Token option.





> PPS.: An empty block option might be another way to indicate the last =
slice, so we don't feel a need to change response codes.




Why avoid using more descriptive response codes, especially when they=
 are codes which are already used for the same thing in HTTP?




__________________

Robert Quattlebaum

Jabber: darco@deepdarc.com

eMail: =A0darco@deepdarc.com

www: =A0 =A0http://w=
ww.deepdarc.com/











--00163642663d83df16049331a199--

From cabo@tzi.org  Fri Oct 22 03:03:28 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1084F3A6891 for ; Fri, 22 Oct 2010 03:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.237
X-Spam-Level: 
X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSFpoGm+gqpd for ; Fri, 22 Oct 2010 03:03:26 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1A67E3A67E3 for ; Fri, 22 Oct 2010 03:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9MA4ntK007875; Fri, 22 Oct 2010 12:04:49 +0200 (CEST)
Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EE728E54; Fri, 22 Oct 2010 12:04:48 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Fri, 22 Oct 2010 12:04:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A8E24ED-B009-4D26-90FC-497BC34E5656@tzi.org>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>  
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 10:03:28 -0000

On Oct 22, 2010, at 11:54, Peter Bigot wrote:

> Unlike HTTP, CoAP can assume that each endpoint is capable of being =
both a server and a client. =20

Is that so?
I don't know of any requirement of this sort so far.
(Maybe you mean something different with "client"/"server" here.)

Gruesse, Carsten


From zach@sensinode.com  Fri Oct 22 03:12:49 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316AF3A686D for ; Fri, 22 Oct 2010 03:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.240,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP9brFkI2TMm for ; Fri, 22 Oct 2010 03:12:46 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E86863A6403 for ; Fri, 22 Oct 2010 03:12:45 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9MAE7Xv015498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Oct 2010 13:14:07 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-59-197603694; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: <8A8E24ED-B009-4D26-90FC-497BC34E5656@tzi.org>
Date: Fri, 22 Oct 2010 13:14:08 +0300
Message-Id: <627ECE5B-9814-4E4A-8D2A-75F3165815FA@sensinode.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>   <8A8E24ED-B009-4D26-90FC-497BC34E5656@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1081)
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 10:12:49 -0000

--Apple-Mail-59-197603694
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 22, 2010, at 1:04 PM, Carsten Bormann wrote:

> On Oct 22, 2010, at 11:54, Peter Bigot wrote:
>=20
>> Unlike HTTP, CoAP can assume that each endpoint is capable of being =
both a server and a client. =20
>=20
> Is that so?
> I don't know of any requirement of this sort so far.
> (Maybe you mean something different with "client"/"server" here.)

It is often the case that a server will also include client =
functionality (if supporting asynchronous responses or subscription, =
they require that you can initiate transactions), but not the other way =
around. You very well may have client-only implementations. Considering =
that we are dealing with constrained devices, we can't assume or require =
that they will implement both.

Zach

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

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


--Apple-Mail-59-197603694
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMjEwMTQw
OVowIwYJKoZIhvcNAQkEMRYEFGC/6hkTNrHIqPCNbOEzPP1NEi4sMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAI+eM2nNr64OuGRGeh3anNLj2Fbqzwnxt8rYJXlG/6wUVGNJEYRuREXZ
SZ2Z0FeQ+NI7KBzDIrMWFOKzS3zLrUU2dFIZuJgoArER2LCCuQQkJo58MBWh/HDBfPEhtLGmG1Wn
2307+WcXOj5fNE0meQtUHSWMhcn4kIUNmhHWByz6RE+vsR/tpAUoc5jUBro3qra3U4o/f3G7tiES
LjdMb0+G9Uc694cGdLi8LCEEZ6Xr2MmyzrutSNrxcBjoJ4c9sMKrXbXBPrXukSoH7+SVCtuXfvh7
8FaObZJXKU6InHIYzzSHNhvG5GOsExLxBEDIRXdqbiVNfsM6KZO4CgwfEpoAAAAAAAA=

--Apple-Mail-59-197603694--

From zach@sensinode.com  Fri Oct 22 03:22:39 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12583A677E for ; Fri, 22 Oct 2010 03:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.064
X-Spam-Level: 
X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tttcaiYoBiRx for ; Fri, 22 Oct 2010 03:22:38 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8850C3A6855 for ; Fri, 22 Oct 2010 03:22:36 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9MAOBb2017236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Oct 2010 13:24:12 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-61-198207949; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Fri, 22 Oct 2010 13:24:13 +0300
Message-Id: 
References: 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] draft-ietf-core-link-format-00 comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 10:22:40 -0000

--Apple-Mail-61-198207949
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Peter,

Thanks for the feedback on link-format. I will work on these =
improvements in the next version, not sure if I can do that for the Oct =
25th cutoff. If not then I'll update the draft when submission opens up =
again in Beijing.

Zach

On Oct 21, 2010, at 10:12 PM, Peter Bigot wrote:

> Section 2:
>    CoRE resource discovery extends the HTTP Link Header format =
specified
>    in [
> I-D.nottingham-http-link-header
> ] which is specified in Augmented
>    Backus-Naur Form (ABNF) notation [
> RFC5234
> ].  The format does not
>=20
> I-D.nottingham-http-link-header (RFC-to-be 5988) uses the ABNF =
notation of RFC2616, not RFC5234.  RFC2616 defines its own syntax, and =
is not compatible with that of RFC5234 or its predecessor RFC2234, which =
is what is used by RFC3986 to define URI syntax.  This draft is indeed =
using the 2616, not 5234, syntax: witness the use of vertical bar =
instead of forward slash for alternatives.
>    The CoRE link format uses the ABNF description and associated rules
>    in Section 5 of [
> I-D.nottingham-http-link-header
> ].  The "Link:" text
>=20
> It's probably worth noting, as I-D.nottingham-http-link-header does, =
that the rules for URI, URI-reference (misspelled URI-Reference in =
nottingham), and pchar (see far below) are taken from RFC3986.
>       link-extension    =3D ( "d" "=3D" <"> URI <">)
>       link-extension    =3D ( "sh" "=3D" <"> URI-Reference <">)
>       link-extension    =3D ( "n" "=3D" ( quoted-string | URI ) )
>       link-extension    =3D ( "ct" "=3D" integer )
>       link-extension    =3D ( "id" "=3D" ( quoted-string | URI ) )
>       integer           =3D 1*DIGIT
>=20
> The reference to "URI" in "d" should probably be a URI-reference.
>=20
> The reference to "URI-Reference" in "sh" should be a URI-reference.
>=20
> The addition of URI as an alternative to quoted-string for "n" and =
"id" results in syntactic ambiguities.  Like the other URI instances, =
these would have to be enclosed in quotes, and therefore could not be =
distinguished from quoted-string values.  The reference to URI in these =
rules should be removed, or an alternative quoting character found to =
distinguish them from quoted-string.  (Although a URI value for "n" =
makes sense, "id" is already described as an opaque string with examples =
of a UUID or XRI; I suggest just dropping URI from the syntax rules, and =
mentioning it in the descriptive text if necessary.)
>=20
> Section 2.1
> 2.1.  Target and context IRIs
>=20
> The term IRI is undefined in this document.  As CoAP doesn't deal with =
internationalization, make this URI?
>    Each link description conveys one target URI as a URI-Reference
>    inside angle brackets ("<>").  The context of a link conveyed in =
the
>    description is by default the URI of the resource that returned the
>    link-format representation (usually ./well-known/core).  Thus each
>=20
> Although I-D.nottingham-http-link-header does refer to a "context =
IRI", the term "base URI" is used in RFC3986, and may be more familiar =
to readers.  A reference to section 5 of RFC3986 may be helpful to =
remind readers how URIs are constructed from URI references.
>=20
> "./well-known/core" is a URI reference, not a URI, and can't serve as =
the base: it lacks the scheme and authority parts of the URI.  I suggest =
simply removing the parenthetical remark.
>    implementation can however choose to ignore such links.  It is not
>    expected that most implementations will be able to derive useful =
from
>    explicitly anchored links.
>=20
> Insert "information" between "useful from"?
>=20
> Section 2.5
>    The resource name "n" attribute is used to assign eith a human
>    readable or a semantically important name to a resource.  In the =
case
>=20
> s/eith/either/
>=20
> Section 3:
>    descriptions) offered by that constrained server.  Well-known
>    resources have a reserved base URI "/.well-known/" as specified in
>    [
> RFC5785].  This document defines a new well-known URI for CoRE
>    discovery "/.well-known/core" Section 5.1.  A server implementing
>=20
>    this specification MUST support this URI on the default port
>    appropriate for the protocol for the purpose of resource discovery.
>=20
> "./well-known/" is not a base URI.  The term used in RFC5785 is "path =
prefix".  This should be rewritten as:
>=20
> ... Well-known resources have a path component that begins with =
"/.well-known/" as specified in  [RFC5785]. This document defines a new =
well-known path prefix for CoRE discovery "/.well-known/core"  [Section =
5.1].  A server implementing this specification MUST support this path =
prefix on the default port....
>=20
> Section 3.1:
>    A server implementing this document MAY support the query string
>    /.well-known/core? with uri=3D corresponding to the link-value or =
any
>    of the resource description attributes for the purpose of filtering =
a
>=20
> Rephrase?  /.well-known/core? is not a query string, and in fact the =
syntax for the query part of a URI does not insist on key=3Dvalue =
elements.  If this is to be included, full syntax for a query part of =
the URI within the well-known path should be included.
>    (if any).  Implementations supporting filtering MUST also support
>    wildcard * endings.  If resource descriptions are organized
>=20
> This assumes somebody knows what supporting wildcard * endings means.  =
I could guess.
>=20
> In the spirit of being helpful, perhaps:
>=20
> A server implementing this document MAY recognize the query part of a =
resource-discovery URI as a filter on the resources to be returned.  The =
query part should conform to the following syntax:
>=20
>   filter-query =3D resource-param "=3D" query-pattern
>   resource-param =3D "uri" | "d" | "sh" | "n" | "id"
>   query-pattern =3D 1*pchar [ "*" ]
>=20
> The resource-param "uri" refers to the URI-reference between the "<" =
and ">" characters of a link-value.  Other resource-param values refer =
to the link attribute they name.  (TBD: Do we want to add the resource =
description attributes that I excluded, or the standard link-param =
attributes from I-D.nottingham-http-link-header?)  Filtering is =
performed by comparing the query-pattern against the value of the =
attribute identified by the resource-param for each link-value in the =
collection of resources identified by the URI path.
>=20
> If the decoded query-pattern does not end with "*", a link value =
matches the query only if the value of the attribute or URI-reference =
denoted by the resource-param is bytewise identical to the =
query-pattern.  If the decoded query-pattern ends with "*", it is =
sufficient that the remainder of the query-pattern be a prefix of the =
value denoted by the resource-param.
>=20
> Not that I'm happy with this, but maybe it's a start?
>=20
> (The legal characters for a query part of a URI are defined by =
RFC3986, which does not use the same ABNF syntax as this document.  =
quoted-string includes characters that cannot be part of a query, so I =
had to go with 1*pchar.  Understand that doing this introduces the =
concept of pct-encoded characters, such as %22 to denote a double quote, =
or %20 for space.  Since we will probably carry the Uri-Query option in =
its unencoded form, this may not matter.  As usual, everything gets =
messy when you try to be formal and start seeing the border cases.)
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

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


--Apple-Mail-61-198207949
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMjEwMjQx
M1owIwYJKoZIhvcNAQkEMRYEFIIp1AmBTTd16UlhBDnZeuv45gt/MIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAHyAg+zmz+ogd5cDpF9lbFs8SvKx1AEGUNYK9WjbiO8NOb0V2c+VI0yj
gASx6W6NXhOdt9H0x/weoZ+Ldsc9ScE6ywqCbWJh01Fl0jt9c4bF/ZG9jCZxByuiO45myX1S7wWw
+sm20/qGcxt/Y8xlWtg7e/DFEyEHw14afIwW/AvL6mdmwSruniW/Es9zZcHarIKR91qx5o819NnC
tkJgSRrxAUb0qpwi7naiy8QiSmkvwuwgKc0brXKQZ5ciuwsBAVIS/4J3zlDRJ7aZqICOBVHIqqIU
nwbzhSffwtq11VQpj/pHwyDqOP1mep0Tl1Y+nFrc04i61q/Qu+dO/RtnjNwAAAAAAAA=

--Apple-Mail-61-198207949--

From zach@sensinode.com  Fri Oct 22 03:38:00 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E75D3A68E6 for ; Fri, 22 Oct 2010 03:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.363
X-Spam-Level: 
X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=0.236,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EXhHoYs2eDS for ; Fri, 22 Oct 2010 03:37:25 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D61343A68E8 for ; Fri, 22 Oct 2010 03:36:42 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9MAc7MN019824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Oct 2010 13:38:09 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-62-199043308; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Fri, 22 Oct 2010 13:38:08 +0300
Message-Id: 
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org> 
To: Robert Quattlebaum 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 10:38:00 -0000

--Apple-Mail-62-199043308
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 22, 2010, at 3:40 AM, Robert Quattlebaum wrote:

>> PS.: Do we really want to have a range option?  I don't think so.  I =
think we'll need a really convincing usage scenario to make that case.
>=20
> As I said earlier, I named it "Range" because it seemed to be =
descriptive of what I was using it for, but the name isn't really =
important: what's important is what it does. Here was the goals I was =
trying to accomplish with the Range option:
>=20
> 	* Provide a way for the client to influence the chunking =
threshold that the server uses.
> 	* Provide a way for the client to associate an asynchronous =
response with the GET request.

This is what a Token is for already.

> 	* Enable random access for GET requests, when supported by the =
server. (Kind of a bonus, as least as far as this spec is concerned)

Now this is an interesting case. Do we want to enable random access to a =
resource? When does random access make sense? At first I was thinking =
that this could be used as a way to recover from the failure of GETs on =
some blocks if you are requesting multiple blocks in parallel. However, =
with the opaque model, you could still do this if the client would keep =
some state on the opaque tags for open requests.=20

> In my proposal, the server would optionally include a range option in =
GET responses (except async responses, where they were required) for =
debugging purposes.

Token can be used for this?

>=20
> I used the option heavily in the PUT and POST cases, but this could be =
easily avoided by only using the "opaque" block option---since that =
alone would allow the server to keep track of the transfer in a =
stateless fashion and the client is most likely stateful anyway. If the =
client really does want to (somehow) be stateless in such a case, it can =
preserve its state using the Token option.

Yep.

Zach

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


--Apple-Mail-62-199043308
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMjEwMzgw
OFowIwYJKoZIhvcNAQkEMRYEFEpuJseUg/KV2/bkoD8ktI5SqSlRMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBADl5jIuDxTbecVJCzhRt9aoR9Sdl5lDnImh5TJV3BspzbTYlekuxZNBR
ZPYa4/aGzTwlVDNnmLhy45Q8ZkZHoutk8Aguhl2X/kjFuCcp/Vxwa9WL/fKGONQszuEPXRw3+M5m
UV4XcFffF0JbOTfdtxdLokzc9t+A7Gv/sh1H9WUO5aV/4zIdch/LUe/7oOq5gXbpUfkFGICSV6Vn
/yuUEU1+bnikeHH/6n5Lzb0Iy+ZifKGMdzo8lZuehlXzl+aRGyxm1Zsi3e4QJnkWdVGgz6aKC1j4
xFOmV1/YUBWqA3BEVp0NWP7qg4h7GaahiwJT03DWqfke/rokfLxUn0ZALs8AAAAAAAA=

--Apple-Mail-62-199043308--

From pab@peoplepowerco.com  Fri Oct 22 03:50:26 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BA73A68C3 for ; Fri, 22 Oct 2010 03:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.327,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAUONi7A4o+f for ; Fri, 22 Oct 2010 03:50:25 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A40303A686A for ; Fri, 22 Oct 2010 03:50:24 -0700 (PDT)
Received: by bwz12 with SMTP id 12so1256161bwz.31 for ; Fri, 22 Oct 2010 03:52:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.62.209 with SMTP id y17mr1971958bkh.88.1287744721341; Fri, 22 Oct 2010 03:52:01 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Fri, 22 Oct 2010 03:52:01 -0700 (PDT)
In-Reply-To: <627ECE5B-9814-4E4A-8D2A-75F3165815FA@sensinode.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>   <8A8E24ED-B009-4D26-90FC-497BC34E5656@tzi.org> <627ECE5B-9814-4E4A-8D2A-75F3165815FA@sensinode.com>
Date: Fri, 22 Oct 2010 05:52:01 -0500
Message-ID: 
From: Peter Bigot 
To: Zach Shelby 
Content-Type: multipart/alternative; boundary=0016e6d26c92ad4c200493326eb5
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 10:50:26 -0000

--0016e6d26c92ad4c200493326eb5
Content-Type: text/plain; charset=ISO-8859-1

I simply meant that a CoAP end-point at the network level uses the same
mechanism to send and receive messages that may be requests or responses.
Unlike HTTP, where clients do not natively provide a service entry point,
thus causing the millions (billions?) of dollars worth of pain associated
with trying to do pub/sub or callbacks over HTTP for the last dozen years.

Is it not a fair constraint to say that a client that doesn't support
minimal server functionality is unable to transmit large resource
descriptions?  I think that's all it would take.  Being a server need not
require supporting resource discovery; the code footprint should be little
more than is required to support asynchronous responses.

I see this as an opportunity to simplify CoAP by removing this rather
artificial asymmetry, but if y'all think it's important to keep it, so be
it.

BTW: Please don't lose the MaximumSize option proposal just because my
symmetry comment didn't fly.  I believe that has independent value, solving
several problems: how clients influence size, how servers determine the need
to chunk, and how a client can get an estimate of the resource
representation size without retrieving it (HEAD functionality).

Peter

On Fri, Oct 22, 2010 at 5:14 AM, Zach Shelby  wrote:

> On Oct 22, 2010, at 1:04 PM, Carsten Bormann wrote:
>
> > On Oct 22, 2010, at 11:54, Peter Bigot wrote:
> >
> >> Unlike HTTP, CoAP can assume that each endpoint is capable of being both
> a server and a client.
> >
> > Is that so?
> > I don't know of any requirement of this sort so far.
> > (Maybe you mean something different with "client"/"server" here.)
>
> It is often the case that a server will also include client functionality
> (if supporting asynchronous responses or subscription, they require that you
> can initiate transactions), but not the other way around. You very well may
> have client-only implementations. Considering that we are dealing with
> constrained devices, we can't assume or require that they will implement
> both.
>
> Zach
>
> >
> > Gruesse, Carsten
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>

--0016e6d26c92ad4c200493326eb5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I simply meant that a CoAP end-point at the network level uses the same mec=
hanism to send and receive messages that may be requests or responses.=A0 U=
nlike HTTP, where clients do not natively provide a service entry point, th=
us causing the millions (billions?) of dollars worth of pain associated wit=
h trying to do pub/sub or callbacks over HTTP for the last dozen years.


Is it not a fair constraint to say that a client that doesn't suppo=
rt minimal server functionality is unable to transmit large resource descri=
ptions?=A0 I=20
think that's all it would take.=A0 Being a server need not require supp=
orting resource discovery; the code footprint should be little more than is=
 required to support asynchronous responses.

I see this as an opport=
unity to simplify CoAP by removing this rather artificial asymmetry, but if=
 y'all think it's important to keep it, so be it.


BTW: Please don't lose the MaximumSize option proposal just because=
 my symmetry comment didn't fly.=A0 I believe that has independent valu=
e, solving several problems: how clients influence size, how servers determ=
ine the need to chunk, and how a client can get an estimate of the resource=
 representation size without retrieving it (HEAD functionality).


Peter

On Fri, Oct 22, 2010 at 5:14 AM=
, Zach Shelby <z=
ach@sensinode.com> wrote:


On Oct 22, 2010, at 1:04 PM, Carsten Borm=
ann wrote:



> On Oct 22, 2010, at 11:54, Peter Bigot wrote:

>

>> Unlike HTTP, CoAP can assume that each endpoint is capable of bein=
g both a server and a client.

>

> Is that so?

> I don't know of any requirement of this sort so far.

> (Maybe you mean something different with "client"/"serv=
er" here.)




It is often the case that a server will also include client fun=
ctionality (if supporting asynchronous responses or subscription, they requ=
ire that you can initiate transactions), but not the other way around. You =
very well may have client-only implementations. Considering that we are dea=
ling with constrained devices, we can't assume or require that they wil=
l implement both.




Zach



>

> Gruesse, Carsten

>

> _______________________________________________

> core mailing list

> core@ietf.org

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



--

Zach Shelby, Chief Nerd, Sensinode Ltd.

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

http://6lowpan.net - M=
y book "6LoWPAN: The Wireless Embedded Internet"

Mobile: +358 40 7796297







--0016e6d26c92ad4c200493326eb5--

From zach@sensinode.com  Fri Oct 22 03:57:30 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B702D3A6834 for ; Fri, 22 Oct 2010 03:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.363
X-Spam-Level: 
X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=0.236,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvRkOC73Gc8N for ; Fri, 22 Oct 2010 03:57:28 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CA1A03A659B for ; Fri, 22 Oct 2010 03:57:27 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9MAwmD1022849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Oct 2010 13:58:48 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-63-200284429; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Fri, 22 Oct 2010 13:58:49 +0300
Message-Id: <63849857-95F4-4D50-A33E-F50A0E665F00@sensinode.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>  
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 10:57:30 -0000

--Apple-Mail-63-200284429
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Peter,=20

Thanks for trying to reconcile these, comments in-line. You and Robert =
do realize you'll have to help us edit this document  :-) Starts to look =
like a re-write soon if we go in this direction...

On Oct 22, 2010, at 12:54 PM, Peter Bigot wrote:

> How about the following to reconcile all this and restore both =
simplicity and orthogonality?  There are two independent proposals here =
(separated by a key concept), and both can be extensions to core CoAP.
>=20
> Size management:
>=20
> - Add an elective option MessageSize, which when used in a request =
encodes a one or two byte unsigned integer representing the maximum size =
of the CoAP (non-error) response message that should be sent to the =
client.  Give it a default value of 1152 or whatever.  Servers use this =
to determine whether the resource response can be sent in one message or =
needs to be chunked.  This use of the option appears only in requests.

Would that eliminate the current text describing what the maximum size =
of a CoAP message is? In reality the default of MessageSize would serve =
that purpose.

> - Add an error code TooLarge sent by the server when the =
representation to be sent to the client exceeds the size it has =
specified (or defaulted) and the server declines (for whatever reason) =
to pre-emptively chunk it.  The response message would use MessageSize =
to convey the total resource size to the client.  In this use, the value =
of the option might be larger than two bytes, if we feel it's reasonable =
for any CoAP resource to ever have a representation larger than 65535 =
bytes.

Considering that many client's have limited memory, it would be useful =
for a client to know how large a resource is before it starts to =
retrieve it. MessageSize could be a variable length uint.=20

>=20
> This eliminates the question of how the server determines whether it =
should use any multi-part response like the block option, and provides a =
facility for influencing chunking on inherently multi-part responses =
like Robert's use cases.
>=20
> A Comment on Symmetry:
>=20
> Unlike HTTP, CoAP can assume that each endpoint is capable of being =
both a server and a client.  This means we have the option of asymmetry: =
in particular if we have a mechanism for GET that allows multi-part =
transactions for large resource representations, we do not need to =
specify a related mechanism for PUT or POST if doing so is difficult.  =
What we do instead is define a content type representing a URI, and do a =
PUT/POST where the body is the URI that the server must in turn retrieve =
in order to get the actual content of the PUT/POST.  It might do so by =
sending an ACK to make the client's transaction asynchronous, retrieving =
the content from the client, then executing the operation.

Although I don't agree that we can assume all endpoints can act as a =
server and client, I do find some logic here though. It might make sense =
to limit the use of chunked requests for GET (although we still need to =
look at how hard PUT/POST actually are). Just because we would do that =
though, doesn't mean we need to build in a callback URI feature. This =
kind of interface belongs to the REST interface design of the =
application, not for the transfer protocol. If chunked transfers only =
are supported for GET, then REST interfaces will naturally be designed =
in that way. We have to be careful about designing too much into the =
transfer protocol.

> Chunked Retrievals:
>=20
> A requested resource may be larger than the client has requested, or =
may have a content-type that naturally supports chunking.  In either =
case, the server may choose to send the resource representation in =
pieces.

Considering that the chunked mode is optional, I would say the server =
MUST return the resource in one message if it is smaller than =
MessageSize. The WG was pretty clear in Maastricht that chunking should =
be an optional feature.

> It does so following essentially Robert's process.  A 206 Partial =
Content response messsage is sent, including an opaque PartialContentId =
option.  The client retrieves the next chunk by re-submitting the =
request but adding the PartialContentId option provided in the last =
chunk.  The final chunk includes a PartialContentId option of length =
zero.  All pieces use the same response code (206).  The value of the =
resource is the byte-wise catenation of the individual responses.

WFM

>=20
> Comments:
>=20
> - Functionally, PartialContentId is similar to HTTP's Content-Range, =
but does not reveal information other than whether the piece is the last =
chunk of the representation (is the option value length zero or not).  I =
don't think CoAP needs a Range option or anything that involves random =
access internal to a resource description.  If the resource has internal =
structure, provide a RESTful interface to it, e.g. sub-resources =
identified by the hierarchical path.

My only requirement for random access is to recover failed chunks. I =
think PartialContentId would be sufficient for doing that if the client =
keeps a little state on open requests (it has to anyways).

> - By accepting the asymmetry of chunking only for responses to GET, we =
always leave it up to the client whether it is willing to use a =
multi-part transaction, and to determine how large the chunks are.  If =
we push chunks at a server, we need a way for the server to say "Too =
big" or to try to get the client to stop.   CoAP's client/server =
symmetry makes that unnecessary.

We still need to think through the use of this with POST/PUT, although I =
do like the idea of keeping this as simple as possible.

Zach

>=20
> Peter
>=20
> On Thu, Oct 21, 2010 at 7:40 PM, Robert Quattlebaum =
 wrote:
> Hello Carsten!
>=20
> On Oct 21, 2010, at 3:21 PM, Carsten Bormann wrote:
>=20
> > Thought experiment: So how could "block" be changed to do this =
protocol?
>=20
> Ultimately that was the goal with my previous email, but for clarity =
sake I was referring to my proposal as the "Next" option. In reality the =
name of the options is immaterial. It could just as easily be named the =
block option, but I felt referring to it as such might be confusing.
>=20
> > -- the M bit would be deleted; the absence of a block option in a =
response (while a block option is present in the request) would indicate =
the last slice.
> > (This goes a bit against the self-describing aspect.)
>=20
> As long as the response code of the last response is 206 (Partial =
Content) instead of 200 (OK), the absence of the M bit doesn't make the =
protocol any less self-describing. If the response code were always 200, =
then there would be no way for the client to differentiate between a =
fully contained response and the last response of a chunked request. =
(e.g., 206 responses are always chunked, and the last chunk is denoted =
by the absence of a block option)
>=20
> > -- in all but the first slice, the client would echo the block =
option it got from the server in the previous slice (i.e., instead of "I =
want block 1 now" it would say "I have block 0 now, give me the next").  =
The server would then increment the block number (or do whatever it =
needs to do).  This gives the server more freedom in the way it encloses =
the block size in the option value (if it wants to be stateless but =
still offer a slice size choice); the current encoding would simply =
become one of many implementation strategies.
>=20
> Sounds great to me!
>=20
> > (Again, the message is now less self-describing than block was.)
>=20
> With the next option, all requests were self-describing as far as the =
server was concerned---but replies were not necessarily self-describing =
to the client. I anticipated that this wasn't a huge problem because if =
the client is keeping state then there is no longer a need for the =
response to be self-describing, as the TID would be adequate. (The TID =
is obviously not adequate in the case of an async response, which is why =
I required the range option to always be included for async responses)
>=20
> However, if a stateless client really needs to the responses to be =
self-describing, there is already a facility to do so: the Token option. =
The client could simply use the Token option to store the number of =
bytes it has received so far in the transfer. This would make all =
responses that the client would receive self-describing, at least to the =
client.
>=20
> > -- the slice size preferred by the client would be indicated outside =
the block option mechanism; we just had an exchange on that aspect.  =
(I'm not sure we want to conflate this with a range option, though.)
>=20
> I just picked the name "Range" for the option because it seemed to be =
so similar. We could easily use a different name to describe a suitably =
similar mechanism. Originally I was just going to re-use the block =
option because it seems to be encoding similar information, but I =
decided against this for the reasons described in my proposal.
>=20
> > After this transformation, the block option is pretty much identical =
to your next option; the option value is now entirely opaque to the =
client.
>=20
> Again, sounds great! While I think the other aspects of my proposal =
are still important, having this alone would be a huge win, IMHO.
>=20
> > Your proposal enhances this by modifying the response codes (which =
would probably need some more detail, as in contrast to HTTP we are not =
just using this for GET).
>=20
> I added the use of the 206 (Partial Response) and 100 (Continue) =
response codes to avoid some ambiguities, as well as to encourage more =
"RESTful" thinking of these sorts of transactions. A 200 code implies =
(to me anyway) that the response of the entire REST transaction is =
self-contained, whereas the other response codes indicate an ongoing =
REST transaction. But that's just me.
>=20
> > What do we gain?  A lot more flexibility.
> >
> > What do we lose?  The simplicity we had because we didn't have the =
flexibility (only 1/2 :-) here).
>=20
> While the new mechanism would certainly be less strict (and more =
flexible), did we really loose any simplicity? It seems to me that doing =
this actually makes implementations *more* simple.
>=20
> As you mentioned earlier, a server which implements the current =
mechanism could be very easily updated to support this new mechanism, =
likely by changing a single line. Zero additional complexity. The client =
would no longer be mutating the block option value before sending it =
back to the server, so this would make client implementations even more =
simple.
>=20
> > Maybe, to facilitate debugging tools, the document could still =
describe an encoding of the opaque slice identifier that looks like the =
current block option (slice number + slice size, minus M bit) as a =
suggested format for those cases where it happens to fit.
>=20
> This is effectively what the Range option contained, but with higher =
resolution.
>=20
> > PS.: Do we really want to have a range option?  I don't think so.  I =
think we'll need a really convincing usage scenario to make that case.
>=20
> As I said earlier, I named it "Range" because it seemed to be =
descriptive of what I was using it for, but the name isn't really =
important: what's important is what it does. Here was the goals I was =
trying to accomplish with the Range option:
>=20
>        * Provide a way for the client to influence the chunking =
threshold that the server uses.
>        * Provide a way for the client to associate an asynchronous =
response with the GET request.
>        * Enable random access for GET requests, when supported by the =
server. (Kind of a bonus, as least as far as this spec is concerned)
>=20
> In my proposal, the server would optionally include a range option in =
GET responses (except async responses, where they were required) for =
debugging purposes.
>=20
> I used the option heavily in the PUT and POST cases, but this could be =
easily avoided by only using the "opaque" block option---since that =
alone would allow the server to keep track of the transfer in a =
stateless fashion and the client is most likely stateful anyway. If the =
client really does want to (somehow) be stateless in such a case, it can =
preserve its state using the Token option.
>=20
> > PPS.: An empty block option might be another way to indicate the =
last slice, so we don't feel a need to change response codes.
>=20
> Why avoid using more descriptive response codes, especially when they =
are codes which are already used for the same thing in HTTP?
>=20
> __________________
> Robert Quattlebaum
> Jabber: darco@deepdarc.com
> eMail:  darco@deepdarc.com
> www:    http://www.deepdarc.com/
>=20
>=20
>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

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


--Apple-Mail-63-200284429
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMjEwNTg1
MFowIwYJKoZIhvcNAQkEMRYEFFfEZZuMyNoGg7Aio2sxcnGb4i9tMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAGCAWwQ2JS+Yy9LrkkPnLXrhQ9ngMIYoHcge6lp2shbjiFjqUvEm0jNI
i3Umezl8GQjVB2jLh9kdC0BE1zeflIxg2k66sM4E/pS48vXrPt4uGCM0uvNaMAHg5Y7y4J2930Es
x7AaivueLbRteFGM06EQrSUH5ffBBWmTEWITr9RPjijT1HDzU96altHNxOXZn2Ivs6pEvX1jYbbB
tPRaP5k7TT7bvBizioPlHyErGxYiCcESyljYVHBU26pWZQWP0SZOBIKHW9I8sWR1/BhlIt1bDVHm
3Er3aRTu+aGM/65iN9q1T7ioh/m0W+HQa4Xz6sGBe6GDSVMpJcTqi5IiCJ8AAAAAAAA=

--Apple-Mail-63-200284429--

From cabo@tzi.org  Fri Oct 22 04:59:49 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38913A68F2 for ; Fri, 22 Oct 2010 04:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.238
X-Spam-Level: 
X-Spam-Status: No, score=-106.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7N9olUfLrvU for ; Fri, 22 Oct 2010 04:59:49 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A17843A68EA for ; Fri, 22 Oct 2010 04:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9MC1EP2028926; Fri, 22 Oct 2010 14:01:15 +0200 (CEST)
Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CA203EE9; Fri, 22 Oct 2010 14:01:14 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <63849857-95F4-4D50-A33E-F50A0E665F00@sensinode.com>
Date: Fri, 22 Oct 2010 14:01:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>   <63849857-95F4-4D50-A33E-F50A0E665F00@sensinode.com>
To: Zach Shelby 
X-Mailer: Apple Mail (2.1081)
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 11:59:50 -0000

On Oct 22, 2010, at 12:58, Zach Shelby wrote:

> I would say the server MUST return the resource in one message if it =
is smaller than MessageSize

If MessageSize is a client option, that would force the server to use a =
size that doesn't make sense server-side.  How does the client get to =
choose a good messagesize without forcing the server to do something =
uncomfortable?  I still think this should be some kind of negotiation.

Gruesse, Carsten


From darco@deepdarc.com  Fri Oct 22 05:03:54 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3421D3A690C for ; Fri, 22 Oct 2010 05:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.083
X-Spam-Level: 
X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.182,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5Lr6+SZRrOp for ; Fri, 22 Oct 2010 05:03:53 -0700 (PDT)
Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 1008D3A6901 for ; Fri, 22 Oct 2010 05:03:53 -0700 (PDT)
Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:34060 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P9GNF-0007TA-2s; Fri, 22 Oct 2010 08:05:29 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Quattlebaum 
In-Reply-To: 
Date: Fri, 22 Oct 2010 05:05:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F51A9EA-0EDC-4A89-9679-BB548235DD7D@deepdarc.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>  
To: Zach Shelby 
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - spider.nocdirect.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - deepdarc.com
Cc: core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 12:03:54 -0000

Hello Zach!

On Oct 22, 2010, at 3:38 AM, Zach Shelby wrote:

> On Oct 22, 2010, at 3:40 AM, Robert Quattlebaum wrote:
>> 	* Enable random access for GET requests, when supported by the =
server. (Kind of a bonus, as least as far as this spec is concerned)
>=20
> Now this is an interesting case. Do we want to enable random access to =
a resource? When does random access make sense?

I'm just taking a stab in the dark with this one, but lets see where it =
goes.

Let's say we have an HTTP-CoAP proxy. An HTTP client makes a GET request =
to the proxy for a CoAP resource with a Range header. Without random =
access, the proxy would have to start retrieving the CoAP resource from =
the start until it gets to the requested offset---which may be =
inefficient. In such a case the HTTP-CoAP proxy would likely simply =
always return a full 200 response, ignoring the range header in the HTTP =
request.

Another possibility is where a constrained device is running some sort =
of compiled script which, due to resource limitations, is served by =
another CoAP node and never stored entirely locally. Random access would =
allow jumps to earlier parts of the compiled script without needing to =
restart the transfer from scratch. Thus without random access this =
scenario becomes unfeasible. (I say *compiled* script here because =
random access doesn't really help when jumping in a non-compiled script)

Do either of these cases sound compelling? The first case is a bit of a =
stretch, but the second case sounds like it may be interesting.=20

> At first I was thinking that this could be used as a way to recover =
from the failure of GETs on some blocks if you are requesting multiple =
blocks in parallel. However, with the opaque model, you could still do =
this if the client would keep some state on the opaque tags for open =
requests.=20

Not sure how you could request multiple blocks in parallel without =
implying random access, especially with an opaque model.

>> In my proposal, the server would optionally include a range option in =
GET responses (except async responses, where they were required) for =
debugging purposes.
>=20
> Token can be used for this?

Yes, but since you can't predict which responses will be asynchronous =
you will need to add a Token to every request you send out (which, IMHO, =
would be unfortunate). Mandating the range option in the async responses =
was a way to make them self-describing without any context.

__________________
Robert Quattlebaum
Jabber: darco@deepdarc.com
eMail:  darco@deepdarc.com
www:    http://www.deepdarc.com/




From darco@deepdarc.com  Fri Oct 22 05:33:43 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5F63A68ED for ; Fri, 22 Oct 2010 05:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level: 
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.161,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWp3hZwCJOYM for ; Fri, 22 Oct 2010 05:33:42 -0700 (PDT)
Received: from spider.nocdirect.com (spider.nocdirect.com [69.73.181.158]) by core3.amsl.com (Postfix) with ESMTP id 684693A68F7 for ; Fri, 22 Oct 2010 05:33:41 -0700 (PDT)
Received: from c-76-21-82-248.hsd1.ca.comcast.net ([76.21.82.248]:47348 helo=[172.30.96.30]) by spider.nocdirect.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P9Gq5-0001GL-GH; Fri, 22 Oct 2010 08:35:17 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Quattlebaum 
In-Reply-To: 
Date: Fri, 22 Oct 2010 05:35:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <47D1B769-EC2D-452C-882D-D40EF8C6FC2F@deepdarc.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>  
To: Peter Bigot 
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - spider.nocdirect.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - deepdarc.com
Cc: core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 12:33:43 -0000

Hello Peter!

On Oct 22, 2010, at 2:54 AM, Peter Bigot wrote:

> Size management:
>=20
> - Add an elective option MessageSize, which when used in a request =
encodes a one or two byte unsigned integer representing the maximum size =
of the CoAP (non-error) response message that should be sent to the =
client.  Give it a default value of 1152 or whatever.  Servers use this =
to determine whether the resource response can be sent in one message or =
needs to be chunked.  This use of the option appears only in requests.
>=20
> - Add an error code TooLarge sent by the server when the =
representation to be sent to the client exceeds the size it has =
specified (or defaulted) and the server declines (for whatever reason) =
to pre-emptively chunk it.  The response message would use MessageSize =
to convey the total resource size to the client.  In this use, the value =
of the option might be larger than two bytes, if we feel it's reasonable =
for any CoAP resource to ever have a representation larger than 65535 =
bytes.

Two quick observations:

A server may not be immediately able to reliably determine the entire =
size of the retrieved content in an efficient manner, so for the =
TooLarge case the "MessageSize" option should be RECOMMENDED.

Second, In the first case you are using MessageSize to convey the =
largest single CoAP message (header+options+payload) that the client is =
willing to accept. Sounds reasonable. However, in the second case you =
are using the same option to contain an entirely different value: the =
size of the fully retrieved content of the requested resource. Perhaps =
we could define two options with the same numerical option identifier: =
For requests, it would be a "Message-Size" (or, as I would prefer, =
"Max-Message-Size"), and for responses it would be a =
"Resource-Content-Size" or something similar. This way it is clear that =
the values of this option in these two contexts are not related in =
function.

__________________
Robert Quattlebaum
Jabber: darco@deepdarc.com
eMail:  darco@deepdarc.com
www:    http://www.deepdarc.com/




From pab@peoplepowerco.com  Fri Oct 22 06:54:49 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88F028C0EA for ; Fri, 22 Oct 2010 06:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.653
X-Spam-Level: 
X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.323,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2Ad56FW9Qbx for ; Fri, 22 Oct 2010 06:54:44 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 22E4528C0DD for ; Fri, 22 Oct 2010 06:54:39 -0700 (PDT)
Received: by bwz12 with SMTP id 12so1414152bwz.31 for ; Fri, 22 Oct 2010 06:56:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.63.137 with SMTP id b9mr2305474bki.18.1287755775802; Fri, 22 Oct 2010 06:56:15 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Fri, 22 Oct 2010 06:56:15 -0700 (PDT)
In-Reply-To: <63849857-95F4-4D50-A33E-F50A0E665F00@sensinode.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>   <63849857-95F4-4D50-A33E-F50A0E665F00@sensinode.com>
Date: Fri, 22 Oct 2010 08:56:15 -0500
Message-ID: 
From: Peter Bigot 
To: Zach Shelby 
Content-Type: multipart/alternative; boundary=001636c5ade7931ee204933501db
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 13:54:49 -0000

--001636c5ade7931ee204933501db
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 22, 2010 at 5:58 AM, Zach Shelby  wrote:

> Peter,
>
> Thanks for trying to reconcile these, comments in-line. You and Robert do
> realize you'll have to help us edit this document  :-) Starts to look like a
> re-write soon if we go in this direction...
>

Rewrite of which document?  core-coap or core-block?  I'd assumed core-coap
was pretty nearly frozen, but if not, let's do this.

 On Oct 22, 2010, at 12:54 PM, Peter Bigot wrote:
>
> > How about the following to reconcile all this and restore both simplicity
> and orthogonality?  There are two independent proposals here (separated by a
> key concept), and both can be extensions to core CoAP.
> >
> > Size management:
> >
> > - Add an elective option MessageSize, which when used in a request
> encodes a one or two byte unsigned integer representing the maximum size of
> the CoAP (non-error) response message that should be sent to the client.
>  Give it a default value of 1152 or whatever.  Servers use this to determine
> whether the resource response can be sent in one message or needs to be
> chunked.  This use of the option appears only in requests.
>
> Would that eliminate the current text describing what the maximum size of a
> CoAP message is? In reality the default of MessageSize would serve that
> purpose.
>

Only if this makes it into the CoAP base document, in which case it would
change that text (I believe the restriction from section 4 to fit in an IP
datagram should remain).  I propose that it should be a critical option if
it's in the base document, as failure to understand and respect it could
result in lost data.


> > - Add an error code TooLarge sent by the server when the representation
> to be sent to the client exceeds the size it has specified (or defaulted)
> and the server declines (for whatever reason) to pre-emptively chunk it.
>  The response message would use MessageSize to convey the total resource
> size to the client.  In this use, the value of the option might be larger
> than two bytes, if we feel it's reasonable for any CoAP resource to ever
> have a representation larger than 65535 bytes.
>
> Considering that many client's have limited memory, it would be useful for
> a client to know how large a resource is before it starts to retrieve it.
> MessageSize could be a variable length uint.
>

That was my assumption.  In requests, it need be no larger than 16 bits
(unless an IPv6 datagram can be larger than 65536 octets?).  In the response
it might require more bits.  We already (or used to) support the concept of
variable-length integers as header option values, so nothing special needed
here.

A client that doesn't know how big the resource is and just wants to find
out can send a request for it with a MessageSize of zero.  Unless the
resource has no representation (fits in zero bytes), the server would be
obliged to return an error message.  As I hinted in my wording, MessageSize
restrictions should not apply to error responses.  I don't want to get
started defining support for reassembling error messages.

>
> >
> > This eliminates the question of how the server determines whether it
> should use any multi-part response like the block option, and provides a
> facility for influencing chunking on inherently multi-part responses like
> Robert's use cases.
> >
> > A Comment on Symmetry:
> >
> > Unlike HTTP, CoAP can assume that each endpoint is capable of being both
> a server and a client.  This means we have the option of asymmetry: in
> particular if we have a mechanism for GET that allows multi-part
> transactions for large resource representations, we do not need to specify a
> related mechanism for PUT or POST if doing so is difficult.  What we do
> instead is define a content type representing a URI, and do a PUT/POST where
> the body is the URI that the server must in turn retrieve in order to get
> the actual content of the PUT/POST.  It might do so by sending an ACK to
> make the client's transaction asynchronous, retrieving the content from the
> client, then executing the operation.
>
> Although I don't agree that we can assume all endpoints can act as a server
> and client, I do find some logic here though. It might make sense to limit
> the use of chunked requests for GET (although we still need to look at how
> hard PUT/POST actually are). Just because we would do that though, doesn't
> mean we need to build in a callback URI feature. This kind of interface
> belongs to the REST interface design of the application, not for the
> transfer protocol. If chunked transfers only are supported for GET, then
> REST interfaces will naturally be designed in that way. We have to be
> careful about designing too much into the transfer protocol.
>

Yes; sorry I said "can assume" instead of "could assume" ;-)

Yes, it's exactly that all this can be done at the REST level.  Callback URI
support does not require anything special from CoAP.


>
> > Chunked Retrievals:
> >
> > A requested resource may be larger than the client has requested, or may
> have a content-type that naturally supports chunking.  In either case, the
> server may choose to send the resource representation in pieces.
>
> Considering that the chunked mode is optional, I would say the server MUST
> return the resource in one message if it is smaller than MessageSize. The WG
> was pretty clear in Maastricht that chunking should be an optional feature.
>

I agree with Carsten that the server should have the right to decline the
size if it knows something the client doesn't.  Carsten may or may not agree
with me that, if it does so, it should deny the request with TooLarge rather
than automatically switch to some chunking protocol.

Small mess here: if the server declines the proposed fragment size, but the
representation is larger than the proposed fragment size, there's currently
no mechanism for the server to suggest an acceptable fragment size.  I
propose that, in that situation, the server reject with TooLarge, and the
client re-submit with the options that enable the chunking protocol.  The
chunking protocol in turn should explicitly allow the server to use a
smaller fragment than the client suggests.


> > It does so following essentially Robert's process.  A 206 Partial Content
> response messsage is sent, including an opaque PartialContentId option.  The
> client retrieves the next chunk by re-submitting the request but adding the
> PartialContentId option provided in the last chunk.  The final chunk
> includes a PartialContentId option of length zero.  All pieces use the same
> response code (206).  The value of the resource is the byte-wise catenation
> of the individual responses.
>
> WFM
>
> >
> > Comments:
> >
> > - Functionally, PartialContentId is similar to HTTP's Content-Range, but
> does not reveal information other than whether the piece is the last chunk
> of the representation (is the option value length zero or not).  I don't
> think CoAP needs a Range option or anything that involves random access
> internal to a resource description.  If the resource has internal structure,
> provide a RESTful interface to it, e.g. sub-resources identified by the
> hierarchical path.
>
> My only requirement for random access is to recover failed chunks. I think
> PartialContentId would be sufficient for doing that if the client keeps a
> little state on open requests (it has to anyways).
>

This works fine if it's necessary for the client to re-transmit a request
because the server didn't receive it.

It doesn't work so fine if the server received it, updated things, and its
response (with a new PartialContentId) was lost.  If it has to be robust in
that situation, this rules out the use of a constant PartialContentId that
the server treats as a "Next" indicator rather than encoding segment
identification information.

Either PartialContentId must contain the complete (opaque) state required
for the server to reconstruct the current position (the REST-ful, but
possibly inefficient, way), or the server must encode segment identification
information in the PartialContentId and further be able to reconstruct
earlier messages.  This might not be possible in an on-demand generation
situation, in which case we need a CantRecreate error.

Also need an error for garbled PartialContentId content.


> > - By accepting the asymmetry of chunking only for responses to GET, we
> always leave it up to the client whether it is willing to use a multi-part
> transaction, and to determine how large the chunks are.  If we push chunks
> at a server, we need a way for the server to say "Too big" or to try to get
> the client to stop.   CoAP's client/server symmetry makes that unnecessary.
>
> We still need to think through the use of this with POST/PUT, although I do
> like the idea of keeping this as simple as possible.
>

I look forward to seeing somebody's proposal.

I suspect that just defining chunk support for GET would make the code
footprint of a full implementation noticeably smaller than one that also had
to support a distinct PUT/PUSH chunking solution.


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

--001636c5ade7931ee204933501db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Oct 22, 2010 at 5:58 AM, Zach Shelby <zach@sensinode.com=
> wrote:

Peter,



Thanks for trying to reconcile these, comments in-line. You and Robert do r=
ealize you'll have to help us edit this document =A0:-) Starts to look =
like a re-write soon if we go in this direction...


Rewrite of which document?=A0 core-coap or core-block?=A0 I'd assum=
ed core-coap was pretty nearly frozen, but if not, let's do this.




On Oct 22, 2010, at 12:54 PM, Peter Bigot wrote:



> How about the following to reconcile all this and restore both simplic=
ity and orthogonality? =A0There are two independent proposals here (separat=
ed by a key concept), and both can be extensions to core CoAP.

>

> Size management:

>

> - Add an elective option MessageSize, which when used in a request enc=
odes a one or two byte unsigned integer representing the maximum size of th=
e CoAP (non-error) response message that should be sent to the client. =A0G=
ive it a default value of 1152 or whatever. =A0Servers use this to determin=
e whether the resource response can be sent in one message or needs to be c=
hunked. =A0This use of the option appears only in requests.





Would that eliminate the current text describing what the maximum siz=
e of a CoAP message is? In reality the default of MessageSize would serve t=
hat purpose.

Only if this makes it into the CoAP b=
ase document, in which case it would change that text (I believe the restri=
ction from section 4 to fit in an IP datagram should remain).=A0 I propose =
that it should be a critical option if it's in the base document, as fa=
ilure to understand and respect it could result in lost data.

=A0

> - Add an error code TooLarge sent by the server when the representatio=
n to be sent to the client exceeds the size it has specified (or defaulted)=
 and the server declines (for whatever reason) to pre-emptively chunk it. =
=A0The response message would use MessageSize to convey the total resource =
size to the client. =A0In this use, the value of the option might be larger=
 than two bytes, if we feel it's reasonable for any CoAP resource to ev=
er have a representation larger than 65535 bytes.





Considering that many client's have limited memory, it would be u=
seful for a client to know how large a resource is before it starts to retr=
ieve it. MessageSize could be a variable length uint.



That was my assumption.=A0 In requests, it need be no larger than =
16 bits (unless an IPv6 datagram can be larger than 65536 octets?).=A0 In t=
he response it might require more bits.=A0 We already (or used to) support =
the concept of variable-length integers as header option values, so nothing=
 special needed here.


A client that doesn't know how big the resource is and just wants t=
o find out can send a request for it with a MessageSize of zero.=A0 Unless =
the resource has no representation (fits in zero bytes), the server would b=
e obliged to return an error message.=A0 As I hinted in my wording, Message=
Size restrictions should not apply to error responses.=A0 I don't want =
to get started defining support for reassembling error messages.






>

> This eliminates the question of how the server determines whether it s=
hould use any multi-part response like the block option, and provides a fac=
ility for influencing chunking on inherently multi-part responses like Robe=
rt's use cases.


>

> A Comment on Symmetry:

>

> Unlike HTTP, CoAP can assume that each endpoint is capable of being bo=
th a server and a client. =A0This means we have the option of asymmetry: in=
 particular if we have a mechanism for GET that allows multi-part transacti=
ons for large resource representations, we do not need to specify a related=
 mechanism for PUT or POST if doing so is difficult. =A0What we do instead =
is define a content type representing a URI, and do a PUT/POST where the bo=
dy is the URI that the server must in turn retrieve in order to get the act=
ual content of the PUT/POST. =A0It might do so by sending an ACK to make th=
e client's transaction asynchronous, retrieving the content from the cl=
ient, then executing the operation.





Although I don't agree that we can assume all endpoints can act a=
s a server and client, I do find some logic here though. It might make sens=
e to limit the use of chunked requests for GET (although we still need to l=
ook at how hard PUT/POST actually are). Just because we would do that thoug=
h, doesn't mean we need to build in a callback URI feature. This kind o=
f interface belongs to the REST interface design of the application, not fo=
r the transfer protocol. If chunked transfers only are supported for GET, t=
hen REST interfaces will naturally be designed in that way. We have to be c=
areful about designing too much into the transfer protocol.



Yes; sorry I said "can assume" instead of &=
quot;could assume" ;-)

Yes, it's exactly that all this can =
be done at the REST level.=A0 Callback URI support does not require anythin=
g special from CoAP.

=A0




> Chunked Retrievals:

>

> A requested resource may be larger than the client has requested, or m=
ay have a content-type that naturally supports chunking. =A0In either case,=
 the server may choose to send the resource representation in pieces.





Considering that the chunked mode is optional, I would say the server=
 MUST return the resource in one message if it is smaller than MessageSize.=
 The WG was pretty clear in Maastricht that chunking should be an optional =
feature.



I agree with Carsten that the server should have the =
right to decline the size if it knows something the client doesn't.=A0 =
Carsten may or may not agree with me that, if it does so, it should deny th=
e request with TooLarge rather than automatically switch to some chunking p=
rotocol.


Small mess here: if the server declines the proposed fragment size, but=
 the representation is larger than the proposed fragment size, there's =
currently no mechanism for the server to suggest an acceptable fragment siz=
e.=A0 I propose that, in that situation, the server reject with TooLarge, a=
nd the client re-submit with the options that enable the chunking protocol.=
=A0 The chunking protocol in turn should explicitly allow the server to use=
 a smaller fragment than the client suggests.




> It does so following essentially Robert's process. =A0A 206 Partia=
l Content response messsage is sent, including an opaque PartialContentId o=
ption. =A0The client retrieves the next chunk by re-submitting the request =
but adding the PartialContentId option provided in the last chunk. =A0The f=
inal chunk includes a PartialContentId option of length zero. =A0All pieces=
 use the same response code (206). =A0The value of the resource is the byte=
-wise catenation of the individual responses.





WFM




>

> Comments:

>

> - Functionally, PartialContentId is similar to HTTP's Content-Rang=
e, but does not reveal information other than whether the piece is the last=
 chunk of the representation (is the option value length zero or not). =A0I=
 don't think CoAP needs a Range option or anything that involves random=
 access internal to a resource description. =A0If the resource has internal=
 structure, provide a RESTful interface to it, e.g. sub-resources identifie=
d by the hierarchical path.





My only requirement for random access is to recover failed chunks. I =
think PartialContentId would be sufficient for doing that if the client kee=
ps a little state on open requests (it has to anyways).



This works fine if it's necessary for the client to re-transmi=
t a request because the server didn't receive it.

It doesn't=
 work so fine if the server received it, updated things, and its response (=
with a new PartialContentId) was lost.=A0 If it has to be robust in that si=
tuation, this rules out the use of a constant PartialContentId that the ser=
ver treats as a "Next" indicator rather than encoding segment ide=
ntification information.


Either PartialContentId must contain the complete (opaque) state requir=
ed for the server to reconstruct the current position (the REST-ful, but po=
ssibly inefficient, way), or the server must encode segment identification =
information in the PartialContentId and further be able to reconstruct earl=
ier messages.=A0 This might not be possible in an on-demand generation situ=
ation, in which case we need a CantRecreate error.


Also need an error for garbled PartialContentId content.

<=
blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



> - By accepting the asymmetry of chunking only for responses to GET, we=
 always leave it up to the client whether it is willing to use a multi-part=
 transaction, and to determine how large the chunks are. =A0If we push chun=
ks at a server, we need a way for the server to say "Too big" or =
to try to get the client to stop. =A0 CoAP's client/server symmetry mak=
es that unnecessary.





We still need to think through the use of this with POST/PUT, althoug=
h I do like the idea of keeping this as simple as possible.

I look forward to seeing somebody's proposal.

I suspec=
t that just defining chunk support for GET would make the code footprint of=
 a full implementation noticeably smaller than one that also had to support=
 a distinct PUT/PUSH chunking solution.

=A0



Zach




--

Zach Shelby, Chief Nerd, Sensinode Ltd.

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

http://6lowpan.net - M=
y book "6LoWPAN: The Wireless Embedded Internet"

Mobile: +358 40 7796297







--001636c5ade7931ee204933501db--

From pab@peoplepowerco.com  Fri Oct 22 06:56:04 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD97228C0DD for ; Fri, 22 Oct 2010 06:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level: 
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.318,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDhZ1W7TtN3Y for ; Fri, 22 Oct 2010 06:56:03 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2B4AD28C0D8 for ; Fri, 22 Oct 2010 06:56:03 -0700 (PDT)
Received: by bwz12 with SMTP id 12so1415407bwz.31 for ; Fri, 22 Oct 2010 06:57:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.58.74 with SMTP id f10mr1332795bkh.161.1287755858661; Fri, 22 Oct 2010 06:57:38 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Fri, 22 Oct 2010 06:57:38 -0700 (PDT)
In-Reply-To: <47D1B769-EC2D-452C-882D-D40EF8C6FC2F@deepdarc.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>   <47D1B769-EC2D-452C-882D-D40EF8C6FC2F@deepdarc.com>
Date: Fri, 22 Oct 2010 08:57:38 -0500
Message-ID: 
From: Peter Bigot 
To: Robert Quattlebaum 
Content-Type: multipart/alternative; boundary=001636c5b6c383552e049335061d
Cc: core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 13:56:04 -0000

--001636c5b6c383552e049335061d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 22, 2010 at 7:35 AM, Robert Quattlebaum wrote:

> Hello Peter!
>
> On Oct 22, 2010, at 2:54 AM, Peter Bigot wrote:
>
> > Size management:
> >
> > - Add an elective option MessageSize, which when used in a request
> encodes a one or two byte unsigned integer representing the maximum size of
> the CoAP (non-error) response message that should be sent to the client.
>  Give it a default value of 1152 or whatever.  Servers use this to determine
> whether the resource response can be sent in one message or needs to be
> chunked.  This use of the option appears only in requests.
> >
> > - Add an error code TooLarge sent by the server when the representation
> to be sent to the client exceeds the size it has specified (or defaulted)
> and the server declines (for whatever reason) to pre-emptively chunk it.
>  The response message would use MessageSize to convey the total resource
> size to the client.  In this use, the value of the option might be larger
> than two bytes, if we feel it's reasonable for any CoAP resource to ever
> have a representation larger than 65535 bytes.
>
> Two quick observations:
>
> A server may not be immediately able to reliably determine the entire size
> of the retrieved content in an efficient manner, so for the TooLarge case
> the "MessageSize" option should be RECOMMENDED.
>

Actually, I'd intended it as the server's best estimate of the total size of
the resource representation, which may not even be a valid message size when
coming from the client.  So recommended/mandatory is irrelevant; it's
informational.  I'm not sure whether the server has to guarantee that the
resource will fit within the limit.  If so, the option would be omitted if
the server can't determine an upper bound on the final representation size.


> Second, In the first case you are using MessageSize to convey the largest
> single CoAP message (header+options+payload) that the client is willing to
> accept. Sounds reasonable. However, in the second case you are using the
> same option to contain an entirely different value: the size of the fully
> retrieved content of the requested resource. Perhaps we could define two
> options with the same numerical option identifier: For requests, it would be
> a "Message-Size" (or, as I would prefer, "Max-Message-Size"), and for
> responses it would be a "Resource-Content-Size" or something similar. This
> way it is clear that the values of this option in these two contexts are not
> related in function.
>

I agree; we just have the legacy issue of trying to reduce the number of
header options that have to be recognized.  Are people are OK with saying
that, say, header option type 7 means "MaxMessageSize" on requests and
"ResourceRepresentationSize" on responses (including error responses)?


>
> __________________
> Robert Quattlebaum
> Jabber: darco@deepdarc.com
> eMail:  darco@deepdarc.com
> www:    http://www.deepdarc.com/
>
>
>
>

--001636c5b6c383552e049335061d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Oct 22, 2010 at 7:35 AM, Robert Quattleb=
aum <darco@deepd=
arc.com> wrote:

Hello Peter!




On Oct 22, 2010, at 2:54 AM, Peter Bigot wrote:



> Size management:

>

> - Add an elective option MessageSize, which when used in a request enc=
odes a one or two byte unsigned integer representing the maximum size of th=
e CoAP (non-error) response message that should be sent to the client. =A0G=
ive it a default value of 1152 or whatever. =A0Servers use this to determin=
e whether the resource response can be sent in one message or needs to be c=
hunked. =A0This use of the option appears only in requests.


>

> - Add an error code TooLarge sent by the server when the representatio=
n to be sent to the client exceeds the size it has specified (or defaulted)=
 and the server declines (for whatever reason) to pre-emptively chunk it. =
=A0The response message would use MessageSize to convey the total resource =
size to the client. =A0In this use, the value of the option might be larger=
 than two bytes, if we feel it's reasonable for any CoAP resource to ev=
er have a representation larger than 65535 bytes.





Two quick observations:



A server may not be immediately able to reliably determine the entire size =
of the retrieved content in an efficient manner, so for the TooLarge case t=
he "MessageSize" option should be RECOMMENDED.



Actually, I'd intended it as the server's best estimate of=
 the total size of the resource representation, which may not even be a val=
id message size when coming from the client.=A0 So recommended/mandatory is=
 irrelevant; it's informational.=A0 I'm not sure whether the server=
 has to guarantee that the resource will fit within the limit.=A0 If so, th=
e option would be omitted if the server can't determine an upper bound =
on the final representation size.


=A0

Second, In the first case you are using MessageSize to convey the largest s=
ingle CoAP message (header+options+payload) that the client is willing to a=
ccept. Sounds reasonable. However, in the second case you are using the sam=
e option to contain an entirely different value: the size of the fully retr=
ieved content of the requested resource. Perhaps we could define two option=
s with the same numerical option identifier: For requests, it would be a &q=
uot;Message-Size" (or, as I would prefer, "Max-Message-Size"=
), and for responses it would be a "Resource-Content-Size" or som=
ething similar. This way it is clear that the values of this option in thes=
e two contexts are not related in function.



I agree; we just have the legacy issue of trying to r=
educe the number of header options that have to be recognized.=A0 Are peopl=
e are OK with saying that, say, header option type 7 means "MaxMessage=
Size" on requests and "ResourceRepresentationSize" on respon=
ses (including error responses)?

=A0




__________________

Robert Quattlebaum

Jabber: darco@deepdarc.com

eMail: =A0darco@deepdarc.com

www: =A0 =A0http://w=
ww.deepdarc.com/











--001636c5b6c383552e049335061d--

From pab@peoplepowerco.com  Fri Oct 22 07:19:40 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5333A67DF for ; Fri, 22 Oct 2010 07:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.662
X-Spam-Level: 
X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=0.314,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afbJcbEvZiI8 for ; Fri, 22 Oct 2010 07:19:39 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D4EC928C0DD for ; Fri, 22 Oct 2010 07:19:38 -0700 (PDT)
Received: by gya6 with SMTP id 6so705954gya.31 for ; Fri, 22 Oct 2010 07:21:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.229.19 with SMTP id g19mr3534238mur.59.1287757275810; Fri, 22 Oct 2010 07:21:15 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Fri, 22 Oct 2010 07:21:15 -0700 (PDT)
Date: Fri, 22 Oct 2010 09:21:15 -0500
Message-ID: 
From: Peter Bigot 
To: core 
Content-Type: multipart/alternative; boundary=00504502dbccfb4eab0493355a1e
Subject: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 14:19:40 -0000

--00504502dbccfb4eab0493355a1e
Content-Type: text/plain; charset=ISO-8859-1

In the interests of continuing to promote this pattern of using call-back
URIs to simplify life, what do people think of the following alternative
observation paradigm:

Assume an observable resource is present at coap://server/observable, where
the authority denotes a unicast end-point.  GET works as usual.

Allow a node client to subscribe to this by POST to coap://server/observable
of a callback URI coap://client/observer along with a subscription duration
(zero to unsubscribe).  The semantics of this are that, until the
subscription expires, whenever the server changes the value of the resource
it PUTs the corresponding representation to the callback URI registered by
each observer (probably as a Non-Confirmable).

Enhancement: Extend the link description for this resource with a link
attribute "obs" the value of which is a URI-Reference that becomes a URI
like "coap://group/server/observable", where the authority denotes a
multicast group.  Whenever the server changes the value of the resource, in
addition to sending to subscribed unicast clients, it PUTs the value of the
resource in a CoAP message sent to the muticast address (and port from the
authority).  Subscribers are free to observe the resource by joining the
corresponding group and recognizing the "/server/observable" path.
Cooperative subscribers might respond to a GET of the multicast URI by
sending their cached representation; the requester can ignore all but the
first response, eliminating the need to combine multiple representations.

RESTful observation without change to the CoAP base protocol, needing
support in the link format only to enable discovery of a multicast alias for
efficient distribution of the resource to anonymous subscribers.

I think it's pretty cool.

Peter

--00504502dbccfb4eab0493355a1e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

In the interests of continuing to promote this pattern of using call-back U=
RIs to simplify life, what do people think of the following alternative obs=
ervation paradigm:

Assume an observable resource is present at coap:=
//server/observable, where the authority denotes a unicast end-point.=A0 GE=
T works as usual.


Allow a node client to subscribe to this by POST to coap://server/obser=
vable of a callback URI coap://client/observer along with a subscription du=
ration (zero to unsubscribe).=A0 The semantics of this are that, until the =
subscription expires, whenever the server changes the value of the resource=
 it PUTs the corresponding representation to the callback URI registered by=
 each observer (probably as a Non-Confirmable).


Enhancement: Extend the link description for this resource with a link =
attribute "obs" the value of which is a URI-Reference that become=
s a URI like "coap://group/server/observable", where the authorit=
y denotes a multicast group.=A0 Whenever the server changes the value of th=
e resource, in addition to sending to subscribed unicast clients, it PUTs t=
he value of the resource in a CoAP message sent to the muticast address (an=
d port from the authority).=A0 Subscribers are free to observe the resource=
 by joining the corresponding group and recognizing the "/server/obser=
vable" path.=A0 Cooperative subscribers might respond to a GET of the =
multicast URI by sending their cached representation; the requester can ign=
ore all but the first response, eliminating the need to combine multiple re=
presentations.


RESTful observation without change to the CoAP base protocol, needing s=
upport in the link format only to enable discovery of a multicast alias for=
 efficient distribution of the resource to anonymous subscribers.


I think it's pretty cool.

Peter



--00504502dbccfb4eab0493355a1e--

From peter.van.der.stok@philips.com  Fri Oct 22 07:32:21 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4BC28C0E7 for ; Fri, 22 Oct 2010 07:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.054
X-Spam-Level: 
X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=1.055,  BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZuNMsgEB-fH for ; Fri, 22 Oct 2010 07:32:12 -0700 (PDT)
Received: from DB3EHSOBE006.bigfish.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by core3.amsl.com (Postfix) with ESMTP id 2C49C3A6840 for ; Fri, 22 Oct 2010 07:32:12 -0700 (PDT)
Received: from mail37-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.8; Fri, 22 Oct 2010 14:33:49 +0000
Received: from mail37-db3 (localhost.localdomain [127.0.0.1])	by mail37-db3-R.bigfish.com (Postfix) with ESMTP id 935E14085E5; Fri, 22 Oct 2010 14:33:49 +0000 (UTC)
X-SpamScore: -44
X-BigFish: VPS-44(zz15d6O9251J9370J217bPzz1202hzz8275bh8275dh1033IL186Mz2dh2a8h61h)
X-Spam-TCS-SCL: 0:0
Received: from mail37-db3 (localhost.localdomain [127.0.0.1]) by mail37-db3 (MessageSwitch) id 1287758028310819_6678; Fri, 22 Oct 2010 14:33:48 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.246])	by mail37-db3.bigfish.com (Postfix) with ESMTP id 49B777A0050; Fri, 22 Oct 2010 14:33:48 +0000 (UTC)
Received: from NLHILEXE01.connect1.local (168.87.56.20) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.0.482.44; Fri, 22 Oct 2010 14:33:44 +0000
Received: from nlamsexh01.connect1.local (172.16.153.11) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 22 Oct 2010 16:33:46 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh01.connect1.local ([172.16.153.11]) with mapi; Fri, 22 Oct 2010 16:33:43 +0200
From: "Stok, Peter van der" 
To: Peter Bigot , core 
Date: Fri, 22 Oct 2010 16:33:41 +0200
Thread-Topic: [core] observation via callbacks
Thread-Index: Actx9Gh0Bwevmd5hRR+b78tJAiF54wAAM+ow
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, nl-NL
Content-Type: multipart/alternative; boundary="_000_B5584ABB89131542BEA01BFAF71A7387864CBDFA01NLCLUEXM03con_"
MIME-Version: 1.0
X-Reverse-DNS: smtpx.philips.com
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 14:32:21 -0000

--_000_B5584ABB89131542BEA01BFAF71A7387864CBDFA01NLCLUEXM03con_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Peter,

I must confess this description seems to come close to my na=EFve imaginati=
on of how battery-less sensors inform interested nodes.
However, the phrase
"Cooperative subscribers might respond to a GET of the multicast URI by sen=
ding their cached representation; the requester can ignore all but the firs=
t response, eliminating the need to combine multiple representations."
exceeds my parsing capabilities.
What is cooperative, cached representation, multiple representation, and wh=
y first and not last response?
Probably you already explained this in earlier mails, and pointing at the r=
elevant parts in those mails would help.

Greetings and thanks,

Peter

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Pet=
er Bigot
Sent: Friday 22 October 2010 16:21
To: core
Subject: [core] observation via callbacks

In the interests of continuing to promote this pattern of using call-back U=
RIs to simplify life, what do people think of the following alternative obs=
ervation paradigm:

Assume an observable resource is present at coap://server/observable, where=
 the authority denotes a unicast end-point.  GET works as usual.

Allow a node client to subscribe to this by POST to coap://server/observabl=
e of a callback URI coap://client/observer along with a subscription durati=
on (zero to unsubscribe).  The semantics of this are that, until the subscr=
iption expires, whenever the server changes the value of the resource it PU=
Ts the corresponding representation to the callback URI registered by each =
observer (probably as a Non-Confirmable).

Enhancement: Extend the link description for this resource with a link attr=
ibute "obs" the value of which is a URI-Reference that becomes a URI like "=
coap://group/server/observable", where the authority denotes a multicast gr=
oup.  Whenever the server changes the value of the resource, in addition to=
 sending to subscribed unicast clients, it PUTs the value of the resource i=
n a CoAP message sent to the muticast address (and port from the authority)=
.  Subscribers are free to observe the resource by joining the correspondin=
g group and recognizing the "/server/observable" path.  Cooperative subscri=
bers might respond to a GET of the multicast URI by sending their cached re=
presentation; the requester can ignore all but the first response, eliminat=
ing the need to combine multiple representations.

RESTful observation without change to the CoAP base protocol, needing suppo=
rt in the link format only to enable discovery of a multicast alias for eff=
icient distribution of the resource to anonymous subscribers.

I think it's pretty cool.

Peter

________________________________
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_B5584ABB89131542BEA01BFAF71A7387864CBDFA01NLCLUEXM03con_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear Peter,


 


I must confess this description seems to come close to my na=
=EFve imagination of how battery-less sensors inform interested nodes.=



However, the phrase



“Cooperative subscribers might respond to a GE=
T of the multicast URI by sending their cached representation; the requeste=
r can ignore all but the first response, eliminating the need to combine mu=
ltiple representations.”

exceeds my parsing capabilities.


What is cooperative, cached representation, multiple represe=
ntation, and why first and not last response?


Probably you already explained this in earlier mails, and po=
inting at the relevant parts in those mails would help.

 


Greetings and thanks,


 


Peter


 




From: core-bou=
nces@ietf.org [mailto:core-bounces@ietf.org]
On Behalf Of Peter Bigot

Sent: Friday 22 October 2010 16:21

To: core

Subject: [core] observation via callbacks




 


In the interests of c=
ontinuing to promote this pattern of using call-back URIs to simplify life,=
 what do people think of the following alternative observation paradigm:


Assume an observable resource is present at coap://server/observable, where=
 the authority denotes a unicast end-point.  GET works as usual.



Allow a node client to subscribe to this by POST to coap://server/observabl=
e of a callback URI coap://client/observer along with a subscription durati=
on (zero to unsubscribe).  The semantics of this are that, until the s=
ubscription expires, whenever the server
 changes the value of the resource it PUTs the corresponding representation=
 to the callback URI registered by each observer (probably as a Non-Confirm=
able).



Enhancement: Extend the link description for this resource with a link attr=
ibute "obs" the value of which is a URI-Reference that becomes a =
URI like "coap://group/server/observable", where the authority de=
notes a multicast group.  Whenever the server changes
 the value of the resource, in addition to sending to subscribed unicast cl=
ients, it PUTs the value of the resource in a CoAP message sent to the muti=
cast address (and port from the authority).  Subscribers are free to o=
bserve the resource by joining the corresponding
 group and recognizing the "/server/observable" path.  Coope=
rative subscribers might respond to a GET of the multicast URI by sending t=
heir cached representation; the requester can ignore all but the first resp=
onse, eliminating the need to combine multiple
 representations.



RESTful observation without change to the CoAP base protocol, needing suppo=
rt in the link format only to enable discovery of a multicast alias for eff=
icient distribution of the resource to anonymous subscribers.



I think it's pretty cool.



Peter







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_B5584ABB89131542BEA01BFAF71A7387864CBDFA01NLCLUEXM03con_--

From klaus.hartke@googlemail.com  Fri Oct 22 07:44:53 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C649C3A6918 for ; Fri, 22 Oct 2010 07:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptKcw0+hxYkg for ; Fri, 22 Oct 2010 07:44:52 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D5F603A66B4 for ; Fri, 22 Oct 2010 07:44:51 -0700 (PDT)
Received: by bwz12 with SMTP id 12so1460537bwz.31 for ; Fri, 22 Oct 2010 07:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=gijCri1rFmv4P2FxnnOO8S/O/dFdx+sdfjr4Kwf85IU=; b=cRwhF/VhjeR/zBqeFW188e5ZGkBMXW23FU4m/Uh81S4eZ2GAG/9NCD1RXdz0IOH2L3 2kF8SnPipMYoDK+86ivoXA7oU1SZ2B10c2Z8FznYSuxX3TUBBoSj2on1kaDx2PhJmBKH I79PgWfJ1an1S2NXr6StCl798upbAKqS6S88k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=rh40SZ3p8qBWeXxSAWmt6HMu88h0fdDV+w8u6O1wnHY7YkV0V7IK/1ZtR7n+JkfMBv nUQLqXIfXJ6fHILfM3Blx2GF1k2eGmuyFsYiVAbrhRfgVHpwgXs9YTWYOlzYgTqicYOf awD0BPBCBa70HrCjrFqcIgHIIEeZyREO/VXP0=
MIME-Version: 1.0
Received: by 10.204.117.212 with SMTP id s20mr2154402bkq.140.1287758788903; Fri, 22 Oct 2010 07:46:28 -0700 (PDT)
Sender: klaus.hartke@googlemail.com
Received: by 10.204.101.65 with HTTP; Fri, 22 Oct 2010 07:46:28 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 22 Oct 2010 16:46:28 +0200
X-Google-Sender-Auth: ad8BCKmOcyMIRHwyBSoYAgpRWTc
Message-ID: 
From: Klaus Hartke 
To: core 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 14:44:54 -0000

Peter Bigot:
> In the interests of continuing to promote this pattern of using call-back
> URIs to simplify life, what do people think of the following alternative
> observation paradigm:

It has some merits. But when Carsten and I discussed this during the
initial design of -observe, we came to the conclusion that a
notification and a PUT request are too different to be expressed with
the same message type.

Differences include:

- Who is the owner of the resource -- sender (notification) or receiver (PUT)

- What happens at proxies -- fanout to all subscribers (notification)
or pass-through to origin (PUT)

- What happens at caches -- update stored response (notification) or not (PUT)

- What are possible error conditions, etc.


Klaus

From pab@peoplepowerco.com  Fri Oct 22 07:48:04 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6123A692C for ; Fri, 22 Oct 2010 07:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC-5bmVaR+DH for ; Fri, 22 Oct 2010 07:48:01 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 451533A67DF for ; Fri, 22 Oct 2010 07:48:01 -0700 (PDT)
Received: by gya6 with SMTP id 6so737275gya.31 for ; Fri, 22 Oct 2010 07:49:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.221.5 with SMTP id y5mr1408438muq.122.1287758978271; Fri, 22 Oct 2010 07:49:38 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Fri, 22 Oct 2010 07:49:38 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 22 Oct 2010 09:49:38 -0500
Message-ID: 
From: Peter Bigot 
To: "Stok, Peter van der" 
Content-Type: multipart/alternative; boundary=0016367659eb74cf9d049335c057
Cc: core 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 14:48:04 -0000

--0016367659eb74cf9d049335c057
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

For previous details of my position concerning REST operations on URIs wher=
e
the authority is a multicast address, see:

http://www.ietf.org/mail-archive/web/core/current/msg00607.html
http://www.ietf.org/mail-archive/web/core/current/msg00745.html

The resource URI coap://group/server/observable is a distributed resource
that is intended to mirror the actual resource at coap://server/observable.

cooperative: Technically, the subscribers don't own the resource, so there'=
s
no obligation that they support a GET operation on it.  In any case, you ma=
y
not want all nodes to respond (to reduce the multicast storm).

cached representation: The representation of the cached resource value,
which may not be the current value as held at the actual resource owner.
(REST maintains distinctions between the resource and its representation in
a particular media type.)

multiple representations: The real resource represents a single value, e.g.
the string "ON".  A GET addressed to a multicast address is likely to
produce multiple representations, which ideally will all be "ON".  How thes=
e
multiple representations should be combined into a single representation is
a difficult question, discussed in the above emails.

first response: because the client in a normal CoAP GET operation expects t=
o
receive one response, which completes the transaction.  For this multicast
GET to work, the client need merely be robust in the presence of additional=
,
later responses, which it ignores.  ("Last" causes difficulty because when
do you decide that there are no more responses coming?)

Peter

On Fri, Oct 22, 2010 at 9:33 AM, Stok, Peter van der <
peter.van.der.stok@philips.com> wrote:

>  Dear Peter,
>
>
>
> I must confess this description seems to come close to my na=EFve imagina=
tion
> of how battery-less sensors inform interested nodes.
>
> However, the phrase
>
> =93Cooperative subscribers might respond to a GET of the multicast URI by
> sending their cached representation; the requester can ignore all but the
> first response, eliminating the need to combine multiple representations.=
=94
> exceeds my parsing capabilities.
>
> What is cooperative, cached representation, multiple representation, and
> why first and not last response?
>
> Probably you already explained this in earlier mails, and pointing at the
> relevant parts in those mails would help.
>
>
>
> Greetings and thanks,
>
>
>
> Peter
>
>
>
> *From:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf O=
f
> *Peter Bigot
> *Sent:* Friday 22 October 2010 16:21
> *To:* core
> *Subject:* [core] observation via callbacks
>
>
>
> In the interests of continuing to promote this pattern of using call-back
> URIs to simplify life, what do people think of the following alternative
> observation paradigm:
>
> Assume an observable resource is present at coap://server/observable, whe=
re
> the authority denotes a unicast end-point.  GET works as usual.
>
> Allow a node client to subscribe to this by POST to
> coap://server/observable of a callback URI coap://client/observer along w=
ith
> a subscription duration (zero to unsubscribe).  The semantics of this are
> that, until the subscription expires, whenever the server changes the val=
ue
> of the resource it PUTs the corresponding representation to the callback =
URI
> registered by each observer (probably as a Non-Confirmable).
>
> Enhancement: Extend the link description for this resource with a link
> attribute "obs" the value of which is a URI-Reference that becomes a URI
> like "coap://group/server/observable", where the authority denotes a
> multicast group.  Whenever the server changes the value of the resource, =
in
> addition to sending to subscribed unicast clients, it PUTs the value of t=
he
> resource in a CoAP message sent to the muticast address (and port from th=
e
> authority).  Subscribers are free to observe the resource by joining the
> corresponding group and recognizing the "/server/observable" path.
> Cooperative subscribers might respond to a GET of the multicast URI by
> sending their cached representation; the requester can ignore all but the
> first response, eliminating the need to combine multiple representations.
>
> RESTful observation without change to the CoAP base protocol, needing
> support in the link format only to enable discovery of a multicast alias =
for
> efficient distribution of the resource to anonymous subscribers.
>
> I think it's pretty cool.
>
> Peter
>
> ------------------------------
> 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 notif=
ied
> 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 cop=
ies
> of the original message.
>

--0016367659eb74cf9d049335c057
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

For previous details of my position concerning REST operations on URIs wher=
e the authority is a multicast address, see:

http://www.ietf.org/ma=
il-archive/web/core/current/msg00607.html

http://www.ietf.org/mail-archive/web/core/current/msg00745.html
The resource URI coap://group/server/observable is a distributed resource =
that is intended to mirror the actual resource at coap://server/observable.=



cooperative: Technically, the subscribers don't own the resource, s=
o there's no obligation that they support a GET operation on it.=A0 In =
any case, you may not want all nodes to respond (to reduce the multicast st=
orm).


cached representation: The representation of the cached resource value,=
 which may not be the current value as held at the actual resource owner.=
=A0 (REST maintains distinctions between the resource and its representatio=
n in a particular media type.)


multiple representations: The real resource represents a single value, =
e.g. the string "ON".=A0 A GET addressed to a multicast address i=
s likely to produce multiple representations, which ideally will all be &qu=
ot;ON".=A0 How these multiple representations should be combined into =
a single representation is a difficult question, discussed in the above ema=
ils.


first response: because the client in a normal CoAP GET operation expec=
ts to receive one response, which completes the transaction.=A0 For this mu=
lticast GET to work, the client need merely be robust in the presence of ad=
ditional, later responses, which it ignores.=A0 ("Last" causes di=
fficulty because when do you decide that there are no more responses coming=
?)


Peter

On Fri, Oct 22, 2010 at 9:33 AM=
, Stok, Peter van der <peter.van.der.stok@philips.com> wrote:
=













Dear Peter,


=A0


I must confess this description seems to come close to my na=EFve ima=
gination of how battery-less sensors inform interested nodes.


However, the phrase



=93Cooperative subscribers might respond to a GET of=
 the multicast URI by sending their cached representation; the requester ca=
n ignore all but the first response, eliminating the need to combine multip=
le representations.=94


exceeds my parsin=
g capabilities.


What is cooperative, cached representation, multiple representation, =
and why first and not last response?


Probably you already explained this in earlier mails, and pointing at=
 the relevant parts in those mails would help.


=A0


Greetings and thanks,


=A0


Peter


=A0




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

Sent: Friday 22 October 2010 16:21

To: core

Subject: [core] observation via callbacks




=A0


In the interests of c=
ontinuing to promote this pattern of using call-back URIs to simplify life,=
 what do people think of the following alternative observation paradigm:



Assume an observable resource is present at coap://server/observable, where=
 the authority denotes a unicast end-point.=A0 GET works as usual.



Allow a node client to subscribe to this by POST to coap://server/observabl=
e of a callback URI coap://client/observer along with a subscription durati=
on (zero to unsubscribe).=A0 The semantics of this are that, until the subs=
cription expires, whenever the server
 changes the value of the resource it PUTs the corresponding representation=
 to the callback URI registered by each observer (probably as a Non-Confirm=
able).



Enhancement: Extend the link description for this resource with a link attr=
ibute "obs" the value of which is a URI-Reference that becomes a =
URI like "coap://group/server/observable", where the authority de=
notes a multicast group.=A0 Whenever the server changes
 the value of the resource, in addition to sending to subscribed unicast cl=
ients, it PUTs the value of the resource in a CoAP message sent to the muti=
cast address (and port from the authority).=A0 Subscribers are free to obse=
rve the resource by joining the corresponding
 group and recognizing the "/server/observable" path.=A0 Cooperat=
ive subscribers might respond to a GET of the multicast URI by sending thei=
r cached representation; the requester can ignore all but the first respons=
e, eliminating the need to combine multiple
 representations.



RESTful observation without change to the CoAP base protocol, needing suppo=
rt in the link format only to enable discovery of a multicast alias for eff=
icient distribution of the resource to anonymous subscribers.



I think it's pretty cool.



Peter







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.










--0016367659eb74cf9d049335c057--

From klaus.hartke@googlemail.com  Fri Oct 22 08:00:35 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E65B28C126 for ; Fri, 22 Oct 2010 08:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFbJviD9HYp7 for ; Fri, 22 Oct 2010 08:00:34 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 88B5B3A6888 for ; Fri, 22 Oct 2010 08:00:28 -0700 (PDT)
Received: by bwz12 with SMTP id 12so1475380bwz.31 for ; Fri, 22 Oct 2010 08:02:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=aVYGMJKs0c19ylHuRanl5axua28WHv3wp/ms17R366I=; b=v/qKw2B7U7vkUtg2/VJWRpMypk7UnSwLYFMCgXjv2V0TL7V+H/8xAXCr/Quj5X/F9F uwHTDsHA/CwEeTCYNtvTy9MI7H7FCM8+I2juTsvbfQ7VTVzer2eY4Srgj2pM/9chvW46 rIKGQQfdXLQEbg33wofeUnnXGdYdelRmMUn88=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=PcV0CBkukHWlu9mVvbn3RHe0o0GLyT+iv4P5dSE1ZxGSkzfHRcJ8GR+y8OeWPwaUKY d8qC2KZgPYml+1jxSqqG3reUjiX19X3KBzg+S2yzLUDSz2AUNg31kdl0YXmS+g8gjWXY Ze4nOQYYYJ6xR2t74I7Yx/jLCW/vEFPMfqXDM=
MIME-Version: 1.0
Received: by 10.204.26.197 with SMTP id f5mr2217254bkc.74.1287759726082; Fri, 22 Oct 2010 08:02:06 -0700 (PDT)
Sender: klaus.hartke@googlemail.com
Received: by 10.204.101.65 with HTTP; Fri, 22 Oct 2010 08:02:06 -0700 (PDT)
In-Reply-To: <002d01cb7103$8b500970$a1f01c50$@uni-rostock.de>
References: <002d01cb7103$8b500970$a1f01c50$@uni-rostock.de>
Date: Fri, 22 Oct 2010 17:02:06 +0200
X-Google-Sender-Auth: AxNtb7OrD3zjvjjq9na8XCHvpS8
Message-ID: 
From: Klaus Hartke 
To: core 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [core] CoAP observe
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 15:00:35 -0000

Guido Moritz wrote:
> sifting through the draft-ietf-core-observe-00 I am missing some negotiation
> mechanisms for the notification endpoint. [...]
>
> I guess this should be added in the "Open Issues" section?!

Done.


Klaus

From pab@peoplepowerco.com  Fri Oct 22 08:22:46 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39263A67E6 for ; Fri, 22 Oct 2010 08:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level: 
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.306,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yh1qg0FX85q for ; Fri, 22 Oct 2010 08:22:45 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 0E9B63A66B4 for ; Fri, 22 Oct 2010 08:22:44 -0700 (PDT)
Received: by ewy27 with SMTP id 27so548153ewy.31 for ; Fri, 22 Oct 2010 08:24:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.213.30.20 with SMTP id s20mr415094ebc.16.1287761061496; Fri, 22 Oct 2010 08:24:21 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Fri, 22 Oct 2010 08:24:21 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 22 Oct 2010 10:24:21 -0500
Message-ID: 
From: Peter Bigot 
To: Klaus Hartke 
Content-Type: multipart/alternative; boundary=000e0cd1e32aa047810493363ca4
Cc: core 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 15:22:46 -0000

--000e0cd1e32aa047810493363ca4
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 22, 2010 at 9:46 AM, Klaus Hartke  wrote:

> Peter Bigot:
> > In the interests of continuing to promote this pattern of using call-back
> > URIs to simplify life, what do people think of the following alternative
> > observation paradigm:
>

Disclaimer: I have not changed my position that multicast with REST is an
ill-defined concept.  This proposal came from my accepting the position that
not everything CoAP enables has to be 100% consistent with REST.  Some of
what falls out from things like applying CoAP to multicast addresses is very
useful and worth adopting when REST is less important than efficiency.


> It has some merits. But when Carsten and I discussed this during the
> initial design of -observe, we came to the conclusion that a
> notification and a PUT request are too different to be expressed with
> the same message type.
>
> Differences include:
>
> - Who is the owner of the resource -- sender (notification) or receiver
> (PUT)
>

The real resource is the one identified by the URI with a unicast authority,
and it's owned by that authority.

The shadow resource identified by the URI with the multicast authority is a
distributed one, not really suitable for REST because there is no owner.  I
might say each subscriber is the owner of its cached copy.  PUTs work; GETs
are odd because the requester doesn't really know who the owner is, and you
end up with multiple (maybe inconsistent) representations.

Perhaps for completeness, each subscriber should make its copy available as
a distinct resource with a unicast URI, but I don't see that as being
particularly useful, except for a similar use in group communications.

- What happens at proxies -- fanout to all subscribers (notification)
> or pass-through to origin (PUT)
>

Recall that there are two URIs.  What's done depends on which one is used in
the REST operation.  I would suggest that the multicast URI should not be
used outside the link-local network segment, in which proxies are most
likely to be border nodes that also serve as routers.

A proxy receiving a PUT for the unicast URI would forward it (toward the
"owner"); one receiving a PUT for the distributed URI would also "forward"
(retransmit) it toward the subscribers, though it should not do so over the
link through which it was received.

- What happens at caches -- update stored response (notification) or not
> (PUT)
>

Same deal: Two URIs, two resources, depends on what the cache is for (e.g.,
is it integrated with a proxy).


> - What are possible error conditions, etc.
>

Dunno until somebody tries it.

CoAP enables you to send and receive messages on multicast addresses, and in
fact its charter requires that it perform certain operations that way.  That
doesn't mean that every aspect of a CoAP system including proxies and caches
needs to make sense when you do this.  But where it does make sense, we
might as well get some value out of it.

Peter


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

--000e0cd1e32aa047810493363ca4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Oct 22, 2010 at 9:46 AM, Klaus Hartke <hartke@tzi.org>=
; wrote:
> In the interests of continuing to promote this patte=
rn of using call-back

> URIs to simplify life, what do people think of the following alternati=
ve

> observation paradigm:
=A0
Disclai=
mer: I have not changed my position that multicast with REST is an ill-defi=
ned concept.=A0 This proposal came from my accepting the position that not =
everything CoAP enables has to be=20
100% consistent with REST.=A0 Some of what falls out from things like apply=
ing CoAP to multicast addresses is very useful and worth adopting when REST=
 is less important=20
than efficiency.
=A0


It has some merits. But when Carsten and I discussed this during the<=
br>
initial design of -observe, we came to the conclusion that a

notification and a PUT request are too different to be expressed with

the same message type.



Differences include:



- Who is the owner of the resource -- sender (notification) or receiver (PU=
T)

The real resource is the one identified by the =
URI with a unicast authority, and it's owned by that authority.


The shadow resource identified by the URI with the multicast authority =
is a distributed one, not really suitable for REST because there is no owne=
r.=A0 I might say each subscriber is the owner of its cached copy.=A0 PUTs =
work; GETs are odd because the requester doesn't really know who the ow=
ner is, and you end up with multiple (maybe inconsistent) representations.<=
br>

Perhaps for completeness, each subscriber should make its copy availabl=
e
 as a distinct resource with a unicast URI, but I don't see that as=20
being particularly useful, except for a similar use in group communications=
.


- What happens at proxies -- fanout to all subscribers (notification)

or pass-through to origin (PUT)

Recall that there =
are two URIs.=A0 What's done depends on which one is used in the REST o=
peration.=A0 I would suggest that the multicast URI should not be used outs=
ide the=20
link-local network segment, in which proxies are most likely to be=20
border nodes that also serve as routers.


A proxy receiving a PUT for the unicast URI would forward it (toward th=
e "owner"); one receiving a PUT for the distributed URI would als=
o "forward" (retransmit) it toward the subscribers, though it sho=
uld not do so over the link through which it was received.




- What happens at caches -- update stored response (notification) or not (P=
UT)

Same deal: Two URIs, two resources, depends on=
 what the cache is for (e.g., is it integrated with a proxy).
=A0



- What are possible error conditions, etc.

Dunno u=
ntil somebody tries it.

CoAP enables you to send and receive message=
s on multicast addresses, and in fact its charter requires that it perform =
certain operations that way.=A0 That doesn't mean that every aspect of =
a CoAP system including proxies and caches needs to make sense when you do =
this.=A0 But where it does make sense, we might as well get some value out =
of it.


Peter




Klaus

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--000e0cd1e32aa047810493363ca4--

From darco@deepdarc.com  Fri Oct 22 10:43:46 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5923A6948 for ; Fri, 22 Oct 2010 10:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyP6Rj2gWJ9x for ; Fri, 22 Oct 2010 10:43:45 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id A2DEC28C0E8 for ; Fri, 22 Oct 2010 10:43:43 -0700 (PDT)
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id CF80BB7747D1; Fri, 22 Oct 2010 10:44:42 -0700 (PDT)
X-AuditID: 11807130-b7b53ae0000049b6-2a-4cc1cd8a217c
Received: from bellatrix.apple.com (bellatrix.apple.com [17.197.13.66]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 55.98.18870.A8DC1CC4; Fri, 22 Oct 2010 10:44:42 -0700 (PDT)
From: Robert Quattlebaum 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 22 Oct 2010 10:44:42 -0700
To: core 
Message-Id: <14612E85-3B60-49C9-803A-D530A106B0DB@deepdarc.com>
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Subject: [core] Event Cascade Loops
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 17:43:46 -0000

I just wanted to bring up a potential problem and a proposed solution.

If CoAP devices can issue requests to other CoAP devices as a direct =
response of it itself receiving a request (what I call a "cascade") it =
becomes possible for infinite loops to be created. This is obviously a =
bad thing.

My proposed solution would involve a new header option, which at the =
moment I will refer to as the "cascade-count" option. The cascade-count =
option is only added to an outbound request if that request was spawned =
by a previous inbound request. The rules are as follows:

	* If the inbound request does not have a cascade-count, the =
value of the cascade count in the outbound request is set to '128'.
	* If the inbound request has a cascade-count, then the that =
value minus one is set as the cascade-count of the outbound request.=20
	* If the inbound request has a cascade-count of zero, then no =
outbound requests are allowed.=20

Note that this is different than a "hop" count because we aren't =
tracking any particular set of data---we are tracking a cascade of =
events. The option itself would be elective, but if adopted should be =
REQUIRED to be supported and used by any node where an inbound request =
could automatically trigger automatic outbound requests.

This capability would be very important for Peter's "observation via =
callbacks" idea. Resources changed by external requests should trigger =
callbacks with a cascade-count. Without this option, or a similar =
mechanism, an infinite cascade loop would likely continue until some or =
all of the devices in the loop are power-cycled (or the configuration =
was changed to prevent the loop).

Thoughts?

__________________
Robert Quattlebaum
Jabber: darco@deepdarc.com
eMail:  darco@deepdarc.com
www:    http://www.deepdarc.com/




From klaus.hartke@googlemail.com  Fri Oct 22 11:15:37 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20373A6956 for ; Fri, 22 Oct 2010 11:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRRxHt7bAeZa for ; Fri, 22 Oct 2010 11:15:36 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 894EE3A6899 for ; Fri, 22 Oct 2010 11:15:31 -0700 (PDT)
Received: by bwz12 with SMTP id 12so1659272bwz.31 for ; Fri, 22 Oct 2010 11:17:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=acnEl/jT2k1L3MrGA0MbnX5J3VRnwOSV5KkbviHzL5g=; b=h3neuZkj1q39iz6MT1gMP+bl8/FZZxQs+gV5e/ThgLqLnF7bAC+IRwgDJvEodCXYKU oiO3bDKzjVltxEIW9D/BBHPaYRmMuzt960HCDe2hYOje03kvrTRfmgwovy5co2nrfD/u alknKRk3Ylz1Fk1OopI43lZFNLXgeWIPMQ2ow=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=Csyt2pHnS7A6Xm8kU98Xj0gVTlGcIggTB7d7faXqF4jee7Y8DVO7H512J8HXobLToY rZiCdABeuR9+P19d+ZIWNRbYK9d70f1uxQgFjBqSPoJazAeZsqv3qYCxrySNYrtKSWH/ f5Jlv3P+utICX6iQFp1pwWQHUJqETOQlvNkKg=
MIME-Version: 1.0
Received: by 10.204.117.199 with SMTP id s7mr2584748bkq.15.1287771419998; Fri, 22 Oct 2010 11:16:59 -0700 (PDT)
Sender: klaus.hartke@googlemail.com
Received: by 10.204.101.65 with HTTP; Fri, 22 Oct 2010 11:16:59 -0700 (PDT)
In-Reply-To: 
References:   
Date: Fri, 22 Oct 2010 20:16:59 +0200
X-Google-Sender-Auth: uBxQcuzJjJJHie6UbNqAj1MZvKA
Message-ID: 
From: Klaus Hartke 
To: core 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 18:15:38 -0000

I think the question is, basically: What do we subscribe to an
observable resource, and how does an observer relate a notification to
a subscription or resource?

Currently, notifications are always sent to the transport address of
the subscribing node, and include the resource URI and/or a
subscriber-supplied token.

We can extend this with an option in the subscription request to
subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the
transport address of the subscribing node. The specified transport
address may specify a multicast address. Notifications include the
resource URI and/or a subscriber-supplied token.

Note how this is equivalent to subscribing an URI to a resource:

(a)
Send-Notifications-To: client:61616
Token: 0xad657b38

(b)
Callback-Uri: coap://client:61616/ad657b38

When the authority in (a) or (b) denotes a multicast group,
subscribers are free to observe the resource by joining the
corresponding group and recognizing the "0xad657b38" token or
"/ad657b38" path.

However, (b) implies that there is a RESTful resource at
coap://client:61616/ad657b38. This complicates a lot of things,
because

- we do not really want a RESTful resource, just something the server
can send notifications to,

- we could only update the RESTful resource using a PUT request, which
is not the same as a notification.

So (a) is the way to go. (That is, if we want to allow subscribing
third parties. When I presented the idea of subscribing a multicast
group to an observable resource in Maastricht, there was unanimous
consensus that this was the worst idea ever.)


Klaus

From pab@peoplepowerco.com  Fri Oct 22 12:11:41 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B7E3A67FD for ; Fri, 22 Oct 2010 12:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.675
X-Spam-Level: 
X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.301,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67mwYyj3xAQ1 for ; Fri, 22 Oct 2010 12:11:40 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 123E83A682B for ; Fri, 22 Oct 2010 12:11:39 -0700 (PDT)
Received: by yxp4 with SMTP id 4so1022644yxp.31 for ; Fri, 22 Oct 2010 12:13:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.217.11 with SMTP id u11mr3959117muq.84.1287774797702; Fri, 22 Oct 2010 12:13:17 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Fri, 22 Oct 2010 12:13:17 -0700 (PDT)
In-Reply-To: 
References:    
Date: Fri, 22 Oct 2010 14:13:17 -0500
Message-ID: 
From: Peter Bigot 
To: Klaus Hartke 
Content-Type: multipart/alternative; boundary=0016367ed5df5e284c0493396f0e
Cc: core 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 22 Oct 2010 19:11:41 -0000

--0016367ed5df5e284c0493396f0e
Content-Type: text/plain; charset=ISO-8859-1

I'm unconvinced.

Creating a local resource and asking somebody to update it (via POST or PUT)
to tell me of changes to another resource seems like a perfectly natural and
RESTful coordination/notification approach given an underlying
request/response transaction model.  More natural and RESTful than accepting
multiple responses to a GET, in my opinion.

That the API technically permits subscription of third parties is something
that can be accepted or prevented by the designer of a specific system.

That the processing impact on the notifier and latency to observers is
diminished by providing a multicast authority in the URI denoting the
resource to be updated is a wonderful optimization that falls out naturally
as a consequence of a UDP-based transaction protocol, even if some REST
operations don't make sense on that URI.

Certainly, I am unaware of anything in CoAP that rules out or even
discourages use of the techniques I proposed.

Did I miss something?

Peter

On Fri, Oct 22, 2010 at 1:16 PM, Klaus Hartke  wrote:

> I think the question is, basically: What do we subscribe to an
> observable resource, and how does an observer relate a notification to
> a subscription or resource?
>
> Currently, notifications are always sent to the transport address of
> the subscribing node, and include the resource URI and/or a
> subscriber-supplied token.
>
> We can extend this with an option in the subscription request to
> subscribe a third party. When it's present, notifications are sent to
> the transport address specified in this option, instead of the
> transport address of the subscribing node. The specified transport
> address may specify a multicast address. Notifications include the
> resource URI and/or a subscriber-supplied token.
>
> Note how this is equivalent to subscribing an URI to a resource:
>
> (a)
> Send-Notifications-To: client:61616
> Token: 0xad657b38
>
> (b)
> Callback-Uri: coap://client:61616/ad657b38
>
> When the authority in (a) or (b) denotes a multicast group,
> subscribers are free to observe the resource by joining the
> corresponding group and recognizing the "0xad657b38" token or
> "/ad657b38" path.
>
> However, (b) implies that there is a RESTful resource at
> coap://client:61616/ad657b38. This complicates a lot of things,
> because
>
> - we do not really want a RESTful resource, just something the server
> can send notifications to,
>
> - we could only update the RESTful resource using a PUT request, which
> is not the same as a notification.
>
> So (a) is the way to go. (That is, if we want to allow subscribing
> third parties. When I presented the idea of subscribing a multicast
> group to an observable resource in Maastricht, there was unanimous
> consensus that this was the worst idea ever.)
>
>
> Klaus
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--0016367ed5df5e284c0493396f0e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm unconvinced.

Creating a local resource and asking somebody t=
o update it (via POST or PUT) to tell me of changes to another resource see=
ms like a perfectly natural and RESTful coordination/notification approach =
given an underlying request/response transaction model.=A0 More natural and=
 RESTful than accepting multiple responses to a GET, in my opinion.


That the API technically permits subscription of third parties is somet=
hing that can be accepted or prevented by the designer of a specific system=
.

That the processing impact on the notifier and latency to observer=
s is diminished by providing a multicast authority in the URI denoting the =
resource to be updated is a wonderful optimization that falls out naturally=
 as a consequence of a UDP-based transaction protocol, even if some REST op=
erations don't make sense on that URI.


Certainly, I am unaware of anything in CoAP that rules out or even disc=
ourages use of the techniques I proposed.

Did I miss something?
<=
br>Peter

On Fri, Oct 22, 2010 at 1:16 PM,=
 Klaus Hartke <hartk=
e@tzi.org> wrote:


I think the quest=
ion is, basically: What do we subscribe to an

observable resource, and how does an observer relate a notification to

a subscription or resource?



Currently, notifications are always sent to the transport address of

the subscribing node, and include the resource URI and/or a

subscriber-supplied token.



We can extend this with an option in the subscription request to

subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the

transport address of the subscribing node. The specified transport

address may specify a multicast address. Notifications include the

resource URI and/or a subscriber-supplied token.



Note how this is equivalent to subscribing an URI to a resource:



(a)

Send-Notifications-To: client:61616

Token: 0xad657b38



(b)

Callback-Uri: coap://client:61616/ad657b38



When the authority in (a) or (b) denotes a multicast group,


subscribers are free to observe the resource by joining t=
he


corresponding group and recognizing the "0xad657b38" token =
or

"/ad657b38" path.



However, (b) implies that there is a RESTful resource at

coap://client:61616/ad657b38. This complicates a lot of things,

because



- we do not really want a RESTful resource, just something the server

can send notifications to,



- we could only update the RESTful resource using a PUT request, which

is not the same as a notification.



So (a) is the way to go. (That is, if we want to allow subscribing

third parties. When I presented the idea of subscribing a multicast

group to an observable resource in Maastricht, there was unanimous

consensus that this was the worst idea ever.)






Klaus

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--0016367ed5df5e284c0493396f0e--

From pab@peoplepowerco.com  Sat Oct 23 03:53:56 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463243A68B9 for ; Sat, 23 Oct 2010 03:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.298,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY8jqNzlgylh for ; Sat, 23 Oct 2010 03:53:54 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 10EA43A67E5 for ; Sat, 23 Oct 2010 03:53:53 -0700 (PDT)
Received: by fxm9 with SMTP id 9so665155fxm.31 for ; Sat, 23 Oct 2010 03:55:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.176.7 with SMTP id d7mr1067126mup.52.1287831332244; Sat, 23 Oct 2010 03:55:32 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Sat, 23 Oct 2010 03:55:32 -0700 (PDT)
Date: Sat, 23 Oct 2010 05:55:32 -0500
Message-ID: 
From: Peter Bigot 
To: core 
Content-Type: multipart/alternative; boundary=0016364c792316d3bd04934699be
Subject: [core] Proxy versus Gateway
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Oct 2010 10:53:56 -0000

--0016364c792316d3bd04934699be
Content-Type: text/plain; charset=ISO-8859-1

I and others have been somewhat confused by the CoAP terms "proxy" and
"cache", which unless clarified actually mix several concepts.  I found
enlightenment in section 5.2.3 of Fielding's
dissertation
:

Intermediary components act as both a client and a server in order to
forward, with possible translation, requests and responses. A proxy
component is an intermediary selected by a client to provide interface
encapsulation of other services, data translation, performance enhancement,
or security protection. A gateway (a.k.a., reverse proxy) component is an
intermediary imposed by the network or origin server to provide an interface
encapsulation of other services, for data translation, performance
enhancement, or security enforcement. Note that the difference between a
proxy and a gateway is that a client determines when it will use a proxy.

I had been misled because the non-technical use of the term "proxy" is
appropriate for several key roles in a CoAP system, including that entity
which serves as the intermediary for sleeping nodes.  The correct term for
this function is "gateway", as most clients need not be aware that they are
acting through an intermediary.

CoAP's use of the term "proxy" is inconsistent with these definitions:

5.3.  Proxying   A proxy is defined as a CoAP end-point which services
cached requests
   on behalf of other CoAP end-points.  Any node in a CoAP network may
   act as a proxy, although in general the node between the constrained
   network and the Internet at large SHOULD always support proxy
   functionality.

This is misleading because it focuses solely on caching, leaving aside the
other reasons why a proxy might be necessary.   As an example, many
constrained nodes  will not support DNS, and therefore cannot translate an
ASCII authority found within a URI to a network address.   Similarly,
constrained devices are unlikely to have the computational resources
necessary to support public key cryptography.   It would be better to say
that a proxy is an intermediary explicitly selected by the client as its
agent when dealing with any transaction it is unable to perform directly.

This is an important but currently implicit role in a CoAP system.  As with
the traditional use of proxy in web browsers (back before desktops became
full participants in the Internet), a CoAP client should need only one proxy
to which it can delegate all CoAP transactions it can't do itself.
Configuration of this proxy for a particular node is an administrative
function outside the scope of CoAP as an on-wire protocol.  (If multiple
proxies were expected at a client, there would have to be some way of
selecting which proxy to use for which operation, an unnecessary
complication that could easily be supported by delegation.)  CoAP need
merely provide a mechanism by which the full information required to
delegate the transaction can be conveyed, which it does.

I encourage use of the term "gateway" when referring to an entity that
supports sleeping nodes, coordinates group activities, or performs any other
role that might be hidden behind the authority part of a URI.

Caching in turn is a function that may be paired with a proxy or with a
gateway, but is not inherently coupled to either one.

If it's not too late to make so major a change in terminology and concept, I
would encourage a rewrite of section 5 to make clear that proxies,
gateways, and caches are independent functions.  I would contribute text for
this if the editors would find that helpful.

Peter

--0016364c792316d3bd04934699be
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I and others have been somewhat confused by the CoAP terms "proxy"=
; and "cache", which unless clarified actually mix several concep=
ts.=A0 I found enlightenment in section 5.2.3 of Fieldi=
ng's dissertation:


Intermediary components act as both a=
 client and a server in order to=20
forward, with possible translation, requests and responses. A proxy=20
component is an intermediary selected by a client to provide interface=20
encapsulation of other services, data translation, performance=20
enhancement, or security protection. A gateway (a.k.a., reverse proxy)=20
component is an intermediary imposed by the network or origin server to=20
provide an interface encapsulation of other services, for data=20
translation, performance enhancement, or security enforcement. Note that
 the difference between a proxy and a gateway is that a client=20
determines when it will use a proxy.

I had been misled because=
 the non-technical use of the term "proxy" is appropriate for sev=
eral key roles in a CoAP system, including that entity which serves as the =
intermediary for sleeping nodes.=A0 The correct term for this function is &=
quot;gateway", as most clients need not be aware that they are acting =
through an intermediary.


CoAP's use of the term "proxy" is inconsistent with these=
 definitions:
5.3.  Proxying
=A0=A0 A proxy is defined as a Co=
AP end-point which services cached requests
   on behalf of other CoAP end-points.  Any node in a CoAP network may
   act as a proxy, although in general the node between the constrained
   network and the Internet at large SHOULD always support proxy
   functionality.

This is misleading because it focuses solely on caching, leaving asid=
e the other reasons why a proxy might be necessary.=A0=A0 As an example, ma=
ny constrained nodes=A0 will not support DNS, and=20
therefore cannot translate an ASCII authority found within a URI to a=20
network address. =A0 Similarly, constrained devices are unlikely to have th=
e computational resources necessary to support public key cryptography. =A0=
 It would be better to say that a proxy is an intermediary explicitly selec=
ted by the client as its agent when dealing with any transaction it is unab=
le to perform directly.


This is an important but currently implicit role in a CoAP system.=A0 A=
s with the traditional use of proxy in web browsers (back before desktops b=
ecame full participants in the Internet), a CoAP client should need only on=
e proxy to which it can delegate all CoAP transactions it can't do itse=
lf.=A0 Configuration of this proxy for a particular node is an administrati=
ve function outside the scope of CoAP as an on-wire protocol.=A0 (If multip=
le proxies were expected at a client, there would have to be some way of se=
lecting which proxy to use for which operation, an unnecessary complication=
 that could easily be supported by delegation.)=A0 CoAP need merely provide=
 a mechanism by which the full information required to delegate the transac=
tion can be conveyed, which it does.


I encourage use of the term "gateway" when referring to an en=
tity that supports sleeping nodes, coordinates group activities, or perform=
s any other role that might be hidden behind the authority part of a URI.

Caching in turn is a function that may be paired with a proxy or with a=
=20
gateway, but is not inherently coupled to either one.



If it's not too late to make so major a change in terminology and conce=
pt, I would encourage a rewrite of section=20
5 to make clear that proxies,=A0 gateways, and caches are independent funct=
ions.=A0 I would contribute text for this if the editors would find that he=
lpful.

Peter


--0016364c792316d3bd04934699be--

From zach@sensinode.com  Sat Oct 23 12:44:59 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DB03A68D0 for ; Sat, 23 Oct 2010 12:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjiepS9UG6b5 for ; Sat, 23 Oct 2010 12:44:58 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A2BE03A6899 for ; Sat, 23 Oct 2010 12:44:57 -0700 (PDT)
Received: from [192.168.1.4] (line-7931.dyn.kponet.fi [85.29.77.89]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9NJkPoP021301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Oct 2010 22:46:26 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-135-318342721; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Sat, 23 Oct 2010 22:46:27 +0300
Message-Id: <2919EC53-416C-4E85-B69D-EED2BEA63215@sensinode.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>   <63849857-95F4-4D50-A33E-F50A0E665F00@sensinode.com> 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Oct 2010 19:44:59 -0000

--Apple-Mail-135-318342721
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 22, 2010, at 4:56 PM, Peter Bigot wrote:

> Rewrite of which document?  core-coap or core-block?  I'd assumed =
core-coap was pretty nearly frozen, but if not, let's do this.


;-) coap-block of course. What we are discussing there doesn't affect =
core-coap much. Of course we need to keep them aligned.=20

Zach

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


--Apple-Mail-135-318342721
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMzE5NDYy
OFowIwYJKoZIhvcNAQkEMRYEFKHvHvBFJ5TlHZQCENgWDWoPqH3qMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBACyd7UPIm8ljJAoDW34Ic6Flrdb8lI/C9BfEutyrOLz4pn9t+nmx2l8Y
QZe0j5mg4yolPq7Zg6zZCNBZNod48ueSeKUl3J++vRmR7SehaZ4OKx5m9HVdwKuGebFr5jIm4SUS
I/k+834VBDJXRLH+KLcpdXSpZrDJOFBRC+ZZJuJWJgy53TPEJ2X3pFdXbpHH5Nk+NHZjyXtu6ICX
7HCDQOWXt+Udd2lUYWU157ga/jxYEYOqrBPsmWIJTfwPEvAHLUCpunsxi2FGazq9OaMYt7bSMr9x
Ls035yprJavCmCRhIyT/q3BX3D2vygBwK2a7SvHeKN4xfJDleN3S5Abr5ekAAAAAAAA=

--Apple-Mail-135-318342721--

From zach@sensinode.com  Sat Oct 23 12:48:54 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78113A6909 for ; Sat, 23 Oct 2010 12:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.528
X-Spam-Level: 
X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyW3jKIIXLdk for ; Sat, 23 Oct 2010 12:48:52 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 42E203A6899 for ; Sat, 23 Oct 2010 12:48:52 -0700 (PDT)
Received: from [192.168.1.4] (line-7931.dyn.kponet.fi [85.29.77.89]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9NJoOVw021350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Oct 2010 22:50:24 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-136-318581817; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Sat, 23 Oct 2010 22:50:26 +0300
Message-Id: 
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>   <47D1B769-EC2D-452C-882D-D40EF8C6FC2F@deepdarc.com> 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Oct 2010 19:48:55 -0000

--Apple-Mail-136-318581817
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 22, 2010, at 4:57 PM, Peter Bigot wrote:

> I agree; we just have the legacy issue of trying to reduce the number =
of header options that have to be recognized.  Are people are OK with =
saying that, say, header option type 7 means "MaxMessageSize" on =
requests and "ResourceRepresentationSize" on responses (including error =
responses)?


This is what I had in mind.

Zach

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


--Apple-Mail-136-318581817
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMzE5NTAy
N1owIwYJKoZIhvcNAQkEMRYEFB5MafJ8tY0eSSMbfkX7mZ7rzIlEMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBADibtKfCUke8uXz6SEjEWaXyKo22ytPe+DhMCFwpYg1j+WLYYaJeSLLo
NbZgWWPY3YBoyppKBuYr2gm4STxeM6emTYv+3KJL8W5sADKeOHP77pm/RdIPypetj/vhH9HbvJ3Q
lTw37NyL1pcJA1FKURJUB+F5NfqHdRjZ/kUIRWWABPTDJxmqavFmOviBhEmis3X7etUeN/AVqMbd
VbsSo3AvDakjY0DX+HicqjFrvrKVNAxF8lQZUMnh22ADqcmXuN7nnKVe6kY1NAWUeqXdviBjJ7u4
W+EO4QwANc1eXziHgTAd3leKtpha+pfkYSUkDU45uw6jG0lKkaeQ9Aqiau0AAAAAAAA=

--Apple-Mail-136-318581817--

From pab@peoplepowerco.com  Sun Oct 24 02:03:38 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7882A3A6818 for ; Sun, 24 Oct 2010 02:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.682
X-Spam-Level: 
X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=0.294,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2fcndk1lnzN for ; Sun, 24 Oct 2010 02:03:36 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5139F3A67F0 for ; Sun, 24 Oct 2010 02:03:35 -0700 (PDT)
Received: by fxm9 with SMTP id 9so1265522fxm.31 for ; Sun, 24 Oct 2010 02:05:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.219.1 with SMTP id w1mr6386732muq.113.1287911117410; Sun, 24 Oct 2010 02:05:17 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Sun, 24 Oct 2010 02:05:17 -0700 (PDT)
In-Reply-To: <14612E85-3B60-49C9-803A-D530A106B0DB@deepdarc.com>
References: <14612E85-3B60-49C9-803A-D530A106B0DB@deepdarc.com>
Date: Sun, 24 Oct 2010 04:05:17 -0500
Message-ID: 
From: Peter Bigot 
To: Robert Quattlebaum 
Content-Type: multipart/alternative; boundary=0016364c74e9a7d2040493592ccd
Cc: core 
Subject: Re: [core] Event Cascade Loops
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 24 Oct 2010 09:03:38 -0000

--0016364c74e9a7d2040493592ccd
Content-Type: text/plain; charset=ISO-8859-1

Thought about this some, and have concluded it shouldn't be CoAP's problem
to solve.  Detecting and reacting to cascades is a policy decision that
doesn't belong in what's essentially a UDP transaction protocol.

Cascades exist only if the business logic associated with the resources
supported by a server enables them.  If I have a cloud of read-only
temperature sensors, there is no potential for a cascade.

If CoAP specifies some behavior where a cascade can be induced without
involving upper layers, we need to fix it.  I think the only place where
this might happen is in the definition of "proxy" (I don't think it does
happen there, but it's a possibility).

Finally, there should be nothing in CoAP that prevents you from implementing
exactly this capability in your API: define a critical option, ensure your
requests include it, and that the business logic implemented in your servers
propagates it.  If CoAP doesn't allow you to do this, it needs to be fixed.

This could be a suggestion in a "best practices" informational RFC, or be
adopted by some industry that requires it for interoperability.  My opinion
is it's not worth an RFC in its own right: it has too much policy hard-coded
(like the default value for a cascade count, or even whether there should be
a default value).  Having too many optional features that don't have clear
motivation for most applications will slow adoption of the base CoAP
standard.

Peter

On Fri, Oct 22, 2010 at 12:44 PM, Robert Quattlebaum wrote:

> I just wanted to bring up a potential problem and a proposed solution.
>
> If CoAP devices can issue requests to other CoAP devices as a direct
> response of it itself receiving a request (what I call a "cascade") it
> becomes possible for infinite loops to be created. This is obviously a bad
> thing.
>
> My proposed solution would involve a new header option, which at the moment
> I will refer to as the "cascade-count" option. The cascade-count option is
> only added to an outbound request if that request was spawned by a previous
> inbound request. The rules are as follows:
>
>        * If the inbound request does not have a cascade-count, the value of
> the cascade count in the outbound request is set to '128'.
>        * If the inbound request has a cascade-count, then the that value
> minus one is set as the cascade-count of the outbound request.
>        * If the inbound request has a cascade-count of zero, then no
> outbound requests are allowed.
>
> Note that this is different than a "hop" count because we aren't tracking
> any particular set of data---we are tracking a cascade of events. The option
> itself would be elective, but if adopted should be REQUIRED to be supported
> and used by any node where an inbound request could automatically trigger
> automatic outbound requests.
>
> This capability would be very important for Peter's "observation via
> callbacks" idea. Resources changed by external requests should trigger
> callbacks with a cascade-count. Without this option, or a similar mechanism,
> an infinite cascade loop would likely continue until some or all of the
> devices in the loop are power-cycled (or the configuration was changed to
> prevent the loop).
>
> Thoughts?
>
> __________________
> Robert Quattlebaum
> Jabber: darco@deepdarc.com
> eMail:  darco@deepdarc.com
> www:    http://www.deepdarc.com/
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--0016364c74e9a7d2040493592ccd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thought about this some, and have concluded it shouldn't be CoAP's =
problem to solve.=A0 Detecting and reacting to cascades is a policy decisio=
n that doesn't belong in what's essentially a UDP transaction proto=
col.


Cascades exist only if the business logic associated with the resources=
 supported by a server enables them.=A0 If I have a cloud of read-only temp=
erature sensors, there is no potential for a cascade.

If CoAP specif=
ies some behavior where a cascade can be induced without involving upper la=
yers, we need to fix it.=A0 I think the only place where this might happen =
is in the definition of "proxy" (I don't think it does happen=
 there, but it's a possibility).


Finally, there should be nothing in CoAP that prevents you from impleme=
nting exactly this capability in your API: define a critical option, ensure=
 your requests include it, and that the business logic implemented in your =
servers propagates it.=A0 If CoAP doesn't allow you to do this, it need=
s to be fixed.


This could be a suggestion in a "best practices" informationa=
l RFC, or be adopted by some industry that requires it for interoperability=
.=A0 My opinion is it's not worth an RFC in its own right: it has too m=
uch policy hard-coded (like the default value for a cascade count, or even =
whether there should be a default value).=A0 Having too many optional featu=
res that don't have clear motivation for most applications will slow ad=
option of the base CoAP standard.


Peter

On Fri, Oct 22, 2010 at 12:44 P=
M, Robert Quattlebaum <darco@deepdarc.com> wrote:

I just wanted to bring up a potential problem and a proposed solution.



If CoAP devices can issue requests to other CoAP devices as a direct respon=
se of it itself receiving a request (what I call a "cascade") it =
becomes possible for infinite loops to be created. This is obviously a bad =
thing.




My proposed solution would involve a new header option, which at the moment=
 I will refer to as the "cascade-count" option. The cascade-count=
 option is only added to an outbound request if that request was spawned by=
 a previous inbound request. The rules are as follows:




 =A0 =A0 =A0 =A0* If the inbound request does not have a cascade-count, the=
 value of the cascade count in the outbound request is set to '128'=
.

 =A0 =A0 =A0 =A0* If the inbound request has a cascade-count, then the that=
 value minus one is set as the cascade-count of the outbound request.

 =A0 =A0 =A0 =A0* If the inbound request has a cascade-count of zero, then =
no outbound requests are allowed.



Note that this is different than a "hop" count because we aren=
9;t tracking any particular set of data---we are tracking a cascade of even=
ts. The option itself would be elective, but if adopted should be REQUIRED =
to be supported and used by any node where an inbound request could automat=
ically trigger automatic outbound requests.




This capability would be very important for Peter's "observation v=
ia callbacks" idea. Resources changed by external requests should trig=
ger callbacks with a cascade-count. Without this option, or a similar mecha=
nism, an infinite cascade loop would likely continue until some or all of t=
he devices in the loop are power-cycled (or the configuration was changed t=
o prevent the loop).




Thoughts?



__________________

Robert Quattlebaum

Jabber: darco@deepdarc.com

eMail: =A0darco@deepdarc.com

www: =A0 =A0http://w=
ww.deepdarc.com/







_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--0016364c74e9a7d2040493592ccd--

From bergmann@tzi.org  Sun Oct 24 02:58:02 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258CB3A67F0 for ; Sun, 24 Oct 2010 02:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[AWL=0.603,  BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unXu+miu0hpU for ; Sun, 24 Oct 2010 02:58:00 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E0DFB3A6832 for ; Sun, 24 Oct 2010 02:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from aung.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9O9xRYW012633; Sun, 24 Oct 2010 11:59:33 +0200 (CEST)
From: Olaf Bergmann 
To: "Rahman\, Akbar" 
References: <73224E51-B5F2-4134-B9C8-7D99F34C98CC@sensinode.com> 
Date: Sun, 24 Oct 2010 11:59:27 +0200
In-Reply-To:  (Akbar Rahman's message of "Thu, 21 Oct 2010 12:18:46 -0400")
Message-ID: <87pquzsygw.fsf@tzi.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: core 
Subject: Re: [core] Plugfest in Beijing
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 24 Oct 2010 09:58:02 -0000

Hi,

"Rahman, Akbar"  writes:

> Hi Zach/Carsten,
>
>
> I'm able to access Carsten's server, however I am not able to access
> Szymon's SENSEI Java server (coap://sensei-dev1.grid.pub.ro:61618).  I
> am able to successfully ping it, however I'm not able to reach the 61618
> UDP port.  The server is returning an ICMP "port is not reachable"
> message.  
>
> Just wondering if the server is indeed up and running.

I have also re-started my server listening on coap-ietf.tzi.org:61680.

The code as well as a client to play with are also available from
.

Gruesse,
Olaf

From peter.van.der.stok@philips.com  Sun Oct 24 07:37:11 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3BA3A684D for ; Sun, 24 Oct 2010 07:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.326
X-Spam-Level: 
X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=1.272,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIahlvK39VKO for ; Sun, 24 Oct 2010 07:36:56 -0700 (PDT)
Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by core3.amsl.com (Postfix) with ESMTP id 0136A3A689E for ; Sun, 24 Oct 2010 07:36:39 -0700 (PDT)
Received: from mail133-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.8; Sun, 24 Oct 2010 14:37:31 +0000
Received: from mail133-tx2 (localhost.localdomain [127.0.0.1])	by mail133-tx2-R.bigfish.com (Postfix) with ESMTP id 901C215500B8; Sun, 24 Oct 2010 14:37:29 +0000 (UTC)
X-SpamScore: -43
X-BigFish: VPS-43(zz15d6O9251J9370J98dN328cM217bP9371P6346ii5a4kzz1202hzz8275bh8275dh1033IL186Mz2dh2a8h61h)
X-Spam-TCS-SCL: 0:0
Received: from mail133-tx2 (localhost.localdomain [127.0.0.1]) by mail133-tx2 (MessageSwitch) id 128793104844803_21231; Sun, 24 Oct 2010 14:37:28 +0000 (UTC)
Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.252])	by mail133-tx2.bigfish.com (Postfix) with ESMTP id F177217D005C; Sun, 24 Oct 2010 14:37:27 +0000 (UTC)
Received: from NLAMSEXE02.connect1.local (168.87.56.20) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.0.482.44; Sun, 24 Oct 2010 14:37:27 +0000
Received: from nlamsexh01.connect1.local (172.16.153.11) by connect1.philips.com (172.16.156.41) with Microsoft SMTP Server (TLS) id 8.3.106.1; Sun, 24 Oct 2010 16:37:36 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh01.connect1.local ([172.16.153.11]) with mapi; Sun, 24 Oct 2010 16:37:25 +0200
From: "Stok, Peter van der" 
To: Peter Bigot 
Date: Sun, 24 Oct 2010 16:37:28 +0200
Thread-Topic: [core] observation via callbacks
Thread-Index: Actx+F7Aih6MHrUMQm2N/xtB+hpUlwBjsoIA
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, nl-NL
Content-Type: multipart/alternative; boundary="_000_B5584ABB89131542BEA01BFAF71A73878660D7C45CNLCLUEXM03con_"
MIME-Version: 1.0
X-Reverse-DNS: smtpx.philips.com
Cc: core 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 24 Oct 2010 14:37:11 -0000

--_000_B5584ABB89131542BEA01BFAF71A73878660D7C45CNLCLUEXM03con_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

Just a small remark on the statement:
first response: because the client in a normal CoAP GET operation expects t=
o receive one response, which completes the transaction.  For this multicas=
t GET to work, the client need merely be robust in the presence of addition=
al, later responses, which it ignores.  ("Last" causes difficulty because w=
hen do you decide that there are no more responses coming?)

I think this is just one of the few ways multicast returns can be handled o=
r need to be handled. Let me cite some examples:
Multicast to a group of devices to set values
            No response needed, only the knowledge that all connected and c=
orrect devices have received the setting within a given period
Multicast to group of devices to get a status back
            Group is known to invoker. When a member of group has not answe=
red within given time it is assumed to be faulty
Multicast to a server out of many possible ones
            Either the first (as you suggest) or one response selected from=
 a set of answers, after closing return channel within a given time period =
(e.g. nearest DNS server)
Multicast to browse available services
            Answers can be continuously received and displayed on visu for =
selection by user (e.g. asking for available PIR sensors when DNS server is=
 not available during maintenance by maintenance tool)
Possibly one should make additional implementation statements about the sco=
pe of the multicast. A mesh of wireless nodes has other response characteri=
stics than a worldwide network of nodes connected through complex patterns =
of routers and edge routers.
Hope this helps,

Peter vd stok



From: Peter Bigot [mailto:pab@peoplepowerco.com]
Sent: Friday 22 October 2010 16:50
To: Stok, Peter van der
Cc: core
Subject: Re: [core] observation via callbacks

For previous details of my position concerning REST operations on URIs wher=
e the authority is a multicast address, see:

http://www.ietf.org/mail-archive/web/core/current/msg00607.html
http://www.ietf.org/mail-archive/web/core/current/msg00745.html

The resource URI coap://group/server/observable is a distributed resource t=
hat is intended to mirror the actual resource at coap://server/observable.

cooperative: Technically, the subscribers don't own the resource, so there'=
s no obligation that they support a GET operation on it.  In any case, you =
may not want all nodes to respond (to reduce the multicast storm).

cached representation: The representation of the cached resource value, whi=
ch may not be the current value as held at the actual resource owner.  (RES=
T maintains distinctions between the resource and its representation in a p=
articular media type.)

multiple representations: The real resource represents a single value, e.g.=
 the string "ON".  A GET addressed to a multicast address is likely to prod=
uce multiple representations, which ideally will all be "ON".  How these mu=
ltiple representations should be combined into a single representation is a=
 difficult question, discussed in the above emails.

first response: because the client in a normal CoAP GET operation expects t=
o receive one response, which completes the transaction.  For this multicas=
t GET to work, the client need merely be robust in the presence of addition=
al, later responses, which it ignores.  ("Last" causes difficulty because w=
hen do you decide that there are no more responses coming?)

Peter
On Fri, Oct 22, 2010 at 9:33 AM, Stok, Peter van der > wrote:
Dear Peter,

I must confess this description seems to come close to my na=EFve imaginati=
on of how battery-less sensors inform interested nodes.
However, the phrase
"Cooperative subscribers might respond to a GET of the multicast URI by sen=
ding their cached representation; the requester can ignore all but the firs=
t response, eliminating the need to combine multiple representations."
exceeds my parsing capabilities.
What is cooperative, cached representation, multiple representation, and wh=
y first and not last response?
Probably you already explained this in earlier mails, and pointing at the r=
elevant parts in those mails would help.

Greetings and thanks,

Peter

From: core-bounces@ietf.org [mailto:core-boun=
ces@ietf.org] On Behalf Of Peter Bigot
Sent: Friday 22 October 2010 16:21
To: core
Subject: [core] observation via callbacks

In the interests of continuing to promote this pattern of using call-back U=
RIs to simplify life, what do people think of the following alternative obs=
ervation paradigm:

Assume an observable resource is present at coap://server/observable, where=
 the authority denotes a unicast end-point.  GET works as usual.

Allow a node client to subscribe to this by POST to coap://server/observabl=
e of a callback URI coap://client/observer along with a subscription durati=
on (zero to unsubscribe).  The semantics of this are that, until the subscr=
iption expires, whenever the server changes the value of the resource it PU=
Ts the corresponding representation to the callback URI registered by each =
observer (probably as a Non-Confirmable).

Enhancement: Extend the link description for this resource with a link attr=
ibute "obs" the value of which is a URI-Reference that becomes a URI like "=
coap://group/server/observable", where the authority denotes a multicast gr=
oup.  Whenever the server changes the value of the resource, in addition to=
 sending to subscribed unicast clients, it PUTs the value of the resource i=
n a CoAP message sent to the muticast address (and port from the authority)=
.  Subscribers are free to observe the resource by joining the correspondin=
g group and recognizing the "/server/observable" path.  Cooperative subscri=
bers might respond to a GET of the multicast URI by sending their cached re=
presentation; the requester can ignore all but the first response, eliminat=
ing the need to combine multiple representations.

RESTful observation without change to the CoAP base protocol, needing suppo=
rt in the link format only to enable discovery of a multicast alias for eff=
icient distribution of the resource to anonymous subscribers.

I think it's pretty cool.

Peter

________________________________
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_B5584ABB89131542BEA01BFAF71A73878660D7C45CNLCLUEXM03con_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

















Hi Peter,



 



Just a small remark on the statement:



first response: because=
 the
client in a normal CoAP GET operation expects to receive one response, whic=
h
completes the transaction.  For this multicast GET to work, the client
need merely be robust in the presence of additional, later responses, which=
 it
ignores.  ("Last" causes difficulty because when do you deci=
de
that there are no more responses coming?)







I think this is just on=
e of the
few ways multicast returns can be handled or need to be handled. Let me cit=
e
some examples:



Multicast to a group of=
 devices
to set values



=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 No response needed,
only the knowledge that all connected and correct devices have received the
setting within a given period



Multicast to group of d=
evices
to get a status back



=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Group is known to
invoker. When a member of group has not answered within given time it is as=
sumed
to be faulty



Multicast to a server o=
ut of
many possible ones



=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Either the first
(as you suggest) or one response selected from a set of answers, after clos=
ing
return channel within a given time period (e.g. nearest DNS server)



Multicast to browse ava=
ilable
services



=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Answers can be continuously
received and displayed on visu for selection by user (e.g. asking for avail=
able
PIR sensors when DNS server is not available during maintenance by maintena=
nce
tool)



Possibly one should mak=
e
additional implementation statements about the scope of the multicast. A me=
sh
of wireless nodes has other response characteristics than a worldwide netwo=
rk
of nodes connected through complex patterns of routers and edge routers.



Hope this helps,



 



Peter vd stok



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



 



 






From: Peter Bigot
[mailto:pab@peoplepowerco.com] 

Sent: Friday 22 October 2010 16:50

To: Stok, Peter van der

Cc: core

Subject: Re: [core] observation via callbacks






 



For previous details of=
 my
position concerning REST operations on URIs where the authority is a multic=
ast
address, see:



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

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



The resource URI coap://group/server/observable is a distributed resource t=
hat
is intended to mirror the actual resource at coap://server/observable.



cooperative: Technically, the subscribers don't own the resource, so there'=
s no
obligation that they support a GET operation on it.  In any case, you =
may
not want all nodes to respond (to reduce the multicast storm).



cached representation: The representation of the cached resource value, whi=
ch
may not be the current value as held at the actual resource owner.  (R=
EST
maintains distinctions between the resource and its representation in a
particular media type.)



multiple representations: The real resource represents a single value, e.g.=
 the
string "ON".  A GET addressed to a multicast address is like=
ly
to produce multiple representations, which ideally will all be
"ON".  How these multiple representations should be combined
into a single representation is a difficult question, discussed in the abov=
e
emails.



first response: because the client in a normal CoAP GET operation expects t=
o
receive one response, which completes the transaction.  For this multi=
cast
GET to work, the client need merely be robust in the presence of additional=
,
later responses, which it ignores.  ("Last" causes difficult=
y
because when do you decide that there are no more responses coming?)



Peter






On Fri, Oct 22, 2010 at 9:33 AM, Stok, Peter van der &=
lt;peter.van.der.stok@philips.c=
om>
wrote:









Dear Peter,



 



I must confess this description se=
ems to
come close to my na=EFve imagination of how battery-less sensors inform
interested nodes.



However, the phrase 



“Cooperative
subscribers might respond to a GET of the multicast URI by sending their ca=
ched
representation; the requester can ignore all but the first response,
eliminating the need to combine multiple representations.”

exceeds my parsing capabilit=
ies.



What is cooperative, cached
representation, multiple representation, and why first and not last respons=
e?



Probably you already explained thi=
s in
earlier mails, and pointing at the relevant parts in those mails would help=
.



 



Greetings and thanks,<=
/o:p>



 



Peter



 






From: core-bounces@ietf.o=
rg
[mailto:core-bou=
nces@ietf.org]
On Behalf Of Peter Bigot

Sent: Friday 22 October 2010 16:21

To: core

Subject: [core] observation via callbacks












 



In the
interests of continuing to promote this pattern of using call-back URIs to
simplify life, what do people think of the following alternative observatio=
n
paradigm:



Assume an observable resource is present at coap://server/observable, where=
 the
authority denotes a unicast end-point.  GET works as usual.



Allow a node client to subscribe to this by POST to coap://server/observabl=
e of
a callback URI coap://client/observer along with a subscription duration (z=
ero
to unsubscribe).  The semantics of this are that, until the subscripti=
on
expires, whenever the server changes the value of the resource it PUTs the
corresponding representation to the callback URI registered by each observe=
r
(probably as a Non-Confirmable).



Enhancement: Extend the link description for this resource with a link
attribute "obs" the value of which is a URI-Reference that become=
s a
URI like "coap://group/server/observable", where the authority
denotes a multicast group.  Whenever the server changes the value of t=
he
resource, in addition to sending to subscribed unicast clients, it PUTs the
value of the resource in a CoAP message sent to the muticast address (and p=
ort
from the authority).  Subscribers are free to observe the resource by
joining the corresponding group and recognizing the
"/server/observable" path.  Cooperative subscribers might
respond to a GET of the multicast URI by sending their cached representatio=
n;
the requester can ignore all but the first response, eliminating the need t=
o
combine multiple representations.



RESTful observation without change to the CoAP base protocol, needing suppo=
rt
in the link format only to enable discovery of a multicast alias for effici=
ent
distribution of the resource to anonymous subscribers.



I think it's pretty cool.



Peter












 












The information contained in this message may be confidential a=
nd
legally protected under applicable law. The message is intended solely for =
the
addressee(s). If you are not the intended recipient, you are hereby notifie=
d
that 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 the
original message.









 









--_000_B5584ABB89131542BEA01BFAF71A73878660D7C45CNLCLUEXM03con_--

From cabo@tzi.org  Sun Oct 24 09:35:05 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28883A68D3 for ; Sun, 24 Oct 2010 09:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.161
X-Spam-Level: 
X-Spam-Status: No, score=-106.161 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzVpeXqNRbhz for ; Sun, 24 Oct 2010 09:34:49 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 3159E3A688D for ; Sun, 24 Oct 2010 09:34:43 -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 o9OGaGQH021851 for ; Sun, 24 Oct 2010 18:36:16 +0200 (CEST)
Received: from [192.168.217.101] (p5489C837.dip.t-dialin.net [84.137.200.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 625D2179; Sun, 24 Oct 2010 18:36:16 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>
Date: Sun, 24 Oct 2010 18:36:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <83E52281-5A66-4ADC-B9EE-D72F1EB77A0F@tzi.org>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>
To: core 
X-Mailer: Apple Mail (2.1081)
Subject: [core] draft-bormann-core-coap-block-01.txt now all sliced up (Re: Next/Range Options (re: draft-ietf-core-block-00))
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Oct 2010 16:35:05 -0000

OK, I wrote up this slicing stuff.

Since I can't submit a new draft at this time, I put it in as =
draft-bormann-core-coap-block-01.
Shoot me.  I'm not trying to compete with the WG draft, I just want to =
have something written up that is not entirely handwaving.

I think the design I'm presenting is complete, and this will enable us =
to compare generalized slicing with block (and/or possibly simplify =
slicing by dropping some of the objectives I had in mind).

Enjoy at:
	http://tools.ietf.org/html/draft-bormann-core-coap-block

(Once the tools server has picked it up -- right now you get to see the =
-00 there; so go to =
http://www.ietf.org/internet-drafts/draft-bormann-core-coap-block-01.txt =
for black-and-white version.)

Gruesse, Carsten


From zach@sensinode.com  Sun Oct 24 14:30:32 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD363A68EE for ; Sun, 24 Oct 2010 14:30:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.532
X-Spam-Level: 
X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFK4LoO99p4o for ; Sun, 24 Oct 2010 14:30:25 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2736E3A68E7 for ; Sun, 24 Oct 2010 14:30:24 -0700 (PDT)
Received: from [192.168.1.4] (line-8502.dyn.kponet.fi [85.29.79.150]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9OLW13o005856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Oct 2010 00:32:02 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-175-411080803; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Mon, 25 Oct 2010 00:32:05 +0300
Message-Id: <9032ADFF-AE86-4BC8-96F0-C0AD3F2BDC47@sensinode.com>
References:   
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core , Klaus Hartke 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 24 Oct 2010 21:30:32 -0000

--Apple-Mail-175-411080803
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 22, 2010, at 6:24 PM, Peter Bigot wrote:

> Disclaimer: I have not changed my position that multicast with REST is =
an ill-defined concept.  This proposal came from my accepting the =
position that not everything CoAP enables has to be 100% consistent with =
REST.  Some of what falls out from things like applying CoAP to =
multicast addresses is very useful and worth adopting when REST is less =
important than efficiency.


Just to synchronize... The intention of this WG was never to make CoAP =
100% consistent with REST. That would be pretty hard considering there =
is no RFC defining what REST is exactly (seems to be some kind of =
cult...), the closest thing that we know is HTTP (which was very much =
designed for transferring hypermedia). The CoRE working group does aim =
to fit its work into the REST architecture, but I would say making CoAP =
(and the security work) useful for constrained nodes and networks in M2M =
applications to be our main goal. Thus I agree with you, multicast CoAP =
is worth developing, and is a must for most applications we are =
considering it for.

Zach

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


--Apple-Mail-175-411080803
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNDIxMzIw
NlowIwYJKoZIhvcNAQkEMRYEFJm/Hc/qlLKCo4AL7I2b8WC/gDtIMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBACOwfNcpTBjIJMAUgdLrpLSPFVnQxlGdyJZWaV9iTaU78Ew8ZIgfOPg8
TQxnufDXVO5Iqzt9MNwekU5T2NeVenfO8J1WS+F/se2FFkHq8vDHoCdG4oPYDqcJpnjjgevDaYfz
qO8HZLCLqS8bmYkqtg6jc2XkZo9owKOEoTGw6gG9j41bg+m+qgIrPfL12FMAua0o2BhoidadelZw
UkCOmvHwlXRJicvEsdNQPQXJyZGsNlOuh+WSFoXuTs9rE5sswq364Iq1phHHQ4Els1GMLCnkpTzE
zgZSo0berVs4Rg8I+Nj00yysl5SsdBio6ZE9g5+/tn973xKY3qfsOAbUfR8AAAAAAAA=

--Apple-Mail-175-411080803--

From zach@sensinode.com  Sun Oct 24 14:37:10 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4913A68D5 for ; Sun, 24 Oct 2010 14:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.536
X-Spam-Level: 
X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrdfzoePO4rB for ; Sun, 24 Oct 2010 14:37:09 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 918FD3A68D1 for ; Sun, 24 Oct 2010 14:37:07 -0700 (PDT)
Received: from [192.168.1.4] (line-8502.dyn.kponet.fi [85.29.79.150]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9OLcjEt005953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Oct 2010 00:38:46 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-176-411484896; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Mon, 25 Oct 2010 00:38:50 +0300
Message-Id: <61C991A8-A377-4135-B96C-9379CD475029@sensinode.com>
References:    
To: Klaus Hartke 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 24 Oct 2010 21:37:10 -0000

--Apple-Mail-176-411484896
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 22, 2010, at 9:16 PM, Klaus Hartke wrote:

> So (a) is the way to go. (That is, if we want to allow subscribing
> third parties. When I presented the idea of subscribing a multicast
> group to an observable resource in Maastricht, there was unanimous
> consensus that this was the worst idea ever.)

This is the first thing that came to mind when Peter brought this up. We =
really got bashed in Maastricht for even suggesting that the =
notifications would go to a third party for security reasons. They =
*really* liked when it was mentioned that this could be a multicast =
address. Think of how powerful of an amplification attack this would be =
built-into a protocol implemented by resource-limited nodes?=20

I do agree with Klaus, if we did want to allow subscription to a third =
party, then (a) makes the most sense to me. However, I am not sure if we =
should or can do that at the transfer protocol level. It sounds like the =
pattern Peter described belongs to a REST application interface design =
instead... =20

Zach

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


--Apple-Mail-176-411484896
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNDIxMzg1
MFowIwYJKoZIhvcNAQkEMRYEFPAdokDW1GzfhTr5UxPvDofl0pxCMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAGoQZlNydQb5/MehxJfyJLxZD0TyY9bzHNxLjxYCeC+pri45PRyFjUyK
dxCXUeUgHe8Pks9oZ/rVBiZj0j+OIiUK/YUAM3HQnWnf/pXT+IJHuWTAYvsYCkLhgxp0/IZe/CuP
CfbCK6yGDdSrtRQkX2SRxbJvzLW8dPV3b7nd9D7SRvr/HhCiP1ypkH1Vxrriu5C/o4aWR1Yb6OcR
yhkbtAOD9HL7Q6XC+5pbxyeOJtPbsQsqjpjbznXP6BhmcpMSLqc428x22BdE1XJmzyMxy0s7vdD1
vjzkHuCxZrYvwF2VytA6DoQYJ1yYDwjdVQSG6GOGkBssUsGjHrAvO01ccYMAAAAAAAA=

--Apple-Mail-176-411484896--

From pab@peoplepowerco.com  Sun Oct 24 15:29:04 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620823A6782 for ; Sun, 24 Oct 2010 15:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.686
X-Spam-Level: 
X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.290,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHApUau6ZonY for ; Sun, 24 Oct 2010 15:29:02 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 762A83A6452 for ; Sun, 24 Oct 2010 15:29:02 -0700 (PDT)
Received: by fxm9 with SMTP id 9so1689255fxm.31 for ; Sun, 24 Oct 2010 15:30:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.217.11 with SMTP id u11mr7280810muq.84.1287959444234; Sun, 24 Oct 2010 15:30:44 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Sun, 24 Oct 2010 15:30:44 -0700 (PDT)
In-Reply-To: <61C991A8-A377-4135-B96C-9379CD475029@sensinode.com>
References:     <61C991A8-A377-4135-B96C-9379CD475029@sensinode.com>
Date: Sun, 24 Oct 2010 17:30:44 -0500
Message-ID: 
From: Peter Bigot 
To: Zach Shelby 
Content-Type: multipart/alternative; boundary=0016367ed5df28a0ab0493646d9f
Cc: core , Klaus Hartke 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 24 Oct 2010 22:29:04 -0000

--0016367ed5df28a0ab0493646d9f
Content-Type: text/plain; charset=ISO-8859-1

Bah.  If the content of the notification is sensitive, don't multicast it.
Or multicast it encrypted.  And disallow third-party subscriptions.  That's
all application-level policy decisions.  And as Zack says, all this can be
done by the application using CoAP as a transport for a REST API.  There are
plenty of notification use cases where third-party and/or anonymous
subscriptions and/or multicast distribution make sense, and CoAP shouldn't
presume to outlaw them (even if it could, which I doubt).

I don't need the proposed subscription options (or multicast) to implement a
workable RESTful notification or group communication scheme, with-or-without
multicast, with-or-without third party subscribers.  Base CoAP's got enough
for me to do that cleanly with unicast, using the techniques I described,
cleanly and no less efficiently than using the draft extensions.  I think
this is evidence of CoAP's robustness and strength as a point-to-point
REST-compatible protocol.

Multicast will be very useful in a CoAP-based protocol that uses a different
scheme and different (non-REST) operations.   Probably handled by a gateway
that transforms both standard CoAP and HTTP-carried REST operations into a
multicast form.  All of Peter van der Stok's examples can be handled, but
clearly need a lot more thought and development so they can be presented in
a conceptually clear model suitable for integration with web-compatible
service oriented architectures (which I think is really the goal, not REST
specifically).  I have ideas, but am too swamped to write them down now.

So: Do we try to discourage people from attempting to use multicast
addresses with CoAP as currently defined, given that we don't have
protection against amplification attacks, haven't really validated using
multicast addresses with the current method set, and don't have a clear
description of how to accomplish the mandated HTTP/CoAP transformations
generally when they're involved?  Or do we leave it unaddressed?

The same issues technically arise in any other UDP-based protocol that
inherently assumes a point-to-point interaction model.  Somebody bolted
multicast onto TFTP five years later on, and that was good enough, but since
CoRE's charter explicitly mentions multicast, and we're not ready for it,
whoever's at Beijing might want to be prepared to address this.  (I will be
attending virtually, not IRL)

Peter

On Sun, Oct 24, 2010 at 4:38 PM, Zach Shelby  wrote:

>
> On Oct 22, 2010, at 9:16 PM, Klaus Hartke wrote:
>
> > So (a) is the way to go. (That is, if we want to allow subscribing
> > third parties. When I presented the idea of subscribing a multicast
> > group to an observable resource in Maastricht, there was unanimous
> > consensus that this was the worst idea ever.)
>
> This is the first thing that came to mind when Peter brought this up. We
> really got bashed in Maastricht for even suggesting that the notifications
> would go to a third party for security reasons. They *really* liked when it
> was mentioned that this could be a multicast address. Think of how powerful
> of an amplification attack this would be built-into a protocol implemented
> by resource-limited nodes?
>
> I do agree with Klaus, if we did want to allow subscription to a third
> party, then (a) makes the most sense to me. However, I am not sure if we
> should or can do that at the transfer protocol level. It sounds like the
> pattern Peter described belongs to a REST application interface design
> instead...
>
> Zach
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>

--0016367ed5df28a0ab0493646d9f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bah.=A0 If the content of the notification is sensitive, don't multicas=
t it. Or multicast it encrypted.=A0 And disallow third-party subscriptions.=
=A0 That's all application-level policy decisions.=A0 And as Zack says,=
 all this can be done by the application using CoAP as a transport for a RE=
ST API.=A0 There are plenty of notification use cases where third-party and=
/or anonymous subscriptions and/or multicast distribution make sense, and C=
oAP shouldn't presume to outlaw them (even if it could, which I doubt).=



I don't need the proposed subscription options (or multicast) to im=
plement a workable RESTful notification or group communication scheme, with=
-or-without multicast, with-or-without third party subscribers.=A0 Base CoA=
P's got enough for me to do that cleanly with unicast, using the techni=
ques I described, cleanly and no less efficiently than using the draft exte=
nsions.=A0 I think this is evidence of CoAP's robustness and strength a=
s a point-to-point REST-compatible protocol.


Multicast will be very useful in a CoAP-based protocol that uses a diff=
erent scheme and different (non-REST) operations. =A0 Probably handled by a=
 gateway that transforms both standard CoAP and HTTP-carried REST operation=
s into a multicast form.=A0 All of Peter van der Stok's examples can be=
 handled, but clearly need a lot more thought and development so they can b=
e presented in a conceptually clear model suitable for integration with web=
-compatible service oriented architectures (which I think is really the goa=
l, not REST specifically).=A0 I have ideas, but am too swamped to write the=
m down now.


So: Do we try to discourage people from attempting to use multicast add=
resses with CoAP as currently defined, given that we don't have protect=
ion against amplification attacks, haven't really validated using multi=
cast addresses with the current method set, and don't have a clear desc=
ription of how to accomplish the mandated HTTP/CoAP transformations general=
ly when they're involved?=A0 Or do we leave it unaddressed?


The same issues technically arise in any other UDP-based protocol that =
inherently assumes a point-to-point interaction model.=A0 Somebody bolted m=
ulticast onto TFTP five years later on, and that was good enough, but since=
 CoRE's charter explicitly mentions multicast, and we're not ready =
for it, whoever's at Beijing might want to be prepared to address this.=
=A0 (I will be attending virtually, not IRL)


Peter

On Sun, Oct 24, 2010 at 4:38 PM=
, Zach Shelby <z=
ach@sensinode.com> wrote:




On Oct 22, 2010, at 9:16 PM, Klaus Hartke wrote:



> So (a) is the way to go. (That is, if we want to allow subscribing

> third parties. When I presented the idea of subscribing a multicast
> group to an observable resource in Maastricht, there was unanimous

> consensus that this was the worst idea ever.)




This is the first thing that came to mind when Peter brought this up.=
 We really got bashed in Maastricht for even suggesting that the notificati=
ons would go to a third party for security reasons. They *really* liked whe=
n it was mentioned that this could be a multicast address. Think of how pow=
erful of an amplification attack this would be built-into a protocol implem=
ented by resource-limited nodes?




I do agree with Klaus, if we did want to allow subscription to a third part=
y, then (a) makes the most sense to me. However, I am not sure if we should=
 or can do that at the transfer protocol level. It sounds like the pattern =
Peter described belongs to a REST application interface design instead...




Zach



--

Zach Shelby, Chief Nerd, Sensinode Ltd.

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

http://6lowpan.net - M=
y book "6LoWPAN: The Wireless Embedded Internet"

Mobile: +358 40 7796297





_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--0016367ed5df28a0ab0493646d9f--

From mab@comnets.uni-bremen.de  Mon Oct 25 02:47:16 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7908B3A6983 for ; Mon, 25 Oct 2010 02:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.949
X-Spam-Level: 
X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp38cK6LRppB for ; Mon, 25 Oct 2010 02:47:14 -0700 (PDT)
Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id 7968F3A69A7 for ; Mon, 25 Oct 2010 02:47:11 -0700 (PDT)
Received: from shelbyville.comnets.uni-bremen.de (shelbyville.comnets.uni-bremen.de [134.102.155.175]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id C08C9D40715; Mon, 25 Oct 2010 11:48:51 +0200 (CEST)
From: Markus Becker 
Organization: Comnets, University Bremen
To: core@ietf.org
Date: Mon, 25 Oct 2010 11:48:50 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.5.1; i686; ; )
References: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de> <336496E8-2D34-41A4-91E9-14F70E7D0634@tzi.org>
In-Reply-To: <336496E8-2D34-41A4-91E9-14F70E7D0634@tzi.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201010251148.51237.mab@comnets.uni-bremen.de>
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 09:47:16 -0000

> > In case of a loss of an asynchronous response (CON tid=3D783 ..message =
in
> > figure 3) from the server, who will take an action on retransmission? 1.
> >  Does the server send the CON message with data again after some xx
> > time?
>=20
> Yes.

It would be favorable if this would be clearly mentioned in the draft.

We see a problem with the current asynchronous operation if the server is=20
retransmitting. If all asynchronous CON responses (even retransmitted ones)=
=20
are lost, client behaviour is not defined. (Client has received ACK for CON=
=20
request, but does not receive any CON response with data.)=20

> > 2.  Does the client send GET message again after some xx time?
> >=20
> > For asynchronous transmission as explained in figure 3, can=E2=80=99t w=
e do as
> > follows? 1.  The client sends CON GET to the server without knowing
> > whether syn/asyn txs. 2.  The server sends ACK as in Figure 3, but with
> > a Processing-Delay option if the response gets delayed. (the experiments
> > we did here show that to get temperature/humidity results from an
> > embedded device, it takes about ~300 ms).
>=20
> Interesting data point.  300 ms should be comfortably within the 500 ms
> default retransmission timeout, though, unless the wireless media is
> congested.

300 ms was for a rather simple temperature/humidity sensor. Other types of=
=20
sensors might easily take more time, think accelaration sensor or video=20
sensor.

You are mentioning 500 ms. In the draft it is meant to be 1s per default. E=
ven=20
with 1s, we experience retransmissions in our M2M scenario, which involves =
a=20
GPRS link of 600ms to 1s RTT alone. Additionally, the 6lowpan implementatio=
n=20
we are using exhibits a 100ms + ~10ms/hop RTT in non congested case.

> > This Processing-Delay can be decided by the server based on the type of
> > URI. This lets the client to compute the waiting time to get the
> > asynchronous response. Example, Waiting-Time =3D (Processing-Delay +  R=
TT
> > + xx delay).
> >=20
> > If the client does not receive any delayed response from the server
> > within this Waiting-Time, the client should send again CON GET message.
> > I believe this would be a simple way to solve the above mentioned
> > issues.
>=20
> This might work where the server has a deterministic processing delay.
> A proxy may not be so lucky.  The result would be that we have a third ki=
nd
> of message exchange (one for immediate responses, one for deterministic
> responses, and one for non-deterministic responses).
>=20
> Of course, at the REST level, a "try again in nnn ms" code might solve a
> similar problem. Is the use case with a deterministic processing delay
> that does not fit in the default retransmission delay likely enough to
> warrant adding it?

Based on above data points, we are thinking that it is not an uncommon case=
=2E=20
Setting the retransmission parameters according to the link specifics is on=
e=20
option. Here we would have to set the value for the worst case (highest=20
processing + transmission delay).=20

By adding a delayed option in the async ACK, the client could dynamically=20
adjust the waiting time for each resource.

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

Best regards,
Markus

=2D-----------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
=2D-----------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: mab@comnets.uni-bremen.de
| telephone: +49 421 218 62379
| building: NW1 room: N2260
=2D-----------------------------------------------

From mab@comnets.uni-bremen.de  Mon Oct 25 02:48:40 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534873A69C5 for ; Mon, 25 Oct 2010 02:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level: 
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pBmWam8G0UP for ; Mon, 25 Oct 2010 02:48:39 -0700 (PDT)
Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id C6FA53A681E for ; Mon, 25 Oct 2010 02:48:38 -0700 (PDT)
Received: from shelbyville.comnets.uni-bremen.de (shelbyville.comnets.uni-bremen.de [134.102.155.175]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 06470D40715; Mon, 25 Oct 2010 11:50:23 +0200 (CEST)
From: Markus Becker 
Organization: Comnets, University Bremen
To: core@ietf.org
Date: Mon, 25 Oct 2010 11:50:21 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.5.1; i686; ; )
References: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201010251150.22061.mab@comnets.uni-bremen.de>
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 09:48:40 -0000

> As Carsten notes, the defined behavior is your option 1 (server retransmits
> con response message).
> 
> I agree there is some uncertainty resulting from the asynchronous response
> not having a time limit, and I too would rather have it resolved so I don't
> have to hold onto request state in the client for an unbounded period, in
> hopes that eventually my answer will come.
> 
> I read what you're suggesting as an elective header option, to be placed in
> the ACK that indicates an asynchronous response, providing an upper bound
> on how long the client should expect to wait for a response.

An additional header option, yes. However, not sure about elective or 
critical. It needs to be elective option because it is in a ACK. (Can ACKs or 
RSTs include critical options at all?) It would however also need to be 
understood by all clients, because client behaviour after receiving the ACK is 
not yet defined properly ('request state for unbounded period').

> Further, we should give it a reasonable default.   31 seconds may elapse
> between first CON transmission and last CON retransmission given the
> default settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which point
> the server will give up.  A default of 60 allows about 29 seconds for the
> server to create the response representation before risking the client
> giving up too soon.
>
> Then a client that has not received the response after that time plus a
> fudge term for network delays can assume the message is lost and recover in
> whatever way is appropriate (e.g., retransmit the GET or give up).
>
> I like this. 

You are proposing the waiting time to be the processing time + time for 
retransmissions + network delays. What we suggested was the processing time + 
network delay of the response (without considering retransmissions of the 
server) and then let the client try the retransmission. We thought of this 
because of high delay links easily triggering unnecessary retransmissions.

> On Thu, Oct 21, 2010 at 4:46 AM, Koojana Kuladinithi <
> koo@comnets.uni-bremen.de> wrote:
[snip]
> > 2.  The server sends ACK as in Figure 3, but with a Processing-Delay
> > option if the response gets delayed. (the experiments we did here show
> > that to get temperature/humidity results from an embedded device, it
> > takes about ~300 ms). This Processing-Delay can be decided by the server
> > based on the type of URI. This lets the client to compute the waiting
> > time to get the asynchronous response. Example, Waiting-Time =
> > (Processing-Delay +  RTT + xx delay).

> BTW: We did all realize that servers supporting asynchronous responses
> should keep hold of the TID for the original request in the client response
> record, so that if the server ACK gets lost and the client retransmits it
> isn't interpreted as a new request, right?  I don't think I've seen that
> called out explicitly anywhere.

True.
 
Best regards,
Markus

> Peter
> 
> > 
> > 
> > 
> > If the client does not receive any delayed response from the server
> > within this Waiting-Time, the client should send again CON GET message.
> > I believe this would be a simple way to solve the above mentioned
> > issues.
> > 
> > 
> > 
> > 
> > 
> > Kind regards
> > 
> > 
> > 
> > Koojana
> > 
> > 
> > 
> > Koojana Kuladinithi
> > 
> > University of Bremen, FB1 - IKOM/TZI
> > 
> > Otto-Hahn Allee NW1, 28359, Bremen, Germany
> > 
> > Tel. +49 421 218 62382, Fax. +49 421 218 3601,
> > 
> > www:
> > http://www.comnets.uni-bremen.de/~koo > 7Ekoo>
> > 
> > 
> > 
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: mab@comnets.uni-bremen.de
| telephone: +49 421 218 62379
| building: NW1 room: N2260
------------------------------------------------

From mab@comnets.uni-bremen.de  Mon Oct 25 02:59:51 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3260B3A67F9 for ; Mon, 25 Oct 2010 02:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.816
X-Spam-Level: 
X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD4Kni84BRHu for ; Mon, 25 Oct 2010 02:59:49 -0700 (PDT)
Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id B0D313A681B for ; Mon, 25 Oct 2010 02:59:49 -0700 (PDT)
Received: from shelbyville.comnets.uni-bremen.de (shelbyville.comnets.uni-bremen.de [134.102.155.175]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 36824D40715 for ; Mon, 25 Oct 2010 12:01:33 +0200 (CEST)
From: Markus Becker 
Organization: Comnets, University Bremen
To: core 
Date: Mon, 25 Oct 2010 12:01:32 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.5.1; i686; ; )
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201010251201.32492.mab@comnets.uni-bremen.de>
Subject: [core] Critical/elective options in CON/NON/ACK/RST
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 09:59:51 -0000

Hi,

can it be made explicit in Table 2 (Options headers) of draft-ietf-core-coap 
which option header might appear in which type of transaction message 
(CON/NON/ACK/RST)? Or are all (current) options possible in all transaction 
types?

What happens for critical options in NON/ACK/RST? Section 2.5.1 only specifies 
the behaviour for CON. This is additional to ticket #27.

Best regards,
Markus
------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: mab@comnets.uni-bremen.de
| telephone: +49 421 218 62379
| building: NW1 room: N2260
------------------------------------------------

From zach@sensinode.com  Mon Oct 25 03:03:03 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA173A6991 for ; Mon, 25 Oct 2010 03:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.367
X-Spam-Level: 
X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-7sUc78zdcQ for ; Mon, 25 Oct 2010 03:03:02 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 21CB03A6983 for ; Mon, 25 Oct 2010 03:03:01 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9PA4fOL003855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Oct 2010 13:04:42 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-188-456238440; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: <201010251201.32492.mab@comnets.uni-bremen.de>
Date: Mon, 25 Oct 2010 13:04:43 +0300
Message-Id: <3DB99CCD-41B6-459D-90DC-C96C07314A15@sensinode.com>
References: <201010251201.32492.mab@comnets.uni-bremen.de>
To: Markus Becker 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] Critical/elective options in CON/NON/ACK/RST
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 10:03:04 -0000

--Apple-Mail-188-456238440
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Markus,

I am working on the coap-03 submission today, and will take a look at =
this.

On Oct 25, 2010, at 1:01 PM, Markus Becker wrote:

> Hi,
>=20
> can it be made explicit in Table 2 (Options headers) of =
draft-ietf-core-coap=20
> which option header might appear in which type of transaction message=20=

> (CON/NON/ACK/RST)? Or are all (current) options possible in all =
transaction=20
> types?

Need to take a look if that makes sense.

>=20
> What happens for critical options in NON/ACK/RST?

The message must be ignored in that case at the REST layer. At the =
transaction layer the ACK should still be used to fulfill the CON, and =
the RST to reset a transaction.=20

Zach

> Section 2.5.1 only specifies=20
> the behaviour for CON. This is additional to ticket #27.
>=20
> Best regards,
> Markus
> ------------------------------------------------
> | Dipl.-Ing. Markus Becker
> | Communication Networks
> | Mobile Research Center
> | TZI - Center for Computing Technologies
> | University Bremen
> | Germany
> ------------------------------------------------
> | web: http://www.comnets.uni-bremen.de/~mab/
> | mailto: mab@comnets.uni-bremen.de
> | telephone: +49 421 218 62379
> | building: NW1 room: N2260
> ------------------------------------------------
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

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


--Apple-Mail-188-456238440
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNTEwMDQ0
NFowIwYJKoZIhvcNAQkEMRYEFPo2heHcKmT6uipTyopGRChut2wRMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAD7Dn5OTm9GzBWz7S9uN/BlO4QbvwTm0N6ylMP9dzmPRwYK/aIuJTrpk
ukwEZJ/Oz0r9FZp12Df1ouRWA4gNtnuQvx8fMceUZlyAwpXfn1X+ycqHUm+dZXgw+JplhJTep7uh
rsDZ5td+DShj6WufOWivw26/QVRLxM2XgAgvNMitU4miruEIA64ik9HFgGGwaUOuBMKZ+prZZ+8v
hKYzIEC5yCnUCe8udKySW5ENRIedicT6gopw5D6LX5Dqq7nWDEqeUu81By2OrUG6R4JbBodWwEHg
6psuBO+G8zxkGMHz6OF42b5C91OCfurQifZFVF4HzI1FNRMX66lwmOsYvmkAAAAAAAA=

--Apple-Mail-188-456238440--

From angelo.castellani@gmail.com  Mon Oct 25 03:09:44 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848B83A69AC for ; Mon, 25 Oct 2010 03:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.058
X-Spam-Level: 
X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbiqlVJpiMYl for ; Mon, 25 Oct 2010 03:09:43 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 2F5303A6998 for ; Mon, 25 Oct 2010 03:09:43 -0700 (PDT)
Received: by qyk1 with SMTP id 1so1204622qyk.10 for ; Mon, 25 Oct 2010 03:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=FQ4bnnsNeOQQLKUXrWEV1bf5HhX1gWHWF/u9IUCPHTQ=; b=xWc+OQXd7Md2xUEqK3UFpIPtQFZsliOa3Tr0ucF+TC+xggyugHcWcmY8cBUs8QsGNq xeU+Q2OY8XXsdEVQEiclLQWjcpHrB0K/CUjs7aCyDGCJJsEHpMRqQWAxB2gFpOwhATj1 CQqf40mPU+7iLp4Q8wc9riXgghxNBl8p26h/s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=rhO2cxzz1AvdWzY4XPBFFWcAVCUFzNnG9eZTwulAoOo1knzJOfsPOTjn6mt+Smo5yN /+wbYwAO2twyQdSDsx0dt6Ytt/HhufodRk+XSRgm2dd86qoHz0wbeFt0PYE/y7eh7VC2 15OZogxbAtVL6DQfvlD5dEVDwGoB3JW7qkCag=
Received: by 10.229.233.80 with SMTP id jx16mr5991937qcb.62.1288001485979; Mon, 25 Oct 2010 03:11:25 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.229.249.201 with HTTP; Mon, 25 Oct 2010 03:11:05 -0700 (PDT)
In-Reply-To: 
References:    
From: "Angelo P. Castellani" 
Date: Mon, 25 Oct 2010 12:11:05 +0200
X-Google-Sender-Auth: f1ZM52QrYqLncBHs4kr5hU41l8I
Message-ID: 
To: Klaus Hartke 
Content-Type: multipart/alternative; boundary=00163630fb5f0ac27604936e37bc
Cc: core 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 10:09:44 -0000

--00163630fb5f0ac27604936e37bc
Content-Type: text/plain; charset=ISO-8859-1

I agree with Peter, see this old discussion on the topic:

http://www.ietf.org/mail-archive/web/core/current/msg00236.html
http://www.ietf.org/mail-archive/web/core/current/msg00243.html

In my opinion designing a protocol that can be simply used by constrained
objects is the main target here.

There is a lot of state involved in the current design, and when concurrent
subscriptions with multiple end-points are in place the current transaction
layer cannot handle it and tokens are required (I pointed out this issue at
the Maastricht meeting too...).

M2M operation should be simplified by CoAP, and in this context even without
multicast an endpoint may request multiple endpoint to collaborate and to
serve some data to it recurrently on the resource in charge of handle this
kind of data.

As Klaus notes, this resource can be the holding the state a token would,
but can also be a prearranged resource to collect data. In my opinion it's a
more flexible and more RESTful solution to the subscription problem.

Moreover HTTP mapping is straightforward and a proxy/gateway in the middle
has no need to handle the token state to route and translate the request to
the right HTTP endpoint.

Angelo

On Fri, Oct 22, 2010 at 20:16, Klaus Hartke  wrote:

> I think the question is, basically: What do we subscribe to an
> observable resource, and how does an observer relate a notification to
> a subscription or resource?
>
> Currently, notifications are always sent to the transport address of
> the subscribing node, and include the resource URI and/or a
> subscriber-supplied token.
>
> We can extend this with an option in the subscription request to
> subscribe a third party. When it's present, notifications are sent to
> the transport address specified in this option, instead of the
> transport address of the subscribing node. The specified transport
> address may specify a multicast address. Notifications include the
> resource URI and/or a subscriber-supplied token.
>
> Note how this is equivalent to subscribing an URI to a resource:
>
> (a)
> Send-Notifications-To: client:61616
> Token: 0xad657b38
>
> (b)
> Callback-Uri: coap://client:61616/ad657b38
>
> When the authority in (a) or (b) denotes a multicast group,
> subscribers are free to observe the resource by joining the
> corresponding group and recognizing the "0xad657b38" token or
> "/ad657b38" path.
>
> However, (b) implies that there is a RESTful resource at
> coap://client:61616/ad657b38. This complicates a lot of things,
> because
>
> - we do not really want a RESTful resource, just something the server
> can send notifications to,
>
> - we could only update the RESTful resource using a PUT request, which
> is not the same as a notification.
>
> So (a) is the way to go. (That is, if we want to allow subscribing
> third parties. When I presented the idea of subscribing a multicast
> group to an observable resource in Maastricht, there was unanimous
> consensus that this was the worst idea ever.)
>
>
> Klaus
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--00163630fb5f0ac27604936e37bc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree with Peter, see this old discussion on the topic:

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


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

In my opinion designing a protocol that can be simp=
ly used by constrained objects is the main target here.




There is a lot of state involved in the current design,=
 and when concurrent subscriptions with multiple end-points are in place th=
e current transaction layer cannot handle it and tokens are required (I poi=
nted out this issue at the Maastricht meeting too...).




M2M operation should be simplified by CoAP, and in this=
 context even without multicast an endpoint may request multiple endpoint t=
o collaborate and to serve some data to it recurrently on the resource in c=
harge of handle this kind of data.




As Klaus notes, this resource can be the holding the st=
ate a token would, but can also be a prearranged resource to collect data. =
In my opinion it's a more flexible and more RESTful solution to the sub=
scription problem.




Moreover HTTP mapping is straightforward and a proxy/ga=
teway in the middle has no need to handle the token state to route and tran=
slate the request to the right HTTP endpoint.



Angelo

On Fri, Oct 22, =
2010 at 20:16, Klaus Hartke <hartke@tzi.org> wrote:


I think the question is, basically: What do we subscribe to an

observable resource, and how does an observer relate a notification to

a subscription or resource?



Currently, notifications are always sent to the transport address of

the subscribing node, and include the resource URI and/or a

subscriber-supplied token.



We can extend this with an option in the subscription request to

subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the

transport address of the subscribing node. The specified transport

address may specify a multicast address. Notifications include the

resource URI and/or a subscriber-supplied token.



Note how this is equivalent to subscribing an URI to a resource:



(a)

Send-Notifications-To: client:61616

Token: 0xad657b38



(b)

Callback-Uri: coap://client:61616/ad657b38



When the authority in (a) or (b) denotes a multicast group,


subscribers are free to observe the resource by joining t=
he


corresponding group and recognizing the "0xad657b38" token =
or

"/ad657b38" path.



However, (b) implies that there is a RESTful resource at

coap://client:61616/ad657b38. This complicates a lot of things,

because



- we do not really want a RESTful resource, just something the server

can send notifications to,



- we could only update the RESTful resource using a PUT request, which

is not the same as a notification.



So (a) is the way to go. (That is, if we want to allow subscribing

third parties. When I presented the idea of subscribing a multicast

group to an observable resource in Maastricht, there was unanimous

consensus that this was the worst idea ever.)






Klaus

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--00163630fb5f0ac27604936e37bc--

From cabo@tzi.org  Mon Oct 25 04:40:21 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E883A69B1 for ; Mon, 25 Oct 2010 04:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.162
X-Spam-Level: 
X-Spam-Status: No, score=-106.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q0ZbvVdexeB for ; Mon, 25 Oct 2010 04:40:20 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 712613A695F for ; Mon, 25 Oct 2010 04:40:19 -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 o9PBftgI015133; Mon, 25 Oct 2010 13:41:55 +0200 (CEST)
Received: from [192.168.217.101] (p5489B82D.dip.t-dialin.net [84.137.184.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EDE0A498; Mon, 25 Oct 2010 13:41:54 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <3DB99CCD-41B6-459D-90DC-C96C07314A15@sensinode.com>
Date: Mon, 25 Oct 2010 13:41:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7086089A-982D-4823-94DA-8529B9758B0F@tzi.org>
References: <201010251201.32492.mab@comnets.uni-bremen.de> <3DB99CCD-41B6-459D-90DC-C96C07314A15@sensinode.com>
To: Zach Shelby 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] Critical/elective options in CON/NON/ACK/RST
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 11:40:21 -0000

On Oct 25, 2010, at 12:04, Zach Shelby wrote:

>> What happens for critical options in NON/ACK/RST?
>=20
> The message must be ignored in that case at the REST layer.

(I think you are talking about critical options not understood by the =
recipient...)
Indeed, NON should be ignored.
For ACK and RST, a response with a critical option that is not =
understood also causes an error for the outstanding transaction at the =
REST layer; similar to a situation where an error code 400 had been =
returned.  In other words, the original request could not be fulfilled =
without some critical addition to the response, and if the original =
requester does not understand that critical addition, the response needs =
to be converted to something like a parameter problem.

> At the transaction layer the ACK should still be used to fulfill the =
CON, and the RST to reset a transaction.=20

Yes.

Gruesse, Carsten


From pab@peoplepowerco.com  Mon Oct 25 05:39:33 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4963A67D4 for ; Mon, 25 Oct 2010 05:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level: 
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.286,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1Hb0OvFTjoy for ; Mon, 25 Oct 2010 05:39:32 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9729F3A67FB for ; Mon, 25 Oct 2010 05:39:31 -0700 (PDT)
Received: by fxm9 with SMTP id 9so2243009fxm.31 for ; Mon, 25 Oct 2010 05:41:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.199.17 with SMTP id b17mr8087515muq.107.1288010475653; Mon, 25 Oct 2010 05:41:15 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Mon, 25 Oct 2010 05:41:15 -0700 (PDT)
In-Reply-To: <201010251150.22061.mab@comnets.uni-bremen.de>
References: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de>  <201010251150.22061.mab@comnets.uni-bremen.de>
Date: Mon, 25 Oct 2010 07:41:15 -0500
Message-ID: 
From: Peter Bigot 
To: Markus Becker 
Content-Type: multipart/alternative; boundary=0016369cfeffde77430493704e28
Cc: core@ietf.org
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 12:39:34 -0000

--0016369cfeffde77430493704e28
Content-Type: text/plain; charset=ISO-8859-1

You're right: I'd inappropriately included retransmissions when proposing a
default, somehow thinking that perhaps this delay was introduced or visible
at the REST layer.  While this could be done, it is more naturally cast as a
pseudo-REST or CoAP-layer concept, as is asynchronous responses, and
retransmissions are irrelevant.

The purpose of the default was to remove the undefined behavior in the base
document.  If the option description doesn't make the base document, a
default is unnecessary.  Similarly, the option might as well be elective in
that case, because system designers couldn't assume clients will implement
the option anyway and for usability a system must be robust in the presence
of clients that don't know how long they should wait (where "robust" should
not mean sending a critical option that may cause the client to fail its
request unnecessarily).

Question: I understand, maybe incorrectly, that there's a huge push to get
CoAP to RFC status ASAP, and that the WG's period-of-performance ends in
December.  Is there any chance for options and major changes that won't be
in coap-03 being added before CoAP becomes an RFC?  Or do we need to start
writing separate documents for this sort of thing?

Peter

On Mon, Oct 25, 2010 at 4:50 AM, Markus Becker wrote:

> > As Carsten notes, the defined behavior is your option 1 (server
> retransmits
> > con response message).
> >
> > I agree there is some uncertainty resulting from the asynchronous
> response
> > not having a time limit, and I too would rather have it resolved so I
> don't
> > have to hold onto request state in the client for an unbounded period, in
> > hopes that eventually my answer will come.
> >
> > I read what you're suggesting as an elective header option, to be placed
> in
> > the ACK that indicates an asynchronous response, providing an upper bound
> > on how long the client should expect to wait for a response.
>
> An additional header option, yes. However, not sure about elective or
> critical. It needs to be elective option because it is in a ACK. (Can ACKs
> or
> RSTs include critical options at all?) It would however also need to be
> understood by all clients, because client behaviour after receiving the ACK
> is
> not yet defined properly ('request state for unbounded period').
>
> > Further, we should give it a reasonable default.   31 seconds may elapse
> > between first CON transmission and last CON retransmission given the
> > default settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which point
> > the server will give up.  A default of 60 allows about 29 seconds for the
> > server to create the response representation before risking the client
> > giving up too soon.
> >
> > Then a client that has not received the response after that time plus a
> > fudge term for network delays can assume the message is lost and recover
> in
> > whatever way is appropriate (e.g., retransmit the GET or give up).
> >
> > I like this.
>
> You are proposing the waiting time to be the processing time + time for
> retransmissions + network delays. What we suggested was the processing time
> +
> network delay of the response (without considering retransmissions of the
> server) and then let the client try the retransmission. We thought of this
> because of high delay links easily triggering unnecessary retransmissions.
>
> > On Thu, Oct 21, 2010 at 4:46 AM, Koojana Kuladinithi <
> > koo@comnets.uni-bremen.de> wrote:
> [snip]
> > > 2.  The server sends ACK as in Figure 3, but with a Processing-Delay
> > > option if the response gets delayed. (the experiments we did here show
> > > that to get temperature/humidity results from an embedded device, it
> > > takes about ~300 ms). This Processing-Delay can be decided by the
> server
> > > based on the type of URI. This lets the client to compute the waiting
> > > time to get the asynchronous response. Example, Waiting-Time =
> > > (Processing-Delay +  RTT + xx delay).
>
> > BTW: We did all realize that servers supporting asynchronous responses
> > should keep hold of the TID for the original request in the client
> response
> > record, so that if the server ACK gets lost and the client retransmits it
> > isn't interpreted as a new request, right?  I don't think I've seen that
> > called out explicitly anywhere.
>
> True.
>
> Best regards,
> Markus
>
> > Peter
> >
> > >
> > >
> > >
> > > If the client does not receive any delayed response from the server
> > > within this Waiting-Time, the client should send again CON GET message.
> > > I believe this would be a simple way to solve the above mentioned
> > > issues.
> > >
> > >
> > >
> > >
> > >
> > > Kind regards
> > >
> > >
> > >
> > > Koojana
> > >
> > >
> > >
> > > Koojana Kuladinithi
> > >
> > > University of Bremen, FB1 - IKOM/TZI
> > >
> > > Otto-Hahn Allee NW1, 28359, Bremen, Germany
> > >
> > > Tel. +49 421 218 62382, Fax. +49 421 218 3601,
> > >
> > > www:
> > > http://www.comnets.uni-bremen.de/~koo
>  > > 7Ekoo>
> > >
> > >
> > >
> > > _______________________________________________
> > > core mailing list
> > > core@ietf.org
> > > https://www.ietf.org/mailman/listinfo/core
> ------------------------------------------------
> | Dipl.-Ing. Markus Becker
> | Communication Networks
> | Mobile Research Center
> | TZI - Center for Computing Technologies
> | University Bremen
> | Germany
> ------------------------------------------------
> | web: http://www.comnets.uni-bremen.de/~mab/
> | mailto: mab@comnets.uni-bremen.de
> | telephone: +49 421 218 62379
> | building: NW1 room: N2260
> ------------------------------------------------
>

--0016369cfeffde77430493704e28
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

You're right: I'd inappropriately included retransmissions when pro=
posing a default, somehow thinking that perhaps this delay was introduced o=
r visible at the REST layer.=A0 While this could be done, it is more natura=
lly cast as a pseudo-REST or CoAP-layer concept, as is asynchronous respons=
es, and retransmissions are irrelevant.


The purpose of the default was to remove the undefined behavior in the =
base document.=A0 If the option description doesn't make the base docum=
ent, a default is unnecessary.=A0 Similarly, the option might as well be el=
ective in that case, because system designers couldn't assume clients w=
ill implement
 the option anyway and for usability a system must be robust in the=20
presence of clients that don't know how long they should wait (where &q=
uot;robust" should not mean sending a critical option that may cause t=
he client to fail its request unnecessarily).

Question: I understand=
, maybe incorrectly, that there's a huge push to get CoAP to RFC status=
 ASAP, and that the WG's period-of-performance ends in December.=A0 Is =
there any chance for options and major changes that won't be in coap-03=
 being added before CoAP becomes an RFC?=A0 Or do we need to start writing =
separate documents for this sort of thing?


Peter

On Mon, Oct 25, 2010 at 4:50 AM=
, Markus Becker <mab@comnets.uni-bremen.de> wrote:


> As Carsten notes, the defined behavior is your optio=
n 1 (server retransmits

> con response message).

>

> I agree there is some uncertainty resulting from the asynchronous resp=
onse

> not having a time limit, and I too would rather have it resolved so I =
don't

> have to hold onto request state in the client for an unbounded period,=
 in

> hopes that eventually my answer will come.

>

> I read what you're suggesting as an elective header option, to be =
placed in

> the ACK that indicates an asynchronous response, providing an upper bo=
und

> on how long the client should expect to wait for a response.




An additional header option, yes. However, not sure about elective or=


critical. It needs to be elective option because it is in a ACK. (Can ACKs =
or

RSTs include critical options at all?) It would however also need to be

understood by all clients, because client behaviour after receiving the ACK=
 is

not yet defined properly ('request state for unbounded period').



> Further, we should give it a reasonable default. =A0 31 seconds may el=
apse

> between first CON transmission and last CON retransmission given the
> default settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which poin=
t

> the server will give up. =A0A default of 60 allows about 29 seconds fo=
r the

> server to create the response representation before risking the client=


> giving up too soon.

>

> Then a client that has not received the response after that time plus =
a

> fudge term for network delays can assume the message is lost and recov=
er in

> whatever way is appropriate (e.g., retransmit the GET or give up).

>

> I like this.




You are proposing the waiting time to be the processing time + time f=
or

retransmissions + network delays. What we suggested was the processing time=
 +

network delay of the response (without considering retransmissions of the
server) and then let the client try the retransmission. We thought of this<=
br>
because of high delay links easily triggering unnecessary retransmissions.<=
br>



> On Thu, Oct 21, 2010 at 4:46 AM, Koojana Kuladinithi <

> koo@comnets.uni-bremen.de=
> wrote:


[snip]


> > 2. =A0The server sends ACK as in Figure 3, but =
with a Processing-Delay

> > option if the response gets delayed. (the experiments we did here=
 show

> > that to get temperature/humidity results from an embedded device,=
 it

> > takes about ~300 ms). This Processing-Delay can be decided by the=
 server

> > based on the type of URI. This lets the client to compute the wai=
ting

> > time to get the asynchronous response. Example, Waiting-Time =3D<=
br>
> > (Processing-Delay + =A0RTT + xx delay).




> BTW: We did all realize that servers supportin=
g asynchronous responses

> should keep hold of the TID for the original request in the client res=
ponse

> record, so that if the server ACK gets lost and the client retransmits=
 it

> isn't interpreted as a new request, right? =A0I don't think I&=
#39;ve seen that

> called out explicitly anywhere.




True.



Best regards,

Markus



> Peter


>

> >

> >

> >

> > If the client does not receive any delayed response from the serv=
er

> > within this Waiting-Time, the client should send again CON GET me=
ssage.

> > I believe this would be a simple way to solve the above mentioned=


> > issues.

> >

> >

> >

> >

> >

> > Kind regards

> >

> >

> >

> > Koojana

> >

> >

> >

> > Koojana Kuladinithi

> >

> > University of Bremen, FB1 - IKOM/TZI

> >

> > Otto-Hahn Allee NW1, 28359, Bremen, Germany

> >

> > Tel. +49 421 218 62382, Fax. +49 421 218 3601,

> >

> > www:


> > http://www.comnets.uni-bremen.de/~koo<http://www.comnets.uni-breme=
n.de/%


> > 7Ekoo>


> >

> >

> >

> > _______________________________________________

> > core mailing list

> > core@ietf.org

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


-----------------------------------=
-------------

| Dipl.-Ing. Markus Becker

| Communication Networks

| Mobile Research Center

| TZI - Center for Computing Technologies

| University Bremen

| Germany

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

| web: http://www.comnets.uni-bremen.de/~mab/

| mailto: mab@comnets.uni-brem=
en.de

| telephone: +49 421 218 62379

| building: NW1 room: N2260

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





--0016369cfeffde77430493704e28--

From pab@peoplepowerco.com  Mon Oct 25 05:46:02 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A6F3A6A0C for ; Mon, 25 Oct 2010 05:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.283,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3eeTouM9IBP for ; Mon, 25 Oct 2010 05:46:01 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5FB053A69F6 for ; Mon, 25 Oct 2010 05:46:00 -0700 (PDT)
Received: by fxm9 with SMTP id 9so2249693fxm.31 for ; Mon, 25 Oct 2010 05:47:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.173.5 with SMTP id a5mr2770805mup.59.1288010864675; Mon, 25 Oct 2010 05:47:44 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Mon, 25 Oct 2010 05:47:44 -0700 (PDT)
In-Reply-To: <2919EC53-416C-4E85-B69D-EED2BEA63215@sensinode.com>
References:  <71FE4DE2-B472-45F0-83AE-FBE8E5559368@tzi.org>   <63849857-95F4-4D50-A33E-F50A0E665F00@sensinode.com>  <2919EC53-416C-4E85-B69D-EED2BEA63215@sensinode.com>
Date: Mon, 25 Oct 2010 07:47:44 -0500
Message-ID: 
From: Peter Bigot 
To: Zach Shelby 
Content-Type: multipart/alternative; boundary=0016364177cf0e4e2604937066b6
Cc: Robert Quattlebaum , core 
Subject: Re: [core] Next/Range Options (re: draft-ietf-core-block-00)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 12:46:03 -0000

--0016364177cf0e4e2604937066b6
Content-Type: text/plain; charset=ISO-8859-1

The proposed size option, as well as the asynchronous delay estimate option,
would both IMO be appropriate for core-coap and would significantly decrease
the number of cases where compliant behavior is unclear.

Peter

On Sat, Oct 23, 2010 at 2:46 PM, Zach Shelby  wrote:

>
> On Oct 22, 2010, at 4:56 PM, Peter Bigot wrote:
>
> > Rewrite of which document?  core-coap or core-block?  I'd assumed
> core-coap was pretty nearly frozen, but if not, let's do this.
>
>
> ;-) coap-block of course. What we are discussing there doesn't affect
> core-coap much. Of course we need to keep them aligned.
>
> Zach
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>

--0016364177cf0e4e2604937066b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The proposed size option, as well as the asynchronous delay estimate option=
, would both IMO be appropriate for core-coap and would significantly decre=
ase the number of cases where compliant behavior is unclear.

Peter

On Sat, Oct 23, 2010 at 2:46 PM, Zach Shelby=
 <zach@sensinode=
.com> wrote:




On Oct 22, 2010, at 4:56 PM, Peter Bigot wrote:



> Rewrite of which document? =A0core-coap or core-block? =A0I'd assu=
med core-coap was pretty nearly frozen, but if not, let's do this.






;-) coap-block of course. What we are discussing there doesn't af=
fect core-coap much. Of course we need to keep them aligned.




Zach



--

Zach Shelby, Chief Nerd, Sensinode Ltd.

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

http://6lowpan.net - M=
y book "6LoWPAN: The Wireless Embedded Internet"

Mobile: +358 40 7796297







--0016364177cf0e4e2604937066b6--

From angelo.castellani@gmail.com  Mon Oct 25 06:43:31 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82833A6A32 for ; Mon, 25 Oct 2010 06:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level: 
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut50o66wNCYj for ; Mon, 25 Oct 2010 06:43:27 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 693A23A6A36 for ; Mon, 25 Oct 2010 06:37:26 -0700 (PDT)
Received: by qwb7 with SMTP id 7so1344063qwb.31 for ; Mon, 25 Oct 2010 06:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=WXYJjr6Y6UQARq1bVJistnJKoyHplLV5g6cVq3dOgf0=; b=A31WYQvsVvl2xIgOuRbvbx8OlFqjERreWutish21oDM+FPHl5wrsabFynYh9cWdmwb 2nyIbbwZJqxFqO0w+pXBgVcRv7aXCkpbdIvGRDtZPua9MfmikMKD6yqUqsg0hrlMTxcy SYavnlaUkBtosc6RgDcKV0jkgs3PAVfcH9q0Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Woikc+uVQXbatXH0dilCQHsrLCKSCzG78ZvmKE7LY0mB6CZlV0qJwaJwfyz+O87vJY rIP9oIzUdI9kE6jdpkapE2N2MS/1O4/EtEIOqOJag4w2pnVRb6vMROTwNgM8Qt560mY7 1czQtkgFUnNc6cZu0tZy8jWmXykEvei/xPSG4=
Received: by 10.229.221.17 with SMTP id ia17mr4069938qcb.270.1288013891503; Mon, 25 Oct 2010 06:38:11 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.229.249.201 with HTTP; Mon, 25 Oct 2010 06:37:50 -0700 (PDT)
In-Reply-To: 
References:     
From: "Angelo P. Castellani" 
Date: Mon, 25 Oct 2010 15:37:50 +0200
X-Google-Sender-Auth: Qsva4s0eGNbSeBO6GQh-iMf4Di4
Message-ID: 
To: Klaus Hartke 
Content-Type: multipart/alternative; boundary=0016362842987805dc0493711aab
Cc: core 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 13:43:31 -0000

--0016362842987805dc0493711aab
Content-Type: text/plain; charset=ISO-8859-1

The main idea around this is to have a Source-URI Option to be used for:

a) subscription to define the resource that will be collecting notifications
b) notification to advertise the resource that is currently sending the
notification

In this way the current coap-observe proposal architecture remains the same,
but both URLs are sent in each transaction (as in CoAP, short URLs are
recommended).

In my opinion, this addition eases HTTP mapping, adds flexibility and adds
full support for concurrent subscriptions.

Best,
Angelo

On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani
wrote:

> I agree with Peter, see this old discussion on the topic:
>
> http://www.ietf.org/mail-archive/web/core/current/msg00236.html
> http://www.ietf.org/mail-archive/web/core/current/msg00243.html
>
> In my opinion designing a protocol that can be simply used by constrained
> objects is the main target here.
>
> There is a lot of state involved in the current design, and when concurrent
> subscriptions with multiple end-points are in place the current transaction
> layer cannot handle it and tokens are required (I pointed out this issue at
> the Maastricht meeting too...).
>
> M2M operation should be simplified by CoAP, and in this context even
> without multicast an endpoint may request multiple endpoint to collaborate
> and to serve some data to it recurrently on the resource in charge of handle
> this kind of data.
>
> As Klaus notes, this resource can be the holding the state a token would,
> but can also be a prearranged resource to collect data. In my opinion it's a
> more flexible and more RESTful solution to the subscription problem.
>
> Moreover HTTP mapping is straightforward and a proxy/gateway in the middle
> has no need to handle the token state to route and translate the request to
> the right HTTP endpoint.
>
> Angelo
>
> On Fri, Oct 22, 2010 at 20:16, Klaus Hartke  wrote:
>
>> I think the question is, basically: What do we subscribe to an
>> observable resource, and how does an observer relate a notification to
>> a subscription or resource?
>>
>> Currently, notifications are always sent to the transport address of
>> the subscribing node, and include the resource URI and/or a
>> subscriber-supplied token.
>>
>> We can extend this with an option in the subscription request to
>> subscribe a third party. When it's present, notifications are sent to
>> the transport address specified in this option, instead of the
>> transport address of the subscribing node. The specified transport
>> address may specify a multicast address. Notifications include the
>> resource URI and/or a subscriber-supplied token.
>>
>> Note how this is equivalent to subscribing an URI to a resource:
>>
>> (a)
>> Send-Notifications-To: client:61616
>> Token: 0xad657b38
>>
>> (b)
>> Callback-Uri: coap://client:61616/ad657b38
>>
>> When the authority in (a) or (b) denotes a multicast group,
>> subscribers are free to observe the resource by joining the
>> corresponding group and recognizing the "0xad657b38" token or
>> "/ad657b38" path.
>>
>> However, (b) implies that there is a RESTful resource at
>> coap://client:61616/ad657b38. This complicates a lot of things,
>> because
>>
>> - we do not really want a RESTful resource, just something the server
>> can send notifications to,
>>
>> - we could only update the RESTful resource using a PUT request, which
>> is not the same as a notification.
>>
>> So (a) is the way to go. (That is, if we want to allow subscribing
>> third parties. When I presented the idea of subscribing a multicast
>> group to an observable resource in Maastricht, there was unanimous
>> consensus that this was the worst idea ever.)
>>
>>
>> Klaus
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>
>

--0016362842987805dc0493711aab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The main idea around this is to have a Source-URI Option to be used for:
a) subscription to define the resource that will be collec=
ting notifications
b) notification to advertise the resource that=
 is currently sending the notification




In this way the current coap-observe proposal architect=
ure remains the same, but both URLs are sent in each transaction (as in CoA=
P, short URLs are recommended).

In my opinion, thi=
s addition eases HTTP mapping, adds flexibility and adds full support for c=
oncurrent subscriptions.




Best,
Angelo


On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <<=
a href=3D"mailto:angelo@castellani.net" target=3D"_blank">angelo@castellani=
.net> wrote:



I agree with Peter, see this old discussion on the topic:

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






In my opinion designing a protoco=
l that can be simply used by constrained objects is the main target here.





There is a lot of state involved in the current design,=
 and when concurrent subscriptions with multiple end-points are in place th=
e current transaction layer cannot handle it and tokens are required (I poi=
nted out this issue at the Maastricht meeting too...).






M2M operation should be simplified by CoAP, and in this=
 context even without multicast an endpoint may request multiple endpoint t=
o collaborate and to serve some data to it recurrently on the resource in c=
harge of handle this kind of data.






As Klaus notes, this resource can be the holding the st=
ate a token would, but can also be a prearranged resource to collect data. =
In my opinion it's a more flexible and more RESTful solution to the sub=
scription problem.






Moreover HTTP mapping is straightforward and a proxy/ga=
teway in the middle has no need to handle the token state to route and tran=
slate the request to the right HTTP endpoint.





Angelo

On Fri, Oct 22, 2010 at 20:16, Klaus Hartke &=
lt;hartke@tzi.org&g=
t; wrote:





I think the question is, basically: What do we subscribe to an

observable resource, and how does an observer relate a notification to

a subscription or resource?



Currently, notifications are always sent to the transport address of

the subscribing node, and include the resource URI and/or a

subscriber-supplied token.



We can extend this with an option in the subscription request to

subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the

transport address of the subscribing node. The specified transport

address may specify a multicast address. Notifications include the

resource URI and/or a subscriber-supplied token.



Note how this is equivalent to subscribing an URI to a resource:



(a)

Send-Notifications-To: client:61616

Token: 0xad657b38



(b)

Callback-Uri: coap://client:61616/ad657b38



When the authority in (a) or (b) denotes a multicast group,


subscribers are free to observe the resource by joining the


corresponding group and recognizing the "0xad657b38" token =
or

"/ad657b38" path.



However, (b) implies that there is a RESTful resource at

coap://client:61616/ad657b38. This complicates a lot of things,

because



- we do not really want a RESTful resource, just something the server

can send notifications to,



- we could only update the RESTful resource using a PUT request, which

is not the same as a notification.



So (a) is the way to go. (That is, if we want to allow subscribing

third parties. When I presented the idea of subscribing a multicast

group to an observable resource in Maastricht, there was unanimous

consensus that this was the worst idea ever.)






Klaus

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core










--0016362842987805dc0493711aab--

From klaus.hartke@googlemail.com  Mon Oct 25 06:51:57 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D813A6849 for ; Mon, 25 Oct 2010 06:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHK9ot0qPR-D for ; Mon, 25 Oct 2010 06:51:56 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3D0BD3A681B for ; Mon, 25 Oct 2010 06:51:55 -0700 (PDT)
Received: by bwz12 with SMTP id 12so3483602bwz.31 for ; Mon, 25 Oct 2010 06:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=UN1/D5NIWWN7IxfJuPam9VhmWJoIZfz/sJgJT2iDijc=; b=qgn2XiSIxtfoNSjEjYMLiEHeVUejLR/QI95r56sn4XOrA+SK3X5j6X3xcacViwaeoe TH2Ew958oiH8ZeQZ4C7tE/e54Uxr0zwPr5J1J2F+yBeTH1jfFGS2OPtHvC21Fvh7a2f/ 7OJ8ZvWZtaW52LRb71D2r1uYLbq1gJHO6iNAs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=wQ3Uo5I0qHVtsCIV4dEIKxAdzQTwQxxgWeP94paV4zt8+hOnhV9sjwq5HIdS/G5WdB sqnzb5tpMj9Jy9uvm6B7JYUi9+ah21ihPtwpQk13TZSOLoCkVNCd6SuZ+OHiSZW/NmL6 IdUcHhWgfwTC8bIVgel2MmhTS5L4KFkrjdS04=
MIME-Version: 1.0
Received: by 10.204.66.12 with SMTP id l12mr4198473bki.81.1288014820345; Mon, 25 Oct 2010 06:53:40 -0700 (PDT)
Sender: klaus.hartke@googlemail.com
Received: by 10.204.101.65 with HTTP; Mon, 25 Oct 2010 06:53:40 -0700 (PDT)
In-Reply-To: 
References:     <61C991A8-A377-4135-B96C-9379CD475029@sensinode.com> 
Date: Mon, 25 Oct 2010 15:53:40 +0200
X-Google-Sender-Auth: H83pIYqbNSFPYX5Osn3zgLEvbXM
Message-ID: 
From: Klaus Hartke 
To: core 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 13:51:57 -0000

Peter Bigot wrote:
> I don't need the proposed subscription options

And I don't need GET, PUT or DELETE.
POST is good enough for me to do that.

But we do have GET, PUT, DELETE and POST in CoAP, because they have
different semantics and it's beneficial to make the meaning of a
message available not only to the sender and recipient, but also to
the intermediary nodes along the way.

The same applies when it comes to observing resources. I guess it is
possible to do subscriptions on top of CoAP, using only basic CoAP
operations without subscription-related options. But then we lose the
benefit of knowing what a PUT request means.

For example, a notification always comes with a set of meta data such
as Etag and Max-Age. When an intermediary node sees a notification, it
knows that the state of a particular resource has changed to a
particular state, and can cache the present representation.

In a PUT request, Etag or Max-Age is not defined. Both are managed by
the origin server, not provided by the client when it supplies a new
resource state. When an intermediary node sees a PUT request, it
cannot make any assumptions about the state of the resource, and it
knows nothing about any sender resources.

A notification has really more in common with a response than with a request.

If you don't need intermediary nodes be aware of what's going on,
nothing prevents you from implementing observation with base CoAP. But
I think if you try to address all aspects of integrating a
subscription/notify mechanism into a RESTful environment, you end up
with a duct tape solution that is much more complex than making the
step and introducing a subscription option.

(To clarify: I'm all in for making things simpler. Reifying observers
into URIs feels really natural. In fact, that's what I had implemented
in my first experimental implementation before I started working on
-observe. But when I proceeded to work out the details, I had to give
up the idea. If you can find a solution that is simpler and works,
let's do it.)

Klaus

From zach@sensinode.com  Mon Oct 25 06:58:32 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABDB83A69B1 for ; Mon, 25 Oct 2010 06:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8cajswtBeIK for ; Mon, 25 Oct 2010 06:58:31 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DC5073A683F for ; Mon, 25 Oct 2010 06:58:30 -0700 (PDT)
Received: from [192.168.11.10] ([213.145.207.93]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9PE0ABR004935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Oct 2010 17:00:11 +0300
From: Zach Shelby 
Content-Type: multipart/signed; boundary=Apple-Mail-209-470367972; protocol="application/pkcs7-signature"; micalg=sha1
Date: Mon, 25 Oct 2010 17:00:13 +0300
Message-Id: <7DAABF04-D171-4681-9C59-3E34220388FE@sensinode.com>
To: core 
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [core] Comments on draft-rahman-core-groupcomm-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 13:58:32 -0000

--Apple-Mail-209-470367972
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Here are my comments on the draft. Overall, I think it is great to =
discuss this all in one place.=20


Section 3.1.3. Group Discovery

- This section claims that ietf-core-link-format is limited to =
link-local multicast scope. This is not correct. ietf-core-coap has no =
limitation on what kinds of multicast addresses it can be used with. I =
think this is maybe being confused with mDNS, which is limited to =
link-local scope?

- I do agree that if DNS is being used to manage the resolution between =
an authority and a mulicast address, then adding more metadata about =
those groups would make sense using DNS-SD. However, DNS is not always =
available in constrained networks. How to discovery available multicast =
addresses without DNS?=20

Section 3.1.4. Group Resource Manipulation

- It is suggested that multicast GET be restricted to link-local =
scope... why?

- Why must multicast requests be sent to the default CoAP port?

- What does "All multicast requests should operate on /.well-known/core =
URIs?" mean.=20

- I am not sure that this requires a notation like coapm:// as we are =
dealing with IP multicast here, and the resolution is done by DNS.

3.1.5.2. Reliable IP Multicast

- It would be good to mention that in order to make a multicast request =
reliable, the client MUST know the members of group g.=20

- We should explore whether it is better to retransmit a multicast =
request using individual unicast requests to members of the group g that =
did not ACK.=20

4. Group Management

- I don't get this section at all. First you spent a lot of time =
explaining how DNS can be used to resolve an authority to a multicast IP =
address. Wouldn't you then manage IP multicast group membership using =
standard tools plus DNS updates? I don't see any need for overloading =
the base CoAP protocol with special options for doing that.=20

5.1. Serial Unicast

s/group URI/authority ?

6. CoAP and HTTP interworking

- Do we need/want/care if HTTP has access to multicast requests? This =
whole concept doesn't exist in HTTP, so I think it would be better for =
an intermediate node to create a new resource out of combined multicast =
responses for access by HTTP. We should think about the requirements =
carefully before trying to do fancy things here.=20

7. Security

- I would love to see a lot more here about msec and the use of IPsec =
for multicast requests. This will be needed as a contribution to =
ietf-core-coap eventually.


Zach

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


--Apple-Mail-209-470367972
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNTE0MDAx
M1owIwYJKoZIhvcNAQkEMRYEFJZqSrwEdaubUrxOOKtgNioK2mszMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAA6Nxz7TgsbTejPEcwtZ+FnMrE3PQ0x6P90BiapHd+1IkBbWKi7BgJ35
Bgj3YuhWUI4VrLbh7CS2LvdH0uY7w+w73bHsWS7m+CC9n+dB5nELEZPWyLWJAKP5GjEHOsAdhcMV
mj6ImY8mCZyTuaS/2OKv73LPNktsQ1BLib76eN8PwWSSEhFgpGWM+zk189OXDEAeu8havzmVKZPC
j0CUwtxPmnjGAD2y4x8C5KSOdLx/qgcZpxxSJV5i4RvJq8xy0eewKQwJmQ2RGMvZvBrzIyq/8Qfa
UwNnXwvvs2AvrNzNaIa/XmikqcrCBgD1wPlrmg7/KB36AYW/H3bIlWfhmzYAAAAAAAA=

--Apple-Mail-209-470367972--

From pab@peoplepowerco.com  Mon Oct 25 07:26:38 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD783A69C2 for ; Mon, 25 Oct 2010 07:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.374
X-Spam-Level: 
X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.602,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRCHs68cx1r8 for ; Mon, 25 Oct 2010 07:26:36 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 5A7733A688C for ; Mon, 25 Oct 2010 07:26:36 -0700 (PDT)
Received: by gwb17 with SMTP id 17so2223957gwb.31 for ; Mon, 25 Oct 2010 07:28:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.2.10 with SMTP id e10mr6732684mui.134.1288016899950; Mon, 25 Oct 2010 07:28:19 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Mon, 25 Oct 2010 07:28:19 -0700 (PDT)
In-Reply-To: 
References:      
Date: Mon, 25 Oct 2010 09:28:19 -0500
Message-ID: 
From: Peter Bigot 
To: "Angelo P. Castellani" 
Content-Type: multipart/alternative; boundary=0016e65aedfac9483b049371cdb2
Cc: core , Klaus Hartke 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 14:26:38 -0000

--0016e65aedfac9483b049371cdb2
Content-Type: text/plain; charset=ISO-8859-1

Curious: why add a Source-URI option, rather than put the URI in the body of
the subscription request?  The body's not used for anything else in this
case (it's a GET, isn't it?).  I can see some motivation for putting it in
the response, but would suggest that the target of the response is adequate
to distinguish the sender (if you're doing fan-in, add a distinguishing path
component to the URI in the subscription request, like
coap://collector/temps/south, coap://collector/temps/north for an aggregate
resource coap://collector/temps).  It'd make the messages shorter, too.

BTW: to correct my example, I now believe the notification by the origin
should be a POST to the callback or notification URI, not a PUT.  The
implication is that the receiving resource is an actor that will process the
notification, not a data store that will hold its value.

Alternatively, which method should be used might be controllable by the
subscriber: in the case of sleeping nodes, the state at an always-up cache
which is the authority for a general-use URI for the resource is pure
storage.  The sleeping node that is the real resource owner can reasonably
PUT the value there.  (Though this is really a fairly special case of
notification, if it's notification at all.)

Klaus: You may well be right.  I suspect that using the natural semantics of
REST operations will allow the effect of intermediate nodes to be exactly
what's expected from REST, but can't say for sure because I haven't done a
deep analysis.  Without asking you to provide a more detailed summary of
your own analysis and assumptions than I've seen, I  have not yet myself
seen a compelling need to modify the protocol, especially in a way that
results in multiple responses to what is naively a single request.  I still
believe a perfectly workable and clear solution can be reached using base
CoAP as it's defined today.

In any case, PUT or POST, subscription or callback, perhaps subscriptions
are better expressed by defining content-types for subscription descriptions
and notifications, rather than adding options to the header and changing the
transaction layer state machine.  This would clearly provide the information
required by intermediate nodes.

Just a thought.

Peter

On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani  wrote:

> The main idea around this is to have a Source-URI Option to be used for:
>
> a) subscription to define the resource that will be collecting
> notifications
> b) notification to advertise the resource that is currently sending the
> notification
>
> In this way the current coap-observe proposal architecture remains the
> same, but both URLs are sent in each transaction (as in CoAP, short URLs are
> recommended).
>
> In my opinion, this addition eases HTTP mapping, adds flexibility and adds
> full support for concurrent subscriptions.
>
> Best,
> Angelo
>
> On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani  > wrote:
>
>> I agree with Peter, see this old discussion on the topic:
>>
>> http://www.ietf.org/mail-archive/web/core/current/msg00236.html
>> http://www.ietf.org/mail-archive/web/core/current/msg00243.html
>>
>> In my opinion designing a protocol that can be simply used by constrained
>> objects is the main target here.
>>
>> There is a lot of state involved in the current design, and when
>> concurrent subscriptions with multiple end-points are in place the current
>> transaction layer cannot handle it and tokens are required (I pointed out
>> this issue at the Maastricht meeting too...).
>>
>> M2M operation should be simplified by CoAP, and in this context even
>> without multicast an endpoint may request multiple endpoint to collaborate
>> and to serve some data to it recurrently on the resource in charge of handle
>> this kind of data.
>>
>> As Klaus notes, this resource can be the holding the state a token would,
>> but can also be a prearranged resource to collect data. In my opinion it's a
>> more flexible and more RESTful solution to the subscription problem.
>>
>> Moreover HTTP mapping is straightforward and a proxy/gateway in the middle
>> has no need to handle the token state to route and translate the request to
>> the right HTTP endpoint.
>>
>> Angelo
>>
>> On Fri, Oct 22, 2010 at 20:16, Klaus Hartke  wrote:
>>
>>> I think the question is, basically: What do we subscribe to an
>>> observable resource, and how does an observer relate a notification to
>>> a subscription or resource?
>>>
>>> Currently, notifications are always sent to the transport address of
>>> the subscribing node, and include the resource URI and/or a
>>> subscriber-supplied token.
>>>
>>> We can extend this with an option in the subscription request to
>>> subscribe a third party. When it's present, notifications are sent to
>>> the transport address specified in this option, instead of the
>>> transport address of the subscribing node. The specified transport
>>> address may specify a multicast address. Notifications include the
>>> resource URI and/or a subscriber-supplied token.
>>>
>>> Note how this is equivalent to subscribing an URI to a resource:
>>>
>>> (a)
>>> Send-Notifications-To: client:61616
>>> Token: 0xad657b38
>>>
>>> (b)
>>> Callback-Uri: coap://client:61616/ad657b38
>>>
>>> When the authority in (a) or (b) denotes a multicast group,
>>> subscribers are free to observe the resource by joining the
>>> corresponding group and recognizing the "0xad657b38" token or
>>> "/ad657b38" path.
>>>
>>> However, (b) implies that there is a RESTful resource at
>>> coap://client:61616/ad657b38. This complicates a lot of things,
>>> because
>>>
>>> - we do not really want a RESTful resource, just something the server
>>> can send notifications to,
>>>
>>> - we could only update the RESTful resource using a PUT request, which
>>> is not the same as a notification.
>>>
>>> So (a) is the way to go. (That is, if we want to allow subscribing
>>> third parties. When I presented the idea of subscribing a multicast
>>> group to an observable resource in Maastricht, there was unanimous
>>> consensus that this was the worst idea ever.)
>>>
>>>
>>> Klaus
>>> _______________________________________________
>>> 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
>
>

--0016e65aedfac9483b049371cdb2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Curious: why add a Source-URI option, rather than put the URI in the body o=
f the subscription request?=A0 The body's not used for anything else in=
 this case (it's a GET, isn't it?).=A0 I can see some motivation fo=
r putting it in the response, but would suggest that the target of the resp=
onse is adequate to distinguish the sender (if you're doing fan-in, add=
 a distinguishing path component to the URI in the subscription request, li=
ke coap://collector/temps/south, coap://collector/temps/north for an aggreg=
ate resource coap://collector/temps).=A0 It'd make the messages shorter=
, too.


BTW: to correct my example, I now believe the notification by the origi=
n should be a POST to the callback or notification URI, not a PUT.=A0 The i=
mplication is that the receiving resource is an actor that will process the=
 notification, not a data store that will hold its value.



Alternatively, which method should be used might be controllable by the=
 subscriber: in the case of sleeping nodes, the state at an always-up cache=
 which is the authority for a general-use URI for the resource is pure stor=
age.=A0 The sleeping node that is the real resource owner can reasonably PU=
T the value there.=A0 (Though this is really a fairly special case of notif=
ication, if it's notification at all.)



Klaus: You may well be right.=A0 I suspect that using the natural seman=
tics of REST operations will allow the effect of intermediate nodes to be e=
xactly what's expected from REST, but can't say for sure because I =
haven't done a deep analysis.=A0 Without asking you to provide a more d=
etailed summary of your own analysis and assumptions than I've seen, I=
=A0 have not yet myself seen a compelling need to modify the protocol, espe=
cially in a way that results in multiple responses to what is naively a sin=
gle request.=A0 I still believe a perfectly workable and clear solution can=
 be reached using base CoAP as it's defined today.



In any case, PUT or POST, subscription or callback, perhaps subscriptio=
ns are better=20
expressed by defining content-types for subscription descriptions and notif=
ications,=20
rather than adding options to the header and changing the transaction layer=
 state machine.=A0 This would clearly provide the information required by i=
ntermediate nodes.

Just a thought.

Peter



On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <=
;angelo@castella=
ni.net> wrote:


The main idea around this is to have a Source-URI Option to be used for:
a) subscription to define the resource that will be collec=
ting notifications
b) notification to advertise the resource that=
 is currently sending the notification






In this way the current coap-observe proposal architect=
ure remains the same, but both URLs are sent in each transaction (as in CoA=
P, short URLs are recommended).

In my opinion, thi=
s addition eases HTTP mapping, adds flexibility and adds full support for c=
oncurrent subscriptions.






Best,
Angelo


On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <<=
a href=3D"mailto:angelo@castellani.net" target=3D"_blank">angelo@castellani=
.net> wrote:





I agree with Peter, see this old discussion on the topic:

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








In my opinion designing a protoco=
l that can be simply used by constrained objects is the main target here.







There is a lot of state involved in the current design,=
 and when concurrent subscriptions with multiple end-points are in place th=
e current transaction layer cannot handle it and tokens are required (I poi=
nted out this issue at the Maastricht meeting too...).








M2M operation should be simplified by CoAP, and in this=
 context even without multicast an endpoint may request multiple endpoint t=
o collaborate and to serve some data to it recurrently on the resource in c=
harge of handle this kind of data.








As Klaus notes, this resource can be the holding the st=
ate a token would, but can also be a prearranged resource to collect data. =
In my opinion it's a more flexible and more RESTful solution to the sub=
scription problem.








Moreover HTTP mapping is straightforward and a proxy/ga=
teway in the middle has no need to handle the token state to route and tran=
slate the request to the right HTTP endpoint.







Angelo

On Fri, Oct 22, 2010 at 20:16, Klaus Hartke &=
lt;hartke@tzi.org&g=
t; wrote:







I think the question is, basically: What do we subscribe to an

observable resource, and how does an observer relate a notification to

a subscription or resource?



Currently, notifications are always sent to the transport address of

the subscribing node, and include the resource URI and/or a

subscriber-supplied token.



We can extend this with an option in the subscription request to

subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the

transport address of the subscribing node. The specified transport

address may specify a multicast address. Notifications include the

resource URI and/or a subscriber-supplied token.



Note how this is equivalent to subscribing an URI to a resource:



(a)

Send-Notifications-To: client:61616

Token: 0xad657b38



(b)

Callback-Uri: coap://client:61616/ad657b38



When the authority in (a) or (b) denotes a multicast group,


subscribers are free to observe the resource by joining the


corresponding group and recognizing the "0xad657b38" token =
or

"/ad657b38" path.



However, (b) implies that there is a RESTful resource at

coap://client:61616/ad657b38. This complicates a lot of things,

because



- we do not really want a RESTful resource, just something the server

can send notifications to,



- we could only update the RESTful resource using a PUT request, which

is not the same as a notification.



So (a) is the way to go. (That is, if we want to allow subscribing

third parties. When I presented the idea of subscribing a multicast

group to an observable resource in Maastricht, there was unanimous

consensus that this was the worst idea ever.)






Klaus

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core











_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core







--0016e65aedfac9483b049371cdb2--

From pab@peoplepowerco.com  Mon Oct 25 07:31:26 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68F93A6A3A for ; Mon, 25 Oct 2010 07:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level: 
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=0.279,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ih5Q+x32YAhA for ; Mon, 25 Oct 2010 07:31:23 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 627713A6A2E for ; Mon, 25 Oct 2010 07:31:11 -0700 (PDT)
Received: by gxk7 with SMTP id 7so65065gxk.31 for ; Mon, 25 Oct 2010 07:32:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.247.2 with SMTP id z2mr3753485mur.56.1288017172221; Mon, 25 Oct 2010 07:32:52 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Mon, 25 Oct 2010 07:32:52 -0700 (PDT)
Date: Mon, 25 Oct 2010 09:32:52 -0500
Message-ID: 
From: Peter Bigot 
To: Zach Shelby 
Content-Type: multipart/alternative; boundary=0016364c43ea03d06d049371deab
Cc: core , Klaus Hartke 
Subject: [core] CoRE and REST metacomment
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 14:31:26 -0000

--0016364c43ea03d06d049371deab
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the historical background.

REST is not a cult; it's a carefully defined technical term describing a set
of architectural constraints which, when followed, tend to produce
architectures suitable for a distributed hypermedia system like the
world-wide web.

It's also a buzzword, adopted by people who look at the success of the web
and conclude that, if they design a system that's "RESTful", it will be just
as successful.  I'm not speaking of CoRE; all kinds of initiatives jump on
the REST bandwagon.  Unfortunately, many people don't understand what
constraints REST imposes and why, or that their problem domain might be
better suited by a different set of constraints.  Classic failure of
requirements validation.

I wasn't present at the inception of CoRE, but it seems likely the
buzzword-sense of REST contributed to why REST made it into the working
group's title, when it really has little to do with the technical content
described in the charter.  An architectural style based on peer-to-peer
transactions that reference local state to reduce communications overhead
rather than hierarchical stateless client-server transactions would be far
more natural for many problems involving constrained nodes, such as wireless
sensor network applications and M2M building management communications.

Presence of the term certainly distracted me from the fundamentals of the
problem and, I think, had a slight negative influence on the final design.
There's no reason why the requirement to define an adaptation interface
compatible with REST over HTTP should have had significant impact on the
internal architecture, but I believe it did.

Peter

On Sun, Oct 24, 2010 at 4:32 PM, Zach Shelby  wrote:

>
> On Oct 22, 2010, at 6:24 PM, Peter Bigot wrote:
>
> > Disclaimer: I have not changed my position that multicast with REST is an
> ill-defined concept.  This proposal came from my accepting the position that
> not everything CoAP enables has to be 100% consistent with REST.  Some of
> what falls out from things like applying CoAP to multicast addresses is very
> useful and worth adopting when REST is less important than efficiency.
>
>
> Just to synchronize... The intention of this WG was never to make CoAP 100%
> consistent with REST. That would be pretty hard considering there is no RFC
> defining what REST is exactly (seems to be some kind of cult...), the
> closest thing that we know is HTTP (which was very much designed for
> transferring hypermedia). The CoRE working group does aim to fit its work
> into the REST architecture, but I would say making CoAP (and the security
> work) useful for constrained nodes and networks in M2M applications to be
> our main goal. Thus I agree with you, multicast CoAP is worth developing,
> and is a must for most applications we are considering it for.
>
> Zach
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>

--0016364c43ea03d06d049371deab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the historical background.

REST is not a cult; it's a=
 carefully defined technical term describing a set of architectural constra=
ints which, when followed, tend to produce architectures suitable for a dis=
tributed hypermedia system like the world-wide web.



It's also a buzzword, adopted by people who look at the success of =
the web and conclude that, if they design a system that's "RESTful=
", it will be just as successful.=A0 I'm not speaking of CoRE; all=
 kinds of initiatives jump on the REST bandwagon.=A0 Unfortunately, many pe=
ople don't understand what constraints REST imposes and why, or that th=
eir problem domain might be better suited by a different set of constraints=
.=A0 Classic failure of requirements validation.



I wasn't present at the inception of CoRE, but it seems likely the =
buzzword-sense of REST contributed to why REST made it into the working gro=
up's title, when it really has little to do with the technical content =
described in the charter.=A0 An architectural style based on peer-to-peer t=
ransactions that reference local state to reduce communications overhead ra=
ther than hierarchical stateless client-server transactions would be far mo=
re natural for many problems involving constrained nodes, such as wireless =
sensor network applications and M2M building management communications.


Presence of the term certainly distracted me from the fundamentals of t=
he problem and, I think, had a slight negative influence on the final desig=
n.=A0 There's no reason why the requirement to define an adaptation int=
erface compatible=20
with REST over HTTP should have had significant impact on the internal=20
architecture, but I believe it did.


Peter

On Sun, Oct 24, 2010 at 4:32 PM=
, Zach Shelby <zach@sensinode.com> wrote:




On Oct 22, 2010, at 6:24 PM, Peter Bigot wrote:



> Disclaimer: I have not changed my position that multicast with REST is=
 an ill-defined concept. =A0This proposal came from my accepting the positi=
on that not everything CoAP enables has to be 100% consistent with REST. =
=A0Some of what falls out from things like applying CoAP to multicast addre=
sses is very useful and worth adopting when REST is less important than eff=
iciency.








Just to synchronize... The intention of this WG was never to make CoA=
P 100% consistent with REST. That would be pretty hard considering there is=
 no RFC defining what REST is exactly (seems to be some kind of cult...), t=
he closest thing that we know is HTTP (which was very much designed for tra=
nsferring hypermedia). The CoRE working group does aim to fit its work into=
 the REST architecture, but I would say making CoAP (and the security work)=
 useful for constrained nodes and networks in M2M applications to be our ma=
in goal. Thus I agree with you, multicast CoAP is worth developing, and is =
a must for most applications we are considering it for.





Zach



--

Zach Shelby, Chief Nerd, Sensinode Ltd.

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

http://6lowpan.net - M=
y book "6LoWPAN: The Wireless Embedded Internet"

Mobile: +358 40 7796297









--0016364c43ea03d06d049371deab--

From kerlyn2001@gmail.com  Mon Oct 25 07:54:09 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604143A6876 for ; Mon, 25 Oct 2010 07:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level: 
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OCtqg9hY6kD for ; Mon, 25 Oct 2010 07:54:07 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4A48B3A6A1C for ; Mon, 25 Oct 2010 07:54:07 -0700 (PDT)
Received: by bwz12 with SMTP id 12so3545595bwz.31 for ; Mon, 25 Oct 2010 07:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q8OF2yZh3GXdKhxn0+hz2vQ/JKpFaLFZkwFPv0PtsAk=; b=NiC9mUFIvQUdgQBivdBL1AwYfRxkdDN6a2+qYDkgoxeHG5OkBqvTuBgmlRHmnzWINy StGN7LJHSO0eA/J3GL8gRLWpvpahVgjennsWJV5uG9pMRRfzBMFn5xMJeWJL7d0WNFqG SoQkt8/4tOoP4qeHUAKCtWHssFm+qQR9dtnRQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nppbiOkWZavCwBxG/Uv6on13uUetPL8M2DRPRWGsdvF5qEiFphVhykKzVXOgITstjN 3GmiaEmkcBwNmgBRpxdEe8UkhLq7n8DseyCiU9DxXmgQ45GxeEHNNUmKbpOJg6/w3Cm+ DaAPEGZjBo+hcgujEhozEns0Mc2eQevC6uLDE=
MIME-Version: 1.0
Received: by 10.204.98.15 with SMTP id o15mr5150487bkn.136.1288018551746; Mon, 25 Oct 2010 07:55:51 -0700 (PDT)
Received: by 10.204.72.131 with HTTP; Mon, 25 Oct 2010 07:55:51 -0700 (PDT)
In-Reply-To: <7DAABF04-D171-4681-9C59-3E34220388FE@sensinode.com>
References: <7DAABF04-D171-4681-9C59-3E34220388FE@sensinode.com>
Date: Mon, 25 Oct 2010 10:55:51 -0400
Message-ID: 
From: Kerry Lynn 
To: Zach Shelby 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: core 
Subject: Re: [core] Comments on draft-rahman-core-groupcomm-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 14:54:09 -0000

Hi Zach,

On Mon, Oct 25, 2010 at 10:00 AM, Zach Shelby  wrote:
> Here are my comments on the draft.
>
Thanks for your comments.

> Overall, I think it is great to discuss this all in one place.
Me too.

>
> Section 3.1.3. Group Discovery
>
> - This section claims that ietf-core-link-format is limited to link-local=
 multicast scope. This is not correct. ietf-core-coap has no limitation on =
what kinds of multicast addresses it can be used with. I think this is mayb=
e being confused with mDNS, which is limited to link-local scope?
>
Good point, modulo the design of draft-ietf-6lowpan-hc to support
3306 and 3956 Unicast-Prefix-based IPv6 Multicast Addresses.

The language should say "in the absence of support for off-link
multicast" or something similar.

>From a BCP perspective, we should probably discuss the scaling
issues in better detail.

> - I do agree that if DNS is being used to manage the resolution between a=
n authority and a mulicast address, then adding more metadata about those g=
roups would make sense using DNS-SD. However, DNS is not always available i=
n constrained networks. How to discovery available multicast addresses with=
out DNS?

I'm sure you have ideas about this from a core-link perspective.
I still have not worked out the relationship between an MLD group
and DNS-SD group names.


>
> Section 3.1.4. Group Resource Manipulation
>
> - It is suggested that multicast GET be restricted to link-local scope...=
 why?
>
I think it was from a scaling perspective.

> - Why must multicast requests be sent to the default CoAP port?
>
> - What does "All multicast requests should operate on /.well-known/core U=
RIs?" mean.
>
The answer to both these is essentially the same.  Without well-know
targets for port and path, how do you increase the probability that all
members of a group receive or interpret the command in the same way?

> - I am not sure that this requires a notation like coapm:// as we are dea=
ling with IP multicast here, and the resolution is done by DNS.
>
The thinking here is that group comms might be implemented
as multicast, serial unicast, or some combination.  Having a
distinct scheme for group comms might signal the proxy
receiving the request to look up the group membership and
replicate serial unicasts as well as multicast packets.


> 3.1.5.2. Reliable IP Multicast
>
> - It would be good to mention that in order to make a multicast request r=
eliable, the client MUST know the members of group g.
>
> - We should explore whether it is better to retransmit a multicast reques=
t using individual unicast requests to members of the group g that did not =
ACK.
>


> 4. Group Management
>
> - I don't get this section at all. First you spent a lot of time explaini=
ng how DNS can be used to resolve an authority to a multicast IP address. W=
ouldn't you then manage IP multicast group membership using standard tools =
plus DNS updates? I don't see any need for overloading the base CoAP protoc=
ol with special options for doing that.
>
I believe the thinking here is that a group authority may represent
a list of IP addresses (perhaps a mix of unicast and multicast) and
current group membership protocols like IGMP and MLD don't
support these concepts.  I guess it's TBD whether coap wants to
invent a technique for membership in compound groups.


> 5.1. Serial Unicast
>
> s/group URI/authority ?
>
> 6. CoAP and HTTP interworking
>
> - Do we need/want/care if HTTP has access to multicast requests? This who=
le concept doesn't exist in HTTP, so I think it would be better for an inte=
rmediate node to create a new resource out of combined multicast responses =
for access by HTTP. We should think about the requirements carefully before=
 trying to do fancy things here.
>
> 7. Security
>
> - I would love to see a lot more here about msec and the use of IPsec for=
 multicast requests. This will be needed as a contribution to ietf-core-coa=
p eventually.
>
>
> Zach
>
Thanks, -K-

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

From root@core3.amsl.com  Mon Oct 25 08:00:02 2010
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 41D1B3A6876; Mon, 25 Oct 2010 08:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20101025150002.41D1B3A6876@core3.amsl.com>
Date: Mon, 25 Oct 2010 08:00:02 -0700 (PDT)
Cc: core@ietf.org
Subject: [core] I-D Action:draft-ietf-core-link-format-01.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 15:00:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.


	Title           : CoRE Link Format
	Author(s)       : Z. Shelby
	Filename        : draft-ietf-core-link-format-01.txt
	Pages           : 11
	Date            : 2010-10-25

This document defines a link format for use by constrained CoAP web
servers to describe URIs of resources offered along with other
attributes.  Based on the HTTP Link Header format, the CoRE link
format is carried as a payload and is assigned an Internet media
type.  A well-known URI is defined as a default entry-point for
requesting the list of links to resources hosted by a server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-core-link-format-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-25075557.I-D@ietf.org>


--NextPart--

From zach@sensinode.com  Mon Oct 25 08:03:32 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95FCD3A6858 for ; Mon, 25 Oct 2010 08:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOVHlRVQf9bN for ; Mon, 25 Oct 2010 08:03:31 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C8C673A689F for ; Mon, 25 Oct 2010 08:03:30 -0700 (PDT)
Received: from [192.168.11.10] ([213.145.207.93]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9PF5Bj1009153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Oct 2010 18:05:11 +0300
From: Zach Shelby 
Content-Type: multipart/signed; boundary=Apple-Mail-226-474268591; protocol="application/pkcs7-signature"; micalg=sha1
Date: Mon, 25 Oct 2010 18:05:13 +0300
References: <20101025145557.D64FB3A6A1D@core3.amsl.com>
To: core 
Message-Id: <3E7C7795-DD21-4DC0-AB81-13C182EB96FE@sensinode.com>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [core] Fwd: New Version Notification for draft-ietf-core-link-format-01
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 15:03:32 -0000

--Apple-Mail-226-474268591
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

http://www.ietf.org/id/draft-ietf-core-link-format-01.txt

I updated the link-format draft with the detailed feedback and contribs =
from Peter on the list. The changes don't really change the =
functionality of an implementation of -00, however please do notice the =
multicast issue in Section 3.1 if filtering is not supported (thanks to =
Guido for pointing that out).

Here is a summary of the changes:

   Changes from ietf-00 to ietf-01:

      o Editorial changes to correct references.

      o Formal definition for filter query string.

      o Removed URI-reference option from "n" and "id".

      o Added security text about multicast requests.

Zach

Begin forwarded message:

> From: IETF I-D Submission Tool 
> Date: October 25, 2010 5:55:57 PM GMT+03:00
> To: zach@sensinode.com
> Subject: New Version Notification for draft-ietf-core-link-format-01=20=

>=20
>=20
> A new version of I-D, draft-ietf-core-link-format-01.txt has been =
successfully submitted by Zach Shelby and posted to the IETF repository.
>=20
> Filename:	 draft-ietf-core-link-format
> Revision:	 01
> Title:		 CoRE Link Format
> Creation_date:	 2010-10-25
> WG ID:		 core
> Number_of_pages: 11
>=20
> Abstract:
> This document defines a link format for use by constrained CoAP web
> servers to describe URIs of resources offered along with other
> attributes.  Based on the HTTP Link Header format, the CoRE link
> format is carried as a payload and is assigned an Internet media
> type.  A well-known URI is defined as a default entry-point for
> requesting the list of links to resources hosted by a server.
>=20
>=20
>=20
> The IETF Secretariat.
>=20
>=20

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


--Apple-Mail-226-474268591
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNTE1MDUx
NFowIwYJKoZIhvcNAQkEMRYEFDncwMZSa32Q+8o7VwuNTLcsGDuNMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAGYE75IPvkJtbSb3fnOO+/4eH4CudR7QDxRLqPeektwL7AXox5/11dWd
gBqNO3m18MsQ2/Yd7+9yY5hrZh9n3+C4r8B0z6pe6qzCx+zaUZUINLPIdTiiRf1K1XOoab+cRVGy
Q3dIqiZ4mDgga1kFih3e0J2cSLLdC36Go+EZQfE8yIdiHsmKWRX8MPUFcXAW8dOcp/YZxbd+SIcz
45o9UPRI+Yw6kGk+VEgG6Dmx1DBoFZ7D9swYpEk6QgBDBPaa5YNVZvAD4RhFRTu1WPMfjcw8rn6B
inOv154MX/E8z4VcxQSJJtkgXuWOTfM1IljECi1fienlYZiad1ywgMFT64MAAAAAAAA=

--Apple-Mail-226-474268591--

From angelo.castellani@gmail.com  Mon Oct 25 08:09:58 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533273A6A5E for ; Mon, 25 Oct 2010 08:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level: 
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6QOEGuWY9ne for ; Mon, 25 Oct 2010 08:09:56 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 566BE3A6A4A for ; Mon, 25 Oct 2010 08:09:56 -0700 (PDT)
Received: by qyk5 with SMTP id 5so1582680qyk.10 for ; Mon, 25 Oct 2010 08:11:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=VyrOLqp8PS2AiKSZshJ1GWCsU8QNT7wNDUOUVhgo7ek=; b=FQ8VPxHVYETIWrGEIOoqOCBwilJEEoaN0Bw4RiD4UdFEPY1u2kboxu147DA8PV/M6B 0hye0srDlROZ78qMUYGU541us9826SsJUd6CRFUlBwWoMIzudg66b0Ai2Z/Zu30IAZ9E HQzwhmbMDjBNsju9wS/NXOQ+mZzwqMZNOc2tU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ZrnFH1zFuCW8DjyAjIiTy5i7LmzV4GG/BDrMEovUGilNLEA4VCeG5EUmdO7cy0fu4u aLQ8Kh7W+2NZ1NM0ycrCXUiFYTFae0Ohbuv3FSqyEMrwmmKkDIKZ8wB2zD8U5CEPQ/e/ /FQY1XS5us/1pM24Ux+lUAc3R+BRXWUUGRoW4=
Received: by 10.224.199.66 with SMTP id er2mr330067qab.15.1288019500314; Mon, 25 Oct 2010 08:11:40 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.229.249.201 with HTTP; Mon, 25 Oct 2010 08:11:13 -0700 (PDT)
In-Reply-To: 
References:       
From: "Angelo P. Castellani" 
Date: Mon, 25 Oct 2010 17:11:13 +0200
X-Google-Sender-Auth: apL0qaI5gLz4kWZYRytiSTOK8cU
Message-ID: 
To: Peter Bigot 
Content-Type: multipart/alternative; boundary=20cf300fb353c7aec90493726802
Cc: core , Klaus Hartke 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 15:09:58 -0000

--20cf300fb353c7aec90493726802
Content-Type: text/plain; charset=ISO-8859-1

The utility of defining subscription fully at CoAP level is to have a CoAP
implementation not dependant upon the resource; CoAP implementation itself
can provide subscription functionality for every resource that is handling..
In constrained nodes this is really useful to save ROM space on the MCU.

There are methods to save space in the payload, just an example: if
source-URI is omitted, source-URI is equal to URI; another option is that
the subscriber can ask not to send back the source-URI in the notifications.

I prefer to receive a status code in the response, not a generic POST (like
in current coap-observe document). I think that it's more useful and
moreover CoAP sw layer can implement subscription by duplicating the same
message with interval X locally limiting sw overhead above CoAP.

An addition: I was wondering why limit subscribe to a GET? If I subscribe
using a POST with fixed parameters, in that case the subscription equals
receiving that particular post every X seconds, if properly elaborated can
be useful under some special circumstances.

Best,
Angelo


On Mon, Oct 25, 2010 at 16:28, Peter Bigot  wrote:

> Curious: why add a Source-URI option, rather than put the URI in the body
> of the subscription request?  The body's not used for anything else in this
> case (it's a GET, isn't it?).  I can see some motivation for putting it in
> the response, but would suggest that the target of the response is adequate
> to distinguish the sender (if you're doing fan-in, add a distinguishing path
> component to the URI in the subscription request, like
> coap://collector/temps/south, coap://collector/temps/north for an aggregate
> resource coap://collector/temps).  It'd make the messages shorter, too.
>
> BTW: to correct my example, I now believe the notification by the origin
> should be a POST to the callback or notification URI, not a PUT.  The
> implication is that the receiving resource is an actor that will process the
> notification, not a data store that will hold its value.
>
> Alternatively, which method should be used might be controllable by the
> subscriber: in the case of sleeping nodes, the state at an always-up cache
> which is the authority for a general-use URI for the resource is pure
> storage.  The sleeping node that is the real resource owner can reasonably
> PUT the value there.  (Though this is really a fairly special case of
> notification, if it's notification at all.)
>
> Klaus: You may well be right.  I suspect that using the natural semantics
> of REST operations will allow the effect of intermediate nodes to be exactly
> what's expected from REST, but can't say for sure because I haven't done a
> deep analysis.  Without asking you to provide a more detailed summary of
> your own analysis and assumptions than I've seen, I  have not yet myself
> seen a compelling need to modify the protocol, especially in a way that
> results in multiple responses to what is naively a single request.  I still
> believe a perfectly workable and clear solution can be reached using base
> CoAP as it's defined today.
>
> In any case, PUT or POST, subscription or callback, perhaps subscriptions
> are better expressed by defining content-types for subscription descriptions
> and notifications, rather than adding options to the header and changing the
> transaction layer state machine.  This would clearly provide the information
> required by intermediate nodes.
>
> Just a thought.
>
> Peter
>
>
> On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <
> angelo@castellani.net> wrote:
>
>> The main idea around this is to have a Source-URI Option to be used for:
>>
>> a) subscription to define the resource that will be collecting
>> notifications
>> b) notification to advertise the resource that is currently sending the
>> notification
>>
>> In this way the current coap-observe proposal architecture remains the
>> same, but both URLs are sent in each transaction (as in CoAP, short URLs are
>> recommended).
>>
>> In my opinion, this addition eases HTTP mapping, adds flexibility and adds
>> full support for concurrent subscriptions.
>>
>> Best,
>> Angelo
>>
>> On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <
>> angelo@castellani.net> wrote:
>>
>>> I agree with Peter, see this old discussion on the topic:
>>>
>>> http://www.ietf.org/mail-archive/web/core/current/msg00236.html
>>> http://www.ietf.org/mail-archive/web/core/current/msg00243.html
>>>
>>> In my opinion designing a protocol that can be simply used by constrained
>>> objects is the main target here.
>>>
>>> There is a lot of state involved in the current design, and when
>>> concurrent subscriptions with multiple end-points are in place the current
>>> transaction layer cannot handle it and tokens are required (I pointed out
>>> this issue at the Maastricht meeting too...).
>>>
>>> M2M operation should be simplified by CoAP, and in this context even
>>> without multicast an endpoint may request multiple endpoint to collaborate
>>> and to serve some data to it recurrently on the resource in charge of handle
>>> this kind of data.
>>>
>>> As Klaus notes, this resource can be the holding the state a token would,
>>> but can also be a prearranged resource to collect data. In my opinion it's a
>>> more flexible and more RESTful solution to the subscription problem.
>>>
>>> Moreover HTTP mapping is straightforward and a proxy/gateway in the
>>> middle has no need to handle the token state to route and translate the
>>> request to the right HTTP endpoint.
>>>
>>> Angelo
>>>
>>> On Fri, Oct 22, 2010 at 20:16, Klaus Hartke  wrote:
>>>
>>>> I think the question is, basically: What do we subscribe to an
>>>> observable resource, and how does an observer relate a notification to
>>>> a subscription or resource?
>>>>
>>>> Currently, notifications are always sent to the transport address of
>>>> the subscribing node, and include the resource URI and/or a
>>>> subscriber-supplied token.
>>>>
>>>> We can extend this with an option in the subscription request to
>>>> subscribe a third party. When it's present, notifications are sent to
>>>> the transport address specified in this option, instead of the
>>>> transport address of the subscribing node. The specified transport
>>>> address may specify a multicast address. Notifications include the
>>>> resource URI and/or a subscriber-supplied token.
>>>>
>>>> Note how this is equivalent to subscribing an URI to a resource:
>>>>
>>>> (a)
>>>> Send-Notifications-To: client:61616
>>>> Token: 0xad657b38
>>>>
>>>> (b)
>>>> Callback-Uri: coap://client:61616/ad657b38
>>>>
>>>> When the authority in (a) or (b) denotes a multicast group,
>>>> subscribers are free to observe the resource by joining the
>>>> corresponding group and recognizing the "0xad657b38" token or
>>>> "/ad657b38" path.
>>>>
>>>> However, (b) implies that there is a RESTful resource at
>>>> coap://client:61616/ad657b38. This complicates a lot of things,
>>>> because
>>>>
>>>> - we do not really want a RESTful resource, just something the server
>>>> can send notifications to,
>>>>
>>>> - we could only update the RESTful resource using a PUT request, which
>>>> is not the same as a notification.
>>>>
>>>> So (a) is the way to go. (That is, if we want to allow subscribing
>>>> third parties. When I presented the idea of subscribing a multicast
>>>> group to an observable resource in Maastricht, there was unanimous
>>>> consensus that this was the worst idea ever.)
>>>>
>>>>
>>>> Klaus
>>>> _______________________________________________
>>>> 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
>>
>>
>

--20cf300fb353c7aec90493726802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The utility of defining subscription fully at CoAP level is to have a CoAP =
implementation not dependant upon the resource; CoAP implementation itself =
can provide subscription functionality for every resource that is handling.=
. In constrained nodes this is really useful to save ROM space on the MCU.<=
div>


There are methods to save space in the payload, just an=
 example: if source-URI is omitted, source-URI is equal to URI; another opt=
ion is that the subscriber can ask not to send back the source-URI in the n=
otifications.




I prefer to receive a status code in the response, not =
a generic POST (like in current coap-observe document). I think that it'=
;s more useful and moreover CoAP sw layer can implement subscription by dup=
licating the same message with interval X locally limiting sw overhead abov=
e CoAP.




An addition: I was wondering wh=
y limit subscribe to a GET? If I subscribe using a POST with fixed paramete=
rs, in that case the subscription equals receiving that particular post eve=
ry X seconds, if properly elaborated can be useful under some special circu=
mstances.




Best,
Angelo


On Mon, Oct 25, 2010 at 16:28, Peter Bigot <pab@peoplepowerco.com&g=
t; wrote:



Curious: why add a Source-URI option, rathe=
r than put the URI in the body of the subscription request?=A0 The body'=
;s not used for anything else in this case (it's a GET, isn't it?).=
=A0 I can see some motivation for putting it in the response, but would sug=
gest that the target of the response is adequate to distinguish the sender =
(if you're doing fan-in, add a distinguishing path component to the URI=
 in the subscription request, like coap://collector/temps/south, coap://col=
lector/temps/north for an aggregate resource coap://collector/temps).=A0 It=
'd make the messages shorter, too.




BTW: to correct my example, I now believe the notification by the origi=
n should be a POST to the callback or notification URI, not a PUT.=A0 The i=
mplication is that the receiving resource is an actor that will process the=
 notification, not a data store that will hold its value.





Alternatively, which method should be used might be controllable by the=
 subscriber: in the case of sleeping nodes, the state at an always-up cache=
 which is the authority for a general-use URI for the resource is pure stor=
age.=A0 The sleeping node that is the real resource owner can reasonably PU=
T the value there.=A0 (Though this is really a fairly special case of notif=
ication, if it's notification at all.)





Klaus: You may well be right.=A0 I suspect that using the natural seman=
tics of REST operations will allow the effect of intermediate nodes to be e=
xactly what's expected from REST, but can't say for sure because I =
haven't done a deep analysis.=A0 Without asking you to provide a more d=
etailed summary of your own analysis and assumptions than I've seen, I=
=A0 have not yet myself seen a compelling need to modify the protocol, espe=
cially in a way that results in multiple responses to what is naively a sin=
gle request.=A0 I still believe a perfectly workable and clear solution can=
 be reached using base CoAP as it's defined today.





In any case, PUT or POST, subscription or callback, perhaps subscriptio=
ns are better=20
expressed by defining content-types for subscription descriptions and notif=
ications,=20
rather than adding options to the header and changing the transaction layer=
 state machine.=A0 This would clearly provide the information required by i=
ntermediate nodes.

Just a thought.

Pe=
ter







On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <=
;angelo@castella=
ni.net> wrote:




The main idea around this is to have a Source-URI Option to be used for:
a) subscription to define the resource that will be collec=
ting notifications
b) notification to advertise the resource that=
 is currently sending the notification








In this way the current coap-observe proposal architect=
ure remains the same, but both URLs are sent in each transaction (as in CoA=
P, short URLs are recommended).

In my opinion, thi=
s addition eases HTTP mapping, adds flexibility and adds full support for c=
oncurrent subscriptions.








Best,
Angelo


On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <<=
a href=3D"mailto:angelo@castellani.net" target=3D"_blank">angelo@castellani=
.net> wrote:







I agree with Peter, see this old discussion on the topic:

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










In my opinion designing a protoco=
l that can be simply used by constrained objects is the main target here.









There is a lot of state involved in the current design,=
 and when concurrent subscriptions with multiple end-points are in place th=
e current transaction layer cannot handle it and tokens are required (I poi=
nted out this issue at the Maastricht meeting too...).










M2M operation should be simplified by CoAP, and in this=
 context even without multicast an endpoint may request multiple endpoint t=
o collaborate and to serve some data to it recurrently on the resource in c=
harge of handle this kind of data.










As Klaus notes, this resource can be the holding the st=
ate a token would, but can also be a prearranged resource to collect data. =
In my opinion it's a more flexible and more RESTful solution to the sub=
scription problem.










Moreover HTTP mapping is straightforward and a proxy/ga=
teway in the middle has no need to handle the token state to route and tran=
slate the request to the right HTTP endpoint.









Angelo

On Fri, Oct 22, 2010 at 20:16, Klaus Hartke &=
lt;hartke@tzi.org&g=
t; wrote:









I think the question is, basically: What do we subscribe to an

observable resource, and how does an observer relate a notification to

a subscription or resource?



Currently, notifications are always sent to the transport address of

the subscribing node, and include the resource URI and/or a

subscriber-supplied token.



We can extend this with an option in the subscription request to

subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the

transport address of the subscribing node. The specified transport

address may specify a multicast address. Notifications include the

resource URI and/or a subscriber-supplied token.



Note how this is equivalent to subscribing an URI to a resource:



(a)

Send-Notifications-To: client:61616

Token: 0xad657b38



(b)

Callback-Uri: coap://client:61616/ad657b38



When the authority in (a) or (b) denotes a multicast group,


subscribers are free to observe the resource by joining the


corresponding group and recognizing the "0xad657b38" token =
or

"/ad657b38" path.



However, (b) implies that there is a RESTful resource at

coap://client:61616/ad657b38. This complicates a lot of things,

because



- we do not really want a RESTful resource, just something the server

can send notifications to,



- we could only update the RESTful resource using a PUT request, which

is not the same as a notification.



So (a) is the way to go. (That is, if we want to allow subscribing

third parties. When I presented the idea of subscribing a multicast

group to an observable resource in Maastricht, there was unanimous

consensus that this was the worst idea ever.)






Klaus

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core











_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core









--20cf300fb353c7aec90493726802--

From pab@peoplepowerco.com  Mon Oct 25 08:47:17 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375AE3A6A75 for ; Mon, 25 Oct 2010 08:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXNl9ruicDbH for ; Mon, 25 Oct 2010 08:47:15 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 927513A6857 for ; Mon, 25 Oct 2010 08:47:14 -0700 (PDT)
Received: by vws6 with SMTP id 6so216980vws.31 for ; Mon, 25 Oct 2010 08:48:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.252.12 with SMTP id e12mr1051690mus.55.1288021735018; Mon, 25 Oct 2010 08:48:55 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Mon, 25 Oct 2010 08:48:54 -0700 (PDT)
In-Reply-To: 
References:        
Date: Mon, 25 Oct 2010 10:48:54 -0500
Message-ID: 
From: Peter Bigot 
To: "Angelo P. Castellani" 
Content-Type: multipart/alternative; boundary=001636417153fb15ea049372eddf
Cc: core , Klaus Hartke 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 15:47:17 -0000

--001636417153fb15ea049372eddf
Content-Type: text/plain; charset=ISO-8859-1

But it's the application level above REST, not CoAP, that determines what
GET, PUT, and especially POST and DELETE mean with respect to a particular
resource and content-type.  I don't think this can be done purely at the
CoAP level.  It would require that the CoAP transaction layer be notified of
every change to resource state to kick off distribution to subscribers, and
possibly that it be able to up-call to the application to retrieve a
resource representation without having a REST request to drive it (or that
it replay the REST request that created the subscription, including all its
companion options and message body, possibly violating the business logic
associated with the resource).

Attempting to account for all that within the transaction layer is pretty
difficult.  Time-driven auto-generation within CoAP, either of notifications
(subscribed GET) or of incoming updates (subscribed POST), also seems like
something that is better handled at the application layer where the
policy-related decisions can be managed.

I'm coming to feel that there's a resource A , there's optionally a second
resource B that provides subscription services for resource A if that's
appropriate, and there's arbitrary resources Ci that have been registered
through B to receive updates when the owner of A has detected a change.  A
"subscribable" resource A makes its subscription manager B visible through
the link description, and everything "just works".

Everything else is managed at the application layer.  Note that each one of
those subscribers might require a different representation (content-type),
or due to other characteristics be given a different view of the resource,
and only the application level can reliable identify (and retain) those
characteristics.  Or, in fact, determine whether a proposed subscription
should be accepted, if the resource content is sensitive.

I don't think the goal in your first sentence is the best way to save ROM
and satisfy domain business logic.  An application-level capability would do
this at least as well, and more generally.

Peter

On Mon, Oct 25, 2010 at 10:11 AM, Angelo P. Castellani <
angelo@castellani.net> wrote:

> The utility of defining subscription fully at CoAP level is to have a CoAP
> implementation not dependant upon the resource; CoAP implementation itself
> can provide subscription functionality for every resource that is handling..
> In constrained nodes this is really useful to save ROM space on the MCU.
>
> There are methods to save space in the payload, just an example: if
> source-URI is omitted, source-URI is equal to URI; another option is that
> the subscriber can ask not to send back the source-URI in the notifications.
>
> I prefer to receive a status code in the response, not a generic POST (like
> in current coap-observe document). I think that it's more useful and
> moreover CoAP sw layer can implement subscription by duplicating the same
> message with interval X locally limiting sw overhead above CoAP.
>
> An addition: I was wondering why limit subscribe to a GET? If I subscribe
> using a POST with fixed parameters, in that case the subscription equals
> receiving that particular post every X seconds, if properly elaborated can
> be useful under some special circumstances.
>
> Best,
> Angelo
>
>
>
> On Mon, Oct 25, 2010 at 16:28, Peter Bigot  wrote:
>
>> Curious: why add a Source-URI option, rather than put the URI in the body
>> of the subscription request?  The body's not used for anything else in this
>> case (it's a GET, isn't it?).  I can see some motivation for putting it in
>> the response, but would suggest that the target of the response is adequate
>> to distinguish the sender (if you're doing fan-in, add a distinguishing path
>> component to the URI in the subscription request, like
>> coap://collector/temps/south, coap://collector/temps/north for an aggregate
>> resource coap://collector/temps).  It'd make the messages shorter, too.
>>
>> BTW: to correct my example, I now believe the notification by the origin
>> should be a POST to the callback or notification URI, not a PUT.  The
>> implication is that the receiving resource is an actor that will process the
>> notification, not a data store that will hold its value.
>>
>> Alternatively, which method should be used might be controllable by the
>> subscriber: in the case of sleeping nodes, the state at an always-up cache
>> which is the authority for a general-use URI for the resource is pure
>> storage.  The sleeping node that is the real resource owner can reasonably
>> PUT the value there.  (Though this is really a fairly special case of
>> notification, if it's notification at all.)
>>
>> Klaus: You may well be right.  I suspect that using the natural semantics
>> of REST operations will allow the effect of intermediate nodes to be exactly
>> what's expected from REST, but can't say for sure because I haven't done a
>> deep analysis.  Without asking you to provide a more detailed summary of
>> your own analysis and assumptions than I've seen, I  have not yet myself
>> seen a compelling need to modify the protocol, especially in a way that
>> results in multiple responses to what is naively a single request.  I still
>> believe a perfectly workable and clear solution can be reached using base
>> CoAP as it's defined today.
>>
>> In any case, PUT or POST, subscription or callback, perhaps subscriptions
>> are better expressed by defining content-types for subscription descriptions
>> and notifications, rather than adding options to the header and changing the
>> transaction layer state machine.  This would clearly provide the information
>> required by intermediate nodes.
>>
>> Just a thought.
>>
>> Peter
>>
>>
>> On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <
>> angelo@castellani.net> wrote:
>>
>>> The main idea around this is to have a Source-URI Option to be used for:
>>>
>>> a) subscription to define the resource that will be collecting
>>> notifications
>>> b) notification to advertise the resource that is currently sending the
>>> notification
>>>
>>> In this way the current coap-observe proposal architecture remains the
>>> same, but both URLs are sent in each transaction (as in CoAP, short URLs are
>>> recommended).
>>>
>>> In my opinion, this addition eases HTTP mapping, adds flexibility and
>>> adds full support for concurrent subscriptions.
>>>
>>> Best,
>>> Angelo
>>>
>>> On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <
>>> angelo@castellani.net> wrote:
>>>
>>>> I agree with Peter, see this old discussion on the topic:
>>>>
>>>> http://www.ietf.org/mail-archive/web/core/current/msg00236.html
>>>> http://www.ietf.org/mail-archive/web/core/current/msg00243.html
>>>>
>>>> In my opinion designing a protocol that can be simply used by
>>>> constrained objects is the main target here.
>>>>
>>>> There is a lot of state involved in the current design, and when
>>>> concurrent subscriptions with multiple end-points are in place the current
>>>> transaction layer cannot handle it and tokens are required (I pointed out
>>>> this issue at the Maastricht meeting too...).
>>>>
>>>> M2M operation should be simplified by CoAP, and in this context even
>>>> without multicast an endpoint may request multiple endpoint to collaborate
>>>> and to serve some data to it recurrently on the resource in charge of handle
>>>> this kind of data.
>>>>
>>>> As Klaus notes, this resource can be the holding the state a token
>>>> would, but can also be a prearranged resource to collect data. In my opinion
>>>> it's a more flexible and more RESTful solution to the subscription problem.
>>>>
>>>> Moreover HTTP mapping is straightforward and a proxy/gateway in the
>>>> middle has no need to handle the token state to route and translate the
>>>> request to the right HTTP endpoint.
>>>>
>>>> Angelo
>>>>
>>>> On Fri, Oct 22, 2010 at 20:16, Klaus Hartke  wrote:
>>>>
>>>>> I think the question is, basically: What do we subscribe to an
>>>>> observable resource, and how does an observer relate a notification to
>>>>> a subscription or resource?
>>>>>
>>>>> Currently, notifications are always sent to the transport address of
>>>>> the subscribing node, and include the resource URI and/or a
>>>>> subscriber-supplied token.
>>>>>
>>>>> We can extend this with an option in the subscription request to
>>>>> subscribe a third party. When it's present, notifications are sent to
>>>>> the transport address specified in this option, instead of the
>>>>> transport address of the subscribing node. The specified transport
>>>>> address may specify a multicast address. Notifications include the
>>>>> resource URI and/or a subscriber-supplied token.
>>>>>
>>>>> Note how this is equivalent to subscribing an URI to a resource:
>>>>>
>>>>> (a)
>>>>> Send-Notifications-To: client:61616
>>>>> Token: 0xad657b38
>>>>>
>>>>> (b)
>>>>> Callback-Uri: coap://client:61616/ad657b38
>>>>>
>>>>> When the authority in (a) or (b) denotes a multicast group,
>>>>> subscribers are free to observe the resource by joining the
>>>>> corresponding group and recognizing the "0xad657b38" token or
>>>>> "/ad657b38" path.
>>>>>
>>>>> However, (b) implies that there is a RESTful resource at
>>>>> coap://client:61616/ad657b38. This complicates a lot of things,
>>>>> because
>>>>>
>>>>> - we do not really want a RESTful resource, just something the server
>>>>> can send notifications to,
>>>>>
>>>>> - we could only update the RESTful resource using a PUT request, which
>>>>> is not the same as a notification.
>>>>>
>>>>> So (a) is the way to go. (That is, if we want to allow subscribing
>>>>> third parties. When I presented the idea of subscribing a multicast
>>>>> group to an observable resource in Maastricht, there was unanimous
>>>>> consensus that this was the worst idea ever.)
>>>>>
>>>>>
>>>>> Klaus
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>

--001636417153fb15ea049372eddf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

But it's the application level above REST, not CoAP, that determines wh=
at GET, PUT, and especially POST and DELETE mean with respect to a particul=
ar resource and content-type.=A0 I don't think this can be done purely =
at the CoAP level.=A0 It would require that the CoAP transaction layer be n=
otified of every change to resource state to kick off distribution to subsc=
ribers, and possibly that it be able to up-call to the application to retri=
eve a resource representation without having a REST request to drive it (or=
 that it replay the REST request that created the subscription, including a=
ll its companion options and message body, possibly violating the business =
logic associated with the resource).


Attempting to account for all that within the transaction layer is=20
pretty difficult.=A0 Time-driven auto-generation within CoAP, either of not=
ifications (subscribed GET) or of incoming updates (subscribed POST), also =
seems like something that is better handled at the application layer where =
the policy-related decisions can be managed.




I'm coming to feel that there's a resource A , there's optional=
ly a second resource B that provides subscription services for resource A i=
f that's appropriate, and there's arbitrary resources Ci that have =
been registered through B to receive updates when the owner of A has detect=
ed a change.=A0 A "subscribable" resource A makes its subscriptio=
n manager B visible through the link description, and everything "just=
 works".


Everything else is managed at the application layer.=A0 Note that each =
one of those subscribers might require a different representation (content-=
type), or due to other characteristics be given a different view of the res=
ource, and only the application level can reliable identify (and retain) th=
ose characteristics.=A0 Or, in fact, determine whether a proposed subscript=
ion should be accepted, if the resource content is sensitive.


I don't think the goal in your first sentence is the best way to sa=
ve ROM and satisfy domain business logic.=A0 An application-level capabilit=
y would do this at least as well, and more generally.

Peter



On Mon, Oct 25, 2010 at 10:11 AM, Angelo P. Cast=
ellani <angel=
o@castellani.net> wrote:

The utility of defining subscription fully at CoAP level is to have a CoAP =
implementation not dependant upon the resource; CoAP implementation itself =
can provide subscription functionality for every resource that is handling.=
. In constrained nodes this is really useful to save ROM space on the MCU.<=
div>



There are methods to save space in the payload, just an=
 example: if source-URI is omitted, source-URI is equal to URI; another opt=
ion is that the subscriber can ask not to send back the source-URI in the n=
otifications.





I prefer to receive a status code in the response, not =
a generic POST (like in current coap-observe document). I think that it'=
;s more useful and moreover CoAP sw layer can implement subscription by dup=
licating the same message with interval X locally limiting sw overhead abov=
e CoAP.





An addition: I was wondering why limit subscribe to a G=
ET? If I subscribe using a POST with fixed parameters, in that case the sub=
scription equals receiving that particular post every X seconds, if properl=
y elaborated can be useful under some special circumstances.





Best,
Angelo



On Mon, Oct 25, 2010 at 16:28, Peter Bigot <pab@peoplepowerco.com=
> wrote:




Curious: why add =
a Source-URI option, rather than put the URI in the body of the subscriptio=
n request?=A0 The body's not used for anything else in this case (it=
9;s a GET, isn't it?).=A0 I can see some motivation for putting it in t=
he response, but would suggest that the target of the response is adequate =
to distinguish the sender (if you're doing fan-in, add a distinguishing=
 path component to the URI in the subscription request, like coap://collect=
or/temps/south, coap://collector/temps/north for an aggregate resource coap=
://collector/temps).=A0 It'd make the messages shorter, too.





BTW: to correct my example, I now believe the notification by the origi=
n should be a POST to the callback or notification URI, not a PUT.=A0 The i=
mplication is that the receiving resource is an actor that will process the=
 notification, not a data store that will hold its value.






Alternatively, which method should be used might be controllable by the=
 subscriber: in the case of sleeping nodes, the state at an always-up cache=
 which is the authority for a general-use URI for the resource is pure stor=
age.=A0 The sleeping node that is the real resource owner can reasonably PU=
T the value there.=A0 (Though this is really a fairly special case of notif=
ication, if it's notification at all.)






Klaus: You may well be right.=A0 I suspect that using the natural seman=
tics of REST operations will allow the effect of intermediate nodes to be e=
xactly what's expected from REST, but can't say for sure because I =
haven't done a deep analysis.=A0 Without asking you to provide a more d=
etailed summary of your own analysis and assumptions than I've seen, I=
=A0 have not yet myself seen a compelling need to modify the protocol, espe=
cially in a way that results in multiple responses to what is naively a sin=
gle request.=A0 I still believe a perfectly workable and clear solution can=
 be reached using base CoAP as it's defined today.






In any case, PUT or POST, subscription or callback, perhaps subscriptio=
ns are better=20
expressed by defining content-types for subscription descriptions and notif=
ications,=20
rather than adding options to the header and changing the transaction layer=
 state machine.=A0 This would clearly provide the information required by i=
ntermediate nodes.

Just a thought.

Pe=
ter








On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <=
;angelo@castella=
ni.net> wrote:





The main idea around this is to have a Source-URI Option to be used for:
a) subscription to define the resource that will be collec=
ting notifications
b) notification to advertise the resource that=
 is currently sending the notification









In this way the current coap-observe proposal architect=
ure remains the same, but both URLs are sent in each transaction (as in CoA=
P, short URLs are recommended).

In my opinion, thi=
s addition eases HTTP mapping, adds flexibility and adds full support for c=
oncurrent subscriptions.









Best,
Angelo


On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <<=
a href=3D"mailto:angelo@castellani.net" target=3D"_blank">angelo@castellani=
.net> wrote:








I agree with Peter, see this old discussion on the topic:

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











In my opinion designing a protoco=
l that can be simply used by constrained objects is the main target here.










There is a lot of state involved in the current design,=
 and when concurrent subscriptions with multiple end-points are in place th=
e current transaction layer cannot handle it and tokens are required (I poi=
nted out this issue at the Maastricht meeting too...).











M2M operation should be simplified by CoAP, and in this=
 context even without multicast an endpoint may request multiple endpoint t=
o collaborate and to serve some data to it recurrently on the resource in c=
harge of handle this kind of data.











As Klaus notes, this resource can be the holding the st=
ate a token would, but can also be a prearranged resource to collect data. =
In my opinion it's a more flexible and more RESTful solution to the sub=
scription problem.











Moreover HTTP mapping is straightforward and a proxy/ga=
teway in the middle has no need to handle the token state to route and tran=
slate the request to the right HTTP endpoint.










Angelo

On Fri, Oct 22, 2010 at 20:16, Klaus Hartke &=
lt;hartke@tzi.org&g=
t; wrote:










I think the question is, basically: What do we subscribe to an

observable resource, and how does an observer relate a notification to

a subscription or resource?



Currently, notifications are always sent to the transport address of

the subscribing node, and include the resource URI and/or a

subscriber-supplied token.



We can extend this with an option in the subscription request to

subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the

transport address of the subscribing node. The specified transport

address may specify a multicast address. Notifications include the

resource URI and/or a subscriber-supplied token.



Note how this is equivalent to subscribing an URI to a resource:



(a)

Send-Notifications-To: client:61616

Token: 0xad657b38



(b)

Callback-Uri: coap://client:61616/ad657b38



When the authority in (a) or (b) denotes a multicast group,


subscribers are free to observe the resource by joining the


corresponding group and recognizing the "0xad657b38" token =
or

"/ad657b38" path.



However, (b) implies that there is a RESTful resource at

coap://client:61616/ad657b38. This complicates a lot of things,

because



- we do not really want a RESTful resource, just something the server

can send notifications to,



- we could only update the RESTful resource using a PUT request, which

is not the same as a notification.



So (a) is the way to go. (That is, if we want to allow subscribing

third parties. When I presented the idea of subscribing a multicast

group to an observable resource in Maastricht, there was unanimous

consensus that this was the worst idea ever.)






Klaus

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core











_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core











--001636417153fb15ea049372eddf--

From zach@sensinode.com  Mon Oct 25 08:50:59 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B343A6A45 for ; Mon, 25 Oct 2010 08:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqG8fGXcCamH for ; Mon, 25 Oct 2010 08:50:57 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2C7593A6A56 for ; Mon, 25 Oct 2010 08:50:56 -0700 (PDT)
Received: from [192.168.11.10] ([213.145.207.93]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9PFqZ19011236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Oct 2010 18:52:35 +0300
From: Zach Shelby 
Content-Type: multipart/signed; boundary=Apple-Mail-234-477112810; protocol="application/pkcs7-signature"; micalg=sha1
Date: Mon, 25 Oct 2010 18:52:37 +0300
Message-Id: <16B2B3A4-6AF9-4A3D-B2FE-ACF0D930F2CB@sensinode.com>
To: core 
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [core] Security threat input for coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 15:50:59 -0000

--Apple-Mail-234-477112810
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I am working on releasing coap-03 tonight. Thanks to Cullen the security =
section is otherwise in pretty good shape, but the security threat =
section is still looking pretty empty. I have time to write up at least =
multicast, but would really appreciate any short text on these security =
threats (or identify new ones!) within the next 4 hours.=20

Thanks!
Zach

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


--Apple-Mail-234-477112810
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNTE1NTIz
OFowIwYJKoZIhvcNAQkEMRYEFFco+amtKcLF7w3EpTbYfLo+FmYvMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAHTanD9Py4b+1PamoKNNgELi3xshU65jOAoz4ipCXBOW7GJ9FAhYMNEu
ydvBLitklE+fOrDU60Hh+IhoGqjLUdB0GUNgyN9o/VKELazkoC8mEuWd/UFML3tfoDeVJl2IWJzl
6vBSCcVa0gT8xWTeYdMxrPBCEECT/itvYUBWcvYGfERWTKirCbBDL2bKBnpOGMNsn7eFdm682A/J
O46NUQUz5cmGXyZypaTEHETRxrnw0l2NJ6ldAB81fC1BdpdtismD9ZatwhRfGAHz4iJo+kDyvJH9
Lna7ZKQbMppQZtKacz5ozCjcMSaLqVa30YKdV/81FlLkCAwvyQGIBfIl1QcAAAAAAAA=

--Apple-Mail-234-477112810--

From Akbar.Rahman@InterDigital.com  Mon Oct 25 12:06:31 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5618F3A67B3 for ; Mon, 25 Oct 2010 12:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.081
X-Spam-Level: 
X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.518,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgE1z07MLIv7 for ; Mon, 25 Oct 2010 12:06:30 -0700 (PDT)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 5A31F3A66B4 for ; Mon, 25 Oct 2010 12:06:30 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 25 Oct 2010 15:08:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Oct 2010 15:08:15 -0400
Message-ID: 
In-Reply-To: <20101025190013.558683A6959@core3.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-rahman-core-groupcomm-01.txt 
Thread-Index: Act0dzEUBgNqPlFzQIKG2NG9tcg5+QAAJxqg
References: <20101025190013.558683A6959@core3.amsl.com>
From: "Rahman, Akbar" 
To: 
X-OriginalArrivalTime: 25 Oct 2010 19:08:15.0115 (UTC) FILETIME=[F9CE05B0:01CB7477]
Subject: Re: [core] I-D Action:draft-rahman-core-groupcomm-01.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 19:06:31 -0000

Hi,


Here is an update to our draft on Group Communication for CoAP.  We have
tried to answer some of the questions raised by Zach earlier today.
Many thanks to Kerry Lynn for all his help in updating the draft.


Sincerely,


Akbar

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Monday, October 25, 2010 3:00 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-rahman-core-groupcomm-01.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Group Communication for CoAP
	Author(s)       : A. Rahman
	Filename        : draft-rahman-core-groupcomm-01.txt
	Pages           : 15
	Date            : 2010-10-25

This is a working document intended to trigger discussion and develop
draft language for the CoAP protocol specification in the area of group
communication (including multicast functionality).  Engineering
tradeoffs become more challenging in constrained environments, therefore
group communication is considered within the context of adjacent topics
that may impact or be impacted by design choices in the subject area.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rahman-core-groupcomm-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From trac@tools.ietf.org  Mon Oct 25 14:11:27 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B163A692A for ; Mon, 25 Oct 2010 14:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2fWwg2+aUbp for ; Mon, 25 Oct 2010 14:11:23 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B3CAB3A69B1 for ; Mon, 25 Oct 2010 14:11:21 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PAULo-0007F8-EX; Mon, 25 Oct 2010 14:13:04 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: cabo@tzi.org, zach@sensinode.com
X-Trac-Project: core
Date: Mon, 25 Oct 2010 21:13:04 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/25#comment:2
Message-ID: <066.337aadcfc86edb618bf4cd8229dfe00b@tools.ietf.org>
References: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org>
X-Trac-Ticket-ID: 25
In-Reply-To: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] coap #25 (closed): Token option
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 21:11:27 -0000

#25: Token option

Changes (by zach@…):

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


Comment:

 - Token now included in coap-03

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:  cabo@…      
     Type:  enhancement         |       Status:  closed      
 Priority:  minor               |    Milestone:  coap-03     
Component:  coap                |      Version:              
 Severity:  -                   |   Resolution:  fixed       
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From trac@tools.ietf.org  Mon Oct 25 14:13:14 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2EA3A684C for ; Mon, 25 Oct 2010 14:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgipLBVC9e9D for ; Mon, 25 Oct 2010 14:13:12 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 547F13A680B for ; Mon, 25 Oct 2010 14:13:12 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PAUNe-0007J9-CO; Mon, 25 Oct 2010 14:14:58 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 25 Oct 2010 21:14:58 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/27#comment:1
Message-ID: <060.5f034eb01504a77c3045c83b3f9f91c5@tools.ietf.org>
References: <051.b5aafdd48d95f827f4a809cf50d97982@tools.ietf.org>
X-Trac-Ticket-ID: 27
In-Reply-To: <051.b5aafdd48d95f827f4a809cf50d97982@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] coap #27 (closed): Erroring out on unknown critical options should be a MUST, not a SHOULD
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 21:13:14 -0000

#27: Erroring out on unknown critical options should be a MUST, not a SHOULD

Changes (by zach@…):

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


Comment:

 - Changed to a MUST in coap-03

-- 
--------------------------------+-------------------------------------------
 Reporter:  cabo@…              |        Owner:  zach@…            
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:  coap-03           
Component:  coap                |      Version:                    
 Severity:  Active WG Document  |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From trac@tools.ietf.org  Mon Oct 25 15:33:34 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADD93A6B27 for ; Mon, 25 Oct 2010 15:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpZ1Cyfj1YN9 for ; Mon, 25 Oct 2010 15:33:20 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 035A53A6856 for ; Mon, 25 Oct 2010 15:33:07 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PAVcv-0003dK-T9; Mon, 25 Oct 2010 15:34:49 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 25 Oct 2010 22:34:49 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/26#comment:1
Message-ID: <066.f0b6830f5606c93c2f40c336459f82fa@tools.ietf.org>
References: <057.2e09eba29a7e1fcfc1016f2c09b38552@tools.ietf.org>
X-Trac-Ticket-ID: 26
In-Reply-To: <057.2e09eba29a7e1fcfc1016f2c09b38552@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] coap #26 (closed): Expand error code space
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 22:33:34 -0000

#26: Expand error code space

Changes (by zach@…):

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


Comment:

 - Added to coap-03

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:  zach@…            
     Type:  enhancement         |       Status:  closed            
 Priority:  minor               |    Milestone:  coap-03           
Component:  coap                |      Version:                    
 Severity:  -                   |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From trac@tools.ietf.org  Mon Oct 25 15:34:04 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D773A6ABB for ; Mon, 25 Oct 2010 15:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM0wnq6awk1m for ; Mon, 25 Oct 2010 15:34:01 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ADBAC3A6A11 for ; Mon, 25 Oct 2010 15:33:57 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PAVdn-0005Zw-RK; Mon, 25 Oct 2010 15:35:43 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 25 Oct 2010 22:35:43 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/22#comment:1
Message-ID: <066.f2632243d9bceba9a321e06efa02850f@tools.ietf.org>
References: <057.434f2ed34b028a8dfa52e661bea01d8f@tools.ietf.org>
X-Trac-Ticket-ID: 22
In-Reply-To: <057.434f2ed34b028a8dfa52e661bea01d8f@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] coap #22 (closed): Security Section
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 22:34:04 -0000

#22: Security Section

Changes (by zach@…):

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


Comment:

 - Initial security section done in coap-03. Big thanks to the
 contributions from Cullen and Carsten!

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:         
     Type:  enhancement         |       Status:  closed 
 Priority:  major               |    Milestone:  coap-02
Component:  coap                |      Version:         
 Severity:  -                   |   Resolution:  fixed  
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From root@core3.amsl.com  Mon Oct 25 16:00:03 2010
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 159833A6905; Mon, 25 Oct 2010 16:00:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20101025230003.159833A6905@core3.amsl.com>
Date: Mon, 25 Oct 2010 16:00:02 -0700 (PDT)
Cc: core@ietf.org
Subject: [core] I-D Action:draft-ietf-core-coap-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 23:00:03 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.


	Title           : Constrained Application Protocol (CoAP)
	Author(s)       : Z. Shelby, et al.
	Filename        : draft-ietf-core-coap-03.txt
	Pages           : 39
	Date            : 2010-10-25

This document specifies the Constrained Application Protocol (CoAP),
a specialized web transfer protocol for use with constrained networks
and nodes for machine-to-machine applications such as smart energy
and building automation.  These constrained nodes often have 8-bit
microcontrollers with small amounts of ROM and RAM, while networks
such as 6LoWPAN often have high packet error rates and a typical
throughput of 10s of kbit/s.  CoAP provides a method/response
interaction model between application end-points, supports built-in
resource discovery, and includes key web concepts such as URIs and
content-types.  CoAP easily translates to HTTP for integration with
the web while meeting specialized requirements such as multicast
support, very low overhead and simplicity for constrained
environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-coap-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-core-coap-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-25155448.I-D@ietf.org>


--NextPart--

From zach@sensinode.com  Mon Oct 25 16:00:24 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF7D3A6C2A for ; Mon, 25 Oct 2010 16:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.539
X-Spam-Level: 
X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG0L9d5Rk8to for ; Mon, 25 Oct 2010 16:00:23 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 761A83A6C4F for ; Mon, 25 Oct 2010 16:00:20 -0700 (PDT)
Received: from [192.168.1.4] (line-5552.dyn.kponet.fi [85.29.68.5]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9PN24Dv027277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Oct 2010 02:02:04 +0300
From: Zach Shelby 
Content-Type: multipart/signed; boundary=Apple-Mail-274-502879266; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 26 Oct 2010 02:02:04 +0300
References: <20101025225448.DF9F03A6C00@core3.amsl.com>
To: core 
Message-Id: <48CA0995-DC01-46D9-93AB-C81C130B8E3F@sensinode.com>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [core] Fwd: New Version Notification for draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 25 Oct 2010 23:00:24 -0000

--Apple-Mail-274-502879266
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

http://www.ietf.org/id/draft-ietf-core-coap-03.txt

Here is the new version of CoAP, now even with a complete (draft) of the =
security section thanks to Cullen and Carsten. This now closes all open =
tickets and issues I could dredge out of the mailing list. As this =
version did not change the base header, and option type numbers are the =
same, we have kept the same version number in the header. This should be =
a fairly easy upgrade for existing implementations (Token Option for =
asynchronous responses, new CoAP specific error codes, Uri-Query =
option). And yes, we will test coap-03 at the plugfest in Beijing.

Here is a summary of changes:

   Changes from ietf-02 to ietf-03:

      o Token Option and related use in asynchronous requests added
      (#25).

      o CoAP specific error codes added (#26).

      o Erroring out on unknown critical options changed to a MUST
      (#27).

      o Uri-Query option added.

      o Terminology and definitions of URIs improved.

      o Security section completed (#22).
=20

Begin forwarded message:

> From: IETF I-D Submission Tool 
> Date: October 26, 2010 1:54:48 AM GMT+03:00
> To: zach@sensinode.com
> Cc: brian@skyfoundry.com,d.sturek@att.net
> Subject: New Version Notification for draft-ietf-core-coap-03=20
>=20
>=20
> A new version of I-D, draft-ietf-core-coap-03.txt has been =
successfully submitted by Zach Shelby and posted to the IETF repository.
>=20
> Filename:	 draft-ietf-core-coap
> Revision:	 03
> Title:		 Constrained Application Protocol (CoAP)
> Creation_date:	 2010-10-26
> WG ID:		 core
> Number_of_pages: 39
>=20
> Abstract:
> This document specifies the Constrained Application Protocol (CoAP),
> a specialized web transfer protocol for use with constrained networks
> and nodes for machine-to-machine applications such as smart energy
> and building automation.  These constrained nodes often have 8-bit
> microcontrollers with small amounts of ROM and RAM, while networks
> such as 6LoWPAN often have high packet error rates and a typical
> throughput of 10s of kbit/s.  CoAP provides a method/response
> interaction model between application end-points, supports built-in
> resource discovery, and includes key web concepts such as URIs and
> content-types.  CoAP easily translates to HTTP for integration with
> the web while meeting specialized requirements such as multicast
> support, very low overhead and simplicity for constrained
> environments.
>=20
>=20
>=20
> The IETF Secretariat.
>=20
>=20

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


--Apple-Mail-274-502879266
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNTIzMDIw
NFowIwYJKoZIhvcNAQkEMRYEFEa0W1hJIPNH5ib0eIkqk3b7Y+mIMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAJnwyH8ZHf+yJFarOaGdg4mO6BdMB/Y2QUOUsma0wKDmZ6x3m4LR0YeO
V1XUMqTW9CmikL4OYycD2mnqWR2TsYmu6ueXsKgHF90e8lwNRMNVhU2GrD6TqR3nuRO1QuMZdZml
0ueUIE3w6jFpHHT3c6SaOtOTal1yo9wvjJDDu5i6giHy6nzuzfEb9PQByQFwY5JwWx8+OssrdPMU
va7BxBDd9+qlGWZMUjR0tn9p+qnveht/cufUacIDcFIgVWiIuggrRX6DRHe+xnrmoTO/JQG/yE5/
/QFKrpw5NasTptZUmLCBpyZJe6yBqEuUf30hyrl/nPNSkBKCW721UhlABAwAAAAAAAA=

--Apple-Mail-274-502879266--

From angelo.castellani@gmail.com  Mon Oct 25 23:59:21 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7B03A67FC for ; Mon, 25 Oct 2010 23:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.036
X-Spam-Level: 
X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geB+9JQ-tYUy for ; Mon, 25 Oct 2010 23:59:19 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id DE9933A67F1 for ; Mon, 25 Oct 2010 23:59:15 -0700 (PDT)
Received: by qwb7 with SMTP id 7so2284620qwb.31 for ; Tue, 26 Oct 2010 00:01:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=bqjMhYzCQlIGngdwIeh5XvLLKDBn3pOQ2vKM2zC8baI=; b=ZTJ0dGMPdpdWzGlInESOFsuMy5bLYHAXdxAKNTcFj+yAQNIJMhD5azz/X+FKAl9PM7 kauaNlDi7or/r9RK2EkuW8ZsO5cGVrXy5f4XWJnIHY255YTzfLPbvNInrt9p/yqGohYT 6BLofwczutsYpuHPDfWX93Lu4keI5yHXWJB1E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=hL8NYnjD29zlY/fUgL8zE+p0vnmJHrqDj1mwnwmlVzQjXR/aCBk1Fi8fb2cU07L7AI 2N/HdcG3cGqjMGNI9kwUEthkaYPddzKhlfEb/z5NuYOBONVL7Gt42QaylKrTQnxKrJtk fl7ocpTSOnAjInrWKAgKb2+ONvGD2XceELYow=
Received: by 10.224.193.202 with SMTP id dv10mr1124654qab.380.1288076462343; Tue, 26 Oct 2010 00:01:02 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.229.249.201 with HTTP; Tue, 26 Oct 2010 00:00:42 -0700 (PDT)
In-Reply-To: 
References:         
From: "Angelo P. Castellani" 
Date: Tue, 26 Oct 2010 09:00:42 +0200
X-Google-Sender-Auth: 1M7NhbD0uBQtp9t9NJrC6zPoXuA
Message-ID: 
To: Peter Bigot 
Content-Type: multipart/alternative; boundary=20cf300fb4b3fb47d204937fabd3
Cc: core , Klaus Hartke 
Subject: Re: [core] observation via callbacks
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Oct 2010 06:59:21 -0000

--20cf300fb4b3fb47d204937fabd3
Content-Type: text/plain; charset=ISO-8859-1

Well probably there is a misunderstanding on some parts of my message.

However, surely a resource can be "non-subscribable" or even better POST on
some resource is "non-subscribable"... The resource itself when receives the
first message, is notified that the message itself is "subscription" message
and can refuse it.

CoAP layer can replicate the requests to the resource only after the
subscription has been successful. The requests to the resource should
contain information (TID?) to match the replicated request with the
precedent subscription.

The CoAP layer support for basic subscription functionality for generic
resources can be useful and standard, for this reason it can be supported by
CoAP applications built using generic CoAP-compliant sensors.

This support does not limit the use of advanced subscription functionalities
in above layers, and to refuse the use on resources that does not like this
mechanism.

A very useful cross-layer optimization that I hope will be possible using
CoAP is also that when the resource itself changes the representation
notifies the CoAP layer, so that even subscribers are notified of the
change; supporting this feature should optional for resources.

Angelo

On Mon, Oct 25, 2010 at 17:48, Peter Bigot  wrote:

> But it's the application level above REST, not CoAP, that determines what
> GET, PUT, and especially POST and DELETE mean with respect to a particular
> resource and content-type.  I don't think this can be done purely at the
> CoAP level.  It would require that the CoAP transaction layer be notified of
> every change to resource state to kick off distribution to subscribers, and
> possibly that it be able to up-call to the application to retrieve a
> resource representation without having a REST request to drive it (or that
> it replay the REST request that created the subscription, including all its
> companion options and message body, possibly violating the business logic
> associated with the resource).
>
> Attempting to account for all that within the transaction layer is pretty
> difficult.  Time-driven auto-generation within CoAP, either of notifications
> (subscribed GET) or of incoming updates (subscribed POST), also seems like
> something that is better handled at the application layer where the
> policy-related decisions can be managed.
>
> I'm coming to feel that there's a resource A , there's optionally a second
> resource B that provides subscription services for resource A if that's
> appropriate, and there's arbitrary resources Ci that have been registered
> through B to receive updates when the owner of A has detected a change.  A
> "subscribable" resource A makes its subscription manager B visible through
> the link description, and everything "just works".
>
> Everything else is managed at the application layer.  Note that each one of
> those subscribers might require a different representation (content-type),
> or due to other characteristics be given a different view of the resource,
> and only the application level can reliable identify (and retain) those
> characteristics.  Or, in fact, determine whether a proposed subscription
> should be accepted, if the resource content is sensitive.
>
> I don't think the goal in your first sentence is the best way to save ROM
> and satisfy domain business logic.  An application-level capability would do
> this at least as well, and more generally.
>
> Peter
>
>
> On Mon, Oct 25, 2010 at 10:11 AM, Angelo P. Castellani <
> angelo@castellani.net> wrote:
>
>> The utility of defining subscription fully at CoAP level is to have a CoAP
>> implementation not dependant upon the resource; CoAP implementation itself
>> can provide subscription functionality for every resource that is handling..
>> In constrained nodes this is really useful to save ROM space on the MCU.
>>
>> There are methods to save space in the payload, just an example: if
>> source-URI is omitted, source-URI is equal to URI; another option is that
>> the subscriber can ask not to send back the source-URI in the notifications.
>>
>> I prefer to receive a status code in the response, not a generic POST
>> (like in current coap-observe document). I think that it's more useful and
>> moreover CoAP sw layer can implement subscription by duplicating the same
>> message with interval X locally limiting sw overhead above CoAP.
>>
>> An addition: I was wondering why limit subscribe to a GET? If I subscribe
>> using a POST with fixed parameters, in that case the subscription equals
>> receiving that particular post every X seconds, if properly elaborated can
>> be useful under some special circumstances.
>>
>> Best,
>> Angelo
>>
>>
>>
>> On Mon, Oct 25, 2010 at 16:28, Peter Bigot  wrote:
>>
>>> Curious: why add a Source-URI option, rather than put the URI in the body
>>> of the subscription request?  The body's not used for anything else in this
>>> case (it's a GET, isn't it?).  I can see some motivation for putting it in
>>> the response, but would suggest that the target of the response is adequate
>>> to distinguish the sender (if you're doing fan-in, add a distinguishing path
>>> component to the URI in the subscription request, like
>>> coap://collector/temps/south, coap://collector/temps/north for an aggregate
>>> resource coap://collector/temps).  It'd make the messages shorter, too.
>>>
>>> BTW: to correct my example, I now believe the notification by the origin
>>> should be a POST to the callback or notification URI, not a PUT.  The
>>> implication is that the receiving resource is an actor that will process the
>>> notification, not a data store that will hold its value.
>>>
>>> Alternatively, which method should be used might be controllable by the
>>> subscriber: in the case of sleeping nodes, the state at an always-up cache
>>> which is the authority for a general-use URI for the resource is pure
>>> storage.  The sleeping node that is the real resource owner can reasonably
>>> PUT the value there.  (Though this is really a fairly special case of
>>> notification, if it's notification at all.)
>>>
>>> Klaus: You may well be right.  I suspect that using the natural semantics
>>> of REST operations will allow the effect of intermediate nodes to be exactly
>>> what's expected from REST, but can't say for sure because I haven't done a
>>> deep analysis.  Without asking you to provide a more detailed summary of
>>> your own analysis and assumptions than I've seen, I  have not yet myself
>>> seen a compelling need to modify the protocol, especially in a way that
>>> results in multiple responses to what is naively a single request.  I still
>>> believe a perfectly workable and clear solution can be reached using base
>>> CoAP as it's defined today.
>>>
>>> In any case, PUT or POST, subscription or callback, perhaps subscriptions
>>> are better expressed by defining content-types for subscription descriptions
>>> and notifications, rather than adding options to the header and changing the
>>> transaction layer state machine.  This would clearly provide the information
>>> required by intermediate nodes.
>>>
>>> Just a thought.
>>>
>>> Peter
>>>
>>>
>>> On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <
>>> angelo@castellani.net> wrote:
>>>
>>>> The main idea around this is to have a Source-URI Option to be used for:
>>>>
>>>> a) subscription to define the resource that will be collecting
>>>> notifications
>>>> b) notification to advertise the resource that is currently sending the
>>>> notification
>>>>
>>>> In this way the current coap-observe proposal architecture remains the
>>>> same, but both URLs are sent in each transaction (as in CoAP, short URLs are
>>>> recommended).
>>>>
>>>> In my opinion, this addition eases HTTP mapping, adds flexibility and
>>>> adds full support for concurrent subscriptions.
>>>>
>>>> Best,
>>>> Angelo
>>>>
>>>> On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <
>>>> angelo@castellani.net> wrote:
>>>>
>>>>> I agree with Peter, see this old discussion on the topic:
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00236.html
>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00243.html
>>>>>
>>>>> In my opinion designing a protocol that can be simply used by
>>>>> constrained objects is the main target here.
>>>>>
>>>>> There is a lot of state involved in the current design, and when
>>>>> concurrent subscriptions with multiple end-points are in place the current
>>>>> transaction layer cannot handle it and tokens are required (I pointed out
>>>>> this issue at the Maastricht meeting too...).
>>>>>
>>>>> M2M operation should be simplified by CoAP, and in this context even
>>>>> without multicast an endpoint may request multiple endpoint to collaborate
>>>>> and to serve some data to it recurrently on the resource in charge of handle
>>>>> this kind of data.
>>>>>
>>>>> As Klaus notes, this resource can be the holding the state a token
>>>>> would, but can also be a prearranged resource to collect data. In my opinion
>>>>> it's a more flexible and more RESTful solution to the subscription problem.
>>>>>
>>>>> Moreover HTTP mapping is straightforward and a proxy/gateway in the
>>>>> middle has no need to handle the token state to route and translate the
>>>>> request to the right HTTP endpoint.
>>>>>
>>>>> Angelo
>>>>>
>>>>> On Fri, Oct 22, 2010 at 20:16, Klaus Hartke  wrote:
>>>>>
>>>>>> I think the question is, basically: What do we subscribe to an
>>>>>> observable resource, and how does an observer relate a notification to
>>>>>> a subscription or resource?
>>>>>>
>>>>>> Currently, notifications are always sent to the transport address of
>>>>>> the subscribing node, and include the resource URI and/or a
>>>>>> subscriber-supplied token.
>>>>>>
>>>>>> We can extend this with an option in the subscription request to
>>>>>> subscribe a third party. When it's present, notifications are sent to
>>>>>> the transport address specified in this option, instead of the
>>>>>> transport address of the subscribing node. The specified transport
>>>>>> address may specify a multicast address. Notifications include the
>>>>>> resource URI and/or a subscriber-supplied token.
>>>>>>
>>>>>> Note how this is equivalent to subscribing an URI to a resource:
>>>>>>
>>>>>> (a)
>>>>>> Send-Notifications-To: client:61616
>>>>>> Token: 0xad657b38
>>>>>>
>>>>>> (b)
>>>>>> Callback-Uri: coap://client:61616/ad657b38
>>>>>>
>>>>>> When the authority in (a) or (b) denotes a multicast group,
>>>>>> subscribers are free to observe the resource by joining the
>>>>>> corresponding group and recognizing the "0xad657b38" token or
>>>>>> "/ad657b38" path.
>>>>>>
>>>>>> However, (b) implies that there is a RESTful resource at
>>>>>> coap://client:61616/ad657b38. This complicates a lot of things,
>>>>>> because
>>>>>>
>>>>>> - we do not really want a RESTful resource, just something the server
>>>>>> can send notifications to,
>>>>>>
>>>>>> - we could only update the RESTful resource using a PUT request, which
>>>>>> is not the same as a notification.
>>>>>>
>>>>>> So (a) is the way to go. (That is, if we want to allow subscribing
>>>>>> third parties. When I presented the idea of subscribing a multicast
>>>>>> group to an observable resource in Maastricht, there was unanimous
>>>>>> consensus that this was the worst idea ever.)
>>>>>>
>>>>>>
>>>>>> Klaus
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>
>>
>

--20cf300fb4b3fb47d204937fabd3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Well probably there is a misunderstanding on some parts of my message.
=

However, surely a resource can be "non-subscribable&quo=
t; or even better POST on some resource is "non-subscribable"... =
The resource itself when receives the first message, is notified that the m=
essage itself is "subscription" message and can refuse it.




CoAP layer can replicate the requests to the resource o=
nly after the subscription has been successful. The requests to the resourc=
e should contain information (TID?) to match the replicated request with th=
e precedent subscription.




The CoAP layer support for basic subscription functiona=
lity for generic resources can be useful and standard, for this reason it c=
an be supported by CoAP applications built using generic CoAP-compliant sen=
sors.




This support does not limit the use of advanced subscri=
ption functionalities in above layers, and to refuse the use on resources t=
hat does not like this mechanism.

A very useful cr=
oss-layer optimization that I hope will be possible using CoAP is also that=
 when the resource itself changes the representation notifies the CoAP laye=
r, so that even subscribers are notified of the change; supporting this fea=
ture should optional for resources.




Angelo

On Mon,=
 Oct 25, 2010 at 17:48, Peter Bigot <pab@peoplepowerco.com> wrote:


But it's the application level above REST, not CoAP, that determines wh=
at GET, PUT, and especially POST and DELETE mean with respect to a particul=
ar resource and content-type.=A0 I don't think this can be done purely =
at the CoAP level.=A0 It would require that the CoAP transaction layer be n=
otified of every change to resource state to kick off distribution to subsc=
ribers, and possibly that it be able to up-call to the application to retri=
eve a resource representation without having a REST request to drive it (or=
 that it replay the REST request that created the subscription, including a=
ll its companion options and message body, possibly violating the business =
logic associated with the resource).




Attempting to account for all that within the transaction layer is=20
pretty difficult.=A0 Time-driven auto-generation within CoAP, either of not=
ifications (subscribed GET) or of incoming updates (subscribed POST), also =
seems like something that is better handled at the application layer where =
the policy-related decisions can be managed.






I'm coming to feel that there's a resource A , there's optional=
ly a second resource B that provides subscription services for resource A i=
f that's appropriate, and there's arbitrary resources Ci that have =
been registered through B to receive updates when the owner of A has detect=
ed a change.=A0 A "subscribable" resource A makes its subscriptio=
n manager B visible through the link description, and everything "just=
 works".




Everything else is managed at the application layer.=A0 Note that each =
one of those subscribers might require a different representation (content-=
type), or due to other characteristics be given a different view of the res=
ource, and only the application level can reliable identify (and retain) th=
ose characteristics.=A0 Or, in fact, determine whether a proposed subscript=
ion should be accepted, if the resource content is sensitive.




I don't think the goal in your first sentence is the best way to sa=
ve ROM and satisfy domain business logic.=A0 An application-level capabilit=
y would do this at least as well, and more generally.



Peter




On Mon, Oct 25, 2010 at 10:11 AM, Angelo P. Cast=
ellani <angelo@castellani.net> wrote:



The utility of defining subscription fully at CoAP level is to have a CoAP =
implementation not dependant upon the resource; CoAP implementation itself =
can provide subscription functionality for every resource that is handling.=
. In constrained nodes this is really useful to save ROM space on the MCU.<=
div>





There are methods to save space in the payload, just an=
 example: if source-URI is omitted, source-URI is equal to URI; another opt=
ion is that the subscriber can ask not to send back the source-URI in the n=
otifications.







I prefer to receive a status code in the response, not =
a generic POST (like in current coap-observe document). I think that it'=
;s more useful and moreover CoAP sw layer can implement subscription by dup=
licating the same message with interval X locally limiting sw overhead abov=
e CoAP.







An addition: I was wondering why limit subscribe to a G=
ET? If I subscribe using a POST with fixed parameters, in that case the sub=
scription equals receiving that particular post every X seconds, if properl=
y elaborated can be useful under some special circumstances.







Best,
Angelo



On Mon, =
Oct 25, 2010 at 16:28, Peter Bigot <pab@peoplepowerco.com> wrote:






Curious: why add a Sour=
ce-URI option, rather than put the URI in the body of the subscription requ=
est?=A0 The body's not used for anything else in this case (it's a =
GET, isn't it?).=A0 I can see some motivation for putting it in the res=
ponse, but would suggest that the target of the response is adequate to dis=
tinguish the sender (if you're doing fan-in, add a distinguishing path =
component to the URI in the subscription request, like coap://collector/tem=
ps/south, coap://collector/temps/north for an aggregate resource coap://col=
lector/temps).=A0 It'd make the messages shorter, too.







BTW: to correct my example, I now believe the notification by the origi=
n should be a POST to the callback or notification URI, not a PUT.=A0 The i=
mplication is that the receiving resource is an actor that will process the=
 notification, not a data store that will hold its value.








Alternatively, which method should be used might be controllable by the=
 subscriber: in the case of sleeping nodes, the state at an always-up cache=
 which is the authority for a general-use URI for the resource is pure stor=
age.=A0 The sleeping node that is the real resource owner can reasonably PU=
T the value there.=A0 (Though this is really a fairly special case of notif=
ication, if it's notification at all.)








Klaus: You may well be right.=A0 I suspect that using the natural seman=
tics of REST operations will allow the effect of intermediate nodes to be e=
xactly what's expected from REST, but can't say for sure because I =
haven't done a deep analysis.=A0 Without asking you to provide a more d=
etailed summary of your own analysis and assumptions than I've seen, I=
=A0 have not yet myself seen a compelling need to modify the protocol, espe=
cially in a way that results in multiple responses to what is naively a sin=
gle request.=A0 I still believe a perfectly workable and clear solution can=
 be reached using base CoAP as it's defined today.








In any case, PUT or POST, subscription or callback, perhaps subscriptio=
ns are better=20
expressed by defining content-types for subscription descriptions and notif=
ications,=20
rather than adding options to the header and changing the transaction layer=
 state machine.=A0 This would clearly provide the information required by i=
ntermediate nodes.

Just a thought.

Pe=
ter










On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <=
;angelo@castella=
ni.net> wrote:







The main idea around this is to have a Source-URI Option to be used for:
a) subscription to define the resource that will be collec=
ting notifications
b) notification to advertise the resource that=
 is currently sending the notification











In this way the current coap-observe proposal architect=
ure remains the same, but both URLs are sent in each transaction (as in CoA=
P, short URLs are recommended).

In my opinion, thi=
s addition eases HTTP mapping, adds flexibility and adds full support for c=
oncurrent subscriptions.











Best,
Angelo


On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <<=
a href=3D"mailto:angelo@castellani.net" target=3D"_blank">angelo@castellani=
.net> wrote:










I agree with Peter, see this old discussion on the topic:

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













In my opinion designing a protoco=
l that can be simply used by constrained objects is the main target here.












There is a lot of state involved in the current design,=
 and when concurrent subscriptions with multiple end-points are in place th=
e current transaction layer cannot handle it and tokens are required (I poi=
nted out this issue at the Maastricht meeting too...).













M2M operation should be simplified by CoAP, and in this=
 context even without multicast an endpoint may request multiple endpoint t=
o collaborate and to serve some data to it recurrently on the resource in c=
harge of handle this kind of data.













As Klaus notes, this resource can be the holding the st=
ate a token would, but can also be a prearranged resource to collect data. =
In my opinion it's a more flexible and more RESTful solution to the sub=
scription problem.













Moreover HTTP mapping is straightforward and a proxy/ga=
teway in the middle has no need to handle the token state to route and tran=
slate the request to the right HTTP endpoint.












Angelo

On Fri, Oct 22, 2010 at 20:16, Klaus Hartke &=
lt;hartke@tzi.org&g=
t; wrote:












I think the question is, basically: What do we subscribe to an

observable resource, and how does an observer relate a notification to

a subscription or resource?



Currently, notifications are always sent to the transport address of

the subscribing node, and include the resource URI and/or a

subscriber-supplied token.



We can extend this with an option in the subscription request to

subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the

transport address of the subscribing node. The specified transport

address may specify a multicast address. Notifications include the

resource URI and/or a subscriber-supplied token.



Note how this is equivalent to subscribing an URI to a resource:



(a)

Send-Notifications-To: client:61616

Token: 0xad657b38



(b)

Callback-Uri: coap://client:61616/ad657b38



When the authority in (a) or (b) denotes a multicast group,


subscribers are free to observe the resource by joining the


corresponding group and recognizing the "0xad657b38" token =
or

"/ad657b38" path.



However, (b) implies that there is a RESTful resource at

coap://client:61616/ad657b38. This complicates a lot of things,

because



- we do not really want a RESTful resource, just something the server

can send notifications to,



- we could only update the RESTful resource using a PUT request, which

is not the same as a notification.



So (a) is the way to go. (That is, if we want to allow subscribing

third parties. When I presented the idea of subscribing a multicast

group to an observable resource in Maastricht, there was unanimous

consensus that this was the worst idea ever.)






Klaus

_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core











_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core














--20cf300fb4b3fb47d204937fabd3--

From peter.van.der.stok@philips.com  Tue Oct 26 05:09:13 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554273A6956 for ; Tue, 26 Oct 2010 05:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level: 
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chQYrfawvmDb for ; Tue, 26 Oct 2010 05:09:12 -0700 (PDT)
Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by core3.amsl.com (Postfix) with ESMTP id BE7D03A682E for ; Tue, 26 Oct 2010 05:09:10 -0700 (PDT)
Received: from mail111-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.8; Tue, 26 Oct 2010 12:10:56 +0000
Received: from mail111-va3 (localhost.localdomain [127.0.0.1])	by mail111-va3-R.bigfish.com (Postfix) with ESMTP id D5B3385826A	for ; Tue, 26 Oct 2010 12:10:56 +0000 (UTC)
X-SpamScore: -49
X-BigFish: VPS-49(zz15d6O9251J936eK542N1370I9370J217bPzz1202hzz8275dh1033ILz2dh2a8h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:NLAMSEXE03.connect1.local; RD:smtpx.philips.com; EFVD:NLI
Received: from mail111-va3 (localhost.localdomain [127.0.0.1]) by mail111-va3 (MessageSwitch) id 1288095056562898_5795; Tue, 26 Oct 2010 12:10:56 +0000 (UTC)
Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.250])	by mail111-va3.bigfish.com (Postfix) with ESMTP id 861BB1168050	for ; Tue, 26 Oct 2010 12:10:56 +0000 (UTC)
Received: from NLAMSEXE03.connect1.local (168.87.56.20) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 26 Oct 2010 12:10:52 +0000
Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 26 Oct 2010 14:10:57 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Tue, 26 Oct 2010 14:10:50 +0200
From: "Stok, Peter van der" 
To: "core@ietf.org" 
Date: Tue, 26 Oct 2010 14:10:49 +0200
Thread-Topic: New Version Notification for draft-vanderstok-core-bc-02 
Thread-Index: Act0S31SRjnR7viyQl2lhFPTp8ThhAAuuQHQ
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: [core] FW: New Version Notification for draft-vanderstok-core-bc-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Oct 2010 12:09:13 -0000

RGVhciBhbGwsDQoNCkJlbG93IHRoZSBhbm5vdW5jZW1lbnQgb2YgdGhlIEludGVybmV0IGRyYWZ0
IG9uIG5hbWluZywgZGlzY292ZXJ5IGFuZCBjb250cm9sIGxlZ2FjeSwgS2VycnkgYW5kIEkgaGFk
IHRoZSBwbGVhc3VyZSB0byBzdWJtaXQuDQoNClRoaXMgb25lIGltcHJvdmVzIG9uIHZlcnNpb24g
MDEgYnk6DQoNCi0gUmVtb3ZlZCBhbGwgcmVmZXJlbmNlcyB0byBtdWx0aWNhc3QgYW5kIG11bHRp
Y2FzdCBzY29wZSwgZ2l2ZW4gZHJhZnQgb2YgcmFobWFuIGdyb3VwIGNvbW11bmljYXRpb24uDQoN
Ci0gQWRhcHRlZCBleGFtcGxlcyB0byBjb2FwLTIgYW5kIGNvcmUtbGluayBkcmFmdHMuDQoNCi0g
dHJhbnNwb3J0IHNob3J0IFVSTCBmb3IgZGVzdGluYXRpb24gcmVjb2duaXRpb24uDQoNCi0gRWxh
Ym9yYXRlZCBsZWdhY3kgZGlzY292ZXJ5IHVuZGVyIEROUy1TRC4NCg0KDQpQZXRlcg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFtt
YWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXQ0KU2VudDogTW9uZGF5IDI1IE9jdG9iZXIgMjAx
MCAxNTo0Nw0KVG86IFN0b2ssIFBldGVyIHZhbiBkZXINCkNjOiBrZXJseW5AaWVlZS5vcmcNClN1
YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdmFuZGVyc3Rvay1jb3Jl
LWJjLTAyDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZhbmRlcnN0b2stY29yZS1i
Yy0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQZXRlciBWYW4gZGVy
IFN0b2sgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAg
ICAgIGRyYWZ0LXZhbmRlcnN0b2stY29yZS1iYw0KUmV2aXNpb246ICAgICAgICAwMg0KVGl0bGU6
ICAgICAgICAgICBDb0FQIFV0aWxpemF0aW9uIGZvciBCdWlsZGluZyBDb250cm9sDQpDcmVhdGlv
bl9kYXRlOiAgIDIwMTAtMTAtMjUNCldHIElEOiAgICAgICAgICAgSW5kZXBlbmRlbnQgU3VibWlz
c2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAxNw0KDQpBYnN0cmFjdDoNClRoaXMgZHJhZnQgZGVzY3Jp
YmVzIGFuIGV4YW1wbGUgdXNlIG9mIHRoZSBSRVNUZnVsIENvQVAgcHJvdG9jb2wgZm9yDQpidWls
ZGluZyBhdXRvbWF0aW9uIGFuZCBjb250cm9sIChCQUMpIGFwcGxpY2F0aW9ucyBzdWNoIGFzIEhW
QUMgYW5kDQpsaWdodGluZy4gIEEgZmV3IGJhc2ljIGRlc2lnbiBhc3N1bXB0aW9ucyBhcmUgc3Rh
dGVkIGZpcnN0LCB0aGVuIFVSSQ0Kc3RydWN0dXJlIGlzIHV0aWxpemVkIHRvIGRlZmluZSBncm91
cCBhcyB3ZWxsIGFzIHVuaWNhc3Qgc2NvcGUgZm9yDQpSRVNUZnVsIG9wZXJhdGlvbnMuICBSRkMg
Mzk4NiBkZWZpbmVzIHRoZSBVUkkgY29tcG9uZW50cyBhcyAoMSkgYQ0Kc2NoZW1lLCAoMikgYW4g
YXV0aG9yaXR5LCB1c2VkIGhlcmUgdG8gbG9jYXRlIHRoZSBidWlsZGluZywgYXJlYSwgb3INCm5v
ZGUgdW5kZXIgY29udHJvbCwgKDMpIGEgcGF0aCwgdXNlZCBoZXJlIHRvIGxvY2F0ZSB0aGUgcmVz
b3VyY2UNCnVuZGVyIGNvbnRyb2wsIGFuZCAoNCkgYSBxdWVyeSBwYXJ0IChmcmFnbWVudHMgYXJl
IG5vdCBzdXBwb3J0ZWQgaW4NCkNvQVAuKSAgTmV4dCwgaXQgaXMgc2hvd24gdGhhdCBETlMgY2Fu
IGJlIHVzZWQgdG8gbG9jYXRlIFVSSXMgb24gdGhlDQpzY2FsZSBuZWNlc3NhcnkgaW4gbGFyZ2Ug
Y29tbWVyY2lhbCBCQUMgZGVwbG95bWVudHMuICBGaW5hbGx5LCBhDQptZXRob2QgaXMgcHJvcG9z
ZWQgZm9yIG1hcHBpbmcgVVJJcyBvbnRvIGxlZ2FjeSBCQUMgcmVzb3VyY2VzLCBlLmcuLA0KdG8g
ZmFjaWxpdGF0ZSBhcHBsaWNhdGlvbi1sYXllciBnYXRld2F5cy4NCg0KVGhpcyBwcm9wb3NhbCBz
dXBwb3J0cyB0aGUgdmlldyB0aGF0ICgxKSBidWlsZGluZyBjb250cm9sIGlzIGxpa2VseQ0KdG8g
bW92ZSBpbiBzdGVwcyB0b3dhcmQgYWxsLUlQIGNvbnRyb2wgbmV0d29ya3MgYmFzZWQgb24gdGhl
IGxlZ2FjeQ0KZWZmb3J0cyBwcm92aWRlZCBieSBEQUxJLCBMT04sIEJBQ25ldCwgWmlnQmVlLCBh
bmQgb3RoZXIgc3RhbmRhcmRzLA0KYW5kICgyKSBzZXJ2aWNlIGRpc2NvdmVyeSBpcyBjb21wbGlt
ZW50YXJ5IHRvIHJlc291cmNlIGRpc2NvdmVyeSBhbmQNCmZhY2lsaXRhdGVzIGNvbnRyb2wgbmV0
d29yayBzY2FsaW5nLg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0KDQpUaGUgaW5m
b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFu
ZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMg
aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2Us
IGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3Nh
Z2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJl
IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5
IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVz
c2FnZS4NCg==


From cabo@tzi.org  Tue Oct 26 11:29:35 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD193A682A for ; Tue, 26 Oct 2010 11:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.165
X-Spam-Level: 
X-Spam-Status: No, score=-107.165 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjSfez2m+eTH for ; Tue, 26 Oct 2010 11:29:33 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 95E033A6774 for ; Tue, 26 Oct 2010 11:29: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 o9QIUdRd000533 for ; Tue, 26 Oct 2010 20:30:39 +0200 (CEST)
Received: from [192.168.217.101] (p5489D870.dip.t-dialin.net [84.137.216.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A46CDCA3; Tue, 26 Oct 2010 20:30:38 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
X-Priority: 3
Date: Tue, 26 Oct 2010 20:30:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <161741695.1288111441984.JavaMail.nobody@jsj2wl015.webex.com>
To: core 
X-Mailer: Apple Mail (2.1081)
Subject: [core] Fwd: Meeting invitation: CORE WG
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 18:29:35 -0000

I completely forgot to announce tomorrow's monthly CoRE webex call.

Please find the details below, as usual at 1500 UTC for 2 hours.

The agenda will be to review the new versions of the drafts that came in =
before the I-D cutoff yesterday (see below), in the light of the recent =
discussions on the mailing list, and to identify gaps that need to be =
filled before the Beijing meeting.

Authors: If you want to give a quick intro/update, and think a slide or =
two would help, preferably please send them to me till 1300 UTC so I can =
consolidate.

Sorry for the late notice.

Gruesse, Carsten

draft-ietf-core-coap	        -03		new	2010-10-25  	=
Active
draft-ietf-core-link-format	-01		new	2010-10-25  	=
Active
draft-ietf-core-observe	        -00	 		2010-10-18  	=
Active
draft-ietf-core-block           -00	 		2010-10-18  	=
Active
draft-bormann-core-coap-block	-01		new	2010-10-24
draft-oflynn-core-bootstrapping	-02			2010-10-19
draft-rahman-core-groupcomm	-01		new	2010-10-25
draft-vanderstok-core-bc	-02		new	2010-10-25



> Subject: Meeting invitation: CORE WG
>=20
> Hello ,=20
>=20
> IETF Secretariat invites you to attend this online meeting.=20
>=20
> Topic: CORE WG=20
> Date: Wednesday, October 27, 2010=20
> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20
> Meeting Number: 963 446 646=20
> Meeting Password: (This meeting does not require a password.)=20
>=20
>=20
> -------------------------------------------------------=20
> To join the online meeting (Now from the Apple iPhone (R) too!)=20
> -------------------------------------------------------=20
> 1. Go to =
https://workgreen.webex.com/workgreen/j.php?ED=3D148403917&UID=3D119049487=
2&RT=3DMiM0=20
> 2. If requested, enter your name and email address.=20
> 3. If a password is required, enter the meeting password: (This =
meeting does not require a password.)=20
> 4. Click "Join".=20
>=20
> To view in other time zones or languages, please click the link:=20
> =
https://workgreen.webex.com/workgreen/j.php?ED=3D148403917&UID=3D119049487=
2&ORT=3DMiM0=20
>=20
> -------------------------------------------------------=20
> To join the audio conference only=20
> -------------------------------------------------------=20
> To receive a call back, provide your phone number when you join the =
meeting, or call the number below and enter the access code.=20
> Call-in toll number (US/Canada): 1-408-792-6300=20
> Global call-in numbers: =
https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED=
=3D148403917&tollFree=3D0=20
>=20
> Access code:963 446 646=20
>=20
> -------------------------------------------------------=20
> For assistance=20
> -------------------------------------------------------=20
> 1. Go to https://workgreen.webex.com/workgreen/mc=20
> 2. On the left navigation bar, click "Support".=20
>=20
> You can contact me at:=20
> amorris@amsl.com=20
> 1-510-492-4081=20
>=20
> To add this meeting to your calendar program (for example Microsoft =
Outlook), click this link:=20
> =
https://workgreen.webex.com/workgreen/j.php?ED=3D148403917&UID=3D119049487=
2&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DH/FeX5IDRE1wJA7lMSmbP/d1H2tCU0L41as=
FItVk1G8=3D&RT=3DMiM0=20
>=20
> The playback of UCF (Universal Communications Format) rich media files =
requires appropriate players. To view this type of rich media files in =
the meeting, please check whether you have the players installed on your =
computer by going to =
https://workgreen.webex.com/workgreen/systemdiagnosis.php=20
>=20
> Sign up for a free trial of WebEx=20
> http://www.webex.com/go/mcemfreetrial=20
>=20
> http://www.webex.com=20
>=20
>=20
>=20
> IMPORTANT NOTICE: This WebEx service includes a feature that allows =
audio and any documents and other materials exchanged or viewed during =
the session to be recorded. By joining this session, you automatically =
consent to such recordings. If you do not consent to the recording, =
discuss your concerns with the meeting host prior to the start of the =
recording or do not join the session. Please note that any such =
recordings may be subject to discovery in the event of litigation.=20


From koo@comnets.uni-bremen.de  Tue Oct 26 13:00:48 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8653A68F7 for ; Tue, 26 Oct 2010 13:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.534
X-Spam-Level: 
X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=0.714,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+z92fAzQeys for ; Tue, 26 Oct 2010 13:00:38 -0700 (PDT)
Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id 054E33A6874 for ; Tue, 26 Oct 2010 13:00:22 -0700 (PDT)
Received: from koojanalaptop (unknown [10.8.0.42]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id 9EFDDD42288; Tue, 26 Oct 2010 22:02:07 +0200 (CEST)
From: "Koojana Kuladinithi" 
To: , "'Zach Shelby'" 
References: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de>		<201010251150.22061.mab@comnets.uni-bremen.de> 
In-Reply-To: 
Date: Tue, 26 Oct 2010 22:02:15 +0200
Message-ID: <004401cb7548$b00761c0$10162540$@uni-bremen.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01CB7559.739031C0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Act0Qe21sx53y1PWR0S/Wc/v3dLZfgBBaCTA
Content-Language: en-us
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Oct 2010 20:00:48 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0045_01CB7559.739031C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Zach,

 

As far as I understood, the client behavior of processing asynchronous
response (section 2.1.2) is not defined properly in the 03.txt version. We
had few email discussions on this issue (see the subject "section 2.1.2
Asynchronous response - a loss of CON message from the Server"). 

 

As Peter asked below, do you plan to address this in the current
specification?

 

Koojana

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
Peter Bigot
Sent: Monday, October 25, 2010 2:41 PM
To: Markus Becker
Cc: core@ietf.org
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON
message from the Server

 

You're right: I'd inappropriately included retransmissions when proposing a
default, somehow thinking that perhaps this delay was introduced or visible
at the REST layer.  While this could be done, it is more naturally cast as a
pseudo-REST or CoAP-layer concept, as is asynchronous responses, and
retransmissions are irrelevant.

The purpose of the default was to remove the undefined behavior in the base
document.  If the option description doesn't make the base document, a
default is unnecessary.  Similarly, the option might as well be elective in
that case, because system designers couldn't assume clients will implement
the option anyway and for usability a system must be robust in the presence
of clients that don't know how long they should wait (where "robust" should
not mean sending a critical option that may cause the client to fail its
request unnecessarily).

Question: I understand, maybe incorrectly, that there's a huge push to get
CoAP to RFC status ASAP, and that the WG's period-of-performance ends in
December.  Is there any chance for options and major changes that won't be
in coap-03 being added before CoAP becomes an RFC?  Or do we need to start
writing separate documents for this sort of thing?

Peter

On Mon, Oct 25, 2010 at 4:50 AM, Markus Becker 
wrote:

> As Carsten notes, the defined behavior is your option 1 (server
retransmits
> con response message).
>
> I agree there is some uncertainty resulting from the asynchronous response
> not having a time limit, and I too would rather have it resolved so I
don't
> have to hold onto request state in the client for an unbounded period, in
> hopes that eventually my answer will come.
>
> I read what you're suggesting as an elective header option, to be placed
in
> the ACK that indicates an asynchronous response, providing an upper bound
> on how long the client should expect to wait for a response.

An additional header option, yes. However, not sure about elective or
critical. It needs to be elective option because it is in a ACK. (Can ACKs
or
RSTs include critical options at all?) It would however also need to be
understood by all clients, because client behaviour after receiving the ACK
is
not yet defined properly ('request state for unbounded period').


> Further, we should give it a reasonable default.   31 seconds may elapse
> between first CON transmission and last CON retransmission given the
> default settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which point
> the server will give up.  A default of 60 allows about 29 seconds for the
> server to create the response representation before risking the client
> giving up too soon.
>
> Then a client that has not received the response after that time plus a
> fudge term for network delays can assume the message is lost and recover
in
> whatever way is appropriate (e.g., retransmit the GET or give up).
>
> I like this.

You are proposing the waiting time to be the processing time + time for
retransmissions + network delays. What we suggested was the processing time
+
network delay of the response (without considering retransmissions of the
server) and then let the client try the retransmission. We thought of this
because of high delay links easily triggering unnecessary retransmissions.


> On Thu, Oct 21, 2010 at 4:46 AM, Koojana Kuladinithi <
> koo@comnets.uni-bremen.de> wrote:

[snip]

> > 2.  The server sends ACK as in Figure 3, but with a Processing-Delay
> > option if the response gets delayed. (the experiments we did here show
> > that to get temperature/humidity results from an embedded device, it
> > takes about ~300 ms). This Processing-Delay can be decided by the server
> > based on the type of URI. This lets the client to compute the waiting
> > time to get the asynchronous response. Example, Waiting-Time =
> > (Processing-Delay +  RTT + xx delay).

> BTW: We did all realize that servers supporting asynchronous responses
> should keep hold of the TID for the original request in the client
response
> record, so that if the server ACK gets lost and the client retransmits it
> isn't interpreted as a new request, right?  I don't think I've seen that
> called out explicitly anywhere.

True.

Best regards,
Markus

> Peter

>
> >
> >
> >
> > If the client does not receive any delayed response from the server
> > within this Waiting-Time, the client should send again CON GET message.
> > I believe this would be a simple way to solve the above mentioned
> > issues.
> >
> >
> >
> >
> >
> > Kind regards
> >
> >
> >
> > Koojana
> >
> >
> >
> > Koojana Kuladinithi
> >
> > University of Bremen, FB1 - IKOM/TZI
> >
> > Otto-Hahn Allee NW1, 28359, Bremen, Germany
> >
> > Tel. +49 421 218 62382, Fax. +49 421 218 3601,
> >
> > www:

> > http://www.comnets.uni-bremen.de/~koo

 
> > 7Ekoo>

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

------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
 
| mailto: mab@comnets.uni-bremen.de
| telephone: +49 421 218 62379
| building: NW1 room: N2260
------------------------------------------------

 


------=_NextPart_000_0045_01CB7559.739031C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hello Zach,



 



As far as I understood, the client behavior of processing =
asynchronous
response (section 2.1.2) is not defined properly in the 03.txt version. =
We had
few email discussions on this issue (see the subject “section =
2.1.2
Asynchronous response - a loss of CON message from the Server”). =




 



As Peter asked below, do you plan to address this in the =
current
specification?



 



Koojana



 






From:=

core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of =
Peter
Bigot

Sent: Monday, October 25, 2010 2:41 PM

To: Markus Becker

Cc: core@ietf.org

Subject: Re: [core] section 2.1.2 Asynchronous response - a loss =
of CON
message from the Server






 



You're right: I'd
inappropriately included retransmissions when proposing a default, =
somehow
thinking that perhaps this delay was introduced or visible at the REST
layer.  While this could be done, it is more naturally cast as a
pseudo-REST or CoAP-layer concept, as is asynchronous responses, and
retransmissions are irrelevant.



The purpose of the default was to remove the undefined behavior in the =
base
document.  If the option description doesn't make the base =
document, a
default is unnecessary.  Similarly, the option might as well be =
elective
in that case, because system designers couldn't assume clients will =
implement
the option anyway and for usability a system must be robust in the =
presence of
clients that don't know how long they should wait (where =
"robust"
should not mean sending a critical option that may cause the client to =
fail its
request unnecessarily).



Question: I understand, maybe incorrectly, that there's a huge push to =
get CoAP
to RFC status ASAP, and that the WG's period-of-performance ends in
December.  Is there any chance for options and major changes that =
won't be
in coap-03 being added before CoAP becomes an RFC?  Or do we need =
to start
writing separate documents for this sort of thing?



Peter






On Mon, Oct 25, 2010 at 4:50 AM, Markus Becker =
<mab@comnets.uni-bremen.de&g=
t;
wrote:






> As Carsten =
notes, the
defined behavior is your option 1 (server retransmits

> con response message).

>

> I agree there is some uncertainty resulting from the asynchronous =
response

> not having a time limit, and I too would rather have it resolved so =
I
don't

> have to hold onto request state in the client for an unbounded =
period, in

> hopes that eventually my answer will come.

>

> I read what you're suggesting as an elective header option, to be =
placed
in

> the ACK that indicates an asynchronous response, providing an upper =
bound

> on how long the client should expect to wait for a =
response.






An additional header option, yes. However, not sure =
about
elective or

critical. It needs to be elective option because it is in a ACK. (Can =
ACKs or

RSTs include critical options at all?) It would however also need to =
be

understood by all clients, because client behaviour after receiving the =
ACK is

not yet defined properly ('request state for unbounded =
period').








> Further, we should give it a reasonable default.   31 seconds =
may
elapse

> between first CON transmission and last CON retransmission given =
the

> default settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which =
point

> the server will give up.  A default of 60 allows about 29 =
seconds for
the

> server to create the response representation before risking the =
client

> giving up too soon.

>

> Then a client that has not received the response after that time =
plus a

> fudge term for network delays can assume the message is lost and =
recover
in

> whatever way is appropriate (e.g., retransmit the GET or give =
up).

>

> I like this.






You are proposing the waiting time to be the =
processing time
+ time for

retransmissions + network delays. What we suggested was the processing =
time +

network delay of the response (without considering retransmissions of =
the

server) and then let the client try the retransmission. We thought of =
this

because of high delay links easily triggering unnecessary =
retransmissions.








> On Thu, Oct 21, 2010 at 4:46 AM, Koojana Kuladinithi <

> koo@comnets.uni-bremen.de&g=
t;
wrote:






[snip]






> > 2. =
 The server
sends ACK as in Figure 3, but with a Processing-Delay

> > option if the response gets delayed. (the experiments we did =
here
show

> > that to get temperature/humidity results from an embedded =
device, it

> > takes about ~300 ms). This Processing-Delay can be decided by =
the
server

> > based on the type of URI. This lets the client to compute the =
waiting

> > time to get the asynchronous response. Example, Waiting-Time =
=3D

> > (Processing-Delay +  RTT + xx delay).









> BTW: We did all =
realize
that servers supporting asynchronous responses

> should keep hold of the TID for the original request in the client
response

> record, so that if the server ACK gets lost and the client =
retransmits it

> isn't interpreted as a new request, right?  I don't think I've =
seen
that

> called out explicitly anywhere.






True.



Best regards,

Markus



> Peter






>

> >

> >

> >

> > If the client does not receive any delayed response from the =
server

> > within this Waiting-Time, the client should send again CON GET
message.

> > I believe this would be a simple way to solve the above =
mentioned

> > issues.

> >

> >

> >

> >

> >

> > Kind regards

> >

> >

> >

> > Koojana

> >

> >

> >

> > Koojana Kuladinithi

> >

> > University of Bremen, FB1 - IKOM/TZI

> >

> > Otto-Hahn Allee NW1, 28359, Bremen, Germany

> >

> > Tel. +49 421 218 62382, Fax. +49 421 218 3601,

> >

> > www:






> > http://www.comnets.uni-bremen.de/~koo<http://www.comnets.uni-bremen.de/%

> > 7Ekoo>






> >

> >

> >

> > _______________________________________________

> > core mailing list

> > core@ietf.org

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












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

| Dipl.-Ing. Markus Becker

| Communication Networks

| Mobile Research Center

| TZI - Center for Computing Technologies

| University Bremen

| Germany

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

| web: http://www.comnets.uni-bremen.de/~mab/

| mailto: mab@comnets.uni-bremen.de
| telephone: +49 421 218 62379

| building: NW1 room: N2260

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












 









------=_NextPart_000_0045_01CB7559.739031C0--


From zach@sensinode.com  Tue Oct 26 14:44:25 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD5F3A68E4 for ; Tue, 26 Oct 2010 14:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7gQ+zwm6spc for ; Tue, 26 Oct 2010 14:44:19 -0700 (PDT)
Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id ECF173A680B for ; Tue, 26 Oct 2010 14:44:16 -0700 (PDT)
Received: from mbm901sn1.teliamobile.net (192.71.148.180) by smtp-out11.han.skanova.net (8.5.124.10) id 4C7E1270016253D3; Tue, 26 Oct 2010 23:46:02 +0200
Received: from host-78-64-88-212.homerun.telia.com (host-78-64-88-212.homerun.telia.com [78.64.88.212]) by mbm901sn1.teliamobile.net (8.13.1/8.13.1) with ESMTP id o9QLk0tG016664; Tue, 26 Oct 2010 23:46:00 +0200
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-350-584715301; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: <004401cb7548$b00761c0$10162540$@uni-bremen.de>
Date: Wed, 27 Oct 2010 00:46:00 +0300
Message-Id: 
References: <001401cb7104$c9cd6480$5d682d80$@uni-bremen.de>		<201010251150.22061.mab@comnets.uni-bremen.de>  <004401cb7548$b00761c0$10162540$@uni-bremen.de>
To: Koojana Kuladinithi 
X-Mailer: Apple Mail (2.1081)
Cc: core@ietf.org
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 26 Oct 2010 21:44:25 -0000

--Apple-Mail-350-584715301
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Koojana,

This was left out on purpose for now, I think we need more WG discussion =
on the issue first. Will make a ticket on this to consider it for -04.=20=


And not totally related to this discussion: We start to have quite a few =
options, so anybody that suggests adding a new one, needs to figure out =
how to remove something else ;-)  OK, it is not that extreme, but we =
should remember that these are constrained devices, so at least =
mandatory features need to be minimized. In fact, I would say that going =
forward we need to spend our energy making CoAP even simpler than it is =
now rather than more complex.=20

Zach

On Oct 26, 2010, at 11:02 PM, Koojana Kuladinithi wrote:

> Hello Zach,
> =20
> As far as I understood, the client behavior of processing asynchronous =
response (section 2.1.2) is not defined properly in the 03.txt version. =
We had few email discussions on this issue (see the subject =93section =
2.1.2 Asynchronous response - a loss of CON message from the Server=94).
> =20
> As Peter asked below, do you plan to address this in the current =
specification?
> =20
> Koojana
> =20
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf =
Of Peter Bigot
> Sent: Monday, October 25, 2010 2:41 PM
> To: Markus Becker
> Cc: core@ietf.org
> Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of =
CON message from the Server
> =20
> You're right: I'd inappropriately included retransmissions when =
proposing a default, somehow thinking that perhaps this delay was =
introduced or visible at the REST layer.  While this could be done, it =
is more naturally cast as a pseudo-REST or CoAP-layer concept, as is =
asynchronous responses, and retransmissions are irrelevant.
>=20
> The purpose of the default was to remove the undefined behavior in the =
base document.  If the option description doesn't make the base =
document, a default is unnecessary.  Similarly, the option might as well =
be elective in that case, because system designers couldn't assume =
clients will implement the option anyway and for usability a system must =
be robust in the presence of clients that don't know how long they =
should wait (where "robust" should not mean sending a critical option =
that may cause the client to fail its request unnecessarily).
>=20
> Question: I understand, maybe incorrectly, that there's a huge push to =
get CoAP to RFC status ASAP, and that the WG's period-of-performance =
ends in December.  Is there any chance for options and major changes =
that won't be in coap-03 being added before CoAP becomes an RFC?  Or do =
we need to start writing separate documents for this sort of thing?
>=20
> Peter
>=20
> On Mon, Oct 25, 2010 at 4:50 AM, Markus Becker =
 wrote:
> > As Carsten notes, the defined behavior is your option 1 (server =
retransmits
> > con response message).
> >
> > I agree there is some uncertainty resulting from the asynchronous =
response
> > not having a time limit, and I too would rather have it resolved so =
I don't
> > have to hold onto request state in the client for an unbounded =
period, in
> > hopes that eventually my answer will come.
> >
> > I read what you're suggesting as an elective header option, to be =
placed in
> > the ACK that indicates an asynchronous response, providing an upper =
bound
> > on how long the client should expect to wait for a response.
>=20
> An additional header option, yes. However, not sure about elective or
> critical. It needs to be elective option because it is in a ACK. (Can =
ACKs or
> RSTs include critical options at all?) It would however also need to =
be
> understood by all clients, because client behaviour after receiving =
the ACK is
> not yet defined properly ('request state for unbounded period').
>=20
> > Further, we should give it a reasonable default.   31 seconds may =
elapse
> > between first CON transmission and last CON retransmission given the
> > default settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which =
point
> > the server will give up.  A default of 60 allows about 29 seconds =
for the
> > server to create the response representation before risking the =
client
> > giving up too soon.
> >
> > Then a client that has not received the response after that time =
plus a
> > fudge term for network delays can assume the message is lost and =
recover in
> > whatever way is appropriate (e.g., retransmit the GET or give up).
> >
> > I like this.
>=20
> You are proposing the waiting time to be the processing time + time =
for
> retransmissions + network delays. What we suggested was the processing =
time +
> network delay of the response (without considering retransmissions of =
the
> server) and then let the client try the retransmission. We thought of =
this
> because of high delay links easily triggering unnecessary =
retransmissions.
>=20
> > On Thu, Oct 21, 2010 at 4:46 AM, Koojana Kuladinithi <
> > koo@comnets.uni-bremen.de> wrote:
> [snip]
> > > 2.  The server sends ACK as in Figure 3, but with a =
Processing-Delay
> > > option if the response gets delayed. (the experiments we did here =
show
> > > that to get temperature/humidity results from an embedded device, =
it
> > > takes about ~300 ms). This Processing-Delay can be decided by the =
server
> > > based on the type of URI. This lets the client to compute the =
waiting
> > > time to get the asynchronous response. Example, Waiting-Time =3D
> > > (Processing-Delay +  RTT + xx delay).
>=20
> > BTW: We did all realize that servers supporting asynchronous =
responses
> > should keep hold of the TID for the original request in the client =
response
> > record, so that if the server ACK gets lost and the client =
retransmits it
> > isn't interpreted as a new request, right?  I don't think I've seen =
that
> > called out explicitly anywhere.
>=20
> True.
>=20
> Best regards,
> Markus
>=20
> > Peter
> >
> > >
> > >
> > >
> > > If the client does not receive any delayed response from the =
server
> > > within this Waiting-Time, the client should send again CON GET =
message.
> > > I believe this would be a simple way to solve the above mentioned
> > > issues.
> > >
> > >
> > >
> > >
> > >
> > > Kind regards
> > >
> > >
> > >
> > > Koojana
> > >
> > >
> > >
> > > Koojana Kuladinithi
> > >
> > > University of Bremen, FB1 - IKOM/TZI
> > >
> > > Otto-Hahn Allee NW1, 28359, Bremen, Germany
> > >
> > > Tel. +49 421 218 62382, Fax. +49 421 218 3601,
> > >
> > > www:
> > > =
http://www.comnets.uni-bremen.de/~koo > > 7Ekoo>
> > >
> > >
> > >
> > > _______________________________________________
> > > core mailing list
> > > core@ietf.org
> > > https://www.ietf.org/mailman/listinfo/core
> ------------------------------------------------
> | Dipl.-Ing. Markus Becker
> | Communication Networks
> | Mobile Research Center
> | TZI - Center for Computing Technologies
> | University Bremen
> | Germany
> ------------------------------------------------
> | web: http://www.comnets.uni-bremen.de/~mab/
> | mailto: mab@comnets.uni-bremen.de
> | telephone: +49 421 218 62379
> | building: NW1 room: N2260
> ------------------------------------------------
> =20

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


--Apple-Mail-350-584715301
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNjIxNDYw
MFowIwYJKoZIhvcNAQkEMRYEFHgLWeOQZQchZa0Hw6S+0USONO8jMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAFiSPTygBUoKJVIHWn5/RgGwCM2rJov63lllEhe75C/7sKiHbVgl3Ewj
D7NMaS1xdmF3MXAglo8aHw59MGVD2P4p4C+1hcDPAZJ1bIldV27ey7J6PCaQSsqWHa9FIboFsm2C
mieXl4YNdgWLdqlOsk819kM4ja/mvyG3C466wkKoVNH08LBJqpUoEXvCfK9Wa1MXsBaM8CscP3Z/
dKHU6c+HeY4AxveWpU0RoRbEr+ydoFdPbNudedo+MNZuFLlKJay+v+VIAkV8t3X6eS+50QyAFb3y
vcIBqLPsZf1iWQkuGc0Q/0iyY+LeU2k+86cOjfDHkeERybUH0YVADoTydMMAAAAAAAA=

--Apple-Mail-350-584715301--

From vipul.x.gupta@oracle.com  Tue Oct 26 15:59:02 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1563A691D for ; Tue, 26 Oct 2010 15:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.598
X-Spam-Level: 
X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfeKViCZE5a8 for ; Tue, 26 Oct 2010 15:59:01 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3984B3A6895 for ; Tue, 26 Oct 2010 15:58:57 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9QN0hJY022070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Oct 2010 23:00:44 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9QMRWaJ005886 for ; Tue, 26 Oct 2010 23:00:42 GMT
Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 725637911288133929; Tue, 26 Oct 2010 15:58:49 -0700
Received: from dhcp-umpk16-75-188.sfbay.sun.com (/129.146.75.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Oct 2010 15:58:49 -0700
From: Vipul Gupta 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 26 Oct 2010 15:58:47 -0700
Message-Id: 
To: core@ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Cc: Vipul Gupta 
Subject: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 22:59:02 -0000

The draft describes a mechanism for CoAP clients to observe changes 
to a resource. In my experience (primarily with Sensor.Network [1]),
it is more useful to be able to subscribe to specific changes to a 
resource, e.g. when the soil moisture falls below a certain threshold 
or an object being tracked enters a given geographical area (geo-
fencing). If the client were to be notified upon every change to 
the resource (moisture or location) in these situations, it would 
be quickly overwhelmed. While the current draft offers an improvement 
over periodic polling of the resource by a client, I feel it doesn't 
go far enough to be really useful.

I also find the use of GETs to create a subscription unweildy. A 
POST to a subscription URL for a resource seems to fit the REST model 
much better. Webhooks (see http://wiki.webhooks.org/RESTful-WebHooks) 
is emerging as a popular way to do notifications with HTTP. Resources 
that allow subscriptions include their subscription URL as part of the
HTTP link header and subsriptions are created via a POST to the subscription 
URL. Notifications take the form of HTTP POSTs to a URL (the 
notification end-point). The POST body in the subscription request can 
be used to specify not only the notification end-point but also the 
specific changes the client is interested in. 

We will need to nail down some additional details but adopting 
something based on Webhooks here would address limitations of the 
current draft (e.g. in applications like geo-fencing, multiple 
clients need to create subscriptions with different criteria on 
the same resource). In addition, it will make HTTP mapping much 
easier. For example, it isn't clear from the draft how multiple 
responses to the GET are mapped to HTTP at an HTTP<->CoAP gateway.

vipul

--
[1] For more info, see http://sensor.network.com/ or
    the presentation/paper on Sensor.Network at 
    http://www.webofthings.com/wot/2010/program.php


From klaus.hartke@googlemail.com  Tue Oct 26 17:50:42 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB8A3A68D2 for ; Tue, 26 Oct 2010 17:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.327
X-Spam-Level: 
X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNbJOdY1qQ+W for ; Tue, 26 Oct 2010 17:50:41 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 25F923A6893 for ; Tue, 26 Oct 2010 17:50:40 -0700 (PDT)
Received: by bwz12 with SMTP id 12so118591bwz.31 for ; Tue, 26 Oct 2010 17:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=FtwlCjGUr32FSZeiyYqLhfl1USQZ0+04JzYEXt6Ui28=; b=ThUyUvdFQwpeR0TLYP9zscsrYFXhd9Dbux0ef5JG0JqzKICrUE6EYI6kZW5x7dT5jB kkAXhapTDY0BIsrK0OrhFoOyQubIocWn7gZ7MgRmslrZxmt1yXIj4B/9XQNnrcXIotvz SzOhtS9iYsCXi5a1p3s3RI8TDVikN54FpEbrE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GvHJukHHc61+yXgoZ8vFdFS0XnrGrDAWfyT/CmkOe1MxRPiZ0mxXhz1D3yunNX0iIK 013nxmLVnj4jCJL9Sq+HuI08GQFLU/AebEZ00OvMNfr+ZsfMzhr99XCftS0caiZQdvRw ub8f1BA/6Nf3CH6AzFDi+2OVHrSGTt9WRfPw4=
MIME-Version: 1.0
Received: by 10.204.72.207 with SMTP id n15mr5840171bkj.208.1288140748893; Tue, 26 Oct 2010 17:52:28 -0700 (PDT)
Received: by 10.204.101.65 with HTTP; Tue, 26 Oct 2010 17:52:28 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 27 Oct 2010 02:52:28 +0200
Message-ID: 
From: Klaus Hartke 
To: core 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 00:50:42 -0000

It sounds like you actually want to observe a resource
coap://server/tracked-object/is-in-area-51 and not
coap://server/tracked-object/current-position.

When you expose your sensors over CoAP, you need to model the sensors
as RESTful resources. The most basic way to do this, is to expose the
state of the subject itself, e.g., the current temperature in some
room. But that's not the only way, there are other ways to expose the
state as well. You can create a resource whose state indicates whether
the temperature is currently above 40*C or not. You can create a
resource whose state is the average of the temperature in the last 30
minutes. You can create a resource whose state indicates whether the
temperature was above 40*C in the last 30 minutes. The possibilities
are endless. It depends on what clients are really interested in.

And remember that resources can be paramterized. You don't need to
create a resource for each possible threshold. You can create a
resource coap://server/soil-moisture?is-below-threshold=X which can be
observed and which indicates if the soil moisture is below threshold
X, rather than returning the soil moisture. Different clients can
observe the same resource with different parameters, and be notified
depending on what they're individually interested in.

So the current observation mechanism is already quite powerful, and in
my opinion it fits very well into a RESTful architecture as is. Like
the block/slice draft extends a GET request in the space dimension,
the observe draft extends a GET request in the time dimension. We use
GET, because that's what GET does - retrieve a representation of the
state of a resource: with block/slice at different locations, with
observe at different points of time.

Klaus

From klaus.hartke@googlemail.com  Tue Oct 26 18:54:17 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54243A6915 for ; Tue, 26 Oct 2010 18:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level: 
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E4xdP9mwE-U for ; Tue, 26 Oct 2010 18:54:15 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 457343A6907 for ; Tue, 26 Oct 2010 18:54:15 -0700 (PDT)
Received: by bwz12 with SMTP id 12so151211bwz.31 for ; Tue, 26 Oct 2010 18:56:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:from:in-reply-to:mime-version :references:date:message-id:subject:to:content-type; bh=ABoXQAsqGD+OgDFOLSHoEM2lk9rICcOyC7nVDGB5LIQ=; b=ObycTL48g1PxALTOU1eNj1sJA+eg/pAvoV2HB42r6HrMkPEHP5MA2Uzk8CKovTckNi NRI+9MJqxxtNNWPPg68PXlr6xXqkSqJIY9JZurFkDiiAIFvoFceJPdXs3J3RmjNazqCw vo+GnCOe+PFhps/1iVFmZSgPOd2cLiQd8Crfg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:in-reply-to:mime-version:references:date:message-id:subject:to :content-type; b=cdRChyQoEB+d5QSKxjh+tdiHy3KE05YU/3D5KIfsVjftUTwspTJWGMlrb9aFFeco9q AG6xozbut9pL2cZm/loRAWtEJTipzSs0m0pweuyJmGwOmYxpr6J0bWsXjKX5Kynsjeqo M+LVeVspzBBDc12qlFhGtBDIdt09xsvtGaPE8=
Received: by 10.204.47.226 with SMTP id o34mr445625bkf.191.1288144562849; Tue, 26 Oct 2010 18:56:02 -0700 (PDT)
From: Klaus Hartke 
In-Reply-To: 
Mime-Version: 1.0 (iPad Mail 7B500)
References: 
Date: Wed, 27 Oct 2010 03:56:30 +0200
Message-ID: <-3618312296587419244@unknownmsgid>
To: core 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 01:54:17 -0000

The difference between CoAP and HTTP is that HTTP doesn't have a
built-in way to observe the changes to the state of a resource. That
makes the HTTP/CoAP mapping slightly more difficult than just
translating messages between CoAP and HTTP syntax, but doesn't mean we
shouldn't have observations in CoAP.

The way to map CoAP-observe to HTTP is to implement the same design
pattern in HTTP and then map between the two incarnations.

There are many ways to implement the subject/observer design pattern
in HTTP. Possible options include long-polling, WebSockets, or
Server-Sent Events (eventsource).

If an HTTP client wants to observe a CoAP resource, it uses the HTTP
observation mechanism to talk to the HTTP/CoAP gateway, and the
HTTP/CoAP gateway uses CoAP-observe to observe the desired resource on
behalf of the the HTTP client.

So, for example, in the case of Server-Sent Events, the gateway will
need to transform the multiple responses to the CoAP GET request to
multiple event stream events.

We don't need to make observing the state of resources complex just to
make the mapping to HTTP simple.

Klaus

From pab@peoplepowerco.com  Tue Oct 26 19:09:40 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742A23A68F1 for ; Tue, 26 Oct 2010 19:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_44=1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcwKFR8ffNMS for ; Tue, 26 Oct 2010 19:09:39 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 97AD43A6825 for ; Tue, 26 Oct 2010 19:09:38 -0700 (PDT)
Received: by fxm9 with SMTP id 9so219890fxm.31 for ; Tue, 26 Oct 2010 19:11:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.95.195 with SMTP id e3mr1638394fan.96.1288145486056; Tue, 26 Oct 2010 19:11:26 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Tue, 26 Oct 2010 19:11:26 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 26 Oct 2010 21:11:26 -0500
Message-ID: 
From: Peter Bigot 
To: Vipul Gupta 
Content-Type: multipart/alternative; boundary=00248c0eea841d8cd004938fbe11
Cc: core@ietf.org
Subject: Re: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 02:09:40 -0000

--00248c0eea841d8cd004938fbe11
Content-Type: text/plain; charset=ISO-8859-1

The Webhooks approach is interesting, though the requirement that the
resource owner notify by posting through a second party may be too
inefficient in a constrained environment (it does nicely decouple the
notification from the decision of whether to use sequential unicast or
multicast).  This solution seems almost in line with my suggestion that
observation be simply a way of applying CoAP: if you have different needs
you can do it a different way.

I think the implementation of the webhooks approach in CoAP might benefit
from adding a Notification-Type header, though this could also go in the
body along with the multiple link descriptions used in some situations.  If
we had provision for user-defined options, it would be easy for people to do
this and other observe variants (excluding those that affect the transaction
state machine) without creating any more interoperability problems than
private IP-based services supported in the dynamic port range.  Any such
solution that got significant market share could easily be made standard
with controlled option values.

Peter

On Tue, Oct 26, 2010 at 5:58 PM, Vipul Gupta wrote:

> The draft describes a mechanism for CoAP clients to observe changes
> to a resource. In my experience (primarily with Sensor.Network [1]),
> it is more useful to be able to subscribe to specific changes to a
> resource, e.g. when the soil moisture falls below a certain threshold
> or an object being tracked enters a given geographical area (geo-
> fencing). If the client were to be notified upon every change to
> the resource (moisture or location) in these situations, it would
> be quickly overwhelmed. While the current draft offers an improvement
> over periodic polling of the resource by a client, I feel it doesn't
> go far enough to be really useful.
>
> I also find the use of GETs to create a subscription unweildy. A
> POST to a subscription URL for a resource seems to fit the REST model
> much better. Webhooks (see http://wiki.webhooks.org/RESTful-WebHooks)
> is emerging as a popular way to do notifications with HTTP. Resources
> that allow subscriptions include their subscription URL as part of the
> HTTP link header and subsriptions are created via a POST to the
> subscription
> URL. Notifications take the form of HTTP POSTs to a URL (the
> notification end-point). The POST body in the subscription request can
> be used to specify not only the notification end-point but also the
> specific changes the client is interested in.
>
> We will need to nail down some additional details but adopting
> something based on Webhooks here would address limitations of the
> current draft (e.g. in applications like geo-fencing, multiple
> clients need to create subscriptions with different criteria on
> the same resource). In addition, it will make HTTP mapping much
> easier. For example, it isn't clear from the draft how multiple
> responses to the GET are mapped to HTTP at an HTTP<->CoAP gateway.
>
> vipul
>
> --
> [1] For more info, see http://sensor.network.com/ or
>    the presentation/paper on Sensor.Network at
>    http://www.webofthings.com/wot/2010/program.php
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--00248c0eea841d8cd004938fbe11
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The Webhooks approach is interesting, though the requirement that the resou=
rce owner notify by posting through a second party may be too inefficient i=
n a constrained environment (it does nicely decouple the notification from =
the decision of whether to use sequential unicast or multicast).=A0 This so=
lution seems almost in line with my suggestion that observation be simply a=
 way of applying CoAP: if you have different needs you can do it a differen=
t way.=A0 



I think the implementation of the webhooks approach in CoAP might=20
benefit from adding a Notification-Type header, though this could also=20
go in the body along with the multiple link descriptions used in some=20
situations.=A0 If we had provision for user-defined options, it would be ea=
sy for people to do this and other observe variants (excluding those that a=
ffect the transaction state machine) without creating any more interoperabi=
lity problems than private IP-based services supported in the dynamic port =
range.=A0 Any such solution that got significant market share could easily =
be made standard with controlled option values.



Peter

On Tue, Oct 26, 2010 at 5:58 PM=
, Vipul Gupta <vipul.x.gupta@oracle.com> wrote:


The draft describes a mechanism for CoAP clients to observe changes

to a resource. In my experience (primarily with Sensor.Network [1]),

it is more useful to be able to subscribe to specific changes to a

resource, e.g. when the soil moisture falls below a certain threshold

or an object being tracked enters a given geographical area (geo-

fencing). If the client were to be notified upon every change to

the resource (moisture or location) in these situations, it would

be quickly overwhelmed. While the current draft offers an improvement

over periodic polling of the resource by a client, I feel it doesn't
go far enough to be really useful.



I also find the use of GETs to create a subscription unweildy. A

POST to a subscription URL for a resource seems to fit the REST model

much better. Webhooks (see http://wiki.webhooks.org/RESTful-WebHooks)

is emerging as a popular way to do notifications with HTTP. Resources

that allow subscriptions include their subscription URL as part of the

HTTP link header and subsriptions are created via a POST to the subscriptio=
n

URL. Notifications take the form of HTTP POSTs to a URL (the

notification end-point). The POST body in the subscription request can

be used to specify not only the notification end-point but also the

specific changes the client is interested in.



We will need to nail down some additional details but adopting

something based on Webhooks here would address limitations of the

current draft (e.g. in applications like geo-fencing, multiple

clients need to create subscriptions with different criteria on

the same resource). In addition, it will make HTTP mapping much

easier. For example, it isn't clear from the draft how multiple

responses to the GET are mapped to HTTP at an HTTP<->CoAP gateway.


vipul



--

[1] For more info, see http://sensor.network.com/ or

 =A0 =A0the presentation/paper on Sensor.Network at

 =A0 =A0http://www.webofthings.com/wot/2010/program.php



_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core







--00248c0eea841d8cd004938fbe11--

From pab@peoplepowerco.com  Tue Oct 26 19:09:42 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5AE3A6927 for ; Tue, 26 Oct 2010 19:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.275,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hkZbn7xFAAY for ; Tue, 26 Oct 2010 19:09:41 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1F8663A6825 for ; Tue, 26 Oct 2010 19:09:40 -0700 (PDT)
Received: by mail-fx0-f44.google.com with SMTP id 9so219890fxm.31 for ; Tue, 26 Oct 2010 19:11:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.103.16 with SMTP id i16mr1652028fao.34.1288145489581; Tue, 26 Oct 2010 19:11:29 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Tue, 26 Oct 2010 19:11:29 -0700 (PDT)
In-Reply-To: 
References:  
Date: Tue, 26 Oct 2010 21:11:29 -0500
Message-ID: 
From: Peter Bigot 
To: Klaus Hartke 
Content-Type: multipart/alternative; boundary=20cf3054ac8753668404938fbe8c
Cc: core 
Subject: Re: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 02:09:42 -0000

--20cf3054ac8753668404938fbe8c
Content-Type: text/plain; charset=ISO-8859-1

 The selection of how to model the resources (event or state) is clearly an
application choice; similarly the application would necessarily be involved
in any decision regarding filtering based on values.  With that much
application involvement anyway, I'm really not seeing a compelling need to
also involve the protocol.

The proposed coap-observe solution is indeed powerful.  I don't see it as
necessary.  Every use case I've encountered can be solved with base coap.
Nor do I see it as RESTful.  Resources are already a temporal map (Fielding
# 5.2.1.1) ; GET is expected to produce a representation of the resource at
the current time (unless the definition of the resource includes a
historical aspect, in which case it's still the value of that historical
content as known at the current time).  Extending a single get request
across time (or perhaps it's across an axis representing state change
events) doesn't make sense to me within a REST model.  Acknowledging that
CoAP need not be REST, I am still concerned with how this approach
complicates the basic transaction state machine by allowing multiple
responses to a single request.

coap-block, in turn, does solve a problem that exists in base coap (transfer
of large representations), though I think the newer concepts also take it
away from being RESTful (by introducing internal structure that is not
reflected in the resource URI).  Again, irrelevant to whatever degree you're
uninterested in requiring CoAP to be REST-compatible all the way down.
Nontheless, having re-read the TFTP spec (RFC1350), my preference is still
to redirect large transfers to that protocol.  Extremely simple, designed
specifically for constrained environments, and over eighteen years in the
field proves it works.  Only thing required in some cases is to implement
RFC2348 to get the packet size down to where it'll work in a constrained
network.

Peter

On Tue, Oct 26, 2010 at 7:52 PM, Klaus Hartke
wrote:

> It sounds like you actually want to observe a resource
> coap://server/tracked-object/is-in-area-51 and not
> coap://server/tracked-object/current-position.
>
> When you expose your sensors over CoAP, you need to model the sensors
> as RESTful resources. The most basic way to do this, is to expose the
> state of the subject itself, e.g., the current temperature in some
> room. But that's not the only way, there are other ways to expose the
> state as well. You can create a resource whose state indicates whether
> the temperature is currently above 40*C or not. You can create a
> resource whose state is the average of the temperature in the last 30
> minutes. You can create a resource whose state indicates whether the
> temperature was above 40*C in the last 30 minutes. The possibilities
> are endless. It depends on what clients are really interested in.
>
> And remember that resources can be paramterized. You don't need to
> create a resource for each possible threshold. You can create a
> resource coap://server/soil-moisture?is-below-threshold=X which can be
> observed and which indicates if the soil moisture is below threshold
> X, rather than returning the soil moisture. Different clients can
> observe the same resource with different parameters, and be notified
> depending on what they're individually interested in.
>
> So the current observation mechanism is already quite powerful, and in
> my opinion it fits very well into a RESTful architecture as is. Like
> the block/slice draft extends a GET request in the space dimension,
> the observe draft extends a GET request in the time dimension. We use
> GET, because that's what GET does - retrieve a representation of the
> state of a resource: with block/slice at different locations, with
> observe at different points of time.
>
> Klaus
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--20cf3054ac8753668404938fbe8c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


The selection of how to model the resources (event or state) is clearly=20
an application choice; similarly the application would necessarily be=20
involved in any decision regarding filtering based on values.=A0 With that
 much application involvement anyway, I'm really not seeing a compellin=
g=20
need to also involve the protocol.


The proposed coap-observe solution is indeed powerful.=A0 I don't s=
ee it as necessary.=A0 Every use case I've encountered can be solved wi=
th base coap.=A0 Nor do I see it as RESTful.=A0 Resources are already a tem=
poral map (Fielding # 5.2.1.1) ; GET is expected to produce a representatio=
n of the resource at the current time (unless the definition of the resourc=
e includes a historical aspect, in which case it's still the value of t=
hat historical content as known at the current time).=A0 Extending a single=
 get request across time (or perhaps it's across an axis representing s=
tate change events) doesn't make sense to me within a REST model.=A0 Ac=
knowledging that CoAP need not be REST, I am still concerned with how this =
approach complicates the basic transaction state machine by allowing multip=
le responses to a single request.



coap-block, in turn, does solve a problem that=20
exists in base coap (transfer of large representations), though I think=20
the newer concepts also take it away from being RESTful (by introducing=20
internal structure that is not reflected in the resource URI).=A0 Again, ir=
relevant to whatever degree you're uninterested in requiring CoAP to be=
 REST-compatible all the way down.=A0 Nontheless, having re-read the TFTP s=
pec (RFC1350), my preference is still to=20
redirect large transfers to that protocol.=A0 Extremely simple, designed=20
specifically for constrained environments, and over eighteen years in=20
the field proves it works.=A0 Only thing required in some cases is to imple=
ment RFC2348=20
to get the packet size down to where it'll work in a constrained=20
network.



Peter

On Tue, Oct 26, 2010 at 7:52 PM, Kl=
aus Hartke <klaus.hartke@googlemail.com> wrote:


It sounds like you actually want to observe a resource

coap://server/tracked-object/is-in-area-51 and not

coap://server/tracked-object/current-position.



When you expose your sensors over CoAP, you need to model the sensors

as RESTful resources. The most basic way to do this, is to expose the

state of the subject itself, e.g., the current temperature in some

room. But that's not the only way, there are other ways to expose the
state as well. You can create a resource whose state indicates whether

the temperature is currently above 40*C or not. You can create a

resource whose state is the average of the temperature in the last 30

minutes. You can create a resource whose state indicates whether the

temperature was above 40*C in the last 30 minutes. The possibilities

are endless. It depends on what clients are really interested in.



And remember that resources can be paramterized. You don't need to

create a resource for each possible threshold. You can create a

resource coap://server/soil-moisture?is-below-threshold=3DX which can be
observed and which indicates if the soil moisture is below threshold

X, rather than returning the soil moisture. Different clients can

observe the same resource with different parameters, and be notified

depending on what they're individually interested in.



So the current observation mechanism is already quite powerful, and in

my opinion it fits very well into a RESTful architecture as is. Like

the block/slice draft extends a GET request in the space dimension,

the observe draft extends a GET request in the time dimension. We use

GET, because that's what GET does - retrieve a representation of the
state of a resource: with block/slice at different locations, with

observe at different points of time.



Klaus


_______________________________________________=


core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core







--20cf3054ac8753668404938fbe8c--

From prvs=5916D9C3A1=guido.moritz@uni-rostock.de  Wed Oct 27 01:15:38 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624B03A677E for ; Wed, 27 Oct 2010 01:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.505
X-Spam-Level: 
X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdBvkPYwdh+K for ; Wed, 27 Oct 2010 01:15:35 -0700 (PDT)
Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id DC36F3A6941 for ; Wed, 27 Oct 2010 01:15:34 -0700 (PDT)
From: Guido Moritz 
To: 'core' 
Date: Wed, 27 Oct 2010 10:17:23 +0200
Message-ID: <002b01cb75af$624644d0$26d2ce70$@uni-rostock.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Act1rucRCOfC90rZRHuomw7bhTQC5w==
Content-Language: de
Subject: [core] Uri Query Option
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Oct 2010 08:15:38 -0000

Dear WG,

the draft-ietf-core-coap-03 specifies in section 3.2.4: Uri-Query Option
MUST be supported by all end-points

But in draft-ietf-core-link-format-01 section 3.1, a server MAY implement
this feature

Is this a contradiction or am I wrong at some point?

BRGDs,
Guido




From cabo@tzi.org  Wed Oct 27 01:47:58 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35EAD3A6919 for ; Wed, 27 Oct 2010 01:47:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.18
X-Spam-Level: 
X-Spam-Status: No, score=-106.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0kBW2RUdXyU for ; Wed, 27 Oct 2010 01:47:57 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E525E3A67A2 for ; Wed, 27 Oct 2010 01:47:56 -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 o9R8nbRX023095; Wed, 27 Oct 2010 10:49:37 +0200 (CEST)
Received: from [192.168.217.101] (p5489D870.dip.t-dialin.net [84.137.216.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E58E1E38; Wed, 27 Oct 2010 10:49:36 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <002b01cb75af$624644d0$26d2ce70$@uni-rostock.de>
Date: Wed, 27 Oct 2010 10:49:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <92A646BF-CB85-45A4-9D29-1EEF3D2A6BDC@tzi.org>
References: <002b01cb75af$624644d0$26d2ce70$@uni-rostock.de>
To: Guido Moritz 
X-Mailer: Apple Mail (2.1081)
Cc: 'core' 
Subject: Re: [core] Uri Query Option
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Oct 2010 08:47:58 -0000

Uri-Query is for encoding the query-part of a URI, see section 3.4 of =
RFC 3986.
URI queries are a feature that is not just used in link-format.

I think the language "MUST support" in 3.2.4 may be a bit misleading, =
because a node need not actually support any URIs that indeed have a =
query, so sending back a 404 on anything that has an option 15 is one =
form of "support".

The intention is certainly not to require support of the link-format's =
discovery query filtering by all nodes -- that is indeed the reason the =
link-format draft says MAY.

Gruesse, Carsten


From prvs=7916833A9D=guido.moritz@uni-rostock.de  Wed Oct 27 02:21:44 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05CA3A6923 for ; Wed, 27 Oct 2010 02:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248,  BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GbmhjpvJvak for ; Wed, 27 Oct 2010 02:21:43 -0700 (PDT)
Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id 6D6153A6905 for ; Wed, 27 Oct 2010 02:21:43 -0700 (PDT)
From: Guido Moritz 
To: 'Carsten Bormann' 
References: <002b01cb75af$624644d0$26d2ce70$@uni-rostock.de> <92A646BF-CB85-45A4-9D29-1EEF3D2A6BDC@tzi.org>
In-Reply-To: <92A646BF-CB85-45A4-9D29-1EEF3D2A6BDC@tzi.org>
Date: Wed, 27 Oct 2010 11:23:33 +0200
Message-ID: <003001cb75b8$a05c58f0$e1150ad0$@uni-rostock.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFu/X9Gm0MctXiwKJWHl0RqWlLgQAGN+28blAEC8TA=
Content-Language: de
Cc: 'core' 
Subject: Re: [core] Uri Query Option
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Oct 2010 09:21:44 -0000

> Uri-Query is for encoding the query-part of a URI, see section 3.4 of RFC
> 3986.
> URI queries are a feature that is not just used in link-format.
Agreed.

> 
> I think the language "MUST support" in 3.2.4 may be a bit misleading,
> because a node need not actually support any URIs that indeed have a
> query, so sending back a 404 on anything that has an option 15 is one form
of
> "support".
Indeed, not having a resource in the arsenal which fits the query causes a
404. But the "MUST support" requires the server to act somehow on the query
and not simply ignore it and send an error.

> 
> The intention is certainly not to require support of the link-format's
discovery
> query filtering by all nodes -- that is indeed the reason the link-format
draft
> says MAY.
I don't have implemented CoAP, but when the query "filtering" described in
coap-03 MUST be supported (despite the according resource might not exist or
the query does not fit to be applied to the resource), why can't this "query
filtering" be reused for the discovery query filtering?

So it might not be a contradiction, but somehow misleading...

> 
> Gruesse, Carsten
RGDs,
Guido



From cabo@tzi.org  Wed Oct 27 03:38:08 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DB23A693A for ; Wed, 27 Oct 2010 03:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.239
X-Spam-Level: 
X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QplZYOLkgfyY for ; Wed, 27 Oct 2010 03:38:05 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 9D9733A6778 for ; Wed, 27 Oct 2010 03:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9RAdj2t012580; Wed, 27 Oct 2010 12:39:45 +0200 (CEST)
Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EE627F32; Wed, 27 Oct 2010 12:39:44 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <003001cb75b8$a05c58f0$e1150ad0$@uni-rostock.de>
Date: Wed, 27 Oct 2010 12:39:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <395BF721-0280-4161-98AC-B8A96AFD473D@tzi.org>
References: <002b01cb75af$624644d0$26d2ce70$@uni-rostock.de> <92A646BF-CB85-45A4-9D29-1EEF3D2A6BDC@tzi.org> <003001cb75b8$a05c58f0$e1150ad0$@uni-rostock.de>
To: Guido Moritz 
X-Mailer: Apple Mail (2.1081)
Cc: 'core' 
Subject: Re: [core] Uri Query Option
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Oct 2010 10:38:09 -0000

>> I think the language "MUST support" in 3.2.4 may be a bit misleading,
>> because a node need not actually support any URIs that indeed have a
>> query, so sending back a 404 on anything that has an option 15 is one =
form
> of
>> "support".
> Indeed, not having a resource in the arsenal which fits the query =
causes a
> 404. But the "MUST support" requires the server to act somehow on the =
query
> and not simply ignore it and send an error.

No, requiring every server to implement at least one URI with a =
query-part is not the intention, and that's why I said the language may =
be misleading.

The "support" required is approximately

if (option_number =3D=3D 15) {
  ack_with(404);
  return;
}

We can discuss whether that is too much of a burden and returning a =
parameter problem (602 =3D=3D 242 in CoAP's base 10-4 representation) =
would be sufficient.

>> The intention is certainly not to require support of the =
link-format's
> discovery
>> query filtering by all nodes -- that is indeed the reason the =
link-format
> draft
>> says MAY.
> I don't have implemented CoAP, but when the query "filtering" =
described in
> coap-03

coap-03 does not define any filtering.
It provides a syntactic way to transport a query-part of a URI.
Nothing in coap-03 assigns any semantics to this syntactic element, so =
no support of any specific semantics can be required from that alone.
link-format-01 assigns semantics to the query-part for /.well-known/core =
only. =20
And implementing those is optional.

switch(option) {
	...
	case 15: break; /* ignore option */
	...
}

is probably the minimal implementation that is most appropriate here.

Gruesse, Carsten


From cabo@tzi.org  Wed Oct 27 07:31:43 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493CD3A692F for ; Wed, 27 Oct 2010 07:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.231
X-Spam-Level: 
X-Spam-Status: No, score=-107.231 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTg-zLOZcUEz for ; Wed, 27 Oct 2010 07:31:42 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E5D673A6784 for ; Wed, 27 Oct 2010 07:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9REXP7W011226 for ; Wed, 27 Oct 2010 16:33:25 +0200 (CEST)
Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6F7E0153; Wed, 27 Oct 2010 16:33:25 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
X-Priority: 3
In-Reply-To: 
Date: Wed, 27 Oct 2010 16:33:24 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <571076BF-939F-4980-8625-662955B9D356@tzi.org>
References: <161741695.1288111441984.JavaMail.nobody@jsj2wl015.webex.com> 
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] Fwd: Meeting invitation: CORE WG
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 14:31:43 -0000

... and here is an agenda.
Hear you in 26 minutes...

Gruesse, Carsten

Agenda for 2010-10-27 CoRE WG phone call
1500 UTC

Since Zach is sitting in a plane in the first hour, and Peter Bigot
also is likely to be late, we'll do this in a slightly illogical
sequence.

* Group Communication/Multicast

draft-rahman-core-groupcomm	-01		new	2010-10-25
draft-vanderstok-core-bc	-02		new	2010-10-25

* Security

draft-oflynn-core-bootstrapping	-02			2010-10-19

(Leaping forward to the security considerations of core-coap:)
More security considerations?

* The Slicing Methods

draft-ietf-core-block           -00			2010-10-18
draft-bormann-core-coap-block	-01		new	2010-10-24

* Some core-coap details:

** Too many options

Critical option Uri-query?
Is there a need for Uri-authority-binary?
The "I'll have that info in ___ ms" option?

** Error codes

Is the 6xx (24x in base 10-4) solution right?

* (Zach is hopefully now here:)

draft-ietf-core-coap	        -03		new	2010-10-25
draft-ietf-core-link-format	-01		new	2010-10-25

draft-ietf-core-observe	        -00			2010-10-18

* Miscellaneous

** New time?  In the winter, 1500 UTC is 0700 PST.


From rstruik.ext@gmail.com  Wed Oct 27 08:02:29 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E80A3A6A4D for ; Wed, 27 Oct 2010 08:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.314
X-Spam-Level: 
X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOd6IYH3UlRh for ; Wed, 27 Oct 2010 08:02:27 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id E0A693A6A5B for ; Wed, 27 Oct 2010 08:02:26 -0700 (PDT)
Received: by eyd10 with SMTP id 10so421616eyd.31 for ; Wed, 27 Oct 2010 08:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:cc:subject:references:in-reply-to :content-type; bh=yTkQ5chtaCGJg4WFLWhD4W+jItbdLIdKlP+fsNiK3SM=; b=o85dCS20HoR7Lhmkwv0g7rOdgAJkFPTy8BbMrh1jyrDMKV74crp/DtM4ua8y4ot8tt deQGjO4EEIm3zpIzfzDafOKNOHZknFtnfchM9zsDZJ78ZtAghjisKIfCAB5ImsmOU8WN DVIIGWl4aSqYjk8wJhEBItFoxH/jJ6aT5+OJk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type; b=PZYpTdrSK+yscV6l6+NlAaucXYEbXztL9EZPO070Buqgv1hH/oj1XGRmXe8vXPJxUw lvGWpFPOvHMhCuefwyiIL0nuaUS/Eujwrgc634O8HnrKeBgbkYBs40c9abM42ND+Xa20 q8/j7MCmWMNbIZmfGs+3sykoIOERaJPuij3gQ=
Received: by 10.213.34.69 with SMTP id k5mr874432ebd.9.1288191856064; Wed, 27 Oct 2010 08:04:16 -0700 (PDT)
Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id b52sm9752006eei.19.2010.10.27.08.04.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 08:04:11 -0700 (PDT)
Message-ID: <4CC83F61.5060109@gmail.com>
Date: Wed, 27 Oct 2010 11:04:01 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
CC: core 
References:   <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com>  <4CA5E8E0.4030503@gmail.com>  <4CA6095F.6040403@gmail.com>  <4CB48B9B.9010206@gmail.com>
In-Reply-To: <4CB48B9B.9010206@gmail.com>
Content-Type: multipart/alternative; boundary="------------000902050302020906010009"
Subject: [core] concerns re draft-oflynn-core-bootstrapping-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Oct 2010 15:02:29 -0000

This is a multi-part message in MIME format.
--------------000902050302020906010009
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Dear colleagues:

I had a brief look at the bootstrapping draft 
(draft-oflynn-core-bootstrapping-02. Some comments below (I am having 
some offline discussions on this, but thought to send this to the list 
as well):

I miss a detailed analysis of deployment scenarios to be considered as 
guidance intodesign, so as to have as very minimal benchmark whether all 
those crypto protocols actually enable the deployment scenarios one has 
in mind. To me, it seems to have merit to discuss the whole spectrum and 
end up with cryptographic building blocks, security protocols, and 
security policies and accompanying enforcement mechanism for trust 
policies that would fit the operational scenarios.

I would favor not sprinkling protocol acronyms into any draft too early 
(since, in my mind, this pushes into a particular direction, and 
notalways with merit). As an example, right now I do not see how, e.g., 
HIP or cryptographically generated addresses (802.1-like) would fit 
in.Similarly, e.g., PANA does not seem to work in heterogeneous 
trustenvironments, assumes online connectivity of a "mothership" node, 
and does not seem to include consideration of how to move from one 
mothership node to the next (or, e.g., if one has an authenticator, how 
to make this work with single-hop/MAC security).

I also miss security objectives and design considerations, such as 
"separation of concern" and no entanglement of concepts from different 
disciplines in the document.

BTW - I mentioned some of this in email correspondence after the last 
CoRE conf call (Wed September 29, 2010). So far, I have not seen too 
much traffic on this. Moreover, I have not seen any adequate answers as 
to what makes, e.g., HIP features an attractive fit for CoRE-like 
environments.

Best regards, Rene

[excerpt email RS as of October 1, 2010, 12:16pm EDT]

In my mind, properties of suitable authenticated key agreement schemes 
should include (a) key establishment; (b) implicit key authentication; 
(c) key confirmation; (d) mutual entity authentication; (e) forward 
secrecy; (f) {perhaps} some more esoteric properties (key compromise 
impersonation resilience, etc.).

Moreover, the "name space" (device identifiers) and the "cryptographic 
space" (public keys, etc.) should be independent, so that this would 
allow trust lifecycle management to be reduced to proper management of 
device identifiers (i.e., *no* entanglement of concepts from different 
disciplines).


On 12/10/2010 12:23 PM, Rene Struik wrote:
> Hi Tobias:
>
> Thanks for your note.
>
> Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing);
> (b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would
> correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/
> personalization stage?
>
> Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,
> this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the
> difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g.,
> NIST?
>
> As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp
> post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper
> resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of
> symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired"
> functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that
> matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of
> draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)
>
> It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic
> properties. I would be happy to give this a look and review.
>
> Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list.
>
> Best regards, Rene
>
>
> [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT]
>
> To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated
> key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of
> the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> >  
> >  In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication;
> (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise
> impersonation resilience, etc.).
> >
> Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to
> rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small
> setups). However, I am not absolutely firm with the envisaged scenarios in CORE.
>> >  Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would
>> allow trust lifecycle management to be reduced to proper management of device identifiers (i.e.,*no*  entanglement of concepts from different
>> disciplines).
>
> Does the "*no*  entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid
> entanglement of routing and naming?
>
>
>
>
>
> On 07/10/2010 5:36 AM, Tobias Heer wrote:
>>> To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
>>> >  
>>> >  In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).
>>> >  
>> Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.
>>
>>> >  Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e.,*no*  entanglement of concepts from different disciplines).
>>
>> Does the "*no*  entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?
>>
>
>
> -- 
> email:rstruik.ext@gmail.com
> Skype: rstruik
> cell: +1 (647) 867-5658
> USA Google voice: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


--------------000902050302020906010009
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit



  
    
  
  
    Dear colleagues:

    

    I had a brief look at the bootstrapping draft
    (draft-oflynn-core-bootstrapping-02. Some comments below (I am
    having some offline discussions on this, but thought to send this to
    the list as well):

    

    I miss a detailed analysis of deployment scenarios to be considered
    as guidance into design,
    so as to have as very minimal benchmark whether all those crypto
    protocols actually enable the deployment scenarios one has in mind.
    To me, it seems to have merit to discuss the whole spectrum and end
    up with cryptographic building blocks, security protocols, and
    security policies and accompanying enforcement mechanism for trust
    policies that would fit the operational scenarios.

    

    I would favor not sprinkling protocol acronyms into any draft too
    early (since, in my mind, this pushes into a particular direction,
    and not always
    with merit). As an example, right now I do not see how, e.g., HIP or
    cryptographically generated addresses (802.1-like) would fit in. Similarly,
    e.g., PANA does not seem to work in heterogeneous trust environments,
    assumes online connectivity of a "mothership" node, and does not
    seem to include consideration of how to move from one  mothership
    node to the next (or, e.g., if one has an authenticator, how to make
    this work with single-hop/MAC security). 

    

      I also miss security objectives and design
    considerations, such as "separation of concern" and no entanglement
    of concepts from different disciplines in the document.

    

    BTW - I mentioned some of this in email correspondence after the
    last CoRE conf call (Wed September 29, 2010). So far, I have not
    seen too much traffic on this. Moreover, I have not seen any
    adequate answers as to what makes, e.g., HIP features an attractive
    fit for CoRE-like environments.

    

    Best regards, Rene

    

    [excerpt email RS as of October 1, 2010, 12:16pm EDT]

    

    In my mind, properties of suitable authenticated key agreement
    schemes should include (a) key establishment; (b) implicit key
    authentication; (c) key confirmation; (d) mutual entity
    authentication; (e) forward secrecy; (f) {perhaps} some more
    esoteric properties (key compromise impersonation resilience, etc.).
    

    

    Moreover, the "name space" (device identifiers) and the
    "cryptographic space" (public keys, etc.) should be independent, so
    that this would allow trust lifecycle management to be reduced to
    proper management of device identifiers (i.e., *no* entanglement of concepts from
    different disciplines).
    

    

    

    On 12/10/2010 12:23 PM, Rene Struik wrote:
    

      
      
Hi Tobias:

Thanks for your note. 

Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing); 
(b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would 
correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/
personalization stage?

Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,
this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the 
difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g., 
NIST?

As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp 
post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper 
resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of
symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired" 
functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that
matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of
draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)

It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic
properties. I would be happy to give this a look and review. 

Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list.

Best regards, Rene


[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT]

To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated 
key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of 
the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; 
(c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise 
impersonation resilience, etc.).
>

      
Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to 
rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small 
setups). However, I am not absolutely firm with the envisaged scenarios in CORE.


      

        
> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would 

      

      

        
allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different 

      

      

        
disciplines).


      

      
 
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid 
entanglement of routing and naming?



      

      

      

      

      On 07/10/2010 5:36 AM, Tobias Heer wrote:
      

        

          
To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).
> 


        

        
Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.



        

          
> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).


        

        
 
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?



      

      

      

      
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

    

    

    

    
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

  


--------------000902050302020906010009--

From fluffy@cisco.com  Wed Oct 27 08:26:44 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00613A6930 for ; Wed, 27 Oct 2010 08:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.516
X-Spam-Level: 
X-Spam-Status: No, score=-110.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+Z+8sSNN-h0 for ; Wed, 27 Oct 2010 08:26:43 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AB89A3A6925 for ; Wed, 27 Oct 2010 08:26:43 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJLix0yrR7Ht/2dsb2JhbAChWXGiQJwehUgEhFeFfIMI
X-IronPort-AV: E=Sophos;i="4.58,246,1286150400"; d="scan'208";a="207597720"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2010 15:28:33 +0000
Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9RFSXW4015595 for ; Wed, 27 Oct 2010 15:28:33 GMT
From: Cullen Jennings 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 27 Oct 2010 09:28:39 -0600
Message-Id: <9230C558-6ECE-4126-B940-FBBA16F4E3A4@cisco.com>
To: core@ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [core] Why the internet barely works
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Oct 2010 15:26:44 -0000

One of my favorite papers about internet architecture 

"Why the Internet only just works" by Mark Handley 
http://www.cs.ucl.ac.uk/staff/m.handley/papers/only-just-works.pdf



From rstruik.ext@gmail.com  Wed Oct 27 08:37:10 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC23F3A680C for ; Wed, 27 Oct 2010 08:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.888
X-Spam-Level: 
X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg+utfvFcwKI for ; Wed, 27 Oct 2010 08:37:09 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id D9D283A6803 for ; Wed, 27 Oct 2010 08:37:08 -0700 (PDT)
Received: by eyd10 with SMTP id 10so465963eyd.31 for ; Wed, 27 Oct 2010 08:38:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Xqw8OwDRLvI3OGdOMIS455hXgDlyuXsDOYZoOuQQEjc=; b=l1XK2hOv4e9qXSCzGUPWVqpOfqgiYJ1F7QBqLgSsfIdX9khNbRmzS1GtpimCPLpuBA BQckjEChHQoJ49ASd3k07qGYmXVRi2CtlN4vY3EHewUXheudRDKNAh4oUHnZdu36TTRK QKnahQYhROqZUUqVtW+HRDRHANJ2HdRvuMwEA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=FU7+j1U+IXzc9NDz0ClksV1q9JzYHPRtRySDmQf1X2nzs/u7xKELl0OBS9Gwae7gPJ Q09czBF5OwIkB5o/l4WZWhZWe0RDPT9RZGouiyZgyNs8FAuphAjS4rdLOmdxjHLeXisE LZnF/bMb/14cNPVNEr1PAplQj25n7FKNwKwAU=
Received: by 10.213.7.68 with SMTP id c4mr3845136ebc.72.1288193937400; Wed, 27 Oct 2010 08:38:57 -0700 (PDT)
Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id q58sm9781029eeh.21.2010.10.27.08.38.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 08:38:56 -0700 (PDT)
Message-ID: <4CC84785.3010408@gmail.com>
Date: Wed, 27 Oct 2010 11:38:45 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] Security considerations draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Oct 2010 15:37:11 -0000

Dear colleagues:

I had a quick glance at draft-ietf-core-coap-03 and in particular 
security related items (unfortunately, no time yet to give this a 
thorough read).

Some initial comments on Section 10 of this document below:

1) Bootstrapping seems to be considered as a preliminary phase of a 
device or system's lifecycle. In my mind, this should be considered as a 
lifecycle stage that may be revisited over the lifetime of a device or 
system. An example hereof would be the deployment scenario where one 
configures a device in a mini-network using a configuration tool and 
subesequently enrols with another network; another one would be where a 
device is configured in stages "along the stack" (e.g., first MAC parms, 
then 6lowpan parms, then application parms). This suggests that 
enrolment and bootstrapping steps are not necessarily confined to a 
pre-operational "embryonic" stage, but may re-occur over time. In fact, 
this may be considered as part of configuration management (where 
shooting in initial parms would be considered as "configuration 
establishment").

2) Security of the coap packets seems to require mostly consideration of 
the "key usage" phase of key management only, i.e., it describes how to 
provide security services for packets communicated over the air. This 
being said, how one establishes shared keying material and maintains 
keys (or how one triggers, e.g., a key update) should of course be 
considered. If one chooses the key usage mindset here, public key 
certificates do not fit in, since these are aimed at setting up a secure 
and authentic channel, not at securing ordinary packets (it is part of 
management functionality, not operational use).

3) The cryptographic constructs to be used with coap should not preclude 
implementations where one already has cryptographic hardware on board, 
such as is the case with IEEE 802.15.4-2006 (where one often has an 
AES-128 engine in forward mode and/or a CCM cryptographic mode of 
operation). Using CBC mode as mode of operation (as one of the ISec 
modes discussed in Section 10.1) requires implementation of the inverse 
AES mode and would be unlikely to be supported by 802.15.4 platforms 
currently available in the market place.

4) The cryptographic constructs should try and be economical with 
communication bandwidth. This suggests that IPSec is a somewhat 
unfortunate choice since it may cause considerable data expansion for 
security admin data, this even cryptographic data expansion (due to 
message authentication codes) aside.

I have more comments, but will put thoughts on this in an email somewhat 
later. Please see also my list of items that require some discussion below.

Rene

==

[excerpt email RS to Zach Shelby as of September 29, 2010, 10:55am EDT]

I read the coap-pre2 draft and the DTLS document (RFC 4347) this weekend, but did not get back to you yet on this.

Some initial feedback:

1) security services: confidentiality, data authenticity, relative ordering in time, timeliness (specific services to be identified in packet header)
2) granularity: depends on scope of key sharing group (key id to be identified in packet)

To be discussed:
1) How to implement security policy enforcement
2) Maintaining state:
a) counter value for originating device;
b) mapping URI and device id;
3) binding packet and corresponding ack packet (so, not all crypto independent on per-packet basis as with DTLS)
4) stateless vs. state
a) properties achieved, resp. lost
b) DoS with handshake

I have time to discuss in detail this Friday (Fri October 1, 2010). Please indicate whether 10:30am EDT works for you.

Best regards, Rene

-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


From oscar.garcia@philips.com  Wed Oct 27 09:23:23 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89ED13A6910 for ; Wed, 27 Oct 2010 09:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnW2ysGXEimy for ; Wed, 27 Oct 2010 09:23:09 -0700 (PDT)
Received: from DB3EHSOBE006.bigfish.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by core3.amsl.com (Postfix) with ESMTP id 869283A69A7 for ; Wed, 27 Oct 2010 09:23:08 -0700 (PDT)
Received: from mail69-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.8; Wed, 27 Oct 2010 16:24:57 +0000
Received: from mail69-db3 (localhost.localdomain [127.0.0.1])	by mail69-db3-R.bigfish.com (Postfix) with ESMTP id 71B2E1498290; Wed, 27 Oct 2010 16:24:57 +0000 (UTC)
X-SpamScore: -73
X-BigFish: VPS-73(zzbb2dKbb2cK15d6O9251J1454K1432N9370J98dN217bP9371Pzz1202hzz8275bh8275dh1033IL186Mz2dh2a8h61h)
X-Spam-TCS-SCL: 0:0
Received: from mail69-db3 (localhost.localdomain [127.0.0.1]) by mail69-db3 (MessageSwitch) id 1288196686655869_10027; Wed, 27 Oct 2010 16:24:46 +0000 (UTC)
Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.241])	by mail69-db3.bigfish.com (Postfix) with ESMTP id 53775D8012B; Wed, 27 Oct 2010 16:24:27 +0000 (UTC)
Received: from NLHILEXE04.connect1.local (168.87.56.20) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.0.482.44; Wed, 27 Oct 2010 16:24:26 +0000
Received: from nlamsexh02.connect1.local (172.16.153.23) by connect1.philips.com (172.16.156.160) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 27 Oct 2010 18:24:28 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh02.connect1.local ([172.16.153.23]) with mapi; Wed, 27 Oct 2010 18:24:22 +0200
From: "Garcia Morchon, Oscar" 
To: Rene Struik 
Date: Wed, 27 Oct 2010 18:24:48 +0200
Thread-Topic: [core] concerns re draft-oflynn-core-bootstrapping-02
Thread-Index: Act16EqEM1dLcM71T7eyo5sKJT94igAAUJuQ
Message-ID: <5F6BB0D9318FCA4083FC774C9A9ECEF68856097F7E@NLCLUEXM03.connect1.local>
References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org>< 4CA3BB54.8050706@gmail.com><4CA5E8E0.4030503@gmail.com><4CA6095F.6040403@gmail.com><4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com>
In-Reply-To: <4CC83F61.5060109@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5F6BB0D9318FCA4083FC774C9A9ECEF68856097F7ENLCLUEXM03con_"
MIME-Version: 1.0
X-Reverse-DNS: smtpx.philips.com
Cc: core 
Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 27 Oct 2010 16:23:23 -0000

--_000_5F6BB0D9318FCA4083FC774C9A9ECEF68856097F7ENLCLUEXM03con_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Rene, all,

Rene, I agree with you that a better comparison might be required.
In my view, we might need two "tables":

-          One including a benchmark (may be including scenarios and featur=
es)

-          Another with the proposed protocols/procedures/solutions and the=
ir corresponding features.
In this way, one might compare both tables, identify advantages/disadvantag=
es, and see which protocols/procedures/solutions are good (enough) for whic=
h scenarios.

Regards,

                Oscar.


Features to take into account

Scenario 1

Scenario 2

Scenario 3

Required features for the security handshake

Key establishment

Yes

Yes

?

Implicit key authentication

Yes

Yes

?

Key confirmation

Yes

No

?

Mutual entity authentication

Yes

Yes

?

Forward secrecy

Yes

No needed

?

Key compromise Impersonation resilience

No

No needed

?

... (to be completed)







Platform features

CPU

32-bit CPU

8-bit CPU

?

Bandwidth

Enough

low

?

Energy

Powered

Energy harvesting

?

Flash

128 KB

32 KB

?

... (to be completed)







Lifecycle and operational needs

...







...







(to be completed)

...







...











Bootstrapping

System Operation

HIP

PANA/EAP/...

DTLS

IPSec

HIP

Features

Key establishment

Yes









Implicit key authentication

...









Key confirmation











Mutual entity authentication











Forward secrecy











Key compromise Impersonation resilience











... (to be completed)











Cost

CPU











# of exchanged messages











Size of exchanged information











... (to be completed)











...















From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ren=
e Struik
Sent: Wednesday 27 October 2010 17:04
Cc: core
Subject: [core] concerns re draft-oflynn-core-bootstrapping-02

Dear colleagues:

I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapp=
ing-02. Some comments below (I am having some offline discussions on this, =
but thought to send this to the list as well):

I miss a detailed analysis of deployment scenarios to be considered as guid=
ance into design, so as to have as very minimal benchmark whether all those=
 crypto protocols actually enable the deployment scenarios one has in mind.=
 To me, it seems to have merit to discuss the whole spectrum and end up wit=
h cryptographic building blocks, security protocols, and security policies =
and accompanying enforcement mechanism for trust policies that would fit th=
e operational scenarios.

I would favor not sprinkling protocol acronyms into any draft too early (si=
nce, in my mind, this pushes into a particular direction, and not always wi=
th merit). As an example, right now I do not see how, e.g., HIP or cryptogr=
aphically generated addresses (802.1-like) would fit in. Similarly, e.g., P=
ANA does not seem to work in heterogeneous trust environments, assumes onli=
ne connectivity of a "mothership" node, and does not seem to include consid=
eration of how to move from one  mothership node to the next (or, e.g., if =
one has an authenticator, how to make this work with single-hop/MAC securit=
y).

I also miss security objectives and design considerations, such as "separat=
ion of concern" and no entanglement of concepts from different disciplines =
in the document.

BTW - I mentioned some of this in email correspondence after the last CoRE =
conf call (Wed September 29, 2010). So far, I have not seen too much traffi=
c on this. Moreover, I have not seen any adequate answers as to what makes,=
 e.g., HIP features an attractive fit for CoRE-like environments.

Best regards, Rene

[excerpt email RS as of October 1, 2010, 12:16pm EDT]

In my mind, properties of suitable authenticated key agreement schemes shou=
ld include (a) key establishment; (b) implicit key authentication; (c) key =
confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {p=
erhaps} some more esoteric properties (key compromise impersonation resilie=
nce, etc.).


Moreover, the "name space" (device identifiers) and the "cryptographic spac=
e" (public keys, etc.) should be independent, so that this would allow trus=
t lifecycle management to be reduced to proper management of device identif=
iers (i.e., *no* entanglement of concepts from different disciplines).


On 12/10/2010 12:23 PM, Rene Struik wrote:

Hi Tobias:



Thanks for your note.



Does your "ascii art" description, Step 1)-3) allow the scenario, where (a)=
 one assigns a node id and imprints this (e.g., blowing fuse during chip te=
sting);

(b) has a node generating its own long-term public/private key pair and out=
putting its node id and public key (e.g., during chip testing -- this would

correspond to registering a public key with an RA); (c) have CA create a ce=
rtificate in different process and return this value at later production/

personalization stage?



Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the i=
mpression that HIP does execute an authenticated DH key agreement scheme. I=
f so,

this makes me wonder how HIP differentiates from protocols, such as ECMQV a=
nd, e.g., HMQV, which are all not that much more expensive than ECDH. If th=
e

difference is in the "puzzle" element, couldn't one just add something simi=
lar to a well-known authenticated scheme that is already standardized with,=
 e.g.,

NIST?



As to forward secrecy: reason to include this is that many sensor-type node=
s can be expected to be physically unprotected (e.g., screwed on a street l=
amp

post, on a garage roof, etc.) and, therefore, may be more vulnerable to dev=
ice compromise over time (esp. since one cannot expect all nodes to be tamp=
er

resistant or tamper evident). By virtue of forward secrecy, compromise over=
 time does not compromise the whole device's history, but only the current =
set of

symmetric keys (note: I make some shortcuts in my reasoning on key manageme=
nt here). Admittedly, my list of security properties is based on "desired"

functionality and does not exclude functionality that may require, e.g., pu=
blic-key crypto constructs. However, from a user's perspective, the only th=
ing that

matters is features and not what is "under the hood", as long as that is no=
t cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of

draft-struik-6lowapp-security-considerations-00). (BTW - All other desired =
security properties I listed have an underlying rationale.)



It would help to have a succinct mathematical description of the protocol y=
ou suggest (stripped from formatting issues) and describe claimed cryptogra=
phic

properties. I would be happy to give this a look and review.



Please feel free to provide to me in person if this would be cumbersome mat=
erial for non-crypto people on the mailing list.



Best regards, Rene





[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias He=
er as of October 7, 2010, 5:36am EDT]



To aid clarity and succinct discussions, it would help to have a clear desc=
ription of desired security services to be offered by an authenticated

key agreement scheme and see whether a candidate scheme (such as, who knows=
, HIP) satisfies these. If you could provide a succinct description of

the HIP protocol itself, so that this is easy to understand, and could prov=
ide what properties it has, that would be of great help!

>

> In my mind, properties of suitable authenticated key agreement schemes sh=
ould include (a) key establishment; (b) implicit key authentication;

(c) key confirmation; (d) mutual entity authentication; (e) forward secrecy=
; (f) {perhaps} some more esoteric properties (key compromise

impersonation resilience, etc.).

>

Is this list valid for all targeted use cases? If yes, it is a very handy l=
ist to check against. However, (e) forward secrecy seems to

rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys)=
 and might not be relevant to all use cases (especially small

setups). However, I am not absolutely firm with the envisaged scenarios in =
CORE.

> Moreover, the "name space" (device identifiers) and the "cryptographic sp=
ace" (public keys, etc.) should be independent, so that this would

allow trust lifecycle management to be reduced to proper management of devi=
ce identifiers (i.e., *no* entanglement of concepts from different

disciplines).



Does the "*no* entanglement of concepts from different disciplines" also me=
an that a concept like the id/loc split should be used to avoid

entanglement of routing and naming?






On 07/10/2010 5:36 AM, Tobias Heer wrote:

To aid clarity and succinct discussions, it would help to have a clear desc=
ription of desired security services to be offered by an authenticated key =
agreement scheme and see whether a candidate scheme (such as, who knows, HI=
P) satisfies these. If you could provide a succinct description of the HIP =
protocol itself, so that this is easy to understand, and could provide what=
 properties it has, that would be of great help!

>

> In my mind, properties of suitable authenticated key agreement schemes sh=
ould include (a) key establishment; (b) implicit key authentication; (c) ke=
y confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) =
{perhaps} some more esoteric properties (key compromise impersonation resil=
ience, etc.).

>

Is this list valid for all targeted use cases? If yes, it is a very handy l=
ist to check against. However, (e) forward secrecy seems to rule a number o=
f "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not =
be relevant to all use cases (especially small setups). However, I am not a=
bsolutely firm with the envisaged scenarios in CORE.



> Moreover, the "name space" (device identifiers) and the "cryptographic sp=
ace" (public keys, etc.) should be independent, so that this would allow tr=
ust lifecycle management to be reduced to proper management of device ident=
ifiers (i.e., *no* entanglement of concepts from different disciplines).



Does the "*no* entanglement of concepts from different disciplines" also me=
an that a concept like the id/loc split should be used to avoid entanglemen=
t of routing and naming?






--

email: rstruik.ext@gmail.com

Skype: rstruik

cell: +1 (647) 867-5658

USA Google voice: +1 (415) 690-7363




--

email: rstruik.ext@gmail.com

Skype: rstruik

cell: +1 (647) 867-5658

USA Google voice: +1 (415) 690-7363

________________________________
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_5F6BB0D9318FCA4083FC774C9A9ECEF68856097F7ENLCLUEXM03con_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Rene, all,


 


Rene, I agree with you that a better comparison might be req=
uired.


In my view, we might need two “tables”:


- =
;        
One including a benchmark (may be including scenarios and fe=
atures)


- =
;        
Another with the proposed protocols/procedures/solutions and=
 their corresponding features.


In this way, one might compare both tables, identify advanta=
ges/disadvantages, and see which protocols/procedures/solutions are good (e=
nough) for which scenarios.


 


Regards,


 


          =
      Oscar.


 


 








Features to take into account




Scenario 1




Scenario 2




Scenario 3








Required features for the security handshake





Key establishment




Yes




Yes




?








Implicit key authentication




Yes




Yes




?








Key confirmation




Yes




No




?








Mutual entity authentication




Yes




Yes




?








Forward secrecy




Yes




No needed




?








Key compromise Impersonation resilience<=
/p>




No




No needed




?








… (to be completed)




 




 




 








Platform features




CPU




32-bit CPU




8-bit CPU




?








Bandwidth




Enough




low




?








Energy




Powered




Energy harvesting





?








Flash




128 KB




32 KB




?








… (to be completed)




 




 




 








Lifecycle and operational needs




…




 




 




 








…




 




 




 








(to be completed)




…




 




 




 








…




 




 




 








 


 








 




Bootstrapping




System Operation








HIP




PANA/EAP/…




DTLS




IPSec




HIP








Features




Key establishment




Yes




 




 




 




 








Implicit key authentication




…




 




 




 




 








Key confirmation




 




 




 




 




 








Mutual entity authentication




 




 




 




 




 








Forward secrecy




 




 




 




 




 








Key compromise Impersonation resilience<=
/p>




 




 




 




 




 








… (to be completed)




 




 




 




 




 








Cost




CPU




 




 




 




 




 








# of exchanged messages




 




 




 




 




 








Size of exchanged information




 




 




 




 




 








… (to be completed)




 




 




 




 




 








…




 




 




 




 




 




 








 


 






From: core-bounces@i=
etf.org [mailto:core-bounces@ietf.org]
On Behalf Of Rene Struik

Sent: Wednesday 27 October 2010 17:04

Cc: core

Subject: [core] concerns re draft-oflynn-core-bootstrapping-02<=
/o:p>






 


Dear colleagues:



I had a brief look at the bootstrapping draft (draft-oflynn-core-bootstrapp=
ing-02. Some comments below (I am having some offline discussions on this, =
but thought to send this to the list as well):



I miss a detailed analysis of deployment scenarios to be considered as guid=
ance into
design, so as to have as very minimal benchmark whether all those cr=
ypto protocols actually enable the deployment scenarios one has in mind. To=
 me, it seems to have merit to discuss the whole spectrum and end up with c=
ryptographic building blocks, security
 protocols, and security policies and accompanying enforcement mechanism fo=
r trust policies that would fit the operational scenarios.



I would favor not sprinkling protocol acronyms into any draft too early (si=
nce, in my mind, this pushes into a particular direction, and not
always with merit). As an example, right now I do not see how, e.g.,=
 HIP or cryptographically generated addresses (802.1-like) would fit in.
Similarly, e.g., PANA does not seem to work in heterogeneous trust
environments, assumes online connectivity of a "mothership"=
; node, and does not seem to include consideration of how to move from one&=
nbsp; mothership node to the next (or, e.g., if one has an authenticator, h=
ow to make this work with single-hop/MAC security).




I also miss security objectives and design considerations, such as &=
quot;separation of concern" and no entanglement of concepts from diffe=
rent disciplines in the document.



BTW - I mentioned some of this in email correspondence after the last CoRE =
conf call (Wed September 29, 2010). So far, I have not seen too much traffi=
c on this. Moreover, I have not seen any adequate answers as to what makes,=
 e.g., HIP features an attractive
 fit for CoRE-like environments.



Best regards, Rene



[excerpt email RS as of October 1, 2010, 12:16pm EDT]



In my mind, properties of suitable authenticated key agreement schemes shou=
ld include (a) key establishment; (b) implicit key authentication; (c) key =
confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {p=
erhaps} some more esoteric properties
 (key compromise impersonation resilience, etc.). 


 




Moreover, the "name space" (device identifiers) and the "cry=
ptographic space" (public keys, etc.) should be independent, so that t=
his would allow trust lifecycle management to be reduced to proper manageme=
nt of device identifiers (i.e.,
*no* entanglement of concepts from different disciplines).






On 12/10/2010 12:23 PM, Rene Struik wrote: 


Hi Tobias:


 


Thanks for your note. 


 


Does your "ascii art" description, Step 1)-3) allow the scen=
ario, where (a) one assigns a node id and imprints this (e.g., blowing fuse=
 during chip testing); 


(b) has a node generating its own long-term public/private key pair an=
d outputting its node id and public key (e.g., during chip testing -- this =
would 


correspond to registering a public key with an RA); (c) have CA create=
 a certificate in different process and return this value at later producti=
on/


personalization stage?


 


Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get =
the impression that HIP does execute an authenticated DH key agreement sche=
me. If so,


this makes me wonder how HIP differentiates from protocols, such as EC=
MQV and, e.g., HMQV, which are all not that much more expensive than ECDH. =
If the 


difference is in the "puzzle" element, couldn't one just add=
 something similar to a well-known authenticated scheme that is already sta=
ndardized with, e.g., 


NIST?


 


As to forward secrecy: reason to include this is that many sensor-type=
 nodes can be expected to be physically unprotected (e.g., screwed on a str=
eet lamp 


post, on a garage roof, etc.) and, therefore, may be more vulnerable t=
o device compromise over time (esp. since one cannot expect all nodes to be=
 tamper 


resistant or tamper evident). By virtue of forward secrecy, compromise=
 over time does not compromise the whole device's history, but only the cur=
rent set of


symmetric keys (note: I make some shortcuts in my reasoning on key man=
agement here). Admittedly, my list of security properties is based on "=
;desired" 


functionality and does not exclude functionality that may require, e.g=
., public-key crypto constructs. However, from a user's perspective, the on=
ly thing that


matters is features and not what is "under the hood", as lon=
g as that is not cost-prohibitive (which I contend it is not -- cf., e.g., =
Section 3.2 of


draft-struik-6lowapp-security-considerations-00). (BTW - All other des=
ired security properties I listed have an underlying rationale.)=



 


It would help to have a succinct mathematical description of the proto=
col you suggest (stripped from formatting issues) and describe claimed cryp=
tographic


properties. I would be happy to give this a look and review. 


 


Please feel free to provide to me in person if this would be cumbersom=
e material for non-crypto people on the mailing list.


 


Best regards, Rene


 


 


[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobi=
as Heer as of October 7, 2010, 5:36am EDT]


 


To aid clarity and succinct discussions, it would help to have a clear=
 description of desired security services to be offered by an authenticated=
 


key agreement scheme and see whether a candidate scheme (such as, who =
knows, HIP) satisfies these. If you could provide a succinct description of=
 


the HIP protocol itself, so that this is easy to understand, and could=
 provide what properties it has, that would be of great help!

> 


> In my mind, properties of=
 suitable authenticated key agreement schemes should include (a) key establ=
ishment; (b) implicit key authentication; 


(c) key confirmation; (d) mutual entity authentication; (e) forward se=
crecy; (f) {perhaps} some more esoteric properties (key compromise 


impersonation resilience, etc.).


> 


Is this list valid for all targeted use cases? If yes, it is a very ha=
ndy list to check against. However, (e) forward secrecy seems to 


rule a number of "cheaper" cryptographic approaches (e.g., p=
re-shared keys) and might not be relevant to all use cases (especially smal=
l 


setups). However, I am not absolutely firm with the envisaged scenario=
s in CORE.




> Moreover, the "name =
space" (device identifiers) and the "cryptographic space" (p=
ublic keys, etc.) should be independent, so that this would 





allow trust lifecycle management to be reduced to proper management of=
 device identifiers (i.e., *no=
* entanglement of concepts from diff=
erent 






disciplines).




 


Does the "*no* entanglement of concepts from different d=
isciplines" also mean that a concept like the id/loc split should be u=
sed to avoid 


entanglement of routing and naming?


 










On 07/10/2010 5:36 AM, Tobias Heer wrote: 




To aid clarity and succinct discussions, it would help to have a clear=
 description of desired security services to be offered by an authenticated=
 key agreement scheme and see whether a candidate scheme (such as, who know=
s, HIP) satisfies these. If you could provide a succinct description of the=
 HIP protocol itself, so that this is easy to understand, and could provide=
 what properties it has, that would be of great help!


> 


> In my mind, properties of=
 suitable authenticated key agreement schemes should include (a) key establ=
ishment; (b) implicit key authentication; (c) key confirmation; (d) mutual =
entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteri=
c properties (key compromise impersonation resilience, etc.).

> 




Is this list valid for all targeted use cases? If yes, it is a very ha=
ndy list to check against. However, (e) forward secrecy seems to rule a num=
ber of "cheaper" cryptographic approaches (e.g., pre-shared keys)=
 and might not be relevant to all use cases (especially small setups). Howe=
ver, I am not absolutely firm with the envisaged scenarios in CORE.


 




> Moreover, the "name =
space" (device identifiers) and the "cryptographic space" (p=
ublic keys, etc.) should be independent, so that this would allow trust lif=
ecycle management to be reduced to proper management of device identifiers =
(i.e., *no* entanglement of concepts from different disciplines).<=
o:p>




 


Does the "*no* entanglement of concepts from different d=
isciplines" also mean that a concept like the id/loc split should be u=
sed to avoid entanglement of routing and naming?


 











-- 


email: rstruik.ext@gmail.com<=
/a>


Skype: rstruik


cell: +1 (647) 867-5658


USA Google voice: +1 (415) 690-7363











-- 


email: rstruik.ext@gmail.com<=
/a>


Skype: rstruik


cell: +1 (647) 867-5658


USA Google voice: +1 (415) 690-7363







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_5F6BB0D9318FCA4083FC774C9A9ECEF68856097F7ENLCLUEXM03con_--

From Mohana.Jeyatharan@sg.panasonic.com  Thu Oct 28 02:24:03 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1DD3A67AB for ; Thu, 28 Oct 2010 02:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPcGNnAUKZPN for ; Thu, 28 Oct 2010 02:24:01 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 8279E3A67AC for ; Thu, 28 Oct 2010 02:24:01 -0700 (PDT)
Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id o9S9PbE2028211; Thu, 28 Oct 2010 18:25:37 +0900 (JST)
Received: from pslexc01.psl.local ([10.81.112.5]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili16) with ESMTP id o9S9PbP11603; Thu, 28 Oct 2010 18:25:37 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Oct 2010 17:29:37 +0800
Message-ID: <5F09D220B62F79418461A978CA0921BD047446FB@pslexc01.psl.local>
In-Reply-To: <48CA0995-DC01-46D9-93AB-C81C130B8E3F@sensinode.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Fwd: New Version Notification for draft-ietf-core-coap-03
Thread-index: Act0mXO/HvYBLxnhSUK0Gz9SE8oTxwB44evQ
References: <20101025225448.DF9F03A6C00@core3.amsl.com> <48CA0995-DC01-46D9-93AB-C81C130B8E3F@sensinode.com>
From: "Mohana Jeyatharan" 
To: "Zach Shelby" , "core" 
Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 09:24:03 -0000

Hi Zach,

I have a few comments and questions on the new version of CoAP draft.

[1]In page 7 the token option is used (this is new).  In fact for the
asynchronous transaction section2.1.2
why the token option is used? The transaction ID is changed when the
server sends delayed response. But the URI authority option would
suffice. Why an additional token option?
The client will be able to identify the transaction from the URI
authority option. I really don't understand the need of this token
option.
Unless we are assuming multiple connections to get resource state of the
same resource from the same client. I guess we are not going to open
multiple connections in such constrained environment?

[2]In section 2.3, the error code for "method not allowed" should be
165. This is just editorial.

[3]Is the URI scheme option completely removed from this version
(version 3 coap draft). I don't see it in table 2 option header.
I guess the only scheme is coap://. I assume this is carried in the
scheme option and I was unable to find a description of this scheme
option.
In the earlier version (version 2) there was an http scheme value
present. Why was this removed? If the client wants to talk to an end
device that is running HTTP, then it is easier for the=20
Proxy to do the CoAP to HTTP mapping. This was my understanding of the
"HTTP://" value in coap scheme option.=20

[4]Deltas are used to identify the option type.  Just a clarification
question.  Why such deltas are used? Why not just have the option type
instead. It makes the processing easier for the devices.

[5] Section 3.2.5: what is the use of location option. It looks the same
as the URI-Path option?

[6] In section 4.4 it is mentioned that default UDP port is used for
resource discovery.  So does this mean that after resource discovery
another UDP port for CoAP will be received from the end device.  Does
resource discovery return UDP port number? Why not use the default UDP
port always for CoAP?

[7] In section 5.3, when the proxy is unable to get the resource value
from origin server it is mentioned that it will send 502 Bad gateway
error. I guess this is fine if the client is a HTTP entity. But if the
client is a CoAP node then the proxy should send an ACK as in the
asynchronous model and then when resource is ready will probably send
the actual resource value.  I am unable to understand why a gateway
error is sent. Am I missing something.

[8] The other question is, what type of proxy are we considering. I mean
when a device sends a message to get or manipulate resource tied to
another device (origin server), it will set the IP address to Proxy IP
address (non-transparent proxy).  I assume that only such proxies are
considered in the draft.  Then in that case in section 10.3.2 why is
Ipsec a problem.  Because the device will use the proxy as the end node.
I am not very clear on the assumption of the proxies here. Are we
considering transparent proxies also?

BR,
Mohana

> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf
Of
> Zach Shelby
> Sent: Tuesday, October 26, 2010 7:02 AM
> To: core
> Subject: [core] Fwd: New Version Notification for
draft-ietf-core-coap-03
>=20
> http://www.ietf.org/id/draft-ietf-core-coap-03.txt
>=20
> Here is the new version of CoAP, now even with a complete (draft) of
the
> security section thanks to Cullen and Carsten. This now closes all
open tickets
> and issues I could dredge out of the mailing list. As this version did
not
> change the base header, and option type numbers are the same, we have
> kept the same version number in the header. This should be a fairly
easy
> upgrade for existing implementations (Token Option for asynchronous
> responses, new CoAP specific error codes, Uri-Query option). And yes,
we
> will test coap-03 at the plugfest in Beijing.
>=20
> Here is a summary of changes:
>=20
>    Changes from ietf-02 to ietf-03:
>=20
>       o Token Option and related use in asynchronous requests added
>       (#25).
>=20
>       o CoAP specific error codes added (#26).
>=20
>       o Erroring out on unknown critical options changed to a MUST
>       (#27).
>=20
>       o Uri-Query option added.
>=20
>       o Terminology and definitions of URIs improved.
>=20
>       o Security section completed (#22).
>=20
>=20
> Begin forwarded message:
>=20
> > From: IETF I-D Submission Tool 
> > Date: October 26, 2010 1:54:48 AM GMT+03:00
> > To: zach@sensinode.com
> > Cc: brian@skyfoundry.com,d.sturek@att.net
> > Subject: New Version Notification for draft-ietf-core-coap-03
> >
> >
> > A new version of I-D, draft-ietf-core-coap-03.txt has been
successfully
> submitted by Zach Shelby and posted to the IETF repository.
> >
> > Filename:	 draft-ietf-core-coap
> > Revision:	 03
> > Title:		 Constrained Application Protocol (CoAP)
> > Creation_date:	 2010-10-26
> > WG ID:		 core
> > Number_of_pages: 39
> >
> > Abstract:
> > This document specifies the Constrained Application Protocol (CoAP),
a
> > specialized web transfer protocol for use with constrained networks
> > and nodes for machine-to-machine applications such as smart energy
and
> > building automation.  These constrained nodes often have 8-bit
> > microcontrollers with small amounts of ROM and RAM, while networks
> > such as 6LoWPAN often have high packet error rates and a typical
> > throughput of 10s of kbit/s.  CoAP provides a method/response
> > interaction model between application end-points, supports built-in
> > resource discovery, and includes key web concepts such as URIs and
> > content-types.  CoAP easily translates to HTTP for integration with
> > the web while meeting specialized requirements such as multicast
> > support, very low overhead and simplicity for constrained
> > environments.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
>=20
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297


From Mohana.Jeyatharan@sg.panasonic.com  Thu Oct 28 03:04:44 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97523A681F for ; Thu, 28 Oct 2010 03:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6o95KAgsrqv for ; Thu, 28 Oct 2010 03:04:43 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 103F43A67E1 for ; Thu, 28 Oct 2010 03:04:37 -0700 (PDT)
Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id o9SA6ShB018984 for ; Thu, 28 Oct 2010 19:06:28 +0900 (JST)
Received: from pslexc01.psl.local ([10.81.112.5]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili14) with ESMTP id o9SA6Sg17863 for ; Thu, 28 Oct 2010 19:06:28 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Oct 2010 18:10:28 +0800
Message-ID: <5F09D220B62F79418461A978CA0921BD04744711@pslexc01.psl.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-core-observe-00
Thread-index: Act2hvwQ+BlmMRc+S9OwkOwpkjq8Eg==
From: "Mohana Jeyatharan" 
To: 
Subject: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Oct 2010 10:04:44 -0000

Hi Klaus,

I have few questions on your draft.

In section 2.2(Notification), I don't see why the remaining lifetime
value is sent in the notification messages. If the server decides to
change lifetime then such an option can be sent. Otherwsie I don't see
the need for remaining lifetime value in notify messages. Thus I don't
understand the need for a MUST in your draft for the remaining lifetime
value.

Furthermore, is the remaining lifetime value carried in the subscription
lifetime option?

Also one more question on Open issues. It is mentioned that mapping will
be highlighted as to how to map to HTTP bi-directional mechanisms
Why mapping specific to long polling, streaming and web socket being
considered.  Isn't there a case the observe mechanism interworks with
normal HTTP.
Or do you forsee, mapping to bi directional HTTP poses more problems?

What is the benefit of this mechanism (subject/observe) and what is the
use case.=20
The benefit is the device need not query often. But if there is an ACK
for the notify then there wont be much savings in signaling.  The only
benefit is that the resource chnages can be observed in real time. Then
what is the use case. In which M2M application you will want this as
opposed to the client performing the query. Just a clarification.

BR,
Mohana


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Constrained RESTful Environments
Working Group of the IETF.


	Title           : Observing Resources in CoAP
	Author(s)       : K. Hartke, Z. Shelby
	Filename        : draft-ietf-core-observe-00.txt
	Pages           : 12
	Date            : 2010-10-18

The state of a resource can change over time.  We want to give
clients of the CoRE WG CoAP protocol the ability to observe this
change.  This short I-D provides a design for such an addition to
CoAP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-observe-00.txt


From pab@peoplepowerco.com  Thu Oct 28 05:41:18 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FAD3A6882 for ; Thu, 28 Oct 2010 05:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.704
X-Spam-Level: 
X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=0.272,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLMgB0GZUOll for ; Thu, 28 Oct 2010 05:41:17 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9E9DD3A684A for ; Thu, 28 Oct 2010 05:41:17 -0700 (PDT)
Received: by fxm9 with SMTP id 9so1948759fxm.31 for ; Thu, 28 Oct 2010 05:43:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.74.202 with SMTP id v10mr3852890faj.114.1288269789105; Thu, 28 Oct 2010 05:43:09 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 28 Oct 2010 05:43:09 -0700 (PDT)
Date: Thu, 28 Oct 2010 07:43:09 -0500
Message-ID: 
From: Peter Bigot 
To: fluffy@cisco.com
Content-Type: multipart/alternative; boundary=00248c11e6b1278f3c0493acaf1a
Cc: core 
Subject: [core] http observe unification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 12:41:18 -0000

--00248c11e6b1278f3c0493acaf1a
Content-Type: text/plain; charset=ISO-8859-1

Cullen:

In the telecon yesterday, you objected to my proposal that the solution to
the observation problem be left to designers of specific systems.  It
sounded like you felt a reference document describing alternative approaches
that applications might take would not be adequate.  Could you elaborate a
little more here on what you believe CoAP must provide, and in what
timeframe?

I understood you to say that some IETF working group was nearly complete
with a proposed standard way to implement observation in HTTP.  Is that the
Httpbis group?  To which of their documents were you referring?
draft-loreto-http-bidirectional is somewhat relevant (wrt streaming
responses).

The clearly relevant one is draft-roach-sip-http-subscribe
s
, but that's based on SIP event notification.  Were we to take that
approach, it might be best to define a CoAP-like protocol "csip", rather
than integrate that functionality directly into CoAP.  On first glance, it
appears this would be at least as much work as defining CoAP has been.  It
would, though, give us a solution to observation, notification, and group
communication that is compatible with the HTTP family of protocols, so is
certainly worth considering.

Thanks.

Peter

--00248c11e6b1278f3c0493acaf1a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Cullen:

In the telecon yesterday, you objected to my proposal that t=
he solution to=20
the observation problem be left to designers of specific systems.=A0 It sou=
nded like you felt a reference document describing alternative approaches t=
hat applications might take would not be adequate.=A0 Could you elaborate
 a little more here on what you believe CoAP must provide, and in what time=
frame?



I understood you to say that some IETF working group was nearly complete wi=
th a proposed standard way to implement observation in HTTP.=A0 Is that the=
 Httpbis group?=A0 To which of their documents were you referring?=A0 draft=
-loreto-http-bidirectional is somewhat relevant (wrt streaming responses).<=
br>

The clearly relevant one is draft-roach-sip-http-subscribe
s
, =
but that's based on SIP event notification.=A0 Were we to take that app=
roach, it might be best to define a CoAP-like protocol "csip", ra=
ther than integrate that functionality directly into CoAP.=A0 On first glan=
ce, it appears this would be at least as much work as defining CoAP has bee=
n.=A0 It would, though, give us a solution to observation, notification, an=
d group communication that is compatible with the HTTP family of protocols,=
 so is certainly worth considering.


Thanks.

Peter










Hello,



 



=D8  =
Similarly,
e.g., PANA does not seem to work in heterogeneous trust environments, assumes online =
connectivity
of a "mothership" node, and does not seem to include =
consideration of
how to move from one  mothership node to the next (or, e.g., if one =
has an
authenticator, how to make this work with single-hop/MAC security). 







Can you please elaborate on what “mothership” =
node
is.



 



Alper



 



 



 



 



 



 






Dear colleagues:



I had a brief look at the bootstrapping draft
(draft-oflynn-core-bootstrapping-02. Some comments below (I am having =
some
offline discussions on this, but thought to send this to the list as =
well):



I miss a detailed analysis of deployment scenarios to be considered as =
guidance
into =
design, so as
to have as very minimal benchmark whether all those crypto protocols =
actually
enable the deployment scenarios one has in mind. To me, it seems to have =
merit
to discuss the whole spectrum and end up with cryptographic building =
blocks,
security protocols, and security policies and accompanying enforcement =
mechanism
for trust policies that would fit the operational scenarios.



I would favor not sprinkling protocol acronyms into any draft too early =
(since,
in my mind, this pushes into a particular direction, and not always with =
merit). As an
example, right now I do not see how, e.g., HIP or cryptographically =
generated
addresses (802.1-like) would fit in. Similarly, e.g., PANA does not seem to work in =
heterogeneous
trust =
environments,
assumes online connectivity of a "mothership" node, and does =
not seem
to include consideration of how to move from one  mothership node =
to the
next (or, e.g., if one has an authenticator, how to make this work with
single-hop/MAC security). 



I also miss security objectives and design considerations, such =
as
"separation of concern" and no entanglement of concepts from
different disciplines in the document.



BTW - I mentioned some of this in email correspondence after the last =
CoRE conf
call (Wed September 29, 2010). So far, I have not seen too much traffic =
on
this. Moreover, I have not seen any adequate answers as to what makes, =
e.g.,
HIP features an attractive fit for CoRE-like environments.



Best regards, Rene



[excerpt email RS as of October 1, 2010, 12:16pm EDT]



In my mind, properties of suitable authenticated key agreement schemes =
should
include (a) key establishment; (b) implicit key authentication; (c) key
confirmation; (d) mutual entity authentication; (e) forward secrecy; (f)
{perhaps} some more esoteric properties (key compromise impersonation
resilience, etc.). 



Moreover, the "name space" (device identifiers) and the
"cryptographic space" (public keys, etc.) should be =
independent, so
that this would allow trust lifecycle management to be reduced to proper
management of device identifiers (i.e., *no* entanglement of concepts from different
disciplines). 





On 12/10/2010 12:23 PM, Rene Struik wrote: 



Hi Tobias:
 
Thanks =
for your note. 
 
Does =
your "ascii art" description, Step 1)-3) allow the scenario, =
where (a) one assigns a node id and imprints this (e.g., blowing fuse =
during chip testing); 
(b) has a node generating =
its own long-term public/private key pair and outputting its node id and =
public key (e.g., during chip testing -- this would =

correspond to registering a public key with an =
RA); (c) have CA create a certificate in different process and return =
this value at later production/
personalization =
stage?
 
Right now, from =
Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression =
that HIP does execute an authenticated DH key agreement scheme. If =
so,
this makes me wonder how HIP differentiates =
from protocols, such as ECMQV and, e.g., HMQV, which are all not that =
much more expensive than ECDH. If the 
difference =
is in the "puzzle" element, couldn't one just add something =
similar to a well-known authenticated scheme that is already =
standardized with, e.g., =

NIST?
 
<=
pre>As to forward secrecy: reason to include this is that many =
sensor-type nodes can be expected to be physically unprotected (e.g., =
screwed on a street lamp 
post, on a garage roof, =
etc.) and, therefore, may be more vulnerable to device compromise over =
time (esp. since one cannot expect all nodes to be tamper =

resistant or tamper evident). By virtue of forward =
secrecy, compromise over time does not compromise the whole device's =
history, but only the current set of
symmetric keys =
(note: I make some shortcuts in my reasoning on key management here). =
Admittedly, my list of security properties is based on =
"desired" 
functionality and does not =
exclude functionality that may require, e.g., public-key crypto =
constructs. However, from a user's perspective, the only thing =
that
matters is features and not what is =
"under the hood", as long as that is not cost-prohibitive =
(which I contend it is not -- cf., e.g., Section 3.2 =
of
draft-struik-6lowapp-security-considerations-00).=
 (BTW - All other desired security properties I listed have an =
underlying =
rationale.)
 
It would =
help to have a succinct mathematical description of the protocol you =
suggest (stripped from formatting issues) and describe claimed =
cryptographic
properties. I would be happy to give =
this a look and review. =

 
Please feel free to =
provide to me in person if this would be cumbersome material for =
non-crypto people on the mailing =
list.
 
Best regards, =
Rene
 
 
[excerpt email RS as of October 1, 2010, 12:16pm EDT and =
response Tobias Heer as of October 7, 2010, 5:36am =
EDT]
 
To aid clarity and =
succinct discussions, it would help to have a clear description of =
desired security services to be offered by an authenticated =

key agreement scheme and see whether a candidate =
scheme (such as, who knows, HIP) satisfies these. If you could provide a =
succinct description of 
the HIP protocol itself, =
so that this is easy to understand, and could provide what properties it =
has, that would be of great help!
> 
> In my mind, properties of suitable =
authenticated key agreement schemes should include (a) key =
establishment; (b) implicit key authentication; =

(c) key confirmation; (d) mutual entity =
authentication; (e) forward secrecy; (f) {perhaps} some more esoteric =
properties (key compromise 
impersonation =
resilience, etc.).
> 
Is this =
list valid for all targeted use cases? If yes, it is a very handy list =
to check against. However, (e) forward secrecy seems to =

rule a number of "cheaper" cryptographic =
approaches (e.g., pre-shared keys) and might not be relevant to all use =
cases (especially small 
setups). However, I am not =
absolutely firm with the envisaged scenarios in CORE.



> Moreover, the "name =
space" (device identifiers) and the "cryptographic space" =
(public keys, etc.) should be independent, so that this would =




allow =
trust lifecycle management to be reduced to proper management of device =
identifiers (i.e., *no* entanglement of concepts from different =




disciplines).



=A0
Does the "*no* entanglement of concepts from different =
disciplines" also mean that a concept like the id/loc split should =
be used to avoid 
entanglement of routing and =
naming?
 











On 07/10/2010 5:36 AM, Tobias Heer wrote: 



To aid =
clarity and succinct discussions, it would help to have a clear =
description of desired security services to be offered by an =
authenticated key agreement scheme and see whether a candidate scheme =
(such as, who knows, HIP) satisfies these. If you could provide a =
succinct description of the HIP protocol itself, so that this is easy to =
understand, and could provide what properties it has, that would be of =
great help!
> 
> In my mind, properties of suitable =
authenticated key agreement schemes should include (a) key =
establishment; (b) implicit key authentication; (c) key confirmation; =
(d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} =
some more esoteric properties (key compromise impersonation resilience, =
etc.).
> 



Is this list valid for all targeted use cases? If yes, it is a very =
handy list to check against. However, (e) forward secrecy seems to rule =
a number of "cheaper" cryptographic approaches (e.g., =
pre-shared keys) and might not be relevant to all use cases (especially =
small setups). However, I am not absolutely firm with the envisaged =
scenarios in CORE.
 



> Moreover, the "name =
space" (device identifiers) and the "cryptographic space" =
(public keys, etc.) should be independent, so that this would allow =
trust lifecycle management to be reduced to proper management of device =
identifiers (i.e., *no* entanglement of concepts from different =
disciplines).



=A0
Does the "*no* entanglement of concepts from different =
disciplines" also mean that a concept like the id/loc split should =
be used to avoid entanglement of routing and =
naming?
 













-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363













-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363








------=_NextPart_000_023B_01CB76FA.ABE934C0--


From pab@peoplepowerco.com  Thu Oct 28 13:47:52 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833D43A68E7 for ; Thu, 28 Oct 2010 13:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.71
X-Spam-Level: 
X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.266,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emFEy1EBB1Uu for ; Thu, 28 Oct 2010 13:47:51 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D85C73A68E1 for ; Thu, 28 Oct 2010 13:47:50 -0700 (PDT)
Received: by fxm9 with SMTP id 9so2479222fxm.31 for ; Thu, 28 Oct 2010 13:49:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.79.68 with SMTP id o4mr4458600fak.0.1288298983014; Thu, 28 Oct 2010 13:49:43 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 28 Oct 2010 13:49:42 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 28 Oct 2010 15:49:42 -0500
Message-ID: 
From: Peter Bigot 
To: Klaus Hartke 
Content-Type: multipart/alternative; boundary=20cf3054a56d3f43200493b37bae
Cc: core 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 20:47:52 -0000

--20cf3054a56d3f43200493b37bae
Content-Type: text/plain; charset=ISO-8859-1

Related specifically to Token:

On Thu, Oct 28, 2010 at 2:11 PM, Klaus Hartke  wrote:

> 2.1.2.
> Why does the server deny to answer the request if a client decides not
> to include a token? If the client can relate the asynchronous response
> to its request without a token, it's not the responsibility of the
> server to tell the client it cannot.
>

This might have been influenced by my comments related to use of Token to
enable the block protocol.  The reason to do this here is to allow the
client to influence the server's decision whether to use an asynchronous
response.  Some clients may not be able to accept asynchronous responses.
Some may accept only one outstanding at a time, and prefer to control which
requests might consume that resource.  A cooperative server might try harder
to return the response synchronously when no Token is present, rather than
immediately converting everything to synchronous.

Perhaps more convincingly: it takes less space to use the Token in the
response than to repeat all the URI-related options; and consistent use of
Token to pair an asynchronous response with the request eliminates ambiguity
in the case of multiple outstanding requests to the same URI.  This pattern
also eliminates the previous need to use URI data and envelope information
for correlation, along with all the code required to do so.

I think rationale like this should be part of the specification.

2.1.2.
> Given the current wording, it seems much simpler to me to let an
> implementation simply always include a token in a request, instead of
> hoping for a synchronous response and retrying in case of an
> asynchronous one. After a successful request, the client cannot even
> cache if it needs to include a token or not, because the same request
> to the same resource may or may not yield an asynchronous response at
> a later point of time.
>

I doubt many resources will normally change whether or not operations on
them are likely to be asynchronous, but yes: applications are certainly
allowed to always include a Token in a request.

 3.2.
>
Table 2 lists the Token Option with a length of 1-2 B. That prevents a
> lot of interesting usage cases wrt statelessness. What's the reasoning
> to limit a token to 1-2 B?
>

I had the same question.  While a limit is reasonable to allow a fixed
representation on the server, I  see Etag and Token be essentially the same
type of object, so would expect them to support the same length (1-4B)


> 3.2.8.
> It is sufficient if token values are unique in use per server.
>

Not generally.  This is only true if the implementation retains the server
network information along with the outstanding request, and uses envelope
information from the response in combination with the token to uniquely
identify the corresponding request.  A more decoupled implementation can
accomplish this more simply by disallowing use of the same token for
outstanding requests to different servers.

3.2.8.
> "If a Token Option is included in a request, the response (and
> any     subsequent delayed responses) MUST include the same value in a
> Token Option." - section 2.1.1. says that Token can be omitted from
> synchronous responses.
>

Concur.


> 3.2.8.
> "If a Token Option is included in a request, any resulting delayed
> response SHOULD NOT include the URI option" - nothing in coap-03
> encourages to ever include URI-related options in a response, or does
> it?
>

With the addition of Token, I believe the only time URI-related options
should appear in a response is when they are required to convey a
redirection involving Location (which as defined only specifies the path
component of the target; Uri-Authority is still required, as will Uri-Scheme
if/when that gets put back).

Wording in several places needs to be updated to reflect this; I'll note
where in my detailed comments.

Peter

--20cf3054a56d3f43200493b37bae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Related specifically to Token:

On Thu, Oc=
t 28, 2010 at 2:11 PM, Klaus Hartke <hartke@tzi.org> wrote:


2.1.2.

Why does the server deny to answer the request if a client decides not

to include a token? If the client can relate the asynchronous response

to its request without a token, it's not the responsibility of the

server to tell the client it cannot.

This might ha=
ve been influenced by my comments related to use of Token to enable the blo=
ck protocol.=A0 The reason to do this here is to allow the client to influe=
nce the server's decision whether to use an asynchronous response.=A0 S=
ome clients may not be able to accept asynchronous responses.=A0 Some may a=
ccept only one outstanding at a time, and prefer to control which requests =
might consume that resource.=A0 A cooperative server might try harder to re=
turn the response synchronously when no Token is present, rather than immed=
iately converting everything to synchronous.


Perhaps more convincingly: it takes less space to use the Token in the =
response than to repeat all the URI-related options; and consistent use of =
Token to pair an asynchronous response with the request eliminates ambiguit=
y in the case of multiple outstanding requests to the same URI.=A0 This pat=
tern also eliminates the previous need to use URI data and envelope informa=
tion for correlation, along with all the code required to do so.


I think rationale like this should be part of the specification.

2.1.2.

Given the current wording, it seems much simpler to me to let an

implementation simply always include a token in a request, instead of

hoping for a synchronous response and retrying in case of an

asynchronous one. After a successful request, the client cannot even

cache if it needs to include a token or not, because the same request

to the same resource may or may not yield an asynchronous response at

a later point of time.

I doubt many resources will=
 normally change whether or not operations on them are likely to be asynchr=
onous, but yes: applications are certainly allowed to always include a Toke=
n in a request.


=A03.2.


Table 2 lists the Token Option with a length of 1-2 B. That prevents a

lot of interesting usage cases wrt statelessness. What's the reasoning<=
br>
to limit a token to 1-2 B?

I had the same question=
.=A0 While a limit is reasonable to allow a fixed representation on the ser=
ver, I=A0 see Etag and Token be essentially the same type of object, so wou=
ld expect them to support the same length (1-4B)

=A0



3.2.8.

It is sufficient if token values are unique in use per server.

Not generally.=A0 This is only true if the implementation reta=
ins the server network information along with the outstanding request, and =
uses envelope information from the response in combination with the token t=
o uniquely identify the corresponding request.=A0 A more decoupled implemen=
tation can accomplish this more simply by disallowing use of the same token=
 for outstanding requests to different servers.




3.2.8.

"If a Token Option is included in a request, the response (and

any =A0 =A0 subsequent delayed responses) MUST include the same value in a<=
br>
Token Option." - section 2.1.1. says that Token can be omitted from
synchronous responses.

Concur. 
=A0<=
/div>

3.2.8.

"If a Token Option is included in a request, any resulting delayed

response SHOULD NOT include the URI option" - nothing in coap-03

encourages to ever include URI-related options in a response, or does

it?

With the addition of Token, I believe the only=
 time URI-related options should appear in a response is when they are requ=
ired to convey a redirection involving Location (which as defined only spec=
ifies the path component of the target; Uri-Authority is still required, as=
 will Uri-Scheme if/when that gets put back).


Wording in several places needs to be updated to reflect this; I'll=
 note where in my detailed comments.

Peter


--20cf3054a56d3f43200493b37bae--

From pab@peoplepowerco.com  Thu Oct 28 13:57:29 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2083A6996 for ; Thu, 28 Oct 2010 13:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.713
X-Spam-Level: 
X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.263,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gId5cmmY+Z-p for ; Thu, 28 Oct 2010 13:57:28 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5445C3A6800 for ; Thu, 28 Oct 2010 13:57:28 -0700 (PDT)
Received: by fxm9 with SMTP id 9so2488709fxm.31 for ; Thu, 28 Oct 2010 13:59:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.86.16 with SMTP id q16mr2156207fal.58.1288299560692; Thu, 28 Oct 2010 13:59:20 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 28 Oct 2010 13:59:20 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 28 Oct 2010 15:59:20 -0500
Message-ID: 
From: Peter Bigot 
To: Klaus Hartke 
Content-Type: multipart/alternative; boundary=20cf3054a6e9adeadc0493b39d1f
Cc: core 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 20:57:30 -0000

--20cf3054a6e9adeadc0493b39d1f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 28, 2010 at 2:11 PM, Klaus Hartke  wrote:

> 4.2.
> Should retransmits of responses transmit the current state of
> resource, rather than a snapshot of the state at the time of the first
> attempt?
>

I would say no.

If this is required, it imposes a fairly tight coupling between the
transaction and REST levels: the transaction level must up-call to the REST
level to get an updated representation for each retransmission.

If this is allowed, it leaves open a potential for confusion as one request
has produced multiple, inconsistent responses with network behavior
determining which one makes it through.

Is there a way to make it clear that the CoAP message octet sequence must be
identical in each retransmission?

Peter

--20cf3054a6e9adeadc0493b39d1f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Oct 28, 2010 at 2:11 PM, Klaus Hartke <hartke@tzi.org>=
; wrote:

List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Oct 2010 21:09:27 -0000

On Oct 28, 2010, at 22:59, Peter Bigot wrote:

> Is there a way to make it clear that the CoAP message octet sequence =
must be identical in each retransmission?

I don't think we want to impose that -- the server may simply not have =
enough memory to store that version.  Constrainedness always wins :-)
I also think the confusion incurred is rather limited.
(But we also don't want to impose that the state must be fresh.)

Gruesse, Carsten


From cabo@tzi.org  Thu Oct 28 14:19:58 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4E63A659C for ; Thu, 28 Oct 2010 14:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.185
X-Spam-Level: 
X-Spam-Status: No, score=-106.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZDC-0nL8buC for ; Thu, 28 Oct 2010 14:19:58 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id A6C7A3A67A8 for ; Thu, 28 Oct 2010 14:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9SLLM28021821; Thu, 28 Oct 2010 23:21:22 +0200 (CEST)
Received: from [192.168.217.101] (p5489FD73.dip.t-dialin.net [84.137.253.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 79850257; Thu, 28 Oct 2010 23:21:22 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <023a01cb76e1$869bfcc0$93d3f640$@yegin@yegin.org>
Date: Thu, 28 Oct 2010 23:21:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 		<935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org>	<4CA3BB54.8050706@gmail.com>		<4CA5E8E0.4030503@gmail.com>		<4CA6095F.6040403@gmail.com>		<4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <023a01cb76e1$869bfcc0$93d3f640$@yegin@yegin.org>
To: "Alper Yegin" 
X-Mailer: Apple Mail (2.1081)
Cc: 'core' 
Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 21:19:58 -0000

On Oct 28, 2010, at 22:48, Alper Yegin wrote:

> mothership

I think other terms are "mother-may-I", "trust center", "RADIUS server", =
or "Policy Decision Point".  Just guessing, though.
I think the use case of interest here is a single constrained network =
that simultaneously serves multiple trust domains, so being authorized =
by any one of them should give you access.

With that potential explanation, can you elucidate whether (and maybe =
how) PANA would work in this scenario?

Gruesse, Carsten


From pab@peoplepowerco.com  Thu Oct 28 14:28:12 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6EB3A69AE for ; Thu, 28 Oct 2010 14:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.716
X-Spam-Level: 
X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiwirmjpcMe3 for ; Thu, 28 Oct 2010 14:28:11 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 292063A69AC for ; Thu, 28 Oct 2010 14:28:11 -0700 (PDT)
Received: by fxm9 with SMTP id 9so2515614fxm.31 for ; Thu, 28 Oct 2010 14:30:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.93.136 with SMTP id v8mr4514795fam.56.1288301403580; Thu, 28 Oct 2010 14:30:03 -0700 (PDT)
Received: by 10.223.97.10 with HTTP; Thu, 28 Oct 2010 14:30:03 -0700 (PDT)
In-Reply-To: <42F80FDA-23BB-4982-A438-7CB0FE143FC9@tzi.org>
References:   <42F80FDA-23BB-4982-A438-7CB0FE143FC9@tzi.org>
Date: Thu, 28 Oct 2010 16:30:03 -0500
Message-ID: 
From: Peter Bigot 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=20cf3054a2e38627c30493b40b79
Cc: core , Klaus Hartke 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 21:28:12 -0000

--20cf3054a2e38627c30493b40b79
Content-Type: text/plain; charset=ISO-8859-1

There must be some limit: constrainedness should not excuse clearly
undesirable behavior.

Whether inconsistent retransmitted messages is such a case isn't something
I'd want to argue either way without a lot of thought about the
ramifications (consider multiple recipients with multicast, or possibly
gateways on different paths seeing different retransmissions, or what it
would mean to allow regenerating the response for something other than a
GET).

In any case, since there's no initial unanimity, whether or not this is
allowed should be explicit with either a MAY or a MUST NOT clause.

Peter

On Thu, Oct 28, 2010 at 4:11 PM, Carsten Bormann  wrote:

> On Oct 28, 2010, at 22:59, Peter Bigot wrote:
>
> > Is there a way to make it clear that the CoAP message octet sequence must
> be identical in each retransmission?
>
> I don't think we want to impose that -- the server may simply not have
> enough memory to store that version.  Constrainedness always wins :-)
> I also think the confusion incurred is rather limited.
> (But we also don't want to impose that the state must be fresh.)
>
> Gruesse, Carsten
>
>

--20cf3054a2e38627c30493b40b79
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There must be some limit: constrainedness should not excuse clearly undesir=
able behavior.

Whether inconsistent retransmitted messages is such a=
 case isn't something I'd want to argue either way without a lot of=
 thought about the ramifications (consider multiple recipients with multica=
st, or possibly gateways on different paths seeing different retransmission=
s, or what it would mean to allow regenerating the response for something o=
ther than a GET).


In any case, since there's no initial unanimity, whether or not thi=
s is allowed should be explicit with either a MAY or a MUST NOT clause.
=

Peter

On Thu, Oct 28, 2010 at 4:11 PM=
, Carsten Bormann <cab=
o@tzi.org> wrote:


On Oct 28, 2010, at 22:59, Peter Bigot wrote:



> Is there a way to make it clear that the CoAP message octet sequence m=
ust be identical in each retransmission?




I don't think we want to impose that -- the server may simply not=
 have enough memory to store that version. =A0Constrainedness always wins :=
-)

I also think the confusion incurred is rather limited.

(But we also don't want to impose that the state must be fresh.)



Gruesse, Carsten







--20cf3054a2e38627c30493b40b79--

From rstruik.ext@gmail.com  Thu Oct 28 14:28:26 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71263A6996 for ; Thu, 28 Oct 2010 14:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level: 
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pPjEAS9ntzA for ; Thu, 28 Oct 2010 14:28:16 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1003D3A689B for ; Thu, 28 Oct 2010 14:28:15 -0700 (PDT)
Received: by qwb7 with SMTP id 7so2473648qwb.31 for ; Thu, 28 Oct 2010 14:30:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=XfT2t6HLvIcMGIHqQ7gMIbdodTYOU972TXlRh9eTt/U=; b=vrkEsvq6+q+sMA8+SbL16Q73tVl07Uv83Fjg3UwCYwP2USioDqCwxkb0TY2oGPnOMH PHsuy10/6X8075BA+hBPtv+YyKATtN3TirdqPvlSnnehF8ZO72Sc5a720LDLTZxWtL39 3RPr5bgnYg9F+R+bm3l1kQixPaa7elU1+nudc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=r0tzayi4WYZTeC0JAUx7hcYCJs5pdTJW5eQgWfVzCmsEKINsMArNP/nVlZ8H6KHpta +BSIjhlBvgQse5ijwJzHEc9E0InRsp0iKj8bQO41DneqpmjXpAxEznnsEhGaftW5lnM7 Wcy4DyxuYSfWsydoDMrNah/1M3mlW5q6m9eYA=
Received: by 10.224.195.198 with SMTP id ed6mr4138103qab.322.1288301408736; Thu, 28 Oct 2010 14:30:08 -0700 (PDT)
Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id w5sm612514vcr.6.2010.10.28.14.30.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 14:30:08 -0700 (PDT)
Message-ID: <4CC9EB4B.7040802@gmail.com>
Date: Thu, 28 Oct 2010 17:29:47 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Alper Yegin 
References: 		<935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org>	<4CA3BB54.8050706@gmail.com>		<4CA5E8E0.4030503@gmail.com>		<4CA6095F.6040403@gmail.com>		<4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <023a01cb76e1$869bfcc0$93d3f640$@yegin@yegin.org>
In-Reply-To: <023a01cb76e1$869bfcc0$93d3f640$@yegin@yegin.org>
Content-Type: multipart/alternative; boundary="------------060601030806070808060001"
Cc: 'core' 
Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 21:28:26 -0000

This is a multi-part message in MIME format.
--------------060601030806070808060001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alper:

With "mothership" I meant to indicate a node that serves as security 
manager for a collection of nodes. There are of course different 
granularities in what the security manager role entails. In ZigBee, the 
mothership node would be "the" trust center.

I hope this helps.

Rene

On 28/10/2010 4:48 PM, Alper Yegin wrote:
>
> Hello,
>
> ØSimilarly, e.g., PANA does not seem to work in heterogeneous 
> trustenvironments, assumes online connectivity of a "mothership" node, 
> and does not seem to include consideration of how to move from one  
> mothership node to the next (or, e.g., if one has an authenticator, 
> how to make this work with single-hop/MAC security).
>
> Can you please elaborate on what "mothership" node is.
>
> Alper
>
> Dear colleagues:
>
> I had a brief look at the bootstrapping draft 
> (draft-oflynn-core-bootstrapping-02. Some comments below (I am having 
> some offline discussions on this, but thought to send this to the list 
> as well):
>
> I miss a detailed analysis of deployment scenarios to be considered as 
> guidance intodesign, so as to have as very minimal benchmark whether 
> all those crypto protocols actually enable the deployment scenarios 
> one has in mind. To me, it seems to have merit to discuss the whole 
> spectrum and end up with cryptographic building blocks, security 
> protocols, and security policies and accompanying enforcement 
> mechanism for trust policies that would fit the operational scenarios.
>
> I would favor not sprinkling protocol acronyms into any draft too 
> early (since, in my mind, this pushes into a particular direction, and 
> notalways with merit). As an example, right now I do not see how, 
> e.g., HIP or cryptographically generated addresses (802.1-like) would 
> fit in.Similarly, e.g., PANA does not seem to work in heterogeneous 
> trustenvironments, assumes online connectivity of a "mothership" node, 
> and does not seem to include consideration of how to move from one  
> mothership node to the next (or, e.g., if one has an authenticator, 
> how to make this work with single-hop/MAC security).
>
> I also miss security objectives and design considerations, such as 
> "separation of concern" and no entanglement of concepts from different 
> disciplines in the document.
>
> BTW - I mentioned some of this in email correspondence after the last 
> CoRE conf call (Wed September 29, 2010). So far, I have not seen too 
> much traffic on this. Moreover, I have not seen any adequate answers 
> as to what makes, e.g., HIP features an attractive fit for CoRE-like 
> environments.
>
> Best regards, Rene
>
> [excerpt email RS as of October 1, 2010, 12:16pm EDT]
>
> In my mind, properties of suitable authenticated key agreement schemes 
> should include (a) key establishment; (b) implicit key authentication; 
> (c) key confirmation; (d) mutual entity authentication; (e) forward 
> secrecy; (f) {perhaps} some more esoteric properties (key compromise 
> impersonation resilience, etc.).
>
> Moreover, the "name space" (device identifiers) and the "cryptographic 
> space" (public keys, etc.) should be independent, so that this would 
> allow trust lifecycle management to be reduced to proper management of 
> device identifiers (i.e., ****no** entanglement of concepts from 
> different disciplines).
>
>
> On 12/10/2010 12:23 PM, Rene Struik wrote:
>
> Hi Tobias:
>   
> Thanks for your note.
>   
> Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing);
> (b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would
> correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/
> personalization stage?
>   
> Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,
> this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the
> difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g.,
> NIST?
>   
> As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp
> post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper
> resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of
> symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired"
> functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that
> matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of
> draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)
>   
> It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic
> properties. I would be happy to give this a look and review.
>   
> Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list.
>   
> Best regards, Rene
>   
>   
> [excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT]
>   
> To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated
> key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of
> the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> >  
> >  In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication;
> (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise
> impersonation resilience, etc.).
> >  
> Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to
> rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small
> setups). However, I am not absolutely firm with the envisaged scenarios in CORE.
>
>     >  Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would
>
>     allow trust lifecycle management to be reduced to proper management of device identifiers (i.e.,****no**  entanglement of concepts from different
>
>     disciplines).
>
>   
> Does the "****no**  entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid
> entanglement of routing and naming?
>   
>
>
>
>
>
> On 07/10/2010 5:36 AM, Tobias Heer wrote:
>
>     To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
>
>     >  
>
>     >  In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).
>
>     >  
>
> Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.
>   
>
>     >  Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e.,****no**  entanglement of concepts from different disciplines).
>
>   
> Does the "****no**  entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?
>   
>
>
>
>
> -- 
> email:rstruik.ext@gmail.com  
> Skype: rstruik
> cell: +1 (647) 867-5658
> USA Google voice: +1 (415) 690-7363
>
>
>
>
> -- 
> email:rstruik.ext@gmail.com  
> Skype: rstruik
> cell: +1 (647) 867-5658
> USA Google voice: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


--------------060601030806070808060001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Alper:

    

    With "mothership" I meant to indicate a node that serves as security
    manager for a collection of nodes. There are of course different
    granularities in what the security manager role entails. In ZigBee,
    the mothership node would be "the" trust center. 

    

    I hope this helps.

    

    Rene

     

    On 28/10/2010 4:48 PM, Alper Yegin wrote:
    

      
      
      
      

        
Hello,

        
 

        
Ø  Similarly,
e.g.,
          PANA does not seem to work in heterogeneous trust environments,
          assumes online connectivity
          of a "mothership" node, and does not seem to include
          consideration of
          how to move from one  mothership node to the next (or, e.g.,
          if one has an
          authenticator, how to make this work with single-hop/MAC
          security). 

          

          

        
Can you please elaborate on what “mothership”
            node
            is.

        
 

        
Alper

        
 

        
 

        
 

        
 

        
 

        
 

        

          
Dear colleagues:

            

            I had a brief look at the bootstrapping draft
            (draft-oflynn-core-bootstrapping-02. Some comments below (I
            am having some
            offline discussions on this, but thought to send this to the
            list as well):

            

            I miss a detailed analysis of deployment scenarios to be
            considered as guidance
            into design,
            so as
            to have as very minimal benchmark whether all those crypto
            protocols actually
            enable the deployment scenarios one has in mind. To me, it
            seems to have merit
            to discuss the whole spectrum and end up with cryptographic
            building blocks,
            security protocols, and security policies and accompanying
            enforcement mechanism
            for trust policies that would fit the operational scenarios.

            

            I would favor not sprinkling protocol acronyms into any
            draft too early (since,
            in my mind, this pushes into a particular direction, and not always
            with merit). As an
            example, right now I do not see how, e.g., HIP or
            cryptographically generated
            addresses (802.1-like) would fit in. Similarly, e.g.,
            PANA does not seem to work in heterogeneous
            trust
            environments,
            assumes online connectivity of a "mothership" node, and does
            not seem
            to include consideration of how to move from one  mothership
            node to the
            next (or, e.g., if one has an authenticator, how to make
            this work with
            single-hop/MAC security). 

            

            I also miss security objectives and design
            considerations, such as
            "separation of concern" and no entanglement of concepts from
            different disciplines in the document.

            

            BTW - I mentioned some of this in email correspondence after
            the last CoRE conf
            call (Wed September 29, 2010). So far, I have not seen too
            much traffic on
            this. Moreover, I have not seen any adequate answers as to
            what makes, e.g.,
            HIP features an attractive fit for CoRE-like environments.

            

            Best regards, Rene

            

            [excerpt email RS as of October 1, 2010, 12:16pm EDT]

            

            In my mind, properties of suitable authenticated key
            agreement schemes should
            include (a) key establishment; (b) implicit key
            authentication; (c) key
            confirmation; (d) mutual entity authentication; (e) forward
            secrecy; (f)
            {perhaps} some more esoteric properties (key compromise
            impersonation
            resilience, etc.). 

            

            Moreover, the "name space" (device identifiers) and the
            "cryptographic space" (public keys, etc.) should be
            independent, so
            that this would allow trust lifecycle management to be
            reduced to proper
            management of device identifiers (i.e., *no* entanglement of
            concepts from different
            disciplines). 

            

            

            On 12/10/2010 12:23 PM, Rene Struik wrote: 

          
Hi Tobias:

          
 

          
Thanks for your note. 

          
 

          
Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing); 

          
(b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would 

          
correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/

          
personalization stage?

          
 

          
Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,

          
this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the 

          
difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g., 

          
NIST?

          
 

          
As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp 

          
post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper 

          
resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of

          
symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired" 

          
functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that

          
matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of

          
draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)

          
 

          
It would help to have a succinct mathematical description of the protocol you suggest (stripped from formatting issues) and describe claimed cryptographic

          
properties. I would be happy to give this a look and review. 

          
 

          
Please feel free to provide to me in person if this would be cumbersome material for non-crypto people on the mailing list.

          
 

          
Best regards, Rene

          
 

          
 

          
[excerpt email RS as of October 1, 2010, 12:16pm EDT and response Tobias Heer as of October 7, 2010, 5:36am EDT]

          
 

          
To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated 

          
key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of 

          
the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!

          
> 

          
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; 

          
(c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise 

          
impersonation resilience, etc.).

          
> 

          
Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to 

          
rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small 

          
setups). However, I am not absolutely firm with the envisaged scenarios in CORE.

          

            
> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would 

          

          

            
allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different 

          

          

            
disciplines).

          

          
 

          
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid 

          
entanglement of routing and naming?

          
 

          


            

            

            

            On 07/10/2010 5:36 AM, Tobias Heer wrote: 

          

            
To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!

            
> 

            
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).

            
> 

          

          
Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.

          
 

          

            
> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).

          

          
 

          
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?

          
 

          


            

            

            

          
-- 

          
email: rstruik.ext@gmail.com

          
Skype: rstruik

          
cell: +1 (647) 867-5658

          
USA Google voice: +1 (415) 690-7363

          


            

            

            

          
-- 

          
email: rstruik.ext@gmail.com

          
Skype: rstruik

          
cell: +1 (647) 867-5658

          
USA Google voice: +1 (415) 690-7363

        

      

    

    

    

    
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

  


--------------060601030806070808060001--

From cabo@tzi.org  Thu Oct 28 14:49:10 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D113A68BB for ; Thu, 28 Oct 2010 14:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.186
X-Spam-Level: 
X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VzBtmHN1gE6 for ; Thu, 28 Oct 2010 14:49:10 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 867CF3A67B3 for ; Thu, 28 Oct 2010 14:49: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 o9SLor53029139; Thu, 28 Oct 2010 23:50:53 +0200 (CEST)
Received: from [192.168.217.101] (p5489FD73.dip.t-dialin.net [84.137.253.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9F9B2281; Thu, 28 Oct 2010 23:50:52 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 28 Oct 2010 23:50:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4AFE79F4-B668-4B36-97A4-536F2A95D6C5@tzi.org>
References:   <42F80FDA-23BB-4982-A438-7CB0FE143FC9@tzi.org> 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core , Klaus Hartke 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 21:49:11 -0000

On Oct 28, 2010, at 23:30, Peter Bigot wrote:

> inconsistent

Philosophical observation:
Knowing when to give up consistency (the C in ACID) was one of the major =
enabling innovations of the web.

My gut feeling is that not constraining applications in that respect =
(i.e., not requiring consistent retransmissions) cannot possibly cause =
problems.
But yes, it can't be wrong to spend some more thought on this.

Gruesse, Carsten


From yoshihiro.ohba@toshiba.co.jp  Thu Oct 28 16:18:27 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3713A680E for ; Thu, 28 Oct 2010 16:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level: 
X-Spam-Status: No, score=-4.089 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, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KihlU0cCqnm for ; Thu, 28 Oct 2010 16:18:26 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 173CC3A6801 for ; Thu, 28 Oct 2010 16:18:25 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp  with ESMTP id o9SNKI2o014591 for ; Fri, 29 Oct 2010 08:20:18 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp  id o9SNKISK023256 for core@ietf.org; Fri, 29 Oct 2010 08:20:18 +0900 (JST)
Received: from unknown [133.199.192.144]  by arc1.toshiba.co.jp with ESMTP id JAA23255; Fri, 29 Oct 2010 08:20:17 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp  with ESMTP id o9SNKH6l017745 for ; Fri, 29 Oct 2010 08:20:17 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o9SNKHnO014866; Fri, 29 Oct 2010 08:20:17 +0900 (JST)
Received: from [133.199.17.172] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LB000CGBWTRII80@mail.po.toshiba.co.jp> for core@ietf.org; Fri, 29 Oct 2010 08:20:17 +0900 (JST)
Date: Fri, 29 Oct 2010 08:20:14 +0900
From: Yoshihiro Ohba 
In-reply-to: 
To: core@ietf.org
Message-id: <4CCA052E.2010909@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
Content-transfer-encoding: 7bit
References:   <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com>  <4CA5E8E0.4030503@gmail.com>  <4CA6095F.6040403@gmail.com>  <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <023a01cb76e1$869bfcc0$93d3f640$%yegin@yegin.org> 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 28 Oct 2010 23:18:27 -0000

OK, then let me use the term "RADIUS server" to explain.

Any EAP transport protocol such as IEEE 802.1X and PANA works with
multiple AAA domains in which a single access network may interface to
multiple RADIUS servers where each RADIUS server serves for a distinct
AAA domain.  With EAP, RADIUS routing is based on the EAP peer
identity such as "foo@domainA.com" and "bar@domainB.com" in a way that
authentication messages for EAP peer "foo@domainA.com"are routed to
"domainA.com" RADIUS server and authentication messages for EAP peer
"bar@domainB.com" are routed to "domainB.com" RADIUS server.  The EAP
peer identity is extracted from the initial EAP exchange by an EAP
pass-through authenticator that is co-located with a RADIUS client at
the border of the access network.  In a large scale RADIUS deployment,
there may be RADIUS proxies between a RADIUS client and a RADIUS
server to simplify the AAA routing task for RADIUS clients.  In PANA,
PAA (PANA Authentication Agent) is the EAP pass-through authenticator,
and PaC (PANA Client) is the EAP peer.

Hope this helps,
Yoshihiro Ohba

(2010/10/29 6:21), Carsten Bormann wrote:
> On Oct 28, 2010, at 22:48, Alper Yegin wrote:
> 
>> mothership
> 
> I think other terms are "mother-may-I", "trust center", "RADIUS server", or "Policy Decision Point".  Just guessing, though.
> I think the use case of interest here is a single constrained network that simultaneously serves multiple trust domains, so being authorized by any one of them should give you access.
> 
> With that potential explanation, can you elucidate whether (and maybe how) PANA would work in this scenario?
> 
> Gruesse, Carsten
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> 


From rstruik.ext@gmail.com  Thu Oct 28 20:37:01 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DB83A69E3 for ; Thu, 28 Oct 2010 20:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.852
X-Spam-Level: 
X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei-F2x8NjLOq for ; Thu, 28 Oct 2010 20:36:49 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 33C3A3A69DE for ; Thu, 28 Oct 2010 20:36:44 -0700 (PDT)
Received: by yxp4 with SMTP id 4so1872702yxp.31 for ; Thu, 28 Oct 2010 20:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=fBwMIzhN/bfceQGnsxngX3n5Z7itfXzWxTGwAjL66ZQ=; b=hk4qy8JYNMLZa2asH4x/SaBNdRoa+EyBnqOR3LrM+A+gt4TTyP1U0zX4sorMyxTkL/ xufHsQaPaQQMy2z0chik2QjAg77pGzCSRYXOgk4OekO4yv2uZrp7cyobFXJ+Fue5MjPN xUp0cGWHlgWkhGyIOuJ/FqkRqGbCU0ZY0G73o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=v3PXeKlMxrJreFvlrTKrZ/GwhbqOhUCqDfcMEnwA+UC9ImyI1YoKqCdk2+U2A/xJIc D6hlsrFqAc08usXdyIbP7KMXFE3IhJcO9fW3NkK1CGOBLDzAJaaA77fswbkj+2/ejReJ q6yMlqX3JprU7RzxaGWqUaOu7Yd85WwfC12vM=
Received: by 10.150.146.14 with SMTP id t14mr21210485ybd.421.1288323511811; Thu, 28 Oct 2010 20:38:31 -0700 (PDT)
Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id v9sm6423514ybe.21.2010.10.28.20.38.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 20:38:31 -0700 (PDT)
Message-ID: <4CCA41AC.6040800@gmail.com>
Date: Thu, 28 Oct 2010 23:38:20 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Yoshihiro Ohba 
References: 		<935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org>	<4CA3BB54.8050706@gmail.com>		<4CA5E8E0.4030503@gmail.com>		<4CA6095F.6040403@gmail.com>		<4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com>	<023a01cb76e1$869bfcc0$93d3f640$%yegin@yegin.org>	 <4CCA052E.2010909@toshiba.co.jp>
In-Reply-To: <4CCA052E.2010909@toshiba.co.jp>
Content-Type: multipart/alternative; boundary="------------020604040200050600090504"
Cc: core@ietf.org
Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 03:37:02 -0000

This is a multi-part message in MIME format.
--------------020604040200050600090504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Yoshihiro:

It seems that in your example each device identifier is tied to a single 
security manager (e.g., device A and security manager S would yield 
device id A@S.com).

This seems to imply the following:
(a) entangles the name space and device role space (since tie-ing node A 
to a node S that assumes a security manager role for A);
(b) precludes scenarios where
     (b1) a device may have multiple security managers (example: remote 
control, spare remote under the pillow, central node);
     (b2) a security manager may change over time (example: change of 
security manager, due to malfunctioning device or ownership change);
     (b3) a device may not have a security manager yet (example: device 
is initially taken out of generic box, without any imprinting happening 
yet);
     (b4) a device and security manager may not be in hierarchical 
relationship (example: simple device pairing a la Bluetooth v2.1 EDR).
As such, this seems to preclude many useful deployment scenarios for 
sensor networks.

Hence, my note in my email as of Wed October 27, 2010, 11:04am EDT re 
the latest version of draft-oflynn-core-bootstrapping-02, in which I 
highlighted the importance of facilitating a flexible set of deployment 
scenarios.

Please let me know if I misinterpreted your EAP-style explanation 
(above, I only focus on logical device roles and not on communication 
patterns).

Best regards, Rene

[excerpt email RS as of October 1, 2010, 12:16pm EDT]

In my mind, properties of suitable authenticated key agreement schemes 
should include (a) key establishment; (b) implicit key authentication; 
(c) key confirmation; (d) mutual entity authentication; (e) forward 
secrecy; (f) {perhaps} some more esoteric properties (key compromise 
impersonation resilience, etc.).

Moreover, the "name space" (device identifiers) and the "cryptographic 
space" (public keys, etc.) should be independent, so that this would 
allow trust lifecycle management to be reduced to proper management of 
device identifiers (i.e., ****no** entanglement of concepts from 
different disciplines).


On 28/10/2010 7:20 PM, Yoshihiro Ohba wrote:
> OK, then let me use the term "RADIUS server" to explain.
>
> Any EAP transport protocol such as IEEE 802.1X and PANA works with
> multiple AAA domains in which a single access network may interface to
> multiple RADIUS servers where each RADIUS server serves for a distinct
> AAA domain.  With EAP, RADIUS routing is based on the EAP peer
> identity such as "foo@domainA.com" and "bar@domainB.com" in a way that
> authentication messages for EAP peer "foo@domainA.com"are routed to
> "domainA.com" RADIUS server and authentication messages for EAP peer
> "bar@domainB.com" are routed to "domainB.com" RADIUS server.  The EAP
> peer identity is extracted from the initial EAP exchange by an EAP
> pass-through authenticator that is co-located with a RADIUS client at
> the border of the access network.  In a large scale RADIUS deployment,
> there may be RADIUS proxies between a RADIUS client and a RADIUS
> server to simplify the AAA routing task for RADIUS clients.  In PANA,
> PAA (PANA Authentication Agent) is the EAP pass-through authenticator,
> and PaC (PANA Client) is the EAP peer.
>
> Hope this helps,
> Yoshihiro Ohba
>
> (2010/10/29 6:21), Carsten Bormann wrote:
>> On Oct 28, 2010, at 22:48, Alper Yegin wrote:
>>
>>> mothership
>> I think other terms are "mother-may-I", "trust center", "RADIUS server", or "Policy Decision Point".  Just guessing, though.
>> I think the use case of interest here is a single constrained network that simultaneously serves multiple trust domains, so being authorized by any one of them should give you access.
>>
>> With that potential explanation, can you elucidate whether (and maybe how) PANA would work in this scenario?
>>
>> Gruesse, Carsten
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


--------------020604040200050600090504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Yoshihiro:

    

    It seems that in your example each device identifier is tied to a
    single security manager (e.g., device A and security manager S would
    yield device id A@S.com). 

    

    This seems to imply the following:

    (a) entangles the name space and device role space (since tie-ing
    node A to a node S that assumes a security manager role for A); 

    (b) precludes scenarios where 

        (b1) a device may have multiple security managers (example:
    remote control, spare remote under the pillow, central node);

        (b2) a security manager may change over time (example: change of
    security manager, due to malfunctioning device or ownership change);

        (b3) a device may not have a security manager yet (example:
    device is initially taken out of generic box, without any imprinting
    happening yet);

        (b4) a device and security manager may not be in hierarchical
    relationship (example: simple device pairing a la Bluetooth v2.1
    EDR).

    As such, this seems to preclude many useful deployment scenarios for
    sensor networks.

    

    Hence, my note in my email as of Wed October 27, 2010, 11:04am EDT
    re the latest version of draft-oflynn-core-bootstrapping-02, in
    which I highlighted the importance of facilitating a flexible set of
    deployment scenarios.

    

    Please let me know if I misinterpreted your EAP-style explanation
    (above, I only focus on logical device roles and not on
    communication patterns).

    

    Best regards, Rene

    

    [excerpt email RS as of October 1, 2010, 12:16pm EDT]

    

    In my mind, properties of suitable authenticated key agreement
    schemes should include (a) key establishment; (b) implicit key
    authentication; (c) key confirmation; (d) mutual entity
    authentication; (e) forward secrecy; (f) {perhaps} some more
    esoteric properties (key compromise impersonation resilience, etc.).
    

    

    Moreover, the "name space" (device identifiers) and the
    "cryptographic space" (public keys, etc.) should be independent, so
    that this would allow trust lifecycle management to be reduced to
    proper management of device identifiers (i.e., *no*
    entanglement of concepts from different disciplines). 

    

    

    On 28/10/2010 7:20 PM, Yoshihiro Ohba wrote:
    

      
OK, then let me use the term "RADIUS server" to explain.

Any EAP transport protocol such as IEEE 802.1X and PANA works with
multiple AAA domains in which a single access network may interface to
multiple RADIUS servers where each RADIUS server serves for a distinct
AAA domain.  With EAP, RADIUS routing is based on the EAP peer
identity such as "foo@domainA.com" and "bar@domainB.com" in a way that
authentication messages for EAP peer "foo@domainA.com"are routed to
"domainA.com" RADIUS server and authentication messages for EAP peer
"bar@domainB.com" are routed to "domainB.com" RADIUS server.  The EAP
peer identity is extracted from the initial EAP exchange by an EAP
pass-through authenticator that is co-located with a RADIUS client at
the border of the access network.  In a large scale RADIUS deployment,
there may be RADIUS proxies between a RADIUS client and a RADIUS
server to simplify the AAA routing task for RADIUS clients.  In PANA,
PAA (PANA Authentication Agent) is the EAP pass-through authenticator,
and PaC (PANA Client) is the EAP peer.

Hope this helps,
Yoshihiro Ohba

(2010/10/29 6:21), Carsten Bormann wrote:


      

        
On Oct 28, 2010, at 22:48, Alper Yegin wrote:



        

          
mothership


        

        
I think other terms are "mother-may-I", "trust center", "RADIUS server", or "Policy Decision Point".  Just guessing, though.
I think the use case of interest here is a single constrained network that simultaneously serves multiple trust domains, so being authorized by any one of them should give you access.

With that potential explanation, can you elucidate whether (and maybe how) PANA would work in this scenario?

Gruesse, Carsten

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



      

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


    

    

    

    
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

  


--------------020604040200050600090504--

From zach@sensinode.com  Thu Oct 28 23:37:17 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCEF3A69DD for ; Thu, 28 Oct 2010 23:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.072
X-Spam-Level: 
X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAtgjEuR8wjJ for ; Thu, 28 Oct 2010 23:37:15 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7B5C93A67A6 for ; Thu, 28 Oct 2010 23:36:54 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9T6cjL7021832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Oct 2010 09:38:45 +0300
From: Zach Shelby 
Content-Type: multipart/signed; boundary=Apple-Mail-48-789481304; protocol="application/pkcs7-signature"; micalg=sha1
Date: Fri, 29 Oct 2010 09:38:46 +0300
References: <20101029053328.1BE96E070C@rfc-editor.org>
To: core 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [core] Fwd: RFC 5988 on Web Linking
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 06:37:17 -0000

--Apple-Mail-48-789481304
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The document that is the main reference for core-link-format has now =
been published as an RFC. Thanks Mark!=20

Zach

Begin forwarded message:

> From: rfc-editor@rfc-editor.org
> Date: October 29, 2010 8:33:28 AM GMT+03:00
> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
> Cc: rfc-editor@rfc-editor.org
> Subject: RFC 5988 on Web Linking
>=20
>=20
> A new Request for Comments is now available in online RFC libraries.
>=20
>=20
>        RFC 5988
>=20
>        Title:      Web Linking=20
>        Author:     M. Nottingham
>        Status:     Standards Track
>        Stream:     IETF
>        Date:       October 2010
>        Mailbox:    mnot@mnot.net
>        Pages:      23
>        Characters: 46834
>        Updates:    RFC4287
>=20
>        I-D Tag:    draft-nottingham-http-link-header-10.txt
>=20
>        URL:        http://www.rfc-editor.org/rfc/rfc5988.txt
>=20
> This document specifies relation types for Web links, and defines a
> registry for them.  It also defines the use of such links in HTTP
> headers with the Link header field.  [STANDARDS-TRACK]
>=20
> This is now a Proposed Standard Protocol.
>=20
> 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.
>=20
> 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
>=20
> For searching the RFC series, see =
http://www.rfc-editor.org/rfcsearch.html.
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
>=20
> 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.
>=20
>=20
> The RFC Editor Team
> Association Management Solutions, LLC
>=20
>=20
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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


--Apple-Mail-48-789481304
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTA2Mzg0
NlowIwYJKoZIhvcNAQkEMRYEFNVnV+/+l2Ouewf+wFz7b1qvSyvfMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAIZcajdQ5GuU9Poyfrm/5EeXl0lro77EjOryr6Id99Gmzt94nr7PofZG
JwcQyaAtAZyXKxRhQ/uI+M02YiMJAgwguXQS65qyZJhNsmre8ulnmjp0oT7+ZFxUa1cDUYpy2z9+
am1K5XkLmg4SMny9OwiaNr107Azud9wNedPkLa4Gn1gLCflzY8CUpAmCn3EZMrjerXheIkkIuNy0
vuhl38S2+Xtt1qxLQ0vm5pB2KOfEHIhy9nlAD08S7tFLlb2U75W+IqE4rPknOP+jkr23TZ/J0uDR
1ctLr/vR2tj00NY6f3uX7p/blEU1vzPAL1LADdN0M6ZmAl7XwJli6EeyUx8AAAAAAAA=

--Apple-Mail-48-789481304--

From zach@sensinode.com  Thu Oct 28 23:54:31 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BB7F3A6A03 for ; Thu, 28 Oct 2010 23:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.37
X-Spam-Level: 
X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.229,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEf0HL0RGhRH for ; Thu, 28 Oct 2010 23:54:26 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5B1213A6A08 for ; Thu, 28 Oct 2010 23:54:20 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9T6u9aJ024470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Oct 2010 09:56:09 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-53-790525483; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Fri, 29 Oct 2010 09:56:10 +0300
Message-Id: 
References:   <42F80FDA-23BB-4982-A438-7CB0FE143FC9@tzi.org> 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: Klaus Hartke , core 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 06:54:32 -0000

--Apple-Mail-53-790525483
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 29, 2010, at 12:30 AM, Peter Bigot wrote:

> In any case, since there's no initial unanimity, whether or not this =
is allowed should be explicit with either a MAY or a MUST NOT clause.


Sure, we should at least describe this better in the draft. My own =
assumption has been that a retransmitted request is equivalent (if not =
identical) to the original request. Implementation wise, this is usually =
handled at the transaction layer, where you tend to keep a copy of the =
buffer. I definitely don't recommend sending a different version of the =
resource representation for each retransmission.... I'll open up a =
ticket on this.

Zach =20

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


--Apple-Mail-53-790525483
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTA2NTYx
MVowIwYJKoZIhvcNAQkEMRYEFBMmlwufZnqUGO6oKg1eL52lGK4fMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAISq2NYCCP5eE1Lbf61a0txEp3Iv4852eSLtrA9Dru+lVwJDZsvlEBmB
3mzHbyJSj4xwfsmPZ9Kvmgs7DEB0kJtZNHrLpeM3KUUVndZ9UWxEQEZMq220w7qyrSQeOB69REYm
FMD+NYgSDHuQSgLMXyJ6FV4ULccvrtE2pXqXLxIdDDI77lAWJ97aQ6EKctkdMOT9+WmIsX57v7t+
wBcsmuEzkXDWO1i81ZEF5JouZGmyanAehSn9I+eFaQBRROvF9NFI3x1XGwd87SaK0x1ueC4HYxiz
fv5pAoE2u1DpCQkkFVWRfFLV6BFU89Yv1LKic6PYQItuTqWt1ss9OsyxGh4AAAAAAAA=

--Apple-Mail-53-790525483--

From trac@tools.ietf.org  Thu Oct 28 23:58:46 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B834B3A6A0B for ; Thu, 28 Oct 2010 23:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b1G4SksOZE4 for ; Thu, 28 Oct 2010 23:58:45 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 94A8F3A6A0A for ; Thu, 28 Oct 2010 23:58:45 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PBix4-0002le-GG; Fri, 29 Oct 2010 00:00:38 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Fri, 29 Oct 2010 07:00:35 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/28
Message-ID: <057.548fe514a79c88899d8aba947024686a@tools.ietf.org>
X-Trac-Ticket-ID: 28
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  coap #28 (new): Clarification on retransmission
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 06:58:46 -0000

#28: Clarification on retransmission

 On Thu, Oct 28, 2010 at 2:11 PM, Klaus Hartke  wrote:
 4.2.
 Should retransmits of responses transmit the current state of
 resource, rather than a snapshot of the state at the time of the first
 attempt?

 Zach: This ticked is to clarify the recommended practice on this. The
 assumption of the CoAP design so far has been that the original request is
 retransmitted.

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  trivial             |   Milestone:     
Component:  coap                |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From trac@tools.ietf.org  Fri Oct 29 00:16:32 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CBE3A6A09 for ; Fri, 29 Oct 2010 00:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKg3mOwYuC68 for ; Fri, 29 Oct 2010 00:16:29 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B5C7B3A6A0D for ; Fri, 29 Oct 2010 00:16:29 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PBjEF-0005sl-A2; Fri, 29 Oct 2010 00:18:23 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Fri, 29 Oct 2010 07:18:23 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/29
Message-ID: <057.720c77c10dfd79dc738e07ea839f5bcb@tools.ietf.org>
X-Trac-Ticket-ID: 29
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  coap #29 (new): Error in Section 2.1.2. example text
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 07:16:32 -0000

#29: Error in Section 2.1.2. example text

 Klaus found an error in the Section 2.1.2. example text:

 "Since no Token Option was included" - A Token Option is clearly
 present in figure 3, no?

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  defect              |      Status:  new
 Priority:  trivial             |   Milestone:     
Component:  coap                |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From trac@tools.ietf.org  Fri Oct 29 00:25:45 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80233A683B for ; Fri, 29 Oct 2010 00:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoKAFfT0tr6F for ; Fri, 29 Oct 2010 00:25:43 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 94CB03A6A0E for ; Fri, 29 Oct 2010 00:25:43 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PBjNB-0005Rz-4S; Fri, 29 Oct 2010 00:27:37 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Fri, 29 Oct 2010 07:27:37 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/30
Message-ID: <057.95e09aa7bf9ef22eefecd576ea57db61@tools.ietf.org>
X-Trac-Ticket-ID: 30
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  coap #30 (new): Max-Age 0-4 bytes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 07:25:46 -0000

#30: Max-Age 0-4 bytes

 From Klaus:

 3.2.
 Table 2 lists the Max-age Option with a length of 1-4 B and a default
 value of 60 seconds. Why not allow a value of 0 seconds to be
 expressed with 0 bytes?

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  minor               |   Milestone:     
Component:  coap                |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From trac@tools.ietf.org  Fri Oct 29 00:27:03 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C4F3A6A12 for ; Fri, 29 Oct 2010 00:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1+OdvM8ilS4 for ; Fri, 29 Oct 2010 00:26:54 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ECB253A6840 for ; Fri, 29 Oct 2010 00:26:53 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PBjOK-0001ws-26; Fri, 29 Oct 2010 00:28:48 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Fri, 29 Oct 2010 07:28:47 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/31
Message-ID: <057.e71925e7e803bcac7a02717afdb67a8f@tools.ietf.org>
X-Trac-Ticket-ID: 31
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  coap #31 (new): Variable unsigned integer definition
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 07:27:03 -0000

#31: Variable unsigned integer definition

 The format of a variable-length unsigned identifier currently isn't
 defined anywhere.

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  defect              |      Status:  new
 Priority:  trivial             |   Milestone:     
Component:  coap                |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: 
core 


From yoshihiro.ohba@toshiba.co.jp  Fri Oct 29 00:29:06 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912643A6A1F for ; Fri, 29 Oct 2010 00:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level: 
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=0.000,  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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVh0aVPG7Kaz for ; Fri, 29 Oct 2010 00:28:50 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id EFC8F3A6A17 for ; Fri, 29 Oct 2010 00:28:49 -0700 (PDT)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp  with ESMTP id o9T7UeKt018426; Fri, 29 Oct 2010 16:30:40 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp  id o9T7UeKb018198; Fri, 29 Oct 2010 16:30:40 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148]  by arc11.toshiba.co.jp with ESMTP id SAA18195; Fri, 29 Oct 2010 16:30:40 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp  with ESMTP id o9T7UdQu006372; Fri, 29 Oct 2010 16:30:40 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o9T7ULFN002160; Fri, 29 Oct 2010 16:30:39 +0900 (JST)
Received: from [133.199.75.97] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LB100G6UJIZJ1E0@mail.po.toshiba.co.jp>; Fri, 29 Oct 2010 16:30:36 +0900 (JST)
Date: Fri, 29 Oct 2010 16:30:33 +0900
From: Yoshihiro Ohba 
In-reply-to: <4CCA41AC.6040800@gmail.com>
To: Rene Struik 
Message-id: <4CCA7819.6020908@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
Content-transfer-encoding: 7bit
References:   <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com>  <4CA5E8E0.4030503@gmail.com>  <4CA6095F.6040403@gmail.com>  <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <023a01cb76e1$869bfcc0$93d3f640$%yegin@yegin.org>  <4CCA052E.2010909@toshiba.co.jp> <4CCA41AC.6040800@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
Cc: core@ietf.org
Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 07:29:06 -0000

Hello Rene,

Thank you very much for expressing your concerns in detail.

Basically there is no implications such as (a) and (b1) to (b4) in the
general framework of PANA, EAP and AAA.  Let me explain this in
details below..

(2010/10/29 12:38), Rene Struik wrote:
> Hi Yoshihiro:
> 
> It seems that in your example each device identifier is tied to a 
> single security manager (e.g., device A and security manager S would 
> yield device id A@S.com).
> 
> This seems to imply the following:
> (a) entangles the name space and device role space (since tie-ing node 
> A to a node S that assumes a security manager role for A);

In the case where the EAP peer identity is tied with the device in
which the EAP peer resides, you are right.  However, the EAP peer
identity is not necessarily tied with the device.  It can be also tied
with the user who uses the device.  Or when a tunneling EAP method
such as EAP-TTLS is used, it is possible to tie the EAP peer identity
for the outer EAP method with the device *and* tie the EAP peer
identity for the inner EAP method with the user.  So in general EAP
framework, there is no fixed binding is assumed between the device and
security manager.

> (b) precludes scenarios where
> (b1) a device may have multiple security managers (example: remote 
> control, spare remote under the pillow, central node);

When PANA is used, it is possible to have multiple PANA sessions
between a PaC and a PAA, and different EAP peer identities can be used
for those PANA sessions where each EAP peer identity may be tied with
a distinct security manager.  OTOH, this kind of scenario is difficult
to be supported by IEEE 802.1X which allows only one authentication
session between a pair of 802.1X Supplicant and Authenticator.

> (b2) a security manager may change over time (example: change of 
> security manager, due to malfunctioning device or ownership change);

I think this is basically a provisioning issue.  If a deployment uses
a provisioning mechanism that allows dynamically changing the EAP peer
identity associated with a particular device, it is possible to change
a security manager over time under the EAP framework.

> (b3) a device may not have a security manager yet (example: device is 
> initially taken out of generic box, without any imprinting happening 
> yet);

Again I think this is a provisioning issue.  If a deployment uses a
provisioning mechanism that supports a standalone bootstrapping
mechanism during the provisioning phase, it is possible not to use a
security manager in the provisioning phase.

> (b4) a device and security manager may not be in hierarchical 
> relationship (example: simple device pairing a la Bluetooth v2.1 EDR).
> As such, this seems to preclude many useful deployment scenarios for 
> sensor networks.

Since the EAP framework does not require to use the AAA
infrastructure, a P2P relationship can be supported by the EAP framework.

We can clarify these things in the core-bootstrapping draft if it helps.

Best Regards,
Yoshihiro Ohba


> 
> Hence, my note in my email as of Wed October 27, 2010, 11:04am EDT re 
> the latest version of draft-oflynn-core-bootstrapping-02, in which I 
> highlighted the importance of facilitating a flexible set of 
> deployment scenarios.
> 
> Please let me know if I misinterpreted your EAP-style explanation 
> (above, I only focus on logical device roles and not on communication 
> patterns).
> 
> Best regards, Rene
> 
> [excerpt email RS as of October 1, 2010, 12:16pm EDT]
> 
> In my mind, properties of suitable authenticated key agreement schemes 
> should include (a) key establishment; (b) implicit key authentication; 
> (c) key confirmation; (d) mutual entity authentication; (e) forward 
> secrecy; (f) {perhaps} some more esoteric properties (key compromise 
> impersonation resilience, etc.).
> 
> Moreover, the "name space" (device identifiers) and the "cryptographic 
> space" (public keys, etc.) should be independent, so that this would 
> allow trust lifecycle management to be reduced to proper management of 
> device identifiers (i.e., ****no** entanglement of concepts from 
> different disciplines).
> 
> 
> On 28/10/2010 7:20 PM, Yoshihiro Ohba wrote:
>> OK, then let me use the term "RADIUS server" to explain.
>>
>> Any EAP transport protocol such as IEEE 802.1X and PANA works with
>> multiple AAA domains in which a single access network may interface to
>> multiple RADIUS servers where each RADIUS server serves for a distinct
>> AAA domain. With EAP, RADIUS routing is based on the EAP peer
>> identity such as "foo@domainA.com" and "bar@domainB.com" in a way that
>> authentication messages for EAP peer "foo@domainA.com"are routed to
>> "domainA.com" RADIUS server and authentication messages for EAP peer
>> "bar@domainB.com" are routed to "domainB.com" RADIUS server. The EAP
>> peer identity is extracted from the initial EAP exchange by an EAP
>> pass-through authenticator that is co-located with a RADIUS client at
>> the border of the access network. In a large scale RADIUS deployment,
>> there may be RADIUS proxies between a RADIUS client and a RADIUS
>> server to simplify the AAA routing task for RADIUS clients. In PANA,
>> PAA (PANA Authentication Agent) is the EAP pass-through authenticator,
>> and PaC (PANA Client) is the EAP peer.
>>
>> Hope this helps,
>> Yoshihiro Ohba
>>
>> (2010/10/29 6:21), Carsten Bormann wrote:
>>> On Oct 28, 2010, at 22:48, Alper Yegin wrote:
>>>
>>>> mothership
>>> I think other terms are "mother-may-I", "trust center", "RADIUS 
>>> server", or "Policy Decision Point". Just guessing, though.
>>> I think the use case of interest here is a single constrained 
>>> network that simultaneously serves multiple trust domains, so being 
>>> authorized by any one of them should give you access.
>>>
>>> With that potential explanation, can you elucidate whether (and 
>>> maybe how) PANA would work in this scenario?
>>>
>>> Gruesse, Carsten
>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
> 
> 


From zach@sensinode.com  Fri Oct 29 00:32:32 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A772D3A683B for ; Fri, 29 Oct 2010 00:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.374
X-Spam-Level: 
X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2+thr1axYEw for ; Fri, 29 Oct 2010 00:32:31 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3EF6C3A6A37 for ; Fri, 29 Oct 2010 00:32:16 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9T7Y2Kj032144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Oct 2010 10:34:02 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-60-792798265; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Fri, 29 Oct 2010 10:34:03 +0300
Message-Id: 
References: 
To: Klaus Hartke 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 07:32:32 -0000

--Apple-Mail-60-792798265
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks Klaus for the detailed review. I start to miss some of these =
details from knowing the text too well. Some comments in-line, my goal =
is to turn the key points you brought up into tickets.=20

On Oct 28, 2010, at 10:11 PM, Klaus Hartke wrote:

> Just some random things I noted while reading coap-03:
>=20
>=20
> 2.1.1.
> The figure suggests that the payload of a 4xx/5xx response is a
> human-readable diagnostic message (here: "Not found"). This doesn't
> seem to be defined anywhere, although I'd love if it was. (For
> example, my CoAP server includes a complete stack trace in a 500
> response when an exception is thrown and it's in debug mode. This
> helps remote debugging a lot.)

We could do that, I guess it would go into Section 11.1 where codes are =
defined in general?

>=20
> 2.1.1.
> It's somewhat unclear to me from this section how ACKs and responses
> relate to each other. Maybe it makes sense to explain asynchronous
> responses first and present synchronous responses as optimization?

OK, we need to play with the organization. I am not totally sure =
changing that order would help though, as asynchronous responses should =
be an exception.

>=20
> 2.1.1.
> This sections talks about the interaction between Req/Res and
> Transaction layers, but section 2.1. is about the Interaction Model
> between CoAP end-points.

Maybe Section 2.1 needs to be re-named? Or we could split the section =
differently:

2.1. Transaction Model
2.1.1. Reliable Transaction
2.1.2. Unreliable Transaction
2.1.3. Transaction Messages

2.2. Request/Response Model
2.2.1. Synchronous Responses
2.2.2. Asynchronous Responses
2.2.3. Methods
2.2.4. Codes

2.3. Options

>=20
> 2.1.2.
> "Since no Token Option was included" - A Token Option is clearly
> present in figure 3, no?

Oops. That's what I get trying to hack the old example text. Needs to be =
fixed.

>=20
> 2.1.2.
> Why does the server deny to answer the request if a client decides not
> to include a token? If the client can relate the asynchronous response
> to its request without a token, it's not the responsibility of the
> server to tell the client it cannot.

See the thread continued by peter on this. We had this discussion when =
deciding on including the Token option.

>=20
> 2.1.2.
> Given the current wording, it seems much simpler to me to let an
> implementation simply always include a token in a request, instead of
> hoping for a synchronous response and retrying in case of an
> asynchronous one. After a successful request, the client cannot even
> cache if it needs to include a token or not, because the same request
> to the same resource may or may not yield an asynchronous response at
> a later point of time.

The purpose of this was to give the client some control whether it wants =
an asynchronous response in the first place. The draft does not prevent =
you always including a token if your client likes. But maybe this would =
need better explanation in the text anyways.=20

>=20
> 2.1.3.
> Section 2.1. says that transaction messages enable optional
> reliability, and sections 2.1.1. and 2.1.2. describe reliable
> requests, but no section talks about unreliable interactions. (The
> only place where non-confirmable messages are mentioned is in section
> 4.1. "Multicast messages SHOULD be Non-Confirmable.")

Good point, see my outline suggestion above... we should add a =
subsection on that.

>=20
> 2.3.2.
> The section suggests that the only possible interpretation of POST is
> to create a new subordinate resource on the server. Is this the case?
> If yes, rename POST to CREATE?

Kerry Lynn suggested an improvement on the text for -03. Sorry I was in =
too much of a hurry submitting -03 to synchronize this with RFC2616. Did =
this break something?=20

> 2.5.1.
> "including a copy of the critical option number in the payload of the
> response." - in what format? I'd assume it's a variable-length
> unsigned integer, but the section doesn't say. I'd also still prefer
> to reserve the payload of error responses for human-readable messages
> (utf-8 string, software must attribute no meaning to message).

I was thinking this would be text/plain. This relates to your earlier =
comment in general about the payload of error messages.

>=20
> 3.2.
> Table 2 lists the Token Option with a length of 1-2 B. That prevents a
> lot of interesting usage cases wrt statelessness. What's the reasoning
> to limit a token to 1-2 B?

I take responsibility for this one. Let's ask the question the other way =
around. Why do you need more than 64k token possibilities? Overhead was =
my reasoning, especially if you are including this token quite often. =
The problem is, constrained nodes will be forced to process or even =
store most options. On some architectures this might force a node to =
reserve space for the largest possible option length. So I would like to =
avoid having all options be up to 4 bytes.=20

>=20
> 3.2.
> Table 2 lists the Max-age Option with a length of 1-4 B and a default
> value of 60 seconds. Why not allow a value of 0 seconds to be
> expressed with 0 bytes?

Good idea.

>=20
> 3.2.
> The format of a variable-length unsigned identifier isn't defined =
anywhere.

We had that before, but many people commented that it is not necessary. =
I guess we should have some text defining this.=20

>=20
> 3.2.8.
> It is sufficient if token values are unique in use per server.

Per client? The token is generated and matched by the client.=20

>=20
> 3.2.8.
> "If a Token Option is included in a request, the response (and
> any	subsequent delayed responses) MUST include the same value in a
> Token Option." - section 2.1.1. says that Token can be omitted from
> synchronous responses.

Hmmm.. that should be fixed. The idea is that if a token is included by =
the client, it MUST be included in the response (synchronous or =
asynchronous).

>=20
> 3.2.8.
> "If a Token Option is included in a request, any resulting delayed
> response SHOULD NOT include the URI option" - nothing in coap-03
> encourages to ever include URI-related options in a response, or does
> it?

Oops, left over from an older version. I would still like to leave the =
URI as an option for observe notifications, but that is for the observe =
draft.=20

>=20
> 3.2.
> Would it make sense to expand table 2 with a column that indicates if
> the option can occur in a request, in a response or in both?

We had that before. But it turns out that most of these can occur in =
either one. Exceptions? Does Location ever occur in a request?

> 4.2.
> Should retransmits of responses transmit the current state of
> resource, rather than a snapshot of the state at the time of the first
> attempt?

Made a ticket on this.

Cheers,
Zach

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

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


--Apple-Mail-60-792798265
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTA3MzQw
M1owIwYJKoZIhvcNAQkEMRYEFAM7vf6nW8cwLhhgkYzRGxPLIs6DMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBACOyG6NQos/oTfhsIXuREjQW/KG1zQqJf3hruCCBYn+spx3ommyYYxV4
/PnwDkkpYnR+8InNND9g3xVJw5yNPuERcjxAKvYVl8BKBZGAXNWsAXUBqBfDi61w700hPEFI+vrc
oRHn+IG+zU6wy6vJZQDDH57jM7uVoXnTd9wbAmhznjYkXCPNibbWb4eMNCrq5VQBUFC+Z+GqxZOj
dOHsN/RUXH9I1E1Z8CX+sS2HgZ49QVqQIEU5whOmT2a3XleekpztVoXkjI48UOSIZB1RnT5USDh9
rQWA6+fvKmldWt7MDwerBzbIjR8ndjgyj84gz8DSMpsxQxf8ginz2nPeuu0AAAAAAAA=

--Apple-Mail-60-792798265--

From Mohana.Jeyatharan@sg.panasonic.com  Fri Oct 29 00:33:38 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F793A6A1E for ; Fri, 29 Oct 2010 00:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnIyIeLRF6kX for ; Fri, 29 Oct 2010 00:33:37 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 4587B3A683B for ; Fri, 29 Oct 2010 00:33:37 -0700 (PDT)
Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id o9T7ZFPh015719; Fri, 29 Oct 2010 16:35:15 +0900 (JST)
Received: from pslexc01.psl.local ([10.81.112.5]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili12) with ESMTP id o9T7ZEX08565; Fri, 29 Oct 2010 16:35:15 +0900
Received: from NW-MOHANA-L1 ([10.81.113.96]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Oct 2010 15:35:13 +0800
Received: from NWMOHANAL1 by NW-MOHANA-L1 (PGP Universal service); Fri, 29 Oct 2010 15:39:15 +0800
X-PGP-Universal: processed; by NW-MOHANA-L1 on Fri, 29 Oct 2010 15:39:15 +0800
From: "mohana Jeyatharan" 
To: "'Klaus Hartke'" , 
References: <5F09D220B62F79418461A978CA0921BD04744711@pslexc01.psl.local> 
In-Reply-To: 
Date: Fri, 29 Oct 2010 15:38:59 +0800
Message-ID: <006601cb773c$5a489380$0ed9ba80$@sg.panasonic.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-index: AQGTYgsyl/2NuL6edU1wh2QibDeyYwHr7eLgk7hSYAA=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-language: en-us
X-OriginalArrivalTime: 29 Oct 2010 07:35:13.0399 (UTC) FILETIME=[D2D2B070:01CB773B]
Subject: Re: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 07:33:39 -0000

Hi Klaus,

Thanks for your response. Please see below.

BR,
Mohana

> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf =
Of
> Klaus Hartke
> Sent: Friday, October 29, 2010 12:41 AM
> To: core@ietf.org
> Subject: Re: [core] Comments on draft-ietf-core-observe-00
>=20
> Mohana Jeyatharan wrote:
> > is the remaining lifetime value carried in the subscription lifetime
> > option?
>=20
> Yes.
>=20
> > In section 2.2(Notification), I don't see why the remaining lifetime
> > value is sent in the notification messages. If the server decides to
> > change lifetime then such an option can be sent. Otherwsie I don't =
see
> > the need for remaining lifetime value in notify messages. Thus I =
don't
> > understand the need for a MUST in your draft for the remaining
> > lifetime value.
>=20
> The default value of the Subscription-Lifetime Option is 0 seconds. So =
if
a
> notification message does not contain the Subscription-Lifetime =
Option,
this
> means that the server ended the subscription and the client needs to
> resubscribe if it wants to continue observing the resource.

Ok, so since there is a default value defined and if subscription life =
time
option is not sent, then the=20
client will interpret at the end of subsciption. Ok understood. So, in =
that
case the subscription lifetime option
needs to be sent, otherwise client will not process the notify messages.

> Also, the remaining lifetime can be used to detect if notification
messages
> got reordered, although this hasn't been formalized yet.

This part I am not very clear. I was thinking transaction ID can solve =
this
re-ordering issue.
Because in the draft every new notification is using a incremental
transaction ID.

> > Also one more question on Open issues. It is mentioned that mapping
> > will be highlighted as to how to map to HTTP bi-directional =
mechanisms
> > Why mapping specific to long polling, streaming and web socket being
> > considered. =A0Isn't there a case the observe mechanism interworks =
with
> > normal HTTP.
>=20
> As I said elsewhere, I believe the way to map CoAP-observe to HTTP is =
by
> defining a method to observe resources in HTTP, and then define how to
> translate between the two methods.


So are you saying a new method in CoAP has to be designed to solve this
observing HTTP resources?
Currently CoAP does not have a method for this..
Not very clear on this.=20

> There are lots of possibilities how to observe resources in HTTP. Long
polling,
> eventsource and web sockets are just what I have at the top of my =
head.
> Wikipedia lists several approaches to push data from a web server to a =
web
> browser [1,2]. And, of course, it's also possible to explore =
approaches
for
> scenarios that are not restricted to a web browser talking to a web =
server
> (e.g., subscribing call-back URIs to a resource if both parties act as =
an
HTTP
> server). All these approaches have different properties; none of it =
was
really
> designed for observing resources. So it should be evaluated which is =
the
best
> fit.
> It might even make sense to define more than one mapping.
>=20
> Klaus
>=20
>=20
> [1] http://en.wikipedia.org/wiki/Comet_(programming)
> [2] http://en.wikipedia.org/wiki/Push_technology
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From zach@sensinode.com  Fri Oct 29 00:39:44 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669763A6A12 for ; Fri, 29 Oct 2010 00:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.378
X-Spam-Level: 
X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.221,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gXEojjM5ZHV for ; Fri, 29 Oct 2010 00:39:42 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 979833A6A21 for ; Fri, 29 Oct 2010 00:39:41 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9T7fTpI001169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Oct 2010 10:41:32 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-64-793245777; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: <006601cb773c$5a489380$0ed9ba80$@sg.panasonic.com>
Date: Fri, 29 Oct 2010 10:41:30 +0300
Message-Id: <8847A643-F6CA-4797-9438-2DE169C6817D@sensinode.com>
References: <5F09D220B62F79418461A978CA0921BD04744711@pslexc01.psl.local>  <006601cb773c$5a489380$0ed9ba80$@sg.panasonic.com>
To: "mohana Jeyatharan" 
X-Mailer: Apple Mail (2.1081)
Cc: core@ietf.org, 'Klaus Hartke' 
Subject: Re: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 07:39:44 -0000

--Apple-Mail-64-793245777
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 29, 2010, at 10:38 AM, mohana Jeyatharan wrote:

>> Also, the remaining lifetime can be used to detect if notification
> messages
>> got reordered, although this hasn't been formalized yet.
>=20
> This part I am not very clear. I was thinking transaction ID can solve =
this
> re-ordering issue.
> Because in the draft every new notification is using a incremental
> transaction ID.

You can't assume that. TIDs may very well be implemented to change =
randomly or decrease linearly...=20

Klaus has an interesting point, although that might not be the most =
reliable way to do it (what if your CoAP implementation automatically =
updates the subscription lifetime, but some application doesn't realize =
it?). I usually recommend the payload data to include a sequence number =
or timestamp if this is important.=20

Zach

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


--Apple-Mail-64-793245777
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTA3NDEz
MVowIwYJKoZIhvcNAQkEMRYEFCmJ28yG2sGX8d908T/0xQPV3ywgMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAKlL7k9MpecPv2KZsiw028+Oi/MAeQQRrQfe7U/Y39JPgOufkswrp1cS
1LccfIczH7W9cJGQrf9hy28Peopup1Bym7XX8h1J3MF4v/Xoi5TNR2GcjLUXEd1RpRtkOKRn4+DA
h4yBhFsX/YDIylkG7n6CABG8rW6KwWAa+6alErk4+Et1vcbVRz2xrnBEYx9OW6aC6BuHfgp9zETd
u8GG5dMkOpKHWANXBJNTu31YIOfa4vaRXg8AwU2Qd/X4Ln+f+glKazG0TDZZDSA1iS5bK4V9tDmG
seusFuZXGLRPss3GtFm7/vDEPqbMqXZUxV7j6S3D3xJpptMoMpmpY4ilHvQAAAAAAAA=

--Apple-Mail-64-793245777--

From zach@sensinode.com  Fri Oct 29 00:51:18 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CCF3A6A30 for ; Fri, 29 Oct 2010 00:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.382
X-Spam-Level: 
X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg7FHP3ltz8L for ; Fri, 29 Oct 2010 00:51:16 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EBA823A6A1E for ; Fri, 29 Oct 2010 00:51:15 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9T7r5ei002938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Oct 2010 10:53:06 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-65-793941009; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: <006601cb773c$5a489380$0ed9ba80$@sg.panasonic.com>
Date: Fri, 29 Oct 2010 10:53:06 +0300
Message-Id: 
References: <5F09D220B62F79418461A978CA0921BD04744711@pslexc01.psl.local>  <006601cb773c$5a489380$0ed9ba80$@sg.panasonic.com>
To: "mohana Jeyatharan" 
X-Mailer: Apple Mail (2.1081)
Cc: core@ietf.org, 'Klaus Hartke' 
Subject: Re: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 07:51:18 -0000

--Apple-Mail-65-793941009
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 29, 2010, at 10:38 AM, mohana Jeyatharan wrote:

>> As I said elsewhere, I believe the way to map CoAP-observe to HTTP is =
by
>> defining a method to observe resources in HTTP, and then define how =
to
>> translate between the two methods.
>=20
>=20
> So are you saying a new method in CoAP has to be designed to solve =
this
> observing HTTP resources?
> Currently CoAP does not have a method for this..
> Not very clear on this.=20

What Klaus meant was that CoAP already solve this problem at the =
transfer protocol level. As HTTP doesn't support this model at all =
without gluing some design pattern on top of HTTP (and there is no =
one-size-fits all solution there!), it is up to e.g. the HTTP proxy to =
provide access to the CoAP resource using any number of HTTP solutions, =
which are summarized nicely here:=20

>=20
>> There are lots of possibilities how to observe resources in HTTP. =
Long
> polling,
>> eventsource and web sockets are just what I have at the top of my =
head.
>> Wikipedia lists several approaches to push data from a web server to =
a web
>> browser [1,2]. And, of course, it's also possible to explore =
approaches
> for
>> scenarios that are not restricted to a web browser talking to a web =
server
>> (e.g., subscribing call-back URIs to a resource if both parties act =
as an
> HTTP
>> server). All these approaches have different properties; none of it =
was
> really
>> designed for observing resources. So it should be evaluated which is =
the
> best
>> fit.
>> It might even make sense to define more than one mapping.


I totally agree with this analysis.=20

After implementing several CoAP to HTTP proxies, it has only become =
clearer that on the HTTP side there must be multiple ways provided to =
access resources. I find the built-in coap-observe extension ideal for a =
proxy to keep its cached CoAP representations fresh, and for this use =
case the URI is the best way to identify the notifications (Token =
requires unnecessary state). Once the resource is cached, it can be =
provided to HTTP clients in any number of ways, and the same resource =
could be made available to multiple HTTP push mechanisms simultaneously. =
I am not even convinced that we need to define any mappings for observe =
(although examples would be nice). It is enough that CoAP has mechanisms =
that a proxy can use to retrieve CoAP resources, and observe is a really =
useful one. =20

Zach

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


--Apple-Mail-65-793941009
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTA3NTMw
NlowIwYJKoZIhvcNAQkEMRYEFHgtLJPifE7Y4miQ7YnH5PYO/4E9MIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAJASe/NTbFWhaFiaVykLnaGIq09VUF5AkqbyYhcPuavnEFqT+bwkTZdX
EAmOjFOWFFYh+J3RfDuY3+npyQkr+9a9d11Kr4kW/P7KzPJCIkntM9gJ+mg0QuAOVoDfBn4qlUVR
xVjl4qB/pdQLbg+SoL7AZ9u4cMq6V6XptLLO0zm4doAHfHE/tpAEQinEL3Nb4Z1rJh62Xl/eeMb8
fjomc5jk/sZPZ2rCWsdLBG/O4sBleL2yxRB1plHD14uBfQwjBvkX4551PXXOndZWG+TgPXzTXnd+
0YWjPw+9JGwJOSCgqYM6wutEPJduQOFyUJdA0RvJZZM9wv9wyOsra9OQNq4AAAAAAAA=

--Apple-Mail-65-793941009--

From salvatore.loreto@ericsson.com  Fri Oct 29 01:05:27 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F3C3A6A15 for ; Fri, 29 Oct 2010 01:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.874
X-Spam-Level: 
X-Spam-Status: No, score=-105.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygvEd5EYAaHz for ; Fri, 29 Oct 2010 01:05:11 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 880313A6822 for ; Fri, 29 Oct 2010 01:04:56 -0700 (PDT)
X-AuditID: c1b4fb39-b7b54ae000003464-10-4cca8099361c
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 42.F2.13412.9908ACC4; Fri, 29 Oct 2010 10:06:49 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Oct 2010 10:05:48 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Oct 2010 10:05:47 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 446C5251F for ; Fri, 29 Oct 2010 11:05:47 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0E32E5013D for ; Fri, 29 Oct 2010 11:05:47 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B463B4FEAE for ; Fri, 29 Oct 2010 11:05:46 +0300 (EEST)
Message-ID: <4CCA805A.1030806@ericsson.com>
Date: Fri, 29 Oct 2010 11:05:46 +0300
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: core@ietf.org
References: <5F09D220B62F79418461A978CA0921BD04744711@pslexc01.psl.local>		<006601cb773c$5a489380$0ed9ba80$@sg.panasonic.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 29 Oct 2010 08:05:47.0732 (UTC) FILETIME=[182BB140:01CB7740]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [core] Comments on draft-ietf-core-observe-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 08:05:27 -0000

On 10/29/10 10:53 AM, Zach Shelby wrote:
> On Oct 29, 2010, at 10:38 AM, mohana Jeyatharan wrote:
>
>>> As I said elsewhere, I believe the way to map CoAP-observe to HTTP is by
>>> defining a method to observe resources in HTTP, and then define how to
>>> translate between the two methods.
>>
>> So are you saying a new method in CoAP has to be designed to solve this
>> observing HTTP resources?
>> Currently CoAP does not have a method for this..
>> Not very clear on this.
> What Klaus meant was that CoAP already solve this problem at the transfer protocol level. As HTTP doesn't support this model at all without gluing some design pattern on top of HTTP (and there is no one-size-fits all solution there!), it is up to e.g. the HTTP proxy to provide access to the CoAP resource using any number of HTTP solutions, which are summarized nicely here:
>
>>> There are lots of possibilities how to observe resources in HTTP. Long
>> polling,
>>> eventsource and web sockets are just what I have at the top of my head.
>>> Wikipedia lists several approaches to push data from a web server to a web
>>> browser [1,2]. And, of course, it's also possible to explore approaches
>> for
>>> scenarios that are not restricted to a web browser talking to a web server
>>> (e.g., subscribing call-back URIs to a resource if both parties act as an
>> HTTP
>>> server). All these approaches have different properties; none of it was
>> really
>>> designed for observing resources. So it should be evaluated which is the
>> best
>>> fit.
>>> It might even make sense to define more than one mapping.
>
> I totally agree with this analysis.
>
> After implementing several CoAP to HTTP proxies, it has only become clearer that on the HTTP side there must be multiple ways provided to access resources. I find the built-in coap-observe extension ideal for a proxy to keep its cached CoAP representations fresh, and for this use case the URI is the best way to identify the notifications (Token requires unnecessary state). Once the resource is cached, it can be provided to HTTP clients in any number of ways, and the same resource could be made available to multiple HTTP push mechanisms simultaneously. I am not even convinced that we need to define any mappings for observe (although examples would be nice). It is enough that CoAP has mechanisms that a proxy can use to retrieve CoAP resources, and observe is a really useful one.
it really depends on which HTTP bidirectional technique you are going to 
use.
For HTTP long polling I am not convinced neither there is any need to 
define mapping for observe.

However for WebSocket (HyBi wg) there is a need to specify an usage for 
CoAP as you may want use WebSocket not only to receive notification/observe
but also to send other kind of CoAP requests.

cheers
/Sal


> Zach
>


-- 
Salvatore Loreto
www.sloreto.com


From matthieu.vial@fr.non.schneider-electric.com  Fri Oct 29 01:09:00 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56713A683B; Fri, 29 Oct 2010 01:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level: 
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.044,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afvoZRnzao3L; Fri, 29 Oct 2010 01:08:58 -0700 (PDT)
Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id D67323A686E; Fri, 29 Oct 2010 01:08:57 -0700 (PDT)
Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2010102909573544-42484 ; Fri, 29 Oct 2010 09:57:35 +0200 
In-Reply-To: 
To: Zach Shelby 
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: matthieu.vial@fr.non.schneider-electric.com
Date: Fri, 29 Oct 2010 10:10:46 +0200
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 29/10/2010 10:10:36, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 29/10/2010 09:57:35, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 29/10/2010 09:57:36
Content-type: multipart/mixed;  Boundary="0__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668"
Cc: core-bounces@ietf.org, core , Klaus Hartke 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 08:09:00 -0000

--0__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668
Content-type: multipart/related; 
	Boundary="1__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668"

--1__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668
Content-type: multipart/alternative; 
	Boundary="2__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668"

--2__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668
Content-transfer-encoding: quoted-printable
Content-type: text/plain; charset=ISO-8859-1




>>
>> 3.2.
>> Would it make sense to expand table 2 with a column that indicates i=
f
>> the option can occur in a request, in a response or in both?

>We had that before. But it turns out that most of these can occur in
either one. Exceptions? Does Location ever occur in a request?

Now that we have the Token option to relate a response to a request do =
we
really need the URI-Path option in a response? If not we could merge
Location and URI-Path into one option or keep it as separate option but=

cleary specify in a table if they can be present in requests or respons=
es.
This would help to reduce the size of the option set for requests and
responses.

Regards,
Matthieu






                                                                       =
    
             Zach Shelby                                               =
    
                                                                    =
  A 
             Envoy=E9 par :              Klaus Hartke  =
      
             core-bounces@ietf                                         =
 cc 
             .org                      core             =
    
                                                                     Ob=
jet 
                                       Re: [core] Comments on          =
    
             29/10/2010 09:34          draft-ietf-core-coap-03         =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    




Thanks Klaus for the detailed review. I start to miss some of these det=
ails
from knowing the text too well. Some comments in-line, my goal is to tu=
rn
the key points you brought up into tickets.

On Oct 28, 2010, at 10:11 PM, Klaus Hartke wrote:

> Just some random things I noted while reading coap-03:
>
>
> 2.1.1.
> The figure suggests that the payload of a 4xx/5xx response is a
> human-readable diagnostic message (here: "Not found"). This doesn't
> seem to be defined anywhere, although I'd love if it was. (For
> example, my CoAP server includes a complete stack trace in a 500
> response when an exception is thrown and it's in debug mode. This
> helps remote debugging a lot.)

We could do that, I guess it would go into Section 11.1 where codes are=

defined in general?

>
> 2.1.1.
> It's somewhat unclear to me from this section how ACKs and responses
> relate to each other. Maybe it makes sense to explain asynchronous
> responses first and present synchronous responses as optimization?

OK, we need to play with the organization. I am not totally sure changi=
ng
that order would help though, as asynchronous responses should be an
exception.

>
> 2.1.1.
> This sections talks about the interaction between Req/Res and
> Transaction layers, but section 2.1. is about the Interaction Model
> between CoAP end-points.

Maybe Section 2.1 needs to be re-named? Or we could split the section
differently:

2.1. Transaction Model
2.1.1. Reliable Transaction
2.1.2. Unreliable Transaction
2.1.3. Transaction Messages

2.2. Request/Response Model
2.2.1. Synchronous Responses
2.2.2. Asynchronous Responses
2.2.3. Methods
2.2.4. Codes

2.3. Options

>
> 2.1.2.
> "Since no Token Option was included" - A Token Option is clearly
> present in figure 3, no?

Oops. That's what I get trying to hack the old example text. Needs to b=
e
fixed.

>
> 2.1.2.
> Why does the server deny to answer the request if a client decides no=
t
> to include a token? If the client can relate the asynchronous respons=
e
> to its request without a token, it's not the responsibility of the
> server to tell the client it cannot.

See the thread continued by peter on this. We had this discussion when
deciding on including the Token option.

>
> 2.1.2.
> Given the current wording, it seems much simpler to me to let an
> implementation simply always include a token in a request, instead of=

> hoping for a synchronous response and retrying in case of an
> asynchronous one. After a successful request, the client cannot even
> cache if it needs to include a token or not, because the same request=

> to the same resource may or may not yield an asynchronous response at=

> a later point of time.

The purpose of this was to give the client some control whether it want=
s an
asynchronous response in the first place. The draft does not prevent yo=
u
always including a token if your client likes. But maybe this would nee=
d
better explanation in the text anyways.

>
> 2.1.3.
> Section 2.1. says that transaction messages enable optional
> reliability, and sections 2.1.1. and 2.1.2. describe reliable
> requests, but no section talks about unreliable interactions. (The
> only place where non-confirmable messages are mentioned is in section=

> 4.1. "Multicast messages SHOULD be Non-Confirmable.")

Good point, see my outline suggestion above... we should add a subsecti=
on
on that.

>
> 2.3.2.
> The section suggests that the only possible interpretation of POST is=

> to create a new subordinate resource on the server. Is this the case?=

> If yes, rename POST to CREATE?

Kerry Lynn suggested an improvement on the text for -03. Sorry I was in=
 too
much of a hurry submitting -03 to synchronize this with RFC2616. Did th=
is
break something?

> 2.5.1.
> "including a copy of the critical option number in the payload of the=

> response." - in what format? I'd assume it's a variable-length
> unsigned integer, but the section doesn't say. I'd also still prefer
> to reserve the payload of error responses for human-readable messages=

> (utf-8 string, software must attribute no meaning to message).

I was thinking this would be text/plain. This relates to your earlier
comment in general about the payload of error messages.

>
> 3.2.
> Table 2 lists the Token Option with a length of 1-2 B. That prevents =
a
> lot of interesting usage cases wrt statelessness. What's the reasonin=
g
> to limit a token to 1-2 B?

I take responsibility for this one. Let's ask the question the other wa=
y
around. Why do you need more than 64k token possibilities? Overhead was=
 my
reasoning, especially if you are including this token quite often. The
problem is, constrained nodes will be forced to process or even store m=
ost
options. On some architectures this might force a node to reserve space=
 for
the largest possible option length. So I would like to avoid having all=

options be up to 4 bytes.

>
> 3.2.
> Table 2 lists the Max-age Option with a length of 1-4 B and a default=

> value of 60 seconds. Why not allow a value of 0 seconds to be
> expressed with 0 bytes?

Good idea.

>
> 3.2.
> The format of a variable-length unsigned identifier isn't defined
anywhere.

We had that before, but many people commented that it is not necessary.=
 I
guess we should have some text defining this.

>
> 3.2.8.
> It is sufficient if token values are unique in use per server.

Per client? The token is generated and matched by the client.

>
> 3.2.8.
> "If a Token Option is included in a request, the response (and
> any		 subsequent delayed responses) MUST include the same value in a
> Token Option." - section 2.1.1. says that Token can be omitted from
> synchronous responses.

Hmmm.. that should be fixed. The idea is that if a token is included by=
 the
client, it MUST be included in the response (synchronous or asynchronou=
s).

>
> 3.2.8.
> "If a Token Option is included in a request, any resulting delayed
> response SHOULD NOT include the URI option" - nothing in coap-03
> encourages to ever include URI-related options in a response, or does=

> it?

Oops, left over from an older version. I would still like to leave the =
URI
as an option for observe notifications, but that is for the observe dra=
ft.

>
> 3.2.
> Would it make sense to expand table 2 with a column that indicates if=

> the option can occur in a request, in a response or in both?

We had that before. But it turns out that most of these can occur in ei=
ther
one. Exceptions? Does Location ever occur in a request?

> 4.2.
> Should retransmits of responses transmit the current state of
> resource, rather than a snapshot of the state at the time of the firs=
t
> attempt?

Made a ticket on this.

Cheers,
Zach

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

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


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________(=
See
attached file: smime.p7s)______________________________________________=
_
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
=

--2__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668
Content-transfer-encoding: quoted-printable
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline



>> 

>> 3.2.

>> Would it make sense to expand table 2 with a column that indic=
ates if

>> the option can occur in a request, in a response or in both?


>We had that before. But it turns out that most of these can occur i=
n either one. Exceptions? Does Location ever occur in a request?



Now that we have the Token option to relate a response to a request=
 do we really need the URI-Path option in a response? If not we could m=
erge Location and URI-Path into one option or keep it as separate optio=
n but cleary specify in a table if they can be present in requests or r=
esponses. This would help to reduce the size of the option set for requ=
ests and responses.



Regards,

Matthieu





3D"InactiveZach Shelby <zach@sensinode.com>










=




    

      

        

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

          29/10/2010 09:34
        

      

    



=


3D""


A
3D""

Klaus Hartke <hartke@tzi.org>



3D""


cc
3D""

core <core@ietf.org>



3D""


Objet
3D""

Re: [core] Comments on draft-ietf-core-coap-03<=
/td>







3D""3D=









Thanks Klaus for the detailed review. I start to miss some of these=
 details from knowing the text too well. Some comments in-line, my goal=
 is to turn the key points you brought up into tickets. 



On Oct 28, 2010, at 10:11 PM, Klaus Hartke wrote:



> Just some random things I noted while reading coap-03:

> 

> 

> 2.1.1.

> The figure suggests that the payload of a 4xx/5xx response is a
> human-readable diagnostic message (here: "Not found"). T=
his doesn't

> seem to be defined anywhere, although I'd love if it was. (For
=

> example, my CoAP server includes a complete stack trace in a 500
> response when an exception is thrown and it's in debug mode. This<=
br>
> helps remote debugging a lot.)



We could do that, I guess it would go into Section 11.1 where codes are=
 defined in general?



> 

> 2.1.1.

> It's somewhat unclear to me from this section how ACKs and respons=
es

> relate to each other. Maybe it makes sense to explain asynchronous=


> responses first and present synchronous responses as optimization?=




OK, we need to play with the organization. I am not totally sure changi=
ng that order would help though, as asynchronous responses should be an=
 exception.



> 

> 2.1.1.

> This sections talks about the interaction between Req/Res and

> Transaction layers, but section 2.1. is about the Interaction Mode=
l

> between CoAP end-points.



Maybe Section 2.1 needs to be re-named? Or we could split the section d=
ifferently:



2.1. Transaction Model

2.1.1. Reliable Transaction

2.1.2. Unreliable Transaction

2.1.3. Transaction Messages



2.2. Request/Response Model

2.2.1. Synchronous Responses

2.2.2. Asynchronous Responses

2.2.3. Methods

2.2.4. Codes



2.3. Options



> 

> 2.1.2.

> "Since no Token Option was included" - A Token Option is=
 clearly

> present in figure 3, no?



Oops. That's what I get trying to hack the old example text. Needs to b=
e fixed.



> 

> 2.1.2.

> Why does the server deny to answer the request if a client decides=
 not

> to include a token? If the client can relate the asynchronous resp=
onse

> to its request without a token, it's not the responsibility of the=


> server to tell the client it cannot.



See the thread continued by peter on this. We had this discussion when =
deciding on including the Token option.



> 

> 2.1.2.

> Given the current wording, it seems much simpler to me to let an
> implementation simply always include a token in a request, instead=
 of

> hoping for a synchronous response and retrying in case of an

> asynchronous one. After a successful request, the client cannot ev=
en

> cache if it needs to include a token or not, because the same requ=
est

> to the same resource may or may not yield an asynchronous response=
 at

> a later point of time.



The purpose of this was to give the client some control whether it want=
s an asynchronous response in the first place. The draft does not preve=
nt you always including a token if your client likes. But maybe this wo=
uld need better explanation in the text anyways. 



> 

> 2.1.3.

> Section 2.1. says that transaction messages enable optional

> reliability, and sections 2.1.1. and 2.1.2. describe reliable

> requests, but no section talks about unreliable interactions. (The=


> only place where non-confirmable messages are mentioned is in sect=
ion

> 4.1. "Multicast messages SHOULD be Non-Confirmable.")


Good point, see my outline suggestion above... we should add a subsecti=
on on that.



> 

> 2.3.2.

> The section suggests that the only possible interpretation of POST=
 is

> to create a new subordinate resource on the server. Is this the ca=
se?

> If yes, rename POST to CREATE?



Kerry Lynn suggested an improvement on the text for -03. Sorry I was in=
 too much of a hurry submitting -03 to synchronize this with RFC2616. D=
id this break something? 



> 2.5.1.

> "including a copy of the critical option number in the payloa=
d of the

> response." - in what format? I'd assume it's a variable-lengt=
h

> unsigned integer, but the section doesn't say. I'd also still pref=
er

> to reserve the payload of error responses for human-readable messa=
ges

> (utf-8 string, software must attribute no meaning to message).
=



I was thinking this would be text/plain. This relates to your earlier c=
omment in general about the payload of error messages.



> 

> 3.2.

> Table 2 lists the Token Option with a length of 1-2 B. That preven=
ts a

> lot of interesting usage cases wrt statelessness. What's the reaso=
ning

> to limit a token to 1-2 B?



I take responsibility for this one. Let's ask the question the other wa=
y around. Why do you need more than 64k token possibilities? Overhead w=
as my reasoning, especially if you are including this token quite often=
. The problem is, constrained nodes will be forced to process or even s=
tore most options. On some architectures this might force a node to res=
erve space for the largest possible option length. So I would like to a=
void having all options be up to 4 bytes. 



> 

> 3.2.

> Table 2 lists the Max-age Option with a length of 1-4 B and a defa=
ult

> value of 60 seconds. Why not allow a value of 0 seconds to be

> expressed with 0 bytes?



Good idea.



> 

> 3.2.

> The format of a variable-length unsigned identifier isn't defined =
anywhere.



We had that before, but many people commented that it is not necessary.=
 I guess we should have some text defining this. 



> 

> 3.2.8.

> It is sufficient if token values are unique in use per server.
=



Per client? The token is generated and matched by the client. 



> 

> 3.2.8.

> "If a Token Option is included in a request, the response (an=
d

> any		 subsequent delayed responses) MUST include the same value in=
 a

> Token Option." - section 2.1.1. says that Token can be omitte=
d from

> synchronous responses.



Hmmm.. that should be fixed. The idea is that if a token is included by=
 the client, it MUST be included in the response (synchronous or asynch=
ronous).



> 

> 3.2.8.

> "If a Token Option is included in a request, any resulting de=
layed

> response SHOULD NOT include the URI option" - nothing in coap=
-03

> encourages to ever include URI-related options in a response, or d=
oes

> it?



Oops, left over from an older version. I would still like to leave the =
URI as an option for observe notifications, but that is for the observe=
 draft. 



> 

> 3.2.

> Would it make sense to expand table 2 with a column that indicates=
 if

> the option can occur in a request, in a response or in both?



We had that before. But it turns out that most of these can occur in ei=
ther one. Exceptions? Does Location ever occur in a request?



> 4.2.

> Should retransmits of responses transmit the current state of

> resource, rather than a snapshot of the state at the time of the f=
irst

> attempt?



Made a ticket on this.



Cheers,

Zach



> 

> 

> Klaus

> _______________________________________________

> core mailing list

> core@ietf.org

> ht=
tps://www.ietf.org/mailman/listinfo/core



-- 

Zach Shelby, Chief Nerd, Sensinode Ltd.

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

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

Mobile: +358 40 7796297





______________________________________________________________________<=
br>
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________<=
/tt>(See attached file: smime.p7s)__________________________=
_____________________

core mailing list

core@ietf.org

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



=


--2__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668--


--1__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668
Content-type: image/gif; 
	name="pic19169.gif"
Content-Disposition: inline; filename="pic19169.gif"
Content-ID: <2__=4EBBFD58DFBFA6688@Schneider-Electric.com>
Content-Transfer-Encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==


--1__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668--


--0__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668
Content-type: application/octet-stream; 
	name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-ID: <1__=4EBBFD58DFBFA6688@Schneider-Electric.com>
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTA3MzQw
M1owIwYJKoZIhvcNAQkEMRYEFAM7vf6nW8cwLhhgkYzRGxPLIs6DMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBACOyG6NQos/oTfhsIXuREjQW/KG1zQqJf3hruCCBYn+spx3ommyYYxV4
/PnwDkkpYnR+8InNND9g3xVJw5yNPuERcjxAKvYVl8BKBZGAXNWsAXUBqBfDi61w700hPEFI+vrc
oRHn+IG+zU6wy6vJZQDDH57jM7uVoXnTd9wbAmhznjYkXCPNibbWb4eMNCrq5VQBUFC+Z+GqxZOj
dOHsN/RUXH9I1E1Z8CX+sS2HgZ49QVqQIEU5whOmT2a3XleekpztVoXkjI48UOSIZB1RnT5USDh9
rQWA6+fvKmldWt7MDwerBzbIjR8ndjgyj84gz8DSMpsxQxf8ginz2nPeuu0AAAAAAAA=


--0__=4EBBFD58DFBFA6688f9e8a93df938690918c4EBBFD58DFBFA668--


From zach@sensinode.com  Fri Oct 29 01:32:40 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBAFB3A6807; Fri, 29 Oct 2010 01:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level: 
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.213,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD+M8hPNUMtq; Fri, 29 Oct 2010 01:32:39 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 48D843A67D1; Fri, 29 Oct 2010 01:32:38 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9T8YRwN008536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Oct 2010 11:34:28 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-70-796423663; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Fri, 29 Oct 2010 11:34:28 +0300
Message-Id: <0C63B3B2-168D-47E0-9E9F-B08F16756C42@sensinode.com>
References: 
To: matthieu.vial@fr.non.schneider-electric.com
X-Mailer: Apple Mail (2.1081)
Cc: core-bounces@ietf.org, core , Klaus Hartke 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 08:32:41 -0000

--Apple-Mail-70-796423663
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 29, 2010, at 11:10 AM, =
matthieu.vial@fr.non.schneider-electric.com wrote:

> >>=20
> >> 3.2.
> >> Would it make sense to expand table 2 with a column that indicates =
if
> >> the option can occur in a request, in a response or in both?
>=20
> >We had that before. But it turns out that most of these can occur in =
either one. Exceptions? Does Location ever occur in a request?
>=20
> Now that we have the Token option to relate a response to a request do =
we really need the URI-Path option in a response? If not we could merge =
Location and URI-Path into one option or keep it as separate option but =
cleary specify in a table if they can be present in requests or =
responses. This would help to reduce the size of the option set for =
requests and responses.

Interesting idea. Although Uri-Path is not needed in a normal response, =
it is useful in coap-observe, so I would not like to disallow it. =
However, Location could maybe be used for the same purpose I have in =
mind. Personally, I wouldn't have a problem with combining them either. =
So in a response Uri-Path would serve the same function as Location in a =
response to a POST, and in coap-observe it would indicate the resource =
the notification is about.=20

Zach=20

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


--Apple-Mail-70-796423663
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTA4MzQy
OVowIwYJKoZIhvcNAQkEMRYEFAk+ZtPkysRrtNhCrbf0JArHRrnTMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAIGN0LONUmvoy+kqtgDzojOyc+diOtvzyHjMW5ArEKEs7jARN3sxri8S
Fs11eQh9X+oev/OJz+KzOXuNDvR4wwzucyKTj/yyvSEgtzs7yTs0JwBfmSdc3ExWV67gOOtBVA9F
ki0Mh1Mw2gLGZHfbzFk2kpXvF93fYIw3k0KesfGVEbbYgjqhYRBalBOPkBEZuIVtezQDIwf2cUUg
m4fwO6KyWB0zNpFSw7IOiSyHnz0RdcPS0UO/OTFPbSSbUZd2xIV2eh7zfDmzyvewxmcIpwOXGI+r
FhGsS9zZoswv5mqmmDXOAtm4LZ1dJ2ThSbKgSGzNzkYPpwFTJvPhqDe8iUYAAAAAAAA=

--Apple-Mail-70-796423663--

From matthieu.vial@fr.non.schneider-electric.com  Fri Oct 29 02:02:04 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF41B3A6845; Fri, 29 Oct 2010 02:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.145
X-Spam-Level: 
X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ob36615K7+V; Fri, 29 Oct 2010 02:02:03 -0700 (PDT)
Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id E04CC3A67C3; Fri, 29 Oct 2010 02:02:02 -0700 (PDT)
Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2010102910455029-83712 ; Fri, 29 Oct 2010 10:45:50 +0200 
In-Reply-To: 
To: Zach Shelby 
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: matthieu.vial@fr.non.schneider-electric.com
Date: Fri, 29 Oct 2010 11:03:53 +0200
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 29/10/2010 11:03:41, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 29/10/2010 10:45:50, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 29/10/2010 10:45:51
Content-type: multipart/mixed;  Boundary="0__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923"
Cc: core-bounces@ietf.org, core , Klaus Hartke 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 09:02:05 -0000

--0__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923
Content-type: multipart/related; 
	Boundary="1__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923"

--1__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923
Content-type: multipart/alternative; 
	Boundary="2__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923"

--2__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923
Content-transfer-encoding: quoted-printable
Content-type: text/plain; charset=ISO-8859-1




>Sure, we should at least describe this better in the draft. My own
assumption has been that a retransmitted request is equivalent (if not
>identical) to the original request. Implementation wise, this is usual=
ly
handled at the transaction layer, where you tend to keep a copy of the
>buffer. I definitely don't recommend sending a different version of th=
e
resource representation for each retransmission.... I'll open up a tick=
et
>on this.

In section 2.2 of coap-observe one can read:
If a confirmable notification requires a
   retransmission, it is RECOMMENDED to send the state that is current
   at the instant of the retransmission;

As I understand this sentence the representation can change for each
retransmission of the transaction. Like Carsten I think it can be much =
more
memory efficient in many use cases so I would recommend a MAY.

Regards,
Matthieu






                                                                       =
    
             Zach Shelby                                               =
    
                                                                    =
  A 
             Envoy=E9 par :              Peter Bigot  
             core-bounces@ietf                                         =
 cc 
             .org                      Klaus Hartke , c=
ore 
                                                        =
    
                                                                     Ob=
jet 
             29/10/2010 08:56          Re: [core] Comments on          =
    
                                       draft-ietf-core-coap-03         =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    




On Oct 29, 2010, at 12:30 AM, Peter Bigot wrote:

> In any case, since there's no initial unanimity, whether or not this =
is
allowed should be explicit with either a MAY or a MUST NOT clause.


Sure, we should at least describe this better in the draft. My own
assumption has been that a retransmitted request is equivalent (if not
identical) to the original request. Implementation wise, this is usuall=
y
handled at the transaction layer, where you tend to keep a copy of the
buffer. I definitely don't recommend sending a different version of the=

resource representation for each retransmission.... I'll open up a tick=
et
on this.

Zach

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


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________(=
See
attached file: smime.p7s)______________________________________________=
_
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
=

--2__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923
Content-transfer-encoding: quoted-printable
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline



>Sure, we should at least describe this better in the draft. My o=
wn assumption has been that a retransmitted request is equivalent (if n=
ot >identical) to the original request. Implementation wise, this is=
 usually handled at the transaction layer, where you tend to keep a cop=
y of the >buffer. I definitely don't recommend sending a different v=
ersion of the resource representation for each retransmission.... I'll =
open up a ticket >on this.



In section 2.2 of coap-observe one can read:

If a confirmable notification requires a

   retransmission, it is RECOMMENDED to send the state that is current<=
br>
   at the instant of the retransmission; 



As I understand this sentence the representation can change for each re=
transmission of the transaction. Like Carsten I think it can be much mo=
re memory efficient in many use cases so I would recommend a MAY.



Regards,

Matthieu





3D"InactiveZach Shelby <zach@sensinode.com>










=




    

      

        

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

          29/10/2010 08:56
        

      

    



=

<=
/tr>


3D""


A
3D""

Peter Bigot <pab@peoplepowerco.com>
3D""


cc
3D""

Klaus Hartke <hartke@tzi.org>, core <core@iet=
f.org>



3D""


Objet
3D""

Re: [core] Comments on draft-ietf-core-coap-03<=
/td>







3D""3D=









On Oct 29, 2010, at 12:30 AM, Peter Bigot wrote:



> In any case, since there's no initial unanimity, whether or not th=
is is allowed should be explicit with either a MAY or a MUST NOT clause=
.





Sure, we should at least describe this better in the draft. My own assu=
mption has been that a retransmitted request is equivalent (if not iden=
tical) to the original request. Implementation wise, this is usually ha=
ndled at the transaction layer, where you tend to keep a copy of the bu=
ffer. I definitely don't recommend sending a different version of the r=
esource representation for each retransmission.... I'll open up a ticke=
t on this.



Zach  



-- 

Zach Shelby, Chief Nerd, Sensinode Ltd.

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

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

Mobile: +358 40 7796297





______________________________________________________________________<=
br>
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________<=
/tt>(See attached file: smime.p7s)__________________________=
_____________________

core mailing list

core@ietf.org

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



=


--2__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923--


--1__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923
Content-type: image/gif; 
	name="pic32391.gif"
Content-Disposition: inline; filename="pic32391.gif"
Content-ID: <2__=4EBBFD58DFA2B9238@Schneider-Electric.com>
Content-Transfer-Encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==


--1__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923--


--0__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923
Content-type: application/octet-stream; 
	name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-ID: <1__=4EBBFD58DFA2B9238@Schneider-Electric.com>
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTA2NTYx
MVowIwYJKoZIhvcNAQkEMRYEFBMmlwufZnqUGO6oKg1eL52lGK4fMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAISq2NYCCP5eE1Lbf61a0txEp3Iv4852eSLtrA9Dru+lVwJDZsvlEBmB
3mzHbyJSj4xwfsmPZ9Kvmgs7DEB0kJtZNHrLpeM3KUUVndZ9UWxEQEZMq220w7qyrSQeOB69REYm
FMD+NYgSDHuQSgLMXyJ6FV4ULccvrtE2pXqXLxIdDDI77lAWJ97aQ6EKctkdMOT9+WmIsX57v7t+
wBcsmuEzkXDWO1i81ZEF5JouZGmyanAehSn9I+eFaQBRROvF9NFI3x1XGwd87SaK0x1ueC4HYxiz
fv5pAoE2u1DpCQkkFVWRfFLV6BFU89Yv1LKic6PYQItuTqWt1ss9OsyxGh4AAAAAAAA=


--0__=4EBBFD58DFA2B9238f9e8a93df938690918c4EBBFD58DFA2B923--


From cabo@tzi.org  Fri Oct 29 03:09:28 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EE93A6869 for ; Fri, 29 Oct 2010 03:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.186
X-Spam-Level: 
X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwyTeyioLQtp for ; Fri, 29 Oct 2010 03:09:22 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E50063A67AF for ; Fri, 29 Oct 2010 03:09:20 -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 o9TAB6LB014580; Fri, 29 Oct 2010 12:11:06 +0200 (CEST)
Received: from [192.168.1.29] (p548992F7.dip0.t-ipconnect.de [84.137.146.247]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 874CF70A; Fri, 29 Oct 2010 12:11:05 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Fri, 29 Oct 2010 12:11:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <80D4CF54-59BE-4AC7-8458-E4A42F91CF75@tzi.org>
References:  
To: Zach Shelby 
X-Mailer: Apple Mail (2.1081)
Cc: core , Klaus Hartke 
Subject: [core] POST (Re:  Comments on draft-ietf-core-coap-03)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 10:09:28 -0000

On Oct 29, 2010, at 09:34, Zach Shelby wrote:

>> 2.3.2.
>> The section suggests that the only possible interpretation of POST is
>> to create a new subordinate resource on the server. Is this the case?
>> If yes, rename POST to CREATE?
>=20
> Kerry Lynn suggested an improvement on the text for -03. Sorry I was =
in too much of a hurry submitting -03 to synchronize this with RFC2616. =
Did this break something?=20

In HTTP, POST pretty much means "send a message to a resource".

RFC 2616 9.5:
   The POST method is used to request that the origin server accept the
   entity enclosed in the request as a new subordinate of the =
resource...
   The actual function performed by the POST method is determined by the
   server and is usually dependent on the Request-URI....
   The action performed by the POST method might not result in a
   resource that can be identified by a URI...

CoAP-03 appears to be more specific in that it actually talks about =
requesting to create a new resource:
2.3.2:
   The POST method is used to request the server to create a new
   subordinate resource under the requested parent URI. =20

(The server then may go ahead and not actually do that and still return =
a 200 OK, which doesn't quite fit the language of the first sentence.)

By appeal to authority, Roy Fielding likes POST in HTTP's semantics:
http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
"It is okay to use POST =BB Untangled"

But maybe we do indeed want to have the more specific semantics.
With a bit more work, this might even enable us to make POST idempotent.
We need realistic usecases to make a well-founded decision.

Gruesse, Carsten


From pab@peoplepowerco.com  Fri Oct 29 04:14:40 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5823A6856 for ; Fri, 29 Oct 2010 04:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.719
X-Spam-Level: 
X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbqMuHQnnihx for ; Fri, 29 Oct 2010 04:14:39 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 68C253A6942 for ; Fri, 29 Oct 2010 04:14:39 -0700 (PDT)
Received: by fxm9 with SMTP id 9so3063869fxm.31 for ; Fri, 29 Oct 2010 04:16:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.101.194 with SMTP id d2mr5379418fao.88.1288350992578; Fri, 29 Oct 2010 04:16:32 -0700 (PDT)
Received: by 10.223.83.207 with HTTP; Fri, 29 Oct 2010 04:16:32 -0700 (PDT)
Date: Fri, 29 Oct 2010 06:16:32 -0500
Message-ID: 
From: Peter Bigot 
To: core 
Content-Type: multipart/alternative; boundary=20cf3054a4ad4237510493bf97f8
Subject: [core] What's to be presented to IESG in December?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 11:14:40 -0000

--20cf3054a4ad4237510493bf97f8
Content-Type: text/plain; charset=ISO-8859-1

Two items raise this question:

- The appearance in coap-03 of the option values associated with the drafts
for coap-observe and coap-block
- A reference by Zack to how coap-observe simplifies caching of updatable
values

To the WG chairs: is it your expectation that coap-observe and coap-block
will be submitted to IESG in December along with the core CoAP document?

Peter

--20cf3054a4ad4237510493bf97f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Two items raise this question:

- The appearance in coap-03 of the op=
tion values associated with the drafts for coap-observe and coap-block
-=
 A reference by Zack to how coap-observe simplifies caching of updatable va=
lues


To the WG chairs: is it your expectation that coap-observe and coap-blo=
ck will be submitted to IESG in December along with the core CoAP document?=


Peter




--20cf3054a4ad4237510493bf97f8--

From zach@sensinode.com  Fri Oct 29 04:26:14 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB7E3A6A37 for ; Fri, 29 Oct 2010 04:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.389
X-Spam-Level: 
X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTUXQ8I8d47K for ; Fri, 29 Oct 2010 04:26:13 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 19ED93A6A10 for ; Fri, 29 Oct 2010 04:26:12 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9TBS2RD014895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Oct 2010 14:28:03 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-89-806839382; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Fri, 29 Oct 2010 14:28:04 +0300
Message-Id: 
References: 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] What's to be presented to IESG in December?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 11:26:14 -0000

--Apple-Mail-89-806839382
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 29, 2010, at 2:16 PM, Peter Bigot wrote:

> - The appearance in coap-03 of the option values associated with the =
drafts for coap-observe and coap-block


To be clear, I did this only as a temporary placeholder for those option =
type IDs to prevent collisions with people working with experimental =
options in other drafts. It is not meant to be interpreted that =
core-block and core-observe need to go to the IESG at precisely the same =
time (nor that those table values even need to be in the CoAP RFC). Now =
that they are both WG documents I think this is helpful to list them in =
the coap option table for now.=20

In my personal opinion, it is most important that we concentrate on =
completing core-coap in December according to our charter. However, as =
core-block and core-observe are both part of the same charter work item, =
it would be a good goal to have them in stable shape at the same time. =
The chairs will surely give more information on the procedure.=20

Peter, it seems you are worried about future innovation around CoRE? I =
wouldn't be. coap-block and coap-observe are two optional mechanisms =
that can be used with CoAP to fulfill basic application requirements we =
have. After this charter is fulfilled, we'll have the opportunity to =
re-charter the WG and to work on new things. This is a really good WG in =
my opinion and people have already identified useful future work, so I =
think we definitely should aim at re-chartering.=20

Zach

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


--Apple-Mail-89-806839382
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTExMjgw
NVowIwYJKoZIhvcNAQkEMRYEFDqD2VinXh7OyissglxWyvQS3FayMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAEJ6X6+xiN00f4tOCv9Ty6zuvOi8kzs/0xkPvOsul+xab3/fsctgKdXR
N9wbaH5aszsf7ekysj45cY8gvbT91XfnJkQIHYetuB6XB0w1WXpyBtl0AFSu61l2OY9ll6653Reu
DRQzX4M+gH7Zlb2zeIBZSou7puhE3rf8myn7LFT4bs1g1+LcM1RrPuOWf2OQ6wNoTSQgy48GrbSX
t9M5CMhTjPiLEbzm4K9okAucrG6crmSOAW2MZ4wcj6eYiqq4B5W06RVwiwD5OpBjO56KPTo8P2E4
U4VZC1yDxszkr8ZNzz+AyqtYSSWQua0eboIdxtbE7siKXmZ/p9OKvz0aSocAAAAAAAA=

--Apple-Mail-89-806839382--

From zach@sensinode.com  Fri Oct 29 04:34:37 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300293A6A60; Fri, 29 Oct 2010 04:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.393
X-Spam-Level: 
X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=0.206,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSG8aU8VYlpS; Fri, 29 Oct 2010 04:34:28 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 06DF03A6A3C; Fri, 29 Oct 2010 04:34:14 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9TBa5Ha018258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Oct 2010 14:36:05 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-90-807321549; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Fri, 29 Oct 2010 14:36:06 +0300
Message-Id: 
References: 
To: matthieu.vial@fr.non.schneider-electric.com
X-Mailer: Apple Mail (2.1081)
Cc: core-bounces@ietf.org, core , Klaus Hartke 
Subject: Re: [core] Comments on draft-ietf-core-coap-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 11:34:37 -0000

--Apple-Mail-90-807321549
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Oct 29, 2010, at 12:03 PM, =
matthieu.vial@fr.non.schneider-electric.com wrote:

> >Sure, we should at least describe this better in the draft. My own =
assumption has been that a retransmitted request is equivalent (if not =
>identical) to the original request. Implementation wise, this is =
usually handled at the transaction layer, where you tend to keep a copy =
of the >buffer. I definitely don't recommend sending a different version =
of the resource representation for each retransmission.... I'll open up =
a ticket >on this.
>=20
> In section 2.2 of coap-observe one can read:
> If a confirmable notification requires a
> retransmission, it is RECOMMENDED to send the state that is current
> at the instant of the retransmission;=20

Oops. This shows how Klaus and I have interpreted how that should be =
done differently. We'll need to synchronize the two drafts for the next =
versions.

>=20
> As I understand this sentence the representation can change for each =
retransmission of the transaction. Like Carsten I think it can be much =
more memory efficient in many use cases so I would recommend a MAY.

I do understand how this optimization might be useful in some cases, =
especially with observe. In that way I have no problem in making that a =
MAY.

Zach

>=20
> Regards,
> Matthieu
>=20
>=20
> Zach Shelby 
>=20
>=20
>=20
>=20
> Zach Shelby =20
> Envoy=E9 par : core-bounces@ietf.org
> 29/10/2010 08:56
>=20
>=20
> A
>=20
> Peter Bigot 
>=20
> cc
>=20
> Klaus Hartke , core 
>=20
> Objet
>=20
> Re: [core] Comments on draft-ietf-core-coap-03
> =09
>=20
> On Oct 29, 2010, at 12:30 AM, Peter Bigot wrote:
>=20
> > In any case, since there's no initial unanimity, whether or not this =
is allowed should be explicit with either a MAY or a MUST NOT clause.
>=20
>=20
> Sure, we should at least describe this better in the draft. My own =
assumption has been that a retransmitted request is equivalent (if not =
identical) to the original request. Implementation wise, this is usually =
handled at the transaction layer, where you tend to keep a copy of the =
buffer. I definitely don't recommend sending a different version of the =
resource representation for each retransmission.... I'll open up a =
ticket on this.
>=20
> Zach =20
>=20
> --=20
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>=20
>=20
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> =
______________________________________________________________________(See=
 attached file: =
smime.p7s)_______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20
> 

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


--Apple-Mail-90-807321549
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyOTExMzYw
N1owIwYJKoZIhvcNAQkEMRYEFEzfAbgEiGo2btsDpeZasv2FC68mMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAJNybxJURNwBnN1kZ6jwNjpcHKJSpsV15Xeyh0hf764yveTiOP0nuMWv
Gjxe35MP6OEl1k8uyBUrc9mqCkpAuoZpTlzXEPVZdQbFtN5qOmag47cYJb9KmRbU/2wa9IrXBucj
OVGtbIKGlJ3DkXi4QhVI/wHKsT95LxfKpY3qmkqW6qQkuMozJmHdV0GN5bjIuflFAV/aLjotBFwH
OgdEsyN4qjGTJR068LlBXlA8f0mbdlJ9djUiqL1KwcMwnODn6Zm/yIbR0GUN5rG9z2nVEJSxHisN
usgx5FW5RPBvyume5YT/tOi7i8Fo/+81u0aGyI2/wrz8tcm96hzE9KqiJFUAAAAAAAA=

--Apple-Mail-90-807321549--

From pab@peoplepowerco.com  Fri Oct 29 05:35:39 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB4A3A67E1 for ; Fri, 29 Oct 2010 05:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level: 
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.254,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t09aqi51a7UL for ; Fri, 29 Oct 2010 05:35:37 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 303233A68E3 for ; Fri, 29 Oct 2010 05:35:36 -0700 (PDT)
Received: by fxm9 with SMTP id 9so3133789fxm.31 for ; Fri, 29 Oct 2010 05:37:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.69.132 with SMTP id z4mr5439786fai.31.1288355847553; Fri, 29 Oct 2010 05:37:27 -0700 (PDT)
Received: by 10.223.83.207 with HTTP; Fri, 29 Oct 2010 05:37:27 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 29 Oct 2010 07:37:27 -0500
Message-ID: 
From: Peter Bigot 
To: Zach Shelby 
Content-Type: multipart/alternative; boundary=20cf30433f00a342140493c0b810
Cc: core 
Subject: Re: [core] What's to be presented to IESG in December?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 12:35:39 -0000

--20cf30433f00a342140493c0b810
Content-Type: text/plain; charset=ISO-8859-1

I am worried that coap-observe sets precedence for using CoAP with multiple
responses to a single request.  I would be much less concerned, and might
support it technically, if it were changed to use a new method instead of a
200 response for its announcements, but I don't think that can be
satisfactorily designed and evaluated before December.  So, I object to
promotion of coap-observe in this time frame.

I feel coap-block is unnecessary if one can defer to alternative protocols
(and we will need Uri-Scheme back to enable that, which I very much want)
and therefore would not use it myself, but with a change that prevents
servers from introducing it in the response when Block doesn't appear in the
request---and pending a final review---I would support it for December.

I have not read the slice-related draft, but feel it is far too close to
December (five weeks) to go that way.

I'm not worried about innovation; I certainly expect to use a variety of
alternative solutions for observe, all at the application level.  But I
think the perception of the Internet community will be that CoRE working
group/IETF is implicitly recommending a specific approach by releasing it
along with the main document.  I don't plan to use it (or support it); my
impression from comments from others is that they wouldn't either; and we're
back at the dozen-incompatible-solutions situation, without the motivation
to unify them that absence of a formal IETF solution would provide.

That CoAP does not have provision for user-defined options and methods makes
it much harder to innovate compatibly, but that's another topic.

My motivation to volunteer to review ways to support observe in the base
protocol for discussion in Beijing was to help satisfy the charter
requirement for an observation capability.  My assessment is that observe is
a hard problem with a lot of application-influenced variables and
constraints, and there is too little experience with the protocol in real
applications and environments to formally recognize any single solution as
preferred at this time.  If the working group disagrees with this
assessment, or the charter requirement is to be met some other way such as
by proposing a specific solution, I don't see any need to do such a review
now.  It merely distracts from the job of getting something out in December.

Peter

On Fri, Oct 29, 2010 at 6:28 AM, Zach Shelby  wrote:

>
> On Oct 29, 2010, at 2:16 PM, Peter Bigot wrote:
>
> > - The appearance in coap-03 of the option values associated with the
> drafts for coap-observe and coap-block
>
>
> To be clear, I did this only as a temporary placeholder for those option
> type IDs to prevent collisions with people working with experimental options
> in other drafts. It is not meant to be interpreted that core-block and
> core-observe need to go to the IESG at precisely the same time (nor that
> those table values even need to be in the CoAP RFC). Now that they are both
> WG documents I think this is helpful to list them in the coap option table
> for now.
>
> In my personal opinion, it is most important that we concentrate on
> completing core-coap in December according to our charter. However, as
> core-block and core-observe are both part of the same charter work item, it
> would be a good goal to have them in stable shape at the same time. The
> chairs will surely give more information on the procedure.
>
> Peter, it seems you are worried about future innovation around CoRE? I
> wouldn't be. coap-block and coap-observe are two optional mechanisms that
> can be used with CoAP to fulfill basic application requirements we have.
> After this charter is fulfilled, we'll have the opportunity to re-charter
> the WG and to work on new things. This is a really good WG in my opinion and
> people have already identified useful future work, so I think we definitely
> should aim at re-chartering.
>
> Zach
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>

--20cf30433f00a342140493c0b810
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am worried that coap-observe sets precedence for using CoAP with multiple=
 responses to a single request.=A0 I would be much less concerned, and migh=
t support it technically, if it were changed to use a new method instead of=
 a 200 response for its announcements, but I don't think that can be sa=
tisfactorily designed and evaluated before December.=A0 So, I object to pro=
motion of coap-observe in this time frame.


I feel coap-block is unnecessary if one can defer to alternative protoc=
ols (and we will need Uri-Scheme back to enable that, which I very much wan=
t) and therefore would not use it myself, but with a change that prevents s=
ervers from introducing it in the response when Block doesn't appear in=
 the request---and pending a final review---I would support it for December=
.


I have not read the slice-related draft, but feel it is far too close t=
o December (five weeks) to go that way.

I'm not worried about in=
novation; I certainly expect to use a variety of
 alternative solutions for observe, all at the application level.=A0 But I =
think the perception of the Internet community will be that CoRE working gr=
oup/IETF is implicitly recommending a specific approach by releasing it alo=
ng with the main=20
document.=A0 I don't plan to use it (or support it); my impression from=
 comments from others is that they wouldn't either; and we're back =
at the dozen-incompatible-solutions situation, without the motivation to un=
ify them that absence of a formal IETF solution would provide.


That CoAP does not have provision for user-defined options and methods =
makes it much harder to innovate compatibly, but that's another topic.<=
br>
My motivation to volunteer to review ways to support observe in the =
base protocol for discussion in Beijing was to help satisfy the charter req=
uirement for an observation capability.=A0 My assessment is that observe is=
 a hard problem with a lot of application-influenced variables and constrai=
nts, and there is too little experience with the protocol in real applicati=
ons and environments to formally recognize any single solution as preferred=
 at this time.=A0 If the working group disagrees with this assessment, or t=
he charter requirement is to be met some other way such as by proposing a s=
pecific solution, I don't see any need to do such a review now.=A0 It m=
erely distracts from the job of getting something out in December.


Peter

On Fri, Oct 29, 2010 at 6:28 AM=
, Zach Shelby <z=
ach@sensinode.com> wrote:




On Oct 29, 2010, at 2:16 PM, Peter Bigot wrote:



> - The appearance in coap-03 of the option values associated with the d=
rafts for coap-observe and coap-block






To be clear, I did this only as a temporary placeholder for those opt=
ion type IDs to prevent collisions with people working with experimental op=
tions in other drafts. It is not meant to be interpreted that core-block an=
d core-observe need to go to the IESG at precisely the same time (nor that =
those table values even need to be in the CoAP RFC). Now that they are both=
 WG documents I think this is helpful to list them in the coap option table=
 for now.




In my personal opinion, it is most important that we concentrate on complet=
ing core-coap in December according to our charter. However, as core-block =
and core-observe are both part of the same charter work item, it would be a=
 good goal to have them in stable shape at the same time. The chairs will s=
urely give more information on the procedure.




Peter, it seems you are worried about future innovation around CoRE? I woul=
dn't be. coap-block and coap-observe are two optional mechanisms that c=
an be used with CoAP to fulfill basic application requirements we have. Aft=
er this charter is fulfilled, we'll have the opportunity to re-charter =
the WG and to work on new things. This is a really good WG in my opinion an=
d people have already identified useful future work, so I think we definite=
ly should aim at re-chartering.




Zach



--

Zach Shelby, Chief Nerd, Sensinode Ltd.

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

http://6lowpan.net - M=
y book "6LoWPAN: The Wireless Embedded Internet"

Mobile: +358 40 7796297







--20cf30433f00a342140493c0b810--

From rstruik.ext@gmail.com  Fri Oct 29 05:41:55 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD833A683B for ; Fri, 29 Oct 2010 05:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.837
X-Spam-Level: 
X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxc+A7GwQttX for ; Fri, 29 Oct 2010 05:41:51 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id F099E3A67E1 for ; Fri, 29 Oct 2010 05:41:50 -0700 (PDT)
Received: by gwb15 with SMTP id 15so2088865gwb.31 for ; Fri, 29 Oct 2010 05:43:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=UBUoI9OnzeKlp5aE3v9DiQPx6aITL/IN/TTHdxGJ8rw=; b=UdNXxP+4ZFTCzJkSGn1VWNBqnrN7Bq8jv9itDQx18QogAD5Wdwhuuu60rjjqnJJn6p V6+Q84iKtDJ3ftK6qTS7BMcioqQe1O9Gf48vHZviVq+X+vwvfKSV8bQuEGLodWfOpL6I cP6LGdkiJCnV4O6JNGPGbu3U/wQhuEMLZfJGE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=W/Or9KtzLrhFgBig1r10YbuWBoIfaTdDQBQyb6rJoVZ24vcKLzHzTKIgoknrXCbgbk mw5r0/H6ksJm+LAYruG9FxjM1DQHhppoqLW1oIlKB/qCVjGZG+k7EC63LbwxYHTw/7od 0ZnECxy8siFJ/n4dJ/BlKtyeERGvSK0bbNo6E=
Received: by 10.100.9.14 with SMTP id 14mr10235779ani.239.1288356224332; Fri, 29 Oct 2010 05:43:44 -0700 (PDT)
Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id b22sm2461850anb.35.2010.10.29.05.43.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 05:43:43 -0700 (PDT)
Message-ID: <4CCAC166.90504@gmail.com>
Date: Fri, 29 Oct 2010 08:43:18 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Yoshihiro Ohba 
References:   <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com>  <4CA5E8E0.4030503@gmail.com>  <4CA6095F.6040403@gmail.com>  <4CB48B9B.9010206@gmail.com> <4CC83F61.5060109@gmail.com> <023a01cb76e1$869bfcc0$93d3f640$%yegin@yegin.org>  <4CCA052E.2010909@toshiba.co.jp> <4CCA41AC.6040800@gmail.com> <4CCA7819.6020908@toshiba.co.jp>
In-Reply-To: <4CCA7819.6020908@toshiba.co.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: core@ietf.org
Subject: Re: [core] concerns re draft-oflynn-core-bootstrapping-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 12:41:55 -0000

Hi Yoshihiro:

As already expressed, I would really favor a more fundamental approach,
where deployment scenarios, desired operational behaviors, and required
security properties are guideline to the design. Protocol soup acronyms
are nice, but they could obscure what one is really after here (at
least, that is what this does to me).

That is also what I expressed in my email 4 weeks ago (October 1, 2010),
originally in the context of HIP. Unfortunately, most of the analysis is
still missing.

Best regards, Rene
(again in the office Monday)

On 29/10/2010 3:30 AM, Yoshihiro Ohba wrote:
> Hello Rene,
>
> Thank you very much for expressing your concerns in detail.
>
> Basically there is no implications such as (a) and (b1) to (b4) in the
> general framework of PANA, EAP and AAA.  Let me explain this in
> details below..
>
> (2010/10/29 12:38), Rene Struik wrote:
>> Hi Yoshihiro:
>>
>> It seems that in your example each device identifier is tied to a 
>> single security manager (e.g., device A and security manager S would 
>> yield device id A@S.com).
>>
>> This seems to imply the following:
>> (a) entangles the name space and device role space (since tie-ing node 
>> A to a node S that assumes a security manager role for A);
> In the case where the EAP peer identity is tied with the device in
> which the EAP peer resides, you are right.  However, the EAP peer
> identity is not necessarily tied with the device.  It can be also tied
> with the user who uses the device.  Or when a tunneling EAP method
> such as EAP-TTLS is used, it is possible to tie the EAP peer identity
> for the outer EAP method with the device *and* tie the EAP peer
> identity for the inner EAP method with the user.  So in general EAP
> framework, there is no fixed binding is assumed between the device and
> security manager.
>
>> (b) precludes scenarios where
>> (b1) a device may have multiple security managers (example: remote 
>> control, spare remote under the pillow, central node);
> When PANA is used, it is possible to have multiple PANA sessions
> between a PaC and a PAA, and different EAP peer identities can be used
> for those PANA sessions where each EAP peer identity may be tied with
> a distinct security manager.  OTOH, this kind of scenario is difficult
> to be supported by IEEE 802.1X which allows only one authentication
> session between a pair of 802.1X Supplicant and Authenticator.
>
>> (b2) a security manager may change over time (example: change of 
>> security manager, due to malfunctioning device or ownership change);
> I think this is basically a provisioning issue.  If a deployment uses
> a provisioning mechanism that allows dynamically changing the EAP peer
> identity associated with a particular device, it is possible to change
> a security manager over time under the EAP framework.
>
>> (b3) a device may not have a security manager yet (example: device is 
>> initially taken out of generic box, without any imprinting happening 
>> yet);
> Again I think this is a provisioning issue.  If a deployment uses a
> provisioning mechanism that supports a standalone bootstrapping
> mechanism during the provisioning phase, it is possible not to use a
> security manager in the provisioning phase.
>
>> (b4) a device and security manager may not be in hierarchical 
>> relationship (example: simple device pairing a la Bluetooth v2.1 EDR).
>> As such, this seems to preclude many useful deployment scenarios for 
>> sensor networks.
> Since the EAP framework does not require to use the AAA
> infrastructure, a P2P relationship can be supported by the EAP framework.
>
> We can clarify these things in the core-bootstrapping draft if it helps.
>
> Best Regards,
> Yoshihiro Ohba
>
>
>> Hence, my note in my email as of Wed October 27, 2010, 11:04am EDT re 
>> the latest version of draft-oflynn-core-bootstrapping-02, in which I 
>> highlighted the importance of facilitating a flexible set of 
>> deployment scenarios.
>>
>> Please let me know if I misinterpreted your EAP-style explanation 
>> (above, I only focus on logical device roles and not on communication 
>> patterns).
>>
>> Best regards, Rene
>>
>> [excerpt email RS as of October 1, 2010, 12:16pm EDT]
>>
>> In my mind, properties of suitable authenticated key agreement schemes 
>> should include (a) key establishment; (b) implicit key authentication; 
>> (c) key confirmation; (d) mutual entity authentication; (e) forward 
>> secrecy; (f) {perhaps} some more esoteric properties (key compromise 
>> impersonation resilience, etc.).
>>
>> Moreover, the "name space" (device identifiers) and the "cryptographic 
>> space" (public keys, etc.) should be independent, so that this would 
>> allow trust lifecycle management to be reduced to proper management of 
>> device identifiers (i.e., ****no** entanglement of concepts from 
>> different disciplines).
>>
>>
>> On 28/10/2010 7:20 PM, Yoshihiro Ohba wrote:
>>> OK, then let me use the term "RADIUS server" to explain.
>>>
>>> Any EAP transport protocol such as IEEE 802.1X and PANA works with
>>> multiple AAA domains in which a single access network may interface to
>>> multiple RADIUS servers where each RADIUS server serves for a distinct
>>> AAA domain. With EAP, RADIUS routing is based on the EAP peer
>>> identity such as "foo@domainA.com" and "bar@domainB.com" in a way that
>>> authentication messages for EAP peer "foo@domainA.com"are routed to
>>> "domainA.com" RADIUS server and authentication messages for EAP peer
>>> "bar@domainB.com" are routed to "domainB.com" RADIUS server. The EAP
>>> peer identity is extracted from the initial EAP exchange by an EAP
>>> pass-through authenticator that is co-located with a RADIUS client at
>>> the border of the access network. In a large scale RADIUS deployment,
>>> there may be RADIUS proxies between a RADIUS client and a RADIUS
>>> server to simplify the AAA routing task for RADIUS clients. In PANA,
>>> PAA (PANA Authentication Agent) is the EAP pass-through authenticator,
>>> and PaC (PANA Client) is the EAP peer.
>>>
>>> Hope this helps,
>>> Yoshihiro Ohba
>>>
>>> (2010/10/29 6:21), Carsten Bormann wrote:
>>>> On Oct 28, 2010, at 22:48, Alper Yegin wrote:
>>>>
>>>>> mothership
>>>> I think other terms are "mother-may-I", "trust center", "RADIUS 
>>>> server", or "Policy Decision Point". Just guessing, though.
>>>> I think the use case of interest here is a single constrained 
>>>> network that simultaneously serves multiple trust domains, so being 
>>>> authorized by any one of them should give you access.
>>>>
>>>> With that potential explanation, can you elucidate whether (and 
>>>> maybe how) PANA would work in this scenario?
>>>>
>>>> Gruesse, Carsten
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> core@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


From rstruik.ext@gmail.com  Fri Oct 29 06:00:49 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D32C3A6A3E for ; Fri, 29 Oct 2010 06:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.824
X-Spam-Level: 
X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOR-q56sLFkc for ; Fri, 29 Oct 2010 06:00:41 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 8A6293A6899 for ; Fri, 29 Oct 2010 06:00:41 -0700 (PDT)
Received: by gya6 with SMTP id 6so2080041gya.31 for ; Fri, 29 Oct 2010 06:02:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=PNfrWuZYEAxrOqwfn0j/ylyvEmfcKzmR9HaRW4+rVS8=; b=rjd7QrUNk7dzuRPtQCJA2l6zkw7NzYsdkZ/03gW4JR29rZFOdlCMeeFlCGcxMiAx1U 5jECpkcwLxIXfDHXfWRADX2eYdgO054WJhvuOrlc5ZIlHkmtOrD5FmUYIr66rBIUZMGQ XQnCAPtvnTuItA8EPsxVqS0PuxupKckntdxAQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YQCde7+6MC2CYt3iMnGMT05fxPHgXXy0YyQpiqoAcYsegjNhQr8V/ZKtZMDErXzoah vbsIRqsZXMhVnXoG3LWpFsahIIPJBW21FMFlB1w3i7s6iMIXN1k2+Uc8WeGDHxdNPQ+S je0FYq0X/G5aNn8w+Ymnwl+9Yo4hJVsM3w9yo=
Received: by 10.100.58.14 with SMTP id g14mr310040ana.230.1288357355477; Fri, 29 Oct 2010 06:02:35 -0700 (PDT)
Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id 13sm2480801anq.30.2010.10.29.06.02.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 06:02:34 -0700 (PDT)
Message-ID: <4CCAC5DF.5090201@gmail.com>
Date: Fri, 29 Oct 2010 09:02:23 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Tobias Heer 
References:   <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com>  <4CA5E8E0.4030503@gmail.com>  <4CA6095F.6040403@gmail.com>  <4CB48B9B.9010206@gmail.com> <4CBF03D6.3050903@gmail.com> <44203C3A-2A58-4880-BDC9-7E0C3D16A49A@cs.rwth-aachen.de> <4CBF11BC.5040301@gmail.com>  <4CBF5288.5090706@gmail.com>
In-Reply-To: <4CBF5288.5090706@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: core 
Subject: Re: [core] HIP identities and puzzle
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 13:00:49 -0000

Hi Tobias:

It would help to have some more insight into claimed functionality of 
the HIP protocol. We had some correspondence on this over the last 4 
weeks, but unfortunately detail as to claimed security properties, 
distinguishing features w.r.t. other protocols, and, e.g., computational 
benefits over other approaches still seems to be partially lacking (at 
least, to me).  Moreover, I still have trouble to understand how the 
protocol could facilitate separation of device ids and cryptographic 
objects, as seems to be beneficial in deployment scenarios, such as 
large scale manufacturing of sensor nodes.

If you could elaborate and put the issues to rest, that would be great.

For the benefit of easy comprehension, I would suggest a succinct 
description (perhaps, with mathematical description of security-relevant 
portions of the protocol flows, properties, etc?).

I am sending this to the list, since Carsten Bormann is right: the group 
as a whole would benefit from technical discussions.

Best regards, Rene

On 20/10/2010 4:35 PM, Rene Struik wrote:
> Hi Tobias:
>
> If the device's public key and the CA's signature verification key are 
> similar mathematical objects (e.g., both are on the same elliptic 
> curve), then the crypto real estate to perform certificate self-tests 
> can be made to reuse that used to perform key computations with an 
> authenticated key agreement scheme that uses certs. Obviously, this 
> would require the device to have access to an authentic copy of the 
> CA's signature verification key. If the CA's public key is not 
> available, it cannot check its own cert an alternative authentic 
> channel has to be established between the device and an external party 
> who attests to the authenticity of the cert. This being said, I do not 
> know of practical scenarios where the latter limitation arises 
> (usually, one does not accept any cert for which one does not already 
> have a bootstrapped [or not] root CA key).
>
> It seems somewhat dangerous to use certs to bind arbitrary strings to 
> public keys if the semantics of that string is not well-understood or 
> can be defined at will be another process. After all, if the string is 
> StrA and semantics of one application defines this as "temperature 
> sensor A", while another application defines this as "thermometer B", 
> confusion may arise: does (StrA, PublicKey) relate to some physical 
> device A or some physical device B? Not sure how this can be avoided 
> if one does not stipulate that for any semantics one may define, the 
> mapping String --> Globally Unique Device Id is an injection. 
> Intuitively, this seems to suggest that each string contains an object 
> that is 1-1 mappable to this globally unique device id.
>
> Best regards, Rene
>
>
>
> On 20/10/2010 2:37 PM, Tobias Heer wrote:
>> Hi Rene,
>>
>> Am 20.10.2010 um 17:58 schrieb Rene Struik:
>>
>>> Hi Tobias:
>>>
>>> No worries - I am just curious to see how HIP fits in with 
>>> ubiquitous networks of smart objects, why one would care about the 
>>> protocol, and which use cases are enabled. Depending the outcome 
>>> hereof, it may be worth pointing to in IETF drafts etc.
>>>
>>> Some brief comments below (enclosed by RS>>  and<>>
>>> Best regards, Rene
>>>
>>> On 20/10/2010 11:31 AM, Tobias Heer wrote:
>>>> Hi Rene,
>>>>
>>>> First: thanks for your feedback. [snip(RS)]. I'll respond to the 
>>>> quick questions immediately and will come back with a more detailed 
>>>> and better specified description in a couple of days. Actually René 
>>>> Hummen might respond instead of me.
>>>>
>>>> Am 20.10.2010 um 16:59 schrieb Rene Struik:
>>>>
>>>>> Hi Tobias, Zhen:
>>>>>
>>>>> I would be indebted if you could provide some feedback on my email 
>>>>> as of Tuesday last week (October 12, 2010, 12:23pm EDT - - cf. 
>>>>> below).
>>>>>
>>>>> Best regards, Rene
>>>>>
>>>>> On 12/10/2010 12:23 PM, Rene Struik wrote:
>>>>>> Hi Tobias:
>>>>>>
>>>>>> Thanks for your note.
>>>>>>
>>>>>> Does your "ascii art" description, Step 1)-3) allow the scenario, 
>>>>>> where (a) one assigns a node id and imprints this (e.g., blowing 
>>>>>> fuse during chip testing);
>>>>>> (b) has a node generating its own long-term public/private key 
>>>>>> pair and outputting its node id and public key (e.g., during chip 
>>>>>> testing -- this would
>>>>>> correspond to registering a public key with an RA); (c) have CA 
>>>>>> create a certificate in different process and return this value 
>>>>>> at later production/
>>>>>> personalization stage?
>>>> a) yes it would
>>>> b) yes, the node could generate the static DH key by itself and 
>>>> acquire a certificate for this key (e.g., at deployment time)
>>>> c) I am not completely sure what you mean with "different process" 
>>>> and "return" however, I can outline the possible flexibility that 
>>>> one would have:
>>>>
>>> RS>>
>>> Setting would be where one would register a pair (Device Id, Public 
>>> key) during production, ship a database of these pairs to a CA, have 
>>> the latter generating a certificate for (Device Id, Public key) 
>>> pairs of its choosing and tie this to associated keying material 
>>> (such as policy field, validity period, and the-like). Certificates 
>>> themselves could then find a way back to a device via any other 
>>> communication channel (does not require online/inline involvement of 
>>> CA and could, e.g., by provided when personalized in a BestBuy shop, 
>>> using a BestBuy CA (note that BestBuy CA would then have to relie on 
>>> the RA used during production - the one that collected the database).
>>> <>>> (I am taking about DEX now, not HIP BEX)
>>>>
>>>> i)   The static DH key can either be node-generated or imprinted by 
>>>> some entity (in a secure environment)
>>>> ii)  The certificate can either be imprinted when the node is 
>>>> manufactured or it can be imprinted later (again, in a secure 
>>>> environment)
>>> RS>>
>>> Not sure why imprinting of certificate (authorization of state 
>>> change aside) would need to be done in secured environment in 
>>> general, since this is public piece of information.
>>> <> Sure, the information is public but nodes that cannot verify their 
>> own certificate (I do not assume that all nodes are able to verify 
>> digital signatures. However, I am not sure if it is useful to assume 
>> that a host supports ECDH but not ECDSA) might accept an invalid 
>> certificate and could, from that moment on, not authenticate towards 
>> a legitimate host anymore. The secure environment is not needed if a) 
>> a node can verify its own certificate or b) if the node can verify 
>> the identity of the device that imprints the certificate.
>>
>>>> iii) The certificate could be renewed at any time (provided there 
>>>> is a secure mechanism for that)
>>>> iv)  The DH public key could be renewed as well (at any time), 
>>>> however, a node would require a new certificate, authenticating the 
>>>> new DH key then
>>>>
>>>> For BEX, nodes' identity would be the RSA/DSA/ECDSA key of the node 
>>>> instead of the static DH public key. Hence, the ephemeral DH key 
>>>> would change more often while the ECDSA public key would be in the 
>>>> certificate.
>>>>
>>> RS>>
>>> I still have some trouble understanding how identifying nodes by 
>>> their public key is going to satisfy use case scenarios where one 
>>> may have changes to the public key, different certificates, and 
>>> the-like. Please note that the objective of certificates is to 
>>> provide for a secure binding between a device's id and its private 
>>> key (via the corresponding public key), thus freeing one to just use 
>>> device ids -- after all, certificate processing would then yield the 
>>> corresponding public key(s) purportedly owned by that device.
>>> <> The certificate would bind a string to the public key (static DH or 
>> RSA/DSA/ECDSA). The string would be used by layers above HIP. HIP 
>> maps the string to the static public key of the peer in the BEX by 
>> using the certificate that the peer provides. A device is therefore 
>> identified by a string not a public key (as in vanilla HIP).
>>
>>>>>> Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I 
>>>>>> get the impression that HIP does execute an authenticated DH key 
>>>>>> agreement scheme. If so,
>>>>>> this makes me wonder how HIP differentiates from protocols, such 
>>>>>> as ECMQV and, e.g., HMQV, which are all not that much more 
>>>>>> expensive than ECDH. If the
>>>>>> difference is in the "puzzle" element, couldn't one just add 
>>>>>> something similar to a well-known authenticated scheme that is 
>>>>>> already standardized with, e.g.,
>>>>>> NIST?
>>>> I'll let René Hummen respond to this question.
>>>>
>>> RS>>
>>> Sure - looking forward to this. This would be easy to compare, once 
>>> one has succinct description of the cryptographic aspects of the 
>>> protocol (so that, e.g., one can count the number of scalar point 
>>> multiplications involved, etc.).
>>> <>>>>> As to forward secrecy: reason to include this is that many 
>>>>>> sensor-type nodes can be expected to be physically unprotected 
>>>>>> (e.g., screwed on a street lamp
>>>>>> post, on a garage roof, etc.) and, therefore, may be more 
>>>>>> vulnerable to device compromise over time (esp. since one cannot 
>>>>>> expect all nodes to be tamper
>>>>>> resistant or tamper evident). By virtue of forward secrecy, 
>>>>>> compromise over time does not compromise the whole device's 
>>>>>> history, but only the current set of
>>>>>> symmetric keys (note: I make some shortcuts in my reasoning on 
>>>>>> key management here). Admittedly, my list of security properties 
>>>>>> is based on "desired"
>>>>>> functionality and does not exclude functionality that may 
>>>>>> require, e.g., public-key crypto constructs. However, from a 
>>>>>> user's perspective, the only thing that
>>>>>> matters is features and not what is "under the hood", as long as 
>>>>>> that is not cost-prohibitive (which I contend it is not -- cf., 
>>>>>> e.g., Section 3.2 of
>>>>>> draft-struik-6lowapp-security-considerations-00). (BTW - All 
>>>>>> other desired security properties I listed have an underlying 
>>>>>> rationale.)
>>>> I am still somewhat unsure about cost and capabilities of the 
>>>> targeted devices. Depending on who you talk to, people seem to 
>>>> expect sensors that are capable of ECC crypto, barely capable or 
>>>> not capable at all.
>>>> Are there minimal hardware specs for target devices?
>>>>
>>> RS>>
>>> Almost all 802.15.4-based modules have hardware support for AES-128 
>>> (in forward mode). Since the MAC layer requires error detection 
>>> using CRC-16 linear feedback shift regsiter circuits (which is a no 
>>> brainer) and since, e.g., elliptic curves over binary extension 
>>> fields can be realized using shift registers that are of order of 
>>> magnitude anything up to 256 registers, I do not see a problem for 
>>> hardware support here (once implemented in large scale environments).
>>>
>>> Source: http://2010.eccworkshop.org/
>>> Junfeng Fan(K.U.Leuven, 
>>> Belgium)
>>> /ECC on constrained devices/
>>> The embedded security community has been looking at the ECC ever 
>>> since it was introduced. Hardware designers are now challenged by 
>>> limited area (<15k Gates), low power budget (<100uw) and 
>>> sophisticated physical attacks. This talk will report the 
>>> state-of-the-art ECC implementations for ultra-constrained devices. 
>>> We take a passive RFID tag as our potential target. We will discuss 
>>> the known techniques to realize ECC on such kind of devices, and 
>>> what are the challenges we face now and in the near future.
>>> <> Impressive. I'll certainly give it a closer look.
>>
>> Tobias
>>
>
>


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


From rstruik.ext@gmail.com  Fri Oct 29 06:12:28 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896A73A6A1F for ; Fri, 29 Oct 2010 06:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Level: 
X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjnz0vYkB9+F for ; Fri, 29 Oct 2010 06:12:27 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4C8BC3A689E for ; Fri, 29 Oct 2010 06:12:27 -0700 (PDT)
Received: by gxk7 with SMTP id 7so2095022gxk.31 for ; Fri, 29 Oct 2010 06:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=nBTFzX8dqoxCi1AFF59k9+Ryh4xLPdkhgUvTcISwjaQ=; b=NY6+hxHLz4CjBBDX/7am2NLJGwESOUfmTMNesQZeCknQn3I+t+RgTZ+zIH04ixEoPm vHc0GFTXk286K0pMXlyiGVdHLRwYMligyBwnxjIr/MzZ97BMFf5ohaYgYZZbFhPYBqdk XOhYhHK99w1obYmyQLaZexhTKvxqecMY/pfRI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=OLIwYu5OA++zffTiYpTbfsdOFuT4qFgSNg2+b9n0IZTwp8t9g2WDIwq4F4npvpuCkU mbt8kpWzD2kQbRXb+NOJckI1ohBdfAPtGygCMsyOuBteylcaiwVlAmqyufDN2O8ieSdD okot+Y+HVUYWnFGKYeOxPyYMYPz0B3OIzZHn0=
Received: by 10.100.32.2 with SMTP id f2mr6667638anf.177.1288358061194; Fri, 29 Oct 2010 06:14:21 -0700 (PDT)
Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id d15sm2493358ana.20.2010.10.29.06.14.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 06:14:20 -0700 (PDT)
Message-ID: <4CCAC8A1.6090500@gmail.com>
Date: Fri, 29 Oct 2010 09:14:09 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Carsten Bormann 
References: <2AC6B6F1-95F5-4C08-A7CC-3E94C87AA8AF@tzi.org>
In-Reply-To: <2AC6B6F1-95F5-4C08-A7CC-3E94C87AA8AF@tzi.org>
Content-Type: multipart/alternative; boundary="------------080607080108080207020106"
Cc: core 
Subject: Re: [core] CoRE IETF79 agenda
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 13:12:28 -0000

This is a multi-part message in MIME format.
--------------080607080108080207020106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Carsten:

As also suggested in my email as of Wed October 27, 2010, 11:04am EDT, in my mind, the bootstrapping document would benefit from a more fundamental approach, where one takes deployment scenarios, desired operational behaviors, and required security properties are guideline to the design. All of these areas still require quite a bit of work (as also evidenced by the email by Yoshihiro Ohba earlier today (Fri October 29, 2010, 3:30am EDT).

Best regards, Rene

==
[excerpt posted agenda]

10:05	draft-oflynn-core-bootstrapping
Gap: documenting the security objectives that go into this work

Objective: sort through the technical alternatives and their technical
requirements; relate them to the security objectives



On 28/10/2010 12:52 PM, Carsten Bormann wrote:
> I have just uploaded an expanded version of the proposed agenda:
>
> http://www.ietf.org/proceedings/79/agenda/core.txt
>
> Apart from timeslots, I have tried to identify objectives for each slot as well as the gaps I think we need to fill in the next 10 days before the meeting.  This is based on the submitted drafts and the discussion yesterday, but of course won't be perfect yet.
>
> What I'd like to hear from you:
>
> 1) What have I missed?
>
> 2) Can the description of the gaps and objectives for each slot be improved?
>
> 3) Which slot do you want to present/lead?
>
> 4) Are the time allocations reasonable?
>
> as well as any other comments/proposals about the agenda.
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


--------------080607080108080207020106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    
      
Dear Carsten:

As also suggested in my email as of Wed October 27, 2010, 11:04am EDT, in my mind, the bootstrapping document would benefit from a more fundamental approach, where one takes deployment scenarios, desired operational behaviors, and required security properties are guideline to the design. All of these areas still require quite a bit of work (as also evidenced by the email by Yoshihiro Ohba earlier today (Fri October 29, 2010, 3:30am EDT).

Best regards, Rene

==
[excerpt posted agenda]

10:05	draft-oflynn-core-bootstrapping
Gap: documenting the security objectives that go into this work

Objective: sort through the technical alternatives and their technical
requirements; relate them to the security objectives

    

    

    On 28/10/2010 12:52 PM, Carsten Bormann wrote:
    

      
I have just uploaded an expanded version of the proposed agenda:

http://www.ietf.org/proceedings/79/agenda/core.txt

Apart from timeslots, I have tried to identify objectives for each slot as well as the gaps I think we need to fill in the next 10 days before the meeting.  This is based on the submitted drafts and the discussion yesterday, but of course won't be perfect yet.

What I'd like to hear from you:

1) What have I missed?

2) Can the description of the gaps and objectives for each slot be improved?

3) Which slot do you want to present/lead?

4) Are the time allocations reasonable?

as well as any other comments/proposals about the agenda.

Gruesse, Carsten

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


    

    

    

    
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

  


--------------080607080108080207020106--

From kerlyn2001@gmail.com  Fri Oct 29 06:53:48 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFEB3A69F0 for ; Fri, 29 Oct 2010 06:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level: 
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL+-DILB0qYr for ; Fri, 29 Oct 2010 06:53:46 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BF2203A69CB for ; Fri, 29 Oct 2010 06:53:45 -0700 (PDT)
Received: by bwz12 with SMTP id 12so2728899bwz.31 for ; Fri, 29 Oct 2010 06:55:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nv9S/hxFmLu8lPHSFrafIS2+jVZ2j3NjCK9wcff8Dkg=; b=IbWJI735T5G4cIr5urh2IKtYqNqvQRvF2jjxAVn2CPdzs40IKi6jXTSb3yLOq2/W+d avFd+83udWDumQH8insNBZ2Puoz0VUCRzKo/kRVfYx5v48kPCHTF5D7AmHRYppwPRe9h iZz8H9B+nQsp03ipAKW+MleaqNQ5JTpaZOKdA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Wdig6tzwjONEuFS7hSn2P+v67clXOigHP8HDBO6tX8ozYuIhu3ayxiiq2bEujDD+yB pI7S1vj8+I+99lnILFcnUCnv9w7LjIJQ66O0J1BA+uthP7t3ShcZKdMA3DYWa6g7vcTp 1Rxni/Jezt6uiWWQdFEocSRsOJwA2ihsLMFCY=
MIME-Version: 1.0
Received: by 10.204.124.14 with SMTP id s14mr5323277bkr.21.1288360538821; Fri, 29 Oct 2010 06:55:38 -0700 (PDT)
Received: by 10.204.72.131 with HTTP; Fri, 29 Oct 2010 06:55:38 -0700 (PDT)
In-Reply-To: <80D4CF54-59BE-4AC7-8458-E4A42F91CF75@tzi.org>
References:   <80D4CF54-59BE-4AC7-8458-E4A42F91CF75@tzi.org>
Date: Fri, 29 Oct 2010 09:55:38 -0400
Message-ID: 
From: Kerry Lynn 
To: Carsten Bormann 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Klaus Hartke , core 
Subject: Re: [core] POST (Re: Comments on draft-ietf-core-coap-03)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 13:53:48 -0000

If you diff -02 and -03, you'll see that I only suggested two words,
"subordinate" and "parent" to clarify the wording that was already
in place.

I am the last one to serve as an arbiter of taste when it comes to
RESTful application of HTTP methods; most of what I know comes
from O'Reilly's "RESTful Web Services" by Richardson and Ruby.
In that book they develop a concept of a Resource Oriented
Architecture (ROA) and discuss two potential ways to employ
post.  I'll paraphrase to say that the way that's most consistent
with ROA is to use it as "append".  I know that other systems
claiming to be RESTful may use it more in the manner of
"invoke", but this seems like a trapdoor to a more RPC-like
behavior and is not deemed to be uniform by the O'Reilly
authors.

I don't think the CoAP spec prohibits the use of POST in this
manner, but perhaps the language should be a little more
equivocal to say the suggested use is more like "append".

Regards, -K-


On Fri, Oct 29, 2010 at 6:11 AM, Carsten Bormann  wrote:
> On Oct 29, 2010, at 09:34, Zach Shelby wrote:
>
>>> 2.3.2.
>>> The section suggests that the only possible interpretation of POST is
>>> to create a new subordinate resource on the server. Is this the case?
>>> If yes, rename POST to CREATE?
>>
>> Kerry Lynn suggested an improvement on the text for -03. Sorry I was in =
too much of a hurry submitting -03 to synchronize this with RFC2616. Did th=
is break something?
>
> In HTTP, POST pretty much means "send a message to a resource".
>
> RFC 2616 9.5:
> =A0 The POST method is used to request that the origin server accept the
> =A0 entity enclosed in the request as a new subordinate of the resource..=
.
> =A0 The actual function performed by the POST method is determined by the
> =A0 server and is usually dependent on the Request-URI....
> =A0 The action performed by the POST method might not result in a
> =A0 resource that can be identified by a URI...
>
> CoAP-03 appears to be more specific in that it actually talks about reque=
sting to create a new resource:
> 2.3.2:
> =A0 The POST method is used to request the server to create a new
> =A0 subordinate resource under the requested parent URI.
>
> (The server then may go ahead and not actually do that and still return a=
 200 OK, which doesn't quite fit the language of the first sentence.)
>
> By appeal to authority, Roy Fielding likes POST in HTTP's semantics:
> http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
> "It is okay to use POST =BB Untangled"
>
> But maybe we do indeed want to have the more specific semantics.
> With a bit more work, this might even enable us to make POST idempotent.
> We need realistic usecases to make a well-founded decision.
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

From matthieu.vial@fr.non.schneider-electric.com  Fri Oct 29 07:09:14 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1001E3A6A71; Fri, 29 Oct 2010 07:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.151
X-Spam-Level: 
X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjTXS7EGk-aK; Fri, 29 Oct 2010 07:09:12 -0700 (PDT)
Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id B4F8F3A6946; Fri, 29 Oct 2010 07:09:11 -0700 (PDT)
Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2010102915574936-56556 ; Fri, 29 Oct 2010 15:57:49 +0200 
In-Reply-To: 
To: Peter Bigot 
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: matthieu.vial@fr.non.schneider-electric.com
Date: Fri, 29 Oct 2010 16:11:02 +0200
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 29/10/2010 16:10:50, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 29/10/2010 15:57:49, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 29/10/2010 15:57:50
Content-type: multipart/related;  Boundary="0__=4EBBFD58DFD999F98f9e8a93df938690918c4EBBFD58DFD999F9"
Cc: core-bounces@ietf.org, core 
Subject: Re: [core] What's to be presented to IESG in December?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 14:09:14 -0000

--0__=4EBBFD58DFD999F98f9e8a93df938690918c4EBBFD58DFD999F9
Content-type: multipart/alternative; 
	Boundary="1__=4EBBFD58DFD999F98f9e8a93df938690918c4EBBFD58DFD999F9"

--1__=4EBBFD58DFD999F98f9e8a93df938690918c4EBBFD58DFD999F9
Content-transfer-encoding: quoted-printable
Content-type: text/plain; charset=ISO-8859-1




Hi Peter,

>I feel coap-block is unnecessary if one can defer to alternative proto=
cols
(and we will need Uri-Scheme back to enable that, which I very much wan=
t)
and therefore would not use it myself, but >with a change that prevents=

servers from introducing it in the response when Block doesn't appear i=
n
the request---and pending a final review---I would support it for Decem=
ber.

I think we should clearly expose the use cases where coap-block would b=
e
necessary.
I see the following items from the previous emails.
1) transfer resources larger than the 1280-x limit
2) force small transactions due to limited available RAM for CoAP buffe=
rs
3) semantic segmentation of a large resource to be able to produce and
consume it incrementally. It also reduces the hardware (RAM, CPU)
requirements to process the resource.
4) optimize link-layer fragmentation and avoid network congestion

Protocols like tftp would probably only solve item 1) and maybe 4) with=
in
limits.
Do you think other items are acceptable and need a solution ?

Regards,
Matthieu






                                                                       =
    
             Peter Bigot                                               =
    
                                                                 =
  A 
             Envoy=E9 par :              Zach Shelby     
             core-bounces@ietf                                         =
 cc 
             .org                      core             =
    
                                                                     Ob=
jet 
                                       Re: [core] What's to be presente=
d   
             29/10/2010 14:37          to IESG in December?            =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    




I am worried that coap-observe sets precedence for using CoAP with mult=
iple
responses to a single request.=A0 I would be much less concerned, and m=
ight
support it technically, if it were changed to use a new method instead =
of a
200 response for its announcements, but I don't think that can be
satisfactorily designed and evaluated before December.=A0 So, I object =
to
promotion of coap-observe in this time frame.

I feel coap-block is unnecessary if one can defer to alternative protoc=
ols
(and we will need Uri-Scheme back to enable that, which I very much wan=
t)
and therefore would not use it myself, but with a change that prevents
servers from introducing it in the response when Block doesn't appear i=
n
the request---and pending a final review---I would support it for Decem=
ber.

I have not read the slice-related draft, but feel it is far too close t=
o
December (five weeks) to go that way.

I'm not worried about innovation; I certainly expect to use a variety o=
f
alternative solutions for observe, all at the application level.=A0 But=
 I
think the perception of the Internet community will be that CoRE workin=
g
group/IETF is implicitly recommending a specific approach by releasing =
it
along with the main document.=A0 I don't plan to use it (or support it)=
; my
impression from comments from others is that they wouldn't either; and
we're back at the dozen-incompatible-solutions situation, without the
motivation to unify them that absence of a formal IETF solution would
provide.

That CoAP does not have provision for user-defined options and methods
makes it much harder to innovate compatibly, but that's another topic.

My motivation to volunteer to review ways to support observe in the bas=
e
protocol for discussion in Beijing was to help satisfy the charter
requirement for an observation capability.=A0 My assessment is that obs=
erve
is a hard problem with a lot of application-influenced variables and
constraints, and there is too little experience with the protocol in re=
al
applications and environments to formally recognize any single solution=
 as
preferred at this time.=A0 If the working group disagrees with this
assessment, or the charter requirement is to be met some other way such=
 as
by proposing a specific solution, I don't see any need to do such a rev=
iew
now.=A0 It merely distracts from the job of getting something out in
December.

Peter

On Fri, Oct 29, 2010 at 6:28 AM, Zach Shelby  wrote=
:

      On Oct 29, 2010, at 2:16 PM, Peter Bigot wrote:

      > - The appearance in coap-03 of the option values associated wit=
h
      the drafts for coap-observe and coap-block


      To be clear, I did this only as a temporary placeholder for those=

      option type IDs to prevent collisions with people working with
      experimental options in other drafts. It is not meant to be
      interpreted that core-block and core-observe need to go to the IE=
SG
      at precisely the same time (nor that those table values even need=
 to
      be in the CoAP RFC). Now that they are both WG documents I think =
this
      is helpful to list them in the coap option table for now.

      In my personal opinion, it is most important that we concentrate =
on
      completing core-coap in December according to our charter. Howeve=
r,
      as core-block and core-observe are both part of the same charter =
work
      item, it would be a good goal to have them in stable shape at the=

      same time. The chairs will surely give more information on the
      procedure.

      Peter, it seems you are worried about future innovation around Co=
RE?
      I wouldn't be. coap-block and coap-observe are two optional
      mechanisms that can be used with CoAP to fulfill basic applicatio=
n
      requirements we have. After this charter is fulfilled, we'll have=
 the
      opportunity to re-charter the WG and to work on new things. This =
is a
      really good WG in my opinion and people have already identified
      useful future work, so I think we definitely should aim at
      re-chartering.

      Zach

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



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
=

--1__=4EBBFD58DFD999F98f9e8a93df938690918c4EBBFD58DFD999F9
Content-transfer-encoding: quoted-printable
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline



Hi Peter,



>I feel coap-block is unnecessary if one can defer =
to alternative protocols (and we will need Uri-Scheme back to enable th=
at, which I very much want) and therefore would not use it myself, but =
>with a change that prevents servers from introducing it in the resp=
onse when Block doesn't appear in the request---and pending a final rev=
iew---I would support it for December.



I think we should clearly expose the use cases where c=
oap-block would be necessary.

I see the following items from the previous emails.

1) transfer resources larger than the 1280-x limit

2) force small transactions due to limited available R=
AM for CoAP buffers

3) semantic segmentation of a large resource to be abl=
e to produce and consume it incrementally. It also reduces the hardware=
 (RAM, CPU) requirements to process the resource.

4) optimize link-layer fragmentation and avoid network=
 congestion



Protocols like tftp would probably only solve item 1) =
and maybe 4) within limits.

Do you think other items are acceptable and need a sol=
ution ?



Regards,

Matthieu





3D"InactivePeter Bigot <pab@peoplepowerco.com>










=




    

      

        

          Peter Bigot <pab@peoplepowerco.com> 
          
Envoy=E9 par : core-bounces@ietf.org

          29/10/2010 14:37
        

      

    



=


3D""


A
3D""

Zach Shelby <zach@sensinode.com>		


3D""


cc
3D""

core <core@ietf.org>



3D""


Objet
3D""

Re: [core] What's to be presented to IESG in December?=








3D""3D=









I am worried that coap-observe sets precedence for usi=
ng CoAP with multiple responses to a single request.=A0 I would be much=
 less concerned, and might support it technically, if it were changed t=
o use a new method instead of a 200 response for its announcements, but=
 I don't think that can be satisfactorily designed and evaluated before=
 December.=A0 So, I object to promotion of coap-observe in this time fr=
ame.



I feel coap-block is unnecessary if one can defer to alternative protoc=
ols (and we will need Uri-Scheme back to enable that, which I very much=
 want) and therefore would not use it myself, but with a change that pr=
events servers from introducing it in the response when Block doesn't a=
ppear in the request---and pending a final review---I would support it =
for December.



I have not read the slice-related draft, but feel it is far too close t=
o December (five weeks) to go that way.



I'm not worried about innovation; I certainly expect to use a variety o=
f alternative solutions for observe, all at the application level.=A0 B=
ut I think the perception of the Internet community will be that CoRE w=
orking group/IETF is implicitly recommending a specific approach by rel=
easing it along with the main document.=A0 I don't plan to use it (or s=
upport it); my impression from comments from others is that they wouldn=
't either; and we're back at the dozen-incompatible-solutions situation=
, without the motivation to unify them that absence of a formal IETF so=
lution would provide.



That CoAP does not have provision for user-defined options and methods =
makes it much harder to innovate compatibly, but that's another topic.<=
br>


My motivation to volunteer to review ways to support observe in the bas=
e protocol for discussion in Beijing was to help satisfy the charter re=
quirement for an observation capability.=A0 My assessment is that obser=
ve is a hard problem with a lot of application-influenced variables and=
 constraints, and there is too little experience with the protocol in r=
eal applications and environments to formally recognize any single solu=
tion as preferred at this time.=A0 If the working group disagrees with =
this assessment, or the charter requirement is to be met some other way=
 such as by proposing a specific solution, I don't see any need to do s=
uch a review now.=A0 It merely distracts from the job of getting someth=
ing out in December.



Peter



On Fri, Oct 29, 2010 at 6:28 AM, Zach Shelby <zach@sensinode.com> wrote:

    


      
On Oct 29, 2010, at 2:16 PM, Peter Bigot wrote:
      

      
> - The appearance in coap-03 of the option values associated with t=
he drafts for coap-observe and coap-block
      

      

      
To be clear, I did this only as a temporary placeholde=
r for those option type IDs to prevent collisions with people working w=
ith experimental options in other drafts. It is not meant to be interpr=
eted that core-block and core-observe need to go to the IESG at precise=
ly the same time (nor that those table values even need to be in the Co=
AP RFC). Now that they are both WG documents I think this is helpful to=
 list them in the coap option table for now.
      

      
In my personal opinion, it is most important that we concentrate on com=
pleting core-coap in December according to our charter. However, as cor=
e-block and core-observe are both part of the same charter work item, i=
t would be a good goal to have them in stable shape at the same time. T=
he chairs will surely give more information on the procedure.
      

      
Peter, it seems you are worried about future innovation around CoRE? I =
wouldn't be. coap-block and coap-observe are two optional mechanisms th=
at can be used with CoAP to fulfill basic application requirements we h=
ave. After this charter is fulfilled, we'll have the opportunity to re-=
charter the WG and to work on new things. This is a really good WG in m=
y opinion and people have already identified useful future work, so I t=
hink we definitely should aim at re-chartering.
      

      
Zach
      

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

    






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

core mailing list

core@ietf.org

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



=


--1__=4EBBFD58DFD999F98f9e8a93df938690918c4EBBFD58DFD999F9--


--0__=4EBBFD58DFD999F98f9e8a93df938690918c4EBBFD58DFD999F9
Content-type: image/gif; 
	name="pic15890.gif"
Content-Disposition: inline; filename="pic15890.gif"
Content-ID: <1__=4EBBFD58DFD999F98@Schneider-Electric.com>
Content-Transfer-Encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==


--0__=4EBBFD58DFD999F98f9e8a93df938690918c4EBBFD58DFD999F9--


From heer@informatik.rwth-aachen.de  Fri Oct 29 08:12:27 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F793A6A79 for ; Fri, 29 Oct 2010 08:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-2.209,  BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQokTjC+UEE5 for ; Fri, 29 Oct 2010 08:12:22 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id A32393A6949 for ; Fri, 29 Oct 2010 08:12:21 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LB200EO54ZQC500@mta-1.ms.rz.RWTH-Aachen.de> for core@ietf.org; Fri, 29 Oct 2010 17:14:14 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.58,259,1286143200";   d="scan'208";a="42125197"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Fri, 29 Oct 2010 17:14:14 +0200
Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LB200GQS4ZQB290@relay-auth-2.ms.rz.rwth-aachen.de> for core@ietf.org; Fri, 29 Oct 2010 17:14:14 +0200 (CEST)
From: Tobias Heer 
In-reply-to: <4CCAC5DF.5090201@gmail.com>
Date: Fri, 29 Oct 2010 17:14:14 +0200
Content-transfer-encoding: quoted-printable
Message-id: <03481F84-F3DE-4794-B826-4336A187FC8F@cs.rwth-aachen.de>
References:   <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> <4CA3BB54.8050706@gmail.com>  <4CA5E8E0.4030503@gmail.com>  <4CA6095F.6040403@gmail.com>  <4CB48B9B.9010206@gmail.com> <4CBF03D6.3050903@gmail.com> <44203C3A-2A58-4880-BDC9-7E0C3D16A49A@cs.rwth-aachen.de> <4CBF11BC.5040301@gmail.com>  <4CBF5288.5090706@gmail.com> <4CCAC5DF.5090201@gmail.com>
To: Rene Struik 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] HIP identities and puzzle
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 15:12:27 -0000

Hello Rene,

thanks for picking this up again.

First, one has to distinguish HIP and DEX (as proposed by Robert). HIP =
is (as defined in 5201) the base protocol and DEX would be the trimmed =
down variant for resource constrained scenarios. However, the DEX is =
certainly still WIP and can probably be bent in one or the other =
direction (if needed). I am not an author of the DEX and I somehow ended =
up mandating HIP here although CoRE is certainly not my primary field of =
work. Hence, I'd like to state that my intention is not to claim that =
HIP is the best protocol for CoRE. I simply don't know CoRE well enough =
to make such statement. However, I can try to answer some questions =
related to HIP so that CoRE WG can make a sound decision on whether HIP =
is something to consider or if it isn't.

Am 29.10.2010 um 15:02 schrieb Rene Struik:

> Hi Tobias:
>=20
> It would help to have some more insight into claimed functionality of =
the HIP protocol. We had some correspondence on this over the last 4 =
weeks, but unfortunately detail as to claimed security properties,

I) Which specific security properties are unclear to you? Maybe we can =
narrow things down a bit. Otherwise I might end up repeating the whole =
protocol as described in RFC5201 here.

> distinguishing features w.r.t. other protocols,

II) Distinguishing features of HIP are (in my opinion):

On a conceptual level:
  a) the implementation of the locator/identifier split,=20

  b) the quite flexible protocol design (emphasis on extendability - =
many people have successfully used HIP for quite different scenarios by =
extending and modifying the base protocol without breaking =
compatibility),

  c) the identity-focused namespace based on cryptographic identities,

  d) its integration within the stack. Upper layers just use HITs like =
IPv6 addresses and HIP takes care of establishing and maintaining an =
authenticated and encrypted channel to the other host. =20


Features on a more technical level are:
  e) A 4-way handshake that includes authentication of both peers, =
generation of a shared secret and set-up of an encrypted payload =
channel. Depending on the scenario, this four-way handshake might be =
better than, e.g., the multi-packet flight-based exchange of DTLS that =
sends more packets. However, I am aware that HIP needs optimizations in =
the form of DEX to avoid fragmentation and DTLS could probably be =
modified to avoid multi-packet flights.

  f) DoS prevention: HIP implements two different mechanisms here: =
return routability checks and puzzles. However, depending on the =
scenario, these may be applicable or may be not applicable for CoRE. I'd =
be happy to discuss this.

All aforementioned points (a-f) are valid for HIP and DEX.
I will gladly give a more detailed explanation of these points if you =
wish - just tell me which requires further elaboration.

> computational benefits over other approaches


HIP uses an authenticated Diffie Hellman key exchange. In terms of =
public key operations, it does:

2 public key verifications at the Initiator side
1 public key verification at the Responder side
1 public key signature at the Initiator side
1 public key signature at the Responder side
1 offline public key signature at the Responder side
1 DH shared key generation at the Initiator side
1 DH shared key generation at the Responder side

This is certainly not an optimal design for tightly resource constrained =
devices. Hence, Robert tried to reduce the number of computations needed =
without changing the way HIP works.
DEX (as proposed by Robert) uses a static Diffie Hellman key exchange =
and amounts to:

1 DH shared key generation at the Initiator side
1 DH shared key generation at the Responder side

The actual cost of these operations depends on the chosen DH groups/ ECC =
curves but the set algorithms is interchangeable and can be adopted to =
the needs of the scenario.

The aforementioned numbers don't reflect the cost of the use of an =
additional third-party certificate (which I believe you would like to =
see in a handshake). Hence, certificate verification at the sender or =
receiver should be added to the cost if the scenario demands it.

I hope this gives you a rough feeling for the cryptographic cost of =
running HIP/DEX.

> Moreover, I still have trouble to understand how the protocol could =
facilitate separation of device ids and cryptographic objects, as seems =
to be beneficial in deployment scenarios, such as large scale =
manufacturing of sensor nodes.

Ren=E9 Hummen is currently preparing a draft on the solution that I =
mentioned in my previous mail. I hope he is done before or shortly after =
Beijing. I hope this document will answer your questions.

>=20
> If you could elaborate and put the issues to rest, that would be =
great.
>=20
Sure. I hope the explanations above shed some light on the open =
questions regarding HIP. I tried to put each argument/point to a new =
line to make it easy for you to indicate which you would like to discuss =
in more detail.

> For the benefit of easy comprehension, I would suggest a succinct =
description (perhaps, with mathematical description of security-relevant =
portions of the protocol flows, properties, etc?).
>=20
I believe Rene Hummen is preparing this, too. I hope the sum of the =
cryptographic operations is enough for now to develop a feeling for the =
cost.

> I am sending this to the list, since Carsten Bormann is right: the =
group as a whole would benefit from technical discussions.
>=20
Sure.

Best regards,

Tobias



> Best regards, Rene
>=20
> On 20/10/2010 4:35 PM, Rene Struik wrote:
>> Hi Tobias:
>>=20
>> If the device's public key and the CA's signature verification key =
are similar mathematical objects (e.g., both are on the same elliptic =
curve), then the crypto real estate to perform certificate self-tests =
can be made to reuse that used to perform key computations with an =
authenticated key agreement scheme that uses certs. Obviously, this =
would require the device to have access to an authentic copy of the CA's =
signature verification key. If the CA's public key is not available, it =
cannot check its own cert an alternative authentic channel has to be =
established between the device and an external party who attests to the =
authenticity of the cert. This being said, I do not know of practical =
scenarios where the latter limitation arises (usually, one does not =
accept any cert for which one does not already have a bootstrapped [or =
not] root CA key).
>>=20
>> It seems somewhat dangerous to use certs to bind arbitrary strings to =
public keys if the semantics of that string is not well-understood or =
can be defined at will be another process. After all, if the string is =
StrA and semantics of one application defines this as "temperature =
sensor A", while another application defines this as "thermometer B", =
confusion may arise: does (StrA, PublicKey) relate to some physical =
device A or some physical device B? Not sure how this can be avoided if =
one does not stipulate that for any semantics one may define, the =
mapping String --> Globally Unique Device Id is an injection. =
Intuitively, this seems to suggest that each string contains an object =
that is 1-1 mappable to this globally unique device id.
>>=20
>> Best regards, Rene
>>=20
>>=20
>>=20
>> On 20/10/2010 2:37 PM, Tobias Heer wrote:
>>> Hi Rene,
>>>=20
>>> Am 20.10.2010 um 17:58 schrieb Rene Struik:
>>>=20
>>>> Hi Tobias:
>>>>=20
>>>> No worries - I am just curious to see how HIP fits in with =
ubiquitous networks of smart objects, why one would care about the =
protocol, and which use cases are enabled. Depending the outcome hereof, =
it may be worth pointing to in IETF drafts etc.
>>>>=20
>>>> Some brief comments below (enclosed by RS>>  and<>>>=20
>>>> Best regards, Rene
>>>>=20
>>>> On 20/10/2010 11:31 AM, Tobias Heer wrote:
>>>>> Hi Rene,
>>>>>=20
>>>>> First: thanks for your feedback. [snip(RS)]. I'll respond to the =
quick questions immediately and will come back with a more detailed and =
better specified description in a couple of days. Actually Ren=E9 Hummen =
might respond instead of me.
>>>>>=20
>>>>> Am 20.10.2010 um 16:59 schrieb Rene Struik:
>>>>>=20
>>>>>> Hi Tobias, Zhen:
>>>>>>=20
>>>>>> I would be indebted if you could provide some feedback on my =
email as of Tuesday last week (October 12, 2010, 12:23pm EDT - - cf. =
below).
>>>>>>=20
>>>>>> Best regards, Rene
>>>>>>=20
>>>>>> On 12/10/2010 12:23 PM, Rene Struik wrote:
>>>>>>> Hi Tobias:
>>>>>>>=20
>>>>>>> Thanks for your note.
>>>>>>>=20
>>>>>>> Does your "ascii art" description, Step 1)-3) allow the =
scenario, where (a) one assigns a node id and imprints this (e.g., =
blowing fuse during chip testing);
>>>>>>> (b) has a node generating its own long-term public/private key =
pair and outputting its node id and public key (e.g., during chip =
testing -- this would
>>>>>>> correspond to registering a public key with an RA); (c) have CA =
create a certificate in different process and return this value at later =
production/
>>>>>>> personalization stage?
>>>>> a) yes it would
>>>>> b) yes, the node could generate the static DH key by itself and =
acquire a certificate for this key (e.g., at deployment time)
>>>>> c) I am not completely sure what you mean with "different process" =
and "return" however, I can outline the possible flexibility that one =
would have:
>>>>>=20
>>>> RS>>
>>>> Setting would be where one would register a pair (Device Id, Public =
key) during production, ship a database of these pairs to a CA, have the =
latter generating a certificate for (Device Id, Public key) pairs of its =
choosing and tie this to associated keying material (such as policy =
field, validity period, and the-like). Certificates themselves could =
then find a way back to a device via any other communication channel =
(does not require online/inline involvement of CA and could, e.g., by =
provided when personalized in a BestBuy shop, using a BestBuy CA (note =
that BestBuy CA would then have to relie on the RA used during =
production - the one that collected the database).
>>>> <>>>> (I am taking about DEX now, not HIP BEX)
>>>>>=20
>>>>> i)   The static DH key can either be node-generated or imprinted =
by some entity (in a secure environment)
>>>>> ii)  The certificate can either be imprinted when the node is =
manufactured or it can be imprinted later (again, in a secure =
environment)
>>>> RS>>
>>>> Not sure why imprinting of certificate (authorization of state =
change aside) would need to be done in secured environment in general, =
since this is public piece of information.
>>>> <>> Sure, the information is public but nodes that cannot verify their =
own certificate (I do not assume that all nodes are able to verify =
digital signatures. However, I am not sure if it is useful to assume =
that a host supports ECDH but not ECDSA) might accept an invalid =
certificate and could, from that moment on, not authenticate towards a =
legitimate host anymore. The secure environment is not needed if a) a =
node can verify its own certificate or b) if the node can verify the =
identity of the device that imprints the certificate.
>>>=20
>>>>> iii) The certificate could be renewed at any time (provided there =
is a secure mechanism for that)
>>>>> iv)  The DH public key could be renewed as well (at any time), =
however, a node would require a new certificate, authenticating the new =
DH key then
>>>>>=20
>>>>> For BEX, nodes' identity would be the RSA/DSA/ECDSA key of the =
node instead of the static DH public key. Hence, the ephemeral DH key =
would change more often while the ECDSA public key would be in the =
certificate.
>>>>>=20
>>>> RS>>
>>>> I still have some trouble understanding how identifying nodes by =
their public key is going to satisfy use case scenarios where one may =
have changes to the public key, different certificates, and the-like. =
Please note that the objective of certificates is to provide for a =
secure binding between a device's id and its private key (via the =
corresponding public key), thus freeing one to just use device ids -- =
after all, certificate processing would then yield the corresponding =
public key(s) purportedly owned by that device.
>>>> <>> The certificate would bind a string to the public key (static DH or =
RSA/DSA/ECDSA). The string would be used by layers above HIP. HIP maps =
the string to the static public key of the peer in the BEX by using the =
certificate that the peer provides. A device is therefore identified by =
a string not a public key (as in vanilla HIP).
>>>=20
>>>>>>> Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, =
I get the impression that HIP does execute an authenticated DH key =
agreement scheme. If so,
>>>>>>> this makes me wonder how HIP differentiates from protocols, such =
as ECMQV and, e.g., HMQV, which are all not that much more expensive =
than ECDH. If the
>>>>>>> difference is in the "puzzle" element, couldn't one just add =
something similar to a well-known authenticated scheme that is already =
standardized with, e.g.,
>>>>>>> NIST?
>>>>> I'll let Ren=E9 Hummen respond to this question.
>>>>>=20
>>>> RS>>
>>>> Sure - looking forward to this. This would be easy to compare, once =
one has succinct description of the cryptographic aspects of the =
protocol (so that, e.g., one can count the number of scalar point =
multiplications involved, etc.).
>>>> <>>>>>> As to forward secrecy: reason to include this is that many =
sensor-type nodes can be expected to be physically unprotected (e.g., =
screwed on a street lamp
>>>>>>> post, on a garage roof, etc.) and, therefore, may be more =
vulnerable to device compromise over time (esp. since one cannot expect =
all nodes to be tamper
>>>>>>> resistant or tamper evident). By virtue of forward secrecy, =
compromise over time does not compromise the whole device's history, but =
only the current set of
>>>>>>> symmetric keys (note: I make some shortcuts in my reasoning on =
key management here). Admittedly, my list of security properties is =
based on "desired"
>>>>>>> functionality and does not exclude functionality that may =
require, e.g., public-key crypto constructs. However, from a user's =
perspective, the only thing that
>>>>>>> matters is features and not what is "under the hood", as long as =
that is not cost-prohibitive (which I contend it is not -- cf., e.g., =
Section 3.2 of
>>>>>>> draft-struik-6lowapp-security-considerations-00). (BTW - All =
other desired security properties I listed have an underlying =
rationale.)
>>>>> I am still somewhat unsure about cost and capabilities of the =
targeted devices. Depending on who you talk to, people seem to expect =
sensors that are capable of ECC crypto, barely capable or not capable at =
all.
>>>>> Are there minimal hardware specs for target devices?
>>>>>=20
>>>> RS>>
>>>> Almost all 802.15.4-based modules have hardware support for AES-128 =
(in forward mode). Since the MAC layer requires error detection using =
CRC-16 linear feedback shift regsiter circuits (which is a no brainer) =
and since, e.g., elliptic curves over binary extension fields can be =
realized using shift registers that are of order of magnitude anything =
up to 256 registers, I do not see a problem for hardware support here =
(once implemented in large scale environments).
>>>>=20
>>>> Source: http://2010.eccworkshop.org/
>>>> Junfeng Fan(K.U.Leuven, =
Belgium)
>>>> /ECC on constrained devices/
>>>> The embedded security community has been looking at the ECC ever =
since it was introduced. Hardware designers are now challenged by =
limited area (<15k Gates), low power budget (<100uw) and sophisticated =
physical attacks. This talk will report the state-of-the-art ECC =
implementations for ultra-constrained devices. We take a passive RFID =
tag as our potential target. We will discuss the known techniques to =
realize ECC on such kind of devices, and what are the challenges we face =
now and in the near future.
>>>> <>> Impressive. I'll certainly give it a closer look.
>>>=20
>>> Tobias
>>>=20
>>=20
>>=20
>=20
>=20
> --=20
> email: rstruik.ext@gmail.com
> Skype: rstruik
> cell: +1 (647) 867-5658
> USA Google voice: +1 (415) 690-7363
>=20




--=20
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi








From pab@peoplepowerco.com  Fri Oct 29 08:12:57 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90443A6A21 for ; Fri, 29 Oct 2010 08:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.724
X-Spam-Level: 
X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.252,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCPiIS2V2c7X for ; Fri, 29 Oct 2010 08:12:56 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1670E3A6A90 for ; Fri, 29 Oct 2010 08:12:55 -0700 (PDT)
Received: by fxm9 with SMTP id 9so3291727fxm.31 for ; Fri, 29 Oct 2010 08:14:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.96.204 with SMTP id i12mr861380fan.145.1288365288628; Fri, 29 Oct 2010 08:14:48 -0700 (PDT)
Received: by 10.223.83.207 with HTTP; Fri, 29 Oct 2010 08:14:48 -0700 (PDT)
Date: Fri, 29 Oct 2010 10:14:48 -0500
Message-ID: 
From: Peter Bigot 
To: matthieu.vial@fr.non.schneider-electric.com
Content-Type: multipart/alternative; boundary=20cf30433ef65f61960493c2eba3
Cc: core 
Subject: [core] CoAP block use cases (was Re: What's to be presented to IESG in December?)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 15:12:57 -0000

--20cf30433ef65f61960493c2eba3
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 29, 2010 at 9:11 AM, <
matthieu.vial@fr.non.schneider-electric.com> wrote:

> >I feel coap-block is unnecessary if one can defer to alternative protocols
> (and we will need Uri-Scheme back to enable that, which I very much want)
> and therefore would not use it myself, but >with a change that prevents
> servers from introducing it in the response when Block doesn't appear in the
> request---and pending a final review---I would support it for December.
>
> I think we should clearly expose the use cases where coap-block would be
> necessary.
>

Agreed, almost.  Let's expose the use cases where "something like
coap-block" would be necessary.  A quick attempt at "something like"
produced "a client or server cannot transmit or receive a request or
response for a particular resource representation in a single CoAP message
while meeting system quality requirements such as avoiding
link-layer--induced fragmentation", which is just gross regardless of
whether it's accurate.


> I see the following items from the previous emails.
> 1) transfer resources larger than the 1280-x limit
>

There is no 1280-x limit.  The formal limit is the size of an IP datagram.
Any specific numeric limit imposes an assumption of an underlying IP version
and perhaps link technology, which I argued last summer was inappropriate
for CoAP.  We could revisit that position.  But yes, even for an IP datagram
limit, this is a valid use case.


> 2) force small transactions due to limited available RAM for CoAP buffers
>

Yes.  The size-related options proposed too late for inclusion in -03 would
be a good approach to ensure this situation is detected and handled, and are
arguably a MUST for the final version.


> 3) semantic segmentation of a large resource to be able to produce and
> consume it incrementally. It also reduces the hardware (RAM, CPU)
> requirements to process the resource.
>

If there's a semantic segmentation within the resource representation, I
think each segment should be treatable as a distinguished resource.  That
could be as simple as adding a numeric or symbolic component at the end of
the path component of the URI for the the aggregate resource.  Or defining
"first" and "next" keys in a query part and using POST, if you want to
dynamically generate the representation.  Absence of those keys would
require that the entire resource be returned in a single representation,
through whatever mechanism that is done.


> 4) optimize link-layer fragmentation and avoid network congestion
>

How CoAP should accommodate link-layer limits that are smaller than
IP-datagram limits, given that there is no requirement to provide access to
those limits, is an open question.  Again, the size-related options would at
least provide a way for the client and server to negotiate the transaction
limits via application or even CoAP-level configuration.


> Protocols like tftp would probably only solve item 1) and maybe 4) within
> limits.
> Do you think other items are acceptable and need a solution ?
>

(2) yes, though I don't see why tftp doesn't work there too.  (3) I think
should be solved at the architectural level in the API, not within the
transfer protocol.

For non-semantic segmentation and to enable a coap-only implementation, I
think the block option can be made to work (with that change I mentioned,
and maybe a little more investigation into the impacts of random access
and/or dropped packets in the face of dynamic representation generation).
That I currently believe TFTP is a superior approach for my own systems is
an architectural trade-off based on my strong preference to re-use existing,
proven solutions unless they're clearly inappropriate.

Peter

--20cf30433ef65f61960493c2eba3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Oct 29, 2010 at 9:11 AM,  <matt=
hieu.vial@fr.non.schneider-electric.com> wrote:



>I feel coap-block is unnecessary if one can defer to a=
lternative protocols (and we will need Uri-Scheme back to enable that, whic=
h I very much want) and therefore would not use it myself, but >with a c=
hange that prevents servers from introducing it in the response when Block =
doesn't appear in the request---and pending a final review---I would su=
pport it for December.





I think we should clearly expose the use cases where=
 coap-block would be necessary.

Agree=
d, almost.=A0 Let's expose the use cases where "something like coa=
p-block" would be necessary.=A0 A quick attempt at "something lik=
e" produced "a client or server cannot transmit or receive a requ=
est or response for a particular resource representation in a single CoAP m=
essage while meeting system quality requirements such as avoiding link-laye=
r--induced fragmentation", which is just gross regardless of whether i=
t's accurate.

=A0

I see the following items from the previous emails.=


1) transfer resources larger than the 1280-x limit<=
br>

There is no 1280-x limit.=A0 The formal limi=
t is the size of an IP datagram.=A0 Any specific numeric limit imposes an a=
ssumption of an underlying IP version and perhaps link technology, which I =
argued last summer was inappropriate for CoAP.=A0 We could revisit that pos=
ition.=A0 But yes, even for an IP datagram limit, this is a valid use case.=


=A0

2) force small transactions due to limited available RAM f=
or CoAP buffers

Yes.=A0 The size-rela=
ted options proposed too late for=20
inclusion in -03 would be a good approach to ensure this situation is detec=
ted and handled, and are=20
arguably a MUST for the final version.
=A0

3) semantic segmentation of a large resource to be able to=
 produce and consume it incrementally. It also reduces the hardware (RAM, C=
PU) requirements to process the resource.


If there's a semantic segmentation within the resource representati=
on, I think each segment should be treatable as a distinguished resource.=
=A0 That could be as simple as adding a numeric or symbolic component at th=
e end of the path component of the URI for the the aggregate resource.=A0 O=
r defining "first" and "next" keys in a query part and =
using POST, if you want to dynamically generate the representation.=A0 Abse=
nce of those keys would require that the entire resource be returned in a s=
ingle representation, through whatever mechanism that is done.

=A0

4) optimize link-layer fragmentation and avoid network con=
gestion

How
 CoAP should accommodate link-layer limits that are smaller than=20
IP-datagram limits, given that there is no requirement to provide access to=
 those limits, is=20
an open question.=A0 Again, the size-related options would at least provide=
 a way for the client and server to negotiate the transaction limits via ap=
plication or even CoAP-level configuration.
=A0


Protocols like tftp would probably only solve item 1) and =
maybe 4) within limits.

Do you think other items are acceptable and need a solutio=
n ?

(2) yes, though I don't see why t=
ftp doesn't work there too.=A0 (3) I think should be solved at the arch=
itectural level in the API, not within the transfer protocol.


For non-semantic segmentation and to enable a coap-only implementation,=
 I think the block option=20
can be made to work (with that change I mentioned, and maybe a little more =
investigation into the impacts of random access and/or dropped packets in t=
he face of dynamic representation generation).=A0 That I currently believe =
TFTP is a=20
superior approach for my own systems is an architectural trade-off based on=
 my strong preference=20
to re-use existing, proven solutions unless they're clearly inappropria=
te.

Peter



--20cf30433ef65f61960493c2eba3--

From fluffy@cisco.com  Fri Oct 29 10:01:30 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5CE3A67DB for ; Fri, 29 Oct 2010 10:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.444
X-Spam-Level: 
X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veuCwfoA0tmz for ; Fri, 29 Oct 2010 10:01:30 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1AFEE3A682B for ; Fri, 29 Oct 2010 10:01:30 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOaaykyrRN+K/2dsb2JhbAChVHGjJpwehUgEhFeFfIMI
X-IronPort-AV: E=Sophos;i="4.58,260,1286150400"; d="scan'208";a="375759155"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2010 17:03:25 +0000
Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9TH3OKU011440; Fri, 29 Oct 2010 17:03:24 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Fri, 29 Oct 2010 11:03:33 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <55E9BB34-0A5B-4BCF-965A-34D1FB095CF2@cisco.com>
References: 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] What's to be presented to IESG in December?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 17:01:31 -0000

On Oct 29, 2010, at 5:16 AM, Peter Bigot wrote:

>=20
> To the WG chairs: is it your expectation that coap-observe and =
coap-block will be submitted to IESG in December along with the core =
CoAP document?


(WIth my chair hat on)

No - that was not my expectation. I would be surprised to see us have =
observer or block done at that point. I expected us to have the =
core-coap sent to IESG before the others. but the others well under way =
by the point core-coap goes to IESG. Which brings up a interesting =
question  for the group. When do we think that  draft-ietf-core-coap =
will be ready to send to IESG?=20=

From fluffy@cisco.com  Fri Oct 29 13:46:34 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2CE3A6857 for ; Fri, 29 Oct 2010 13:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.448
X-Spam-Level: 
X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skREPoKnpd5X for ; Fri, 29 Oct 2010 13:46:33 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 25B4E3A6767 for ; Fri, 29 Oct 2010 13:46:33 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAN/PykyrRN+K/2dsb2JhbAChUXGkDJwXhUgEhFeFfIMI
X-IronPort-AV: E=Sophos;i="4.58,261,1286150400"; d="scan'208";a="611653946"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2010 20:48:28 +0000
Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9TKmRnK024667; Fri, 29 Oct 2010 20:48:27 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Fri, 29 Oct 2010 14:48:36 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B46E7DD-0D06-46B1-AF6D-D934E2DDB3C6@cisco.com>
References: 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] http observe unification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 20:46:34 -0000

(inline and all of this in my individual contributor roll not my =
co-chair roll )

On Oct 28, 2010, at 6:43 AM, Peter Bigot wrote:

> Cullen:
>=20
> In the telecon yesterday, you objected to my proposal that the =
solution to the observation problem be left to designers of specific =
systems.

Yes - I think there should be at document that describes at least one =
way to do this. I don't care if there could be many ways to do it. I can =
see that there are some designs where you need to change or extend the =
underlying COAP protocol and there are also designs where it is layered =
on top with no change to COAP. I don't care too much which of the two it =
is as in the end that is really just moving where the bits are in the =
packet which I could care less about.=20

>  It sounded like you felt a reference document describing alternative =
approaches that applications might take would not be adequate. =20

sorry if I gave that impression - I'd love to see a document like that - =
it would help understand the design space. I am more concerned about =
having less than 1 solution than the problem of having more than 1 =
solution. I do not think the document that describes a solution has to =
be the same RFC as the base spec COAP spec and devices could choose if =
they were just doing the base spec or if they implemented base spec + an =
observation solution.=20

> Could you elaborate a little more here on what you believe CoAP must =
provide, and in what timeframe?

I don't care if it is in COAP, an extortion to COAP, or just a way of =
using COAP but I would like to see the WG produce a way of having a way =
for Application A to to say it wants to know about changes to resource B =
and when B changes, a message gets sent to A saying it changed. It's not =
really very complicated what I want. As my friend Dean says, there's =
many ways to skin this cat, I rather not see us use a potato peeler. Oh, =
and let me be clear on one more thing about it - I do not care in the =
slightest if anyone thinks it is REST or not, I just want my message =
when the resource changes and something that is reasonable to implement. =
I've got a pretty deep understanding of REST and I don't see how the =
concepts of REST actually help much with the conversation here. I do =
think discussion of what devices need to store state, for how long, and =
how much do help with the design as well as discussion of what is =
idempotent. The security and flexibility implications of various =
solutions are also interesting to consider along with the obvious issues =
of size, complexity, and efficiency.=20

>=20
> I understood you to say that some IETF working group was nearly =
complete with a proposed standard way to implement observation in HTTP.  =
Is that the Httpbis group?  To which of their documents were you =
referring?  draft-loreto-http-bidirectional is somewhat relevant (wrt =
streaming responses).

HyBy

http://tools.ietf.org/wg/hybi/draft-ietf-hybi-thewebsocketprotocol/

>=20
> The clearly relevant one is draft-roach-sip-http-subscribe, but that's =
based on SIP event notification.  Were we to take that approach, it =
might be best to define a CoAP-like protocol "csip", rather than =
integrate that functionality directly into CoAP.  On first glance, it =
appears this would be at least as much work as defining CoAP has been.  =
It would, though, give us a solution to observation, notification, and =
group communication that is compatible with the HTTP family of =
protocols, so is certainly worth considering.

I helped design the SIP Sub/Notify system and it's design goals were =
very different from what we are trying to do here. At a high level it is =
isomorphic to what we want but as you did into the details, it was =
optimized for something fairly different than the CoAP use cases. I'm =
certainly not pushing the approach that was used in SIP thought I tend =
to fall into using the terminology from SIP just because I know it well.=20=


>=20
> Thanks.
>=20
> Peter


From adam@nostrum.com  Fri Oct 29 14:55:20 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0E63A6A81 for ; Fri, 29 Oct 2010 14:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.626
X-Spam-Level: 
X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to3Y7s-uOQug for ; Fri, 29 Oct 2010 14:55:18 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B32F53A6853 for ; Fri, 29 Oct 2010 14:55:01 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9TLurvg038873 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 29 Oct 2010 16:56:53 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4CCB4325.4090708@nostrum.com>
Date: Fri, 29 Oct 2010 16:56:53 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: core@ietf.org
References:  <1B46E7DD-0D06-46B1-AF6D-D934E2DDB3C6@cisco.com>
In-Reply-To: <1B46E7DD-0D06-46B1-AF6D-D934E2DDB3C6@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Subject: Re: [core] http observe unification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 29 Oct 2010 21:55:21 -0000

On 10/29/10 3:48 PM, Cullen Jennings wrote:
> On Oct 28, 2010, at 6:43 AM, Peter Bigot wrote:
>> The clearly relevant one is draft-roach-sip-http-subscribe, but that's based on SIP event notification.  Were we to take that approach, it might be best to define a CoAP-like protocol "csip", rather than integrate that functionality directly into CoAP.  On first glance, it appears this would be at least as much work as defining CoAP has been.  It would, though, give us a solution to observation, notification, and group communication that is compatible with the HTTP family of protocols, so is certainly worth considering.
> I helped design the SIP Sub/Notify system and it's design goals were very different from what we are trying to do here. At a high level it is isomorphic to what we want but as you did into the details, it was optimized for something fairly different than the CoAP use cases. I'm certainly not pushing the approach that was used in SIP thought I tend to fall into using the terminology from SIP just because I know it well.

Oh, yeah, wow. You don't want to use SIP for this, unless you change 
what the "Co" stands for in "CoAP." You don't really even want to try to 
mirror its semantics into a CoAP-related protocol. One of the things I'm 
finding refreshing about CoAP at this stage of its life is that no one 
has started adding in giant arrays of nuclear-powered kitchen sinks. At 
least, not yet.

What we've done with SIP events is arbitrarily flexible, which is why 
it's used for everything from presence to dialog state monitoring, user 
agent configuration, and even certificate management. We've even seen 
proposals to use it to monitor automotive data in real-time. Really.

You don't need this.

Now, what's kind of nice about RFC 5989 (draft-roach-sip-http-subscribe 
was published as an RFC last night) is that it's a very simple use of 
SIP events. Just about any explicit observation model you come up with 
for CoAP should be able to interwork with RFC 5989 (at least, as long as 
you're using CoAP servers and HTTP clients -- I wouldn't want to try to 
make it go in the other direction, but I don't think that's on the table).

I really wouldn't focus on the semantics of the SIP events mechanism 
when you're designing CoAP observations, anyway. There are other ways to 
monitor for changes to a resource, such as PubSubHubbub, that are 
designed for certain niches.

In terms of a model that is simple, deployed, and works over UDP 
(well... and proprietary), you might look here for design inspiration: 
http://msdn.microsoft.com/en-us/library/aa143117%28EXCHG.65%29.aspx

/a

From cabo@tzi.org  Fri Oct 29 23:18:40 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54BBF3A67E4 for ; Fri, 29 Oct 2010 23:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSJCS8vwG8uF for ; Fri, 29 Oct 2010 23:18:39 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id CE2973A6768 for ; Fri, 29 Oct 2010 23:18:37 -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 o9U6KNO9006812; Sat, 30 Oct 2010 08:20:23 +0200 (CEST)
Received: from ip-109-40-178-121.web.vodafone.de (ip-109-40-178-121.web.vodafone.de [109.40.178.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 2C6DFA82; Sat, 30 Oct 2010 08:20:20 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <1B46E7DD-0D06-46B1-AF6D-D934E2DDB3C6@cisco.com>
Date: Sat, 30 Oct 2010 08:20:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <1B46E7DD-0D06-46B1-AF6D-D934E2DDB3C6@cisco.com>
To: Cullen Jennings 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] http observe unification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Oct 2010 06:18:40 -0000

On Oct 29, 2010, at 22:48, Cullen Jennings wrote:

> I do not care in the slightest if anyone thinks it is REST or not, I =
just want my message when the resource changes and something that is =
reasonable to implement. I've got a pretty deep understanding of REST =
and I don't see how the concepts of REST actually help much with the =
conversation here.

What could be RESTful about observation?  Indeed, we won't get that much =
direct guidance from the REST scriptures here..

I think the obvious (and interesting) property we want to achieve is =
that a proxy should be able to fan out observation notifications, i.e., =
if three clients want to observe the same resource through the same =
proxy, the proxy can make do with observing it once.  This property =
should be part of the architecture, not an application-specific hack.

(Why is that property interesting?  Because it allows constrained nodes =
to minimize their direct communication.)

Gruesse, Carsten


From pab@peoplepowerco.com  Sat Oct 30 05:51:19 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1D83A69F7 for ; Sat, 30 Oct 2010 05:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.727
X-Spam-Level: 
X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.249,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqHcv1n8sPyt for ; Sat, 30 Oct 2010 05:51:18 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 473253A69F5 for ; Sat, 30 Oct 2010 05:51:17 -0700 (PDT)
Received: by fxm9 with SMTP id 9so4107595fxm.31 for ; Sat, 30 Oct 2010 05:53:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.69.132 with SMTP id z4mr6777977fai.31.1288442667706; Sat, 30 Oct 2010 05:44:27 -0700 (PDT)
Received: by 10.223.83.207 with HTTP; Sat, 30 Oct 2010 05:44:27 -0700 (PDT)
In-Reply-To: 
References:  <1B46E7DD-0D06-46B1-AF6D-D934E2DDB3C6@cisco.com> 
Date: Sat, 30 Oct 2010 07:44:27 -0500
Message-ID: 
From: Peter Bigot 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=20cf30433f0085a8210493d4ef91
Cc: core 
Subject: Re: [core] http observe unification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Oct 2010 12:51:19 -0000

--20cf30433f0085a8210493d4ef91
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Oct 30, 2010 at 1:20 AM, Carsten Bormann  wrote:

> On Oct 29, 2010, at 22:48, Cullen Jennings wrote:
>
> > I do not care in the slightest if anyone thinks it is REST or not, I just
> want my message when the resource changes and something that is reasonable
> to implement. I've got a pretty deep understanding of REST and I don't see
> how the concepts of REST actually help much with the conversation here.
>
> What could be RESTful about observation?  Indeed, we won't get that much
> direct guidance from the REST scriptures here..
>

Much could be RESTful about observation.  It sounds like there's little
interest in pursuing the issue from that perspective, though.

The meta-concept behind REST is that having a well-defined set of
constraints to guide the architectural decisions helps ensure a scalable and
successful system.  Up to now, we've been using REST as the constraints to
help assess alternative approaches in CoAP.  What constraints are we using
for this problem?

I think the obvious (and interesting) property we want to achieve is that a
> proxy should be able to fan out observation notifications, i.e., if three
> clients want to observe the same resource through the same proxy, the proxy
> can make do with observing it once.  This property should be part of the
> architecture, not an application-specific hack.
>

Proposal: A proxy, as you are using the term, is an application.

Consequently, its behavior should be defined in a separate document from the
one that specifies the CoAP protocol: data encoding, supported metadata
(options), and transaction state machines.

(Why is that property interesting?  Because it allows constrained nodes to
> minimize their direct communication.)
>

Yes.  Observation in a constrained environment really involves four distinct
roles, not two.  Whether some of those roles are implemented on the same
end-point is necessarily going to be a system-specific decision.

And I'm really not looking forward to trying to explain over email why that
is so.

Peter

--20cf30433f0085a8210493d4ef91
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sat, Oct 30, 2010 at 1:20 AM, Carsten Bormann=
 <cabo@tzi.org>=
 wrote:


On Oct 29, 2010, at 22:48, Cullen Jennings wrote:



> I do not care in the slightest if anyone thinks it is REST or not, I j=
ust want my message when the resource changes and something that is reasona=
ble to implement. I've got a pretty deep understanding of REST and I do=
n't see how the concepts of REST actually help much with the conversati=
on here.





What could be RESTful about observation? =A0Indeed, we won't get =
that much direct guidance from the REST scriptures here..
<=
div>
Much could be RESTful about observation.=A0 It sounds like there=
9;s little interest in pursuing the issue from that perspective, though.

The meta-concept behind REST is that having a well-defined set of const=
raints to guide=20
the architectural decisions helps ensure a scalable and successful=20
system.=A0 Up to now, we've been using REST as the constraints to help =
assess alternative approaches in CoAP.=A0 What constraints are we using for=
 this problem?


I think the obvious (and interesting) property we want to achieve is that a=
 proxy should be able to fan out observation notifications, i.e., if three =
clients want to observe the same resource through the same proxy, the proxy=
 can make do with observing it once. =A0This property should be part of the=
 architecture, not an application-specific hack.



Proposal: A proxy, as you are using the term, is an a=
pplication.

Consequently, its behavior should be defined in a separa=
te document=20
from the one that specifies the CoAP protocol: data=20
encoding, supported metadata (options), and transaction state machines.
=


(Why is that property interesting? =A0Because it allows constrained nodes t=
o minimize their direct communication.)

Yes.=A0 Ob=
servation in a constrained environment really involves four distinct roles,=
 not two.=A0 Whether some of those roles are implemented on the same end-po=
int is necessarily going to be a system-specific decision.


And I'm really not looking forward to trying to explain over email =
why that is so.

Peter



--20cf30433f0085a8210493d4ef91--

From zach@sensinode.com  Sun Oct 31 14:00:14 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20CE3A67C2 for ; Sun, 31 Oct 2010 14:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.542
X-Spam-Level: 
X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5DFZCFNoTfX for ; Sun, 31 Oct 2010 14:00:13 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id F3BA33A67B7 for ; Sun, 31 Oct 2010 14:00:12 -0700 (PDT)
Received: from [192.168.1.4] (line-8141.dyn.kponet.fi [85.29.78.44]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9VL26ql016280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 31 Oct 2010 23:02:07 +0200
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-39-1014085104; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Sun, 31 Oct 2010 23:02:10 +0200
Message-Id: 
References:   
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] coap-observe response code
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 31 Oct 2010 21:00:14 -0000

--Apple-Mail-39-1014085104
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Peter,

I stared a new thread on this technical comment.=20

On Oct 29, 2010, at 3:37 PM, Peter Bigot wrote:

>  if it were changed to use a new method instead of a 200 response for =
its announcements


You missed some of the early mailing list fun in CoRE.... we've been =
through this several times before. This WG clearly *does not* want any =
new methods added to CoAP (we tried in first versions of CoRE =
subscription). This is the beauty of how simple coap-observe is... with =
just one lifetime option it enables observation in the transfer =
protocol.=20

Now, it might really make sense to send a response code different than =
200 for observe notifications. Something in the CoAP reserved range? Or =
would a new 2xx code make more sense as it could be weird to mix errors =
and success in the new 6xx range.

Zach

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


--Apple-Mail-39-1014085104
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAzMTIxMDIx
MFowIwYJKoZIhvcNAQkEMRYEFHbTUZAL/YQznc7kdT9pNZsk6641MIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAGdm9aS5GgGTYEq6aWIbbUM9VMcJbTJrTM+gmdXXoAca2BfSVyYvSgXr
t5Y6v+CApT6ENgXHguvpM3hjIwfWPTwj1iSa2A/viLPH2cEH6KfyF13O9ffm5Nq9JpZ/2k1uMi3m
XvxBYddnWe2EJ8ezXzF2indZDktPc7TBMTTXTU0cf1G3S3apGnnFUW+pSUnhWitkHW9n1NgWDqZY
DhY0PKeQexwp3ayeyVJL2NvtiZsb/Pv8dhzjAPT6uk+htixFdoRxfpQ4Oegq0wF9YMoIbYnZ53Bp
C5JZfsv2M7ohYDpOaa5Qx9ZiqQqTAwN1j1hteGi8pLo93C27BJkr/DAh+6YAAAAAAAA=

--Apple-Mail-39-1014085104--

From zach@sensinode.com  Sun Oct 31 14:32:16 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CA13A67E1 for ; Sun, 31 Oct 2010 14:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.544
X-Spam-Level: 
X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBzIt+CrWenq for ; Sun, 31 Oct 2010 14:32:14 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8A9F83A67D6 for ; Sun, 31 Oct 2010 14:32:12 -0700 (PDT)
Received: from [192.168.1.4] (line-8141.dyn.kponet.fi [85.29.78.44]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9VLY8rI016732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 31 Oct 2010 23:34:08 +0200
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-40-1016007083; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby 
In-Reply-To: 
Date: Sun, 31 Oct 2010 23:34:12 +0200
Message-Id: <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com>
References:   
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] What's to be presented to IESG in December?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 31 Oct 2010 21:32:16 -0000

--Apple-Mail-40-1016007083
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 29, 2010, at 3:37 PM, Peter Bigot wrote:

> I feel coap-block is unnecessary if one can defer to alternative =
protocols (and we will need Uri-Scheme back to enable that, which I very =
much want)


I don't agree that this has anything to do with CoAP, which is a =
transfer protocol. If you want to provide a link to a different =
protocol, this should be done in your resource representation (just like =
an HTML link). Alternatively, the CoRE link format would allow you to =
include links to other protocols. I absolutely do not agree that CoAP =
should be returning some header option redirecting a client to use some =
other protocol.=20

You have already indicated that you personally want to use TFTP for your =
application, fine. There is nothing in the current specifications that =
prevents you from doing that. The core-block draft is separate (and thus =
optional) from the base protocol exactly for that reason, some =
applications might not need that at all and some might use a different =
protocol for large transfers. In Maastricht the WG made the decision to =
keep optional features as separate drafts, the original plan was to =
include link-format, observe and block in the base specification.

That you do not need an optional feature is not a valid argument for =
CoRE not specifying one. We are designing for the whole M2M industry and =
Internet community here, not just your application.=20

Zach

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


--Apple-Mail-40-1016007083
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9
fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl
bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH
i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb
6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto
GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja
5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I
2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf
nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W
PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm
nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn
VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL
EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu
ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAzMTIxMzQx
MlowIwYJKoZIhvcNAQkEMRYEFILmI8XHQBiDIVdDY0s7XRjLFw93MIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBACQ3w50U/8pDi3uKzqN0gwl1k9Wf4IPgt44GCvFs2hlu7MSNIzvK3ijJ
Op2gjQN3sNDf0CAZDCBsDFXzmHru/+2Qg13UQazOkcVokEbxnWH6t9Cdnv4gSHWW78vt4/p8dZAb
QDJythiHVKJkkHQWyxJT1/3YFedVTR0t2sqAicHUwBlUueHl90DxXCX/JoyXJS1mCoAqP0CfvXqz
7g20t/E1stk8OJ2reZnCtEVYrubJJt+6dhDO7usS44R4EgnuIJuluEMB9CTMz9AYoTnHiFGpHlLg
U18K8XQiDYd+HaAu+JbuyVOMowH6iZoc0iRSNlkE+VIitFcur2Y6r3pEoMcAAAAAAAA=

--Apple-Mail-40-1016007083--

From cabo@tzi.org  Sun Oct 31 14:36:07 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8523A67D3 for ; Sun, 31 Oct 2010 14:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.187
X-Spam-Level: 
X-Spam-Status: No, score=-106.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWK45vEENdrl for ; Sun, 31 Oct 2010 14:36:06 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 17FF43A67ED for ; Sun, 31 Oct 2010 14:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9VLb0oV014940; Sun, 31 Oct 2010 22:37:00 +0100 (CET)
Received: from [192.168.217.101] (p5489CD68.dip.t-dialin.net [84.137.205.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8129EC65; Sun, 31 Oct 2010 22:37:00 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 31 Oct 2010 22:36:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <56C80DC5-388D-4479-8F25-8A1611537D32@tzi.org>
References:    
To: Zach Shelby 
X-Mailer: Apple Mail (2.1081)
Cc: core 
Subject: Re: [core] coap-observe response code
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 31 Oct 2010 21:36:07 -0000

On Oct 31, 2010, at 22:02, Zach Shelby wrote:

> it might really make sense to send a response code different than 200 =
for observe notifications

Or it might not.  What is so different about a second or third observe =
notification from an initial response?  Can't the client simly remember =
it got the first?

The status code might actually mean something.
E,g, we should at some point be able to do a 304, or maybe we want to =
use something like 226 (RFC 3229 -- this is just an example) instead of =
200 later.  Let's not overload the status code with state machine state.

If we do need to transmit that state bit, we probably should put it into =
the subscription-lifetime option of the response, which is the other =
half of that state.
(Do we?)

Gruesse, Carsten


From L.Wood@surrey.ac.uk  Sun Oct 31 14:58:02 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF153A67D3 for ; Sun, 31 Oct 2010 14:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.582
X-Spam-Level: 
X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwRy8zAJxwh7 for ; Sun, 31 Oct 2010 14:58:00 -0700 (PDT)
Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id EBBBC3A6452 for ; Sun, 31 Oct 2010 14:57:59 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-4.tower-78.messagelabs.com!1288562398!34165806!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [131.227.200.39]
Received: (qmail 26215 invoked from network); 31 Oct 2010 21:59:58 -0000
Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-4.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 31 Oct 2010 21:59:58 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sun, 31 Oct 2010 21:59:58 +0000
From: 
To: 
Date: Sun, 31 Oct 2010 21:59:57 +0000
Thread-Topic: [core] What's to be presented to IESG in December?
Thread-Index: Act5RvTgYKSOuzVCTBmNIPjAyE3gDA==
Message-ID: 
References:    <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com>
In-Reply-To: <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: core@ietf.org, L.Wood@surrey.ac.uk
Subject: Re: [core] What's to be presented to IESG in December?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 31 Oct 2010 21:58:02 -0000

On 31 Oct 2010, at 21:34, Zach Shelby wrote:
>=20
> You have already indicated that you personally want to use TFTP for your =
application, fine.

Why would anyone want to use tftp for _anything_?


puzzled,

L.

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




From pab@peoplepowerco.com  Sun Oct 31 15:12:45 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFE43A67E7 for ; Sun, 31 Oct 2010 15:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.73
X-Spam-Level: 
X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.246,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdZR7UZ4NLrm for ; Sun, 31 Oct 2010 15:12:44 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 96F3D3A67D3 for ; Sun, 31 Oct 2010 15:12:44 -0700 (PDT)
Received: by fxm9 with SMTP id 9so4815648fxm.31 for ; Sun, 31 Oct 2010 15:14:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.69.132 with SMTP id z4mr1413222fai.31.1288563283853; Sun, 31 Oct 2010 15:14:43 -0700 (PDT)
Received: by 10.223.83.207 with HTTP; Sun, 31 Oct 2010 15:14:43 -0700 (PDT)
In-Reply-To: <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com>
References:    <2F0A9D45-A3D3-48B8-999B-0CEA5674784D@sensinode.com>
Date: Sun, 31 Oct 2010 17:14:43 -0500
Message-ID: 
From: Peter Bigot 
To: Zach Shelby 
Content-Type: multipart/alternative; boundary=20cf30433f00ce01420493f1044c
Cc: core 
Subject: Re: [core] What's to be presented to IESG in December?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 31 Oct 2010 22:12:45 -0000

--20cf30433f00ce01420493f1044c
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Oct 31, 2010 at 4:34 PM, Zach Shelby  wrote:

> On Oct 29, 2010, at 3:37 PM, Peter Bigot wrote:
>
> > I feel coap-block is unnecessary if one can defer to alternative
> protocols (and we will need Uri-Scheme back to enable that, which I very
> much want)
>
> I don't agree that this has anything to do with CoAP, which is a transfer
> protocol. If you want to provide a link to a different protocol, this should
> be done in your resource representation (just like an HTML link).
> Alternatively, the CoRE link format would allow you to include links to
> other protocols. I absolutely do not agree that CoAP should be returning
> some header option redirecting a client to use some other protocol.
>

Could you clarify: are you saying that you don't want to require CoAP to
redirect to another protocol in this case, or that you don't want CoAP to
ever support redirection to another protocol?

That you do not need an optional feature is not a valid argument for CoRE
> not specifying one. We are designing for the whole M2M industry and Internet
> community here, not just your application.
>

Agreed.  The remainder of that sentence you quoted noted my willingness to
support coap-block if a particular technical issue was addressed.

Peter

--20cf30433f00ce01420493f1044c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sun, Oct 31, 2010 at 4:34 PM, Zach Shelby <zach@sensinode.com=
> wrote:


On Oct 29, 2010, at 3:37 PM, Peter Bigot wrote:



> I feel coap-block is unnecessary if one can defer to alternative proto=
cols (and we will need Uri-Scheme back to enable that, which I very much wa=
nt)





I don't agree that this has anything to do with CoAP, which is a =
transfer protocol. If you want to provide a link to a different protocol, t=
his should be done in your resource representation (just like an HTML link)=
. Alternatively, the CoRE link format would allow you to include links to o=
ther protocols. I absolutely do not agree that CoAP should be returning som=
e header option redirecting a client to use some other protocol.



Could you clarify: are you saying that you don't =
want to require CoAP to redirect to another protocol in this case, or that =
you don't want CoAP to ever support redirection to another protocol?


That you do not need an optional feature is not a valid argument for CoRE n=
ot specifying one. We are designing for the whole M2M industry and Internet=
 community here, not just your application.

Agreed=
.=A0 The remainder of that sentence you quoted noted my willingness to supp=
ort coap-block if a particular technical issue was addressed.


Peter


--20cf30433f00ce01420493f1044c--

From cabo@tzi.org  Sun Oct 31 15:28:42 2010
Return-Path: 
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD77D3A67E6 for ; Sun, 31 Oct 2010 15:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.188
X-Spam-Level: 
X-Spam-Status: No, score=-106.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUe9BVVJHUgK for ; Sun, 31 Oct 2010 15:28:42 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 8DDE33A67E7 for ; Sun, 31 Oct 2010 15:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9VMUYxr001556 for ; Sun, 31 Oct 2010 23:30:34 +0100 (CET)
Received: from [192.168.217.101] (p5489CD68.dip.t-dialin.net [84.137.205.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 919F4C70; Sun, 31 Oct 2010 23:30:34 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 31 Oct 2010 23:30:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: core 
X-Mailer: Apple Mail (2.1081)
Subject: [core] Uri-scheme (Re: What's to be presented to IESG in December?)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: 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, 31 Oct 2010 22:28:42 -0000

On Oct 29, 2010, at 14:37, Peter Bigot wrote:

> we will need Uri-Scheme back

I completely agree, if for a different reason:
Uri-scheme is needed to tell a multi-scheme proxy which scheme is =
actually needed.
E.g., a coap-to-http proxy has no idea whether the resource the client =
wants has a URI with scheme http or https.
A more general proxy might also support ftp (or even tftp).
Encoding the URI scheme into the port number of the proxy becomes a =
configuration nightmare quickly, unless we have a way to fully automate =
that configuration.

Gruesse, Carsten