From trac@tools.ietf.org Wed Dec 1 03:26: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 CD1553A6B3F for ; Wed, 1 Dec 2010 03:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 N0t5vpfatTVE for ; Wed, 1 Dec 2010 03:26:33 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 75DBC28C0F3 for ; Wed, 1 Dec 2010 03:26:17 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PNkqI-0005r3-2n; Wed, 01 Dec 2010 03:27:22 -0800 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 X-Trac-Project: core Date: Wed, 01 Dec 2010 11:27:22 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/87 Message-ID: <051.eeb8059d1ae7e95d8ee7a5d799dbefa1@tools.ietf.org> X-Trac-Ticket-ID: 87 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] coap #87 (new): DTLS section fixes 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, 01 Dec 2010 11:26:33 -0000 #87: DTLS section fixes This draft is not in the business of making recommendations with respect to the implementability of security protocols. Instead section 10 should document the security considerations. Remove: -- claim that DTLS is an order of magnitude more complex than CoAP -- claim that DTLS has appreciable handshake overhead Instead, provide some input on how DTLS can be used in a way that is appropriate for constrained devices. If there were a DTLS-lite draft (similar to the one foreseen for IKE- lite), we could reference that -- we should attempt to procure it. Other fixes required: -- More text about PSK and the minimum entropy of that key. -- Fix citation (currently of 5246) for the PSK modes. -- 10.3.1 is obvious to security people. It is also limiting itself to URI parsing. More generally, this could refer to robustness in protocol parsing (not just by referring to testing). We could point out that we have attempted to minimize the URI parser concerns by not exposing the CoAP protocol to the URI syntax. (However, we still carry the link- format, where this *is* a valid security concern.) -- s/cypher/cipher/g (Channeling EKR's review in http://www.ietf.org/mail- archive/web/core/current/msg01061.html) -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: Type: defect | Status: new Priority: major | Milestone: coap-03 Component: coap | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From kovatsch@inf.ethz.ch Wed Dec 1 03:46:18 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6773A6C65 for ; Wed, 1 Dec 2010 03:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id armhHgORmfAB for ; Wed, 1 Dec 2010 03:46:17 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by core3.amsl.com (Postfix) with ESMTP id 44C573A6B41 for ; Wed, 1 Dec 2010 03:46:16 -0800 (PST) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 1 Dec 2010 12:47:21 +0100 Received: from MBX10.d.ethz.ch ([169.254.1.163]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%11]) with mapi id 14.01.0218.012; Wed, 1 Dec 2010 12:47:29 +0100 From: "Kovatsch Matthias" To: core WG Thread-Topic: [core] Review of draft-ietf-core-coap-03.txt Thread-Index: AQHLhimuEtxLMowFxkGWDYOXIoEgg5N+xJMAgAbG04CAAEgjAIAAFgQAgAWfIVA= Date: Wed, 1 Dec 2010 11:47:28 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5082B7895@MBX10.d.ethz.ch> References: <4CE38524.60106@isode.com> <4CF13897.2000206@isode.com> <165D2C63-2C32-4300-A653-B829734CC47B@tzi.org> <4CF18792.2040302@isode.com> In-Reply-To: <4CF18792.2040302@isode.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 11:46:18 -0000 Hi To me, Table 2 in "3.2. Header options" appears to have some flaws: - option type 3 columns displaced: "Reserved" under data type while stating= C for critical - option type 7: completely blank, not reserved? - option type 8: missing Maybe also types 14, 28, etc. should be listed as reserved or otherwise mar= ked here? I personally was also missing a table for the transaction types which alway= s help with the implementation. Best regards Matthias From cabo@tzi.org Wed Dec 1 03:46:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F83B3A6C65 for ; Wed, 1 Dec 2010 03:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjsbg-yhp1XM for ; Wed, 1 Dec 2010 03:46:52 -0800 (PST) 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 E182D3A6A0C for ; Wed, 1 Dec 2010 03:46:51 -0800 (PST) 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 oB1BlRgR027936; Wed, 1 Dec 2010 12:47:27 +0100 (CET) Received: from eduroam-0157.wlan.uni-bremen.de (eduroam-0157.wlan.uni-bremen.de [134.102.16.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5E12A86A; Wed, 1 Dec 2010 12:47:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 1 Dec 2010 12:47:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82E83012-DAED-4080-8268-415663C5BF3B@tzi.org> References: To: matthieu.vial@fr.non.schneider-electric.com X-Mailer: Apple Mail (2.1082) Cc: core WG , Klaus Hartke Subject: Re: [core] :Re: Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 11:46:53 -0000 On Nov 29, 2010, at 15:54, matthieu.vial@fr.non.schneider-electric.com = wrote: >>> However you didn't answer the question what code should be returned, >>> 100 or 202? >=20 >> Neither 100 nor 202. Here's an example: >> C: CON + GET coap://server/resource (token=3D0x5f) >> S: ACK >> S: CON + S_OK (token=3D0x5f) "Hello World" >> C: ACK >=20 > But is it allowed for an HTTP/CoAP proxy to translate the first ACK = with=20 > code 0 into a 202 Accepted response? I don't think so. (First of all, there is no 202 in HTTP for GET. But let's pretend the = example is about a POST.) With a 202 response, the HTTP server makes a "non-commital" (RFC 2616, = 10.2.3) final response. There is no way to send a deferred response = later as we can in CoAP. Here, the ACK means just that: "stop retransmitting, I got the datagram = with the request". It does not mean the request even will be accepted. = The actual response comes back in the form of a deferred response. It = is that which carries the actual response code. The ACKs have no = meaning with respect to the request/response pair; hence they carry "no = code" (=3D 0). Gruesse, Carsten From cabo@tzi.org Wed Dec 1 04:06:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADA73A6C56 for ; Wed, 1 Dec 2010 04:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws038P36E3kj for ; Wed, 1 Dec 2010 04:06:44 -0800 (PST) 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 C818D3A6C69 for ; Wed, 1 Dec 2010 04:06:43 -0800 (PST) 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 oB1C7nCN007901; Wed, 1 Dec 2010 13:07:49 +0100 (CET) Received: from eduroam-0157.wlan.uni-bremen.de (eduroam-0157.wlan.uni-bremen.de [134.102.16.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 249DF893; Wed, 1 Dec 2010 13:07:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5082B7895@MBX10.d.ethz.ch> Date: Wed, 1 Dec 2010 13:07:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CE38524.60106@isode.com> <4CF13897.2000206@isode.com> <165D2C63-2C32-4300-A653-B829734CC47B@tzi.org> <4CF18792.2040302@isode.com> <55877B3AFB359744BA0F2140E36F52B5082B7895@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1082) Cc: core WG Subject: Re: [core] Review of draft-ietf-core-coap-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 12:06:45 -0000 Thanks, Matthias. Yes, we need to clean up that table. On Dec 1, 2010, at 12:47, Kovatsch Matthias wrote: > Hi >=20 > To me, Table 2 in "3.2. Header options" appears to have some flaws: >=20 > - option type 3 columns displaced: "Reserved" under data type while = stating C for critical That is actually not a flaw -- option type 3 is reserved (and probably = will be resurrected as "Uri-Scheme" in coap-04). It is Critical because the option number is odd. Critical means that an = implementation that does not understand the option cannot properly = handle a message that uses it. > - option type 7: completely blank, not reserved? (There is a proposal lingering to use this for Uri-Authority-Binary -- = coap-misc section 3.2. =20 Yes, the intention here in core-coap appears to be to make it reserved = for now.) > - option type 8: missing This is actually unassigned (was Date and Accept in various previous = versions). I don't think we need to list all unassigned codes. > Maybe also types 14, 28, etc. should be listed as reserved or = otherwise marked here? Indeed, these should be listed in the table (see also coap-misc section 4.5). > I personally was also missing a table for the transaction types which = always help with the implementation. Good point. It's buried in the definition of "T" in section 3.1 right = now. (The nibble-spotters among us tend to see the hex values of 4=3DCON, = 5=3DNON, 6=3DACK, 7=3DRST in the packet dumps, maybe even that should be = mentioned somewhere.) T field resulting first nibble (Ver||T) CON 0 4 NON 1 5 ACK 2 6 RST 3 7 Gruesse, Carsten From matthieu.vial@fr.non.schneider-electric.com Wed Dec 1 08:37: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 992073A6C56 for ; Wed, 1 Dec 2010 08:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 DXuscp3JP5IV for ; Wed, 1 Dec 2010 08:36:58 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 588183A6BC1 for ; Wed, 1 Dec 2010 08:36:58 -0800 (PST) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2010120117181870-34829 ; Wed, 1 Dec 2010 17:18:18 +0100 In-Reply-To: <82E83012-DAED-4080-8268-415663C5BF3B@tzi.org> To: Carsten Bormann MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: Matthieu VIAL Message-ID: Date: Wed, 1 Dec 2010 17:38:07 +0100 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 01/12/2010 17:38:03, Serialize complete at 01/12/2010 17:38:03, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 01/12/2010 17:18:18, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 01/12/2010 17:18:19, Serialize complete at 01/12/2010 17:18:19 Content-Type: text/plain; charset="US-ASCII" Cc: Klaus Hartke , core WG Subject: Re: [core] :Re: Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 16:37:00 -0000 >> But is it allowed for an HTTP/CoAP proxy to translate the first ACK with >> code 0 into a 202 Accepted response? >I don't think so. >(First of all, there is no 202 in HTTP for GET. But let's pretend the example is about a POST.) So if a proxy wants to allow parallel jobs for a batch process it should answer with HTTP 202 responses and forward the POST requests as non-confirmable CoAP transactions? And If the proxy thinks the CoAP deferred response takes too much time to arrive it must send an HTTP 504 Gateway timeout response and never an HTTP 202? >With a 202 response, the HTTP server makes a "non-commital" (RFC 2616, 10.2.3) final response. There is no way to send a deferred response later as we can in CoAP. >Here, the ACK means just that: "stop retransmitting, I got the datagram with the request". It does not mean the request even will be accepted. The actual response comes back in the form of a deferred response. It is that which carries the actual response code. The ACKs have no meaning with respect to the request/response pair; hence they carry "no code" (= 0). >From the HTTP client's perspective I can't see a big difference between "It does not mean the request even will be accepted" of CoAP and "[the request] it might be disallowed when processing actually takes place" of HTTP. The HTTP request may be accepted from the proxy point of view. Then the forwarded request may not be accepted by the CoAP server which I can also understand as "disallowed when processing". Let's take the following example. The proxy wants to answer its HTTP clients always within X seconds. After Xs with a "no code" ACK but no deferred response from the CoAP server the proxy send a 202 Accepted response with the URL to a resource containing the status of the outstanding CoAP request. Then the HTTP client can start a new request and check the result of the previous one later. Is there something wrong with that? Matthieu From pab@peoplepowerco.com Wed Dec 1 09:21: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 131F53A6C1C for ; Wed, 1 Dec 2010 09:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LzgjpeeiTiA for ; Wed, 1 Dec 2010 09:21:39 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 93EA13A6C1A for ; Wed, 1 Dec 2010 09:21:38 -0800 (PST) Received: by fxm9 with SMTP id 9so5928959fxm.31 for ; Wed, 01 Dec 2010 09:22:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.74.198 with SMTP id v6mr1565030faj.4.1291224171785; Wed, 01 Dec 2010 09:22:51 -0800 (PST) Received: by 10.223.93.195 with HTTP; Wed, 1 Dec 2010 09:22:51 -0800 (PST) In-Reply-To: <014a01cb8e13$36e71db0$a4b55910$@com> References: <014a01cb8e13$36e71db0$a4b55910$@com> Date: Wed, 1 Dec 2010 11:22:51 -0600 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=20cf3043450415b02d04965c8eff Subject: Re: [core] Need WG input: request/response matching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 17:21:41 -0000 --20cf3043450415b02d04965c8eff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Time to wrap this up: Based on two "yes", one "no", and several dozen abstaining, I think the consensus of the WG is that clients must support deferred responses. The rationale is an assumption that "constrained" is loose enough that this is a not burden to any implementation. An implicit consequence is that there is no need for a client to be able to influence the server's selection of immediate or deferred response. The impact of this on sleeping nodes is not a concern; presumably it can be handled by proxies/reverse proxies. This allows an entirely new conceptualization of CoAP transactions. I had thought of immediate response as the normal situation, with deferred a special case to allow for long-duration operations. With deferred response support required, I can simplify my server by having it immediately transmi= t a CoAP-layer acknowledgement of every request, and allow the REST layer to provide the actual response at whatever time is most convenient. Technically, given the previous consensus that the server is entitled to change the contents of a CoAP-layer response to a retransmitted (same TID) request, if the REST layer responds in time I still could bundle the response into the ack in that situation. Interesting. Peter On Sat, Nov 27, 2010 at 3:12 AM, Linyi Tian wrote: > Hi, Peter > > > > My answer is =93yes=94. Here is my observation: > > 1. Client will not know whether the server needs time to process th= e > request. It will be hard for client to decide when to use negotiation > mechanism. > > 2. The server chooses to use deferred message is because the server > needs time to process the request. Even if the client wants to get the > result immediately it may not be realistic. If the server can=92t do it i= n > ACK, what the server can do? Simply reject the message? > > 3. If the end point can support the complex mechanism like > scheduling, I can=92t imagine it can=92t store the state associated with = Token > for short of time. > > > > The main mechanism for the client needs is to store the Token and has a > time-out mechanism. Maybe this is not a big issue for clients. Correct me= if > I am wrong. > > > > Cheers, > > Linyi > > > > *From:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf O= f > *Peter Bigot > *Sent:* Friday, November 26, 2010 3:41 AM > *To:* core > *Subject:* [core] Need WG input: request/response matching > > > > After the telecon yesterday there is a remaining issue in > http://trac.tools.ietf.org/wg/core/trac/ticket/74: whether or not CoAP > must provide a mechanism, such as presence/absence of the Token option in= a > request, to influence the server's decision to use an immediate or deferr= ed > response to a specific request. > > Carsten and I hold opposing positions, and I don't know which side Zack > ended on. So, we really need group input on this: > > *Should clients be required to support deferred responses to their > requests?* > > > Carsten's position is "Yes", because this requirement has minimal impact = on > the client and so there is no need to provide such a mechanism. Dependin= g > on the approach, this could reduce message sizes, simplify the client by > eliminating the need to re-transmit a request with "deferred-ok" flag if = the > server can't send an immediate response, and simplify the server > implementation. > > My position is "No". While any end-point that can accept incoming reques= ts > should have this machinery, I believe extremely constrained clients might > not want to incorporate that code (e.g., to send acknowledgements for > incoming confirmable messages), or to support any sort of state associate= d > with unfulfilled requests (e.g., correlating security contexts). Further= , > even if a client has the mechanism in place, there may be temporary reaso= ns > why the client does not want a deferred response for a specific request. > For example, following an observation by Zack, certain schedule-based acc= ess > policies might be difficult to implement if deferred responses, as curren= tly > drafted, were allowed. So, I think it's important to give the client the > ability to prevent deferred responses. > > Carsten, please follow up if I've failed to explain your position > adequately. > > Comments from anybody else? > > (This is a separate issue from a question of whether a client should be > able to provide a deadline by which the server must provide either an > immediate or deferred response, or to influence the retransmission delays > e.g. due to use of a satellite link, although having a mechanism for thes= e > issues might make it a moot question. I don't expect we'll have such a > mechanism defined within the time by which we expect to submit CoAP to > IESG.) > > Peter > --20cf3043450415b02d04965c8eff Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Time to wrap this up: Based on two "yes", one "no", and= several dozen abstaining, I think the consensus of the WG is that clients = must support deferred responses.=A0 The rationale is an assumption that &qu= ot;constrained" is loose enough that this is a not burden to any imple= mentation.=A0 An implicit consequence is that there is no need for a client= to be able to influence the server's selection of immediate or deferre= d response.=A0 The impact of this on sleeping nodes is not a concern; presu= mably it can be handled by proxies/reverse proxies.

This allows an entirely new conceptualization of CoAP transactions.=A0 = I had thought of immediate response as the normal situation, with deferred = a special case to allow for long-duration operations.=A0 With deferred resp= onse support required, I can simplify my server by having it immediately tr= ansmit a CoAP-layer acknowledgement of every request, and allow the REST la= yer to provide the actual response at whatever time is most convenient.=A0 = Technically, given the previous consensus that the server is entitled to ch= ange the contents of a CoAP-layer response to a retransmitted (same TID) re= quest, if the REST layer responds in time I still could bundle the response= into the ack in that situation.

Interesting.

Peter

On Sat, Nov= 27, 2010 at 3:12 AM, Linyi Tian <tianlinyi@huawei.com> w= rote:

Hi, Peter

=A0

My answer is =93yes=94. Here is my observation:

1.=A0=A0=A0=A0=A0=A0 Client will not know whether the server needs time to process the request. It will be hard for client to decide when to use negotiation mechanism.

2.=A0=A0=A0=A0=A0=A0 The server chooses to use deferred message is because the server needs time to process the request. Even if th= e client wants to get the result immediately it may not be realistic. If the server can=92t do it in ACK, what the server can do? Simply reject the mess= age?

3.=A0=A0=A0=A0=A0=A0 =A0If the end point can support the complex mechanism like scheduling, I can=92t imagine it can=92t store t= he state associated with Token for short of time.

=A0

The main mechanism for the client needs is to store = the Token and has a time-out mechanism. Maybe this is not a big issue for clients. Correct me if I am wrong.

=A0

Cheers,

Linyi

=A0

F= rom: core-bounces@ietf.org [= mailto:core-boun= ces@ietf.org] On Behalf Of Peter Bigot
Sent: Friday, November 26, 2010 3:41 AM
To: core
Subject: [core] Need WG input: request/response matching

=A0

= After the telecon yesterday there is a remaining issue in http://trac.tools.ietf= .org/wg/core/trac/ticket/74: whether or not CoAP must provide a mechanism, such as presence/absence of t= he Token option in a request, to influence the server's decision to use an immediate or deferred response to a specific request.

Carsten and I hold opposing positions, and I don't know which side Zack= ended on.=A0 So, we really need group input on this:

Should clients be required t= o support deferred responses to their requests?


Carsten's position is "Yes", because this requirement has min= imal impact on the client and so there is no need to provide such a mechanism.= =A0 Depending on the approach, this could reduce message sizes, simplify the cl= ient by eliminating the need to re-transmit a request with "deferred-ok&quo= t; flag if the server can't send an immediate response, and simplify the s= erver implementation.

My position is "No".=A0 While any end-point that can accept incoming requests should have this machinery, I believe extremely constrain= ed clients might not want to incorporate that code (e.g., to send acknowledgem= ents for incoming confirmable messages), or to support any sort of state associa= ted with unfulfilled requests (e.g., correlating security contexts).=A0 Further= , even if a client has the mechanism in place, there may be temporary reasons= why the client does not want a deferred response for a specific request.=A0 For example, following an observation by Zack, certain schedule-based access policies might be difficult to implement if deferred responses, as currentl= y drafted, were allowed.=A0 So, I think it's important to give the client= the ability to prevent deferred responses.

Carsten, please follow up if I've failed to explain your position adequ= ately.

Comments from anybody else?

(This is a separate issue from a question of whether a client should be abl= e to provide a deadline by which the server must provide either an immediate or deferred response, or to influence the retransmission delays e.g. due to us= e of a satellite link, although having a mechanism for these issues might make i= t a moot question.=A0 I don't expect we'll have such a mechanism define= d within the time by which we expect to submit CoAP to IESG.)

Peter


--20cf3043450415b02d04965c8eff-- From cabo@tzi.org Wed Dec 1 15:06: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 263463A680D for ; Wed, 1 Dec 2010 15:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 N0YABaOf11+2 for ; Wed, 1 Dec 2010 15:06:04 -0800 (PST) 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 BACB43A680A for ; Wed, 1 Dec 2010 15:06:03 -0800 (PST) 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 oB1N7AqD008607; Thu, 2 Dec 2010 00:07:10 +0100 (CET) Received: from [192.168.217.101] (p5489F670.dip.t-dialin.net [84.137.246.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 96888BBE; Thu, 2 Dec 2010 00:07:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 2 Dec 2010 00:07:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92EB69E4-0124-4D40-AB75-79B0DE84FC4D@tzi.org> References: To: Matthieu VIAL X-Mailer: Apple Mail (2.1082) Cc: Klaus Hartke , core WG Subject: Re: [core] :Re: Draft needs Asynchronous transaction details X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 23:06:05 -0000 On Dec 1, 2010, at 17:38, Matthieu VIAL wrote: >>> But is it allowed for an HTTP/CoAP proxy to translate the first ACK=20= > with=20 >>> code 0 into a 202 Accepted response? >=20 >> I don't think so. >> (First of all, there is no 202 in HTTP for GET. But let's pretend = the=20 > example is about a POST.) >=20 > So if a proxy wants to allow parallel jobs for a batch process it = should=20 > answer with HTTP 202 responses and forward the POST requests as=20 > non-confirmable CoAP transactions? I'm not sure I understand the scenario, but sending a 202 and then = forwarding on a nonconfirmable strikes me as wrong -- 202 at least means = "accepted", and there is no way to know whether the NON actually arrived = at the origin server. > And If the proxy thinks the CoAP deferred response takes too much time = to=20 > arrive it must send an HTTP 504 Gateway timeout response and never an = HTTP=20 > 202? Good question. A CoAP server that takes a LOOONG time to do a POST maybe is not a very = good candidate to map into the HTTP world. Or maybe it is, if the proxy is just patient enough (and has the = resources to be patient, e.g., sockets). >> =46rom the HTTP client's perspective I can't see a big difference = between=20 > "It does not mean the request even will be accepted" of CoAP and "[the=20= > request] it might be disallowed when processing actually takes place" = of=20 > HTTP. The HTTP request may be accepted from the proxy point of view. = Then=20 > the forwarded request may not be accepted by the CoAP server which I = can=20 > also understand as "disallowed when processing".=20 > Let's take the following example. The proxy wants to answer its HTTP=20= > clients always within X seconds. That is certainly one way to manage its resources. This proxy is just not very useful with very slow CoAP servers, unless = it has some processing rules like the ones you give below. (Note that if X < ~32, some processing rules are also required for the = case that it simply took a number of retransmissions to get an = "immediate" answer.) > After Xs with a "no code" ACK but no=20 > deferred response from the CoAP server the proxy send a 202 Accepted=20= > response with the URL to a resource containing the status of the=20 > outstanding CoAP request. That might work quite well for POST. (What does that resource respond while the POST is in progress?) > Then the HTTP client can start a new request and=20 > check the result of the previous one later. Is there something wrong = with=20 > that? I don't think there is anything particularly wrong with that mapping. (It is clearly not the only conceivable mapping.) I'm not sure that many HTTP clients know what to do with a 202 response, = so you may be in somewhat uncharted territory here. Gruesse, Carsten From zach@sensinode.com Thu Dec 2 07:02:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F2228C140 for ; Thu, 2 Dec 2010 07:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYXACCrVAZQP for ; Thu, 2 Dec 2010 07:02:41 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E023F28C0E3 for ; Thu, 2 Dec 2010 07:02:40 -0800 (PST) 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 oB2F3pEN016983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Dec 2010 17:03:51 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-78--537578594; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Thu, 2 Dec 2010 17:03:53 +0200 Message-Id: <575366D3-E600-4F5A-9F65-76E5297BC691@sensinode.com> References: <014a01cb8e13$36e71db0$a4b55910$@com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] Need WG input: request/response matching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 15:02:43 -0000 --Apple-Mail-78--537578594 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Peter, Thanks for taking the poll on this.=20 On Dec 1, 2010, at 7:22 PM, Peter Bigot wrote: > Time to wrap this up: Based on two "yes", one "no", and several dozen = abstaining, I think the consensus of the WG is that clients must support = deferred responses. The rationale is an assumption that "constrained" = is loose enough that this is a not burden to any implementation. An = implicit consequence is that there is no need for a client to be able to = influence the server's selection of immediate or deferred response. The = impact of this on sleeping nodes is not a concern; presumably it can be = handled by proxies/reverse proxies. In practice this means that a client makes a CON request, it must always = includes a token. This token is always included in the corresponding = response. Thus we never include the URI in a response for matching. I = can live with that. We have one more questions to answer for this ticket: 1. Do we allow the Token Option to have a default value, and thus not = requiring a Token Option to be included for clients that perform one = request at a time with an end-point? Klaus has this proposal in the = ticket right now. My personal opinion, is that we should consider supporting the default = value, however the security risks of that need to considered carefully. >=20 > This allows an entirely new conceptualization of CoAP transactions. I = had thought of immediate response as the normal situation, with deferred = a special case to allow for long-duration operations. With deferred = response support required, I can simplify my server by having it = immediately transmit a CoAP-layer acknowledgement of every request, and = allow the REST layer to provide the actual response at whatever time is = most convenient. Technically, given the previous consensus that the = server is entitled to change the contents of a CoAP-layer response to a = retransmitted (same TID) request, if the REST layer responds in time I = still could bundle the response into the ack in that situation. We are specifying how a protocol must behave here, not how clients are = implemented. I do agree that there are interesting implementation = optimizations to be made with this model. I am not sure that it would be = wise or efficient to always immediately send an ACK, as you would = increase network overhead, using 4 messages instead of 2. I think the = recommendation is that the response SHOULD be included with the first = ACK if possible in the specification. Zach >=20 > Interesting. >=20 > Peter >=20 > On Sat, Nov 27, 2010 at 3:12 AM, Linyi Tian = wrote: > Hi, Peter >=20 > =20 > My answer is =93yes=94. Here is my observation: >=20 > 1. Client will not know whether the server needs time to process = the request. It will be hard for client to decide when to use = negotiation mechanism. >=20 > 2. The server chooses to use deferred message is because the = server needs time to process the request. Even if the client wants to = get the result immediately it may not be realistic. If the server can=92t = do it in ACK, what the server can do? Simply reject the message? >=20 > 3. If the end point can support the complex mechanism like = scheduling, I can=92t imagine it can=92t store the state associated with = Token for short of time. >=20 > =20 > The main mechanism for the client needs is to store the Token and has = a time-out mechanism. Maybe this is not a big issue for clients. Correct = me if I am wrong. >=20 > =20 > Cheers, >=20 > Linyi >=20 > =20 > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Peter Bigot > Sent: Friday, November 26, 2010 3:41 AM > To: core > Subject: [core] Need WG input: request/response matching >=20 > =20 > After the telecon yesterday there is a remaining issue in = http://trac.tools.ietf.org/wg/core/trac/ticket/74: whether or not CoAP = must provide a mechanism, such as presence/absence of the Token option = in a request, to influence the server's decision to use an immediate or = deferred response to a specific request. >=20 > Carsten and I hold opposing positions, and I don't know which side = Zack ended on. So, we really need group input on this: >=20 > Should clients be required to support deferred responses to their = requests? >=20 >=20 > Carsten's position is "Yes", because this requirement has minimal = impact on the client and so there is no need to provide such a = mechanism. Depending on the approach, this could reduce message sizes, = simplify the client by eliminating the need to re-transmit a request = with "deferred-ok" flag if the server can't send an immediate response, = and simplify the server implementation. >=20 > My position is "No". While any end-point that can accept incoming = requests should have this machinery, I believe extremely constrained = clients might not want to incorporate that code (e.g., to send = acknowledgements for incoming confirmable messages), or to support any = sort of state associated with unfulfilled requests (e.g., correlating = security contexts). Further, even if a client has the mechanism in = place, there may be temporary reasons why the client does not want a = deferred response for a specific request. For example, following an = observation by Zack, certain schedule-based access policies might be = difficult to implement if deferred responses, as currently drafted, were = allowed. So, I think it's important to give the client the ability to = prevent deferred responses. >=20 > Carsten, please follow up if I've failed to explain your position = adequately. >=20 > Comments from anybody else? >=20 > (This is a separate issue from a question of whether a client should = be able to provide a deadline by which the server must provide either an = immediate or deferred response, or to influence the retransmission = delays e.g. due to use of a satellite link, although having a mechanism = for these issues might make it a moot question. I don't expect we'll = have such a mechanism defined within the time by which we expect to = submit CoAP to IESG.) >=20 > Peter >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-78--537578594 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIwMjE1MDM1 NFowIwYJKoZIhvcNAQkEMRYEFNzlwQESo1Cg9KH1QUL4yQoEOF2dMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABXo7w5mjScf6d1VyJNBfsf75HU4zSfOHPCjICtVvfqZrLOjlTuNDjNl 2FF/PGZNLbpD+TwsX3byQYkYc/2+bN4yMMIg9pWoryZk7xvGvk/WuZmxikVE/zKP/xBn6J5kSxzV Gfi1CWLUy8leZasA782O+xVyYLqfygS9NIdBDYRKSTnrUNq4z3jM3XNl8eELqiYFHgAGE295YMfz Az133aaEyQIwPQwT2a/LTVqa5ga5a2v08vVehgTc973V/aA9hQRnq08wk2+Az4zjjfpIL81SC/Gq TcEZndskWini7CORgyAILi7KiNIZVCjaNv9VceYFHb7EJQxF2Sbq3AMYlc4AAAAAAAA= --Apple-Mail-78--537578594-- From cabo@tzi.org Thu Dec 2 07:22: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 2FD3B3A6971 for ; Thu, 2 Dec 2010 07:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.857 X-Spam-Level: X-Spam-Status: No, score=-105.857 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784, 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 gP2WQ937CeN4 for ; Thu, 2 Dec 2010 07:22:43 -0800 (PST) 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 93B073A696F for ; Thu, 2 Dec 2010 07:22:42 -0800 (PST) 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 oB2FNn0q003918; Thu, 2 Dec 2010 16:23:49 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6386BF66; Thu, 2 Dec 2010 16:23:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <575366D3-E600-4F5A-9F65-76E5297BC691@sensinode.com> Date: Thu, 2 Dec 2010 16:23:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <014a01cb8e13$36e71db0$a4b55910$@com> <575366D3-E600-4F5A-9F65-76E5297BC691@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1082) Cc: core Subject: Re: [core] Need WG input: request/response matching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 15:22:44 -0000 On Dec 2, 2010, at 16:03, Zach Shelby wrote: > We are specifying how a protocol must behave here, not how clients are = implemented.=20 Yes, but then we want to make sure we have a rough idea that (and thus = to a certain extent how) clients *can* be implemented. If the communication part of server is decoupled from the resource = manager enough that it does not know whether the response will be ready = in less than (RESPONSE_TIMEOUT - IP_latency_corrected_for_stddev), a = likely implementation strategy is to set a timer (say, to 0.5 s) and to = send the ACK/0 when the timer expires; if the response is ready before = timer expiration, you cancel the timer and send an immediate response = (ACK/response_code with options and payload). Many highly constrained servers will be integrated enough that they can = make the immediate/deferred decision in a much simpler way. Re the token default: If a client only ever asks the same question to a = specific server, a default value for the Token will serve that client = well; more so if the exchange is protected by a security association. Gruesse, Carsten From angelo.castellani@gmail.com Thu Dec 2 08:32: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 3AB1C28C165 for ; Thu, 2 Dec 2010 08:32:04 -0800 (PST) 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.583, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 V7vTxYcy7ARl for ; Thu, 2 Dec 2010 08:31:34 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5E1F528C1A0 for ; Thu, 2 Dec 2010 08:30:42 -0800 (PST) Received: by vws7 with SMTP id 7so3333858vws.31 for ; Thu, 02 Dec 2010 08:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=GnlrViHBOqoTkXB6zy5dIgOcH9EIY4uqwOlPQ107Znk=; b=L5v0Qc+uR4Tk3JfF6ez6h0ATnMpA8nmv2ce6miyh96q+zlmoAY3pNpecIfzmG/9IDL V/yowPhAatnbkfb0Hc8RidSOHNGU//HXOWX+XmPVZKz54P5achdhTk23Imy4MGlkJWNW DQSWjSJCGHgMla5qwm9hxHLKLCXGZuUAkw4JI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=PP5KGVVls2L3umTjt1ncuSxF1jef/c7Fc2gsUYfNcNbQx470CnTtjsux+GdAMURBSn co9e7oPwPtlBVGQOtRyF8NNr9RuvtXUiY1ePwU1HIU/9qKVTYHkV05uY5f7v2BwamqlH sUiMxDD6MTwnfmw26F+Z26/iW6LHmI0rvMpUg= Received: by 10.229.220.78 with SMTP id hx14mr233809qcb.13.1291307412545; Thu, 02 Dec 2010 08:30:12 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.13.194 with HTTP; Thu, 2 Dec 2010 08:29:52 -0800 (PST) In-Reply-To: <014101cb8e09$497befa0$dc73cee0$@com> References: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> <066.6f4fbea26c0f0b2beb3be88808ad2f58@tools.ietf.org> <0562357F-90DE-48B0-832A-4868E2C7BF60@tzi.org> <014101cb8e09$497befa0$dc73cee0$@com> From: "Angelo P. Castellani" Date: Thu, 2 Dec 2010 17:29:52 +0100 X-Google-Sender-Auth: aJyB2y-yk-j8YSFOx8B3mpihTf0 Message-ID: To: Linyi Tian Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nicola Bui , Constrained RESTful Environments WG , Klaus Hartke Subject: Re: [core] Closing coap #53 (new): Token length X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 16:32:05 -0000 +1 I fully agree with you, usefulness and/or use case for increasing the token length is still not clear to me. A. On Sat, Nov 27, 2010 at 09:01, Linyi Tian wrote: > Hi, All > > I need some clarification for the token discussion. (sorry for missed the > call). > > 1. Did we decide to put state into token and extend the usage for the tok= en? > 2. If Token is only used as correlation for deferred message, the current > length (2 bytes) maybe enough. > 3. If we want to use token for storing state, what is the use case? > > I believe before we make a decision we need to understand in which scenar= io > we want to use this mechanism. > > Cheers, > Linyi > >>>-----Original Message----- >>>From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >>>Angelo P. Castellani >>>Sent: Friday, November 26, 2010 4:23 PM >>>To: Carsten Bormann >>>Cc: Nicola Bui; Klaus Hartke; Constrained RESTful Environments WG >>>Subject: Re: [core] Closing coap #53 (new): Token length >>> >>>PROS: >>>a) you can put more information inside the token >>> >>>CONS: >>>a) soft state information in a CoAP server for every request requires >>>8 bytes for token option, dynamic memory allocation is usually not >>>done in these devices, especially for small data objects... so if 8 is >>>the max, it will also be the allocated size >>>b) matching a request by doing a search can be more complex (64-bit >>>comparisons are more complex than 16-bit comparisons, especially >>>because a lot of these devices have 16bit MCUs like MSP430) >>> >>>If Token is still to be used for *request/response matching* purposes >>>the Pros aren't valuable, because I hardly imagine a 64-bit space of >>>concurrent requests... If we have advantages in that size, the Cons >>>can be handled and accepted because we obtain a benefit in having it >>>that big. >>> >>>In my opinion Token with 8 bytes makes sense only if someone want to >>>stuff some information in it (state), so it will be something similar >>>to a reverse Cookie for CoAP. >>> >>>I currently cannot think any valid reason to believe that stuffing >>>state in the server is the right approach in a REST protocol, please >>>point me to some valid case if I'm wrong. >>> >>>In HTTP server stateless operation is always preserved, to handle >>>"stateful" sessions of interaction Cookies have been introduced: >>>preserving server stateless operation, but allowing to build stateful >>>applications! >>> >>>Can we move to a Cookie approach? >>> >>>Letting the server define the "Token", and the client store it? >>> >>>There are a number of advantages in this: >>>i) stateless server operation >>>ii) HTTP compatibility/mapping >>>iii) if the response has to be deferred, the server can send an ACK >>>and a Cookie. The client can request again, or the server can send a >>>new response with the same Cookie? >>> >>>Regards, >>>Angelo >>> >>>On Thu, Nov 25, 2010 at 23:48, Carsten Bormann wrote: >>>> On Nov 25, 2010, at 18:13, core issue tracker wrote: >>>> >>>>> There is agreement that 0 to 8 bytes is the right size. >>>> >>>> Small clarification: There was agreement about this in Wednesday's pho= ne >>>call. =A0But we have to validate this on the list. >>>> Unless there is new discussion on the mailing list within the next wee= k, > we'll >>>consider this issue done. >>>> >>>> Gruesse, Carsten >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>_______________________________________________ >>>core mailing list >>>core@ietf.org >>>https://www.ietf.org/mailman/listinfo/core > > From trac@tools.ietf.org Thu Dec 2 13:25: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 837873A697E for ; Thu, 2 Dec 2010 13:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 ALFACLFyM5HI for ; Thu, 2 Dec 2010 13:25:10 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D0F673A6359 for ; Thu, 2 Dec 2010 13:25:01 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGfN-0004tM-3l; Thu, 02 Dec 2010 13:26:13 -0800 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: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Thu, 02 Dec 2010 21:26:12 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/77#comment:1 Message-ID: <062.83e167ccf4fd0475d837fd0a6ce0c7de@tools.ietf.org> References: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <053.9ea9efc3dcb9be1a7f2b477e72d5fadd@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #77 (new): Response code semantics 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, 02 Dec 2010 21:25:19 -0000 #77: Response code semantics Changes (by zach@…): * owner: zach@… => hartke@… -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: enhancement | Status: new Priority: major | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:26: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 1A0033A67A3 for ; Thu, 2 Dec 2010 13:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 QtUUy00fI7uK for ; Thu, 2 Dec 2010 13:26:22 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6EE583A6359 for ; Thu, 2 Dec 2010 13:26:21 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGgi-0006FQ-GZ; Thu, 02 Dec 2010 13:27:36 -0800 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: Thu, 02 Dec 2010 21:27:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/87#comment:1 Message-ID: <060.f1ee2f64b29db1926ded6502f3aee5f6@tools.ietf.org> References: <051.eeb8059d1ae7e95d8ee7a5d799dbefa1@tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <051.eeb8059d1ae7e95d8ee7a5d799dbefa1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #87 (new): DTLS section fixes 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, 02 Dec 2010 21:26:24 -0000 #87: DTLS section fixes Changes (by zach@…): * owner: => cabo@… * milestone: coap-03 => -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… Type: defect | Status: new Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:27:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F06A3A67A3 for ; Thu, 2 Dec 2010 13:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 0Cd3OiKrdw9E for ; Thu, 2 Dec 2010 13:27:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B89053A6359 for ; Thu, 2 Dec 2010 13:27:51 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGiB-0007xe-7n; Thu, 02 Dec 2010 13:29:07 -0800 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: Thu, 02 Dec 2010 21:29:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/54#comment:1 Message-ID: <066.3954771268e67c389f01d0361351c4a6@tools.ietf.org> References: <057.c99f346c5afd3fa73502ae8c72aadce9@tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <057.c99f346c5afd3fa73502ae8c72aadce9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #54 (new): IPsec and multicast 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, 02 Dec 2010 21:27:54 -0000 #54: IPsec and multicast Changes (by zach@…): * owner: => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:28:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDD03A697E for ; Thu, 2 Dec 2010 13:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 pXyY-0RaRUi9 for ; Thu, 2 Dec 2010 13:28:24 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7081B3A6359 for ; Thu, 2 Dec 2010 13:28:24 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGih-0000ky-Km; Thu, 02 Dec 2010 13:29:39 -0800 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: Thu, 02 Dec 2010 21:29:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/58#comment:1 Message-ID: <066.13c26810c7d9fb9df3e494fbb1d3b658@tools.ietf.org> References: <057.c926cbbf08febeb5dad3f2eec7273279@tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <057.c926cbbf08febeb5dad3f2eec7273279@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #58 (new): Define trust model 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, 02 Dec 2010 21:28:25 -0000 #58: Define trust model Changes (by zach@…): * owner: => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:29:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6A43A67B1 for ; Thu, 2 Dec 2010 13:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 ED1VZMMdHtwO for ; Thu, 2 Dec 2010 13:29:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7B5FF3A67A3 for ; Thu, 2 Dec 2010 13:29:11 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGjS-0002DD-Jf; Thu, 02 Dec 2010 13:30:26 -0800 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: Thu, 02 Dec 2010 21:30:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/61#comment:1 Message-ID: <066.77d8c9679ef424300ee75f3cf67d8d2a@tools.ietf.org> References: <057.e4cc3beda4c24f32f37d2786e56a309d@tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <057.e4cc3beda4c24f32f37d2786e56a309d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #61 (new): Cross-protocol attacks 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, 02 Dec 2010 21:29:12 -0000 #61: Cross-protocol attacks Changes (by zach@…): * owner: => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:29:55 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A6E3A67AD for ; Thu, 2 Dec 2010 13:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 4vSRczB8Ma-n for ; Thu, 2 Dec 2010 13:29:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EA72B3A67A3 for ; Thu, 2 Dec 2010 13:29:54 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGkB-0005NL-6u; Thu, 02 Dec 2010 13:31:11 -0800 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, 02 Dec 2010 21:31:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/63#comment:1 Message-ID: <066.e3e3533c92847b111760d553c17ec146@tools.ietf.org> References: <057.0bb67d2c41ff89e249108086d44ce3e4@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <057.0bb67d2c41ff89e249108086d44ce3e4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #63 (new): Verify all syncronous and asyncronous interactions 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, 02 Dec 2010 21:29:55 -0000 #63: Verify all syncronous and asyncronous interactions Changes (by zach@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:30:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847463A67A3 for ; Thu, 2 Dec 2010 13:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 PraSfoCpgpj3 for ; Thu, 2 Dec 2010 13:30:52 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D2DCD3A6359 for ; Thu, 2 Dec 2010 13:30:52 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGl5-0002bF-Kd; Thu, 02 Dec 2010 13:32:08 -0800 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: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Thu, 02 Dec 2010 21:32:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/71#comment:1 Message-ID: <062.5e650631b15844890a7c1a07ee855af2@tools.ietf.org> References: <053.57a7428f32de33ba4221270bca8ca168@tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <053.57a7428f32de33ba4221270bca8ca168@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #71 (new): Terminology section X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:30:53 -0000 #71: Terminology section Changes (by zach@…): * owner: zach@… => hartke@… -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:32:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930AA3A67AD for ; Thu, 2 Dec 2010 13:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 OZfyG20Orq-Z for ; Thu, 2 Dec 2010 13:32:27 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6900F3A6359 for ; Thu, 2 Dec 2010 13:32:27 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGmc-0007Uq-I5; Thu, 02 Dec 2010 13:33:42 -0800 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: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Thu, 02 Dec 2010 21:33:42 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/80#comment:2 Message-ID: <066.648fe683a0d3fc2997a186ba3a615492@tools.ietf.org> References: <057.92cfec853763e811014fc69193f53889@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <057.92cfec853763e811014fc69193f53889@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #80 (new): IANA section X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:32:28 -0000 #80: IANA section Changes (by zach@…): * owner: zach@… => hartke@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:34:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF1C3A67AD for ; Thu, 2 Dec 2010 13:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 5LCqi+-lIj7G for ; Thu, 2 Dec 2010 13:34:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6F4FE3A6359 for ; Thu, 2 Dec 2010 13:34:05 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGoC-0003ug-Pz; Thu, 02 Dec 2010 13:35:20 -0800 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: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Thu, 02 Dec 2010 21:35:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/86#comment:1 Message-ID: <062.d0d278dd73dead035a0b45876e00a6cd@tools.ietf.org> References: <053.c7f8bd862113c8c3e12141c8288869b9@tools.ietf.org> X-Trac-Ticket-ID: 86 In-Reply-To: <053.c7f8bd862113c8c3e12141c8288869b9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #86 (new): Response code numbering 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, 02 Dec 2010 21:34:07 -0000 #86: Response code numbering Changes (by zach@…): * owner: => hartke@… -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:34: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 810983A697E for ; Thu, 2 Dec 2010 13:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 KBmqXL8++p+U for ; Thu, 2 Dec 2010 13:34:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 49F633A67AD for ; Thu, 2 Dec 2010 13:34:50 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGow-0004hX-NL; Thu, 02 Dec 2010 13:36:06 -0800 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, 02 Dec 2010 21:36:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/28#comment:2 Message-ID: <066.97cebc3577f94d65c29ccbbc92e1e2eb@tools.ietf.org> References: <057.548fe514a79c88899d8aba947024686a@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <057.548fe514a79c88899d8aba947024686a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #28 (new): Clarification on retransmission X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:34:52 -0000 #28: Clarification on retransmission Changes (by zach@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:35:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90163A69B4 for ; Thu, 2 Dec 2010 13:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 R60OHQfdPdQ4 for ; Thu, 2 Dec 2010 13:35:22 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3C82E3A67AD for ; Thu, 2 Dec 2010 13:35:22 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGpM-0005Jb-EU; Thu, 02 Dec 2010 13:36:32 -0800 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, 02 Dec 2010 21:36:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/29#comment:1 Message-ID: <066.8a0f7dcaeeddfdd5f8c34b67766a4bd5@tools.ietf.org> References: <057.720c77c10dfd79dc738e07ea839f5bcb@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <057.720c77c10dfd79dc738e07ea839f5bcb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #29 (new): Error in Section 2.1.2. example text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:35:24 -0000 #29: Error in Section 2.1.2. example text Changes (by zach@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:36: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 1352C3A697E for ; Thu, 2 Dec 2010 13:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 gbahWXQZIskw for ; Thu, 2 Dec 2010 13:35:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 32A043A6407 for ; Thu, 2 Dec 2010 13:35:58 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGq2-0006OF-8R; Thu, 02 Dec 2010 13:37:14 -0800 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, 02 Dec 2010 21:37:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/31#comment:1 Message-ID: <066.6c806c9161065d5a49a3f4e55bf37e6b@tools.ietf.org> References: <057.e71925e7e803bcac7a02717afdb67a8f@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <057.e71925e7e803bcac7a02717afdb67a8f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #31 (new): Variable unsigned integer definition X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:36:01 -0000 #31: Variable unsigned integer definition Changes (by zach@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:36:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42FB3A67B1 for ; Thu, 2 Dec 2010 13:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 51m9CdAsYuPZ for ; Thu, 2 Dec 2010 13:36:38 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 357063A6407 for ; Thu, 2 Dec 2010 13:36:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGqf-0007aJ-N6; Thu, 02 Dec 2010 13:37:53 -0800 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: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Thu, 02 Dec 2010 21:37:52 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/50#comment:2 Message-ID: <066.72dacc1b90cb7e300f67479298bd4bdb@tools.ietf.org> References: <057.5388bf9ad1647d65c4eca0123ed73ff3@tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <057.5388bf9ad1647d65c4eca0123ed73ff3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #50 (new): Human readable error payloads 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, 02 Dec 2010 21:36:39 -0000 #50: Human readable error payloads Changes (by zach@…): * owner: => hartke@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:37: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 0B3AE3A69F6 for ; Thu, 2 Dec 2010 13:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 2sgtDETsc4vE for ; Thu, 2 Dec 2010 13:37:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2C5F83A69FB for ; Thu, 2 Dec 2010 13:37:29 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGrU-0001O0-WC; Thu, 02 Dec 2010 13:38:45 -0800 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, 02 Dec 2010 21:38:41 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/51#comment:1 Message-ID: <066.9715c786d30be37e77d45c8b12c0d383@tools.ietf.org> References: <057.4b7183120354df949e6f1eceb1905167@tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <057.4b7183120354df949e6f1eceb1905167@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #51 (new): Section 2 organization 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, 02 Dec 2010 21:37:30 -0000 #51: Section 2 organization Changes (by zach@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:38: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 AFE6B3A69B5 for ; Thu, 2 Dec 2010 13:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 W-dDZTQMZopj for ; Thu, 2 Dec 2010 13:38:12 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6C4893A69B4 for ; Thu, 2 Dec 2010 13:38:11 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGsA-0002BL-6X; Thu, 02 Dec 2010 13:39:26 -0800 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: Thu, 02 Dec 2010 21:39:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/55#comment:4 Message-ID: <066.4f95b234e334d7e2275a352405656ac6@tools.ietf.org> References: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <057.cbcb8082fb49a1a254def976b454a663@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #55 (new): AES-CCM vs. AES-CBC 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, 02 Dec 2010 21:38:17 -0000 #55: AES-CCM vs. AES-CBC Changes (by zach@…): * owner: => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:39:02 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4983A6452 for ; Thu, 2 Dec 2010 13:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 l2ILGzAefL+i for ; Thu, 2 Dec 2010 13:38:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D59CA3A659C for ; Thu, 2 Dec 2010 13:38:53 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGsr-0003ZH-Ck; Thu, 02 Dec 2010 13:40:09 -0800 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: Thu, 02 Dec 2010 21:40:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/56#comment:2 Message-ID: <066.0fa7b52859d755b6c3e386178c9ceafc@tools.ietf.org> References: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN 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, 02 Dec 2010 21:39:02 -0000 #56: Distinguishing DTLS, CoAP and STUN Changes (by zach@…): * owner: => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:39:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0DD3A659C for ; Thu, 2 Dec 2010 13:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 Ddtth8zpKJVn for ; Thu, 2 Dec 2010 13:39:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 807E43A69F6 for ; Thu, 2 Dec 2010 13:39:29 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGtQ-0004Oe-BP; Thu, 02 Dec 2010 13:40:45 -0800 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: Thu, 02 Dec 2010 21:40:44 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/59#comment:1 Message-ID: <066.625734b409c1fa17592baed082537faf@tools.ietf.org> References: <057.cbf0bd75bba0dd710f209966e4d26782@tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <057.cbf0bd75bba0dd710f209966e4d26782@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #59 (new): Assumed device capabilities 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, 02 Dec 2010 21:39:34 -0000 #59: Assumed device capabilities Changes (by zach@…): * owner: => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: task | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:40: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 E26623A6452 for ; Thu, 2 Dec 2010 13:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 5FBk78iWv-eR for ; Thu, 2 Dec 2010 13:40:33 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 234B63A6359 for ; Thu, 2 Dec 2010 13:40:33 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGuS-0006bt-LE; Thu, 02 Dec 2010 13:41:48 -0800 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, hartke@tzi.org X-Trac-Project: core Date: Thu, 02 Dec 2010 21:41:48 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/53#comment:2 Message-ID: <066.b5f41a61d28df31fe5bb03b9f42b9044@tools.ietf.org> References: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <057.3c2c33e201209462cb9746082696f761@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #53 (new): Token length 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, 02 Dec 2010 21:40:34 -0000 #53: Token length Changes (by zach@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:41:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185E43A69F8 for ; Thu, 2 Dec 2010 13:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 tBRWKTt2tH-v for ; Thu, 2 Dec 2010 13:41:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6401E3A69F7 for ; Thu, 2 Dec 2010 13:41:03 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGux-000858-GY; Thu, 02 Dec 2010 13:42:19 -0800 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, 02 Dec 2010 21:42:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/52#comment:1 Message-ID: <066.c3ddfde75771c2f52f448aa53166b400@tools.ietf.org> References: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:41:04 -0000 #52: How strict to make POST definition? Changes (by zach@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Thu Dec 2 13:41:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F7C3A69F8 for ; Thu, 2 Dec 2010 13:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 Byoxaalvy6Vv for ; Thu, 2 Dec 2010 13:41:33 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8ED893A6452 for ; Thu, 2 Dec 2010 13:41:33 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POGvR-0001Kn-Vd; Thu, 02 Dec 2010 13:42:50 -0800 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, 02 Dec 2010 21:42:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/30#comment:1 Message-ID: <066.f0c8f9f0823aaea6938e61946b341413@tools.ietf.org> References: <057.95e09aa7bf9ef22eefecd576ea57db61@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <057.95e09aa7bf9ef22eefecd576ea57db61@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #30 (new): Max-Age 0-4 bytes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:41:34 -0000 #30: Max-Age 0-4 bytes Changes (by zach@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From zach@sensinode.com Thu Dec 2 13:44: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 980113A69DA for ; Thu, 2 Dec 2010 13:44:12 -0800 (PST) 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=[AWL=0.000, 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 xe6pBEfCuwkh for ; Thu, 2 Dec 2010 13:44:10 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 638AC3A6452 for ; Thu, 2 Dec 2010 13:44:10 -0800 (PST) Received: from [192.168.1.5] (line-6257.dyn.kponet.fi [85.29.70.200]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oB2LjKJB004423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 2 Dec 2010 23:45:21 +0200 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-101--513488631; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 2 Dec 2010 23:45:23 +0200 Message-Id: <3AD52525-791A-4760-9DFF-FFB848EE0352@sensinode.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Ignore the last 28 messages... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:44:12 -0000 --Apple-Mail-101--513488631 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was simply assigning tickets to people as we are working on getting = coap-04 updates done.=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-101--513488631 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIwMjIxNDUy NFowIwYJKoZIhvcNAQkEMRYEFJczXb/iS1fhVLfP/7Bc0869oilpMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAGndvgqyR3SOTE0Etf0BTQQDc52n6EOO6UdqfubxX32gL3baCcxlFsR9 H9kxkMvVUf1ziK0s6cYTC166taO5bjEmJ3PwCXVByFQV0tefZivR1f2iY9bPIvTTRElwme/8mde6 esoTIXmfyiFGkd+A1ZiKtOj39hy6OOoFRnCxaDsxmHC9uEtJP7L2IXu3ppA5Ywv0jUnPkC1+sutS 72oMzQxMK0wdA0CGCNJqrJoqt9elGQzsu0ad21pA0VHSqZ1fwwXDeL7dTAUtC+beq+wA+r8kDZDq 2ViHu9UiOEBxK4WyuZy5lY3nUPo30NLOzXlTvRHIAb7YOa0xTerg4UNnzA4AAAAAAAA= --Apple-Mail-101--513488631-- From fluffy@cisco.com Thu Dec 2 14:21: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 649AC3A67B7 for ; Thu, 2 Dec 2010 14:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 RRBgdXHy+5Ov for ; Thu, 2 Dec 2010 14:21:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 85E1E3A63EB for ; Thu, 2 Dec 2010 14:21:51 -0800 (PST) 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: AvsEAE+r90yrRN+J/2dsb2JhbACjLXGoJZsShUcEhF6GCYMRgnI X-IronPort-AV: E=Sophos;i="4.59,289,1288569600"; d="scan'208";a="629804334" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2010 22:23:07 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oB2MN6DD004680; Thu, 2 Dec 2010 22:23:07 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <860443.93182.qm@web52204.mail.re2.yahoo.com> Date: Thu, 2 Dec 2010 15:23:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1AEB5C5F-2925-4187-BE00-89542C53C3CF@cisco.com> References: <860443.93182.qm@web52204.mail.re2.yahoo.com> To: dogan yazar X-Mailer: Apple Mail (2.1082) Cc: Thanh Ngoc , core@ietf.org Subject: Re: [core] Help me with CoAP Demo X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 22:21:52 -0000 Is there an open source version in C or C++ that is not GPL? On Nov 22, 2010, at 3:10 AM, dogan yazar wrote: > There is a COAP implementation in the upcoming version of Contiki = (version 2.5). There is also a REST layer written on top of it to ease = the development of RESTful applications. >=20 > Regards > Dogan Yazar >=20 > From: Thanh Ngoc > To: core@ietf.org > Sent: Mon, November 22, 2010 2:13:01 AM > Subject: [core] Help me with CoAP Demo >=20 > Dear evey one, >=20 > now i am starting with CoAP and have to make a demo. >=20 > do you know where i should start ? and does it have any demo is = available for CoAP (in tinyos or contiki). >=20 > could you give me some guide for CoAP Demo? >=20 > thank you very much, >=20 >=20 > Ngoc Thanh >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Thu Dec 2 14:29:36 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DECA93A67A8 for ; Thu, 2 Dec 2010 14:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.565 X-Spam-Level: X-Spam-Status: No, score=-110.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 KX1UUqoQ9rnQ for ; Thu, 2 Dec 2010 14:29:35 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0CCE43A6778 for ; Thu, 2 Dec 2010 14:29:35 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPOs90yrR7H+/2dsb2JhbACjLnGoFpsUhUcEhF6GCYMR X-IronPort-AV: E=Sophos;i="4.59,289,1288569600"; d="scan'208";a="296561788" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2010 22:30:51 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB2MUnZ1012187; Thu, 2 Dec 2010 22:30:50 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Thu, 2 Dec 2010 15:31:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3604E90C-C3EF-4A79-9117-0A8C2B28D41A@cisco.com> References: <057.86ca4d29ed54c1be14e57fe22ff95263@tools.ietf.org> To: Peter Bigot X-Mailer: Apple Mail (2.1082) Cc: core Subject: Re: [core] coap #56 (new): Distinguishing DTLS, CoAP and STUN X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 22:29:37 -0000 Peter, I personally like the ability to run the secure and none secure = version of a protocol on separate ports. However the transport people = don't like that and are considering changing the IANA policy so you = *have* to use one port. You might want to send the IESG email if you = think that is a bad idea.=20 On Nov 8, 2010, at 10:59 AM, Peter Bigot wrote: > I missed the working group discussion during which it was decided to = carry both secure and non-secure packets over the same protocol on the = same port. >=20 > Following the general URI concept that the authority and hier-part = define the resource, while the scheme defines how you talk to the = resource owner, it is more natural (and consistent with http/https) that = an alternative scheme denote encrypted CoAP traffic. Since the scheme = would be encrypted, use of a distinct port to disambiguate the content = is also more clear. This would also decouple CoAP from being impacted = by evolutionary decisions made within DTLS. >=20 > On what basis was the decision made to diverge from the way it's done = in HTTP? >=20 > Peter >=20 > On Sat, Nov 6, 2010 at 11:15 AM, core issue tracker = wrote: > #56: Distinguishing DTLS, CoAP and STUN >=20 > Section 10.2 need a discussion on how to tell the difference between = DTLS > and CoAP messages as the same port is used by default. >=20 > -- > = --------------------------------+-----------------------------------------= -- > Reporter: zach@=85 | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: coap | Version: > Severity: - | Keywords: > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From kerlyn2001@gmail.com Thu Dec 2 14:42: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 6D0B73A69DD for ; Thu, 2 Dec 2010 14:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 0uW8dIJXOaWX for ; Thu, 2 Dec 2010 14:42:01 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C340C3A69F1 for ; Thu, 2 Dec 2010 14:42:00 -0800 (PST) Received: by gyb13 with SMTP id 13so4941863gyb.31 for ; Thu, 02 Dec 2010 14:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=/PAwntmt0haaxTpGrkW1hzQ8K6n+Lu6p3LcdF61KHLw=; b=ay6UzCQvtDM//Ait2o/Mf7vcSiEwvpbBrWOfxIdamR3vC7CPdniyc07lQHv1VXIFID iRK+vI0YYKsUVsfUXgGIzvk+dm2bOdmFH6gdAJ2j++tQgoSqIDg6P0DcUBhk7F0V3Y76 1wsoThjwNfzd4APEv9WbNzsozib7dfKCMGxrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=BH01dvE8VOGT1TLMLY4hcpjmhRB0U7qAk4c0H4VMaavQH3DSfy/+0OiJQJn0HpEhBK A06rbOTad1vEgR8IHcnFKGeqH6iF7/FpA3hxa+GJyKcxtrvJbHUL8k4WYh7VNYJyJJNm ocgZW+oa/77MiFkrkHtEAeDUMzZmgWr8RbqN8= Received: by 10.150.145.13 with SMTP id s13mr2526147ybd.27.1291329796780; Thu, 02 Dec 2010 14:43:16 -0800 (PST) Received: from [172.16.1.127] (67-133-135-50.dia.static.qwest.net [67.133.135.50]) by mx.google.com with ESMTPS id i2sm614415yha.25.2010.12.02.14.43.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Dec 2010 14:43:15 -0800 (PST) References: <860443.93182.qm@web52204.mail.re2.yahoo.com> <1AEB5C5F-2925-4187-BE00-89542C53C3CF@cisco.com> In-Reply-To: <1AEB5C5F-2925-4187-BE00-89542C53C3CF@cisco.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <71D93D54-7586-417D-BE54-77E9D656AA71@gmail.com> X-Mailer: iPhone Mail (8C148) From: Kerry Lynn Date: Thu, 2 Dec 2010 16:43:11 -0600 To: Cullen Jennings Cc: Thanh Ngoc , "core@ietf.org" Subject: Re: [core] Help me with CoAP Demo X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 22:42:03 -0000 Contiki is modified BSD. Is there a portable (*nix) C or C++ that's not GPL? Sent from my iPhone On Dec 2, 2010, at 4:23 PM, Cullen Jennings wrote: >=20 > Is there an open source version in C or C++ that is not GPL? >=20 > On Nov 22, 2010, at 3:10 AM, dogan yazar wrote: >=20 >> There is a COAP implementation in the upcoming version of Contiki (versio= n 2.5). There is also a REST layer written on top of it to ease the developm= ent of RESTful applications. >>=20 >> Regards >> Dogan Yazar >>=20 >> From: Thanh Ngoc >> To: core@ietf.org >> Sent: Mon, November 22, 2010 2:13:01 AM >> Subject: [core] Help me with CoAP Demo >>=20 >> Dear evey one, >>=20 >> now i am starting with CoAP and have to make a demo. >>=20 >> do you know where i should start ? and does it have any demo is available= for CoAP (in tinyos or contiki). >>=20 >> could you give me some guide for CoAP Demo? >>=20 >> thank you very much, >>=20 >>=20 >> Ngoc Thanh >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac@tools.ietf.org Thu Dec 2 16:30:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872D628C128 for ; Thu, 2 Dec 2010 16:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.009, 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 Et-mWsYQGTuC for ; Thu, 2 Dec 2010 16:30:32 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8EC593A6A20 for ; Thu, 2 Dec 2010 16:30:31 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1POJYy-0004km-5X; Thu, 02 Dec 2010 16:31:48 -0800 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, hartke@tzi.org X-Trac-Project: core Date: Fri, 03 Dec 2010 00:31:48 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/37#comment:1 Message-ID: <066.5c1712e06bb8866b278901787abafaca@tools.ietf.org> References: <057.d76c4fb4eaf8e8db6bc0402562ae16bd@tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <057.d76c4fb4eaf8e8db6bc0402562ae16bd@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] observe #37 (new): Section on complimentary sub/pub REST frameworks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 00:30:37 -0000 #37: Section on complimentary sub/pub REST frameworks Changes (by hartke@…): * owner: hartke@… => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From brian.tridium@gmail.com Sat Dec 4 11:13: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 EB96828C0D0 for ; Sat, 4 Dec 2010 11:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF3Oco7v46-B for ; Sat, 4 Dec 2010 11:12:58 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id DD08728C0CE for ; Sat, 4 Dec 2010 11:12:57 -0800 (PST) Received: by bwz12 with SMTP id 12so10230870bwz.31 for ; Sat, 04 Dec 2010 11:14:17 -0800 (PST) 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=BV+yi1LrXguQddymUGz44/6BvAEf8YRsK+LdR05MA1k=; b=kuCpqPVglLdVanltEVONh6IQbUOUkZoP6IbzEJRd5tTuiAFKnRf7pcIR+IvDJHLh8h TZRfPNfO5vIQgc+4d4Ia0rcCeRkAuYXCtOjVCMlGBwGmRjgydi8TscElKpLoUspRqhxr 1C/NaT9XNgR1ePzFXtVHEVnOoHfF2sjHl1yrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=a3xVCA0NrvfSU0XWBgfKQso+2Oq0kcleTGzwGHtMrwEzG7nEJyFsCo/f6rCeTvJJiV 65mX0qLdgC0RxrxM2y8OxbebK8VoAbwbDyptoC8I3Fy833ejqSfFsOn+x0UrYEg1uTSS BMqcE9Dj/XKRhMeLCQ1UDdgxHQkADiif8AL0Y= MIME-Version: 1.0 Received: by 10.204.75.194 with SMTP id z2mr3962354bkj.132.1291490056912; Sat, 04 Dec 2010 11:14:16 -0800 (PST) Received: by 10.204.80.97 with HTTP; Sat, 4 Dec 2010 11:14:16 -0800 (PST) Date: Sat, 4 Dec 2010 14:14:16 -0500 Message-ID: From: Brian Frank To: core Content-Type: multipart/alternative; boundary=001485f7d7d212bf6b04969a76e0 Subject: [core] Proxy vs Non-Proxy Requests (#82) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 19:13:00 -0000 --001485f7d7d212bf6b04969a76e0 Content-Type: text/plain; charset=ISO-8859-1 Currently the spec requires end-points to examine the Uri-Authority to determine if they request is for itself or a request to be proxied to another server. There as been some discussion about if this is robust enough as tracked by ticket #82. Couple specific problems with current design: - what should non-proxies do with Uri-Authority? are they are they required to check it? - what are the exact semantics to check if a Uri-Authority is yourself? local host, etc issues make this potential non-trivial All the solutions that I can image including those suggested in ticket #82 and others: 1. Use of the Uri-Authority option can only be used for proxy requests; Pros is that is super simple to implement and understand. A non-proxy automatically rejects requests with this option. Proxies immediately know to forward it on if they see this option. Cons is that it doesn't actually allow complex features like virtual hosts (although is that really needed?) 2. Use an alternate, parallel Uri-Authority option such as Proxy-Uri-Authority. Requests to Uri-Authority are assumed to be for end-point itself, requests to Proxy-Uri-Authority are assumed to be another server. Pros is easy for proxies to process. But it leaves open the question of what non-proxy should do with Uri-Authority - just ignore it? Check it? 3. Use additional boolean/marker option such as Request-Proxy. This would paired with Uri-Authority and would imply that authority is not end-point itself. Cons: first off requires an additional byte in message vs option 1 and 2. Second cons is that now proxy has to check for Request-Proxy, then do error checking to ensure Uri-Authority is also specified (assuming that a missing Uri-Authority is an error). Still simple, but doesn't seem quite as elegant as option 1 or 2. 4. Use Uri-Scheme. I've read the discussion and to be honest this makes no sense to me. Why would specifying the scheme as "coap" have anything to do whether the client intended a proxy request? I guess if we had two schemes such as "coap" and "coap-proxy", then I can understand this design. But it doesn't seem as intuitive, efficient, or as robust as 1, 2, or 3. 5. Perform some bitwise shift of method codes. This would work, but doesn't seem intuitive or robust to me personally. 6. Potentially require proxies to be on another port so that all traffic is completely separated. Don't know how this effects constrained IP stacks though? Or security? And is it really a solution, support you have your port configured incorrectly? For simplicity, I would vote for option 1. If you use Uri-Authority option its a proxy request. If you omit it, then its intended as a request to the end-point itself. But maybe that is too simple in which case I would vote for option 2. --001485f7d7d212bf6b04969a76e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Currently the spec requires end-points to examine the Uri-Authority to dete= rmine if they request is for itself or a request to be proxied to another s= erver. =A0There as been some discussion about if this is robust enough as t= racked by ticket #82. =A0Couple specific problems with current design:

=A0=A0- what should non-proxies do with Uri-Authority? =A0are they= are they required to check it?

=A0=A0- what are t= he exact semantics to check if a Uri-Authority is yourself? =A0local host, = etc issues make this potential non-trivial


All the solutions that I can image= including those suggested in ticket #82 and others:

1. =A0Use of the Uri-Authority option can only be used for proxy request= s; Pros is that is super simple to implement=A0and understand. =A0A non-pro= xy automatically rejects requests with this option. =A0Proxies immediately = know to forward it on if they see this option. =A0Cons is that it doesn'= ;t actually allow complex features like virtual hosts (although is that rea= lly needed?)

2. Use an alternate, parallel Uri-Authority option such= as Proxy-Uri-Authority. =A0Requests to Uri-Authority are assumed to be for= end-point itself, requests to Proxy-Uri-Authority are assumed to be anothe= r server. =A0Pros is easy for proxies to process. =A0But it leaves open the= question of what non-proxy should do with Uri-Authority - just ignore it? = =A0Check it?

3. Use additional boolean/marker option such as Request= -Proxy. =A0This would paired with Uri-Authority and would imply that author= ity is not end-point itself. =A0Cons: first off requires an additional byte= in message vs option 1 and 2. =A0Second cons is that now proxy has to chec= k for Request-Proxy, then do error checking to ensure Uri-Authority is also= specified (assuming that a missing Uri-Authority is an error). =A0Still si= mple, but doesn't seem quite as elegant as option 1 or 2.

4. Use Uri-Scheme. =A0I've read the discussion and = to be honest this makes no sense to me. =A0Why would specifying the scheme = as "coap" have anything to do whether the client intended a proxy= request? =A0I guess if we had two schemes such as "coap" and &qu= ot;coap-proxy", then I can understand this design. =A0But it doesn'= ;t seem as intuitive, efficient, or as robust as 1, 2, or 3.

5. Perform some bitwise shift of method codes. =A0This = would work, but doesn't seem intuitive or robust to me personally.

6. Potentially require proxies to be on another port s= o that all traffic is completely separated. Don't know how this effects= constrained IP stacks though? =A0Or security? =A0And is it really a soluti= on, support you have your port configured incorrectly?

For simplicity, I would vote for option 1. If you use U= ri-Authority option its a proxy request. =A0If you omit it, then its intend= ed as a request to the end-point itself. =A0But maybe that is too simple in= which case I would vote for option 2.

--001485f7d7d212bf6b04969a76e0-- From brian.tridium@gmail.com Sat Dec 4 12:02: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 978423A699E for ; Sat, 4 Dec 2010 12:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MFB68qYXMp4 for ; Sat, 4 Dec 2010 12:02:21 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id CC0073A6993 for ; Sat, 4 Dec 2010 12:02:20 -0800 (PST) Received: by bwz12 with SMTP id 12so10254072bwz.31 for ; Sat, 04 Dec 2010 12:03:40 -0800 (PST) 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=rQ9o0T3ZiA1ysp29AS/MqCg9d/RBs8uCzL2xwRXftTE=; b=WwEePD+zXZ9wIGF4tNJmabv2nGqQhudkb5Hzc4NZvnwd/t+4eLIQ8228THSAZ2ONVX rQdmkvcvoBqvch2i89yLpMYBwAT7v25bBMmzUgIPfaeSbtjWm1NfhQmlcx7/li+e8Vqn qs06l/x/9baIiewF4jaZ/2FVc6fuwKZv4hbU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KuBqeeBh5xSKYazhWZ1rb6ozQfYotM4wkHaIqszXbiCGcnxafWO3Dy4o9uBiX0WtqH vJpVxhK2wpBUtPAciAs2fYldYl1LZp3tdyCxZPpTssjA6xH+aYdb5iNp24EtoyHU8t8v 2LyiQ1/A2VFfbfVtXCce3JebCs4bZlH7oSFm0= MIME-Version: 1.0 Received: by 10.204.102.2 with SMTP id e2mr3926244bko.24.1291493020111; Sat, 04 Dec 2010 12:03:40 -0800 (PST) Received: by 10.204.80.97 with HTTP; Sat, 4 Dec 2010 12:03:40 -0800 (PST) Date: Sat, 4 Dec 2010 15:03:40 -0500 Message-ID: From: Brian Frank To: core Content-Type: multipart/alternative; boundary=001636c5a258b1929004969b2694 Subject: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 20:02:22 -0000 --001636c5a258b1929004969b2694 Content-Type: text/plain; charset=ISO-8859-1 Sometimes I think it is useful to just take a step back and reevaluate exactly what we are trying to accomplish. Personally, I got involved in the CoAP effort for one primary reason: I believe that every piece of information associated with the Internet of Things should have a URI. Not just any URI, but an "http" URI - so that smart devices could integrate with the web at large. So for me the whole idea of CoAP is not really that desirable, rather it is a necessary evil. It is necessitated by the fact that HTTP doesn't run over constrained networks and in constrained devices: - number of bytes on the wire matters greatly (http text headers too verbose) - network bandwidth, network characteristics, and device processing/memory make TCP hard - sleeping nodes are big pain I realize that not everyone necessarily shares my philosophy, but to me personally the whole point of CoAP is to seamless integrate to HTTP so that the Internet of Things can integrate into the web at large. If you share this philosophy, then probably one of the most critical aspects of CoAP is the CoaP/HTTP mapping Section 7. Up to this point we (me included) have sort of been treating this section as the thing to do last after all the important stuff has been done. But after reviewing a lot of the tickets and outstanding issues, I think we have been putting the cart before the horse so to speak. HTTP is the end-goal, CoAP is just the means to the end. I personally would like to see every feature of CoAP evaluated in the context of its HTTP mapping. Just to review a couple of the biggies: Proxy Terminology (#72) ================== This is what started me on this whole thought process. The more I started thinking about terminology, the more I started thinking that the most important proxy/gateway is the HTTP-to-CoAP functionality. And I really didn't see this discussed on the mailing list (perhaps I missed it though). The key idea is that "proxy" could mean different things: - there is the actual IP address where you direct requests to (explicit proxies, interception proxies, reverse proxies etc) - there is caching semantics (which is both a proxy issue *and* a end-client issue) - there is actual protocol translations HTTP->CoAP and CoAP->HTTP (and potentially others like XMPP, etc) - there are potentially MIME content translations (for example XML <-> compress XML/binary as it goes thru HTTP <-> CoAP) I am not sure we can really tackle proxy terminology without tackling some of the latter issues which haven't really received much discussion. Caching Semantics (#78) =================== It may just be a process/document structure issue. But I suspect that the technique we use to tackle section 7 and how we cross reference RFC 2616 will actually dictate how we should fix caching to do more cross reference of the HTTP spec itself. Deferred Requests ============== I understand how we got here. But it doesn't really fit the simple HTTP req/res model. So I think this discussion has to include the HTTP side of things. Pub/Sub Observations ================= I know there are application tricks to do this with HTTP, but how will we map it? I personally am finding this requirement is creating a lot of complexity. Furthermore based on my experience, the state management of the current design is too complicated and has too much overhead to implement in constrained devices. I just want to raise the flag that I worry about this one. I'd love to see it, but I am more than happy to live with a solid, simple req/res model that works seamlessly with HTTP. A couple key take away points: - are we actually all on the same page that seamless HTTP integration is a critical aspect of this effort? - assuming yes to the above, then should we make HTTP mapping the top priority and see how everything else fits into that? Just my random thoughts... Brian --001636c5a258b1929004969b2694 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sometimes I think it is useful to just take a step back and reevaluate exac= tly what we are trying to accomplish.

Personally, I got = involved in the CoAP effort for one primary reason: I believe that every pi= ece of information associated with the Internet of Things should have a URI= . =A0Not just any URI, but an "http" URI - so that smart devices = could=A0integrate=A0with the web at large. =A0So for me the whole idea of C= oAP is not really that desirable, rather it is a necessary evil. =A0It is n= ecessitated by the fact that HTTP doesn't run over=A0constrained=A0netw= orks and in=A0constrained=A0devices:

=A0=A0- number of bytes on the wire matters greatly (ht= tp text headers too verbose)

=A0=A0- network=A0ban= dwidth, network characteristics, and device processing/memory make TCP hard=

=A0=A0- sleeping nodes are big pain

I realize that not everyone necessarily shares my philosophy, but to = me=A0personally=A0the whole point of CoAP is to seamless integrate to HTTP = so that the Internet of Things can integrate into the web at large. =A0

If you share this philosophy, then probably one of the = most critical aspects of CoAP is the CoaP/HTTP mapping Section 7. =A0Up to = this point we (me included) have sort of been treating this section as the = thing to do last after all the important stuff has been done. =A0But after = reviewing a lot of the tickets and outstanding issues, I think we have been= putting the cart before the horse so to speak. =A0HTTP is the end-goal, Co= AP is just the means to the end. =A0I personally would like to see every fe= ature of CoAP evaluated in the context of its HTTP mapping.

Just to review a couple of the biggies:

<= /div>
Proxy Terminology (#72)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
This is what started me on this whole th= ought process. =A0The more I started thinking about terminology, the more I= started thinking that the most important proxy/gateway is the HTTP-to-CoAP= functionality. =A0And I really didn't see this discussed on the mailin= g list (perhaps I missed it though). The key idea is that "proxy"= could mean different things:

=A0=A0- there is the actual IP address where you direct= requests to (explicit proxies, interception proxies, reverse proxies etc)<= /div>

=A0=A0- there is caching semantics (which is both = a proxy issue *and* a end-client issue)

=A0=A0- there is actual protocol translations HTTP->= CoAP and CoAP->HTTP (and potentially others like XMPP, etc)
=A0=A0- there are potentially MIME content translations (for e= xample XML <-> compress XML/binary as it goes thru HTTP <-> CoA= P)

I am not sure we can really tackle proxy=A0terminology= =A0without tackling some of the latter issues which haven't really rece= ived much discussion.

Caching Semantics (#78)=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
It= may just be a process/document structure issue. =A0But I suspect that the = technique we use to tackle section 7 and how we cross reference RFC 2616 wi= ll actually dictate how we should fix caching to do more cross reference of= the HTTP spec itself.

Deferred Requests
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
I understand how we got here. =A0But = it doesn't really fit the simple HTTP req/res model. =A0So I think this= discussion has to include the HTTP side of things.

Pub/Sub Observations
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
I know there are application tricks t= o do this with HTTP, but how will we map it? =A0I personally am finding thi= s requirement is creating a lot of complexity. =A0Furthermore based on my e= xperience, the state management of the current design is too complicated an= d has too much overhead to implement in constrained devices. =A0I just want= to raise the flag that I worry about this one. =A0I'd love to see it, = but I am more than happy to live with a solid, simple req/res model that wo= rks seamlessly with HTTP.


A couple key take away points:

=A0=A0- are we actually all on the same page that sea= mless HTTP integration is a critical aspect of this effort?

<= /div>
=A0=A0- assuming yes to the above, then should we make HTTP mapping th= e top priority and see how everything else fits into that?

Just my random thoughts...
Brian

--001636c5a258b1929004969b2694-- From pab@peoplepowerco.com Sun Dec 5 09:48: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 D91C728C0F5 for ; Sun, 5 Dec 2010 09:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLhp7upePf1I for ; Sun, 5 Dec 2010 09:48:04 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 114F63A6A7A for ; Sun, 5 Dec 2010 09:48:03 -0800 (PST) Received: by fxm9 with SMTP id 9so9455244fxm.31 for ; Sun, 05 Dec 2010 09:49:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.101.141 with SMTP id c13mr4580208fao.118.1291571363305; Sun, 05 Dec 2010 09:49:23 -0800 (PST) Received: by 10.223.93.195 with HTTP; Sun, 5 Dec 2010 09:49:23 -0800 (PST) In-Reply-To: References: Date: Sun, 5 Dec 2010 11:49:23 -0600 Message-ID: From: Peter Bigot To: Brian Frank Content-Type: multipart/alternative; boundary=20cf3054a25f4fd8090496ad647b Cc: core Subject: Re: [core] Proxy vs Non-Proxy Requests (#82) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 17:48:06 -0000 --20cf3054a25f4fd8090496ad647b Content-Type: text/plain; charset=ISO-8859-1 I think section 2.5.2 of CoAP-03 is pretty clear on how non-proxies should treat Uri-Authority, except that it does indeed fail to say whether the end-point must check it when it's present. My assumption was "yes", just as a node that supports only a single resource should still check whether the Uri-Path is the expected value and not simply return that resource regardless of the request URI. How the end-point determines whether the authority is itself is outside CoAP's scope, as it tends to depend on things like DNS, availability at the CoAP level of the node's assigned addresses, and implementation-specific configuration data. We had discussed this in detail perhaps six months ago, and I thought came to a reasonable compromise that allowed those who felt the authority was unnecessary to omit it, while those who disagreed could still make use of it. I thought the resolution of #82 was to be a new (critical?) option, perhaps Proxy-This, indicating that the client expected the request to be proxied. I don't see how one gets more simple than that. I do wish that the inclination to overload the presence or absence of URI-related options with information not relevant to identifying the resource would not be so tempting. To do this complicates ones mental model of what those options mean, and can prevent application of CoAP in architectures and solutions not yet considered by the working group. URIs serve a valuable role in a variety of protocols and web technologies, and in my opinion it's short-sighted to assume that our current understanding of their application in constrained domains is adequate to justify restricting how they can be used by changing what they are or mean. Peter On Sat, Dec 4, 2010 at 1:14 PM, Brian Frank wrote: > Currently the spec requires end-points to examine the Uri-Authority to > determine if they request is for itself or a request to be proxied to > another server. There as been some discussion about if this is robust > enough as tracked by ticket #82. Couple specific problems with current > design: > > - what should non-proxies do with Uri-Authority? are they are they > required to check it? > > - what are the exact semantics to check if a Uri-Authority is yourself? > local host, etc issues make this potential non-trivial > > > All the solutions that I can image including those suggested in ticket #82 > and others: > > 1. Use of the Uri-Authority option can only be used for proxy requests; > Pros is that is super simple to implement and understand. A non-proxy > automatically rejects requests with this option. Proxies immediately know > to forward it on if they see this option. Cons is that it doesn't actually > allow complex features like virtual hosts (although is that really needed?) > > 2. Use an alternate, parallel Uri-Authority option such as > Proxy-Uri-Authority. Requests to Uri-Authority are assumed to be for > end-point itself, requests to Proxy-Uri-Authority are assumed to be another > server. Pros is easy for proxies to process. But it leaves open the > question of what non-proxy should do with Uri-Authority - just ignore it? > Check it? > > 3. Use additional boolean/marker option such as Request-Proxy. This would > paired with Uri-Authority and would imply that authority is not end-point > itself. Cons: first off requires an additional byte in message vs option 1 > and 2. Second cons is that now proxy has to check for Request-Proxy, then > do error checking to ensure Uri-Authority is also specified (assuming that a > missing Uri-Authority is an error). Still simple, but doesn't seem quite as > elegant as option 1 or 2. > > 4. Use Uri-Scheme. I've read the discussion and to be honest this makes no > sense to me. Why would specifying the scheme as "coap" have anything to do > whether the client intended a proxy request? I guess if we had two schemes > such as "coap" and "coap-proxy", then I can understand this design. But it > doesn't seem as intuitive, efficient, or as robust as 1, 2, or 3. > > 5. Perform some bitwise shift of method codes. This would work, but > doesn't seem intuitive or robust to me personally. > > 6. Potentially require proxies to be on another port so that all traffic is > completely separated. Don't know how this effects constrained IP stacks > though? Or security? And is it really a solution, support you have your > port configured incorrectly? > > For simplicity, I would vote for option 1. If you use Uri-Authority option > its a proxy request. If you omit it, then its intended as a request to the > end-point itself. But maybe that is too simple in which case I would vote > for option 2. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --20cf3054a25f4fd8090496ad647b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think section 2.5.2 of CoAP-03 is pretty clear on how non-proxies should = treat Uri-Authority, except that it does indeed fail to say whether the end= -point must check it when it's present.=A0 My assumption was "yes&= quot;, just as a node that supports only a single resource should still che= ck whether the Uri-Path is the expected value and not simply return that re= source regardless of the request URI.=A0 How the end-point determines wheth= er the authority is itself is outside CoAP's scope, as it tends to depe= nd on things like DNS, availability at the CoAP level of the node's ass= igned addresses, and implementation-specific configuration data.=A0 We had = discussed this in detail perhaps six months ago, and I thought came to a re= asonable compromise that allowed those who felt the authority was unnecessa= ry to omit it, while those who disagreed could still make use of it.

I thought the resolution of #82 was to be a new (critical?) option, per= haps Proxy-This, indicating that the client expected the request to be prox= ied.=A0 I don't see how one gets more simple than that.

I do wis= h that the inclination to overload the presence or absence of URI-related o= ptions with information not relevant to identifying the resource would not = be so tempting.=A0 To do this complicates ones mental model of what those o= ptions mean, and can prevent application of CoAP in architectures and solut= ions not yet considered by the working group.=A0 URIs serve a valuable role= in a variety of protocols and web technologies, and in my opinion it's= short-sighted to assume that our current understanding of their applicatio= n in constrained domains is adequate to justify restricting how they can be= used by changing what they are or mean.

Peter

On Sat, Dec 4, 2010 at 1:14 PM,= Brian Frank <brian.tridium@gmail.com> wrote:
Currently the spec requires end-points to examine the Uri-Authority to dete= rmine if they request is for itself or a request to be proxied to another s= erver. =A0There as been some discussion about if this is robust enough as t= racked by ticket #82. =A0Couple specific problems with current design:

=A0=A0- what should non-proxies do with Uri-Authority? =A0are they= are they required to check it?

=A0=A0- what are t= he exact semantics to check if a Uri-Authority is yourself? =A0local host, = etc issues make this potential non-trivial


All the solutions that I can image= including those suggested in ticket #82 and others:

1. =A0Use of the Uri-Authority option can only be used for proxy request= s; Pros is that is super simple to implement=A0and understand. =A0A non-pro= xy automatically rejects requests with this option. =A0Proxies immediately = know to forward it on if they see this option. =A0Cons is that it doesn'= ;t actually allow complex features like virtual hosts (although is that rea= lly needed?)

2. Use an alternate, parallel Uri-Authority option such= as Proxy-Uri-Authority. =A0Requests to Uri-Authority are assumed to be for= end-point itself, requests to Proxy-Uri-Authority are assumed to be anothe= r server. =A0Pros is easy for proxies to process. =A0But it leaves open the= question of what non-proxy should do with Uri-Authority - just ignore it? = =A0Check it?

3. Use additional boolean/marker option such as Request= -Proxy. =A0This would paired with Uri-Authority and would imply that author= ity is not end-point itself. =A0Cons: first off requires an additional byte= in message vs option 1 and 2. =A0Second cons is that now proxy has to chec= k for Request-Proxy, then do error checking to ensure Uri-Authority is also= specified (assuming that a missing Uri-Authority is an error). =A0Still si= mple, but doesn't seem quite as elegant as option 1 or 2.

4. Use Uri-Scheme. =A0I've read the discussion and = to be honest this makes no sense to me. =A0Why would specifying the scheme = as "coap" have anything to do whether the client intended a proxy= request? =A0I guess if we had two schemes such as "coap" and &qu= ot;coap-proxy", then I can understand this design. =A0But it doesn'= ;t seem as intuitive, efficient, or as robust as 1, 2, or 3.

5. Perform some bitwise shift of method codes. =A0This = would work, but doesn't seem intuitive or robust to me personally.

6. Potentially require proxies to be on another port s= o that all traffic is completely separated. Don't know how this effects= constrained IP stacks though? =A0Or security? =A0And is it really a soluti= on, support you have your port configured incorrectly?

For simplicity, I would vote for option 1. If you use U= ri-Authority option its a proxy request. =A0If you omit it, then its intend= ed as a request to the end-point itself. =A0But maybe that is too simple in= which case I would vote for option 2.


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


--20cf3054a25f4fd8090496ad647b-- From pab@peoplepowerco.com Sun Dec 5 09:48: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 6F4A328C115 for ; Sun, 5 Dec 2010 09:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBBMK1O7vdqz for ; Sun, 5 Dec 2010 09:48:08 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 56E6B28C114 for ; Sun, 5 Dec 2010 09:48:07 -0800 (PST) Received: by mail-fx0-f44.google.com with SMTP id 9so9455244fxm.31 for ; Sun, 05 Dec 2010 09:49:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.79.66 with SMTP id o2mr976770fak.80.1291571368747; Sun, 05 Dec 2010 09:49:28 -0800 (PST) Received: by 10.223.93.195 with HTTP; Sun, 5 Dec 2010 09:49:28 -0800 (PST) In-Reply-To: References: Date: Sun, 5 Dec 2010 11:49:28 -0600 Message-ID: From: Peter Bigot To: Brian Frank Content-Type: multipart/alternative; boundary=90e6ba10a783a2e4f40496ad645d Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 17:48:09 -0000 --90e6ba10a783a2e4f40496ad645d Content-Type: text/plain; charset=ISO-8859-1 I share your desire to have all resources associated with a URI, but not the further step that assumes all those URIs should be accessible by HTTP. I think the scheme portion of the URI serves a critical role in allowing domain-specific protocols to be used where appropriate. A specific example will be for resources involved in group communications, where the client/server point-to-point model of HTTP is simply a non-starter. Beyond that, I agree with your assessment that CoAP's integration with HTTP is far too complex to bolt on as an afterthought. I had thought to use REST, rather than simply HTTP, as the primary architectural model for CoAP, but found there to be insufficient agreement on what that meant or the degree to which it should drive the solution. (With that approach, it would be a matter of expressing REST operations in HTTP and vice-versa, a technique that's reasonably well understood.) I think the group had already determined that CoAP was not going to be a transliteration of HTTP. Consequently, I believe HTTP/CoAP integration can be made seamless but that the effort involved is really a separate initiative will include things like how to translate group operations into something meaningfully expressible by HTTP operations. This will necessarily involve transformation, aggregation, and separation of the resource representations, an issue that is currently completely unaddressed. Peter On Sat, Dec 4, 2010 at 2:03 PM, Brian Frank wrote: > Sometimes I think it is useful to just take a step back and reevaluate > exactly what we are trying to accomplish. > > Personally, I got involved in the CoAP effort for one primary reason: I > believe that every piece of information associated with the Internet of > Things should have a URI. Not just any URI, but an "http" URI - so that > smart devices could integrate with the web at large. So for me the whole > idea of CoAP is not really that desirable, rather it is a necessary evil. > It is necessitated by the fact that HTTP doesn't run > over constrained networks and in constrained devices: > > - number of bytes on the wire matters greatly (http text headers too > verbose) > > - network bandwidth, network characteristics, and device > processing/memory make TCP hard > > - sleeping nodes are big pain > > I realize that not everyone necessarily shares my philosophy, but to > me personally the whole point of CoAP is to seamless integrate to HTTP so > that the Internet of Things can integrate into the web at large. > > If you share this philosophy, then probably one of the most critical > aspects of CoAP is the CoaP/HTTP mapping Section 7. Up to this point we (me > included) have sort of been treating this section as the thing to do last > after all the important stuff has been done. But after reviewing a lot of > the tickets and outstanding issues, I think we have been putting the cart > before the horse so to speak. HTTP is the end-goal, CoAP is just the means > to the end. I personally would like to see every feature of CoAP evaluated > in the context of its HTTP mapping. > > Just to review a couple of the biggies: > > Proxy Terminology (#72) > ================== > This is what started me on this whole thought process. The more I started > thinking about terminology, the more I started thinking that the most > important proxy/gateway is the HTTP-to-CoAP functionality. And I really > didn't see this discussed on the mailing list (perhaps I missed it though). > The key idea is that "proxy" could mean different things: > > - there is the actual IP address where you direct requests to (explicit > proxies, interception proxies, reverse proxies etc) > > - there is caching semantics (which is both a proxy issue *and* a > end-client issue) > > - there is actual protocol translations HTTP->CoAP and CoAP->HTTP (and > potentially others like XMPP, etc) > > - there are potentially MIME content translations (for example XML <-> > compress XML/binary as it goes thru HTTP <-> CoAP) > > I am not sure we can really tackle proxy terminology without tackling some > of the latter issues which haven't really received much discussion. > > Caching Semantics (#78) > =================== > It may just be a process/document structure issue. But I suspect that the > technique we use to tackle section 7 and how we cross reference RFC 2616 > will actually dictate how we should fix caching to do more cross reference > of the HTTP spec itself. > > Deferred Requests > ============== > I understand how we got here. But it doesn't really fit the simple HTTP > req/res model. So I think this discussion has to include the HTTP side of > things. > > Pub/Sub Observations > ================= > I know there are application tricks to do this with HTTP, but how will we > map it? I personally am finding this requirement is creating a lot of > complexity. Furthermore based on my experience, the state management of the > current design is too complicated and has too much overhead to implement in > constrained devices. I just want to raise the flag that I worry about this > one. I'd love to see it, but I am more than happy to live with a solid, > simple req/res model that works seamlessly with HTTP. > > > A couple key take away points: > > - are we actually all on the same page that seamless HTTP integration is > a critical aspect of this effort? > > - assuming yes to the above, then should we make HTTP mapping the top > priority and see how everything else fits into that? > > Just my random thoughts... > Brian > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --90e6ba10a783a2e4f40496ad645d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I share your desire to have all resources associated with a URI, but not th= e further step that assumes all those URIs should be accessible by HTTP.=A0= I think the scheme portion of the URI serves a critical role in allowing d= omain-specific protocols to be used where appropriate.=A0 A specific exampl= e will be for resources involved in group communications, where the client/= server point-to-point model of HTTP is simply a non-starter.

Beyond that, I agree with your assessment that CoAP's integration w= ith HTTP is far too complex to bolt on as an afterthought.=A0 I had thought= to use REST, rather than simply HTTP, as the primary architectural model f= or CoAP, but found there to be insufficient agreement on what that meant or= the degree to which it should drive the solution.=A0 (With that approach, = it would be a matter of expressing REST operations in HTTP and vice-versa, = a technique that's reasonably well understood.)

I think the group had already determined that CoAP was not going to be = a transliteration of HTTP.=A0 Consequently, I believe HTTP/CoAP integration= can be made seamless but that the effort involved is really a separate ini= tiative will include things like how to translate group operations into som= ething meaningfully expressible by HTTP operations.=A0 This will necessaril= y involve transformation, aggregation, and separation of the resource repre= sentations, an issue that is currently completely unaddressed.

Peter

On Sat, Dec 4, 2010 at 2:03 PM,= Brian Frank <brian.tridium@gmail.com> wrote:
Sometimes I think it is useful to just take a step back and reevaluate exac= tly what we are trying to accomplish.

Personally, I got = involved in the CoAP effort for one primary reason: I believe that every pi= ece of information associated with the Internet of Things should have a URI= . =A0Not just any URI, but an "http" URI - so that smart devices = could=A0integrate=A0with the web at large. =A0So for me the whole idea of C= oAP is not really that desirable, rather it is a necessary evil. =A0It is n= ecessitated by the fact that HTTP doesn't run over=A0constrained=A0netw= orks and in=A0constrained=A0devices:

=A0=A0- number of bytes on the wire matters greatly (ht= tp text headers too verbose)

=A0=A0- network=A0ban= dwidth, network characteristics, and device processing/memory make TCP hard=

=A0=A0- sleeping nodes are big pain

I realize that not everyone necessarily shares my philosophy, but to = me=A0personally=A0the whole point of CoAP is to seamless integrate to HTTP = so that the Internet of Things can integrate into the web at large. =A0

If you share this philosophy, then probably one of the = most critical aspects of CoAP is the CoaP/HTTP mapping Section 7. =A0Up to = this point we (me included) have sort of been treating this section as the = thing to do last after all the important stuff has been done. =A0But after = reviewing a lot of the tickets and outstanding issues, I think we have been= putting the cart before the horse so to speak. =A0HTTP is the end-goal, Co= AP is just the means to the end. =A0I personally would like to see every fe= ature of CoAP evaluated in the context of its HTTP mapping.

Just to review a couple of the biggies:

<= /div>
Proxy Terminology (#72)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
This is what started me on this whole th= ought process. =A0The more I started thinking about terminology, the more I= started thinking that the most important proxy/gateway is the HTTP-to-CoAP= functionality. =A0And I really didn't see this discussed on the mailin= g list (perhaps I missed it though). The key idea is that "proxy"= could mean different things:

=A0=A0- there is the actual IP address where you direct= requests to (explicit proxies, interception proxies, reverse proxies etc)<= /div>

=A0=A0- there is caching semantics (which is both = a proxy issue *and* a end-client issue)

=A0=A0- there is actual protocol translations HTTP->= CoAP and CoAP->HTTP (and potentially others like XMPP, etc)
=A0=A0- there are potentially MIME content translations (for e= xample XML <-> compress XML/binary as it goes thru HTTP <-> CoA= P)

I am not sure we can really tackle proxy=A0terminology= =A0without tackling some of the latter issues which haven't really rece= ived much discussion.

Caching Semantics (#78)=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
It= may just be a process/document structure issue. =A0But I suspect that the = technique we use to tackle section 7 and how we cross reference RFC 2616 wi= ll actually dictate how we should fix caching to do more cross reference of= the HTTP spec itself.

Deferred Requests
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
I understand how we got here. =A0But = it doesn't really fit the simple HTTP req/res model. =A0So I think this= discussion has to include the HTTP side of things.

Pub/Sub Observations
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
I know there are application tricks t= o do this with HTTP, but how will we map it? =A0I personally am finding thi= s requirement is creating a lot of complexity. =A0Furthermore based on my e= xperience, the state management of the current design is too complicated an= d has too much overhead to implement in constrained devices. =A0I just want= to raise the flag that I worry about this one. =A0I'd love to see it, = but I am more than happy to live with a solid, simple req/res model that wo= rks seamlessly with HTTP.


A couple key take away points:

=A0=A0- are we actually all on the same page that sea= mless HTTP integration is a critical aspect of this effort?

=A0=A0- assuming yes to the above, then should we make HTTP mapping th= e top priority and see how everything else fits into that?

Just my random thoughts...
Brian


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


--90e6ba10a783a2e4f40496ad645d-- From angelo.castellani@gmail.com Mon Dec 6 00:17: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 5F1813A6A27 for ; Mon, 6 Dec 2010 00:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 HZywRlrY38pC for ; Mon, 6 Dec 2010 00:17:06 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id BCAB33A69FD for ; Mon, 6 Dec 2010 00:17:05 -0800 (PST) Received: by qwg5 with SMTP id 5so10925957qwg.31 for ; Mon, 06 Dec 2010 00:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Id2ZWr86U3gRAb1wF7u3A+nZnv4gjJratMWvBvHDYH4=; b=XTGj63Dd2JfNlQpj/09OHXybPjhmDrqcL/ufHoHzpNsOrQf+J2TyHVdDKmytT6k/e6 dRNLVOSJNLbwVXU3ZiXNkQy6aSOL1QykWRXdu0VUUUvoDL+3Shf53klV4yJYlg0ZSEP4 pT7iar+YQl5fnstE+Sf6XsgBH1DRjXB3v7faw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=DzfKKvKV2GJ85Sp1/J1qiBJKm7eav4pBW2mHfzwpUysBr6o7BDbKTf8z0UbuVIWuRp SSLiUesAQENv+lEh2TnH6wDnUaSq+/ENpGcGMtR1gFLBtumSLUnWOsfbZPyws5y9So/u Xd1oAqlbPhbScnMXnll3VXTCtyVTRoKO3p+uw= Received: by 10.229.185.7 with SMTP id cm7mr4209844qcb.89.1291623508557; Mon, 06 Dec 2010 00:18:28 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.13.194 with HTTP; Mon, 6 Dec 2010 00:18:08 -0800 (PST) In-Reply-To: References: From: "Angelo P. Castellani" Date: Mon, 6 Dec 2010 09:18:08 +0100 X-Google-Sender-Auth: 9nkzdfsc3DoVO3JZ9F9d_Om6G50 Message-ID: To: Brian Frank Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 08:17:07 -0000 Thanks Brian for your message, I share completely your point(s). To me also seems that CoAP design is too much oriented on the design of a stand-alone application protocol, instead of focusing on REST and HTTP mapping as a top priority. Observe in my opinion has been designed as an efficient stand-alone mechanism, leaving in the to do list the mapping to/from HTTP; this should not be the design procedure and could lead to (big?) problems when integrating with the "legacy" web. CoAP priority should be the design of efficient *and* HTTP mappable solutions; if the proposed solution maps hardly to HTTP, introduces state (requiring a stateful entity to be correctly mapped) or can't work in both directions CoAP->HTTP and HTTP->CoAP, then it should be reconsidered. Angelo On Sat, Dec 4, 2010 at 21:03, Brian Frank wrote: > Sometimes I think it is useful to just take a step back and reevaluate > exactly what we are trying to accomplish. > Personally, I got involved in the CoAP effort for one primary reason: I > believe that every piece of information associated with the Internet of > Things should have a URI. =A0Not just any URI, but an "http" URI - so tha= t > smart devices could=A0integrate=A0with the web at large. =A0So for me the= whole > idea of CoAP is not really that desirable, rather it is a necessary evil. > =A0It is necessitated by the fact that HTTP doesn't run > over=A0constrained=A0networks and in=A0constrained=A0devices: > =A0=A0- number of bytes on the wire matters greatly (http text headers to= o > verbose) > =A0=A0- network=A0bandwidth, network characteristics, and device processi= ng/memory > make TCP hard > =A0=A0- sleeping nodes are big pain > I realize that not everyone necessarily shares my philosophy, but to > me=A0personally=A0the whole point of CoAP is to seamless integrate to HTT= P so > that the Internet of Things can integrate into the web at large. > If you share this philosophy, then probably one of the most critical aspe= cts > of CoAP is the CoaP/HTTP mapping Section 7. =A0Up to this point we (me > included) have sort of been treating this section as the thing to do last > after all the important stuff has been done. =A0But after reviewing a lot= of > the tickets and outstanding issues, I think we have been putting the cart > before the horse so to speak. =A0HTTP is the end-goal, CoAP is just the m= eans > to the end. =A0I personally would like to see every feature of CoAP evalu= ated > in the context of its HTTP mapping. > Just to review a couple of the biggies: > Proxy Terminology (#72) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This is what started me on this whole thought process. =A0The more I star= ted > thinking about terminology, the more I started thinking that the most > important proxy/gateway is the HTTP-to-CoAP functionality. =A0And I reall= y > didn't see this discussed on the mailing list (perhaps I missed it though= ). > The key idea is that "proxy" could mean different things: > =A0=A0- there is the actual IP address where you direct requests to (expl= icit > proxies, interception proxies, reverse proxies etc) > =A0=A0- there is caching semantics (which is both a proxy issue *and* a > end-client issue) > =A0=A0- there is actual protocol translations HTTP->CoAP and CoAP->HTTP (= and > potentially others like XMPP, etc) > =A0=A0- there are potentially MIME content translations (for example XML = <-> > compress XML/binary as it goes thru HTTP <-> CoAP) > I am not sure we can really tackle proxy=A0terminology=A0without tackling= some > of the latter issues which haven't really received much discussion. > Caching Semantics (#78) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > It may just be a process/document structure issue. =A0But I suspect that = the > technique we use to tackle section 7 and how we cross reference RFC 2616 > will actually dictate how we should fix caching to do more cross referenc= e > of the HTTP spec itself. > Deferred Requests > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I understand how we got here. =A0But it doesn't really fit the simple HTT= P > req/res model. =A0So I think this discussion has to include the HTTP side= of > things. > Pub/Sub Observations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I know there are application tricks to do this with HTTP, but how will we > map it? =A0I personally am finding this requirement is creating a lot of > complexity. =A0Furthermore based on my experience, the state management o= f the > current design is too complicated and has too much overhead to implement = in > constrained devices. =A0I just want to raise the flag that I worry about = this > one. =A0I'd love to see it, but I am more than happy to live with a solid= , > simple req/res model that works seamlessly with HTTP. > > A couple key take away points: > =A0=A0- are we actually all on the same page that seamless HTTP integrati= on is a > critical aspect of this effort? > =A0=A0- assuming yes to the above, then should we make HTTP mapping the t= op > priority and see how everything else fits into that? > Just my random thoughts... > Brian > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From ynir@checkpoint.com Mon Dec 6 02:35: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 6A5013A6A5A for ; Mon, 6 Dec 2010 02:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=1.482, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqaYEmUcgDcj for ; Mon, 6 Dec 2010 02:35:04 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 619423A69AC for ; Mon, 6 Dec 2010 02:35:03 -0800 (PST) X-CheckPoint: {4CFCBCA9-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oB6AaMO2002704; Mon, 6 Dec 2010 12:36:22 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 6 Dec 2010 12:36:23 +0200 From: Yoav Nir To: "Angelo P. Castellani" Date: Mon, 6 Dec 2010 12:36:23 +0200 Thread-Topic: [core] CoAP and HTTP - Philosophy and Direction Thread-Index: AcuVMWza1dmbTEueRj62rIk0DspNqw== Message-ID: <0EBAC7F4-C42A-4B2D-BC14-420A03F3A5A2@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 10:35:06 -0000 I don't think the problem is in the design of Observe. The problem is with = the requirement. In some cases, observers require immediate notification. P= icture a light switch that has been flipped, with the light fixture observi= ng.=20 The best that HTTP can provide is either polling ("are you on now? No. (ti= me passes) Are you on now? No. (time passes) Are you on now? Yes.") or else= long connections waiting for a response ("Are you being turned on? (time p= asses) Timeout. Are you being turned on? (less time passes) Yes."). Both ar= e crude and inefficient bastardizations of HTTP. I don't see a way to map that observer required behavior to HTTP. Yoav On Dec 6, 2010, at 10:18 AM, Angelo P. Castellani wrote: > Thanks Brian for your message, I share completely your point(s). >=20 > To me also seems that CoAP design is too much oriented on the design > of a stand-alone application protocol, instead of focusing on REST and > HTTP mapping as a top priority. >=20 > Observe in my opinion has been designed as an efficient stand-alone > mechanism, leaving in the to do list the mapping to/from HTTP; this > should not be the design procedure and could lead to (big?) problems > when integrating with the "legacy" web. >=20 > CoAP priority should be the design of efficient *and* HTTP mappable > solutions; if the proposed solution maps hardly to HTTP, introduces > state (requiring a stateful entity to be correctly mapped) or can't > work in both directions CoAP->HTTP and HTTP->CoAP, then it should be > reconsidered. >=20 > Angelo >=20 > On Sat, Dec 4, 2010 at 21:03, Brian Frank wrote= : >> Sometimes I think it is useful to just take a step back and reevaluate >> exactly what we are trying to accomplish. >> Personally, I got involved in the CoAP effort for one primary reason: I >> believe that every piece of information associated with the Internet of >> Things should have a URI. Not just any URI, but an "http" URI - so that >> smart devices could integrate with the web at large. So for me the whol= e >> idea of CoAP is not really that desirable, rather it is a necessary evil= . >> It is necessitated by the fact that HTTP doesn't run >> over constrained networks and in constrained devices: >> - number of bytes on the wire matters greatly (http text headers too >> verbose) >> - network bandwidth, network characteristics, and device processing/me= mory >> make TCP hard >> - sleeping nodes are big pain >> I realize that not everyone necessarily shares my philosophy, but to >> me personally the whole point of CoAP is to seamless integrate to HTTP s= o >> that the Internet of Things can integrate into the web at large. >> If you share this philosophy, then probably one of the most critical asp= ects >> of CoAP is the CoaP/HTTP mapping Section 7. Up to this point we (me >> included) have sort of been treating this section as the thing to do las= t >> after all the important stuff has been done. But after reviewing a lot = of >> the tickets and outstanding issues, I think we have been putting the car= t >> before the horse so to speak. HTTP is the end-goal, CoAP is just the me= ans >> to the end. I personally would like to see every feature of CoAP evalua= ted >> in the context of its HTTP mapping. >> Just to review a couple of the biggies: >> Proxy Terminology (#72) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> This is what started me on this whole thought process. The more I start= ed >> thinking about terminology, the more I started thinking that the most >> important proxy/gateway is the HTTP-to-CoAP functionality. And I really >> didn't see this discussed on the mailing list (perhaps I missed it thoug= h). >> The key idea is that "proxy" could mean different things: >> - there is the actual IP address where you direct requests to (explici= t >> proxies, interception proxies, reverse proxies etc) >> - there is caching semantics (which is both a proxy issue *and* a >> end-client issue) >> - there is actual protocol translations HTTP->CoAP and CoAP->HTTP (and >> potentially others like XMPP, etc) >> - there are potentially MIME content translations (for example XML <-> >> compress XML/binary as it goes thru HTTP <-> CoAP) >> I am not sure we can really tackle proxy terminology without tackling so= me >> of the latter issues which haven't really received much discussion. >> Caching Semantics (#78) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> It may just be a process/document structure issue. But I suspect that t= he >> technique we use to tackle section 7 and how we cross reference RFC 2616 >> will actually dictate how we should fix caching to do more cross referen= ce >> of the HTTP spec itself. >> Deferred Requests >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> I understand how we got here. But it doesn't really fit the simple HTTP >> req/res model. So I think this discussion has to include the HTTP side = of >> things. >> Pub/Sub Observations >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> I know there are application tricks to do this with HTTP, but how will w= e >> map it? I personally am finding this requirement is creating a lot of >> complexity. Furthermore based on my experience, the state management of= the >> current design is too complicated and has too much overhead to implement= in >> constrained devices. I just want to raise the flag that I worry about t= his >> one. I'd love to see it, but I am more than happy to live with a solid, >> simple req/res model that works seamlessly with HTTP. >>=20 >> A couple key take away points: >> - are we actually all on the same page that seamless HTTP integration = is a >> critical aspect of this effort? >> - assuming yes to the above, then should we make HTTP mapping the top >> priority and see how everything else fits into that? >> Just my random thoughts... >> Brian >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > Scanned by Check Point Total Security Gateway. From gc355804@ohio.edu Mon Dec 6 03:24:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399973A6A56 for ; Mon, 6 Dec 2010 03:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMynlzOQGbY7 for ; Mon, 6 Dec 2010 03:23:31 -0800 (PST) Received: from mx2.oit.ohio.edu (mx2.oit.ohio.edu [132.235.51.19]) by core3.amsl.com (Postfix) with ESMTP id D720A3A69E7 for ; Mon, 6 Dec 2010 03:23:26 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ9W/EyE6who/2dsb2JhbACjMXG0H4hmhUkEhF+GD4YF X-IronPort-AV: E=Sophos;i="4.59,305,1288584000"; d="scan'208";a="65542005" Received: from exht1.oit.ohio.edu ([132.235.8.104]) by smtpout2.oit.ohio.edu with ESMTP; 06 Dec 2010 06:24:48 -0500 Received: from exmail1.ohio.edu ([10.13.10.1]) by exht1.oit.ohio.edu ([10.13.10.31]) with mapi; Mon, 6 Dec 2010 06:24:47 -0500 From: "Clark, Gilbert" To: "Angelo P. Castellani" , Brian Frank Date: Mon, 6 Dec 2010 06:24:46 -0500 Thread-Topic: [core] CoAP and HTTP - Philosophy and Direction Thread-Index: AcuVHi0LXysiaGwXSbyROm0Q37o3JQAGgKWZ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 11:24:23 -0000 For what it's worth: I agree that supporting some subset of HTTP is important, but I'd be wary o= f designing CoAP around its HTTP support. CoAP networks are likely to have very different characteristics from networks running HTTP; CoAP should therefore be primarily designed to operate best in the environment into which it's being deployed. Also, I see the state required by OBSERVE as being part of an HTTP server's cache. In this case, though, instead of caching content, the server is caching a GET and passing back data to tell the client what the GET is called so it knows when it gets a response; the server has the option of telling the client it won't do so, so no state is actually *forced* onto th= e server; instead, the server is choosing to cache the request with the understanding that supporting 10K of cached GET requests could go a long wa= y to minimizing power / CPU utilization in the long run. Additionally, HTTP assumes that the server involved in a connection will be up the majority of the time. I'd imagine that, for many constrained devices, the opposite would be true: they'd be sleeping for the vast majority of their lifetime, which means that timing a poll to hit one of th= e brief periods the device was awake would be difficult at best. An alternative to this approach might be forcing the device to wake every time it was polled, which seems like it might be pretty bad for networks where power and / or network utilization was a constraint. I agree that there's probably not a good way to make OBSERVE visible to an HTTP client; at the same time, I also feel like a 1:1 mapping should not be required as long as the CoAP <--> HTTP translator is able to support a viable subset of HTTP. For example, in the case of OBSERVE, the CoAP <--> HTTP translator could actually fulfill HTTP GET requests by OBSERVE-ing the resource specified in the GET, and caching content between updates. This would minimize load on the CoAP network while maintaining HTTP compatibility, and HTTP wouldn't necessarily have to know the translator wa= s cheating and using OBSERVE. /$0.02 --Gilbert Clark On 12/6/10 3:18 AM, "Angelo P. Castellani" wrote: > Thanks Brian for your message, I share completely your point(s). >=20 > To me also seems that CoAP design is too much oriented on the design > of a stand-alone application protocol, instead of focusing on REST and > HTTP mapping as a top priority. >=20 > Observe in my opinion has been designed as an efficient stand-alone > mechanism, leaving in the to do list the mapping to/from HTTP; this > should not be the design procedure and could lead to (big?) problems > when integrating with the "legacy" web. >=20 > CoAP priority should be the design of efficient *and* HTTP mappable > solutions; if the proposed solution maps hardly to HTTP, introduces > state (requiring a stateful entity to be correctly mapped) or can't > work in both directions CoAP->HTTP and HTTP->CoAP, then it should be > reconsidered. >=20 > Angelo >=20 > On Sat, Dec 4, 2010 at 21:03, Brian Frank wrote= : >> Sometimes I think it is useful to just take a step back and reevaluate >> exactly what we are trying to accomplish. >> Personally, I got involved in the CoAP effort for one primary reason: I >> believe that every piece of information associated with the Internet of >> Things should have a URI. =A0Not just any URI, but an "http" URI - so th= at >> smart devices could=A0integrate=A0with the web at large. =A0So for me th= e whole >> idea of CoAP is not really that desirable, rather it is a necessary evil= . >> =A0It is necessitated by the fact that HTTP doesn't run >> over=A0constrained=A0networks and in=A0constrained=A0devices: >> =A0=A0- number of bytes on the wire matters greatly (http text headers t= oo >> verbose) >> =A0=A0- network=A0bandwidth, network characteristics, and device process= ing/memory >> make TCP hard >> =A0=A0- sleeping nodes are big pain >> I realize that not everyone necessarily shares my philosophy, but to >> me=A0personally=A0the whole point of CoAP is to seamless integrate to HT= TP so >> that the Internet of Things can integrate into the web at large. >> If you share this philosophy, then probably one of the most critical asp= ects >> of CoAP is the CoaP/HTTP mapping Section 7. =A0Up to this point we (me >> included) have sort of been treating this section as the thing to do las= t >> after all the important stuff has been done. =A0But after reviewing a lo= t of >> the tickets and outstanding issues, I think we have been putting the car= t >> before the horse so to speak. =A0HTTP is the end-goal, CoAP is just the = means >> to the end. =A0I personally would like to see every feature of CoAP eval= uated >> in the context of its HTTP mapping. >> Just to review a couple of the biggies: >> Proxy Terminology (#72) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> This is what started me on this whole thought process. =A0The more I sta= rted >> thinking about terminology, the more I started thinking that the most >> important proxy/gateway is the HTTP-to-CoAP functionality. =A0And I real= ly >> didn't see this discussed on the mailing list (perhaps I missed it thoug= h). >> The key idea is that "proxy" could mean different things: >> =A0=A0- there is the actual IP address where you direct requests to (exp= licit >> proxies, interception proxies, reverse proxies etc) >> =A0=A0- there is caching semantics (which is both a proxy issue *and* a >> end-client issue) >> =A0=A0- there is actual protocol translations HTTP->CoAP and CoAP->HTTP = (and >> potentially others like XMPP, etc) >> =A0=A0- there are potentially MIME content translations (for example XML= <-> >> compress XML/binary as it goes thru HTTP <-> CoAP) >> I am not sure we can really tackle proxy=A0terminology=A0without tacklin= g some >> of the latter issues which haven't really received much discussion. >> Caching Semantics (#78) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> It may just be a process/document structure issue. =A0But I suspect that= the >> technique we use to tackle section 7 and how we cross reference RFC 2616 >> will actually dictate how we should fix caching to do more cross referen= ce >> of the HTTP spec itself. >> Deferred Requests >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> I understand how we got here. =A0But it doesn't really fit the simple HT= TP >> req/res model. =A0So I think this discussion has to include the HTTP sid= e of >> things. >> Pub/Sub Observations >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> I know there are application tricks to do this with HTTP, but how will w= e >> map it? =A0I personally am finding this requirement is creating a lot of >> complexity. =A0Furthermore based on my experience, the state management = of the >> current design is too complicated and has too much overhead to implement= in >> constrained devices. =A0I just want to raise the flag that I worry about= this >> one. =A0I'd love to see it, but I am more than happy to live with a soli= d, >> simple req/res model that works seamlessly with HTTP. >>=20 >> A couple key take away points: >> =A0=A0- are we actually all on the same page that seamless HTTP integrat= ion is a >> critical aspect of this effort? >> =A0=A0- assuming yes to the above, then should we make HTTP mapping the = top >> priority and see how everything else fits into that? >> Just my random thoughts... >> Brian >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From ynir@checkpoint.com Mon Dec 6 04:57:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FB43A6778 for ; Mon, 6 Dec 2010 04:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.187 X-Spam-Level: X-Spam-Status: No, score=-9.187 tagged_above=-999 required=5 tests=[AWL=1.412, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5u6iFvbQTXy for ; Mon, 6 Dec 2010 04:57:52 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 46CA13A676A for ; Mon, 6 Dec 2010 04:57:51 -0800 (PST) X-CheckPoint: {4CFCDE21-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oB6CxD5m007334; Mon, 6 Dec 2010 14:59:13 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 6 Dec 2010 14:59:12 +0200 From: Yoav Nir To: "Clark, Gilbert" Date: Mon, 6 Dec 2010 14:59:15 +0200 Thread-Topic: [core] CoAP and HTTP - Philosophy and Direction Thread-Index: AcuVRWFOrO/KwEwbQJm/6sEJAJgsqw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 12:57:53 -0000 I think that would work well. I don't know if the caching proxy defined in = section 5 of CoAP does this, but the proxy can do the OBSERVE with the actu= al server, while the HTTP client can poll the proxy. This is not a 1:1 mapp= ing, but should be close enough. The lamp needs immediate access to the lig= ht switch, so it should use OBSERVE, but a control station that polls the l= ight switches in the building at 10 PM to see which one is still on can rel= y on HTTP. On Dec 6, 2010, at 1:24 PM, Clark, Gilbert wrote: > For what it's worth: >=20 > I agree that supporting some subset of HTTP is important, but I'd be wary= of > designing CoAP around its HTTP support. CoAP networks are likely to have > very different characteristics from networks running HTTP; CoAP should > therefore be primarily designed to operate best in the environment into > which it's being deployed. >=20 > Also, I see the state required by OBSERVE as being part of an HTTP server= 's > cache. In this case, though, instead of caching content, the server is > caching a GET and passing back data to tell the client what the GET is > called so it knows when it gets a response; the server has the option of > telling the client it won't do so, so no state is actually *forced* onto = the > server; instead, the server is choosing to cache the request with the > understanding that supporting 10K of cached GET requests could go a long = way > to minimizing power / CPU utilization in the long run. >=20 > Additionally, HTTP assumes that the server involved in a connection will = be > up the majority of the time. I'd imagine that, for many constrained > devices, the opposite would be true: they'd be sleeping for the vast > majority of their lifetime, which means that timing a poll to hit one of = the > brief periods the device was awake would be difficult at best. An > alternative to this approach might be forcing the device to wake every ti= me > it was polled, which seems like it might be pretty bad for networks where > power and / or network utilization was a constraint. >=20 > I agree that there's probably not a good way to make OBSERVE visible to a= n > HTTP client; at the same time, I also feel like a 1:1 mapping should not = be > required as long as the CoAP <--> HTTP translator is able to support a > viable subset of HTTP. For example, in the case of OBSERVE, the CoAP <--= > > HTTP translator could actually fulfill HTTP GET requests by OBSERVE-ing t= he > resource specified in the GET, and caching content between updates. This > would minimize load on the CoAP network while maintaining HTTP > compatibility, and HTTP wouldn't necessarily have to know the translator = was > cheating and using OBSERVE. >=20 > /$0.02 >=20 > --Gilbert Clark >=20 > On 12/6/10 3:18 AM, "Angelo P. Castellani" wrote: >=20 >> Thanks Brian for your message, I share completely your point(s). >>=20 >> To me also seems that CoAP design is too much oriented on the design >> of a stand-alone application protocol, instead of focusing on REST and >> HTTP mapping as a top priority. >>=20 >> Observe in my opinion has been designed as an efficient stand-alone >> mechanism, leaving in the to do list the mapping to/from HTTP; this >> should not be the design procedure and could lead to (big?) problems >> when integrating with the "legacy" web. >>=20 >> CoAP priority should be the design of efficient *and* HTTP mappable >> solutions; if the proposed solution maps hardly to HTTP, introduces >> state (requiring a stateful entity to be correctly mapped) or can't >> work in both directions CoAP->HTTP and HTTP->CoAP, then it should be >> reconsidered. >>=20 >> Angelo >>=20 >> On Sat, Dec 4, 2010 at 21:03, Brian Frank wrot= e: >>> Sometimes I think it is useful to just take a step back and reevaluate >>> exactly what we are trying to accomplish. >>> Personally, I got involved in the CoAP effort for one primary reason: I >>> believe that every piece of information associated with the Internet of >>> Things should have a URI. Not just any URI, but an "http" URI - so tha= t >>> smart devices could integrate with the web at large. So for me the who= le >>> idea of CoAP is not really that desirable, rather it is a necessary evi= l. >>> It is necessitated by the fact that HTTP doesn't run >>> over constrained networks and in constrained devices: >>> - number of bytes on the wire matters greatly (http text headers too >>> verbose) >>> - network bandwidth, network characteristics, and device processing/m= emory >>> make TCP hard >>> - sleeping nodes are big pain >>> I realize that not everyone necessarily shares my philosophy, but to >>> me personally the whole point of CoAP is to seamless integrate to HTTP = so >>> that the Internet of Things can integrate into the web at large. >>> If you share this philosophy, then probably one of the most critical as= pects >>> of CoAP is the CoaP/HTTP mapping Section 7. Up to this point we (me >>> included) have sort of been treating this section as the thing to do la= st >>> after all the important stuff has been done. But after reviewing a lot= of >>> the tickets and outstanding issues, I think we have been putting the ca= rt >>> before the horse so to speak. HTTP is the end-goal, CoAP is just the m= eans >>> to the end. I personally would like to see every feature of CoAP evalu= ated >>> in the context of its HTTP mapping. >>> Just to review a couple of the biggies: >>> Proxy Terminology (#72) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> This is what started me on this whole thought process. The more I star= ted >>> thinking about terminology, the more I started thinking that the most >>> important proxy/gateway is the HTTP-to-CoAP functionality. And I reall= y >>> didn't see this discussed on the mailing list (perhaps I missed it thou= gh). >>> The key idea is that "proxy" could mean different things: >>> - there is the actual IP address where you direct requests to (explic= it >>> proxies, interception proxies, reverse proxies etc) >>> - there is caching semantics (which is both a proxy issue *and* a >>> end-client issue) >>> - there is actual protocol translations HTTP->CoAP and CoAP->HTTP (an= d >>> potentially others like XMPP, etc) >>> - there are potentially MIME content translations (for example XML <-= > >>> compress XML/binary as it goes thru HTTP <-> CoAP) >>> I am not sure we can really tackle proxy terminology without tackling s= ome >>> of the latter issues which haven't really received much discussion. >>> Caching Semantics (#78) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> It may just be a process/document structure issue. But I suspect that = the >>> technique we use to tackle section 7 and how we cross reference RFC 261= 6 >>> will actually dictate how we should fix caching to do more cross refere= nce >>> of the HTTP spec itself. >>> Deferred Requests >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I understand how we got here. But it doesn't really fit the simple HTT= P >>> req/res model. So I think this discussion has to include the HTTP side= of >>> things. >>> Pub/Sub Observations >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I know there are application tricks to do this with HTTP, but how will = we >>> map it? I personally am finding this requirement is creating a lot of >>> complexity. Furthermore based on my experience, the state management o= f the >>> current design is too complicated and has too much overhead to implemen= t in >>> constrained devices. I just want to raise the flag that I worry about = this >>> one. I'd love to see it, but I am more than happy to live with a solid= , >>> simple req/res model that works seamlessly with HTTP. >>>=20 >>> A couple key take away points: >>> - are we actually all on the same page that seamless HTTP integration= is a >>> critical aspect of this effort? >>> - assuming yes to the above, then should we make HTTP mapping the top >>> priority and see how everything else fits into that? >>> Just my random thoughts... >>> Brian >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > Scanned by Check Point Total Security Gateway. From angelo.castellani@gmail.com Mon Dec 6 09:06:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490273A681D for ; Mon, 6 Dec 2010 09:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_44=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMo-Wa3q9CXX for ; Mon, 6 Dec 2010 09:06:53 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8BE533A6835 for ; Mon, 6 Dec 2010 09:06:52 -0800 (PST) Received: by qwg5 with SMTP id 5so11445060qwg.31 for ; Mon, 06 Dec 2010 09:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=xGZgV0ZDRl2eBTtPLWLEqnwzdx6KNGfXO6a98DGhrjQ=; b=rdXZRdf1ocCW8l3HQ38rwkQTM0FgdNvu0oF7mwTZmQRyAIy721TeysthlwPGkM5Oi0 RpOTEUr/GUwpPIJhUKJou+jp2U2N+vMjcvrmot6q0u9Uze9U74wlhk6LHgz/AjksSTCS zrFd6lKvEOaqf8Yf38I/Ev7jkwBpixTYe4i88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=sgq2thyCLb6RWKdkpWGq1lLQCHJH6aAKn9g0CkJPOa59uDkkIJZgHTIgS+d59i+iq0 +8AmT0LTnoNwLlfumGWEtjZVO0uKYZSX5hC+Ln1QZVm7MyatRobCJWu2jnc9ni6Y4Liz ee2vjkPQXzyOIuZ3XI+J6OyDPBmbRhBiJjQ3s= Received: by 10.229.74.206 with SMTP id v14mr1532301qcj.203.1291655294450; Mon, 06 Dec 2010 09:08:14 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.13.194 with HTTP; Mon, 6 Dec 2010 09:07:54 -0800 (PST) In-Reply-To: <0EBAC7F4-C42A-4B2D-BC14-420A03F3A5A2@checkpoint.com> References: <0EBAC7F4-C42A-4B2D-BC14-420A03F3A5A2@checkpoint.com> From: "Angelo P. Castellani" Date: Mon, 6 Dec 2010 18:07:54 +0100 X-Google-Sender-Auth: d3-f0HoY1wIjzAfpdUCHVkWy148 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 17:06:54 -0000 Yoav, in my opinion there at least two ways to cope better with HTTP, the first is more simple but has minor pros and some cons, the second more ambitious but can lead to some bigger advantages. a aka simple alternative) support HTTP streaming introducing CoAP chunked transfer encoding HTTP supports chunked Transfer-Encoding, through this feature is possible to push data to clients. This mechanism can be ported to CoAP and can be mapped directly to HTTP by an in-the-middle "proxy". Status associated with every notification, which is useful and present in the current design, has to be dropped in HTTP and/or can be present only in CoAP<->CoAP communication. This alternative however doesn't introduce significant advantages over the observe one. Unconvenient state is still present: persistent tcp connections and soft-state during streaming. Moreover could be harder to define how to cache data (single chunks can be cached?). b aka hard/ambitious alternative) only servers can support observations In M2M environments, interactions are expected to be using a peer-to-peer communication fashion. For this reason to realize the subscription functionality, the subscription can be defined as an interaction between resources (so between servers). Every message should be defined in terms of source and destination URI, so that resource A requests resource B to notify its value (on change, every X secs, etc.). Moreover notifications can also carry the status code associated with that particular notification. This kind of mechanism requires the definition of a header in HTTP, however CoAP observe itself to be mapped to HTTP probably requires a Subscription-lifetime header as well. Main advantage is that with this kind of solution, proxy implementors can choose whether to support natively CoAP observe or not, and they can even map it to a long polling or HTTP streaming session. But also is possible to pass-through the proxy without requiring the establishment of state inside it. Moreover proxies can implement policies to redirect incoming subscriptions to a single local proxy-owned subscription. However, as said before, this technique doesn't specify an obliged solution but supports flexibly more message exchanges and so system architectures. CoAP header compression: using Token option Caching: still possible through request caching Security: to be evaluated (some effort may be needed) On Mon, Dec 6, 2010 at 11:36, Yoav Nir wrote: > I don't think the problem is in the design of Observe. The problem is wit= h the requirement. In some cases, observers require immediate notification.= Picture a light switch that has been flipped, with the light fixture obser= ving. > > The best that HTTP can provide is either polling ("are you on now? =A0No.= (time passes) Are you on now? No. (time passes) Are you on now? Yes.") or = else long connections waiting for a response ("Are you being turned on? (ti= me passes) Timeout. Are you being turned on? (less time passes) Yes."). Bot= h are crude and inefficient bastardizations of HTTP. > > I don't see a way to map that observer required behavior to HTTP. > > Yoav > > On Dec 6, 2010, at 10:18 AM, Angelo P. Castellani wrote: > >> Thanks Brian for your message, I share completely your point(s). >> >> To me also seems that CoAP design is too much oriented on the design >> of a stand-alone application protocol, instead of focusing on REST and >> HTTP mapping as a top priority. >> >> Observe in my opinion has been designed as an efficient stand-alone >> mechanism, leaving in the to do list the mapping to/from HTTP; this >> should not be the design procedure and could lead to (big?) problems >> when integrating with the "legacy" web. >> >> CoAP priority should be the design of efficient *and* HTTP mappable >> solutions; if the proposed solution maps hardly to HTTP, introduces >> state (requiring a stateful entity to be correctly mapped) or can't >> work in both directions CoAP->HTTP and HTTP->CoAP, then it should be >> reconsidered. >> >> Angelo >> >> On Sat, Dec 4, 2010 at 21:03, Brian Frank wrot= e: >>> Sometimes I think it is useful to just take a step back and reevaluate >>> exactly what we are trying to accomplish. >>> Personally, I got involved in the CoAP effort for one primary reason: I >>> believe that every piece of information associated with the Internet of >>> Things should have a URI. =A0Not just any URI, but an "http" URI - so t= hat >>> smart devices could integrate with the web at large. =A0So for me the w= hole >>> idea of CoAP is not really that desirable, rather it is a necessary evi= l. >>> =A0It is necessitated by the fact that HTTP doesn't run >>> over constrained networks and in constrained devices: >>> =A0 - number of bytes on the wire matters greatly (http text headers to= o >>> verbose) >>> =A0 - network bandwidth, network characteristics, and device processing= /memory >>> make TCP hard >>> =A0 - sleeping nodes are big pain >>> I realize that not everyone necessarily shares my philosophy, but to >>> me personally the whole point of CoAP is to seamless integrate to HTTP = so >>> that the Internet of Things can integrate into the web at large. >>> If you share this philosophy, then probably one of the most critical as= pects >>> of CoAP is the CoaP/HTTP mapping Section 7. =A0Up to this point we (me >>> included) have sort of been treating this section as the thing to do la= st >>> after all the important stuff has been done. =A0But after reviewing a l= ot of >>> the tickets and outstanding issues, I think we have been putting the ca= rt >>> before the horse so to speak. =A0HTTP is the end-goal, CoAP is just the= means >>> to the end. =A0I personally would like to see every feature of CoAP eva= luated >>> in the context of its HTTP mapping. >>> Just to review a couple of the biggies: >>> Proxy Terminology (#72) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> This is what started me on this whole thought process. =A0The more I st= arted >>> thinking about terminology, the more I started thinking that the most >>> important proxy/gateway is the HTTP-to-CoAP functionality. =A0And I rea= lly >>> didn't see this discussed on the mailing list (perhaps I missed it thou= gh). >>> The key idea is that "proxy" could mean different things: >>> =A0 - there is the actual IP address where you direct requests to (expl= icit >>> proxies, interception proxies, reverse proxies etc) >>> =A0 - there is caching semantics (which is both a proxy issue *and* a >>> end-client issue) >>> =A0 - there is actual protocol translations HTTP->CoAP and CoAP->HTTP (= and >>> potentially others like XMPP, etc) >>> =A0 - there are potentially MIME content translations (for example XML = <-> >>> compress XML/binary as it goes thru HTTP <-> CoAP) >>> I am not sure we can really tackle proxy terminology without tackling s= ome >>> of the latter issues which haven't really received much discussion. >>> Caching Semantics (#78) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> It may just be a process/document structure issue. =A0But I suspect tha= t the >>> technique we use to tackle section 7 and how we cross reference RFC 261= 6 >>> will actually dictate how we should fix caching to do more cross refere= nce >>> of the HTTP spec itself. >>> Deferred Requests >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I understand how we got here. =A0But it doesn't really fit the simple H= TTP >>> req/res model. =A0So I think this discussion has to include the HTTP si= de of >>> things. >>> Pub/Sub Observations >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I know there are application tricks to do this with HTTP, but how will = we >>> map it? =A0I personally am finding this requirement is creating a lot o= f >>> complexity. =A0Furthermore based on my experience, the state management= of the >>> current design is too complicated and has too much overhead to implemen= t in >>> constrained devices. =A0I just want to raise the flag that I worry abou= t this >>> one. =A0I'd love to see it, but I am more than happy to live with a sol= id, >>> simple req/res model that works seamlessly with HTTP. >>> >>> A couple key take away points: >>> =A0 - are we actually all on the same page that seamless HTTP integrati= on is a >>> critical aspect of this effort? >>> =A0 - assuming yes to the above, then should we make HTTP mapping the t= op >>> priority and see how everything else fits into that? >>> Just my random thoughts... >>> Brian >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> Scanned by Check Point Total Security Gateway. > > From angelo.castellani@gmail.com Mon Dec 6 09:16: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 33EF63A6838 for ; Mon, 6 Dec 2010 09:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 POoiSL1dAtOs for ; Mon, 6 Dec 2010 09:16:08 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 3819F3A681D for ; Mon, 6 Dec 2010 09:16:08 -0800 (PST) Received: by qyk34 with SMTP id 34so3741324qyk.10 for ; Mon, 06 Dec 2010 09:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=6RaWx7FU3jITXuTIVemO+8zgTPn2GyrMzh1qn3lQrnw=; b=mn/5UnY8LFxsR7yx+Iwv/8xrcn+Qvl3tqgtU3p1wPWsmQXYqsYwSNyef6P55g4GnZa mc80ARENJqfLx/gGRDh9MSp48Y06SkSIqINpE+UDrpcF0lIH26DWwk5fh8qthw1Ihu25 ze48vAwR3DsOiIzqXxFMj0UlytFtY1Wn8mTUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=f81+oDHeTGf1eQLIZviihVv8WMBDEdSddeODsdgmBF+9H5zuSm9jqXF6k43giuq7UL k0JtLHeFexLLFJew0wlyRGxoBEZhPo2gA6cwzcadIXELThTv3Edy+OW/LPAztY8tRGoJ ubK+x3vsJxGQUArWDap2IuerziF0KjhCqvtkE= Received: by 10.229.220.78 with SMTP id hx14mr4729342qcb.13.1291655850010; Mon, 06 Dec 2010 09:17:30 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.13.194 with HTTP; Mon, 6 Dec 2010 09:17:09 -0800 (PST) In-Reply-To: References: From: "Angelo P. Castellani" Date: Mon, 6 Dec 2010 18:17:09 +0100 X-Google-Sender-Auth: Q9-UWFZk6uqTNKHC4wolCCUpWDM Message-ID: To: "Clark, Gilbert" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 17:16:09 -0000 On Mon, Dec 6, 2010 at 12:24, Clark, Gilbert wrote: > Also, I see the state required by OBSERVE as being part of an HTTP server= 's > cache. Caching the state can be hardly implementable, because that state is required to match responses so has to be promptly available to the proxy process whether usually caching mechanisms rely on a more looser storage support that could require higher access time.. Moreover the bigger state to be mantained could be *one TCP connection* open for *every subscriber*, this is required to push the notification to the client. > Additionally, HTTP assumes that the server involved in a connection will = be > up the majority of the time. =A0I'd imagine that, for many constrained > devices, the opposite would be true: they'd be sleeping for the vast > majority of their lifetime, which means that timing a poll to hit one of = the > brief periods the device was awake would be difficult at best. =A0An > alternative to this approach might be forcing the device to wake every ti= me > it was polled, which seems like it might be pretty bad for networks where > power and / or network utilization was a constraint. This can be obtained also with an alternative, subscription itself is an high-level solution to this.. I don't think we should not support subscription. > I agree that there's probably not a good way to make OBSERVE visible to a= n > HTTP client; at the same time, I also feel like a 1:1 mapping should not = be > required as long as the CoAP <--> HTTP translator is able to support a > viable subset of HTTP. In my opinion the problem we face is not really about finding a way to map, but about finding a *simple* and *scalable* way to map CoAP to HTTP. > For example, in the case of OBSERVE, the CoAP <--> > HTTP translator could actually fulfill HTTP GET requests by OBSERVE-ing t= he > resource specified in the GET, and caching content between updates. =A0Th= is > would minimize load on the CoAP network while maintaining HTTP > compatibility, and HTTP wouldn't necessarily have to know the translator = was > cheating and using OBSERVE. Sure, I agree that the subscription technique proposed should obviously support caching in some way. Regards, Angelo From jonsmirl@gmail.com Mon Dec 6 09:36: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 CB7B63A681D for ; Mon, 6 Dec 2010 09:36:22 -0800 (PST) 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 RcLC8Om9p5ff for ; Mon, 6 Dec 2010 09:36:21 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 51FCF3A686A for ; Mon, 6 Dec 2010 09:36:21 -0800 (PST) Received: by pxi6 with SMTP id 6so2555082pxi.31 for ; Mon, 06 Dec 2010 09:37:45 -0800 (PST) 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=iyPvUBw+mEPmD5GDCCcFnWnCXqYRGrkfK+lLgZ/IO+c=; b=rebjL6al1Zxm/SgvMuLs8OriJ/h+MMamGWn8dHQZS51VI9xgS8SlasR1uJ/5fNsU3F gPY9Z+UJK0GbnFXZx+qpdxlxUY+MKNTqkayTljC31eMlhaAcu+XqDgnOgPqwq8ZDFlE9 GUHk1ep+Jdq+AQxUx56t6ioh1bgIQ5Y7gSOIM= 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=Bl6mnryIu7htlRhQZJrLGYaYq8AnVQp6NT+StgFtz6WZr8eAJt4wv+F8SUmviPLyF8 7/f/tpCsc1hPqGUNk0ORtrb7wte6wvyG9aujHMyOFxWROjjszkc8shi6jHBkCX70uUFH bnXM2iG4wUfaaTbTPLtRYFhj5FBqJ6nh0p0as= MIME-Version: 1.0 Received: by 10.142.48.16 with SMTP id v16mr5469509wfv.294.1291657065167; Mon, 06 Dec 2010 09:37:45 -0800 (PST) Received: by 10.142.186.7 with HTTP; Mon, 6 Dec 2010 09:37:45 -0800 (PST) In-Reply-To: <0EBAC7F4-C42A-4B2D-BC14-420A03F3A5A2@checkpoint.com> References: <0EBAC7F4-C42A-4B2D-BC14-420A03F3A5A2@checkpoint.com> Date: Mon, 6 Dec 2010 12:37:45 -0500 Message-ID: From: "jonsmirl@gmail.com" To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 17:36:23 -0000 On Mon, Dec 6, 2010 at 5:36 AM, Yoav Nir wrote: > I don't think the problem is in the design of Observe. The problem is wit= h the requirement. In some cases, observers require immediate notification.= Picture a light switch that has been flipped, with the light fixture obser= ving. > > The best that HTTP can provide is either polling ("are you on now? =A0No.= (time passes) Are you on now? No. (time passes) Are you on now? Yes.") or = else long connections waiting for a response ("Are you being turned on? (ti= me passes) Timeout. Are you being turned on? (less time passes) Yes."). Bot= h are crude and inefficient bastardizations of HTTP. --------------------------------------------- I agree that HTTP is the wrong protocol for group operations and status information. What about using XMPP (IM chat) instead? The XMPP protocol already supports concepts like presence, status, group and individual conversations, etc. A fixed function chat client (the light switch) does not take a lot of resources. The chat server could run on a wifi router (multiple free implementations exist) and handle proxies for sleeping devices. XMPP also has a serverless mode which should be adaptable to directly use mutlticast LANs packets. http://xmpp.org/extensions/xep-0174.html For direct browser access to the devices, use http or run a Javascript chat client in the browser. --=20 Jon Smirl jonsmirl@gmail.com From cabo@tzi.org Mon Dec 6 09:40:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BEFC3A681D for ; Mon, 6 Dec 2010 09:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.332 X-Spam-Level: X-Spam-Status: No, score=-106.332 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugc0xyTqi--q for ; Mon, 6 Dec 2010 09:40:26 -0800 (PST) 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 D526F3A6864 for ; Mon, 6 Dec 2010 09:40:25 -0800 (PST) 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 oB6HfeEe024280; Mon, 6 Dec 2010 18:41:40 +0100 (CET) Received: from [192.168.217.101] (p5489B34C.dip.t-dialin.net [84.137.179.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 46A4DBBA; Mon, 6 Dec 2010 18:41:40 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 6 Dec 2010 18:41:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7C0EA487-23C6-4599-AF2A-6EF92E2D51A4@tzi.org> References: <0EBAC7F4-C42A-4B2D-BC14-420A03F3A5A2@checkpoint.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1082) Cc: core WG Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 17:40:28 -0000 One very useful rule that this WG has been following so far for the = design of CoAP is:=20 When in doubt, do it like HTTP. There is absolutely no doubt here, though. There is nothing we can = follow. On Dec 6, 2010, at 18:07, Angelo P. Castellani wrote: > HTTP supports chunked Transfer-Encoding, Yes. > through this feature is > possible to push data to clients. (If you mean "push" in the sense of deferred response:) No. Yes, I'm aware of "forever-frames" and all those wonderful asynchronous = AJAX hacks. (I built a little toy based on long-polls in 2005; = http://tzi.org:2000/s6.html if you are interested). These hacks are not a part of HTTP, they are abusing HTTP, and they work = only because the idiosyncrasies of certain specific implementations = happen to line up just right. I'll leave the last word to Brian Carpenter, who prefixed his review of = draft-loreto-http-bidirectional-05.txt with: > This is real example of protocol abuse. HTTP wasn't designed for this = and doesn't do this properly.=20 Gruesse, CArsten From gc355804@ohio.edu Mon Dec 6 12:12:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD12B3A68B1 for ; Mon, 6 Dec 2010 12:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peGReyeVQJFR for ; Mon, 6 Dec 2010 12:12:44 -0800 (PST) Received: from mx4.oit.ohio.edu (mx4.oit.ohio.edu [132.235.250.54]) by core3.amsl.com (Postfix) with ESMTP id 95FDA3A688A for ; Mon, 6 Dec 2010 12:12:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABPT/EyE6wh6/2dsb2JhbACjPHG2GohmhUkEhF+GDw X-IronPort-AV: E=Sophos;i="4.59,306,1288584000"; d="scan'208";a="61957924" Received: from exht2.oit.ohio.edu ([132.235.8.122]) by smtpout4.oit.ohio.edu with ESMTP; 06 Dec 2010 15:14:08 -0500 Received: from exmail1.ohio.edu ([10.13.10.1]) by exht2.oit.ohio.edu ([10.13.10.32]) with mapi; Mon, 6 Dec 2010 15:14:07 -0500 From: "Clark, Gilbert" To: "Angelo P. Castellani" Date: Mon, 6 Dec 2010 15:14:06 -0500 Thread-Topic: [core] CoAP and HTTP - Philosophy and Direction Thread-Index: AcuVaX17Hvm3W4UrRzSy8RHnUCZP3AAGKSW+ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 20:12:45 -0000 Hi: Responses inline. On 12/6/10 12:17 PM, "Angelo P. Castellani" wrote: > On Mon, Dec 6, 2010 at 12:24, Clark, Gilbert wrote: >> Also, I see the state required by OBSERVE as being part of an HTTP serve= r's >> cache. >=20 > Caching the state can be hardly implementable, because that state is > required to match responses so has to be promptly available to the > proxy process whether usually caching mechanisms rely on a more looser > storage support that could require higher access time.. Couldn't you generate the value for the token option based on a hashed combination of the resource URI and the subscriber, eliminating the need fo= r additional state (at the cost of additional CPU)? I'm behind on list traffic, so I'm not sure how those are generated at the moment, but in general I believe it might be possible for a token to be implicitly defined= . Wouldn't the state be required only to match requests, and not responses? Also, I'm not sure I understand why state would need to be promptly available; you could sacrifice update granularity to allow for deferred processing, at the cost of storing a token option / queued update. > Moreover the bigger state to be mantained could be *one TCP > connection* open for *every subscriber*, this is required to push the > notification to the client. Correction: I was intending to argue that the state required by OBSERVE could arguably be considered to be part of a server's cache (and therefore could be included as part of a REST architecture). I didn't mean to say that this would be a good thing to try to implement within HTTP. >> Additionally, HTTP assumes that the server involved in a connection will= be >> up the majority of the time. =A0I'd imagine that, for many constrained >> devices, the opposite would be true: they'd be sleeping for the vast >> majority of their lifetime, which means that timing a poll to hit one of= the >> brief periods the device was awake would be difficult at best. =A0An >> alternative to this approach might be forcing the device to wake every t= ime >> it was polled, which seems like it might be pretty bad for networks wher= e >> power and / or network utilization was a constraint. >=20 > This can be obtained also with an alternative, subscription itself is > an high-level solution to this.. I don't think we should not support > subscription. Clarification: I was trying to imply the following (quoting Yoav): > I don't see a way to map that observer required behavior to HTTP. -- >> I agree that there's probably not a good way to make OBSERVE visible to = an >> HTTP client; at the same time, I also feel like a 1:1 mapping should not= be >> required as long as the CoAP <--> HTTP translator is able to support a >> viable subset of HTTP. >=20 > In my opinion the problem we face is not really about finding a way to > map, but about finding a *simple* and *scalable* way to map CoAP to > HTTP. One straightforward approach to scaling a HTTP <--> CoAP proxy as described in my original e-mail would be to make each CoAP node a subdomain (e.g. node1.proxy.coapiscool.net), and implement the DNS lookup service such that it will return the appropriate HTTP <--> CoAP proxy for a given node. In any case, my issue with stating the problem as "finding a simple and scalable way to map CoAP to HTTP" is that it's ambiguous. What parts of HTTP and CoAP should be interoperable? Why? What is "simple"? What is "scalable"? I vote we come up with a concrete problem statement and then try to argue about its implementation; it could be that we're all in violen= t agreement and we just don't know it yet. >> For example, in the case of OBSERVE, the CoAP <--> >> HTTP translator could actually fulfill HTTP GET requests by OBSERVE-ing = the >> resource specified in the GET, and caching content between updates. =A0T= his >> would minimize load on the CoAP network while maintaining HTTP >> compatibility, and HTTP wouldn't necessarily have to know the translator= was >> cheating and using OBSERVE. >=20 > Sure, I agree that the subscription technique proposed should > obviously support caching in some way. s/should/must/ > Regards, > Angelo --Gilbert Clark From paduffy@cisco.com Mon Dec 6 16:56: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 294E528C0CF for ; Mon, 6 Dec 2010 16:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp-u56DVVsXq for ; Mon, 6 Dec 2010 16:56:03 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9200C3A68DA for ; Mon, 6 Dec 2010 16:56:03 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGcV/UxAZnwM/2dsb2JhbACjOHGjZ4JHDgGYcoVJBIRfhg+DE4Jy X-IronPort-AV: E=Sophos;i="4.59,308,1288569600"; d="scan'208";a="189905062" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Dec 2010 00:57:27 +0000 Received: from [161.44.65.170] ([161.44.65.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB70vRJA012059; Tue, 7 Dec 2010 00:57:27 GMT Message-ID: <4CFD8677.7030607@cisco.com> Date: Mon, 06 Dec 2010 19:57:27 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Angelo P. Castellani" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 00:56:05 -0000 Strong agreement with Brian's and Angelo's points. COAP <--> HTTP mapping needs to be as simple and stateless as possible. Else you run the risk of islanding COAP from the rest of the Web. I cringe, however, when I see existing Web referred to as "legacy". How about "ubiquitously deployed and in no danger of going away anytime soon"? Cheers On 12/6/2010 3:18 AM, Angelo P. Castellani wrote: > Thanks Brian for your message, I share completely your point(s). > > To me also seems that CoAP design is too much oriented on the design > of a stand-alone application protocol, instead of focusing on REST and > HTTP mapping as a top priority. > > Observe in my opinion has been designed as an efficient stand-alone > mechanism, leaving in the to do list the mapping to/from HTTP; this > should not be the design procedure and could lead to (big?) problems > when integrating with the "legacy" web. > > CoAP priority should be the design of efficient *and* HTTP mappable > solutions; if the proposed solution maps hardly to HTTP, introduces > state (requiring a stateful entity to be correctly mapped) or can't > work in both directions CoAP->HTTP and HTTP->CoAP, then it should be > reconsidered. > > Angelo > > On Sat, Dec 4, 2010 at 21:03, Brian Frank wrote: >> Sometimes I think it is useful to just take a step back and reevaluate >> exactly what we are trying to accomplish. >> Personally, I got involved in the CoAP effort for one primary reason: I >> believe that every piece of information associated with the Internet of >> Things should have a URI. Not just any URI, but an "http" URI - so that >> smart devices could integrate with the web at large. So for me the whole >> idea of CoAP is not really that desirable, rather it is a necessary evil. >> It is necessitated by the fact that HTTP doesn't run >> over constrained networks and in constrained devices: >> - number of bytes on the wire matters greatly (http text headers too >> verbose) >> - network bandwidth, network characteristics, and device processing/memory >> make TCP hard >> - sleeping nodes are big pain >> I realize that not everyone necessarily shares my philosophy, but to >> me personally the whole point of CoAP is to seamless integrate to HTTP so >> that the Internet of Things can integrate into the web at large. >> If you share this philosophy, then probably one of the most critical aspects >> of CoAP is the CoaP/HTTP mapping Section 7. Up to this point we (me >> included) have sort of been treating this section as the thing to do last >> after all the important stuff has been done. But after reviewing a lot of >> the tickets and outstanding issues, I think we have been putting the cart >> before the horse so to speak. HTTP is the end-goal, CoAP is just the means >> to the end. I personally would like to see every feature of CoAP evaluated >> in the context of its HTTP mapping. >> Just to review a couple of the biggies: >> Proxy Terminology (#72) >> ================== >> This is what started me on this whole thought process. The more I started >> thinking about terminology, the more I started thinking that the most >> important proxy/gateway is the HTTP-to-CoAP functionality. And I really >> didn't see this discussed on the mailing list (perhaps I missed it though). >> The key idea is that "proxy" could mean different things: >> - there is the actual IP address where you direct requests to (explicit >> proxies, interception proxies, reverse proxies etc) >> - there is caching semantics (which is both a proxy issue *and* a >> end-client issue) >> - there is actual protocol translations HTTP->CoAP and CoAP->HTTP (and >> potentially others like XMPP, etc) >> - there are potentially MIME content translations (for example XML<-> >> compress XML/binary as it goes thru HTTP<-> CoAP) >> I am not sure we can really tackle proxy terminology without tackling some >> of the latter issues which haven't really received much discussion. >> Caching Semantics (#78) >> =================== >> It may just be a process/document structure issue. But I suspect that the >> technique we use to tackle section 7 and how we cross reference RFC 2616 >> will actually dictate how we should fix caching to do more cross reference >> of the HTTP spec itself. >> Deferred Requests >> ============== >> I understand how we got here. But it doesn't really fit the simple HTTP >> req/res model. So I think this discussion has to include the HTTP side of >> things. >> Pub/Sub Observations >> ================= >> I know there are application tricks to do this with HTTP, but how will we >> map it? I personally am finding this requirement is creating a lot of >> complexity. Furthermore based on my experience, the state management of the >> current design is too complicated and has too much overhead to implement in >> constrained devices. I just want to raise the flag that I worry about this >> one. I'd love to see it, but I am more than happy to live with a solid, >> simple req/res model that works seamlessly with HTTP. >> >> A couple key take away points: >> - are we actually all on the same page that seamless HTTP integration is a >> critical aspect of this effort? >> - assuming yes to the above, then should we make HTTP mapping the top >> priority and see how everything else fits into that? >> Just my random thoughts... >> Brian >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From zach@sensinode.com Tue Dec 7 01:01:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90D13A6939 for ; Tue, 7 Dec 2010 01:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MMHc2YVX7uN for ; Tue, 7 Dec 2010 01:01:52 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 59DF43A692F for ; Tue, 7 Dec 2010 01:01:50 -0800 (PST) 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 oB793AWY019902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 11:03:11 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-275--127220512; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Tue, 7 Dec 2010 11:03:11 +0200 Message-Id: <009E3D74-D2FF-4DCF-AC84-554763BEA92A@sensinode.com> References: To: "Clark, Gilbert" X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 09:01:53 -0000 --Apple-Mail-275--127220512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Gilbert, This was exactly how I envision observe being used. The philosophy is = that observe is a mechanism a CoAP-HTTP caching proxy can use to update = its cache. HTTP clients can request resources using polling, long = polling or with some other mechanism. To an HTTP client observe is not = visible, in other words, it does not require a mapping. It is up to the = proxy how it wants to decide when observation should be used. We have a = ticket already to add examples of this to the next version of = core-observe.=20 Zach On Dec 6, 2010, at 1:24 PM, Clark, Gilbert wrote: > For what it's worth: >=20 > I agree that supporting some subset of HTTP is important, but I'd be = wary of > designing CoAP around its HTTP support. CoAP networks are likely to = have > very different characteristics from networks running HTTP; CoAP should > therefore be primarily designed to operate best in the environment = into > which it's being deployed. >=20 > Also, I see the state required by OBSERVE as being part of an HTTP = server's > cache. In this case, though, instead of caching content, the server = is > caching a GET and passing back data to tell the client what the GET is > called so it knows when it gets a response; the server has the option = of > telling the client it won't do so, so no state is actually *forced* = onto the > server; instead, the server is choosing to cache the request with the > understanding that supporting 10K of cached GET requests could go a = long way > to minimizing power / CPU utilization in the long run. >=20 > Additionally, HTTP assumes that the server involved in a connection = will be > up the majority of the time. I'd imagine that, for many constrained > devices, the opposite would be true: they'd be sleeping for the vast > majority of their lifetime, which means that timing a poll to hit one = of the > brief periods the device was awake would be difficult at best. An > alternative to this approach might be forcing the device to wake every = time > it was polled, which seems like it might be pretty bad for networks = where > power and / or network utilization was a constraint. >=20 > I agree that there's probably not a good way to make OBSERVE visible = to an > HTTP client; at the same time, I also feel like a 1:1 mapping should = not be > required as long as the CoAP <--> HTTP translator is able to support a > viable subset of HTTP. For example, in the case of OBSERVE, the CoAP = <--> > HTTP translator could actually fulfill HTTP GET requests by = OBSERVE-ing the > resource specified in the GET, and caching content between updates. = This > would minimize load on the CoAP network while maintaining HTTP > compatibility, and HTTP wouldn't necessarily have to know the = translator was > cheating and using OBSERVE. >=20 > /$0.02 >=20 > --Gilbert Clark >=20 > On 12/6/10 3:18 AM, "Angelo P. Castellani" = wrote: >=20 >> Thanks Brian for your message, I share completely your point(s). >>=20 >> To me also seems that CoAP design is too much oriented on the design >> of a stand-alone application protocol, instead of focusing on REST = and >> HTTP mapping as a top priority. >>=20 >> Observe in my opinion has been designed as an efficient stand-alone >> mechanism, leaving in the to do list the mapping to/from HTTP; this >> should not be the design procedure and could lead to (big?) problems >> when integrating with the "legacy" web. >>=20 >> CoAP priority should be the design of efficient *and* HTTP mappable >> solutions; if the proposed solution maps hardly to HTTP, introduces >> state (requiring a stateful entity to be correctly mapped) or can't >> work in both directions CoAP->HTTP and HTTP->CoAP, then it should be >> reconsidered. >>=20 >> Angelo >>=20 >> On Sat, Dec 4, 2010 at 21:03, Brian Frank = wrote: >>> Sometimes I think it is useful to just take a step back and = reevaluate >>> exactly what we are trying to accomplish. >>> Personally, I got involved in the CoAP effort for one primary = reason: I >>> believe that every piece of information associated with the Internet = of >>> Things should have a URI. Not just any URI, but an "http" URI - so = that >>> smart devices could integrate with the web at large. So for me the = whole >>> idea of CoAP is not really that desirable, rather it is a necessary = evil. >>> It is necessitated by the fact that HTTP doesn't run >>> over constrained networks and in constrained devices: >>> - number of bytes on the wire matters greatly (http text headers = too >>> verbose) >>> - network bandwidth, network characteristics, and device = processing/memory >>> make TCP hard >>> - sleeping nodes are big pain >>> I realize that not everyone necessarily shares my philosophy, but to >>> me personally the whole point of CoAP is to seamless integrate to = HTTP so >>> that the Internet of Things can integrate into the web at large. >>> If you share this philosophy, then probably one of the most critical = aspects >>> of CoAP is the CoaP/HTTP mapping Section 7. Up to this point we (me >>> included) have sort of been treating this section as the thing to do = last >>> after all the important stuff has been done. But after reviewing a = lot of >>> the tickets and outstanding issues, I think we have been putting the = cart >>> before the horse so to speak. HTTP is the end-goal, CoAP is just = the means >>> to the end. I personally would like to see every feature of CoAP = evaluated >>> in the context of its HTTP mapping. >>> Just to review a couple of the biggies: >>> Proxy Terminology (#72) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> This is what started me on this whole thought process. The more I = started >>> thinking about terminology, the more I started thinking that the = most >>> important proxy/gateway is the HTTP-to-CoAP functionality. And I = really >>> didn't see this discussed on the mailing list (perhaps I missed it = though). >>> The key idea is that "proxy" could mean different things: >>> - there is the actual IP address where you direct requests to = (explicit >>> proxies, interception proxies, reverse proxies etc) >>> - there is caching semantics (which is both a proxy issue *and* a >>> end-client issue) >>> - there is actual protocol translations HTTP->CoAP and CoAP->HTTP = (and >>> potentially others like XMPP, etc) >>> - there are potentially MIME content translations (for example XML = <-> >>> compress XML/binary as it goes thru HTTP <-> CoAP) >>> I am not sure we can really tackle proxy terminology without = tackling some >>> of the latter issues which haven't really received much discussion. >>> Caching Semantics (#78) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> It may just be a process/document structure issue. But I suspect = that the >>> technique we use to tackle section 7 and how we cross reference RFC = 2616 >>> will actually dictate how we should fix caching to do more cross = reference >>> of the HTTP spec itself. >>> Deferred Requests >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I understand how we got here. But it doesn't really fit the simple = HTTP >>> req/res model. So I think this discussion has to include the HTTP = side of >>> things. >>> Pub/Sub Observations >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I know there are application tricks to do this with HTTP, but how = will we >>> map it? I personally am finding this requirement is creating a lot = of >>> complexity. Furthermore based on my experience, the state = management of the >>> current design is too complicated and has too much overhead to = implement in >>> constrained devices. I just want to raise the flag that I worry = about this >>> one. I'd love to see it, but I am more than happy to live with a = solid, >>> simple req/res model that works seamlessly with HTTP. >>>=20 >>> A couple key take away points: >>> - are we actually all on the same page that seamless HTTP = integration is a >>> critical aspect of this effort? >>> - assuming yes to the above, then should we make HTTP mapping the = top >>> priority and see how everything else fits into that? >>> Just my random thoughts... >>> Brian >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 > _______________________________________________ > 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-275--127220512 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIwNzA5MDMx MlowIwYJKoZIhvcNAQkEMRYEFGmAs+XsmkXmgjLt0Rh7r+C8nlOMMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAIjT14/0OEBZKk+oBTT4JfrjK/SY0nglTV9LMQKZyUnHElw2PiG3SziK UL0xNBPJiccniW+q6h2ZRQr5dZAOkvX1pUnEZbksrDMJvY7P6hbPJfbzFqm+xVyWyPJWGG46ImXr VzqG0V4zRyvrSTeRR8+NP7QEN58RhQX2Hh4zPHEu0UTagm51llGCqJ2KLKy4sxD2OxhNhkfMDCTz Q11R+pZGzlhhJHcxerEzAqEZm4uE3GWtgZL51vO0p8DP9l8i5t1YuKNT6zujqCRGxVZNgBJGKITf ABEDJXTx42dCOuyxAtwjYsXabvYwJaWDgIpOywebCuVC8avgUMRNeQSeEY0AAAAAAAA= --Apple-Mail-275--127220512-- From zach@sensinode.com Tue Dec 7 01:33:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904613A6943 for ; Tue, 7 Dec 2010 01:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 75NCxBj09qPf for ; Tue, 7 Dec 2010 01:33:32 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 82D073A693E for ; Tue, 7 Dec 2010 01:33:30 -0800 (PST) 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 oB79YpZG025126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 11:34:52 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-276--125319006; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Tue, 7 Dec 2010 11:34:53 +0200 Message-Id: <3DB1451D-7796-48DE-96CF-83861F40C40B@sensinode.com> References: To: Brian Frank X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] CoAP and HTTP - Philosophy and Direction X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Dec 2010 09:33:38 -0000 --Apple-Mail-276--125319006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 4, 2010, at 10:03 PM, Brian Frank wrote: > Sometimes I think it is useful to just take a step back and reevaluate = exactly what we are trying to accomplish. Good idea. >=20 > Personally, I got involved in the CoAP effort for one primary reason: = I believe that every piece of information associated with the Internet = of Things should have a URI. Not just any URI, but an "http" URI - so = that smart devices could integrate with the web at large. So for me the = whole idea of CoAP is not really that desirable, rather it is a = necessary evil. It is necessitated by the fact that HTTP doesn't run = over constrained networks and in constrained devices: >=20 > - number of bytes on the wire matters greatly (http text headers too = verbose) >=20 > - network bandwidth, network characteristics, and device = processing/memory make TCP hard >=20 > - sleeping nodes are big pain >=20 > I realize that not everyone necessarily shares my philosophy, but to = me personally the whole point of CoAP is to seamless integrate to HTTP = so that the Internet of Things can integrate into the web at large. =20 That may be your main use case for HTTP, but it clearly is just one use = case for the WG. I would say a simple HTTP mapping is an important = aspect of CoAP, but fulfilling the other M2M application requirements = are just as important. Many of the application people will be using this = for in the M2M industry won't require HTTP mapping at all. For the = long-term evolution of the Internet of Things, I agree that HTTP mapping = is important.=20 > If you share this philosophy, then probably one of the most critical = aspects of CoAP is the CoaP/HTTP mapping Section 7. Up to this point we = (me included) have sort of been treating this section as the thing to do = last after all the important stuff has been done. But after reviewing a = lot of the tickets and outstanding issues, I think we have been putting = the cart before the horse so to speak. HTTP is the end-goal, CoAP is = just the means to the end. I personally would like to see every feature = of CoAP evaluated in the context of its HTTP mapping. We haven't forgotten about HTTP mapping by any means, Section 7 is = important to the document. On the list I think everyone has been = assuming HTTP mapping as an underlying requirement, thus it is not = brought up in every post. Not every feature of CoAP affects HTTP = mapping, for example the transaction model of CoAP is invisible to HTTP.=20= Although there is no ticket for it (I will make one now), Klaus has done = some work on improvements for the HTTP mapping section and we plan on = having a better table there e.g. for response code mappings in both = directions. Is there something else in particular missing from the HTTP = mapping section? =20 > Just to review a couple of the biggies: >=20 > Proxy Terminology (#72) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This is what started me on this whole thought process. The more I = started thinking about terminology, the more I started thinking that the = most important proxy/gateway is the HTTP-to-CoAP functionality. And I = really didn't see this discussed on the mailing list (perhaps I missed = it though). The key idea is that "proxy" could mean different things: >=20 > - there is the actual IP address where you direct requests to = (explicit proxies, interception proxies, reverse proxies etc) >=20 > - there is caching semantics (which is both a proxy issue *and* a = end-client issue) >=20 > - there is actual protocol translations HTTP->CoAP and CoAP->HTTP = (and potentially others like XMPP, etc) >=20 > - there are potentially MIME content translations (for example XML = <-> compress XML/binary as it goes thru HTTP <-> CoAP) >=20 > I am not sure we can really tackle proxy terminology without tackling = some of the latter issues which haven't really received much discussion. I think we can tackle these in the text. Already we made the decision to = separate the caching semantics from the proxy function. Reverse proxies = are really out of scope, although we do plan on mentioning them. HTTP = translation is already explained in section 7. Although MIME = translations are out of scope for CoAP, I don't think it would hurt to = mention that this is something a proxy may want to do. =20 >=20 > Caching Semantics (#78) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > It may just be a process/document structure issue. But I suspect that = the technique we use to tackle section 7 and how we cross reference RFC = 2616 will actually dictate how we should fix caching to do more cross = reference of the HTTP spec itself. Exactly. >=20 > Deferred Requests > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I understand how we got here. But it doesn't really fit the simple = HTTP req/res model. So I think this discussion has to include the HTTP = side of things. This is a transaction layer issue, and is invisible to request/response = and HTTP.=20 >=20 > Pub/Sub Observations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I know there are application tricks to do this with HTTP, but how will = we map it? I personally am finding this requirement is creating a lot = of complexity. Furthermore based on my experience, the state management = of the current design is too complicated and has too much overhead to = implement in constrained devices. I just want to raise the flag that I = worry about this one. I'd love to see it, but I am more than happy to = live with a solid, simple req/res model that works seamlessly with HTTP. There were already some good comments on this, but just to summarize. = The main point is that core-observe does not require mapping. Instead it = is just a cache refresh mechanism to an HTTP proxy. I envision that more = explicit REST pub/sub frameworks would be used end-to-end if you want = more sophisticated features. core-observe is not meant to compete with = or replace those frameworks, they have different goals. We have APs to = both add good examples and discuss how observe differs from other = frameworks in the next version of that document. > A couple key take away points: >=20 > - are we actually all on the same page that seamless HTTP = integration is a critical aspect of this effort? Everyone agrees that HTTP mapping is an important requirement. > - assuming yes to the above, then should we make HTTP mapping the = top priority and see how everything else fits into that? I disagree that it is the top priority. But I don't think that any of = our current design issues are at odds here. There really isn't anything = in CoAP that makes HTTP mapping particularly difficult, we did a lot of = work to make things that don't work in the HTTP world invisible to it. = Mostly I think some more editorial work is needed in the next versions = of core-coap and core-observe to portrait that clearly. Zach >=20 > Just my random thoughts... > Brian >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-276--125319006 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIwNzA5MzQ1 M1owIwYJKoZIhvcNAQkEMRYEFLTmq+X/Mc5NxO3uINilUcsHhY7XMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAAuQYJrElztsCL09URCY8F9KFo2bMEQyo+qv2W9eIfo26pIX1a24Tk2I bF8oMKO/vEyY4bjYiKycE+l8xn2EelDY4/vrx2grw1Bn1WOhJlJARdzEgLmMPmmrT/gvMr7BuBC6 0EJl9QLTvhHFZsKdZJfmN/p/gl5CeA7qLgGH9B/S8WhfoigoB+w9/kdTNL6aa62dcAvsPUoNgmgs VD1rGirUKAtGs+Xx8XlYa6x+MX7kSg8HjDkt4iQd5WI93MACbZpz4McWJA9QO2WAMLYzgOsVVa1I oBzILj9p29/0bHzLVYJFNlVhUWDNkpbbifpt0TNe0W56WSWik2J0EsX3kUkAAAAAAAA= --Apple-Mail-276--125319006-- From Internet-Drafts@ietf.org Fri Dec 10 04:30: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 405A528C108; Fri, 10 Dec 2010 04:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.627 X-Spam-Level: X-Spam-Status: No, score=-98.627 tagged_above=-999 required=5 tests=[AWL=3.972, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zsgzr1CRHIQd; Fri, 10 Dec 2010 04:30:08 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375143A6ADA; Fri, 10 Dec 2010 04:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101210123002.9375.78350.idtracker@localhost> Date: Fri, 10 Dec 2010 04:30:02 -0800 Cc: core@ietf.org Subject: [core] I-D Action:draft-ietf-core-link-format-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: Fri, 10 Dec 2010 12:30:10 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : CoRE Link Format Author(s) : Z. Shelby Filename : draft-ietf-core-link-format-02.txt Pages : 14 Date : 2010-12-10 This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, 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 links hosted by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-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-link-format-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-10042640.I-D@ietf.org> --NextPart-- From zach@sensinode.com Fri Dec 10 04:38: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 C147428C0D7 for ; Fri, 10 Dec 2010 04:38:17 -0800 (PST) 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=[AWL=0.000, 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 nEUSRfON97K8 for ; Fri, 10 Dec 2010 04:38:15 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4BCAF3A6B02 for ; Fri, 10 Dec 2010 04:38:14 -0800 (PST) Received: from [192.168.0.105] (line-11647.dyn.kponet.fi [85.29.91.235]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id oBACdfmu008909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 10 Dec 2010 14:39:42 +0200 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-433-144970738; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 10 Dec 2010 14:39:43 +0200 References: <20101210122645.2F4333A6AFD@core3.amsl.com> To: core WG Message-Id: <0767A74E-3B22-43D8-A4D5-6FB2A07175FD@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Fwd: New Version Notification for draft-ietf-core-link-format-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 12:38:17 -0000 --Apple-Mail-433-144970738 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I submitted a new version of the CoRE Link Format. This now closes all = the tickets from Beijing and the interim meeting. Thanks to Carsten, = Peter and Martin for providing detailed comments on the draft. http://www.ietf.org/id/draft-ietf-core-link-format-02.txt Changes from ietf-01 to ietf-02: o Added references to RFC5988 (#41). o Removed sh and id link-extensions (#42). o Defined the use of UTF-8 (#84). o Changed query filter definition for any parameter (#70). o Added more example, now as a separate section (#43). o Mentioned cyclical links in the security section (#57). o Removed the sh and id attributes, added obs and sz attributes (#42). o Improved the context and relation description wrt RFC5988 and requested a new "hosts" default relation type (#85). Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: December 10, 2010 2:26:42 PM GMT+02:00 > To: zach@sensinode.com > Subject: New Version Notification for draft-ietf-core-link-format-02=20= >=20 >=20 > A new version of I-D, draft-ietf-core-link-format-02.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-core-link-format > Revision: 02 > Title: CoRE Link Format > Creation_date: 2010-12-10 > WG ID: core > Number_of_pages: 14 >=20 > Abstract: > This document defines Web Linking using a link format for use by > constrained web servers to describe hosted resources, their > attributes and other relationships between links. Based on the HTTP > Link Header format defined in RFC5988, 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 > links 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-433-144970738 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIxMDEyMzk0 M1owIwYJKoZIhvcNAQkEMRYEFNDxZP7YvwBt90RZu0roFwDu+N/uMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAJMl0x594k/hPhONGCcJkYg3XNem6p9t4phAEaSdzYN3GSju3aX9noeB 55WzwIrGoJzr1NCzC8B8l3wNdW4GghotQaWCPclVH8qMOMFaI9ZyvGYlgj+Hf1WrWd3Mel5aDSqr 4zfD/1RJT5UKbRxwepVSahc6KdARknCyTm7K0lC7w3vmOdk2yz/PvwfBbbaYsS2kaG2JMWIbHLi9 RP6J+msva+83ZnTA0GzKrEMZiPKtkzLDYB1FcaWcv7gU+4COU9myK8XpTZvlYV6s36rqb+C5lxaB 6H2jXd9xIqRJJxE6DmnLgkD1JvaZHJ7NTNYHYdvb2tfi85mn/P/a75tVdFoAAAAAAAA= --Apple-Mail-433-144970738-- From cabo@tzi.org Sun Dec 12 13:34: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 6311E3A6D47 for ; Sun, 12 Dec 2010 13:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.32 X-Spam-Level: X-Spam-Status: No, score=-106.32 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 Ok62x1bxhBKO for ; Sun, 12 Dec 2010 13:34:40 -0800 (PST) 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 D771B3A6E11 for ; Sun, 12 Dec 2010 13:34:36 -0800 (PST) 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 oBCLZw7x020154 for ; Sun, 12 Dec 2010 22:36:01 +0100 (CET) Received: from [192.168.217.101] (p5489F15A.dip.t-dialin.net [84.137.241.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65F49222; Sun, 12 Dec 2010 22:35:58 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 12 Dec 2010 22:35:57 +0100 To: core WG Message-Id: <4FB3F60A-C292-4DDE-BAEA-354252090C91@tzi.org> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [core] IETF79 minutes uploaded X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 21:34:41 -0000 I have uploaded the draft minutes for CoRE. Thanks to Geoff and Shoichi for the raw material. Please find the minutes at: http://www.ietf.org/proceedings/79/minutes/core.txt Please send any corrections to the list or to me. (Also, if I haven't caught your name properly, please tell me who "??" was.) I apologize for the length -- we had some pretty good discussion in Beijing, and this often had more meat than I could turn into a simple decision record. Gruesse, Carsten From gm.lee@it-sudparis.eu Mon Dec 13 23:58: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 B2CDA3A6F76 for ; Mon, 13 Dec 2010 23:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERvYMWJjuUjF for ; Mon, 13 Dec 2010 23:58:10 -0800 (PST) Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 53D753A6F70 for ; Mon, 13 Dec 2010 23:58:10 -0800 (PST) Received: from smtp2.it-sudparis.eu (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id BE908FE028F; Tue, 14 Dec 2010 08:59:49 +0100 (CET) Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.it-sudparis.eu (Postfix) with ESMTP id AF97BF40087; Tue, 14 Dec 2010 08:59:46 +0100 (CET) Received: from gmleenote (unknown [113.160.248.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 6FF7B2C18534; Tue, 14 Dec 2010 08:59:43 +0100 (CET) From: "Gyu Myoung Lee" To: References: In-Reply-To: Date: Tue, 14 Dec 2010 08:59:39 +0100 Message-ID: <003401cb9b64$df13e910$9d3bbb30$@lee@it-sudparis.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01CB9B6D.40D85110" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuHtV0KDhGmLVFKTxSSmElIQ/C+DwQjUsRwAMOU5BAAADWUAAAEv/dw Content-Language: ko X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner-ID: AF97BF40087.A64FF X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: gm.lee@it-sudparis.eu Cc: 'Bruce Nordman' Subject: [core] Call for proposal on the IoT X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 07:58:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0035_01CB9B6D.40D85110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All Sorry for cross-posting. Based on meeting results of last IoT Bar BoF in Beijing, we have decided to call for a short proposal on the IoT after discussing with Bruce and Ning. The aim is to identify problems and key issues for establishing a new group on the IoT in IRTF. Please see the details as follows. The submission deadline: 7th January 2011 (Friday) Scope: All related future research topics for the IoT within the IETF/IRTF Proposal submission: iot-irtf-discussion@googlegroups.com The template of proposal (1-2 pages) [based on Bruce's]: -Title -Summary -Problem statement -Research approach -Expected results -Interested people -Relationship to the IETF/IRTF working groups After receiving all proposals, we will prepare a formal BoF by the end of January. - Have an audio conference for reviewing proposals with key members - Update the PS document (editors) - Request an I-D for a good proposal (contributors) - Prepare a draft charter for IoT RG - Submit a BoF proposal If you have any question, feel free to contact me. In addition, please circulate this e-mail to your colleagues for promoting this activity. Looking forward to receiving valuable inputs from you. Best Regards, Gyu Myoung Lee ------=_NextPart_000_0035_01CB9B6D.40D85110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = All

 

Sorry for cross-posting.

 

Based on meeting results of last IoT Bar BoF in Beijing, we = have decided to call for a short proposal on the IoT after discussing = with Bruce and Ning.

The = aim is to identify problems and key issues for establishing a new group = on the IoT in IRTF.

 

Please see the details as follows.

The submission = deadline: 7th January 2011 = (Friday)

Scope: All = related future research topics for the IoT within the IETF/IRTF =

Proposal = submission: iot-irtf-discussion@googlegroups.com  

The template of = proposal (1-2 pages) [based on Bruce’s]:

-Title

-Summary

-Problem = statement

-Research = approach

-Expected = results

-Interested = people

-Relationship to = the IETF/IRTF working groups

After receiving = all proposals, we will prepare a formal BoF by the end of = January.

-       = Have an audio = conference for reviewing proposals with key = members

-       = Update the PS = document (editors)

-       = Request an I-D = for a good proposal (contributors)

-       = Prepare a draft = charter for IoT RG

-       = Submit a BoF = proposal

 

If = you have any question, feel free to contact me. In addition, please = circulate this e-mail to your colleagues for promoting this = activity.

Looking forward = to receiving valuable inputs from you.

 

Best = Regards,

Gyu Myoung = Lee

------=_NextPart_000_0035_01CB9B6D.40D85110-- From prvs=0964AD3ACA=guido.moritz@uni-rostock.de Tue Dec 14 08:29:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1F43A6FAF for ; Tue, 14 Dec 2010 08:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=0.943, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gpTiWIkdApJ for ; Tue, 14 Dec 2010 08:29:54 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id 8C3A93A6EA9 for ; Tue, 14 Dec 2010 08:29:53 -0800 (PST) From: Guido Moritz To: 'core' Date: Tue, 14 Dec 2010 17:31:34 +0100 Message-ID: <002101cb9bac$5f3f8670$1dbe9350$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acubp3RnEEWzF/tqQ1SnqatbrPg9Dg== Content-Language: de Subject: [core] CoAP and messages sizes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:29:55 -0000 Unfortunately I am only able to follow CoRE in short periods of time in the last month, so sorry if my questions/comments are again a bit late or even already solved. Because I am trying to put somehow SOAP in resource constrained networks (e.g. 6LoWPAN networks, please don't hit me for that) I have to work sometimes with particular huge messages for these devices (up to 5K), if no compression like EXI is applied. I assumed that the block option supports both large requests and responses and I would have been fine with that. But it seems that large messages are only supported for the response, not for the request. (Sorry, am I wrong here?) The mailing list argues that most of the scenarios which require large request are firmware updates and it would be reasonable to use TFTP or whatever. But CoAP might operate for several years in different domains and even if we cannot find an application scenario for every requirement, it wouldn't be bad to thing about from a different perspective. More specific: (1) IP packet vs. IP datagram. There seems to be a clear difference between these wording as a CoAP packet SHOULD fit within a packet and MUST fit within a datagram. Sorry, but the difference is not completely clear to me and after asking several people around here from different domains, I got 4 different opinions and definitions (all of them sound reasonable btw). So before I start assuming what it means, can we clarify the wording please? Thanks. (2) I would argue that the limitation to fit into a single IP datagram/packet/whatever is hard to meet, because nobody knows over which link layer and in which scenarios CoAP is used later on. "Assuming MTU of 1280" is too specific as it assumes IPv6?! For example, I am using CoAP as lightweight reliable binding for SOAP in contrast to the unreliable SOAP-over-UDP. This is not restricted to 6LoWPAN networks and/or IPv6, but might operate also in existing IPv4 networks. And there is a significant difference in minimum MTU of IPv4 and IPv6. Do we really want an application designer keeping in mind which IP version and link layer he/she develops for? Sorry for raising this point again, but my work is particularly close to the boundaries of message size and I am not completely happy with the current solution. (3) The CoAP block option supports only for large Responses, not for Requests (Right?) SOAP is one application scenario for messages larger than MTU for both request and response. Would it be worth finding a more general solution like the transaction layer also for the large message problem? Maybe CoAP will not only become a solution for resource constrained networks but also in common LANs (e.g. Home network) as a reasonable tradeoff between TCP handshake overhead and unreliable UDP. A more general solution for both directions would also weaken the long term significance of (1) and (2). As far as a message is too big, just switch on the block option for your message and it will work over which IP version and link layer you want (instead of switching to another protocol which would require a negotiation mechanism for the used protocol and parameters ...). Best, Guido From cabo@tzi.org Tue Dec 14 08:40: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 CEA713A6FBC for ; Tue, 14 Dec 2010 08:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.118 X-Spam-Level: X-Spam-Status: No, score=-106.118 tagged_above=-999 required=5 tests=[AWL=0.131, 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 uoHWLrhrAUTC for ; Tue, 14 Dec 2010 08:40:20 -0800 (PST) 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 9FBCF3A6FBA for ; Tue, 14 Dec 2010 08:40:19 -0800 (PST) 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 oBEGfpPu028874; Tue, 14 Dec 2010 17:41:51 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3F328BC9; Tue, 14 Dec 2010 17:41:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <002101cb9bac$5f3f8670$1dbe9350$@uni-rostock.de> Date: Tue, 14 Dec 2010 17:41:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9158D652-86B1-4D68-93E5-A26A8C6F298D@tzi.org> References: <002101cb9bac$5f3f8670$1dbe9350$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1082) Cc: 'core' Subject: Re: [core] CoAP and messages sizes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:40:20 -0000 On Dec 14, 2010, at 17:31, Guido Moritz wrote: > (3) The CoAP block option supports only for large Responses, not for > Requests (Right?) Right now, -block applies to response bodies in GET, and request bodies = in PUT/POST. (2.2, page 7:) In a PUT or POST transfer, the Block option refers to the body in the request, i.e., there is no way to perform a block-wise retrieval of the body of the response. Servers that do need to supply large bodies in response to PUT/POST SHOULD therefore be employing redirects. In Beijing, we said we didn't really want to add the redirect mechanisms = now. So, as -block is defined now, there is no support for transferring a = large response on a PUT or POST. Gruesse, Carsten From prvs=296477CCB0=guido.moritz@uni-rostock.de Tue Dec 14 08:54: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 5D1F428C0F9 for ; Tue, 14 Dec 2010 08:54:07 -0800 (PST) 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.708, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgyGhq+2sL7F for ; Tue, 14 Dec 2010 08:54:06 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by core3.amsl.com (Postfix) with ESMTP id 52D3528B797 for ; Tue, 14 Dec 2010 08:54:06 -0800 (PST) From: Guido Moritz To: 'core' References: <002101cb9bac$5f3f8670$1dbe9350$@uni-rostock.de> <9158D652-86B1-4D68-93E5-A26A8C6F298D@tzi.org> In-Reply-To: <9158D652-86B1-4D68-93E5-A26A8C6F298D@tzi.org> Date: Tue, 14 Dec 2010 17:55:48 +0100 Message-ID: <002701cb9baf$c1fbd540$45f37fc0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEN7BSLFnikQwj6I9nbEQJN1UKpgGHGDKJk6K1ulA= Content-Language: de Subject: Re: [core] CoAP and messages sizes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:54:07 -0000 OK, thank you for correcting that! Nevertheless, I would still vote for having block mechanism for both directions, independent of the method. Supporting large messages is = (from my perspective) an independent feature and should not rely on method or direction. This would always assum a specific scenario and semantic of = the content of the response on e.g. a GET and not aims at defining a generic mechanism which is more flexible. Best, Guido=20 > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Dienstag, 14. Dezember 2010 17:42 > An: Guido Moritz > Cc: 'core' > Betreff: Re: [core] CoAP and messages sizes >=20 > On Dec 14, 2010, at 17:31, Guido Moritz wrote: >=20 > > (3) The CoAP block option supports only for large Responses, not for > > Requests (Right?) >=20 > Right now, -block applies to response bodies in GET, and request = bodies in > PUT/POST. >=20 > (2.2, page 7:) > In a PUT or POST transfer, the Block option refers to the body in = the > request, i.e., there is no way to perform a block-wise retrieval of > the body of the response. Servers that do need to supply large > bodies in response to PUT/POST SHOULD therefore be employing > redirects. >=20 > In Beijing, we said we didn't really want to add the redirect = mechanisms now. > So, as -block is defined now, there is no support for transferring a = large > response on a PUT or POST. >=20 > Gruesse, Carsten From trac@tools.ietf.org Wed Dec 15 06:58:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0D23A7053 for ; Wed, 15 Dec 2010 06:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 kTQJGfxhhPpA for ; Wed, 15 Dec 2010 06:58:24 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8CFC73A6F99 for ; Wed, 15 Dec 2010 06:58:24 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PSspq-0001OG-Lf; Wed, 15 Dec 2010 07:00:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 15 Dec 2010 15:00:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/51#comment:2 Message-ID: <066.68306a8bf04dae21bce8a0b64a334635@tools.ietf.org> References: <057.4b7183120354df949e6f1eceb1905167@tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <057.4b7183120354df949e6f1eceb1905167@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #51 (closed): Section 2 organization 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, 15 Dec 2010 14:58:25 -0000 #51: Section 2 organization Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Section 2 and other sections were re-organized for easier understanding for people new to CoAP and better reference for all. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: trivial | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Wed Dec 15 10:32:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443A228C1F3 for ; Wed, 15 Dec 2010 10:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 faStfVIzfv96 for ; Wed, 15 Dec 2010 10:32:48 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A600828C1F1 for ; Wed, 15 Dec 2010 10:32:48 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PSwBH-0001dP-3i; Wed, 15 Dec 2010 10:34:27 -0800 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: hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 15 Dec 2010 18:34:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/62#comment:1 Message-ID: <066.cdb5d8f45020c74e1d66c4e9a1019e8e@tools.ietf.org> References: <057.d26408d9e353ca9909f2d305c8811103@tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <057.d26408d9e353ca9909f2d305c8811103@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #62 (new): Uri-Scheme 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, 15 Dec 2010 18:32:49 -0000 #62: Uri-Scheme option Changes (by cabo@…): * owner: => hartke@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Wed Dec 15 11:22:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01FD28C1F7 for ; Wed, 15 Dec 2010 11:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 YYpHnf9xo5Oa for ; Wed, 15 Dec 2010 11:22:27 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F14F428C1C5 for ; Wed, 15 Dec 2010 11:22:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PSwxL-0002KE-QK; Wed, 15 Dec 2010 11:24:07 -0800 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: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 15 Dec 2010 19:24:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/30#comment:2 Message-ID: <066.4b4e2aa9b902230ac059400caa0a5f56@tools.ietf.org> References: <057.95e09aa7bf9ef22eefecd576ea57db61@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <057.95e09aa7bf9ef22eefecd576ea57db61@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #30 (new): Max-Age 0-4 bytes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 19:22:28 -0000 #30: Max-Age 0-4 bytes Changes (by hartke@…): * owner: zach@… => hartke@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Wed Dec 15 11:22:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526C628C1C5 for ; Wed, 15 Dec 2010 11:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 jmxxcEcPHB25 for ; Wed, 15 Dec 2010 11:22:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 732F128C17F for ; Wed, 15 Dec 2010 11:22:49 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PSwxj-0003Re-Kb; Wed, 15 Dec 2010 11:24:31 -0800 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: hartke@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 15 Dec 2010 19:24:31 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/52#comment:2 Message-ID: <066.1cab044c49d256db64ac68211d98bfd3@tools.ietf.org> References: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <057.7877dadaee8c1a49ad3c621003bde997@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #52 (new): How strict to make POST definition? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 19:22:50 -0000 #52: How strict to make POST definition? Changes (by hartke@…): * owner: zach@… => hartke@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Wed Dec 15 11: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 E156E28C1F7 for ; Wed, 15 Dec 2010 11:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 Y1OHZESV+ikS for ; Wed, 15 Dec 2010 11:23:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 266A528C17F for ; Wed, 15 Dec 2010 11:23:07 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PSwy2-0004UR-5a; Wed, 15 Dec 2010 11:24:50 -0800 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: hartke@tzi.org X-Trac-Project: core Date: Wed, 15 Dec 2010 19:24:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/75#comment:1 Message-ID: <062.75886a558cf5a4f77bb3e44a39ea415c@tools.ietf.org> References: <053.310dac6d65b7eb7bd1bd723e299cee6d@tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <053.310dac6d65b7eb7bd1bd723e299cee6d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #75 (new): Error in Section 3.2.5. 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, 15 Dec 2010 19:23:08 -0000 #75: Error in Section 3.2.5. Changes (by hartke@…): * owner: zach@… => hartke@… -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: defect | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac@tools.ietf.org Wed Dec 15 11:24:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946DA28C1F9 for ; Wed, 15 Dec 2010 11:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 4De7pMxWAr2v for ; Wed, 15 Dec 2010 11:24:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F3BA928C17F for ; Wed, 15 Dec 2010 11:24:48 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PSwzg-0002HR-39; Wed, 15 Dec 2010 11:26:32 -0800 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, hartke@tzi.org X-Trac-Project: core Date: Wed, 15 Dec 2010 19:26:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/47#comment:1 Message-ID: <066.9c32887fdd4aeb3911f9bb520b114396@tools.ietf.org> References: <057.bc5380c6c85bd757f33164f373868a0c@tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.bc5380c6c85bd757f33164f373868a0c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] block #47 (new): Benefits to introduction 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, 15 Dec 2010 19:24:49 -0000 #47: Benefits to introduction Changes (by hartke@…): * owner: => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: defect | Status: new Priority: major | Milestone: Component: block | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Wed Dec 15 11:26: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 887CF28C1F7 for ; Wed, 15 Dec 2010 11:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 lKsnsZz58YOM for ; Wed, 15 Dec 2010 11:26:38 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DDD3B28C17F for ; Wed, 15 Dec 2010 11:26:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PSx1R-00011K-85; Wed, 15 Dec 2010 11:28:21 -0800 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, hartke@tzi.org X-Trac-Project: core Date: Wed, 15 Dec 2010 19:28:21 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/60#comment:1 Message-ID: <066.29c3bbd0192729ba4a7cb48c6f55f5be@tools.ietf.org> References: <057.b16a799c382877519fb8cb657d149a2b@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <057.b16a799c382877519fb8cb657d149a2b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] coap #60 (new): Access control and proxy caches 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, 15 Dec 2010 19:26:39 -0000 #60: Access control and proxy caches Changes (by hartke@…): * owner: => zach@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: major | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Dec 18 07:24: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 B20A73A6AF6 for ; Sat, 18 Dec 2010 07:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 TcgiAU8ylBrW for ; Sat, 18 Dec 2010 07:24:52 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 056773A6AF5 for ; Sat, 18 Dec 2010 07:24:52 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PTygA-000624-GX; Sat, 18 Dec 2010 07:26:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, cabo@tzi.org X-Trac-Project: core Date: Sat, 18 Dec 2010 15:26:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/44#comment:1 Message-ID: <066.cbf60c96fbe828ba992ea0e3fc17ace3@tools.ietf.org> References: <057.5368cb3fe031bdae8ac56f6b7d67d322@tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.5368cb3fe031bdae8ac56f6b7d67d322@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] block #44 (closed): How to estimate the size of a representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 15:24:52 -0000 #44: How to estimate the size of a representation Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: In Beijing, we said (copied from draft minutes): We had a bit of discussion of size estimates (slide 47, #44), one proposal was to add a new option, the alternative is to add size information as a target attribute to the link-format -- could find out size estimate in discovery, but not necessarily current. In most applications we have seen so far that would work well. For an option, we would need to decide whether this is exact, or a maximum etc., but what are the use cases? Decide on the list. draft-ietf-core-link-format-02.txt now has a "sz" target attribute, so we now have a way to find out the expected size during discovery. So that part of this ticket is resolved. In the 2010-11-24 Webex call, we briefly discussed this again, and didn't find a good use case that would require adding an option to provide a more dynamic indication of the size. Even if there were such a use case, such an option would be entirely independent of the workings of the block draft, so there is no need to make such a decision before finishing -block -- the option can be added later at any time. So for the -block draft, the disposition for such an additional option should be WONTFIX. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: major | Milestone: Component: block | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac@tools.ietf.org Sat Dec 18 08:40:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB4F3A6B32 for ; Sat, 18 Dec 2010 08:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 XUdJSwxftUFK for ; Sat, 18 Dec 2010 08:40:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3C8313A6B2F for ; Sat, 18 Dec 2010 08:40:54 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PTzrm-00068u-9y; Sat, 18 Dec 2010 08:42:42 -0800 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, hartke@tzi.org X-Trac-Project: core Date: Sat, 18 Dec 2010 16:42:42 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/47#comment:2 Message-ID: <066.37b57bc7b84295357fe5e2951ba253bb@tools.ietf.org> References: <057.bc5380c6c85bd757f33164f373868a0c@tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <057.bc5380c6c85bd757f33164f373868a0c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] block #47 (closed): Benefits to introduction 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: Sat, 18 Dec 2010 16:40:55 -0000 #47: Benefits to introduction Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Addressed in SVN r45, to become block-01. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: defect | Status: closed Priority: major | Milestone: Component: block | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From dnl_dnl@libero.it Sat Dec 18 09:15: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 2CF193A6B3F for ; Sat, 18 Dec 2010 09:15:57 -0800 (PST) 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 ntLeh+ojnKk2 for ; Sat, 18 Dec 2010 09:15:56 -0800 (PST) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by core3.amsl.com (Postfix) with ESMTP id 283C43A6B3E for ; Sat, 18 Dec 2010 09:15:55 -0800 (PST) Received: from wmail56 (172.31.0.247) by cp-out4.libero.it (8.5.107) (authenticated as dnl_dnl@libero.it) id 4D0162A500C41A42 for core@ietf.org; Sat, 18 Dec 2010 18:17:43 +0100 Message-ID: <16181812.3422561292692663882.JavaMail.defaultUser@defaultHost> Date: Sat, 18 Dec 2010 18:17:43 +0100 (CET) From: "dnl_dnl@libero.it" To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 160.80.133.165 X-Mailman-Approved-At: Sun, 19 Dec 2010 12:39:14 -0800 Subject: [core] option lenght problem X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "dnl_dnl@libero.it" List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 20:17:41 -0000 hy to all, i need an help for the implemtation of the coap, in particularly the lenght of the option code is 4 bit for the code and other 4 bit for the lenght of the option value( 1byte in total), now if the lenght of the option value is more than 15 we need to add another byte so in total 16(bit)[short] so i need to know: if a client sent a short how can a server know if it is a short or a byte? example client sent an option value with the lenght of 20 +---+---+---+---+---+---+---+---+---+--- | option delta | 1 0100 | length > 15 | +---+---+---+---+---+---+---+---+---+--- now i cant represent 20 with 4 bit i need to add other 8 bit, now the option delta and the lenght as to become a short so that i can represent 20, i want to know how the server knows when a client are sending a short? i hope someone can help bye thanks From cabo@tzi.org Sun Dec 19 12:45: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 513A63A68DA for ; Sun, 19 Dec 2010 12:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.436 X-Spam-Level: X-Spam-Status: No, score=-106.436 tagged_above=-999 required=5 tests=[AWL=-0.187, 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 dzcCCdha1i+f for ; Sun, 19 Dec 2010 12:45:58 -0800 (PST) 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 026A93A68D7 for ; Sun, 19 Dec 2010 12:45:57 -0800 (PST) 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 oBJKlgHK018116; Sun, 19 Dec 2010 21:47:42 +0100 (CET) Received: from [192.168.217.101] (p5489AFB2.dip.t-dialin.net [84.137.175.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 78CE1C15; Sun, 19 Dec 2010 21:47:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <16181812.3422561292692663882.JavaMail.defaultUser@defaultHost> Date: Sun, 19 Dec 2010 21:47:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7CA8D595-1624-488A-B1BF-BE8FA3C0A9D1@tzi.org> References: <16181812.3422561292692663882.JavaMail.defaultUser@defaultHost> To: "dnl_dnl@libero.it" X-Mailer: Apple Mail (2.1082) Cc: core@ietf.org Subject: Re: [core] option lenght problem X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 20:45:59 -0000 Hi, Section 3.2 of coap-03 says: Each option has the following format: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | option delta | length | for 0..14 +---+---+---+---+---+---+---+---+ for 15..270: +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | option delta | 1 1 1 1 | length - 15 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 6: Header option format So to send an option with length of 20, send +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | option delta | 1 1 1 1 | 20 - 15 =3D 5 = | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The receiver can recognize the extended format by the presence of the = number 15 (0b1111) in the second nibble. Gruesse, Carsten From likepeng@huawei.com Sun Dec 19 17:02:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C8E3A6990 for ; Sun, 19 Dec 2010 17:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=1.397, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 jri1al+yey5Z for ; Sun, 19 Dec 2010 17:02:53 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E9C343A698E for ; Sun, 19 Dec 2010 17:02:52 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LDP00864CBMR6@szxga04-in.huawei.com> for core@ietf.org; Mon, 20 Dec 2010 09:04:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LDP00J0HCBMJQ@szxga04-in.huawei.com> for core@ietf.org; Mon, 20 Dec 2010 09:04:34 +0800 (CST) Received: from l43852p ([10.70.109.72]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LDP00BQYCBJ17@szxml06-in.huawei.com> for core@ietf.org; Mon, 20 Dec 2010 09:04:34 +0800 (CST) Date: Mon, 20 Dec 2010 09:04:31 +0800 From: Kepeng Li In-reply-to: <7CA8D595-1624-488A-B1BF-BE8FA3C0A9D1@tzi.org> To: core@ietf.org Message-id: <002d01cb9fe1$dc241000$946c3000$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcufvgXLfkpPn6Y2SAqcNpd6Fv/cBwAI0Zwg x-cr-hashedpuzzle: AI5X AlvT Cgb0 Cs93 DidX D+Sg EdLx Fkfq Fqee G+ml IHsQ I0Z9 JZzz J77k J+vv KRC/; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {569A2AE1-CD81-4671-BEF6-7014436793BF}; bABpAGsAZQBwAGUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Mon, 20 Dec 2010 01:04:28 GMT; WwBjAG8AcgBlAF0AIABCAGwAbwBjAGsAIABTAGkAegBlACAATgBlAGcAbwB0AGkAYQB0AGkAbwBuAA== x-cr-puzzleid: {569A2AE1-CD81-4671-BEF6-7014436793BF} References: <16181812.3422561292692663882.JavaMail.defaultUser@defaultHost> <7CA8D595-1624-488A-B1BF-BE8FA3C0A9D1@tzi.org> Subject: [core] Block Size Negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 01:02:54 -0000 Hi all, I want to get a help to know that, in a Put/Post, do we need to negotiate the block size (SZX)? I notice that in the spec, only Get is mentioned, but there is no text about Put/Post. >> To influence the block size used in response to a GET request, the requestor uses the Block option, giving the desired size, a block number of zero and an M bit of zero. Thanks, Kind Regards Kepeng