From klaus.hartke@googlemail.com Wed Sep 1 09:23:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C5D3A677E for ; Wed, 1 Sep 2010 09:23:07 -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 pz4jeCiz7XwU for ; Wed, 1 Sep 2010 09:22:59 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E90083A695B for ; Wed, 1 Sep 2010 09:22:58 -0700 (PDT) Received: by bwz9 with SMTP id 9so6596353bwz.31 for ; Wed, 01 Sep 2010 09:23:28 -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=aEEFH0bSIWdC707OKOlwwdUXpO87BdhHZWQJqJjNGVE=; b=iXfBdLFJvK7nvz7gkgGEToIvupfLfOIlhG3geSUH0/EiFSNVbNqtY3HkfRqvzR6H2E 953gWMHTPpV3k69FCtVYVznmCoyn6z8wdek1LYPTunYe8RnaIG+2laeb9PDeiSIDtDxI Lt2Q42j7EV3wWdaIC3cLYhL5lmVbV/4EsB5XY= 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=ntJTTwGwyCTCxCQ++553CuwUeoRI9ZMYPZngcXVIbMC476F+6Nxl6pbSkXA2xT5x5F YLVfsJb42XUR7h+jLi/3TLLOosx6XNlWoraSSjlQTKl97m11QFmqG32R0051wt4bpwH0 TpeiVn2MG+OUFFi57gs1BnUf6siyrH2kHwO1I= MIME-Version: 1.0 Received: by 10.204.84.20 with SMTP id h20mr5814138bkl.186.1283358208806; Wed, 01 Sep 2010 09:23:28 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.103.202 with HTTP; Wed, 1 Sep 2010 09:23:28 -0700 (PDT) In-Reply-To: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> Date: Wed, 1 Sep 2010 18:23:28 +0200 X-Google-Sender-Auth: YxU-XZ8jfTJ7KjuNAVI_qggHI-0 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #23: Virtual server capability? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Sep 2010 16:23:07 -0000 I think the problem we're trying to solve is as follows: We have the commonly occurring pattern of a CoAP server with which communication is only possible in a meaningful/practical way if the request is moved through some intermediary node, for example, because the server is a sleep node or it is located in a subnet that is only reachable from the intermediary node. One solution to this problem is what we call a "Virtual server capability": instead of the IP address of the server, we specify the IP address of the intermediary node in the A/AAAA DNS record for the server. All requests are then sent to the intermediary node which needs a way to distinguish between requests intended for different servers. This solution has two implications: - All request must specify the Uri-Authority Option, because a client cannot know if a resolved IP address refers to a server or such an intermediary node. - All servers should know their DNS name, so they can decide if a request is intended for them or if they are expected to act as a proxy. Since DNS names can be quite verbose, we'd like to be able to omit the Uri-Authority Option in most cases. I don't know if this a problem or not, but the sweet-spot for server implementations is to simply accept any DNS name in the Uri-Authority Option. Another solution is to shift the burden from the server to the client: instead of the IP address of the server, we specify the IP address of the intermediary node in the (say) SRV DNS record for the server. If such a record is present, the client knows that the IP address refers to a CoAP proxy (otherwise, the client falls back to the A/AAAA DNS record). - Since the client knows if it's communicating with a proxy or not, it can include or omit the Uri-Authority Option accordingly. The Uri-Authority Option can likely be omitted in most cases. - A server can determine if it's expected to act as proxy or server simply by checking if the Uri-Authority Option is present or not. The sweet-spot for client implementations is either to correctly implement this feature, because otherwise it wouldn't work, or to not implement it, but not to implement wrong/problematic behaviour. Many DNS APIs do not provide functions for retrieving non-A/AAAA DNS records though. (Note that both solutions allow the intermediary node to act on behalf of the guarded server, or to expose a set of "virtual" servers that do not exist as actual, separate nodes.) I think both solutions can be tweaked to solve the problem. The first question is, of course: Is the problem the one stated above or is it actually a different one? Are there other possible solutions to the problem that we haven't thought about yet? It has repeatedly been stated that it is an essential part of REST that the Uri-Authority Option must always be present. I'm not sure if I understand this fully yet. Where exactly does it come into play, i.e. what problem does it solve? How can we recognise a different solution to the same problem? The problem scenario should also become very interesting in the light of end-to-end security. Do we need to think about a mechanism to securely allow a CoAP node to act on behalf of another one? Klaus From pab@peoplepowerco.com Wed Sep 1 16:22: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 9D5A63A6872 for ; Wed, 1 Sep 2010 16:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.449, 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 0eDnOefVBQFF for ; Wed, 1 Sep 2010 16:22:09 -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 CCB0E3A6898 for ; Wed, 1 Sep 2010 16:22:08 -0700 (PDT) Received: by fxm18 with SMTP id 18so5899505fxm.31 for ; Wed, 01 Sep 2010 16:22:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.111.206 with SMTP id t14mr7725018fap.32.1283383358349; Wed, 01 Sep 2010 16:22:38 -0700 (PDT) Received: by 10.223.108.75 with HTTP; Wed, 1 Sep 2010 16:22:38 -0700 (PDT) In-Reply-To: References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> Date: Wed, 1 Sep 2010 18:22:38 -0500 Message-ID: From: Peter Bigot To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] #23: Virtual server capability? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Sep 2010 23:22:10 -0000 I agree with the problem statement and the implications, though I would make it clear that the server knowing its DNS name should not be taken to imply that the server must speak DNS as a protocol. It just has to recognize itself when presented with an authority. My objection to solutions that push the burden to the client is due to the core REST principle of consistent interfaces. Under REST, all the client knows is the URI, and some basic information about the resource state description. In REST, there can be an arbitrary number of intermediate servers between the client and the origin server, all of which do something that's important to somebody, but which must look, from the client's REST perspective, exactly like the origin server. Adding a requirement that the client know whether it is talking to the real origin server directly makes it difficult for client/server connections that traverse different administrative domains to adapt to changes in how the resources are provided (e.g., addition of intermediate nodes). Imposing requirements that clients support additional DNS query facilities or other ways to obtain information that is not part of the URI but is required to connect to the identified resource makes implementing clients and managing CoAP environments both more complex. The reason I keep saying the authority is an essential part of REST is because the authority is an essential part of a URI, and REST uses URIs to identify the resources whose state it transfers. In support of this, I again refer to Fielding's dissertation (section 6.3.2.1) where he admitted that allowing the authority to be dropped in HTTP/1.0 was one of the worst mistakes they made. When part of a URI is removed, the URI no longer uniquely identifies the resource. *If* the removed part can be restored on the (intermediate) server(s) through envelope or external information that is maintained and made available at every stage of the entire (unknown) underlying transport network that carries the REST message, then the information is not really lost and the resource remains uniquely identified. Clearly, carrying the original URI authority within the REST message all the way from client to origin sever would retain this information. I don't believe we have clearly proven that there is an alternative approach that will work in all REST-ful architectures and all reasonable implementation environments, including the ones I outlined. The authors of HTTP/1.1 found they could not solve the problem any other way. I have no objection to providing wording that allows the Uri-Authority option to be omitted in a situation where the architect of a particular CoAP service or installation has ensured it is safe to do so. That's why I proposed wording that allows this. I do, though, object to creating a specification that mandates situations where the authority part cannot be retained in a REST message, imposes the use of "complex" solutions to the problem thus created, and doesn't provide a fallback that allows the client to recover automatically when the server disagrees about the importance of having the authority or can't successfully figure out what it was supposed to be. Which is where it looked like we were going. I'm afraid that doing that would prevent CoAP from being used in a full-featured REST-ful architectures. (I'm also afraid of how to define a CoAP/HTTP bridge in situations where it's difficult to maintain in CoAP information that HTTP expects to be provided, so would prefer to limit those situations, at least until we understand better how to solve that problem.) I'm satisfied with the current disposition of this ticket. Clients that do not want to include Uri-Authority are free to omit it. Servers that are simplified by requiring its presence are free to require it. When these choices conflict, the two can still communicate: the client simply adds information it already has and retransmits the request, and the server gets what it needs[*]. All is good, no? Peter [*] Carsten is absolutely right about the ugliness of using "400 Bad Request" to identify this situation. In my proposed text I specifically chose not to confuse the issue by inventing a new result code. That's a whole separate issue, peripheral to this one, and on which I currently hold no opinions. On Wed, Sep 1, 2010 at 11:23 AM, Klaus Hartke wrote: > I think the problem we're trying to solve is as follows: > > We have the commonly occurring pattern of a CoAP server with which > communication is only possible in a meaningful/practical way if the > request is moved through some intermediary node, for example, because > the server is a sleep node or it is located in a subnet that is only > reachable from the intermediary node. > > > One solution to this problem is what we call a "Virtual server > capability": instead of the IP address of the server, we specify the > IP address of the intermediary node in the A/AAAA DNS record for the > server. All requests are then sent to the intermediary node which > needs a way to distinguish between requests intended for different > servers. > > This solution has two implications: > > - All request must specify the Uri-Authority Option, because a client > cannot know if a resolved IP address refers to a server or such an > intermediary node. > > - All servers should know their DNS name, so they can decide if a > request is intended for them or if they are expected to act as a > proxy. > > Since DNS names can be quite verbose, we'd like to be able to omit the > Uri-Authority Option in most cases. > > I don't know if this a problem or not, but the sweet-spot for server > implementations is to simply accept any DNS name in the Uri-Authority > Option. > > > Another solution is to shift the burden from the server to the client: > instead of the IP address of the server, we specify the IP address of > the intermediary node in the (say) SRV DNS record for the server. If > such a record is present, the client knows that the IP address refers > to a CoAP proxy (otherwise, the client falls back to the A/AAAA DNS > record). > > - Since the client knows if it's communicating with a proxy or not, it > can include or omit the Uri-Authority Option accordingly. The > Uri-Authority Option can likely be omitted in most cases. > > - A server can determine if it's expected to act as proxy or server > simply by checking if the Uri-Authority Option is present or not. > > The sweet-spot for client implementations is either to correctly > implement this feature, because otherwise it wouldn't work, or to not > implement it, but not to implement wrong/problematic behaviour. > > Many DNS APIs do not provide functions for retrieving non-A/AAAA DNS > records though. > > > (Note that both solutions allow the intermediary node to act on behalf > of the guarded server, or to expose a set of "virtual" servers that do > not exist as actual, separate nodes.) > > > I think both solutions can be tweaked to solve the problem. The first > question is, of course: Is the problem the one stated above or is it > actually a different one? > > Are there other possible solutions to the problem that we haven't > thought about yet? > > It has repeatedly been stated that it is an essential part of REST > that the Uri-Authority Option must always be present. I'm not sure if > I understand this fully yet. Where exactly does it come into play, > i.e. what problem does it solve? How can we recognise a different > solution to the same problem? > > The problem scenario should also become very interesting in the light > of end-to-end security. Do we need to think about a mechanism to > securely allow a CoAP node to act on behalf of another one? > > > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From hariharasudhan.tce@gmail.com Wed Sep 1 23:06: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 745403A6A4F for ; Wed, 1 Sep 2010 23:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_20=-0.74, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR7jbv9OXo+M for ; Wed, 1 Sep 2010 23:06:10 -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 2666A3A6A5A for ; Wed, 1 Sep 2010 23:06:10 -0700 (PDT) Received: by yxl31 with SMTP id 31so3929yxl.31 for ; Wed, 01 Sep 2010 23:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=EcjPunFD6u+DZwaLP+S3SzY3T5X/kZ3M2GQRCwwTjYc=; b=LcStOrAYsdAHgBMyeDu7f/pEDczM9rSdSnCLX4vYois1poV3ytJbQQ5ckWHOr5BMFh YwhBZ54oeRh5ye4FdigFg2WVpo2VBc5F67j41baUlLrq6eGVeV43PlU33NIKy711sa/Q /cmfmqt/Qh8D0su1BjNUpJLyd6Hg/iNVbDgbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=laz+w8srFqr9qsOd6C2QoPNXIlVB1BMVSgx3PiLP78RNs8AwbdN4axbT6FNIMqCmwE Bw/+57sjZCXuYr5X9pw2TKp3JyldsrbKO26rbz9zPpsn/2zJHzSDudy1CmmHlrFqf5uT gxjIHnrBf0sEq3pGPLjLq3/i8nXvk+9tufuyc= MIME-Version: 1.0 Received: by 10.100.135.13 with SMTP id i13mr9551261and.34.1283407600098; Wed, 01 Sep 2010 23:06:40 -0700 (PDT) Received: by 10.100.104.9 with HTTP; Wed, 1 Sep 2010 23:06:40 -0700 (PDT) Date: Thu, 2 Sep 2010 11:36:40 +0530 Message-ID: From: Hari Hara Sudhan R To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] doubt regarding duplicate CON messages in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 06:06:11 -0000 Hi all, I have a doubt regarding duplicate CON messages in CoAP. If we have a scenario as mentioned below how should the receiver respond. Sender Receiver | CON(TID = X) | |----------------------------->| | |Receiver is processing the request. | | | CON(TID = X) | |------------------------------>| | | | | To discard the duplicate should the receiver maintain a list of transaction IDs of confirmable messages yet to be acknowledged? I know the above scenario is unlikely but in constrained environment the scenario is possible. Does the specification mention anything for this scenario? Thanks and Regards, Hari Hara Sudhan R From cabo@tzi.org Thu Sep 2 00:30:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47443A6908 for ; Thu, 2 Sep 2010 00:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 X6JIjLAlHACj for ; Thu, 2 Sep 2010 00:30: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 707913A6A7D for ; Thu, 2 Sep 2010 00:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o827UWWT024960; Thu, 2 Sep 2010 09:30:37 +0200 (CEST) Received: from [10.57.90.94] (m85-94-180-195.andorpac.ad [85.94.180.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A9D296D89; Thu, 2 Sep 2010 09:30:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 2 Sep 2010 09:30:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hari Hara Sudhan R X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] doubt regarding duplicate CON messages in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 07:30:24 -0000 On Sep 2, 2010, at 08:06, Hari Hara Sudhan R wrote: > Hi all, >=20 > I have a doubt regarding duplicate CON messages in CoAP. >=20 > If we have a scenario as mentioned below how should the receiver = respond. >=20 >=20 > Sender Receiver >=20 > | CON(TID =3D X) | > |----------------------------->| > | |Receiver is processing the request. > | | > | CON(TID =3D X) | > |------------------------------>| > | | > | | >=20 > To discard the duplicate Well, the receiver should send an (another) ACK, not just ignore the = CON. (Otherwise, the initiator would never get a reply if the return packet = is lost.) > should the receiver maintain a list of > transaction IDs of confirmable > messages yet to be acknowledged? This is a question about implementation. If the request is not idempotent, yes, the receiver needs to keep a list = of TIDs to remove duplicate copies of the datagram or retransmissions. If the request is idempotent, it is a matter of implementation = convenience and performance whether this is done or whether each = retransmission is processed and replied to from scratch. Gruesse, Carsten From hariharasudhan.tce@gmail.com Thu Sep 2 00:45:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F9F3A686D for ; Thu, 2 Sep 2010 00:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME838kVAtmtx for ; Thu, 2 Sep 2010 00:45:46 -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 99ADD3A6852 for ; Thu, 2 Sep 2010 00:45:46 -0700 (PDT) Received: by ywk9 with SMTP id 9so84779ywk.31 for ; Thu, 02 Sep 2010 00:46:16 -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=093ezTKNEXOuMA3xymxvU7DfU+Gv94fPzC71GluRC8g=; b=b9/Lg9xCBhk7lDejhSdxHgX7T6gcAyEKZOSpTmO5LQEe+rxbXUvFxkGPL57Usae2rr azDl2oMVutzqx57hKDNA4024H55ml14vvWTVDZAZET4DPGthZVidCHMQ26uQgaXixQXS nhqKgNdlwelHEBVjAsLKAhhjfPjG50TDRoOaI= 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=O6e4XMGfUB/iPQaTt81iX/YJZ9KUDMfVB8U5TRmZhW3DOLxyc46K5D123u75yl9DV6 auwpbDsgRfU5VXQ44+vUd/mRSCvVsQmrvh8fDRdZUaRf3fv75S3Vv3rDyRTwE0ZUdCLi t+IiCB28H997DWRQBcWLTuBE1xRi5U/lU2VkQ= MIME-Version: 1.0 Received: by 10.100.31.13 with SMTP id e13mr9562591ane.13.1283413575223; Thu, 02 Sep 2010 00:46:15 -0700 (PDT) Received: by 10.100.104.9 with HTTP; Thu, 2 Sep 2010 00:46:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Sep 2010 13:16:15 +0530 Message-ID: From: Hari Hara Sudhan R To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] doubt regarding duplicate CON messages in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 07:45:47 -0000 > Sender Receiver > > | CON(TID =3D X) | > |----------------------------->| > | |Receiver is processing the request. > | | > | CON(TID =3D X) | > |------------------------------>| > | | > | | > > To discard the duplicate >Well, the receiver should send an (another) ACK, not just ignore the CON. >(Otherwise, the initiator would never get a reply if the return packet is = lost.) If it is the same request that is getting retransmiited after a time-out. The scenario I'm trying to explain is "When receiver is processing a CON request sender times-out and retransmit the same message again". Thanks and Regards, Hari Hara Sudhan R On Thu, Sep 2, 2010 at 1:00 PM, Carsten Bormann wrote: > On Sep 2, 2010, at 08:06, Hari Hara Sudhan R wrote: > >> Hi all, >> >> I have a doubt regarding duplicate CON messages in CoAP. >> >> If we have a scenario as mentioned below how should the receiver respond= . >> >> >> Sender =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Receiver >> >> | =A0 =A0 CON(TID =3D X) =A0 =A0 =A0| >> |----------------------------->| >> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |Receiver = is processing the request. >> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> | =A0 =A0 =A0CON(TID =3D X) =A0 =A0 =A0| >> |------------------------------>| >> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> >> To discard the duplicate > > Well, the receiver should send an (another) ACK, not just ignore the CON. > (Otherwise, the initiator would never get a reply if the return packet is= lost.) > >> should the receiver maintain a list of >> transaction IDs of confirmable >> messages yet to be acknowledged? > > This is a question about implementation. > If the request is not idempotent, yes, the receiver needs to keep a list = of TIDs to remove duplicate copies of the datagram or retransmissions. > If the request is idempotent, it is a matter of implementation convenienc= e and performance whether this is done or whether each retransmission is pr= ocessed and replied to from scratch. > > Gruesse, Carsten > > From matthieu.vial@fr.non.schneider-electric.com Thu Sep 2 03:03: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 9BF8F3A6A84; Thu, 2 Sep 2010 03:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-1.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 eh+5e4i3+hbx; Thu, 2 Sep 2010 03:03:04 -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 D9A853A6A1B; Thu, 2 Sep 2010 03:03:03 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2010090211453292-43790 ; Thu, 2 Sep 2010 11:45:32 +0200 In-Reply-To: To: Carsten Bormann X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Thu, 2 Sep 2010 11:57:03 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 02/09/2010 12:00:36, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 02/09/2010 11:48:29, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 02/09/2010 11:48:31 Content-type: multipart/related; Boundary="0__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD" Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] doubt regarding duplicate CON messages in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 10:03:05 -0000 --0__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD Content-type: multipart/alternative; Boundary="1__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD" --1__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi, >This is a question about implementation. >If the request is not idempotent, yes, the receiver needs to keep a li= st of TIDs to remove duplicate copies of the datagram or retransmissions. >If the request is idempotent, it is a matter of implementation conveni= ence and performance whether this is done or whether each retransmission is >processed and replied to from scratch. How long the server shall retain the non idempotent requests ? If I'm r= ight , the server can't known if the client has received the ack so it shall= keep the transaction context during the retransmission window: RESPONSE_TIMEOUT * (2 ^ MAX_RETRANSMIT - 1). The sequence with timeout and retry is then: Client Server | | | CON tid=3D47 | | POST /foo | +---------------->| Process and store the result | | | ACK tid=3D47 | | 200 | timeout| lost X--------+ | | | CON tid=3D47 | | POST /foo | retry+---------------->| Do not process and get the previous result | | | ACK tid=3D47 | | 200 | |<----------------+ | | | | Free context with tid=3D47 Regards, Matthieu VIAL = Carsten Bormann = = Envoy=E9 par : = A core-bounces@ietf Hari Hara Sudhan R = .org = = cc core@ietf.org = 02/09/2010 09:30 Ob= jet Re: [core] doubt regarding = duplicate CON messages in CoAP = = = = = = = On Sep 2, 2010, at 08:06, Hari Hara Sudhan R wrote: > Hi all, > > I have a doubt regarding duplicate CON messages in CoAP. > > If we have a scenario as mentioned below how should the receiver resp= ond. > > > Sender Receiver > > | CON(TID =3D X) | > |----------------------------->| > | |Receiver is processing the request. > | | > | CON(TID =3D X) | > |------------------------------>| > | | > | | > > To discard the duplicate Well, the receiver should send an (another) ACK, not just ignore the CO= N. (Otherwise, the initiator would never get a reply if the return packet = is lost.) > should the receiver maintain a list of > transaction IDs of confirmable > messages yet to be acknowledged? This is a question about implementation. If the request is not idempotent, yes, the receiver needs to keep a lis= t of TIDs to remove duplicate copies of the datagram or retransmissions. If the request is idempotent, it is a matter of implementation convenie= nce and performance whether this is done or whether each retransmission is processed and replied to from scratch. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Hi,

>This is a question about implementation.
>If the request is not idempotent, yes, the receiver needs to keep a= list of TIDs to remove duplicate copies of the datagram or retransmiss= ions.
>If the request is idempotent, it is a matter of implementation conv= enience and performance whether this is done or whether each retransmis= sion is >processed and replied to from scratch.

How long the server shall retain the non idempotent requests ? If I'm right, the server can't kn= own if the client has received the ack so it shall keep the transaction= context during the retransmission windo= w: RESPONSE_TIMEOUT * (2 ^ MAX_RETRANSMIT - 1).

The sequence with timeout and retry is then:

Client             S= erver  
      |              = ;   |          
      |    CON tid=3D47   |    = ;
      |    POST /foo    |   &n= bsp;  
      +---------------->|  Process and store th= e result      
      |              = ;   |        
      |    ACK tid=3D47   |    = ;  
      |    200         &n= bsp;|        
timeout|  lost  X--------+       <= br>        |       =           |        
      |    CON tid=3D47   |    = ;
      |    POST /foo    |   &n= bsp;  
 retry+---------------->|  Do not process and get the pre= vious result      
      |              = ;   |        
      |    ACK tid=3D47   |    = ;  
      |    200         &n= bsp;|        
      |<----------------+      
       |       =           |
       |       =           |  Free context with tid=3D47

Regards,
Matthieu VIAL

3D"InactiveCarsten Bormann <cabo@tzi.org>



=
          Carsten Bormann <cabo@tzi.org>=
          Envoy=E9 par : core-bounces@ietf.org

          02/09/2010 09:30

 =
3D=
A
3D""
Hari Hara Sudhan R <hariharasudhan.tce@gmail.com>= ;
3D=
cc
3D""
core@ietf.org
3D=
Objet
3D""
Re: [core] doubt regarding duplicate CON messages in C= oAP
3D=3D""

On Sep 2, 2010, at 08:06, Hari Hara Sudhan R wrote:

> Hi all,
>
> I have a doubt regarding duplicate CON messages in CoAP.
>
> If we have a scenario as mentioned below how should the receiver r= espond.
>
>
> Sender                Rece= iver
>
> |     CON(TID =3D X)      |
> |----------------------------->|
> |                   &= nbsp;           |Receiver is processing the re= quest.
> |                   &= nbsp;           |
> |      CON(TID =3D X)      |
> |------------------------------>|
> |                   &= nbsp;            |
> |                   &= nbsp;            |
>
> To discard the duplicate

Well, the receiver should send an (another) ACK, not just ignore the CO= N.
(Otherwise, the initiator would never get a reply if the return packet = is lost.)

> should the receiver maintain a list of
> transaction IDs of confirmable
> messages yet to be acknowledged?

This is a question about implementation.
If the request is not idempotent, yes, the receiver needs to keep a lis= t of TIDs to remove duplicate copies of the datagram or retransmissions= .
If the request is idempotent, it is a matter of implementation convenie= nce and performance whether this is done or whether each retransmission= is processed and replied to from scratch.

Gruesse, Carsten

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

______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
= --1__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD-- --0__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFD01DFA73BBD8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD Content-type: image/gif; name="pic05436.gif" Content-Disposition: inline; filename="pic05436.gif" Content-ID: <2__=4EBBFD01DFA73BBD8@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__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFD01DFA73BBD8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFD01DFA73BBD8f9e8a93df938690918c4EBBFD01DFA73BBD-- From pab@peoplepowerco.com Thu Sep 2 04:03: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 DF35F3A6A7E for ; Thu, 2 Sep 2010 04:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hakYxYxxyYy5 for ; Thu, 2 Sep 2010 04:03: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 E5E033A6950 for ; Thu, 2 Sep 2010 04:03:48 -0700 (PDT) Received: by fxm18 with SMTP id 18so124786fxm.31 for ; Thu, 02 Sep 2010 04:04:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.111.206 with SMTP id t14mr8331217fap.32.1283425458039; Thu, 02 Sep 2010 04:04:18 -0700 (PDT) Received: by 10.223.108.75 with HTTP; Thu, 2 Sep 2010 04:04:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Sep 2010 06:04:17 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e6d27e8f85acf1048f44c651 Cc: core@ietf.org Subject: Re: [core] doubt regarding duplicate CON messages in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 11:03:58 -0000 --0016e6d27e8f85acf1048f44c651 Content-Type: text/plain; charset=ISO-8859-1 Interesting question. I don't think we even have a SHOULD in the draft specifying how rapidly the server must respond to a CON request, with either a response or an ACK that converts it into an asynchronous request. If it takes two seconds to compute the response, and it's not made asynchronous right away, confusion will result. CON/ACK are part of the transport-layer of CoAP. If the REST layer is separated in an implementation following "best design practices", is it possible that the part of the server that deals with this can't tell whether the request is idempotent? That's certainly true for proxies, isn't it? Perhaps proxies must always immediately ack to convert requests to be asynchronous. Maybe we need a way for the server to detect retransmissions. Recall that UDP can deliver packets out of order, and could (especially in a wireless mesh network with sleeping nodes) take quite a long time to get around to doing so. What we have now says the TID is specific to the (source) endpoint. It's supposed to change on each new transaction, but is not required to be incremented by one. I don't see a way for a destination to infer the "freshness" of a packet by comparing its TID with the one last received from the same source, since the TID is not associated with the (source, destination) pair. Peter On Thu, Sep 2, 2010 at 2:30 AM, Carsten Bormann wrote: > On Sep 2, 2010, at 08:06, Hari Hara Sudhan R wrote: > > > Hi all, > > > > I have a doubt regarding duplicate CON messages in CoAP. > > > > If we have a scenario as mentioned below how should the receiver respond. > > > > > > Sender Receiver > > > > | CON(TID = X) | > > |----------------------------->| > > | |Receiver is processing the request. > > | | > > | CON(TID = X) | > > |------------------------------>| > > | | > > | | > > > > To discard the duplicate > > Well, the receiver should send an (another) ACK, not just ignore the CON. > (Otherwise, the initiator would never get a reply if the return packet is > lost.) > > > should the receiver maintain a list of > > transaction IDs of confirmable > > messages yet to be acknowledged? > > This is a question about implementation. > If the request is not idempotent, yes, the receiver needs to keep a list of > TIDs to remove duplicate copies of the datagram or retransmissions. > If the request is idempotent, it is a matter of implementation convenience > and performance whether this is done or whether each retransmission is > processed and replied to from scratch. > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0016e6d27e8f85acf1048f44c651 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Interesting question.=A0 I don't think we even have a SHOULD in the dra= ft specifying how rapidly the server must respond to a CON request, with ei= ther a response or an ACK that converts it into an asynchronous request.=A0= If it takes two seconds to compute the response, and it's not made asy= nchronous right away, confusion will result.

CON/ACK are part of the transport-layer of CoAP.=A0 If the REST layer i= s separated in an implementation following "best design practices"= ;, is it possible that the part of the server that deals with this can'= t tell whether the request is idempotent?=A0 That's certainly true for = proxies, isn't it?=A0 Perhaps proxies must always immediately ack to co= nvert requests to be asynchronous.

Maybe we need a way for the server to detect retransmissions.=A0 Recall= that UDP can deliver packets out of order, and could (especially in a wire= less mesh network with sleeping nodes) take quite a long time to get around= to doing so.=A0 What we have now says the TID is specific to the (source) = endpoint.=A0 It's supposed to change on each new transaction, but is no= t required to be incremented by one.=A0 I don't see a way for a destina= tion to infer the "freshness" of a packet by comparing its TID wi= th the one last received from the same source, since the TID is not associa= ted with the (source, destination) pair.

Peter

On Thu, Sep 2, 2010 at 2:30 AM,= Carsten Bormann <cabo= @tzi.org> wrote:
On Sep 2, 2010, at 08:06, Hari Hara Sudhan R wrote:

> Hi all,
>
> I have a doubt regarding duplicate CON messages in CoAP.
>
> If we have a scenario as mentioned below how should the receiver respo= nd.
>
>
> Sender =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Receiver
>
> | =A0 =A0 CON(TID =3D X) =A0 =A0 =A0|
> |----------------------------->|
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |Receive= r is processing the request.
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> | =A0 =A0 =A0CON(TID =3D X) =A0 =A0 =A0|
> |------------------------------>|
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>
> To discard the duplicate

Well, the receiver should send an (another) ACK, not just ignore the = CON.
(Otherwise, the initiator would never get a reply if the return packet is l= ost.)

> should the receiver maintain a list of
> transaction IDs of confirmable
> messages yet to be acknowledged?

This is a question about implementation.
If the request is not idempotent, yes, the receiver needs to keep a list of= TIDs to remove duplicate copies of the datagram or retransmissions.
If the request is idempotent, it is a matter of implementation convenience = and performance whether this is done or whether each retransmission is proc= essed and replied to from scratch.

Gruesse, Carsten

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

--0016e6d27e8f85acf1048f44c651-- From pab@peoplepowerco.com Tue Sep 7 02:50:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E41A3A6A9B for ; Tue, 7 Sep 2010 02:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.242 X-Spam-Level: X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZejgcxs1ubJ for ; Tue, 7 Sep 2010 02:50:46 -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 D1E993A6AB9 for ; Tue, 7 Sep 2010 02:44:55 -0700 (PDT) Received: by fxm18 with SMTP id 18so3312040fxm.31 for ; Tue, 07 Sep 2010 02:45:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.103.148 with SMTP id k20mr1151318fao.37.1283852723548; Tue, 07 Sep 2010 02:45:23 -0700 (PDT) Received: by 10.223.112.70 with HTTP; Tue, 7 Sep 2010 02:45:23 -0700 (PDT) Date: Tue, 7 Sep 2010 04:45:23 -0500 Message-ID: From: Peter Bigot To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] Handling potentially-large resource representations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 09:50:47 -0000 In what follows, I'm considering resource representations that would produc= e transaction message lengths that fall into three categories: "short" (withi= n the path MTU), "oversize" (exceeds the path MTU but within the data layer MTU (IPv6 1280)), and "too big" (exceeds the data layer MTU).=A0 I believe that "too big" can be determined by the source natively, while "oversize" i= s discovered either by returning a Packet Too Big ICMP message to the source or by the network dropping the packet before it reaches the destination. My server provides a resource where the length of the representation in a given media type varies depending on the resource value.=A0 For some values= , the representation will be oversize or too big, but in most cases the representation is short.=A0 By default the clients GET the resource without including a block option in the request. (1) If the server determines that the representation is too big and therefore requires a block option for success, how does it communicate this need to the client? (2) If a transaction response turns out to be oversize and is not delivered= , but the network returns a ICMP "Packet Too Big" message to the server, is i= t the server's responsibility to recognize this and respond to the client as though the representation was too big?=A0 [I think the answer has to be "no= ", because the network might not have returned that indication.] (3) Assume a client begins to retrieve the resource value using GET with block options.=A0 During this series of transport transactions, the value o= f the resource changes, as does its representation.=A0 How is the client made awa= re of this so it does not reconstruct an invalid representation? [For this last question I think the answer involves ETag, but since ETag is elective, the server or client or both may not recognize it, and it's not clearly defined when the server is permitted or obliged to include it in a response to a request that did not include it. I think an approach that allows this situation to arise in a way that a standards-conformant CoAP client cannot detect it is unacceptable. The end result may be that ETag becomes critical when using the Block option.] (4) I see that draft-bormann-core-coap-block-00 introduces both the Block option and the Token option, which have been removed from draft-bormann-coap-misc-06.=A0 I'm concerned that if this pairing remains, = it would implicitly require that both be implemented together in order to clai= m conformance to the corresponding RFC, when in fact Token is useful and warranted independently of the Block option.=A0 Is that a valid concern sha= red by anybody else? (5) As noted in the interim WG telecon, Block is the first option that clearly applies at the transport level rather than the REST level of CoAP. The ramifications of this on end-to-end processing are still being understood. CoAP would be tremendously simplified by delegating responsibility for transferring large resource representations to an alternative protocol such as tftp, and natively supporting only those resources that fit within the data layer MTU. Servers would redirect requests to resources with large descriptions to a URI with a different scheme; clients would transmit requests using a URI content-type that the server would have to retrieve (or reject as unsupported). Is there any chance that this approach would be acceptable to the community for which CoAP/CoRE is being developed? (Note that regardless of whether CoAP define= s the Block option, this mechanism of transferring resource representations through an external protocol via URIs is still something CoAP must enable.) Peter From zach@sensinode.com Wed Sep 8 03:38: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 8E75C3A6832 for ; Wed, 8 Sep 2010 03:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2PUT3SkskB3 for ; Wed, 8 Sep 2010 03:38:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DCFA93A68C8 for ; Wed, 8 Sep 2010 03:37:48 -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 o88Ac9iA023029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Sep 2010 13:38:09 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-24-692413430; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 8 Sep 2010 13:38:11 +0300 Message-Id: References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org, Klaus Hartke Subject: Re: [core] #23: Virtual server capability? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 10:38:39 -0000 --Apple-Mail-24-692413430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 2, 2010, at 2:22 AM, Peter Bigot wrote: > I'm satisfied with the current disposition of this ticket. Clients > that do not want to include Uri-Authority are free to omit it. > Servers that are simplified by requiring its presence are free to > require it. When these choices conflict, the two can still > communicate: the client simply adds information it already has and > retransmits the request, and the server gets what it needs[*]. All is > good, no? Both Klaus and Peter have captured the problem well, although with = slightly different terms. I think the only reason we were dropping = Uri-Authority from normal requests in coap-01 is that we didn't have = transversing transparent REST intermediates on our radar so far. I also = agree with Peter that moving the burden to the client is not a good = solution, however in some cases clients may be configured with = intermediate proxy information just as they are in HTTP. For the = solution to Ticket #23, I would like to add a rule to those suggested by = Peter: 1 If the Uri-Authority option is absent and the remainder of the URI = uniquely identifies a resource the server MAY proceed to execute the = request. =20 2. If the server is able to determine the IP destination address of the = request, it SHOULD/MAY? assume this as the authority of the URI.=20 3. If no authority can be determined and the server requires the = authority to identify the resource it MUST reject the request with "400 = Bad Request" [*] Is this acceptable? It makes use of the IP destination address possible = for stacks which give access to it. >=20 > Peter >=20 > [*] Carsten is absolutely right about the ugliness of using "400 Bad > Request" to identify this situation. In my proposed text I > specifically chose not to confuse the issue by inventing a new result > code. That's a whole separate issue, peripheral to this one, and on > which I currently hold no opinions. Right, I will use 400 Bad Request for now, and we need to separately = discuss whether to add a new response code for this...=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-24-692413430 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwODEwMzgx MVowIwYJKoZIhvcNAQkEMRYEFPLv0Rdg2M+YAv/OFzk3MwHUikdkMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFtY0aGkMXa8beAmISuZtSTQtpZS372LWxUejSCBm8kpSVJ7X9elst9M NIEWvN0Nbb1yR3H9Pe8+bAplQGqtibmO74QYuOIo3w+pk6iRjGNVJLn366fMCxYDA5uihyx1ok9b /uDZJnV5Gpj9ZNigPijT4ph80NgPk04bXVTDQKIMSDx14IV7Xuf4CZdvr8/zTgMIi9nLdJgdLPat GSnfwDgVo6KUItWuOfxdjqFnxZEktFfJZMRqBayN3wBNjD45Eimc6D+mpss7AekW+kg2sgAcy3xe ny6R9fUztHTuu3KUy+u4Sg0ZnKSXxVjLh+wh6uBEf+OvIWF3Bht7L4fKV0wAAAAAAAA= --Apple-Mail-24-692413430-- From zach@sensinode.com Wed Sep 8 03:42: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 6A3B63A6805 for ; Wed, 8 Sep 2010 03:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 HwspMKlHlsSL for ; Wed, 8 Sep 2010 03:42:34 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E66343A67E5 for ; Wed, 8 Sep 2010 03:42:33 -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 o88AgwXT024093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Sep 2010 13:42:58 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-25-692702777; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 8 Sep 2010 13:43:00 +0300 Message-Id: <590F32D5-3D7E-4F5F-A153-1B4DF58DD50D@sensinode.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] doubt regarding duplicate CON messages in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 10:42:35 -0000 --Apple-Mail-25-692702777 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 2, 2010, at 2:04 PM, Peter Bigot wrote: > Maybe we need a way for the server to detect retransmissions. Recall = that UDP can deliver packets out of order, and could (especially in a = wireless mesh network with sleeping nodes) take quite a long time to get = around to doing so. What we have now says the TID is specific to the = (source) endpoint. It's supposed to change on each new transaction, but = is not required to be incremented by one. I don't see a way for a = destination to infer the "freshness" of a packet by comparing its TID = with the one last received from the same source, since the TID is not = associated with the (source, destination) pair. This is something we have been thinking about especially for high = capacity end-points (e.g. on M2M data collection server) dealing with = large numbers of constrained end-points. There is nothing in the = specification that would disallow a client from associating TID with = each (source, destination) pair if it has the memory capacity for that.=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-25-692702777 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwODEwNDMw MVowIwYJKoZIhvcNAQkEMRYEFAzRP+Bc1fnP3pjLoQTUY/fVSpl4MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAEB/WyIFKgpKzXqFtGGcZAa1H13e8FFCAHW+sHzg2T19vKz3ayj1uNUV mLJovtv8nCZE81ZTAYJxyZt1nYdOnaANckKMTjw13VGxF8i6+SC8ZmAy4u9paHnDWJCdpL1MIlvV IxatWHpDTVXd8TRG5du1BSV9irAN61JXDzWNRxSPc4qMt+ro8stqOfuZzywt7n61tvF0hU9h01Mn kzWhg+udWltI9iDVyjSpsBWBf5Bj/rjUnDjKgyzBdKIKarvbUf80apNtMy40gFpfI0hpNoqIrE6K eHm22ZU1NNv1ykwOHi5M9QLtwob7jyGN6b9KL3P97I5KHtJ1Intjp1UWru8AAAAAAAA= --Apple-Mail-25-692702777-- From trac@tools.ietf.org Wed Sep 8 05:26:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FFC63A679F for ; Wed, 8 Sep 2010 05:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 XSPBjgIKmv7Q for ; Wed, 8 Sep 2010 05:26:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B653B3A676A for ; Wed, 8 Sep 2010 05:26:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OtJjf-0003AC-CF; Wed, 08 Sep 2010 05:26: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: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 08 Sep 2010 12:26:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/25 Message-ID: <057.c48d47c735ea30f8117943933607dbf7@tools.ietf.org> X-Trac-Ticket-ID: 25 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: [core] #25: 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: Wed, 08 Sep 2010 12:26:19 -0000 #25: Token option --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: minor | Milestone: coap-03 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- The token option is currently defined in coap-misc for the purpose of long-term matching of asynchronous replies. There are several situations where this option is being considered for use, therefore the correct place for it would be in the base coap specification. This ticket is to consider if the WG has consensus to add the Token option to CoAP, and if so to integrate that into the document (goal is to close this as part of coap-03). -- Ticket URL: core From zach@sensinode.com Wed Sep 8 05:27: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 A329E3A676A for ; Wed, 8 Sep 2010 05:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C21tvzf1rYua for ; Wed, 8 Sep 2010 05:27: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 0BB4B3A679F for ; Wed, 8 Sep 2010 05:27: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 o88CRcLj022422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Sep 2010 15:27:39 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-46-698983241; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 8 Sep 2010 15:27:41 +0300 Message-Id: References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Handling potentially-large resource representations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 12:27:17 -0000 --Apple-Mail-46-698983241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A few answers below from my understand of coap-block. One thing to = emphasize here - we definitely must define a black transfer option for = CoAP. In addition you surely may also use other protocols like TFTP to = transfer your resources, but that is out of scope for this WG as there = is nothing stopping you from doing so. =20 On Sep 7, 2010, at 12:45 PM, Peter Bigot wrote: > In what follows, I'm considering resource representations that would = produce > transaction message lengths that fall into three categories: "short" = (within > the path MTU), "oversize" (exceeds the path MTU but within the data = layer > MTU (IPv6 1280)), and "too big" (exceeds the data layer MTU). I = believe > that "too big" can be determined by the source natively, while = "oversize" is > discovered either by returning a Packet Too Big ICMP message to the = source > or by the network dropping the packet before it reaches the = destination. >=20 > My server provides a resource where the length of the representation = in a > given media type varies depending on the resource value. For some = values, > the representation will be oversize or too big, but in most cases the > representation is short. By default the clients GET the resource = without > including a block option in the request. >=20 > (1) If the server determines that the representation is too big and > therefore requires a block option for success, how does it communicate = this > need to the client? coap-block-00 specifies this already, it simply responds with the first = block in the response and includes the Block option. It is then up to = the client if it wants to request further blocks. >=20 > (2) If a transaction response turns out to be oversize and is not = delivered, > but the network returns a ICMP "Packet Too Big" message to the server, = is it > the server's responsibility to recognize this and respond to the = client as > though the representation was too big? [I think the answer has to be = "no", > because the network might not have returned that indication.] The server should then behave as in (1). I don't see how the client = could otherwise find out that it should "try" to request smaller blocks = instead of a normal request.=20 > (3) Assume a client begins to retrieve the resource value using GET = with > block options. During this series of transport transactions, the = value of the > resource changes, as does its representation. How is the client made = aware > of this so it does not reconstruct an invalid representation? >=20 > [For this last question I think the answer involves ETag, but since = ETag is > elective, the server or client or both may not recognize it, and it's = not > clearly defined when the server is permitted or obliged to include it = in a > response to a request that did not include it. I think an approach = that > allows this situation to arise in a way that a standards-conformant = CoAP > client cannot detect it is unacceptable. The end result may be that = ETag > becomes critical when using the Block option.] This is defined in Section 2.2 of coap-block-00, it has a SHOULD for the = use of ETag in this way. You are correct, ETag becomes critical when = used together with Block. >=20 > (4) I see that draft-bormann-core-coap-block-00 introduces both the = Block > option and the Token option, which have been removed from > draft-bormann-coap-misc-06. I'm concerned that if this pairing = remains, it > would implicitly require that both be implemented together in order to = claim > conformance to the corresponding RFC, when in fact Token is useful and > warranted independently of the Block option. Is that a valid concern = shared > by anybody else? coap-block-00 is not a WG document yet, so this pairing to me is = temporary. Token is not required by Block, but if we find it useful in = general the right place for it is in the base coap specification. I = think Token is actually still defined in coap-misc-06 right now, but is = just shortly mentioned in coap-block-00. I will add consideration of = Token for the base coap spec as a ticket aimed at coap-03. We have = enough to close already for -02. >=20 > (5) As noted in the interim WG telecon, Block is the first option that > clearly applies at the transport level rather than the REST level of = CoAP. > The ramifications of this on end-to-end processing are still being > understood. CoAP would be tremendously simplified by delegating > responsibility for transferring large resource representations to an > alternative protocol such as tftp, and natively supporting only those > resources that fit within the data layer MTU. Servers would redirect > requests to resources with large descriptions to a URI with a = different > scheme; clients would transmit requests using a URI content-type that = the > server would have to retrieve (or reject as unsupported). Is there = any > chance that this approach would be acceptable to the community for = which > CoAP/CoRE is being developed? (Note that regardless of whether CoAP = defines > the Block option, this mechanism of transferring resource = representations > through an external protocol via URIs is still something CoAP must = enable.) We seem to have good WG consensus that we will standardize an optional = Block transfer feature. There is nothing stopping you from developing a = server that also makes resources available using e.g. TFTP, but that = functionality is out of scope for the WG in my opinion. Web servers = often make resources also available via FTP in the same way.=20 Zach >=20 > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-46-698983241 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwODEyMjc0 MVowIwYJKoZIhvcNAQkEMRYEFJ5cmOdusTCLx8mO5PqYXq63J/xVMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAF3eFYmDin1qL8MCQXiMkC27U1V1ibw3Axgkztju2hfcfLrEEIHcLm4q Fu/Lx1izIqL5XIEM4hylP7k4rRf9g7ojrh2ImsGYQUyiNWNU8ASYk9vGSe7zqZ/1eYiRowdhxNyN rBV+Ym5m6Pc5H7fhabST1SnonIDgoOyGWS9HtzzReDR3Yo7qGjvtm403bxyMUIUicZ4hL+cVw5Xl GcRKSllg5vWl8HJZO8ykK575bT3Hw6U0wQ1jYANSwoilPLz5xYX4/J4JRtwQi7q/2NIQXE3HfqW2 TVhAcz0EL0Oj7r5jbC6l4t6U5ADozy2uqkDZ9gP9qP5Wlj9jUD5LpXt1y5AAAAAAAAA= --Apple-Mail-46-698983241-- From pab@peoplepowerco.com Wed Sep 8 08:00: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 3D3F03A68DE for ; Wed, 8 Sep 2010 08:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=0.454, 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 WF6EGyJC60ai for ; Wed, 8 Sep 2010 08:00: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 8F36D3A68F3 for ; Wed, 8 Sep 2010 08:00:39 -0700 (PDT) Received: by fxm18 with SMTP id 18so140819fxm.31 for ; Wed, 08 Sep 2010 08:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.200 with SMTP id g8mr10528fap.103.1283958066674; Wed, 08 Sep 2010 08:01:06 -0700 (PDT) Received: by 10.223.112.70 with HTTP; Wed, 8 Sep 2010 08:01:06 -0700 (PDT) In-Reply-To: References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> Date: Wed, 8 Sep 2010 10:01:06 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org, Klaus Hartke Subject: Re: [core] #23: Virtual server capability? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 15:00:41 -0000 I would accept MAY in the new rule. I still think this is a bad idea for consistent end-to-end REST processing, so SHOULD makes me uncomfortable, especially as it's conditional on an implementation choice. MAY is more consistent with rule 1 as well. Peter On Wed, Sep 8, 2010 at 5:38 AM, Zach Shelby wrote: > > On Sep 2, 2010, at 2:22 AM, Peter Bigot wrote: > >> I'm satisfied with the current disposition of this ticket. =A0Clients >> that do not want to include Uri-Authority are free to omit it. >> Servers that are simplified by requiring its presence are free to >> require it. =A0When these choices conflict, the two can still >> communicate: the client simply adds information it already has and >> retransmits the request, and the server gets what it needs[*]. =A0All is >> good, no? > > Both Klaus and Peter have captured the problem well, although with slight= ly different terms. I think the only reason we were dropping Uri-Authority = from normal requests in coap-01 is that we didn't have transversing transpa= rent REST intermediates on our radar so far. I also agree with Peter that m= oving the burden to the client is not a good solution, however in some case= s clients may be configured with intermediate proxy information just as the= y are in HTTP. For the solution to Ticket #23, I would like to add a rule t= o those suggested by Peter: > > 1 =A0If the Uri-Authority option is absent and the remainder of the URI u= niquely identifies a resource the server MAY proceed to execute the request= . > 2. If the server is able to determine the IP destination address of the r= equest, it SHOULD/MAY? assume this as the authority of the URI. > 3. If no authority can be determined and the server requires the authorit= y to identify the resource it MUST reject the request with "400 Bad Request= " [*] > > Is this acceptable? It makes use of the IP destination address possible f= or stacks which give access to it. > >> >> Peter >> >> [*] Carsten is absolutely right about the ugliness of using "400 Bad >> Request" to identify this situation. =A0In my proposed text I >> specifically chose not to confuse the issue by inventing a new result >> code. =A0That's a whole separate issue, peripheral to this one, and on >> which I currently hold no opinions. > > > Right, I will use 400 Bad Request for now, and we need to separately disc= uss whether to add a new response code for this... > > 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 > > From pab@peoplepowerco.com Wed Sep 8 09:02: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 BAFF83A6807 for ; Wed, 8 Sep 2010 09:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=0.444, 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 o5tf3PEDJEyD for ; Wed, 8 Sep 2010 09:02: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 EF9AF3A695F for ; Wed, 8 Sep 2010 09:02:42 -0700 (PDT) Received: by fxm18 with SMTP id 18so208935fxm.31 for ; Wed, 08 Sep 2010 09:03:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.103.203 with SMTP id l11mr167074fao.82.1283961790087; Wed, 08 Sep 2010 09:03:10 -0700 (PDT) Received: by 10.223.112.70 with HTTP; Wed, 8 Sep 2010 09:03:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Sep 2010 11:03:10 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Handling potentially-large resource representations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:02:44 -0000 Thanks. Responses inline. On Wed, Sep 8, 2010 at 7:27 AM, Zach Shelby wrote: >> (1) If the server determines that the representation is too big and >> therefore requires a block option for success, how does it communicate t= his >> need to the client? > > coap-block-00 specifies this already, it simply responds with the first b= lock in the response and includes the Block option. It is then up to the cl= ient if it wants to request further blocks. That the server can add the block option to a response when it was not present in the request was not clear to me on initial reading, and still isn't. I was going to suggest clarifying that, but actually I'm going to recommend that the server reject the message with a code that indicates that the response is too big. If the client isn't explicitly (and reliably) informed that the response is large, network limitations out of the control of both the client and the server can prevent the client from ever getting a response and knowing that the reason is that it needed to use a block option. See below. >> (2) If a transaction response turns out to be oversize and is not delive= red, >> but the network returns a ICMP "Packet Too Big" message to the server, i= s it >> the server's responsibility to recognize this and respond to the client = as >> though the representation was too big? =A0[I think the answer has to be = "no", >> because the network might not have returned that indication.] > > The server should then behave as in (1). I don't see how the client could= otherwise find out that it should "try" to request smaller blocks instead = of a normal request. If the server receives ICMP messages and correlates them with responses, it *could* retransmit its response with a (smaller) block option. Big "if", IMO: I think we should assume that ICMP "Packet Too Big" messages are more likely to be absent than available. To clarify this: In the normal case, the client sends a request (without a block option); the server sends the first block of the response; the network eats it. The client never gets a response, so the transaction layer retransmits the same request. I assume that the server is *not* permitted to send a different response payload to this request, since it can't be sure (absent ICMP) why the client didn't get it, and therefore it can't be sure the client won't still receive a late-delivered earlier version. Having multiple distinct responses to the same request floating about would be very confusing. Therefore, the server repeatedly sends the same response packet which gets eaten by the network every time. The client ultimately times out because it doesn't get a response, but it doesn't know why. Normally this would be because of a more complete network failure between the client and the server. Only if the client knew that the document might be large (because it included the block option) could it assume that perhaps the loss was due to a path MTU problem, and re-try the request with a smaller block size. I don't think there's any way the server can infer from the receipt of a second request for the same resource, absent a block option, that the reason the client is asking for it again is because it didn't get it the first time, and therefore change the block size that it uses. (Also, if it could infer this, it would still have to remember that that client had just requested that resource and what block size it used in the response, which is an unreasonable burden.) Similarly, if the server had already informed the client the response would be coming asychronously, from the client's perspective it will simply never get an answer. Again it won't know that MTU issues are the cause. I believe all this confusion goes away if the server only sends responses with block options in the case where the client has explicitly requested it. Since the maximum size of a block (2048 bytes) is larger than the expected data layer MTU (1280), this should not significantly increase traffic: requests involving a resource that is known to potentially exceed an MTU can support this with a one-byte block option asking for the first 2KB of the response, incurring no re-request overhead when the response fits in a packet. For completeness, the server should be permitted to reject a request that includes a block option if it knows that the requested block size is too large for the intervening network. The same response code can be used for this as for the case when the client does not include a block option in the request. >> (3) Assume a client begins to retrieve the resource value using GET with >> block options. =A0During this series of transport transactions, the valu= e of the >> resource changes, as does its representation. =A0How is the client made = aware >> of this so it does not reconstruct an invalid representation? >> >> [For this last question I think the answer involves ETag, but since ETag= is >> elective, the server or client or both may not recognize it, and it's no= t >> clearly defined when the server is permitted or obliged to include it in= a >> response to a request that did not include it. =A0I think an approach th= at >> allows this situation to arise in a way that a standards-conformant CoAP >> client cannot detect it is unacceptable. =A0The end result may be that E= Tag >> becomes critical when using the Block option.] > > This is defined in Section 2.2 of coap-block-00, it has a SHOULD for the = use of ETag in this way. You are correct, ETag becomes critical when used t= ogether with Block. SHOULD is not MUST. I think we need to require ETag on any transaction response that includes the block option. ETag can't (syntactically) be critical unless there's a new ETag header that has an odd type code. Requiring it be paired with the (critical) block would at least allow the specification to mandate its implementation and recognition in this situation; clients that don't implement block won't mistakenly interpret the partial response as complete because block *is* syntactically critical. Block is really messy once you get into the details, but if we only permit the server to send the option when it's present in the request, and we require ETag to be included in every response message that includes the block option, I think these problems can be avoided. Peter From zach@sensinode.com Thu Sep 9 03:41: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 6517C3A67D4 for ; Thu, 9 Sep 2010 03:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 2cy60d1Azi7w for ; Thu, 9 Sep 2010 03:41:40 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 719A13A67F1 for ; Thu, 9 Sep 2010 03:41: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 o89Ag1B0011848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Sep 2010 13:42:01 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-10-779045218; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Thu, 9 Sep 2010 13:42:03 +0300 Message-Id: <3AA3CF63-F926-4C0B-A133-BF50BCD00CA9@sensinode.com> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org, Klaus Hartke Subject: Re: [core] #23: Virtual server capability? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 10:41:41 -0000 --Apple-Mail-10-779045218 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Allright, let's give it a try with MAY. If this rule becomes problematic = in practice I am happy to remove it later on as well.=20 Zach On Sep 8, 2010, at 6:01 PM, Peter Bigot wrote: > I would accept MAY in the new rule. I still think this is a bad idea > for consistent end-to-end REST processing, so SHOULD makes me > uncomfortable, especially as it's conditional on an implementation > choice. MAY is more consistent with rule 1 as well. >=20 > Peter >=20 > On Wed, Sep 8, 2010 at 5:38 AM, Zach Shelby = wrote: >>=20 >> On Sep 2, 2010, at 2:22 AM, Peter Bigot wrote: >>=20 >>> I'm satisfied with the current disposition of this ticket. Clients >>> that do not want to include Uri-Authority are free to omit it. >>> Servers that are simplified by requiring its presence are free to >>> require it. When these choices conflict, the two can still >>> communicate: the client simply adds information it already has and >>> retransmits the request, and the server gets what it needs[*]. All = is >>> good, no? >>=20 >> Both Klaus and Peter have captured the problem well, although with = slightly different terms. I think the only reason we were dropping = Uri-Authority from normal requests in coap-01 is that we didn't have = transversing transparent REST intermediates on our radar so far. I also = agree with Peter that moving the burden to the client is not a good = solution, however in some cases clients may be configured with = intermediate proxy information just as they are in HTTP. For the = solution to Ticket #23, I would like to add a rule to those suggested by = Peter: >>=20 >> 1 If the Uri-Authority option is absent and the remainder of the URI = uniquely identifies a resource the server MAY proceed to execute the = request. >> 2. If the server is able to determine the IP destination address of = the request, it SHOULD/MAY? assume this as the authority of the URI. >> 3. If no authority can be determined and the server requires the = authority to identify the resource it MUST reject the request with "400 = Bad Request" [*] >>=20 >> Is this acceptable? It makes use of the IP destination address = possible for stacks which give access to it. >>=20 >>>=20 >>> Peter >>>=20 >>> [*] Carsten is absolutely right about the ugliness of using "400 Bad >>> Request" to identify this situation. In my proposed text I >>> specifically chose not to confuse the issue by inventing a new = result >>> code. That's a whole separate issue, peripheral to this one, and on >>> which I currently hold no opinions. >>=20 >>=20 >> Right, I will use 400 Bad Request for now, and we need to separately = discuss whether to add a new response code for this... >>=20 >> Zach >>=20 >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >>=20 >>=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-10-779045218 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwOTEwNDIw M1owIwYJKoZIhvcNAQkEMRYEFEwUa7F9UsAHSK+xpF5jwksbl3qxMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFHEWm1Wn/yBIGt8LxHde2BpTSJeTITHUcMiWUpsulMd7vlnCFQXE/d6 7E3EphndpBrSij8+FDcgaU0i3uXp1NhdEda6ha8Ue7K4WwkcYGKa3pIBkomiFHNTwyC2FAptWdxe zph7Uj+OaU9Ue802JE0Q01YfA1PkTQBUCGfvBNjbWS9qaMIfdk55HZEuV4xOH7v8SKgPgbDLGW8T UY4j0CIP7fbpjIxDKebvldN0wPdBwO5xPfRGtQd7fqeKW24Gt132P59/a839JcSj7xR6Xe0D4dja CLN8k5IBp4HUxY3vjn4LDtt/KqTgiQZjDcrt8nVjToTUEM9DtxIGLp+vGU0AAAAAAAA= --Apple-Mail-10-779045218-- From trac@tools.ietf.org Thu Sep 9 03:44: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 C2D4A3A67F1 for ; Thu, 9 Sep 2010 03:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 NdiTPCvC-ylv for ; Thu, 9 Sep 2010 03:44:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AAEB83A67D4 for ; Thu, 9 Sep 2010 03:44: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 1Oted1-0006bN-2C; Thu, 09 Sep 2010 03:45:15 -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: Thu, 09 Sep 2010 10:45:15 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/23#comment:1 Message-ID: <066.7062ea16e4d70e132637fa12f7f1793e@tools.ietf.org> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.5447f06c446cb40161a608a9b48422f5@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] #23: Virtual server capability? 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, 09 Sep 2010 10:44:48 -0000 #23: Virtual server capability? --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: minor | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Comment(by zach@…): From a longish WG list discussion led by Peter Bigot it became clear there is a valid use case for the URI Authority in CoRE. However, for efficiency it should be possible for a client to leave the URI-Authority out. The following rule was defined for coap-02: 1 If the Uri-Authority option is absent and the remainder of the URI uniquely identifies a resource the server MAY proceed to execute the request. 2. If the server is able to determine the IP destination address of the request, it MAY assume this as the authority of the URI. 3. If no authority can be determined and the server requires the authority to identify the resource it MUST reject the request with "400 Bad Request" [*] [*] 400 Bad Request is pretty badly overloaded, so it is still to be determined if a new error code is needed for this case. -- Ticket URL: core From zach@sensinode.com Thu Sep 9 03:46: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 185D43A6A5B for ; Thu, 9 Sep 2010 03:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 pITEdRycnuEk for ; Thu, 9 Sep 2010 03:46: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 136EF3A6A63 for ; Thu, 9 Sep 2010 03:46: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 o89AkqQo012415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Sep 2010 13:46:53 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-11-779336558; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Thu, 9 Sep 2010 13:46:54 +0300 Message-Id: <83357A84-4278-4E7B-961A-A12380FF01E5@sensinode.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Handling potentially-large resource representations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 10:46:33 -0000 --Apple-Mail-11-779336558 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 8, 2010, at 7:03 PM, Peter Bigot wrote: > Block is really messy once you get into the details, but if we only > permit the server to send the option when it's present in the request, > and we require ETag to be included in every response message that > includes the block option, I think these problems can be avoided. Sounds like reasonable advice to me, but I'll defer to the authors of = coap-block to take this into account.=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-11-779336558 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwOTEwNDY1 NFowIwYJKoZIhvcNAQkEMRYEFPZ+TDLDJqF4wJjWliPH+1AZAfFvMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAAgZdBSclKGmM9HjTy+Rjgx2lCr9El/fOAK+0ovsqgSi+VhgcMm8FZ9+ 436sVVAmkdZZs6Cv5mS86Z5zPguVCdL/tR3cEXVEeyPRiB8c2mavzGQXix4ANRYgxjP1wWFZroAm fHfvUwoxtz6emsUEdynkhSxWaS0Jpyo3nPkXI0zjnGwPkb9FKgqt6BRe9lh330v2xCM3I406V0Gg sg9RmeEtdLw7pHqtpxG+SQiCGmROvWWYnyBPcWbnQJ61h/Tsy/ZBZ83Iv6p4y0AC9rEUSQdNwsxl obLEDSaSwU56KVKIKRXJVur5mfUbdaHG3V16bB7JuUFKUxMDBJgTpkqJ960AAAAAAAA= --Apple-Mail-11-779336558-- From trac@tools.ietf.org Thu Sep 9 04:19: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 5445C3A6814 for ; Thu, 9 Sep 2010 04:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 BlNyeH40BMCX for ; Thu, 9 Sep 2010 04:19:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5A72B3A67F1 for ; Thu, 9 Sep 2010 04:19: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 1OtfAS-0007Ij-Ns; Thu, 09 Sep 2010 04:19: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: Thu, 09 Sep 2010 11:19:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/20#comment:1 Message-ID: <066.e8cfa5e269d7f6a4479cf9453aa333ea@tools.ietf.org> References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <057.a66ba7c3b9381ba45cb0037c8effd015@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] #20: Proxying clarification 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, 09 Sep 2010 11:19:22 -0000 #20: Proxying clarification --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: coap-02 Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: The third change was made in coap-02 and Uri-Scheme was removed. The first two changes are no longer relevant due to Ticket #23. -- Ticket URL: core From trac@tools.ietf.org Thu Sep 9 04:27: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 F219A3A6827 for ; Thu, 9 Sep 2010 04:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 yM+-lvAP5g7L for ; Thu, 9 Sep 2010 04:27:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 399403A6824 for ; Thu, 9 Sep 2010 04:27:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OtfI5-00028C-Pd; Thu, 09 Sep 2010 04:27:41 -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: Thu, 09 Sep 2010 11:27:41 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/24#comment:1 Message-ID: <066.57b0556c1732af97e56c8de37919076c@tools.ietf.org> References: <057.dc61e7b30438c8091fedd8b14607cd68@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <057.dc61e7b30438c8091fedd8b14607cd68@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] #24: Clarification about repeated options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 11:27:15 -0000 #24: Clarification about repeated options --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: closed Priority: minor | Milestone: coap-02 Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Based on the list discussion, multiple options are not forbidden, but each option must describe if it can occur multiple times and the resulting meaning in that case. Current options in coap-02 can occur only once, with the possible exception of Etag (TBD). -- Ticket URL: core From trac@tools.ietf.org Thu Sep 9 04:38: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 487133A6851 for ; Thu, 9 Sep 2010 04:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 r3ke6VtJ8E5P for ; Thu, 9 Sep 2010 04:38:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 56B9D3A683E for ; Thu, 9 Sep 2010 04:37:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OtfS7-0005W8-IO; Thu, 09 Sep 2010 04:38:03 -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: Thu, 09 Sep 2010 11:38:03 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/23#comment:2 Message-ID: <066.3934da178a7dde230da0dcc43bf9946b@tools.ietf.org> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.5447f06c446cb40161a608a9b48422f5@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] #23: Virtual server capability? 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, 09 Sep 2010 11:38:11 -0000 #23: Virtual server capability? --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: closed Priority: minor | Milestone: coap-02 Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Rules added to Section 2.5.2 of coap-02 and proxy section fixed. -- Ticket URL: core From trac@tools.ietf.org Thu Sep 9 04:40: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 B01B53A685D for ; Thu, 9 Sep 2010 04:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 9BnbPq8AGf+F for ; Thu, 9 Sep 2010 04:40:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 42F8D3A6857 for ; Thu, 9 Sep 2010 04:39:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OtfU3-0007OZ-06; Thu, 09 Sep 2010 04:40:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: fluffy@cisco.com, zach@sensinode.com X-Trac-Project: core Date: Thu, 09 Sep 2010 11:40:02 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/6#comment:3 Message-ID: <066.f563c3f6fc4ce78771627fd4aefbb4e5@tools.ietf.org> References: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <057.da78d33bccd664276d29b01bb2121dd2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: fluffy@cisco.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #6: Date option text needs update X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 11:40:19 -0000 #6: Date option text needs update --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Cullen Jennings Type: defect | Status: closed Priority: trivial | Milestone: coap-02 Component: coap | Version: Severity: - | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => wontfix -- Ticket URL: core From trac@tools.ietf.org Thu Sep 9 04:42: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 759953A6827 for ; Thu, 9 Sep 2010 04:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 sRHP31dHBtTo for ; Thu, 9 Sep 2010 04:42:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 895A23A6821 for ; Thu, 9 Sep 2010 04:42:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OtfXK-0007qJ-4I; Thu, 09 Sep 2010 04:43:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 09 Sep 2010 11:43:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/18#comment:1 Message-ID: <066.ef34469629740fc46f9e89e2bc7ae06f@tools.ietf.org> References: <057.72fc0681b884c100f9ed31e99d5f745b@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <057.72fc0681b884c100f9ed31e99d5f745b@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] #18: Error on critical option clarification 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, 09 Sep 2010 11:42:59 -0000 #18: Error on critical option clarification --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: trivial | Milestone: coap-02 Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Fixed in coap-02. -- Ticket URL: core From trac@tools.ietf.org Thu Sep 9 04:46: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 4461E3A6878 for ; Thu, 9 Sep 2010 04:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 umphezAi0-KB for ; Thu, 9 Sep 2010 04:46:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 68F133A6851 for ; Thu, 9 Sep 2010 04:46:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OtfaQ-0000mf-2H; Thu, 09 Sep 2010 04:46:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 09 Sep 2010 11:46:37 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/21#comment:1 Message-ID: <066.fefb515eea5a0ace5599c9a1a005f713@tools.ietf.org> References: <057.83b661287e9e4b9d6725189a7f45adbe@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <057.83b661287e9e4b9d6725189a7f45adbe@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] #21: Resource discovery changes 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, 09 Sep 2010 11:46:11 -0000 #21: Resource discovery changes --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: critical | Milestone: coap-02 Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - The resource discovery section is now removed from coap-02 with a reference to a separate CoRE Link Format document. - The CoRE Link Format document defines an improved link-format, the /.well-known/core URI and the Internet media type for the payload. References to multicast and DNS-SD were removed completely. The draft is in progress and will be submitted with coap-02. -- Ticket URL: core From trac@tools.ietf.org Thu Sep 9 04:56: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 791883A6821 for ; Thu, 9 Sep 2010 04:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 mayFUjRLuGgF for ; Thu, 9 Sep 2010 04:56:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 671AD3A6851 for ; Thu, 9 Sep 2010 04:56:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OtfkY-0004S3-WD; Thu, 09 Sep 2010 04:57:07 -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: Thu, 09 Sep 2010 11:57:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/19#comment:1 Message-ID: <066.2bc370aa1f01bce641d756d8d3d4d077@tools.ietf.org> References: <057.ca541c1c2b0a8779f8dcf23985b22808@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <057.ca541c1c2b0a8779f8dcf23985b22808@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] #19: Clarification about PUT 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, 09 Sep 2010 11:56:40 -0000 #19: Clarification about PUT --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: trivial | Milestone: coap-02 Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Fixed in coap-02 -- Ticket URL: core From zach@sensinode.com Thu Sep 9 05:14: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 0093E3A6880 for ; Thu, 9 Sep 2010 05:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 7QIq0VEEBI-H for ; Thu, 9 Sep 2010 05:13: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 B52BD3A6827 for ; Thu, 9 Sep 2010 05:13:57 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o89CEK4a026375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 9 Sep 2010 15:14:21 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-14-784585027; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 9 Sep 2010 15:14:22 +0300 Message-Id: <11C475FD-519E-4A27-AFD7-74E40EFF6482@sensinode.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Security considerations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 12:14:00 -0000 --Apple-Mail-14-784585027 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry for the barrage of Trac messages, but I am working on closing the = open tickets for coap-02. Most of the tickets were straight-forward = thanks to good list discussion.=20 The Security considerations sections is going to need to new work = though, and we need help from the WG here. I created an initial table of = contents for the section. Rene Struik informally volunteered to help out = on the DTLS section, any other help/ideas welcome as well. On the = security limitations I encourage everyone to think about that, and throw = any ideas for what to include there to the list. It is a good idea to = start with reading section 15 of RFC2616 as some of that is pertinent to = CoAP as well. What new limitations are special for CoAP? I tried to list = a few possible ones below. 10. Security Considerations 10.1. Securing CoAP with DTLS This section describes how to secure CoAP with DTLS, along with a couple minimal DTLS configurations appropriate for constrained environments. 10.2. Threat analysis and protocol limitations This section is meant to inform protocol and application developers about the security limitations of CoAP as described in this document. As CoAP realizes a subset of the features in HTTP/1.1, the security considerations in Section 15 of [RFC2616] are also pertinent to CoAP. This section concentrates on describing limitations specific to CoAP and CoRE. 10.2.1. Processing URIs 10.2.2. Proxying and Caching 10.2.3. Attacks on TIDs 10.2.4. Risk of amplification using multicast 10.2.5. Asynchronous responses --=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-14-784585027 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwOTEyMTQy M1owIwYJKoZIhvcNAQkEMRYEFOPpo6HbxqC8cIPOEHzBijRcZiTbMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADMq21UYGoWensKfDyk5ZhzJqqmP+tYrXq5wnHM69UmkelnLZ1SI2VM4 q4wQwBSGlkVf6HfP6ANfM7SS7WPBZXXb8ViVtULmSTlXaJkqKEQTN7dKV0W+7GmpFwCacBb45cMw 2TDnaAjJ29FuxfPhnfu9fD4NHnMnaIede1Csck+taQoUDnFXLHpMI7A5yLzTetNLwrPdeBEGMZmW IC0sIXK+z00/eTyby5n1zEaw/WcaFUZcuudzuVDQ8UdXwrbw0F/jRK5VHCOe/Ha1aak1eufd8Fb+ tbct3372Pu1oh15BNm+yfKTqbPQbhTCYVObfmIZvhD51BUAYyTgSBpSQ408AAAAAAAA= --Apple-Mail-14-784585027-- From hariharasudhan.tce@gmail.com Thu Sep 16 00:09: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 194443A6868 for ; Thu, 16 Sep 2010 00:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.183 X-Spam-Level: X-Spam-Status: No, score=-1.183 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcqF9TBFdJJ4 for ; Thu, 16 Sep 2010 00:09:11 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0F1B13A6767 for ; Thu, 16 Sep 2010 00:09:11 -0700 (PDT) Received: by iwn3 with SMTP id 3so961212iwn.31 for ; Thu, 16 Sep 2010 00:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=6dCT2X1QG5nzDrDpecgTz9LRoxLo6/XX28k3psnByLg=; b=PHtmdJ+A6erTvMM875ewrPmwqOJd5HHD1Ip28NpSZqXrql4+uL6WqmBAm0cW9Gdi/M 9pV/9Ea1XqWc7U//6NOn4GqaQS2c6XDlAVZM6UnW9wtwarvUQ1ceKaFhWDFSLSBvN7z4 xfvS6mO2EYIc9yxKG6ctNT1qu+7OSlQ5YFBBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XFV+nPdvTIuxU54sAdslihNjEm9irEyiPFF8iVwaKJ8vvW18twhoLF1ptMr4rZnmAy SFn/IODgCTd9xEyZvKm5QCoXNKjkJsRPUm9nxXeWGlipZvEaZYtBKflNaMdNAkt9Xg8u EKAtmr9busR0xGyuWJUxOMR9xbOT/9HV/Tu1s= MIME-Version: 1.0 Received: by 10.231.59.212 with SMTP id m20mr2990634ibh.130.1284620973820; Thu, 16 Sep 2010 00:09:33 -0700 (PDT) Received: by 10.231.199.141 with HTTP; Thu, 16 Sep 2010 00:09:33 -0700 (PDT) Date: Thu, 16 Sep 2010 12:39:33 +0530 Message-ID: From: Hari Hara Sudhan R To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Problem in using ACK in resource discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 07:09:12 -0000 CoAP spec mentions that when CoAP endpoint receives an acknowledgement it searches for context and if it doesnt any entry they send a RESET message. Section 2.2.4. of CoAP spec indicates that "A Reset message indicates that a specific Confirmable message was received, but some context is missing to properly process it." Section 4.2 Retransmission mention that "When a matching Acknowledgment is received for an entry, the entry is invalidated." When resource discovery message ("./well-known/core") is multicast more than one CoAP endpoint would send a RD response. when the first ACK response is received the entry is invalidated and all the other ACKs sent by the other clients will result in RESET message as it will not be able to find the CoAP context. Should we handle the CON message for resource discovery in a different way? Thanks and Regards, Hari Hara Sudhan R From cabo@tzi.org Fri Sep 24 01:56: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 923613A6B10 for ; Fri, 24 Sep 2010 01:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.177 X-Spam-Level: X-Spam-Status: No, score=-107.177 tagged_above=-999 required=5 tests=[AWL=1.072, 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 MPk8H2UYgNQr for ; Fri, 24 Sep 2010 01:56:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id BBF8C3A6B0C for ; Fri, 24 Sep 2010 01:56: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 o8O8uq6V025327 for ; Fri, 24 Sep 2010 10:56:52 +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 1BCE1F6B; Fri, 24 Sep 2010 10:56:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann X-Priority: 3 Date: Fri, 24 Sep 2010 10:56:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <233397975.1285088047253.JavaMail.nobody@jsj2wl013.webex.com> To: core X-Mailer: Apple Mail (2.1081) Subject: [core] 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, 24 Sep 2010 08:56:30 -0000 [I seem to have really bad luck with E-Mail right now. =20 This is a resend, because the original message never arrived in the = mailing list archive.] At the last CORE Webex meeting, we discussed having these meetings once = a month in the last week of the month. So I asked for a Webex room/conference/meeting and got it assigned -- = unfortunately, I didn't notice that this message only got to me. Kerry = just pointed out to me that this hadn't been announced on the list. So please find the details below (and please accept my apologies for = sitting on this information). Note that 1500 UTC ("GMT") is 0800 PDT, 1100 EDT, 1700 CEST, 1800 EEST, = 2400 JST/KST. If you have agenda items that you want to bring to this meeting, please = give Cullen and me -- a short subject line, -- the objective of having that discussion, and -- pointer(s) to relevant draft(s). If your item gets scheduled, I'd like your slides on Monday so I can do = the usual consolidated set. Gruesse, Carsten > Hello ,=20 >=20 > IETF Secretariat invites you to attend this online meeting.=20 >=20 > Topic: CORE WG=20 > Date: Wednesday, September 29, 2010=20 > Time: 3:00 pm, (Reykjavik, GMT)=20 > Meeting Number: 963 078 535=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=3D147542532&UID=3D118579186= 2&RT=3DMiMyMA%3D%3D=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=3D147542532&UID=3D118579186= 2&ORT=3DMiMyMA%3D%3D=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= =3D147542532&tollFree=3D0=20 >=20 > Access code:963 078 535=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=3D147542532&UID=3D118579186= 2&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DvjLz1JtYfKkmL2Gpzw5H1lr7GVJUx0nv3CS= fu33a3iU=3D&RT=3DMiMyMA%3D%3D=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 kerlyn2001@gmail.com Fri Sep 24 05:51: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 CA66B3A6B91 for ; Fri, 24 Sep 2010 05:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 SbOP25g4KpWj for ; Fri, 24 Sep 2010 05:51: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 A7A2B3A6B42 for ; Fri, 24 Sep 2010 05:51:05 -0700 (PDT) Received: by bwz9 with SMTP id 9so2499700bwz.31 for ; Fri, 24 Sep 2010 05:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=eiHuBF7qJ4k7NtGzXxh/tnkapyBMeS5aZGWWITSFv/Q=; b=XIUhFFU1kzKQKMd/hIQaj1pF7K6aNofMIZxzIDghqBxB9CRN4t/Z4Iav6uTACtBS/A BpkZy16gbmWxiGnwZyL0S4qiK4TaXZiWPZFS876KNhK/NZtVUMd/nfTKN2Iqm7/cUNIf Sz37whDGgSPHQsFNGDoOJTyzv5nTnIBETJnqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NdYtJsC5liKSKHiyfnNAapGzFtYtoDK+RQvfaHiK07E8wZ2Jz+WYPMNlbEWvC1vhPK pOR39LK7LKR9ruFKWvqgDJQCguu1/mbyCEjlnHd+nueSjmerIeHCf6stRbpb6844knb2 +z7a/t1KvNVTyAaEidCKos2/u5HIuYYk1wAMA= MIME-Version: 1.0 Received: by 10.204.54.82 with SMTP id p18mr1984071bkg.142.1285332696250; Fri, 24 Sep 2010 05:51:36 -0700 (PDT) Received: by 10.204.104.14 with HTTP; Fri, 24 Sep 2010 05:51:36 -0700 (PDT) Date: Fri, 24 Sep 2010 08:51:36 -0400 Message-ID: From: Kerry Lynn To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Proposed Energy Management (eman) 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, 24 Sep 2010 12:51:06 -0000 This was news to me: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07907.html Subscribe to the discussion here: https://www.ietf.org/mailman/listinfo/eman -K- From behcetsarikaya@yahoo.com Fri Sep 24 14:34: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 8517F3A67D4 for ; Fri, 24 Sep 2010 14:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.266, 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 Dguwe1GONmXZ for ; Fri, 24 Sep 2010 14:34:04 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id 5A6243A6A45 for ; Fri, 24 Sep 2010 14:34:03 -0700 (PDT) Received: (qmail 29853 invoked by uid 60001); 24 Sep 2010 21:34:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1285364073; bh=2H3Sd7LOFMhCCFVNiUfsaFCtcXGVTLqhayYkjEl1lCg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=doSV+oTKhBIhGxdos0cQ0pPHLlxFSfkGJdMHhjehB4JOioRq4AXvek/NcMjr3d8zv9+Cntvo3fkVDaQZt77B26kazj6TygMVNXvuNp87AbCcsyM7EJhWQbVUcytMsf+czuayxbLMuL2cxsUQTb6QH9E2suiAmmGnFEAPZ20Hlgo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6A4Fa7fXHhSjvMUMRkrdX2dAAeIsVwaBkdnGHLXQXlchChTgJ4AYIGghIexmXK67Xu758xt3JMQOFLeZ9A4GlD+ZtOurlu5KxV6olrbJL13lZ1ALde5PFpVwTyudgAihJv1r8MEmyjt00vOH/uFu04zhRuqxy6FLH+z/gfmQMR8=; Message-ID: <49642.29391.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: 0.j60r0VM1nF_BTi24pbqWLRoJebKkCoyas2AJ6Y6NwqrNz gfMguvXE0.BnF8tn.N2NYwdjQyu_VHhFgghq.qAOp7Ct.mVAqWtusT748h6_ dKNgAV4yAkyxanqFD2vdzHL51fPw9LaQFobGlOsCT.nSDY0nYA.rsxRMSud6 cmLMSKACozAH1lBGmWuF_RTAOKYrjYLct_CvcMsXBg4a4UrMox.L1_joas2L WhZA8Dum78.JZloSzDduuS6xRvYYrSJrdMyaWY4qWWYG_13ksWt026T3I8aA o4TRtUPYmesPGeGUm2Bo2PFBQYJpdXyBbgexWdBmRluv4sdzZZtq_I_qHbD5 M9f77grArubvIT5YVMqMrSE02Sg-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Fri, 24 Sep 2010 14:34:32 PDT X-Mailer: YahooMailRC/497 YahooMailWebService/0.8.105.279950 References: Date: Fri, 24 Sep 2010 14:34:32 -0700 (PDT) From: Behcet Sarikaya To: Kerry Lynn , core In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [core] Proposed Energy Management (eman) WG 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: Fri, 24 Sep 2010 21:34:09 -0000 X-List-Received-Date: Fri, 24 Sep 2010 21:34:09 -0000 Eman is now a new WG: http://www.ietf.org/mail-archive/web/eman/current/msg00053.html ----- Original Message ---- > From: Kerry Lynn > To: core > Sent: Fri, September 24, 2010 7:51:36 AM > Subject: [core] Proposed Energy Management (eman) WG > > This was news to me: > http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07907.html > > Subscribe to the discussion here: > https://www.ietf.org/mailman/listinfo/eman > > -K- > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From zach@sensinode.com Mon Sep 27 04:13: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 54D663A6C55 for ; Mon, 27 Sep 2010 04:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=-1.871, BAYES_20=-0.74, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL5cZ5-QNicO for ; Mon, 27 Sep 2010 04:13:10 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 18E743A6C73 for ; Mon, 27 Sep 2010 04:13:09 -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 o8RBDibI023248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Sep 2010 14:13:45 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-115-188664501; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 27 Sep 2010 14:13:45 +0300 References: <20100927110348.BD4813A6CA9@core3.amsl.com> To: core Message-Id: <4CFA2138-0CFD-4035-BE01-9C18EF770709@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-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, 27 Sep 2010 11:13:12 -0000 --Apple-Mail-115-188664501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii http://www.ietf.org/id/draft-ietf-core-coap-02.txt I submitted a new version of CoAP so that we can discuss the work needed = to complete the security section (Ticket #22) during the interim meeting = this week. Just to make security guys nervous, I wrote some placeholder = text ;-) This definitely needs to be improved, but at least it is a = start. I would like to reserve 15 minutes in the meeting to discuss the = security section.=20 As agreed in the last meeting the resource discovery section was = removed, and I will soon be submitting a separate CoRE Link Format = draft. The link format draft will include minor changes compared to -01, = e.g. the registration of /.well-known/core and quotes around string = values.=20 This version of the draft otherwise closes all the tickets we had = planned for the -02 release. In practice coap-01 implementations should = still be compatible with coap-02 as there were no header changes. Do = note that the Uri-Scheme option was removed and Uri-Authority processing = has been clarified. Here is a summary of the main changes: Changes from ietf-01 to ietf-02: o Sending an error on a critical option clarified (#18). o Clarification on behavior of PUT and idempotent operations (#19). o Use of Uri-Authority clarified along with server processing rules. Uri-Scheme option removed. (#20, #23) o Resource discovery section removed to a separate CoRE Link Format draft (#21) o Initial security section outline added. Regards, Zach=20 Begin forwarded message: > From: IETF I-D Submission Tool > Date: September 27, 2010 2:03:48 PM GMT+03:00 > To: zach@sensinode.com > Cc: brian@skyfoundry.com,d.sturek@att.net > Subject: New Version Notification for draft-ietf-core-coap-02=20 >=20 >=20 > A new version of I-D, draft-ietf-core-coap-02.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-core-coap > Revision: 02 > Title: Constrained Application Protocol (CoAP) > Creation_date: 2010-09-27 > WG ID: core > Number_of_pages: 35 >=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-115-188664501 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyNzExMTM0 NlowIwYJKoZIhvcNAQkEMRYEFFxTQ0ygoaIOSCQCV+NYdDao+4lSMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAHHoMXR0XEPoPlkc0P4g7KPXxeXp7fRLPzo4h3iouDHJfz9O5okuI8oB O+DZYRNCEi8fxTw+RLcZ/Bic4rrpP7o6kvSd4pXmAueYHMlnYKL1PW3vWNMTUseqxp6paZQTohmQ HRy3yzNHAaOqatqvWVZNc4F9V6wkiUVCY1g9BqfmKMVfsrh4sbKcGDyL21Z9WCOe7Ub3lFQl2er/ A8LzAVHGEQjrp6QVRKCFPlcCMUZD7QKhjbuHnDQXdOM9eUtVGBtDxma9Rg0GRdTiSbF3Bz7KEaYR +rqTk5tpd+5dQJcadrZwpNwaN69pC952Xh8PB9toE9WSt3S9zd5Mynu5lXsAAAAAAAA= --Apple-Mail-115-188664501-- From root@core3.amsl.com Mon Sep 27 04: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 B586F3A6CF3; Mon, 27 Sep 2010 04:15:04 -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: <20100927111504.B586F3A6CF3@core3.amsl.com> Date: Mon, 27 Sep 2010 04:15:04 -0700 (PDT) Cc: core@ietf.org Subject: [core] I-D Action:draft-ietf-core-coap-02.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, 27 Sep 2010 11:15:05 -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-02.txt Pages : 35 Date : 2010-09-27 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-27040348.I-D@ietf.org> --NextPart-- From e.gutierrezmlot@sssup.it Tue Sep 28 02:02: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 26F193A6D5C for ; Tue, 28 Sep 2010 02:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFcN79HPtoxh for ; Tue, 28 Sep 2010 02:02:13 -0700 (PDT) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by core3.amsl.com (Postfix) with ESMTP id CEEAF3A6C94 for ; Tue, 28 Sep 2010 02:02:09 -0700 (PDT) Received: from [10.30.3.232] (HELO localhost) by sssup.it (CommuniGate Pro SMTP 5.3.2) with ESMTPS id 63497897 for core@ietf.org; Tue, 28 Sep 2010 11:02:48 +0200 Date: Tue, 28 Sep 2010 11:02:48 +0200 (CEST) From: Esteban Damian Gutierrez Mlot To: core@ietf.org Message-ID: <31312889.121285664567378.JavaMail.esguti@esguti-sssup> In-Reply-To: <27874776.101285664491524.JavaMail.esguti@esguti-sssup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [core] clarify resource discovery for 6LoWPAN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Sep 2010 09:02:14 -0000 In order to apply a Service Oriented Architecture and made resources available for users, I would implement a discovery mechanism. I think this is a point is not clear for 6LoWPAN. Should I use SSLP (draft-daniel-6lowpan-sslp-02.txt) or I should use CoAP (draft-ietf-core-coap-01)? Could somebody clarify this point or give some advices? Regards, Esteban From zach@sensinode.com Tue Sep 28 02:05: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 F228F3A6D37 for ; Tue, 28 Sep 2010 02:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 DtJ3fgisCP-w for ; Tue, 28 Sep 2010 02:05:41 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B6DCF3A6A24 for ; Tue, 28 Sep 2010 02:05:40 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o8S96Hco016188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Sep 2010 12:06:18 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-202-267417792; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 28 Sep 2010 12:06:19 +0300 References: <20100928085643.27A7C3A6C7A@core3.amsl.com> To: core Message-Id: <12D57F29-D6CC-496B-B37B-519BECFD16F3@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-link-format-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, 28 Sep 2010 09:05:48 -0000 --Apple-Mail-202-267417792 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii http://www.ietf.org/id/draft-shelby-core-link-format-00.txt This new draft specifies the link format and well-known URI interface = for use in CoRE resource discovery separately from the base CoAP draft = as per ticket #21. In the process of spinning this into a separate = draft, several improvements were made (thanks Mark and Carsten!). =20 o The link format ABNF from draft-nottingham-http-link-header was = completely re-used, avoiding the need to redefine it. o Quoted strings were added for string attributes o Explanation of the target/context URI was added along with use of the = relation attribute in-line with draft-nottingham-http-link-header o References to DNS-SD and mDNS were completely removed as this was = found to be misleading in Maastricht o Well-known URI changed to /.well-known/core to make registration = possible (/r was too short) o Filtering was changed to a MAY o Proper IANA section was created I plan on making one slide capturing these changes for tomorrow's = interim WG meeting, a 10 minute slot should be enough. Zach=20 Begin forwarded message: > From: IETF I-D Submission Tool > Date: September 28, 2010 11:56:43 AM GMT+03:00 > To: zach@sensinode.com > Subject: New Version Notification for draft-shelby-core-link-format-00=20= >=20 >=20 > A new version of I-D, draft-shelby-core-link-format-00.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-link-format > Revision: 00 > Title: CoRE Link Format > Creation_date: 2010-09-28 > WG ID: Independent Submission > Number_of_pages: 10 >=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-202-267417792 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyODA5MDYx OVowIwYJKoZIhvcNAQkEMRYEFCBakXPeGSNcK8kgO28P6FIrt+btMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFcS5+pi5lV/Eem3/Yxn073Fo5OUW1Q3JTCCVKWQRndIz6Tn2xUs7oXv L1QvAhVWF1xxMcNee/qzoOk0/t7pBdKcIulUtlFHI9Tk0HtQCxE7LCLKvdUD5PcaKEP7AFSbX9x8 z+z8rVwusDhqIwr9pcxIDq94bF3JpS0hI+xlXiaWZiAHeFbqPCvfbLf1E/kLH034EwH9sAEhS+RJ RBsDaj9zdcpIaaNRDrQBQkZY7MmbegOSkP4ljLLw8c+pZMhuvPXiDl53+tmys1N4e+AMYzl78v/a HEO+YXrh+mF4ZGnhlw84ptuLl3D/cOAWdzZt/I4QfSLwSx7NW/RZww5FDdoAAAAAAAA= --Apple-Mail-202-267417792-- From zach@sensinode.com Tue Sep 28 02:13:03 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129ED3A6D8A for ; Tue, 28 Sep 2010 02:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 0MT5B3Y9kXnW for ; Tue, 28 Sep 2010 02:12: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 8D7403A6D90 for ; Tue, 28 Sep 2010 02:10:48 -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 o8S9At16016773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Sep 2010 12:10:56 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-203-267695954; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <31312889.121285664567378.JavaMail.esguti@esguti-sssup> Date: Tue, 28 Sep 2010 12:10:57 +0300 Message-Id: References: <31312889.121285664567378.JavaMail.esguti@esguti-sssup> To: Esteban Damian Gutierrez Mlot X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] clarify resource discovery for 6LoWPAN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Sep 2010 09:13:04 -0000 --Apple-Mail-203-267695954 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Estaban, Please see the draft just posted (draft-shelby-core-coap-link-format). = This draft does make it possible to discover the list of resources that = a CoAP server provides by doing a GET on /.well-known/core. This of = course assumes that you are using CoAP and know that a CoAP server = exists in your network - if you don't then some sort of service = discovery might be needed first (SLP, DNS-SD etc.). The combination of = these depends a lot on your application. Regards, Zach On Sep 28, 2010, at 12:02 PM, Esteban Damian Gutierrez Mlot wrote: > In order to apply a Service Oriented Architecture and made resources = available for users, I would implement a discovery mechanism. I think = this is a point is not clear for 6LoWPAN. Should I use SSLP = (draft-daniel-6lowpan-sslp-02.txt) or I should use CoAP = (draft-ietf-core-coap-01)? >=20 > Could somebody clarify this point or give some advices? >=20 > Regards, > Esteban > _______________________________________________ > 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-203-267695954 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyODA5MTA1 N1owIwYJKoZIhvcNAQkEMRYEFAk8/V1i74yE0g5h0Di9Jb8XCcJBMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAJoJPvWl7Vbdr3eky3TMB3BbQ/zNfrSQpmC34ru40wASlIwozuAudHjn 1HoJLQ8Okenvqd+h4jy3BXHnST2fFNRvlDCbQgXTacdotWyhu3UDS/pt3UaqP2zoKCfGCLmw/rdp 4KmMJlbrWCUc+QJMHvpbmfo+4wSKfgejhrkRaB6Zu+iIKgFogtDl7F3E0eA1+DPtmz/o6Y/WbPj8 E2+vpAtuSYAdthgJZkJR6FZw7s+WmQ8iCGUwVM+NEbqI+tFyfFnt0y678sa7qfJAlrOTnsLIxsDI y8un4p+v4ngIl8Q0XXeWBsertNWLIF7uwhEaq75S//kvR+ZKl7TCp5QkVqsAAAAAAAA= --Apple-Mail-203-267695954-- From kerlyn2001@gmail.com Tue Sep 28 19:27: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 20EC53A6BB5 for ; Tue, 28 Sep 2010 19:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 8BkN1jau5PnV for ; Tue, 28 Sep 2010 19:27:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 69D223A6A21 for ; Tue, 28 Sep 2010 19:27:14 -0700 (PDT) Received: by bwz9 with SMTP id 9so310316bwz.31 for ; Tue, 28 Sep 2010 19:27:56 -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=JG4dMt/yNPGcw2ZFOrLNhU8vJ8y/+mlqEGCWcsMJOjY=; b=heUGnOG8qsPoTSK73T825pP/v1teL9ShhmmlYTorjT+zpkpjPmrF+HS19uMFn+IXh5 ETJ4KvC1boPoEzUSERYecGL/0UBqicxgxpOonfYBkElHqNiNBMr0efKVcNtb2J4rzSDb DMK5mC4AM8tK0IGPENDFzVQ+brSdD12fW7z4I= 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=T+WmuXxTp9YljZQbP3mGx459yN42wrrwUWcil73OYLZTZ+n2KyjL8yZBAARpNq1HeE DUZfQdM5nAb9WnJhOj/TiBCz+/dRFNl/qmhTeVAwkXiIS5CHw0Cd+yngIfR/PWD2e2fj jc7R9vUbLmOGvZGlEfr9bN/YxJBrVHF+OAs9A= MIME-Version: 1.0 Received: by 10.204.112.129 with SMTP id w1mr571862bkp.204.1285727276219; Tue, 28 Sep 2010 19:27:56 -0700 (PDT) Received: by 10.204.104.14 with HTTP; Tue, 28 Sep 2010 19:27:56 -0700 (PDT) In-Reply-To: <12D57F29-D6CC-496B-B37B-519BECFD16F3@sensinode.com> References: <20100928085643.27A7C3A6C7A@core3.amsl.com> <12D57F29-D6CC-496B-B37B-519BECFD16F3@sensinode.com> Date: Tue, 28 Sep 2010 22:27:56 -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] Fwd: New Version Notification for draft-shelby-core-link-format-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, 29 Sep 2010 02:27:16 -0000 Hi Zach, I am wondering if this is the way to discover which port the service is bound to? (I'm thinking here of the dynamic hc ports.) Also, let's FIX the DNS-SD text in -03 rather than deleting it. I hope we are not planning to punt on REQ8, which comes to us from the charter. We clearly need a scalable service discovery mechanism for building automation. Regards, -K- On Tue, Sep 28, 2010 at 5:06 AM, Zach Shelby wrote: > http://www.ietf.org/id/draft-shelby-core-link-format-00.txt > > This new draft specifies the link format and well-known URI interface for= use in CoRE resource discovery separately from the base CoAP draft as per = ticket #21. In the process of spinning this into a separate draft, several = improvements were made (thanks Mark and Carsten!). > > o The link format ABNF from draft-nottingham-http-link-header was complet= ely re-used, avoiding the need to redefine it. > o Quoted strings were added for string attributes > o Explanation of the target/context URI was added along with use of the r= elation attribute in-line with draft-nottingham-http-link-header > o References to DNS-SD and mDNS were completely removed as this was found= to be misleading in Maastricht > o Well-known URI changed to /.well-known/core to make registration possib= le (/r was too short) > o Filtering was changed to a MAY > o Proper IANA section was created > > I plan on making one slide capturing these changes for tomorrow's interim= WG meeting, a 10 minute slot should be enough. > > Zach > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: September 28, 2010 11:56:43 AM GMT+03:00 >> To: zach@sensinode.com >> Subject: New Version Notification for draft-shelby-core-link-format-00 >> >> >> A new version of I-D, draft-shelby-core-link-format-00.txt has been succ= essfully submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0draft-shelby-core-link-format >> Revision: =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CoRE Link Format >> Creation_date: =A0 =A0 =A0 =A0 2010-09-28 >> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> This document defines a link format for use by constrained CoAP web >> servers to describe URIs of resources offered along with other >> attributes. =A0Based on the HTTP Link Header format, the CoRE link >> format is carried as a payload and is assigned an Internet media >> type. =A0A well-known URI is defined as a default entry-point for >> requesting the list of links to resources hosted by a server. >> >> >> >> The IETF Secretariat. >> >> > > -- > 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 cabo@tzi.org Wed Sep 29 06:33: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 167E33A6AED for ; Wed, 29 Sep 2010 06:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.078 X-Spam-Level: X-Spam-Status: No, score=-107.078 tagged_above=-999 required=5 tests=[AWL=1.171, 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 yFlKc7pJnIIu for ; Wed, 29 Sep 2010 06:33: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 B10823A6B9C for ; Wed, 29 Sep 2010 06:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o8TDXYGn008442 for ; Wed, 29 Sep 2010 15:33:34 +0200 (CEST) Received: from [192.168.217.101] (p5489AC72.dip.t-dialin.net [84.137.172.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 00C24FE7; Wed, 29 Sep 2010 15:33:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann X-Priority: 3 Date: Wed, 29 Sep 2010 15:33:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: core X-Mailer: Apple Mail (2.1081) Subject: [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: Wed, 29 Sep 2010 13:33:08 -0000 So you don't have to hunt them down, below are the Webex details for the = conference call today. Note that 1500 UTC is 0800 PDT, 1100 EDT, 1700 CEST, 1800 EEST, 2400 = JST/KST, i.e., soon. We have a pretty short agenda this time: -- Document status -- Splitting draft-ietf-core-coap-02 and draft-shelby-link-format-00 -- (Any other comments on draft-bormann-core-coap-block-00, draft-hartke-coap-observe-02) -- Planning ahead of Beijing -- Security Bootstrapping -- Further Webex meetings (2010-10-27) -- I-D deadline at 2010-10-18 (initial) and 2010-10-25 (update) There is only one slideset, for coap-02/link-format-00, currently at: http://6lowapp.net/2010-09-29/ (I know this still isn't the right place...) Please note that we do intend to record this meeting. Gruesse, Carsten > Hello ,=20 >=20 > IETF Secretariat invites you to attend this online meeting.=20 >=20 > Topic: CORE WG=20 > Date: Wednesday, September 29, 2010=20 > Time: 3:00 pm, (Reykjavik, GMT)=20 > Meeting Number: 963 078 535=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=3D147542532&UID=3D118579186= 2&RT=3DMiMyMA%3D%3D=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=3D147542532&UID=3D118579186= 2&ORT=3DMiMyMA%3D%3D=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= =3D147542532&tollFree=3D0=20 >=20 > Access code:963 078 535=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=3D147542532&UID=3D118579186= 2&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DvjLz1JtYfKkmL2Gpzw5H1lr7GVJUx0nv3CS= fu33a3iU=3D&RT=3DMiMyMA%3D%3D=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 fluffy@cisco.com Wed Sep 29 07:43:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D2B3A6CF1 for ; Wed, 29 Sep 2010 07:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 6hW8pSYyApYA for ; Wed, 29 Sep 2010 07:43:14 -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 55F0F3A6CEB for ; Wed, 29 Sep 2010 07:43:14 -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: AvsEAI7tokyrR7Ht/2dsb2JhbACiHnGqMZxphUQEhFCFaoJ/ X-IronPort-AV: E=Sophos;i="4.57,253,1283731200"; d="scan'208";a="596571420" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2010 14:43:58 +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 o8TEhvpt015613; Wed, 29 Sep 2010 14:43:57 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Sep 2010 08:43:57 -0600 Message-Id: <4F4FC690-504D-483F-BACE-EE9BABA456D6@cisco.com> To: core@ietf.org, Zach Shelby Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Filtering in draft-shelby-core-link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 14:43:16 -0000 It seems like you should clear up the behavior of devices that do not = support filtering receives a request with a filter query. For example = what happens when a device that does not do filtering gets=20 GET /.well-known/core?n=3DLightLux I think the answer should be it ignores it and returns exactly the same = things as if it had got=20 GET /.well-known/core Should also deal with what happens with a query with "*" when the device = does not support it. This seems a bit harder to specify - I'd almost be = tempted to say supporting * is required if you do filtering I'm a little concerned with the=20 " If no Content-type code attribute is present then text/ plain is assumed. " I think it might be better to say that nothing about the type can be = assumed if the attribute is not present.=20 Cullen From kerlyn2001@gmail.com Wed Sep 29 09: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 2C54E3A6EF0 for ; Wed, 29 Sep 2010 09:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 6QQeqTwOSeHO for ; Wed, 29 Sep 2010 09:09:12 -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 1692C3A6DF4 for ; Wed, 29 Sep 2010 09:09:11 -0700 (PDT) Received: by bwz9 with SMTP id 9so847987bwz.31 for ; Wed, 29 Sep 2010 09:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=qnLW8R7n5Nsm3GiTbKWDkdhX77Lj3okusuEPYAzEhe4=; b=bVy6Yl4i6jmRJAPRcNeWjf2HGH35Xw5JWL88e/lHpeUfjlwASroQN4ERKXTInVtMPZ 5Tgm0JZNSbb6RtWK+/DjJFqKdkB8Q81lf3qWMpyJ/bqw6iUUTHH9RCVruzuON5qFnDxc pretKpkHQ9Biy+xTsHBzGOY9MIk+LVkkYRJ4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iLjRydGvHdvdDa6tNp6/FlOOsJstaG0HXpwC1zZG/PfHjsPuuYuhOQqBwZEw6z4f3B sn34OUMkziOKXqTonP4J9kktdI/EHMsxFzo6jyAygzpwkNdFhHOxTcgChHr3TTFdkJ+m y4nmn+HggYrZW8r57ftcZda+n0Vciaic587WE= MIME-Version: 1.0 Received: by 10.204.141.16 with SMTP id k16mr1376257bku.177.1285776595203; Wed, 29 Sep 2010 09:09:55 -0700 (PDT) Received: by 10.204.104.14 with HTTP; Wed, 29 Sep 2010 09:09:55 -0700 (PDT) Date: Wed, 29 Sep 2010 12:09:55 -0400 Message-ID: From: Kerry Lynn To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Link to multicast http I-D X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 16:09:13 -0000 http://tools.ietf.org/html/draft-goland-http-udp-01 -K- From zach@sensinode.com Wed Sep 29 09:15: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 344AB3A6D43 for ; Wed, 29 Sep 2010 09:15:01 -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 igXq8rBZ7Dz7 for ; Wed, 29 Sep 2010 09:14:59 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8C5ED3A6DF1 for ; Wed, 29 Sep 2010 09:14:57 -0700 (PDT) Received: from [192.168.0.82] (82-128-196-163.bb.dnainternet.fi [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o8TGFY2X024467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Sep 2010 19:15:34 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-336-379575380; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4F4FC690-504D-483F-BACE-EE9BABA456D6@cisco.com> Date: Wed, 29 Sep 2010 19:15:36 +0300 Message-Id: <118E6191-0FA0-4D2D-A003-4CA2AD843C76@sensinode.com> References: <4F4FC690-504D-483F-BACE-EE9BABA456D6@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Filtering in draft-shelby-core-link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 16:15:01 -0000 --Apple-Mail-336-379575380 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Cullen, These all sound reasonable to me, I will make a ticket for = link-format-02 if there are no objections. Zach On Sep 29, 2010, at 5:43 PM, Cullen Jennings wrote: >=20 > It seems like you should clear up the behavior of devices that do not = support filtering receives a request with a filter query. For example = what happens when a device that does not do filtering gets=20 >=20 > GET /.well-known/core?n=3DLightLux >=20 > I think the answer should be it ignores it and returns exactly the = same things as if it had got=20 >=20 > GET /.well-known/core >=20 > Should also deal with what happens with a query with "*" when the = device does not support it. This seems a bit harder to specify - I'd = almost be tempted to say supporting * is required if you do filtering >=20 >=20 > I'm a little concerned with the=20 > " If no Content-type code attribute is present then text/ > plain is assumed. " >=20 > I think it might be better to say that nothing about the type can be = assumed if the attribute is not present.=20 >=20 >=20 >=20 > Cullen >=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-336-379575380 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyOTE2MTUz N1owIwYJKoZIhvcNAQkEMRYEFM1aahEZv9ZF8MRujRmRhfgLV5QfMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAC91AXAfOx2KHSLCxsAM6D132p4VKiKaNnFiDNyaHGfleqyvhDpkIoPV T0fRaBo8IDtMdYB450l09DWpqdi98Vp0sq3KQJsbM3OQHaygOz4aY92xRh6WfYXvklyFo07mZJJ2 UxgESorgkMAkxIz6CeaSxgvw4d0WVTH6/OQ4SZ+QsvRlnWZeciKXXTFpPM9WN9DcVroug0+VuxbH d0pyD2jC10LYZ/0vDigsieosr3uVslQuEahr6yaib97+U6aEjWAtV7rL8eGW392pMK6VPaCIs0al uYAlkz4HcLDuT5GPME46hCGOrjAo0o8XLdbO6npVKAlujQwEKQ1sDW1dnHoAAAAAAAA= --Apple-Mail-336-379575380-- From pab@peoplepowerco.com Wed Sep 29 09:17: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 EAD873A6DD5 for ; Wed, 29 Sep 2010 09:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=0.435, 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 NYwzW9b+a-Qh for ; Wed, 29 Sep 2010 09:17:30 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 0A71E3A6CF2 for ; Wed, 29 Sep 2010 09:17:21 -0700 (PDT) Received: by pxi6 with SMTP id 6so311907pxi.31 for ; Wed, 29 Sep 2010 09:18:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.39.16 with SMTP id m16mr2128522wam.221.1285777084693; Wed, 29 Sep 2010 09:18:04 -0700 (PDT) Received: by 10.220.179.11 with HTTP; Wed, 29 Sep 2010 09:18:04 -0700 (PDT) In-Reply-To: <12D57F29-D6CC-496B-B37B-519BECFD16F3@sensinode.com> References: <20100928085643.27A7C3A6C7A@core3.amsl.com> <12D57F29-D6CC-496B-B37B-519BECFD16F3@sensinode.com> Date: Wed, 29 Sep 2010 11:18:04 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-link-format-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, 29 Sep 2010 16:17:33 -0000 The link extensions just prior to section 2.1 need to add required quotations around URI and URI-Reference, as are present with the anchor link param in draft-nottingham-http-link-header. Otherwise they're not conformant to that document's syntax for link-extensions. link-extension =3D ( "d" "=3D" <"> URI <"> ) link-extension =3D ( "sh" "=3D" <"> URI-Reference <"> ) link-extension =3D ( "n" "=3D" quoted-string ) link-extension =3D ( "ct" "=3D" integer ) link-extension =3D ( "id" "=3D" quoted-string ) Also need to add: integer =3D 1*DIGIT Unfortunately this makes it impossible to syntactically distinguish URIs from strings in the "n" and "id" extensions. Dunno if that will be a problem for anybody. Peter On Tue, Sep 28, 2010 at 4:06 AM, Zach Shelby wrote: > http://www.ietf.org/id/draft-shelby-core-link-format-00.txt > > This new draft specifies the link format and well-known URI interface for= use in CoRE resource discovery separately from the base CoAP draft as per = ticket #21. In the process of spinning this into a separate draft, several = improvements were made (thanks Mark and Carsten!). > > o The link format ABNF from draft-nottingham-http-link-header was complet= ely re-used, avoiding the need to redefine it. > o Quoted strings were added for string attributes > o Explanation of the target/context URI was added along with use of the r= elation attribute in-line with draft-nottingham-http-link-header > o References to DNS-SD and mDNS were completely removed as this was found= to be misleading in Maastricht > o Well-known URI changed to /.well-known/core to make registration possib= le (/r was too short) > o Filtering was changed to a MAY > o Proper IANA section was created > > I plan on making one slide capturing these changes for tomorrow's interim= WG meeting, a 10 minute slot should be enough. > > Zach > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: September 28, 2010 11:56:43 AM GMT+03:00 >> To: zach@sensinode.com >> Subject: New Version Notification for draft-shelby-core-link-format-00 >> >> >> A new version of I-D, draft-shelby-core-link-format-00.txt has been succ= essfully submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0draft-shelby-core-link-format >> Revision: =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CoRE Link Format >> Creation_date: =A0 =A0 =A0 =A0 2010-09-28 >> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> This document defines a link format for use by constrained CoAP web >> servers to describe URIs of resources offered along with other >> attributes. =A0Based on the HTTP Link Header format, the CoRE link >> format is carried as a payload and is assigned an Internet media >> type. =A0A well-known URI is defined as a default entry-point for >> requesting the list of links to resources hosted by a server. >> >> >> >> The IETF Secretariat. >> >> > > -- > 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 L.Wood@surrey.ac.uk Wed Sep 29 09:19: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 4FABE3A6CF2 for ; Wed, 29 Sep 2010 09:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 b2t+lL5WYQxf for ; Wed, 29 Sep 2010 09:19:04 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id E4A153A6EFD for ; Wed, 29 Sep 2010 09:18:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-3.tower-82.messagelabs.com!1285777130!34841539!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 19158 invoked from network); 29 Sep 2010 16:18:50 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-3.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 29 Sep 2010 16:18:50 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 29 Sep 2010 17:18:50 +0100 From: To: , Date: Wed, 29 Sep 2010 17:18:50 +0100 Thread-Topic: [core] Link to multicast http I-D Thread-Index: Actf8M0ou7cEcvE5SvOvJ9IwP6cAYAAAFcsw Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Link to multicast http I-D X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 16:19:35 -0000 The Goland draft mentioned below is a ten-year-old proposal. Rather more useful and general than trying to specify http over UDP is brea= king http from TCP as a separate layer, and then putting it over a variety = of reliable transports, be they UDP-based, SCTP, TCP or otherwise. Some notes on this and various pieces of work in this area are at: http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-draft= s/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-turning-http-into-a-standal= one-layer-ietf-75-tsvarea-slides.pdf Turning HTTP into a standalone layer: decoupling HTTP from TCP, talk given = to the TSVAREA meeting, IETF 75, Stockholm, 27 July 2009. and on http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn delay-tolerant networking (DTN) provided a motivation for separating HTTP f= rom TCP for environments where TCP fails, but the overall need to treat HTT= P as a separate layer remains; just ignore the DTN-forwarding-specific Cont= ent- headers. (meanwhile, Joe Touch would be interested in getting BGP off of only TCP, a= nd onto e.g. SCTP... again, breaking coupling between layers in implementat= ions with greater use of layering. HTTP really is a layer in its own right,= and should be able to run over any reliable transport.) -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ker= ry Lynn Sent: 29 September 2010 17:10 To: core Subject: [core] Link to multicast http I-D http://tools.ietf.org/html/draft-goland-http-udp-01 -K- From kerlyn2001@gmail.com Wed Sep 29 09:23: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 960263A6C36 for ; Wed, 29 Sep 2010 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 oux01O95HpHx for ; Wed, 29 Sep 2010 09:23: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 23F5E3A6BB0 for ; Wed, 29 Sep 2010 09:23:14 -0700 (PDT) Received: by bwz9 with SMTP id 9so865138bwz.31 for ; Wed, 29 Sep 2010 09:23:58 -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=8xT1rFxdaAUdpWGzaxI95T7lzC1Xp2otlYkunzlwq+Y=; b=fqO7w/7dyhKSVm1nHjLIlcvBxDEIlsiiIpAvt1xT1oAK+Pu67/D6KVyD7hssVZ5JVR hQ1nSnGPxqZK2tnpe37HyHPL4r9yaV5io0qSEUoZd5JiNjvxCfpEmZh+HCGnd2gSM8vz WSSfbOklxCzTjGxa55HQ20xkOjdTOSXpc32gY= 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=cWJqg+/AAUW1Qg+HdodewHrX3FlYgr7wKMyn5VQ0uIZSq3fB9ZS0sg1iIoDOHDDSdJ uEKENpVcSurtepAI2QOllvubmZEkZRjRs49d9x0zkUQLKVaI4hZrF95KjmBPnhWT8BEP Vhjzmu1BTpp3wqZP0U1RZqlL6bTnXA6DuwdO0= MIME-Version: 1.0 Received: by 10.204.63.211 with SMTP id c19mr1440940bki.133.1285777437685; Wed, 29 Sep 2010 09:23:57 -0700 (PDT) Received: by 10.204.104.14 with HTTP; Wed, 29 Sep 2010 09:23:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Sep 2010 12:23:57 -0400 Message-ID: From: Kerry Lynn To: L.Wood@surrey.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Link to multicast http I-D X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 16:23:16 -0000 Do any of this work specifically address the topic of multicast resource manipulation? -K- On Wed, Sep 29, 2010 at 12:18 PM, wrote: > The Goland draft mentioned below is a ten-year-old proposal. > > Rather more useful and general than trying to specify http over UDP is br= eaking http from TCP as a separate layer, and then putting it over a variet= y of reliable transports, be they UDP-based, SCTP, TCP or otherwise. > > Some notes on this and various pieces of work in this area are at: > http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-dra= fts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-turning-http-into-a-stand= alone-layer-ietf-75-tsvarea-slides.pdf > Turning HTTP into a standalone layer: decoupling HTTP from TCP, talk give= n to the TSVAREA meeting, IETF 75, Stockholm, 27 July 2009. > > and on > http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn > > delay-tolerant networking (DTN) provided a motivation for separating HTTP= from TCP for environments where TCP fails, but the overall need to treat H= TTP as a separate layer remains; just ignore the DTN-forwarding-specific Co= ntent- headers. > > (meanwhile, Joe Touch would be interested in getting BGP off of only TCP,= and onto e.g. SCTP... again, breaking coupling between layers in implement= ations with greater use of layering. HTTP really is a layer in its own righ= t, and should be able to run over any reliable transport.) > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of K= erry Lynn > Sent: 29 September 2010 17:10 > To: core > Subject: [core] Link to multicast http I-D > > http://tools.ietf.org/html/draft-goland-http-udp-01 > > -K- > From L.Wood@surrey.ac.uk Wed Sep 29 09:34: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 EB9763A6BB0 for ; Wed, 29 Sep 2010 09:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 EZtzN7dReJ3J for ; Wed, 29 Sep 2010 09:34:30 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id E08123A6D24 for ; Wed, 29 Sep 2010 09:34:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-82.messagelabs.com!1285778111!22013892!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 28405 invoked from network); 29 Sep 2010 16:35:11 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-11.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 29 Sep 2010 16:35:11 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Wed, 29 Sep 2010 17:35:10 +0100 From: To: Date: Wed, 29 Sep 2010 17:35:11 +0100 Thread-Topic: [core] Link to multicast http I-D Thread-Index: Actf8rjTIAN00MXqQv6wdrPuMOidMwAAKmjw Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core@ietf.org Subject: Re: [core] Link to multicast http I-D X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 16:34:39 -0000 "multicast resource manipulation" is not a topic per se. HTTP-DTN was proposed as running over Saratoga (UDP + necessary reliability= for large files and resend) and Saratoga supports multicast. http://tools.ietf.org/html/draft-wood-tsvwg-saratoga You might also look into DDS, which is publish/subscribe CORBA middleware t= hat does resource management and claims support of multicast as one of its = transports. http://www.opendds.org/transport.html http://en.wikipedia.org/wiki/Data_Distribution_Service -----Original Message----- From: Kerry Lynn [mailto:kerlyn2001@gmail.com]=20 Sent: 29 September 2010 17:24 To: Wood L Dr (Electronic Eng) Cc: core@ietf.org Subject: Re: [core] Link to multicast http I-D Importance: High Do any of this work specifically address the topic of multicast resource ma= nipulation? -K- On Wed, Sep 29, 2010 at 12:18 PM, wrote: > The Goland draft mentioned below is a ten-year-old proposal. > > Rather more useful and general than trying to specify http over UDP is br= eaking http from TCP as a separate layer, and then putting it over a variet= y of reliable transports, be they UDP-based, SCTP, TCP or otherwise. > > Some notes on this and various pieces of work in this area are at: > http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet- > drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-turning-http-into > -a-standalone-layer-ietf-75-tsvarea-slides.pdf > Turning HTTP into a standalone layer: decoupling HTTP from TCP, talk give= n to the TSVAREA meeting, IETF 75, Stockholm, 27 July 2009. > > and on > http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn > > delay-tolerant networking (DTN) provided a motivation for separating HTTP= from TCP for environments where TCP fails, but the overall need to treat H= TTP as a separate layer remains; just ignore the DTN-forwarding-specific Co= ntent- headers. > > (meanwhile, Joe Touch would be interested in getting BGP off of only=20 > TCP, and onto e.g. SCTP... again, breaking coupling between layers in=20 > implementations with greater use of layering. HTTP really is a layer=20 > in its own right, and should be able to run over any reliable=20 > transport.) > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf=20 > Of Kerry Lynn > Sent: 29 September 2010 17:10 > To: core > Subject: [core] Link to multicast http I-D > > http://tools.ietf.org/html/draft-goland-http-udp-01 > > -K- > From cabo@tzi.org Wed Sep 29 09:35: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 8AFE23A6C3F for ; Wed, 29 Sep 2010 09:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.105 X-Spam-Level: X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=0.144, 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 E1TACJRKawmJ for ; Wed, 29 Sep 2010 09:35: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 0EB943A6C36 for ; Wed, 29 Sep 2010 09:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o8TGZe4Z002748; Wed, 29 Sep 2010 18:35:40 +0200 (CEST) Received: from [192.168.217.101] (p5489AC72.dip.t-dialin.net [84.137.172.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DDBB8C3; Wed, 29 Sep 2010 18:35:39 +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, 29 Sep 2010 18:35:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96499F34-490E-46B4-81B4-EA799F8FD78B@tzi.org> References: To: X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Link to multicast http I-D X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 16:35:17 -0000 On Sep 29, 2010, at 18:18, wrote: > The Goland draft mentioned below is a ten-year-old proposal. I think we can all agree that we don't want to dig up this proposal as = is. We thought it might be useful to look at this because, in the CoRE webex = call, we just had a little discussion what it means to do a REST = operation on a multicast (or, maybe more generally speaking: group) = authority. If you have any input on how to address the obvious (and not = so obvious) problems, that would be helpful. Gruesse, Carsten From zach@sensinode.com Wed Sep 29 09:52: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 BCBA73A6D35 for ; Wed, 29 Sep 2010 09:52:48 -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 11d6P2gE1kxv for ; Wed, 29 Sep 2010 09:52:47 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 332FF3A6B4C for ; Wed, 29 Sep 2010 09:52:45 -0700 (PDT) Received: from [192.168.0.82] (82-128-196-163.bb.dnainternet.fi [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o8TGrONx025602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Sep 2010 19:53:25 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-339-381845852; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 29 Sep 2010 19:53:27 +0300 Message-Id: <95FE86D4-31BD-44BA-9267-505AAC254E96@sensinode.com> References: To: Kerry Lynn X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Link to multicast http I-D X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 16:52:49 -0000 --Apple-Mail-339-381845852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 29, 2010, at 7:09 PM, Kerry Lynn wrote: > http://tools.ietf.org/html/draft-goland-http-udp-01 I found this to have some interesting ideas, although obviously not = applicable as-is.=20 In particular Section 7 describes the use of the an mx header for = requesting a random delay of 0 to mx before sending a response to avoid = overflow. The draft also seems to assume that a multicast request is not = made to a distributed authority, but to all authorities that happen to = be listening to the IP address and port. "When used with a multicast UDP HTTP request the "*" request-URI means = "to everyone who is listening to this IP address and port." Zach >=20 > -K- > _______________________________________________ > 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-339-381845852 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyOTE2NTMy N1owIwYJKoZIhvcNAQkEMRYEFK0QmNWMtzrAHDrilMpmBN463vpkMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAKO+2dBXXCp1dk7QsFX/TZ2sozhTPgM7gX1P5+rEehKtoEn/7Z4y3vN0 ZUjX6Tw8EHcU0DkZJHi8DjYAEl0QDQPDMy3Ko2u03bTjs6g28bjqVaZzCBrzg+HfOWxzvWPNIUki 7Inl8Iq3O1ZhFIfzzqDCSJ+37aOIHCHEwg21HKIA6iWQfgiDEiIRqFn6Yiv+u5LaHEap48VtwQIq q4JIgR4BqxNlCvKMZgm3XTpx4UQtxGjS+MG6ghAeEKUl/lfXxJiW/dw3B533WQy3WfDb5uNgLgkF FwdBtxhbQlfOm8vATvNorlRVZCD6pZ0pk2gR26emIVroSxOZBixFIUUkjUAAAAAAAAA= --Apple-Mail-339-381845852-- From pab@peoplepowerco.com Wed Sep 29 10:13: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 4EF6D3A6D43 for ; Wed, 29 Sep 2010 10:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywbqL0K1r+m4 for ; Wed, 29 Sep 2010 10:13:20 -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 60C843A6B69 for ; Wed, 29 Sep 2010 10:13:18 -0700 (PDT) Received: by fxm6 with SMTP id 6so768661fxm.31 for ; Wed, 29 Sep 2010 10:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.212.16 with SMTP id o16mr1075880muq.38.1285780441077; Wed, 29 Sep 2010 10:14:01 -0700 (PDT) Received: by 10.220.179.11 with HTTP; Wed, 29 Sep 2010 10:14:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Sep 2010 12:14:00 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=0016368482837318a3049169166b Subject: Re: [core] REST, URIs, and constrained devices X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:13:22 -0000 --0016368482837318a3049169166b Content-Type: text/plain; charset=ISO-8859-1 To raise the issue again: my concern is how to think about URIs where the authority resolves to an IP multicast address, while retaining the core REST concepts. A couple months ago, I wrote this: On Mon, Jul 26, 2010 at 10:19 AM, Peter Bigot wrote: > 2) Groups of resources on distributed devices > > A second key feature of REST is that it describes a client-server model > where addressable resources are transferred through a representation of > their state. > > If CoRE wants to extend the concept of URI to denote a distributed resource > which is an aggregation of independently managed state, it must define the > processes by which (a) the state representation in a request is distributed, > and (b) the state representations gathered from responses are combined to > return to the REST client a meaningful representation of the state of the > distributed resource. > > In particular, this is necessary for any access to constrained devices > through an HTTP gateway, as implied by the "HTTP REST based API" requirement > in the CoRE charter. An HTTP client will not accept multiple responses to a > single request. > > Peter > Subsequently, to explain the matter to co-workers, I wrote the following extended example of how I would expect to use CoAP in a REST architecture for home lighting management. There are certainly restrictive assumptions that could be made to make this work, like a client performing an analysis on the authority to determine whether it's a unicast, multicast, (anycast?) address. In my opinion, imposing these restrictive assumptions make it harder for CoAP to be inserted into a complex REST systems (with proxies, intermediate servers, non-CoAP gateways, etc.) and still operate in the way most people will expect. It's this blind interoperability that makes REST so powerful. I really believe multicast has no place in a REST system, but would like to hear details on how the two can be reconciled. Peter REST is an architectural style designed to access and manage distributed hypermedia documents. In the form of HTTP and CoAP, it uses a fixed set of operations on resources. A resource is a consistent mapping from a name (its URI) to a view of server-side state (the resource representation). The operations of HTTP and CoAP include GET to obtain the state of a resource, PUT to idempotently replace a resource state, POST for a non-idempotent creation or change to the resource (may imply a side-effect), DELETE to remove the resource entirely. REST is actually much more than this (and is not CRUD), but that is the relevant part for this discussion. Assume I have a device, like the Insteon LampLink or InlineLinc, that controls a 120V load. This device has an IP network interface, and I want to use CoAP to monitor and control it. To simplify things, assume the device presents a single resource, named "state". This resource indicates whether the device passes ("on") or blocks ("off") flow of electricity to its load, and is represented by the ASCII text "on" or "off". Assume that I am permitted to update the state, and when doing so can cause the device to change whether electricity flows to its load. Let's say I install one of these devices in my living room, and connect it to a lamp on the western end-table. In the DHCP server for my home network, I assign the name "westlr" and an IP address to the device. Now assume I'm away from home, and forgot to turn off the lights before I left. My Android phone has a VPN connection that allows it to connect directly to any host on my internal network, and I have a CoAP browser on my phone (I wish....). The browser allows me to specify a URI, has a box into which I can type a resource representation to be sent as a message body, buttons for the four REST operations, and a window in which the returned state description is displayed. If I I enter "coap://westlr/state" in the URI box and press GET, the result window will contain the string "on" (without quotes), because I forgot to turn off the lights. If I type "off" into the message body window, then press PUT, the lamp should turn off. Pressing "GET" again should put the string "off" in the result window. Now let's say I put a similar device on the lamp on the other side of the sofa, and registered it as "eastlr". I can individually query and command that lamp through the uri "coap://eastlr/state". Now: Building automation folks naturally see this and say "But I want to turn off all the lights simultaneously". They think, "Hey, CoAP is based on UDP, which supports multicast. Why don't I select an IP multicast group address, put it into DNS as "lamps", and have westlr and eastlr join that group. Then I can PUT "off" to "coap://lamps/state" and turn everything off at once." Granted that could work for PUT, probably. But leave the PUT aside. In REST, the syntactic act of requesting a method on a resource is always OK; whether that method has any meaning when applied to a resource is determined by the server that processes the REST transaction. I put "coap://lamps/state" into my CoAP browser and press GET. What shows up in my result window? Under the covers, my droid sends a CoAP GET message to the IP address that "lamps" resolves to. It has no idea that this is a multicast address (it could be forced to examine it, but normally it wouldn't). Fine, assume it does, and it knows it could get responses from zero or more devices, depending on whether the request packet reaches the west lamp, east lamp, both, or neither. Each of those will be a document containing "on" or "off". What's it supposed to display? I suppose I'd want to see something like "westlr: on; eastlr: off". That's not something the browser can figure out on its own. Maybe eastlr is busy doing daily backups, and takes a few extra seconds to reply. How does the browser know when it's received "all" the responses? Really, this describes the fundamental problem. Putting "off" in the message body window and pressing POST is the easy part. Defining what happens with all the other ways you can legally use CoAP or HTTP with this URI "scheme://lamps/state" that happens to have an authority part that resolves to a multicast group---that's the hard part. Recall that neither the client, nor any intermediate servers that happen to observe the transaction as it passes between the client and the origin server(s) have any knowledge about the operation except what can be determined from the REST method, the URI, and the transaction message contents. None of that explains how to aggregate multiple representations into a single resource state. There *is* no single resource state, because the URI does not identify a resource. One way to solve the building automation problem is to say that "coap://lamps/state" is a distinct resource the value of which is the aggregate view of the states of all devices that are members of group "lamps", from the perspective of some authoritative view provided by a single server. That server can, under the covers, perform its updates in whatever way it needs to: iterating through a list sending CoAP messages to each lamp, or multicasting a non-REST "turn off" command. What it can't do, without opening a huge can of mess, is try to use REST over multicast to manipulate a bunch of resources simultaneously. That's not REST, at least as I understand it. --0016368482837318a3049169166b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To raise the issue again: my concern is how to think about URIs where the a= uthority resolves to an IP multicast address, while retaining the core REST= concepts.=A0 A couple months ago, I wrote this:

On Mon, Jul 26, 2010 at 10:19 AM, Peter Bigot <pab@peoplepowerco.com> wrot= e:
2) Groups of resources on distributed devices

A second key feature o= f REST is that it describes a client-server model where addressable resourc= es are transferred through a representation of their state.

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

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

Peter

Subsequently, to explain the matt= er to co-workers, I wrote the following extended example of how I would exp= ect to use CoAP in a REST architecture for home lighting management.=A0 The= re are certainly restrictive assumptions that could be made to make this wo= rk, like a client performing an analysis on the authority to determine whet= her it's a unicast, multicast, (anycast?) address.=A0 In my opinion, im= posing these restrictive assumptions make it harder for CoAP to be inserted= into a complex REST systems (with proxies, intermediate servers, non-CoAP = gateways, etc.) and still operate in the way most people will expect.=A0 It= 's this blind interoperability that makes REST so powerful.=A0 I really= believe multicast has no place in a REST system, but would like to hear de= tails on how the two can be reconciled.

Peter

REST is an architectural st= yle designed to access and manage=20 distributed hypermedia documents.=A0 In the form of HTTP and CoAP, it uses a fixed set of operations on resources.=A0 A resource is a consistent=20 mapping from a name (its URI) to a view of server-side state (the=20 resource representation).=A0 The operations of HTTP and CoAP include GET=20 to obtain the state of a resource, PUT to idempotently replace a=20 resource state, POST for a non-idempotent creation or change to the=20 resource (may imply a side-effect), DELETE to remove the resource=20 entirely.=A0 REST is actually much more than this (and is not CRUD), but=20 that is the relevant part for this discussion.

Assume I have a device, like the Insteon LampLink or InlineLinc,=20 that controls a 120V load.=A0 This device has an IP network interface, and I want to use CoAP to monitor and control it.=A0 To simplify things,=20 assume the device presents a single resource, named "state".=A0 T= his=20 resource indicates whether the device passes ("on") or blocks (&= quot;off")=20 flow of electricity to its load, and is represented by the ASCII text=20 "on" or "off".=A0 Assume that I am permitted to update = the state, and when doing so can cause the device to change whether electricity flows to=20 its load.

Let's say I install one of these devices in my living room, and=20 connect it to a lamp on the western end-table.=A0 In the DHCP server for=20 my home network, I assign the name "westlr" and an IP address to = the=20 device.

Now assume I'm away from home, and forgot to turn off the lights=20 before I left.=A0 My Android phone has a VPN connection that allows it to= =20 connect directly to any host on my internal network, and I have a CoAP=20 browser on my phone (I wish....).=A0 The browser allows me to specify a=20 URI, has a box into which I can type a resource representation to be=20 sent as a message body, buttons for the four REST operations, and a=20 window in which the returned state description is displayed.

If I I enter "coap://westlr/state" in the URI box and press G= ET, the result window will contain the string "on" (without quotes), bec= ause I=20 forgot to turn off the lights.=A0=A0 If I type "off" into the mes= sage body=20 window, then press PUT, the lamp should turn off.=A0 Pressing "GET&quo= t; again=20 should put the string "off" in the result window.

Now let's say I put a similar device on the lamp on the other side= =20 of the sofa, and registered it as "eastlr".=A0 I can individually= query=20 and command that lamp through the uri "coap://eastlr/state".

Now: Building automation folks naturally see this and say "But I w= ant to turn=20 off all the lights simultaneously".=A0 They think, "Hey, CoAP is = based on=20 UDP, which supports multicast.=A0 Why don't I select an IP multicast gr= oup address, put it into DNS as "lamps", and have westlr and eastlr = join=20 that group.=A0 Then I can PUT "off" to "coap://lamps/state&q= uot; and turn=20 everything off at once."

Granted that could work for PUT, probably.=A0 But=20 leave the PUT aside.=A0 In REST, the syntactic act of requesting a method= =20 on a resource is always OK; whether that method has any meaning when=20 applied to a resource is determined by the server that processes the=20 REST transaction.=A0 I put "coap://lamps/state" into my CoAP brow= ser and=20 press GET.=A0 What shows up in my result window?

Under the covers, my droid sends a CoAP GET message to the IP=20 address that "lamps" resolves to.=A0 It has no idea that this is = a=20 multicast address (it could be forced to examine it, but normally it=20 wouldn't).=A0 Fine, assume it does, and it knows it could get responses= =20 from zero or more devices, depending on whether the request packet=20 reaches the west lamp, east lamp, both, or neither.=A0 Each of those will= =20 be a document containing "on" or "off".=A0 What's i= t supposed to display?=A0 I suppose I'd want to see something like "westlr: on; eastlr: off= ".=A0=20 That's not something the browser can figure out on its own.

Maybe eastlr is busy doing daily backups, and takes a few extra=20 seconds to reply.=A0 How does the browser know when it's received "= ;all"=20 the responses?

Really, this describes the fundamental problem.=A0=20 Putting "off" in the message body window and pressing POST is the= easy=20 part.=A0 Defining what happens with all the other ways you can legally use CoAP or HTTP with this URI "scheme://lamps/state" that happens t= o have=20 an authority part that resolves to a multicast group---that's the hard= =20 part.=A0 Recall that neither the client, nor any intermediate servers that happen to observe the transaction as it passes between the client and=20 the origin server(s) have any knowledge about the operation except what=20 can be determined from the REST method, the URI, and the transaction=20 message contents.=A0 None of that explains how to aggregate multiple=20 representations into a single resource state.=A0 There *is* no single=20 resource state, because the URI does not identify=A0 a resource.

One way to solve=20 the building automation problem is to say that "coap://lamps/state&quo= t; is a distinct resource the value of which is the aggregate view of the=20 states of all devices that are members of group "lamps", from the= =20 perspective of some authoritative view provided by a single server.=A0=20 That server can, under the covers, perform its updates in whatever way=20 it needs to: iterating through a list sending CoAP messages to each=20 lamp, or multicasting a non-REST "turn off" command.=A0 What it c= an't do,=20 without opening a huge can of mess, is try to use REST over multicast to manipulate a bunch of resources simultaneously.=A0 That's not REST, at= least as I understand it.

--0016368482837318a3049169166b-- From cabo@tzi.org Wed Sep 29 11:31: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 0DAB23A6D54 for ; Wed, 29 Sep 2010 11:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.109 X-Spam-Level: X-Spam-Status: No, score=-106.109 tagged_above=-999 required=5 tests=[AWL=0.140, 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 kSSf37Ny9myE for ; Wed, 29 Sep 2010 11:31: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 D7F1B3A6D86 for ; Wed, 29 Sep 2010 11:31: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 o8TIWNNs029305; Wed, 29 Sep 2010 20:32:23 +0200 (CEST) Received: from [192.168.217.101] (p5489AC72.dip.t-dialin.net [84.137.172.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E52F7110; Wed, 29 Sep 2010 20:32:22 +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, 29 Sep 2010 20:32:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71ACAD30-3D18-4BC6-9D4D-03CCE3052DDB@tzi.org> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: [core] Group operations (was: Re: REST, URIs, and constrained devices) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 18:31:52 -0000 On Sep 29, 2010, at 19:14, Peter Bigot wrote: > If CoRE wants to extend the concept of URI to denote a distributed = resource which is an aggregation of independently managed state I think that is a big IF. I prefer to think about this as operating on a _set_ of resources. Having a single identifier that identifies this set is relatively(*) = easy. As you note, defining the semantics of a PUT also is reasonably easy = (assuming no errors); GET less so, because we suddenly need a way to = represent the resulting table/dictionary/hash/mapping (mathematically, = it's a function). (*) The even more interesting part is defining who is part of the group = (and thus, the domain of the above function). Reducing the thought to = IP multicast means that this group is a somewhat random subset of the = set of nodes that have joined the multicast address; this assumes that = the constrained network has a good way to manage the joins. Taking out = the randomness requires a reliable multicast (transport) protocol. RFC = 5740 defines a good one; it just happens to be about half an order of = magnitude more complex than TCP (which we are trying to avoid because it = may be too complex for our constrained environments). If you want to define another one, good luck: RFC 5740 was published in = 2009 based on work that was started in the early to mid-1990s. The other way to manage a group is through a proxy-like construction. = This then also can do any concept of aggregation that we care about. = Classical sensor network research has often attempted to integrate that = proxy function with packet forwarding. Gruesse, Carsten From cabo@tzi.org Wed Sep 29 11:41: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 696AE3A6CFB for ; Wed, 29 Sep 2010 11:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.112 X-Spam-Level: X-Spam-Status: No, score=-106.112 tagged_above=-999 required=5 tests=[AWL=0.137, 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 5i1pDLXcTWBU for ; Wed, 29 Sep 2010 11:41: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 2713C3A6D71 for ; Wed, 29 Sep 2010 11:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o8TIfhNp003477; Wed, 29 Sep 2010 20:41:43 +0200 (CEST) Received: from [192.168.217.101] (p5489AC72.dip.t-dialin.net [84.137.172.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1D19211A; Wed, 29 Sep 2010 20:41:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <95FE86D4-31BD-44BA-9267-505AAC254E96@sensinode.com> Date: Wed, 29 Sep 2010 20:41:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <551ED6AE-6A55-4CD1-B5CF-736C089D84E9@tzi.org> References: <95FE86D4-31BD-44BA-9267-505AAC254E96@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Link to multicast http I-D X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Sep 2010 18:41:07 -0000 On Sep 29, 2010, at 18:53, Zach Shelby wrote: > requesting a random delay of 0 to mx before sending a response How do you choose that delay? You need a group size estimate plus an estimate of the capacities of = networks/nodes. The former is hard to obtain with the distributed group membership = management of IP multicast; the latter is essentially the congestion = control problem, but with the slight complication that the path now is a = tree. (In a small and lightly-loaded network, some worst-case assumptions can = carry quite far, though; e.g., section 5.5.4 of RFC 5740 gets by with = simply assuming a group size estimate of 10000 is not worse than an = order of magnitude wrong -- this would certainly be true with RFC 4944 = 16-bit addressing.) Gruesse, Carsten From zach@sensinode.com Wed Sep 29 12:49: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 59A973A6C7B for ; Wed, 29 Sep 2010 12:49:31 -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 7kfTMIX3hqbx for ; Wed, 29 Sep 2010 12:49:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 533263A6A94 for ; Wed, 29 Sep 2010 12:49:28 -0700 (PDT) Received: from [192.168.1.3] (line-5246.dyn.kponet.fi [85.29.66.209]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o8TJnjKQ031368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Sep 2010 22:50:06 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-4-387189903; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 29 Sep 2010 21:22:31 +0300 Message-Id: <5D12CFA3-73F4-4D46-8C5C-70B52472282A@sensinode.com> References: <20100928085643.27A7C3A6C7A@core3.amsl.com> <12D57F29-D6CC-496B-B37B-519BECFD16F3@sensinode.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-link-format-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, 29 Sep 2010 19:49:31 -0000 --Apple-Mail-4-387189903 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Peter, On Sep 29, 2010, at 7:18 PM, Peter Bigot wrote: > The link extensions just prior to section 2.1 need to add required > quotations around URI and URI-Reference, as are present with the > anchor link param in draft-nottingham-http-link-header. Otherwise > they're not conformant to that document's syntax for link-extensions. >=20 > link-extension =3D ( "d" "=3D" <"> URI <"> ) > link-extension =3D ( "sh" "=3D" <"> URI-Reference <"> ) > link-extension =3D ( "n" "=3D" quoted-string ) > link-extension =3D ( "ct" "=3D" integer ) > link-extension =3D ( "id" "=3D" quoted-string ) >=20 > Also need to add: >=20 > integer =3D 1*DIGIT Thanks, I will fix that.=20 > Unfortunately this makes it impossible to syntactically distinguish > URIs from strings in the "n" and "id" extensions. Dunno if that will > be a problem for anybody. I wouldn't find that to be a problem, except this text in Section 2.7 = obviously needs to be fixed as id is only a quoted-string. "This attribute (id) may be in quoted-string format (e.g. in the case of = a UUID or XRI) or in URI format (e.g. in the case of a URN)." Zach >=20 > Peter >=20 > On Tue, Sep 28, 2010 at 4:06 AM, Zach Shelby = wrote: >> http://www.ietf.org/id/draft-shelby-core-link-format-00.txt >>=20 >> This new draft specifies the link format and well-known URI interface = for use in CoRE resource discovery separately from the base CoAP draft = as per ticket #21. In the process of spinning this into a separate = draft, several improvements were made (thanks Mark and Carsten!). >>=20 >> o The link format ABNF from draft-nottingham-http-link-header was = completely re-used, avoiding the need to redefine it. >> o Quoted strings were added for string attributes >> o Explanation of the target/context URI was added along with use of = the relation attribute in-line with draft-nottingham-http-link-header >> o References to DNS-SD and mDNS were completely removed as this was = found to be misleading in Maastricht >> o Well-known URI changed to /.well-known/core to make registration = possible (/r was too short) >> o Filtering was changed to a MAY >> o Proper IANA section was created >>=20 >> I plan on making one slide capturing these changes for tomorrow's = interim WG meeting, a 10 minute slot should be enough. >>=20 >> Zach >>=20 >> Begin forwarded message: >>=20 >>> From: IETF I-D Submission Tool >>> Date: September 28, 2010 11:56:43 AM GMT+03:00 >>> To: zach@sensinode.com >>> Subject: New Version Notification for = draft-shelby-core-link-format-00 >>>=20 >>>=20 >>> A new version of I-D, draft-shelby-core-link-format-00.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >>>=20 >>> Filename: draft-shelby-core-link-format >>> Revision: 00 >>> Title: CoRE Link Format >>> Creation_date: 2010-09-28 >>> WG ID: Independent Submission >>> Number_of_pages: 10 >>>=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 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-4-387189903 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyOTE4MjIz MVowIwYJKoZIhvcNAQkEMRYEFLI5Xza9ex3M6sjuAyJIPZvU1qHOMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAIR1wEAq8zqhxk2YOXZ6SJbVfPMYkM14m7vnyzZ0AhNcTVlelTVRU8PC WlpBpcKqUg9aFGT8Kr7NtBBQAk9eW7yRiIndkKgvADSyWAN/V3P7BItq8Ramk50yXkJfN6GDe5ej Wf3jboy4YmRWhEWHqX7FulJuRMepw10LW2Y2RrKxUH/TbS3s2Cgp7xnZrhtA25JOkHteD+YwaieQ HIt3x55kvbr4gBV9FlYRgt0S1Oz99Y8PlbSubMm82YcRKpXO0xD2MUKEAq8hv4tAWgUDQkcI2YFB r1OB6e6ChydMfBhSrkisZviP7Wx4WHUfCgPKXj1vcb/n6y6RzkyHQzkT+IcAAAAAAAA= --Apple-Mail-4-387189903-- From cabo@tzi.org Wed Sep 29 14:35: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 554313A6AEA for ; Wed, 29 Sep 2010 14:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.115 X-Spam-Level: X-Spam-Status: No, score=-107.115 tagged_above=-999 required=5 tests=[AWL=1.134, 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 lbo9DRai0N7O for ; Wed, 29 Sep 2010 14:35: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 A24903A6A29 for ; Wed, 29 Sep 2010 14:35: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 o8TLaO8b027119 for ; Wed, 29 Sep 2010 23:36:24 +0200 (CEST) Received: from [192.168.217.101] (p5489AC72.dip.t-dialin.net [84.137.172.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 99E9816D; Wed, 29 Sep 2010 23:36:24 +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, 29 Sep 2010 23:36:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> References: To: core X-Mailer: Apple Mail (2.1081) 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: Wed, 29 Sep 2010 21:35:56 -0000 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 From rstruik.ext@gmail.com Wed Sep 29 15:18: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 38F953A6A29 for ; Wed, 29 Sep 2010 15:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 L4Qn2gBAR+CE for ; Wed, 29 Sep 2010 15:18:07 -0700 (PDT) Received: from mail-ww0-f52.google.com (mail-ww0-f52.google.com [74.125.82.52]) by core3.amsl.com (Postfix) with ESMTP id 7E2FE3A6A9A for ; Wed, 29 Sep 2010 15:18:06 -0700 (PDT) Received: by wwc33 with SMTP id 33so257655wwc.33 for ; Wed, 29 Sep 2010 15:18:48 -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=4DRJmX9d7pRjiYmuFzku9cQobOz3IMDcVekUFQpV7P4=; b=UuOYv5uEbnHyp5X/we3pqR0L1qAJIozCW01Q1ayb3h6b3kh9RU82BcDebOJsCuQqBC XbIPkFlo1ya79t4o4GQ6zekfr1dABfMiBCrPBRZ1Z66v8WqP1XMkl7nc+oe/ak8tlSGg KsTaAbL7yWK6sVaLVonVQubwdzHs9ab7+E03w= 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=hCRgCaINmrx/LZ1E7yq3RiNoaT/F58BbWjHXit0AWFo/3O8VvCCA9CIlO13KgFLLIo e8yvGUSHA3OURcDdNwZ1jUBNUm5tHu4pGgFrqaJ1sJ4EZsa6SkNQbRotM7JjuCW3jT0+ QBxkrYBuJc18EhWyaE2twGHZKGumB6BTELp00= Received: by 10.216.168.202 with SMTP id k52mr2039213wel.105.1285798727582; Wed, 29 Sep 2010 15:18:47 -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 e18sm2760051vcf.12.2010.09.29.15.18.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 15:18:47 -0700 (PDT) Message-ID: <4CA3BB41.9040900@gmail.com> Date: Wed, 29 Sep 2010 18:18:41 -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: Carsten Bormann References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> In-Reply-To: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> Content-Type: multipart/alternative; boundary="------------090809020805010508090009" 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: Wed, 29 Sep 2010 22:18:14 -0000 This is a multi-part message in MIME format. --------------090809020805010508090009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 --------------090809020805010508090009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
--------------090809020805010508090009-- From rstruik.ext@gmail.com Wed Sep 29 15:18: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 68F953A6C43 for ; Wed, 29 Sep 2010 15:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.023 X-Spam-Level: X-Spam-Status: No, score=-4.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 5XzOcboRXmc3 for ; Wed, 29 Sep 2010 15:18:24 -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 687653A6BBB for ; Wed, 29 Sep 2010 15:18:23 -0700 (PDT) Received: by eyd10 with SMTP id 10so691968eyd.31 for ; Wed, 29 Sep 2010 15:19:07 -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=poYVz33KnAORdRHeshTsi6u3t8a0Vgoo8BvTbtsVAOc=; b=Mc0c76GNQ0DJ9nM15LTUI/fvTqhbRmYBRLrtEYEB076RgYaS4Zdrs1+32zclxXYefR TXbX7iSjBdhGkioATq7SIsFbKU96ukiR/BIkL4kEOvKYdj6dh3uw4eR2iuQumTOUiI73 e6EAwmIhP4ZBFdM4Zu6d9a9rSIw0rTJUVoFv0= 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=xfr6ZSbWIKE09s5zAlwbiPc1u5Fw1fOA05xqgDcDKrZ6QRt7gqKefw7O7q8Jw17r7c C74RIyJ1DRWn7l8xdrh7N2go34Ay6wPCUVr8E4TfuoKeSD9pAISkZx2r2ZxwV4RzI35V tHp4cc3Tig2SXCErzrf9O832v4yAkQ8BM1J6w= Received: by 10.213.35.133 with SMTP id p5mr2212329ebd.32.1285798746368; Wed, 29 Sep 2010 15:19:06 -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 k15sm2760292vcs.29.2010.09.29.15.19.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Sep 2010 15:19:05 -0700 (PDT) Message-ID: <4CA3BB54.8050706@gmail.com> Date: Wed, 29 Sep 2010 18:19:00 -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: Carsten Bormann References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> In-Reply-To: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> Content-Type: multipart/alternative; boundary="------------080704040600050309060901" 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: Wed, 29 Sep 2010 22:18:32 -0000 This is a multi-part message in MIME format. --------------080704040600050309060901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 --------------080704040600050309060901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
--------------080704040600050309060901-- From kerlyn2001@gmail.com Wed Sep 29 15:35: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 0E9A93A6BD2 for ; Wed, 29 Sep 2010 15:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 Yts9X8TiAWAR for ; Wed, 29 Sep 2010 15:35: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 966F03A6835 for ; Wed, 29 Sep 2010 15:35:03 -0700 (PDT) Received: by bwz9 with SMTP id 9so1243111bwz.31 for ; Wed, 29 Sep 2010 15:35:47 -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=0TaeS2Tz6+mEGb7wotsfv2YoRtU+I3pp1fEs8KATG/Q=; b=SbONEH+EnIJfOonovbKkJQZSTyXl3Rr23d9xgYMbnS8Oo4/CrwS8s9TYZFn4TISKvq EkRBs1FduTbDoSIJx2OKu3nP0DOGC4ueWtNs6o924/ASbz7Iget4qN48+ALdnpMjBk3c x0oS4aVPM5XNFHZGt72OFkAtrCn12XiQ12Cl0= 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=iv+TQePQAk/b+ZmiAY4ZXhe6Ey6k3PwQSo/hKe/q2PX2RcpTXJM4v5qej/QFmoK1Lo OrH8ZX9W0Kxxtd6LfhnZryr01yLPtoRS27CDd9mgwkaaRD5G7dCwZJrnqOxclEtueaWU f7rs8id0GylVlv8T5I/tn82pbUBk15F3OIe8k= MIME-Version: 1.0 Received: by 10.204.112.146 with SMTP id w18mr1957344bkp.16.1285799747280; Wed, 29 Sep 2010 15:35:47 -0700 (PDT) Received: by 10.204.104.14 with HTTP; Wed, 29 Sep 2010 15:35:47 -0700 (PDT) In-Reply-To: <71ACAD30-3D18-4BC6-9D4D-03CCE3052DDB@tzi.org> References: <71ACAD30-3D18-4BC6-9D4D-03CCE3052DDB@tzi.org> Date: Wed, 29 Sep 2010 18:35:47 -0400 Message-ID: From: Kerry Lynn To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Group operations (was: Re: REST, URIs, and constrained devices) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 22:35:19 -0000 Obviously this topic requires much thought and discussion, but I did want t= o reiterate a few points that were made on today's call. The plan is to gath= er all the issues relating to Group Communications into a single working doc. I agree with Carsten's point of view. Conceptually, the result of a multic= ast GET or PUT should be the same as if the client had unicast them serially (that is, a set of {URI, representation} tuples). Logically, this seems si= milar to pub/sub. Practically, there are major benefits to solving this problem: - packet economy on constrained networks - M2M resource discovery (solves the "chicken-and-egg" problem) - apparent simultaneity of events (e.g. lighting applications) For data links (or transports) that don't support multicast, a serial unica= st analog must be provided. In either case it should be possible to enumerate the members of a group. For links that do support multicast, I think there are a few implications: - All multicast requests MUST be sent to the well-known port - All multicast requests SHOULD operate on /.well-known/core URIs One question is whether the application (or middleboxes) need to be aware that a request is intended for a group. Aside from the response dithering already pointed out by Zach, here's where a separate scheme (e.g. corem) as proposed by the old Microsoft I-D might be useful. Lastly, in response to Carsten's comments about (non-)reliable multicast, one strategy might be to send multiple requests, particularly for unconfirm= ed. Of course then we'd need to avoid non-idempotent requests (POST). In some confirmed request scenarios (those requiring apparent simultaneity) it may be preferable to repeat multicast requests even if it results in the same amount of traffic as the equivalent reliable serial unicast. Regards, -K- On Wed, Sep 29, 2010 at 2:32 PM, Carsten Bormann wrote: > On Sep 29, 2010, at 19:14, Peter Bigot wrote: > >> If CoRE wants to extend the concept of URI to denote a distributed resou= rce which is an aggregation of independently managed state > > I think that is a big IF. > > I prefer to think about this as operating on a _set_ of resources. > > Having a single identifier that identifies this set is relatively(*) easy= . > As you note, defining the semantics of a PUT also is reasonably easy (ass= uming no errors); GET less so, because we suddenly need a way to represent = the resulting table/dictionary/hash/mapping (mathematically, it's a functio= n). > > (*) The even more interesting part is defining who is part of the group (= and thus, the domain of the above function). =A0Reducing the thought to IP = multicast means that this group is a somewhat random subset of the set of n= odes that have joined the multicast address; this assumes that the constrai= ned network has a good way to manage the joins. =A0Taking out the randomnes= s requires a reliable multicast (transport) protocol. RFC 5740 defines a go= od one; it just happens to be about half an order of magnitude more complex= than TCP (which we are trying to avoid because it may be too complex for o= ur constrained environments). > If you want to define another one, good luck: RFC 5740 was published in 2= 009 based on work that was started in the early to mid-1990s. > > The other way to manage a group is through a proxy-like construction. =A0= This then also can do any concept of aggregation that we care about. =A0Cla= ssical sensor network research has often attempted to integrate that proxy = function with packet forwarding. > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From cabo@tzi.org Wed Sep 29 16:08: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 D0FEF3A69DD for ; Wed, 29 Sep 2010 16:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.139 X-Spam-Level: X-Spam-Status: No, score=-106.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 PID28-G0PIqa for ; Wed, 29 Sep 2010 16:08:19 -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 1DEE43A6835 for ; Wed, 29 Sep 2010 16:08:18 -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 o8TN8tqD000138; Thu, 30 Sep 2010 01:08:55 +0200 (CEST) Received: from [192.168.217.101] (p5489AC72.dip.t-dialin.net [84.137.172.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7E1CB181; Thu, 30 Sep 2010 01:08:54 +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, 30 Sep 2010 01:08:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F9ACAB3-9ED7-466E-83BD-FCD541CD4D98@tzi.org> References: <71ACAD30-3D18-4BC6-9D4D-03CCE3052DDB@tzi.org> To: Kerry Lynn X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Group operations (was: Re: REST, URIs, and constrained devices) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 23:08:20 -0000 Thanks, Kerry, for summarizing these important points. One quick comment: On Sep 30, 2010, at 00:35, Kerry Lynn wrote: > Lastly, in response to Carsten's comments about (non-)reliable = multicast, > one strategy might be to send multiple requests, particularly for = unconfirmed. This strategy is often called "saturation" in reliable multicast = protocols, and it can indeed be used to increase the subset of the group = membership from which a response actually arrives. (To minimize = redundant confirmations, a bloom filter can be sent with each repeated = request). > Of course then we'd need to avoid non-idempotent requests (POST). We already have transaction IDs in CoAP, which solve this problem = nicely. The one thing that might need additional attention is the lifetime of a = transaction; for unicast, this is pretty much limited by = RESPONSE_TIMEOUT * (2 ^ MAX_RETRANSMIT - 1) (~ half a minute). For = multicast, it MAY be sensible to extend that retention time, or we = could decide that half a minute is enough. In any case, the last = paragraph of 4.2 may need to be extended. Gruesse, Carsten From Colin.OFlynn@atmel.com Thu Sep 30 01:11: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 9E0EB3A6C1F for ; Thu, 30 Sep 2010 01:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=1.527, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 RBGQwZ5m3C9I for ; Thu, 30 Sep 2010 01:11:29 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 32CA63A69F9 for ; Thu, 30 Sep 2010 01:11:28 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o8U89XiZ013224; Thu, 30 Sep 2010 01:09:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6077.2276412E" Date: Thu, 30 Sep 2010 02:10:08 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Meeting minutes Thread-Index: ActgHnLs9ft8dD7RSgirxMaDeqFZdgAWHKFE References: <935DB371-B149-486A-8AD2-3B4454C9B172@tzi.org> From: "Oflynn, Colin" To: "Carsten Bormann" , "core" Subject: Re: [core] Meeting minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 08:11:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6077.2276412E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Just a note the minutes show the bootstrapping draft was moving towards = "More about bootstrapping, less security.". That should have been the = other way around - the current draft dealt mostly with bootstrapping, = but instead it will be moving to more about security setup. -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Carsten Bormann Sent: Wed 29/09/2010 22:36 To: core Subject: Re: [core] Fwd: Wed 29, 1500 UTC (Fwd: Meeting invitation: = CORE WG) =20 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 ------_=_NextPart_001_01CB6077.2276412E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] Meeting minutes

Hello,

Just a note the minutes show the bootstrapping draft was moving towards = "More about bootstrapping, less security.". That should have = been the other way around - the current draft dealt mostly with = bootstrapping, but instead it will be moving to more about security = setup.

  -Colin




-----Original Message-----
From: core-bounces@ietf.org on behalf of Carsten Bormann
Sent: Wed 29/09/2010 22:36
To: core
Subject: Re: [core] Fwd:  Wed 29, 1500 UTC (Fwd: Meeting = invitation: CORE WG)

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

------_=_NextPart_001_01CB6077.2276412E-- From ydoi@isl.rdc.toshiba.co.jp Thu Sep 30 02: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 85AC53A6DC0 for ; Thu, 30 Sep 2010 02:17:31 -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 1m5+IiMmhnQI for ; Thu, 30 Sep 2010 02:17:30 -0700 (PDT) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by core3.amsl.com (Postfix) with ESMTP id 8B0C43A6C4D for ; Thu, 30 Sep 2010 02:17:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id 121292E3F3 for ; Thu, 30 Sep 2010 18:18:13 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp ([127.0.0.1]) by localhost (tsbgw.wide.toshiba.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJuRnjzlBdkL for ; Thu, 30 Sep 2010 18:18:12 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp.isl.rdc.toshiba.co.jp (localhost [127.0.0.1]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id E06A72E3F0 for ; Thu, 30 Sep 2010 18:18:12 +0900 (JST) Date: Thu, 30 Sep 2010 18:18:12 +0900 Message-ID: From: ydoi@isl.rdc.toshiba.co.jp To: core@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [core] a trivial question on coap-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, 30 Sep 2010 09:17:31 -0000 Hi, I have a trivial question on coap-02. coap-02 says: Unknown options of class "critical" in a Confirmable SHOULD cause the return of a response code "400 Bad Request" (TBD) including a copy of the critical option number in the payload of the response. May I assume the payload in "text/plain" and the value would be somewhat like ascii "3" (0x33) ? Regards, Yusuke