From trac+core@trac.tools.ietf.org Fri Feb 1 17:13:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F0821E805A for ; Fri, 1 Feb 2013 17:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2F+PGKqW36y for ; Fri, 1 Feb 2013 17:13:57 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EE70E21E8049 for ; Fri, 1 Feb 2013 17:13:56 -0800 (PST) Received: from localhost ([127.0.0.1]:52800 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U1Rg3-0008Kf-IT; Sat, 02 Feb 2013 02:13:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Sat, 02 Feb 2013 01:13:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/276 Message-ID: <053.6afac6cda5f51cd8ab0bb72a4babdcfe@trac.tools.ietf.org> X-Trac-Ticket-ID: 276 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130202011356.EE70E21E8049@ietfa.amsl.com> Resent-Date: Fri, 1 Feb 2013 17:13:56 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #276: Use of EXCHANGE_LIFETIME in reordering detection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 01:13:57 -0000 #276: Use of EXCHANGE_LIFETIME in reordering detection The mechanism for reordering detection in observe-07 depends on EXCHANGE_LIFETIME and that both client and server use the same value for this variable. If the client and the server do not use the same value for EXCHANGE_LIFETIME, things break (see offlist13j). EXCHANGE_LIFETIME is calculated (among other variables) from ACK_TIMEOUT. However, if an implementation dynamically adjusts the RTO (= ACK_TIMEOUT) based on RTT samples (see draft-bormann-core-cocoa-00), then the value of EXCHANGE_LIFETIME changes dynamically as well. So, with RTO Estimation, it is basically impossible for the client and the server to keep their EXCHANGE_LIFETIME values in sync. Solution: Define a new variable in -observe to be used instead of EXCHANGE_LIFETIME for reordering detection. Its value MUST be no less than the maximum EXCHANGE_LIFETIME that can result from dynamically adjusting ACK_TIMEOUT. Client and server MUST use the same value. Give a fixed default value based on default CoAP transmission parameters. If in the future endpoints are negotiating CoAP transmission parameters, this value needs to be negotiated as well. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-07 Component: observe | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Feb 2 10:18:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1631121F852B for ; Sat, 2 Feb 2013 10:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFTcAAydaHZU for ; Sat, 2 Feb 2013 10:18:29 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 368CE21F851C for ; Sat, 2 Feb 2013 10:18:28 -0800 (PST) Received: from localhost ([127.0.0.1]:36949 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U1hfX-00061Q-RF; Sat, 02 Feb 2013 19:18:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Sat, 02 Feb 2013 18:18:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/276#comment:1 Message-ID: <068.f74beb14286b8e5612b8fda197cb0a47@trac.tools.ietf.org> References: <053.6afac6cda5f51cd8ab0bb72a4babdcfe@trac.tools.ietf.org> X-Trac-Ticket-ID: 276 In-Reply-To: <053.6afac6cda5f51cd8ab0bb72a4babdcfe@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130202181829.368CE21F851C@ietfa.amsl.com> Resent-Date: Sat, 2 Feb 2013 10:18:28 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #276: Use of EXCHANGE_LIFETIME in reordering detection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 18:18:30 -0000 #276: Use of EXCHANGE_LIFETIME in reordering detection Comment (by hartke@tzi.org): Actually, the value does not necessarily need to be no less than the maximum EXCHANGE_LIFETIME, since the sequence number must be updated each time a notification is retransmitted. The value must be no less than the maximum time a datagram is expected to take from the start of its transmission to the completion of its reception (MAX_LATENCY). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-07 Component: observe | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From darconeous@gmail.com Sat Feb 2 11:46:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F25721F854E for ; Sat, 2 Feb 2013 11:46:19 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0+fbhdJ1ifl for ; Sat, 2 Feb 2013 11:46:18 -0800 (PST) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id EB9C321F854C for ; Sat, 2 Feb 2013 11:46:17 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id p5so2134759dak.19 for ; Sat, 02 Feb 2013 11:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=3toAYX/Yf8j40zsgisxu1qk9MRoSFAnxJuBeB+UKJsA=; b=ZH+B47U4fI61kvqwD/9M3uWiqrlXfIYfgkMj2bcJhX3Cf6QFZvA0AVK2KLmin6OsQD AkbgnqihFmgdMv3igx2PX5dFaFEVv1Y1vypqOkDxNV/xSpPXaMmf9wUGADUihfIu3nwb S6hiFhZJQT3dvUcf5H92nuSwWDSGPhtKu8NcxpXpxXhfXXEZlErVTCFXfg4HuPCBOYrB PdbUuwQrC1UDk3C2aPlHI+ESUfLQxalU5NTHph9GCSWoXeifAuV7HSw6mdz0Ivv54zmz sQOnzuBxDIq7zIUKw+BTG/P7dP8bExLAMZ+lU9ozYR3IPFAc1SxJi+vvk6i8RRYg7wLL tDSw== X-Received: by 10.68.253.137 with SMTP id aa9mr42949427pbd.102.1359834366835; Sat, 02 Feb 2013 11:46:06 -0800 (PST) Received: from [172.30.96.30] (c-67-174-221-32.hsd1.ca.comcast.net. [67.174.221.32]) by mx.google.com with ESMTPS id sk1sm12516848pbc.0.2013.02.02.11.46.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Feb 2013 11:46:06 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: Date: Sat, 2 Feb 2013 11:46:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <76B4185D-C1CF-4DF8-89C2-8C610D7A3669@gmail.com> To: Maciej Wasilak X-Mailer: Apple Mail (2.1499) Cc: IETF CoRE Working Group Subject: Re: [core] Apparent race condition in draft-ietf-core-block-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 19:46:19 -0000 Hello Maciej. Sorry for the late reply. On Jan 23, 2013, at 12:31 PM, Maciej Wasilak wrote: > As far as I understand all stateful blockwise transfers should be = identified now by a tuple (client, uri_path), where client is another = tuple (address, port). I agree that introducing proxies might lead to = race conditions. It is true for PUT/POST transfers, but also for = stateful GET transfers (as in draft-ietf-core-block-10: "The server may = identify the sequence by the combination of the requesting end-point and = the URI being the same in each block-wise request."). So if two GET = requests (for example with different uri-query) are sent through a = proxy, server also won't be able to tell them apart.=20 This is true as well, but with GET transfers there are mechanisms that can be used to work around this, such as caching. However, a non-caching proxy server could easily run afoul of this problem with a blockwise GET. > Some practical workaround might be sending POST/PUT requests to = subresources instead of a base resource:=20 > POST /data-sink/sensor1=20 > POST /data-sink/sensor2 > where sensor1 and sensor2 are temporary labels, instead of: > POST /data-sink > However both proxy and server need to understand these labels, which = might be complicated. Yes, you could work around this issue at the application level, but it would be profoundly unfortunate for such a hack to be necessary in the first place. If we have the opportunity to truly fix this at this level before the drafts become standards, I think we should. An ideal solution would require no changes for transfers which disambiguation is not necessary. I have bounced a few ideas for solutions off of Carsten, but he seems to be rather busy lately. The solution I brought up was to add a new option called a 'stoken'. The solution has the following pros and cons: ### Pros ### * Appears to solve all of the problems I described earlier. * Has additional benefits for constrained servers serving dynamic content. * Client doesn't need prior knowledge if the option is necessary because the client only uses the option when told to by the server. * Works with both block1 and block2. * Not conceptually limited to the block protocol. For example, it could be used for canceling individual observations (although that would only really be a problem if you were using a non-caching proxy as far as I can tell) * Option would only be used by the server when required, so constrained clients may leave it out and still continue to work in the majority of cases. * Constrained Clients which don't implement the stoken option (and have an NSTART of 1) could still benefit from the use of the option by using a proxy which supported the stoken option. ### Cons ### * Adds yet another option. * Clients wanting to implement this would need to be able to store an additional ~10 bytes of state between receipt of a response and the sending of the next related request. A more formalized explanation of the semantics of the option are = described below. I'd love some feedback, especially about any potential edge cases = or other issues. -------------------- * Option Name: `Stoken` * Option Number: TBD * Critical: TBD * Unsafe: No * Data: Opaque 0-8 bytes * Default value: Empty The `stoken` option is used when a server needs to associate a subsequent request as being definitively related to a specific prior request. The specific value of the stoken option is meaningful only to the server and is entirely opaque to the client. Only sequential requests can be related using this mechanism. If a server receives a request that it needs to definitively associate with a subsequent request, it will add a stoken option to the response (the specific value of which is implementation specific). When the client sends the next request in the series, it will include the stoken option from the previously received response. The server can then use the stoken value to relate the current request to the previous request. This process can associate an indefinite number of requests. The server is not restricted to using the same stoken value for each response in the series. CLIENT SERVER | | | CON [MID=3D1234], GET, /status ------> | | | | <------ ACK [MID=3D1234], 2.05 Content | | Stoken:5678 Block2:0/1/128 | | | | CON [MID=3D1235], GET, /status ------> | | Stoken:5678 Block2:1/1/128 | | | | <------ ACK [MID=3D1235], 2.05 Content | | Stoken:9012 Block2:1/1/128 | | | | CON [MID=3D1236], GET, /status ------> | | Stoken:9012 Block2:2/0/128 | | | | <------ ACK [MID=3D1236], 2.05 Content | | Block2:2/0/128 | Figure 1. Block2 with Stoken CLIENT SERVER | | | CON [MID=3D1237], PUT, /options ------> | | Block1:0/1/128 | | | | <------ ACK [MID=3D1237], 2.05 Content | | Stoken:1111 Block1:0/1/128 | | | | CON [MID=3D1238], PUT, /options ------> | | Stoken:1111 Block1:1/1/128 | | | | <------ ACK [MID=3D1238], 2.05 Content | | Stoken:2222 Block1:1/1/128 | | | | CON [MID=3D1239], PUT, /options ------> | | Stoken:2222 Block1:2/0/128 | | | | <------ ACK [MID=3D1239], 2.05 Content | | Block1:1/0/128 | Figure 2. Block1 with Stoken =46rom a different perspective, the stoken option may be used to store server state about the ongoing transaction, without actually storing any state in the server. This is especially useful when serving potentially large content---like link-formats---dynamically, without server-side state. Example: Let's say we have a large list of links that is dynamically generated. Each link entry is a variable size. With the stoken parameter, we can implement this efficiently without any state on the server by storing the index of the last item along with the number of bytes from the last item we managed to add to the end of the returned block. When the client sends the request for the next block, we will know exactly where we left off from. Without the stoken parameter we would have either had to start over from scratch on each request (dramatically increasing the resources required to serve later requests) or store the state for each transaction, keyed off of the client IP address and port (Which I have just shown to be somewhat unreliable). -- Robert >=20 > Best Regards >=20 > Maciej Wasilak > 2012/12/24 Robert Quattlebaum >> Hello everyone, >>=20 >> I just wanted to bring up a race condition apparently present in >> the current blockwise transfer draft. However, even if you are not >> interested in draft-ietf-core-block, you may want to read over this >> email anyway: Similar problems may be present in protocols which >> need the server to associate multiple messages as being a part of >> the same logical request. For now I'll limit the discussion to >> draft-ietf-core-block-10. >>=20 >> Previously, the token field (as well as the source IP address and >> port) could be used by the server to correlate multiple messages >> that were a part of the same logical request ("token-affinity"). >> In this sense the token field was not really opaque because the >> server was relying on the value of the token to not change between >> subsequent messages in the same logical request. However, this >> semantic-entanglement had the benefit of ensuring truly atomic >> behavior of requests which consist of multiple messages, without >> depending on artificial limitations on how the protocol should be >> used or the behavior of a specific transport layer. >>=20 >> At some point over the past year (Forgive me, I haven't been paying >> attention), the semantics of the token parameter was clarified to >> be entirely opaque (meaning that only the client's address/port >> could be used for determining which messages are a part of the same >> blocked request). This was a reasonable change because it allows >> client implementations to be more flexible. However, without further >> clarification or additional mechanisms, this change leads to >> undefined/unreliable behavior in certain cases. >>=20 >> Consider the case where you have a LoWPAN where nodes regularly >> dump gathered information to a CoAP server in "the cloud" via a >> CoAP-CoAP proxy. If two (or more) nodes try to perform a large POST >> (using Block1) to the same CoAP URL thru the proxy at the same time, >> the destination machine in the cloud has no way to differentiate >> the messages as being two independent atomic requests. >>=20 >> In a previous discussion off-list, Carsten suggested that the proxy >> could identify the start of subsequent requests as potentially >> conflicting and use a different source port for each conflicting >> request sent from the proxy, but this technique only works if the >> cloud-side transport layer uses the UDP/IP transport---this technique >> would not work if the proxy was sending requests to the cloud via >> CoAP-over-SMS, as described in section 14 of >> draft-becker-core-coap-sms-gprs-02. >>=20 >> I think the root of this problem is the reliance on information >> from the transport layer in determining which individual messages >> belong to the same logical request. Doing this just happens to work >> out in most cases. However, because these edge cases are transient >> in nature, diagnosing such problems in the field may be very = difficult >> and frustrating. Sure, there are work-arounds, but they have specific >> disadvantages which may not be obvious. >>=20 >> The bottom line is that by refining the semantics of the token field >> to no longer allow the server to use token-affinity to associate >> multiple messages to logical requests, a race condition has been >> introduced into the protocol. This race condition was hidden by the >> fact that, by using the address/port information from the transport >> layer, things *usually* work just fine. Usually, but not always. >>=20 >> All that being said, I don't necessarily believe that reverting the >> token behavior is necessarily the right solution to this problem: >> Allowing the client to use the token to keep track of state on a >> message-per-message basis is useful. The trick is giving the same >> flexibility to the server: If we can't rely entirely on the transport >> layer information to associate logically-related messages (and we >> can't use the token) then what should be used? >>=20 >> We could always simply document this class of problems in the draft >> so that implementors are aware that they may need to work around >> it, but I worry that this may be the first of a class of similar >> race conditions if this issue is not addressed directly. >>=20 >> Thoughts? >>=20 From trac+core@trac.tools.ietf.org Sat Feb 2 15:47:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636A221F8450 for ; Sat, 2 Feb 2013 15:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgnpoeavBXVN for ; Sat, 2 Feb 2013 15:47:20 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 968C921F844F for ; Sat, 2 Feb 2013 15:47:20 -0800 (PST) Received: from localhost ([127.0.0.1]:33039 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U1mnn-0003WM-4P; Sun, 03 Feb 2013 00:47:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Sat, 02 Feb 2013 23:47:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/276#comment:2 Message-ID: <068.ba637ad61d49e1f5b31c8cd4425a5c8a@trac.tools.ietf.org> References: <053.6afac6cda5f51cd8ab0bb72a4babdcfe@trac.tools.ietf.org> X-Trac-Ticket-ID: 276 In-Reply-To: <053.6afac6cda5f51cd8ab0bb72a4babdcfe@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130202234720.968C921F844F@ietfa.amsl.com> Resent-Date: Sat, 2 Feb 2013 15:47:20 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #276: Use of EXCHANGE_LIFETIME in reordering detection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 23:47:21 -0000 #276: Use of EXCHANGE_LIFETIME in reordering detection Comment (by hartke@tzi.org): Converse argument: if the value was no less than the maximum EXCHANGE_LIFETIME, then the sequence number would not need to be updated each time a notification is retransmitted. This is already the case if the sequence number is based on a per-resource variable that is incremented each time the resource changes, and the resource did not undergo a change before the notification is retransmitted. So the argument is relevant only in the case where the sequence number is based on the timestamp from a local clock. However, observe-07 currently requires that "a server uses a number of retransmit attempts (MAX_RETRANSMIT) such that removing a client from the list of observers before Max-Age ends is avoided." Since there is no limit on MAX_RETRANSMIT, there is no maximum EXCHANGE_LIFETIME. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-07 Component: observe | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Feb 3 12:24:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CB321F87DC for ; Sun, 3 Feb 2013 12:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n9-hEiTs50k for ; Sun, 3 Feb 2013 12:24:21 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 674D121F87D3 for ; Sun, 3 Feb 2013 12:24:21 -0800 (PST) Received: from localhost ([127.0.0.1]:36333 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U266t-00074m-Oy; Sun, 03 Feb 2013 21:24:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Sun, 03 Feb 2013 20:24:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/235#comment:1 Message-ID: <066.89872125b64d83634d34dcb394d61782@trac.tools.ietf.org> References: <051.aebb41ca9cf09eeb9e4c6d482e343ba5@trac.tools.ietf.org> X-Trac-Ticket-ID: 235 In-Reply-To: <051.aebb41ca9cf09eeb9e4c6d482e343ba5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130203202421.674D121F87D3@ietfa.amsl.com> Resent-Date: Sun, 3 Feb 2013 12:24:21 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #235: Avoid extending the base standard retransmission rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 20:24:22 -0000 #235: Avoid extending the base standard retransmission rules Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1190]: Closes #235 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | observe@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: minor | Version: observe-05 Component: observe | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Feb 3 14:13:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EF821F88A1 for ; Sun, 3 Feb 2013 14:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4vOYhzDrU2L for ; Sun, 3 Feb 2013 14:13:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 36A4B21F889D for ; Sun, 3 Feb 2013 14:13:05 -0800 (PST) Received: from localhost ([127.0.0.1]:43127 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U27o6-0005kZ-FM; Sun, 03 Feb 2013 23:13:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, fluffy@cisco.com, hartke@tzi.org X-Trac-Project: core Date: Sun, 03 Feb 2013 22:13:02 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/221#comment:2 Message-ID: <066.6d91a5fba47b33a452a0f3eb860a8ec4@trac.tools.ietf.org> References: <051.96050ca332dbb50866094e054b75514d@trac.tools.ietf.org> X-Trac-Ticket-ID: 221 In-Reply-To: <051.96050ca332dbb50866094e054b75514d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, fluffy@cisco.com, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130203221305.36A4B21F889D@ietfa.amsl.com> Resent-Date: Sun, 3 Feb 2013 14:13:05 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #221: Occasionally sending CON is not just a security consideration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 22:13:06 -0000 #221: Occasionally sending CON is not just a security consideration Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1193]: Closes #221 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | observe@tools.ietf.org Type: protocol | Status: closed defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-05 Component: observe | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 4 03:27:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33D121F85E2 for ; Mon, 4 Feb 2013 03:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqHVz8z8jUcJ for ; Mon, 4 Feb 2013 03:27:49 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 39B5221F8442 for ; Mon, 4 Feb 2013 03:27:48 -0800 (PST) Received: from localhost ([127.0.0.1]:40826 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2KDC-0005uz-KH; Mon, 04 Feb 2013 12:27:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Mon, 04 Feb 2013 11:27:46 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/271#comment:1 Message-ID: <075.3c850080f7fc3c2ac2f1b1bfab6ed51c@trac.tools.ietf.org> References: <060.098bc8881df48568161fdd11a361f525@trac.tools.ietf.org> X-Trac-Ticket-ID: 271 In-Reply-To: <060.098bc8881df48568161fdd11a361f525@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #271: Review groupcomm requirements language X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 11:27:49 -0000 #271: Review groupcomm requirements language Changes (by esko.dijk@philips.com): * owner: draft-ietf-core-groupcomm@tools.ietf.org => esko.dijk@philips.com * status: new => assigned Comment: Use of requirements language was reviewed by the authors; it is commonly used in informational RFCs (e.g. 6663, 5867, 3576) therefore propose to keep it. Requirements languagage serves these purposes in the GroupComm I-D: 1. to clarify/quote/'echo' relevant normative requirements from other RFCs/I-Ds. 2. to establish clear guidelines for a recommended way of using CoAP group communication; where implementers are free to follow these recommendations or not. To claim conformance to these guidelines an implementation MUST address all normative requirements stated. -- -----------------------------------+------------------------------------ Reporter: esko.dijk@philips.com | Owner: esko.dijk@philips.com Type: task | Status: assigned Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 4 03:32:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820E521F8444 for ; Mon, 4 Feb 2013 03:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDddBypoGW0H for ; Mon, 4 Feb 2013 03:32:17 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9B21F8430 for ; Mon, 4 Feb 2013 03:32:16 -0800 (PST) Received: from localhost ([127.0.0.1]:40983 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2KHV-0006Xj-Qj; Mon, 04 Feb 2013 12:32:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 04 Feb 2013 11:32:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/187#comment:1 Message-ID: <075.b11b85af02d2bc71b1a301f68b6f29f9@trac.tools.ietf.org> References: <060.5ebafee4b484555221fd2bac521f9baa@trac.tools.ietf.org> X-Trac-Ticket-ID: 187 In-Reply-To: <060.5ebafee4b484555221fd2bac521f9baa@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130204113216.F3E9B21F8430@ietfa.amsl.com> Resent-Date: Mon, 4 Feb 2013 03:32:16 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #187: Identify deployment scenarios where IP multicast may NOT work well X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 11:32:17 -0000 #187: Identify deployment scenarios where IP multicast may NOT work well Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Added a new section 3.9 (Exceptions) that highlights cases where IP Multicast is not available; in groupcomm-05. One identified case is mesh network with RPL Non-Storing mode routing and no other routing/forwarding protocols. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 4 03:35:29 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B39321F869B for ; Mon, 4 Feb 2013 03:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkcaZDMNCTCd for ; Mon, 4 Feb 2013 03:35:28 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6981321F8467 for ; Mon, 4 Feb 2013 03:35:28 -0800 (PST) Received: from localhost ([127.0.0.1]:41328 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2KKc-0001ro-W4; Mon, 04 Feb 2013 12:35:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 04 Feb 2013 11:35:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/277 Message-ID: <060.b621de78a4e36bdb7376f838715098f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 277 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130204113528.6981321F8467@ietfa.amsl.com> Resent-Date: Mon, 4 Feb 2013 03:35:28 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #277: Security section to include threats and threat mitigations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 11:35:29 -0000 #277: Security section to include threats and threat mitigations Restructuring / enhancement needed of section Security to include threats and mitigations. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 4 04:21:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4726321F867B for ; Mon, 4 Feb 2013 04:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwmQuJtivWFn for ; Mon, 4 Feb 2013 04:21:55 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8695821F861F for ; Mon, 4 Feb 2013 04:21:55 -0800 (PST) Received: from localhost ([127.0.0.1]:45183 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2L3Z-0002wo-3i; Mon, 04 Feb 2013 13:21:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 04 Feb 2013 12:21:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/277#comment:1 Message-ID: <075.a4e6c4ca8e5616d2cf2c760f2c8f4953@trac.tools.ietf.org> References: <060.b621de78a4e36bdb7376f838715098f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 277 In-Reply-To: <060.b621de78a4e36bdb7376f838715098f8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130204122155.8695821F861F@ietfa.amsl.com> Resent-Date: Mon, 4 Feb 2013 04:21:55 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #277: Security section to include threats and threat mitigations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 12:21:56 -0000 #277: Security section to include threats and threat mitigations Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in [1204] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 4 13:15:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7853621F8B0A for ; Mon, 4 Feb 2013 13:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-TEdvLxzCie for ; Mon, 4 Feb 2013 13:15:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DDDAA21F8A48 for ; Mon, 4 Feb 2013 13:15:25 -0800 (PST) Received: from localhost ([127.0.0.1]:55447 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2TNs-0001Nd-QS; Mon, 04 Feb 2013 22:15:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Mon, 04 Feb 2013 21:15:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/237#comment:1 Message-ID: <066.af4f234a688089beb86285606c9a6335@trac.tools.ietf.org> References: <051.48bbba5d4ea128746704b038a67dd534@trac.tools.ietf.org> X-Trac-Ticket-ID: 237 In-Reply-To: <051.48bbba5d4ea128746704b038a67dd534@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130204211525.DDDAA21F8A48@ietfa.amsl.com> Resent-Date: Mon, 4 Feb 2013 13:15:25 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #237: Multicast -> reference groupcomm draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 21:15:26 -0000 #237: Multicast -> reference groupcomm draft Changes (by hartke@tzi.org): * status: new => closed * resolution: => wontfix Comment: Esko and I agree with Peter that it would be interesting/useful to discuss the use of a group communication protocol in conjunction with -observe. However, with current document scopes, this scenario is out of scope for both the -observe and the -groupcomm draft. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | observe@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last | Resolution: wontfix Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 4 13:42:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2B21F8558 for ; Mon, 4 Feb 2013 13:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFM7MJimE88c for ; Mon, 4 Feb 2013 13:42:21 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EBF5721F8528 for ; Mon, 4 Feb 2013 13:42:20 -0800 (PST) Received: from localhost ([127.0.0.1]:56962 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2Tnv-00046p-NC; Mon, 04 Feb 2013 22:42:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Mon, 04 Feb 2013 21:42:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/276#comment:3 Message-ID: <068.2c907241298bbaf202f6a13ae4811cca@trac.tools.ietf.org> References: <053.6afac6cda5f51cd8ab0bb72a4babdcfe@trac.tools.ietf.org> X-Trac-Ticket-ID: 276 In-Reply-To: <053.6afac6cda5f51cd8ab0bb72a4babdcfe@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130204214220.EBF5721F8528@ietfa.amsl.com> Resent-Date: Mon, 4 Feb 2013 13:42:20 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #276: Use of EXCHANGE_LIFETIME in reordering detection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 21:42:21 -0000 #276: Use of EXCHANGE_LIFETIME in reordering detection Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: observe-08 now uses a fixed constant of 128 seconds. This is a nice, round number that is slightly larger than CoAP's MAX_RETRANSMIT (100 seconds) and TCP's MSL (120 seconds). * If a client receives a notification, and then nothing for 128 seconds, and then a second notification, then that second notification cannot originate from before the first notification. So, after 128 seconds, the client does not need to compare the sequence numbers to determine that the second notification is newer than the first one. * If a client receives a notification and then a second notification within 128 seconds, then it needs to compare the sequence numbers to determine if the second notification is newer than the first one. The largest delta between two sequence numbers that it is meaningful in 24-bit space is `2^(24-1)-1`, so the sequence numbers must not increase faster than by `2^24` in less than 256 seconds. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: closed defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-07 Component: observe | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Feb 5 04:22:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B63221F85AB for ; Tue, 5 Feb 2013 04:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJzPqQPCtX9I for ; Tue, 5 Feb 2013 04:22:42 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADF921F8609 for ; Tue, 5 Feb 2013 04:22:42 -0800 (PST) Received: from localhost ([127.0.0.1]:36435 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2hXn-0002on-5Z; Tue, 05 Feb 2013 13:22:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, cabo@tzi.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 05 Feb 2013 12:22:35 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/252#comment:2 Message-ID: <075.483c4908324acb536c8c48984fad791b@trac.tools.ietf.org> References: <060.21265d28244400dba1ada3082dcb036a@trac.tools.ietf.org> X-Trac-Ticket-ID: 252 In-Reply-To: <060.21265d28244400dba1ada3082dcb036a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, cabo@tzi.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130205122242.8ADF921F8609@ietfa.amsl.com> Resent-Date: Tue, 5 Feb 2013 04:22:42 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #252: Conflicting security requirements in groupcomm/core-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 12:22:43 -0000 #252: Conflicting security requirements in groupcomm/core-coap Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Additional work added in GroupComm svn [1210]. Describes some methods to meet the "authentication" requirement for multicast added in core-coap-13 svn [1100]. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From zach@sensinode.com Tue Feb 5 05:29:35 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDCA21F870E for ; Tue, 5 Feb 2013 05:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, MANGLED_DOMAIN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG9oqrs-J+e4 for ; Tue, 5 Feb 2013 05:29:35 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id BDCA421F8648 for ; Tue, 5 Feb 2013 05:29:34 -0800 (PST) Received: from [10.119.234.35] (static-195.22.91.10.addr.tdcsong.se [195.22.91.10]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r15DTU1d029699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2013 15:29:30 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Zach Shelby In-Reply-To: <510653E8.4060109@intec.ugent.be> Date: Tue, 5 Feb 2013 14:30:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30a64b4fc85a612b82a5ed4fe685476e@xs4all.nl> <5F948749-91FB-4687-B0F6-CD0B713E3931@sensinode.com> <7e66b0ef133d031d61a4cd103108bb0f@xs4all.nl> <14303B24-14FE-4026-BA9F-CA4444E2492D@sensinode.com> <510653E8.4060109@intec.ugent.be> To: Floris Van den Abeele X-Mailer: Apple Mail (2.1499) Cc: Core Subject: Re: [core] resource-directory-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:29:35 -0000 Hi Floris, Thanks for the RD draft feedback and implementation experience. See my = comments in-line: On Jan 28, 2013, at 11:33 AM, Floris Van den Abeele = wrote: > Hi Zach&all, >=20 > I read and implemented the draft and interpreted the usage of the con = parameter the same way as Zach did, i.e. to be used to update volatile = IP addresses thus ensuring the reachability of the registered endpoint. >=20 > I also have a couple of comments/questions about = draft-shelby-core-resource-directory-04: > * Shouldn't the default value for the con parameter in section 5.2 = also be the 'default discovery URI' as in section 4? The draft states to = use the source port as the context port, however this port will usually = be a client port and will differ from the port the endpoint is listening = on (e.g. port 60000 vs 5683).=20 > * In draft-bormann-core-simple-server-discovery-00 a definition is = given for the 'default discovery URI', I would suggest referencing it or = adding it to the document in section 4. This definition does include the = listening port instead of the source port. Well, those are different things. The default discovery URI defines the = default CoAP destination port you can expect to find an RD interface at.=20= The location of the Endpoint that you are registering which will be = exposed to a client doing an RD lookup in order to contact your Endpoint = is of course different than the location of the RD itself. So it doesn't = make sense to somehow assume that every Endpoint is at port 5683, since = many entities can host multiple Endpoints, for example a gateway type of = device.=20 The idea behind the RD registration is that the Endpoint should register = from the same socket that it is using to listen for incoming requests to = that Endpoint. Thus the source port would be correct. So far we have not = seen any implementation reasons why that is not possible. This also = saves overhead when registering, not requiring the con parameter to be = included. We have been using this model widely and it has worked great.=20= Now the con parameter is actually meant to allow a 3rd party to register = on behalf of an Endpoint. For example you might have a Proxy RD that = accepts local registrations and then registers on behalf of those = Endpoints to another RD. =20 > * Peter wrote: > In the example of sec 5.3, the last line, = ;ct=3D41;rt=3D=94lightLux;if=3D=94sensor=94 is identical = to the 2nd line in the payload of the Registration example. This = contradicts the last line of the intro of sec 5.32 Parameters (not = Paremeters) that have not changed SHOULD NOT be included in an update. = Better remove or change the last line in the Update example. >=20 > Good eye. Will change that. > I don't agree that this a contradiction, the last line of 5.32 refers = to the URI query parameters that are passed on (e.g. con, rt and lt) and = not the CoAP Payload. So in my view this shouldn't be altered. Enforcing = this on the payload as well, would seem to imply that the payload would = be a patch of some sort (which seems to be out of the scope of the = document). Yes, you are actually correct. That section is referring to the query = parameters, and not the payload.=20 I actually would like to simplify the Update further and remove the = payload completely. Just do a new Registration if the links change.=20 > * Why reuse the rt accronym for end point type? This is confusing with = the resource type that is defined in RFC 6690.=20 The reason for this is that the RD is modelled as a resource hierarchy = itself. Thus the Endpoint entry is just a resource in the RD, and thus = the Resource Type of that entry happens to describe the type of = Endpoint. You can see that when you look at the RD lookup structures, as = the Endpoints are described as RFC 6690 links. > * There is small mistake in the last example of section 6. The example = should be GET /rd-lookup/d instead of GET /rd-lookup/d > omain in the ASCII figure and the accompanying text beneath it. Fixed. Regards, Zach >=20 > Regards, > Floris=20 >=20 > On ma 24 sep 2012 14:15:36 CEST, Zach Shelby wrote: >>=20 >> On Sep 24, 2012, at 11:12 AM, peter van der Stok wrote: >>=20 >>>=20 >>> Hi Zach, >>>=20 >>> In relation to the point below, Some questions remain. >>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> In sec 5.3 the con parameter is also mentioned to update the = entry. In the case that the host:port changes completely, a new entry is = required IMO. May be remove con from update? >>>>=20 >>>>=20 >>>> The whole point of an update is that it would update a change in = the >>>> ip:port, as this can happen often. This way the endpoint name in = the >>>> RD is stable, and does not change even though the ip:port tuple >>>> changes. >>>>=20 >>>=20 >>>=20 >>> I understood that con could also be used with a scheme and a FQDN >>> e.g. con=3Dcoap://mynode.example.com >>> I hope that is correct. >>=20 >>=20 >> Sure, assuming such an FQDN exists (often times that is not the case = in M2M however). >>=20 >>>=20 >>> Following your reasoning when using host:port, then >>> by reassigning changing IP addresses continuously to the RD = end-points, the RD takes over DNS functionality? >>=20 >>=20 >> Not at all. DNS just really isn't used in M2M today, as it is usually = not practical or even possible to update DNS entries when nodes are = often changing their IPv6 address due to changes in point of attachment = or getting dynamic IP address assignment e.g. in Cellular networks. >>=20 >>>=20 >>> Would it not be better to keep DNS functionality outside the RD, use = FQDNs, and only use IP addresses when the environment does not support = DNS. >>> In the latter case I do not see the IP addresses changing very = frequently, because there is no IP provider either. >>=20 >>=20 >> In theory an RD could keep track of the IP addresses of registered = nodes using DNS, but that is really an implementation issue and not an = interface specification one. >>=20 >> Zach >>=20 >>>=20 >>>=20 >>> Greetings, >>>=20 >>> peter --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Tue Feb 5 05:32:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951D921F87A6 for ; Tue, 5 Feb 2013 05:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=2.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fDmTxfiOj3p for ; Tue, 5 Feb 2013 05:32:01 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9A21F869E for ; Tue, 5 Feb 2013 05:32:00 -0800 (PST) Received: from [10.119.234.35] (static-195.22.91.10.addr.tdcsong.se [195.22.91.10]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r15DVws4030354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2013 15:31:58 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Zach Shelby In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B76082@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Tue, 5 Feb 2013 14:32:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30a64b4fc85a612b82a5ed4fe685476e@xs4all.nl> <5F948749-91FB-4687-B0F6-CD0B713E3931@sensinode.com> <7e66b0ef133d031d61a4cd103108bb0f@xs4all.nl> <14303B24-14FE-4026-BA9F-CA4444E2492D@sensinode.com> <510653E8.4060109@intec.ugent.be> <031DD135F9160444ABBE3B0C36CED618B76082@011-DB3MPN2-081.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1499) Cc: Core Subject: Re: [core] resource-directory-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:32:01 -0000 Esko, On Jan 28, 2013, at 2:03 PM, "Dijk, Esko" wrote: > > I don't agree that this a contradiction, the last line of 5.32 = refers to the URI query parameters that are passed on (e.g. con, rt and = lt) and not the CoAP Payload. So in my view this shouldn't be altered. = Enforcing this on the payload as well, would seem to imply that the = payload would be a patch of some sort (which seems to be out of the = scope of the document). > =20 > To me it=92s not clear from the text whether the PUT request to do an = update overwrites the previous entries entirely (which would be most = RESTful) or that =93update=94 implies that only new and/or changed = resources are included in the payload. (Then I would expect a POST = rather than PUT) > Maybe an idea is allowing both PUT (to overwrite existing) or POST (to = update existing) ? In an effort to simplify this more, as in large M2M systems the Update = load can get really high, I am actually going to propose not including a = payload at all in Updates. But instead using the Update only to update = registration parameters and refresh the entry timeout. If you need to = change your links, just Register again.=20 This also aligns with the OMA Lightweight standard which this RD design = has become part of.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Tue Feb 5 05:38:54 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A43421F889C for ; Tue, 5 Feb 2013 05:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvzWuwsbY9gq for ; Tue, 5 Feb 2013 05:38:53 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id F323421F881D for ; Tue, 5 Feb 2013 05:38:52 -0800 (PST) Received: from [10.119.234.35] (static-195.22.91.10.addr.tdcsong.se [195.22.91.10]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r15DcllJ032268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2013 15:38:49 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Zach Shelby In-Reply-To: <20130131170606.GA14325@hephaistos.amsuess.com> Date: Tue, 5 Feb 2013 14:39:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130131170606.GA14325@hephaistos.amsuess.com> To: chrysn X-Mailer: Apple Mail (2.1499) Cc: core@ietf.org Subject: Re: [core] application/senml+json in coap content format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:38:54 -0000 Hi Chrysn, Glad to see your feedback on both CoRE Interfaces and SenML.=20 On Jan 31, 2013, at 6:06 PM, chrysn wrote: > hello core people, >=20 > as of experimenting with coap (especially core-interfaces), i'd like = to > transfer sensor data as application/senml+json. however, i didn't find > any attempt to register that mime type at the content-format registry > set up in draft-ietf-core-coap-13 -- even though extensive use thereof > is made in the examples in draft-shelby-core-interfaces-03. >=20 > * is there a type in use even though it's not yet published? >=20 > * if not, what should i use until one gets allocated? >=20 > * which document do i need to watch for a future allocation? (i'd = assume > draft-jennings-senml-10) People are actually using SenML, over HTTP using the proposed Media = Types and over CoAP using experimental values. As soon as the CoAP content-format registry has been created the SenML = draft can request values to be allocated in that registry. The other alternative would be to request that entries already be = included in the initial registry defined by the CoAP draft. There are = actually people using SenML over CoAP (we are at least) for real = applications, so I could see justification for that. So a question to = the chairs, do you see any issues if we could include the SenML = content-format assignments already in the initial registry definition? =20= > * (being new here,) is this list the right place for such questions? Definitely! And the authors of these documents are on this list = (although this one is slow in responding, appologies). > * researching current use, i found a glitch in > draft-shelby-core-interfaces-03 section 5.8 -- given what the = response > looks like, the answer to the GET request should be typed > application/link-format. are there better places to report such = things > than here? Thanks, now fixed in the SVN. Zach >=20 > best regards > chrysn >=20 > --=20 > A beginning is the time for taking the most delicate care that the > balances are correct. > -- Princess Irulan, Manual of Muad'Dib > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From trac+core@trac.tools.ietf.org Tue Feb 5 07:41:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4633421F85A2 for ; Tue, 5 Feb 2013 07:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTIvAyWBACXo for ; Tue, 5 Feb 2013 07:41:20 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AC11921F85A1 for ; Tue, 5 Feb 2013 07:41:20 -0800 (PST) Received: from localhost ([127.0.0.1]:52657 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2ke4-0005v8-Gq; Tue, 05 Feb 2013 16:41:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 05 Feb 2013 15:41:16 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/278 Message-ID: <060.5a65e8888a8762d62705314cddf068ae@trac.tools.ietf.org> X-Trac-Ticket-ID: 278 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130205154120.AC11921F85A1@ietfa.amsl.com> Resent-Date: Tue, 5 Feb 2013 07:41:20 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #278: Add single-subnet configuration to use cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:41:21 -0000 #278: Add single-subnet configuration to use cases Suggested by review Peter van der Stok and IETF85 WG discussion, that it's best to start explaining the simple/basic cases and then gradually build up complexity. Simplest case not shown yet would be a single subnet network configuration, which is currently not present in the I-D; only the 2-subnet configuration of Fig 1. Do we need to add such case, or doesn't it add much? Note that core-coap Figure 22 already shows the simplest case of link- local multicast. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Feb 5 07:43:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CB121F869A for ; Tue, 5 Feb 2013 07:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoDtpyo7WZ29 for ; Tue, 5 Feb 2013 07:43:06 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 517CF21F86A6 for ; Tue, 5 Feb 2013 07:43:06 -0800 (PST) Received: from localhost ([127.0.0.1]:52897 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2kfo-0008Lh-BD; Tue, 05 Feb 2013 16:43:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 05 Feb 2013 15:43:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/279 Message-ID: <060.96eb9ab9636e9ef18dbaf3eb2c38a6d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 279 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130205154306.517CF21F86A6@ietfa.amsl.com> Resent-Date: Tue, 5 Feb 2013 07:43:06 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #279: Add use case with controller (client) located on the backbone X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:43:07 -0000 #279: Add use case with controller (client) located on the backbone Suggested by discussion following review Peter van der Stok: case missing where a controller (client) is located on the backbone. Do we need to add such case, or doesn't it add much? To be discussed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Feb 5 07:45:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EB121F8716 for ; Tue, 5 Feb 2013 07:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp4Zz2Nb39XG for ; Tue, 5 Feb 2013 07:45:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CBB8321F86EB for ; Tue, 5 Feb 2013 07:45:40 -0800 (PST) Received: from localhost ([127.0.0.1]:53155 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U2kiI-0002sP-1b; Tue, 05 Feb 2013 16:45:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 05 Feb 2013 15:45:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/280 Message-ID: <060.551223a5c99f3a96dbcae80387a25ad3@trac.tools.ietf.org> X-Trac-Ticket-ID: 280 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130205154540.CBB8321F86EB@ietfa.amsl.com> Resent-Date: Tue, 5 Feb 2013 07:45:40 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #280: Issues with two/multiple Resource Directories in use case X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:45:41 -0000 #280: Issues with two/multiple Resource Directories in use case Some potential issues with RD came out of review Peter van der Stok and WG discussion IETF85. There are two RD servers; use case shows that only one is found despite the fact that site-local multicast is used - should be two RDs found. Proposal is to simplify use case to a single RD server on the backbone to avoid such RD-specific issues like synchronization of RD information between servers. Alternatively, the two-RD situation can be kept and both will be discovered. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Tue Feb 5 09:48:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860F621F8803; Tue, 5 Feb 2013 09:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlr93a8bwXvA; Tue, 5 Feb 2013 09:48:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826E121F885B; Tue, 5 Feb 2013 09:48:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130205174822.759.10190.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2013 09:48:22 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:48:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-05.txt Pages : 32 Date : 2013-02-05 Abstract: CoAP is a RESTful transfer protocol for constrained devices and networks. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Tue Feb 5 09:53:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49C821F86B0 for ; Tue, 5 Feb 2013 09:53:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koIUzD5OWH4m for ; Tue, 5 Feb 2013 09:53:14 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id E33A021F8615 for ; Tue, 5 Feb 2013 09:53:11 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Feb 2013 12:53:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Feb 2013 12:53:10 -0500 Message-ID: In-Reply-To: <20130205174822.759.10190.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-05.txt Thread-Index: Ac4DyQMcgC1HWvOYT/+QX+lfNUU+fQAAAiPQ References: <20130205174822.759.10190.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 05 Feb 2013 17:53:11.0085 (UTC) FILETIME=[A9B515D0:01CE03C9] Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:53:14 -0000 Hi, Esko and I have updated the Group Communications I-D to address the following points. Special thanks to Peter van der Stok for his detailed review that led to some of the key updates. We would also appreciate any other feedback from the WG and the other volunteer reviewers. Thanks, Akbar & Esko =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Changes from ietf-04 to ietf-05: o Added a new section 3.9 (Exceptions) that highlights that IP multicast (and hence group communications) is not always available (#187). o Updated text on the use of [RFC2119] language (#271) in Section 1. o Included guidelines on when (not) to use CoAP responses to multicast requests and when (not) to accept multicast requests (#273). o Added guideline on use of core-block for minimizing response size (#275). o Restructured section 6 (Security Considerations) to more fully describe threats and threat mitigation (#277). o Clearly indicated that DNS resolution and reverse DNS lookup are optional. o Removed confusing text about a single group having multiple IP addresses. If multiple IP addresses are required then multiple groups (with the same members) should be created. o Removed repetitive text about the fact that group communications is not guaranteed. o Merged previous section 5.2 (Multicast Routing) into 3.1 (IP Multicast Routing Background) and added link to section 5.2 (Advertising Membership of Multicast Groups). o Clarified text in section 3.8 (Congestion Control) regarding precedence of use of IP multicast domains (i.e. first try to use link-local scope, then site-local scope, and only use global IP multicast as a last resort). o Extended group resource manipulation guidelines with use of preconfigured ports/paths for the multicast group. o Consolidated all text relating to ports in a new section 3.3 (Port Configuration). o Clarified that all methods (GET/PUT/POST) for configuring group membership in endpoints should be unicast (and not multicast) in section 3.7 (Configuring Group Membership In Endpoints). o Various editorial updates for improved readability, including editorial comments by Peter van der Stok to WG list of December 18th, 2012. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, February 05, 2013 12:48 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-05.txt 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 : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-05.txt Pages : 32 Date : 2013-02-05 Abstract: CoAP is a RESTful transfer protocol for constrained devices and networks. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Tue Feb 5 14:40:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820D921F8910 for ; Tue, 5 Feb 2013 14:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfw+YkiQxMCW for ; Tue, 5 Feb 2013 14:40:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 56D8C21F890D for ; Tue, 5 Feb 2013 14:40:18 -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 r15MeA1T011324 for ; Tue, 5 Feb 2013 23:40:10 +0100 (CET) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 633BD3D5 for ; Tue, 5 Feb 2013 23:40:10 +0100 (CET) Received: by mail-la0-f46.google.com with SMTP id fq12so750097lab.33 for ; Tue, 05 Feb 2013 14:40:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.144.103 with SMTP id sl7mr24392956lab.23.1360104009830; Tue, 05 Feb 2013 14:40:09 -0800 (PST) Received: by 10.112.58.13 with HTTP; Tue, 5 Feb 2013 14:40:09 -0800 (PST) Date: Wed, 6 Feb 2013 00:40:09 +0200 Message-ID: From: Klaus Hartke To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 22:40:19 -0000 The rules for handling the Accept option in a request are quite well defined for an origin server: - If the origin server implements the Accept option, it checks if a response with an acceptable content-format is available (in order of the client's preference) and, if yes, returns that. Otherwise, it either returns an error response or a response with an unacceptable content-format (which is basically the same, as the client doesn't get what it wants). - If the origin server does not implement the Accept option, it returns a response which either happens to have an acceptable content-format or otherwise an unacceptable content-format. But what about intermediaries? Here are three examples that I'm not sure of: 1. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 43 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? 2. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 44 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? 3. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? Best regards, Klaus From Bert.Greevenbosch@huawei.com Tue Feb 5 18:17:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9026621F8950 for ; Tue, 5 Feb 2013 18:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cSkhAlF3Dkc for ; Tue, 5 Feb 2013 18:17:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8B721F865B for ; Tue, 5 Feb 2013 18:17:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APL81562; Wed, 06 Feb 2013 02:17:46 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Feb 2013 02:16:46 +0000 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Feb 2013 02:17:44 +0000 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.007; Wed, 6 Feb 2013 10:17:41 +0800 From: Bert Greevenbosch To: Klaus Hartke , "core@ietf.org WG" Thread-Topic: [core] Accept option and intermediaries Thread-Index: AQHOA/HKwuYLJnlDGE6upT/pxgrx/5hsDy4Q Date: Wed, 6 Feb 2013 02:17:40 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D5830BE@szxeml558-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 02:17:48 -0000 Hi Claus, I think your examples do not have a fixed answer. Especially, Section 5.10.= 4 in the CoAP spec uses "SHOULD" in the text about returning an error when = the requested content-format cannot be used: { The server SHOULD return one of the preferred Content-Formats if available. If none of the preferred Content-Formats can be returned, then a 4.06 "Not Acceptable" SHOULD be sent as a response. Note that as a server might not support the Accept option (and thus would ignore it as it is elective), the client needs to be prepared to receive a representation in a different Content-Format. The client can simply discard a representation it cannot make use of. } This means that you cannot reliably determine whether a response in another= content-type than was requested through the "accept" option is due to the = server not supporting the "accept" option, or due to it not being able to d= eliver the requested content-type. As for why is it is a "SHOULD" here I am not certain. Maybe the "SHOULD" is= to ensure non-supporting servers do not violate normative text. This would= make this an editorial issue. Having said that, I think the following behaviour would make most sense: { 1. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 43 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? } The intermediary MAY return the cached response. Even though the content-fo= rmat 42 may be more suitable, the client will be fine with receiving 43. Ho= wever, the intermediary should be allowed to choose, as it may know that co= ntent-format 42 is better than 43. { 2. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 44 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? } Forward to the server. The cached response with content-format 44 is irrele= vant for this request. { 3. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? } Forward to the server, as we don't know if the server does not support cont= ent-type 43 or does not support "accept". Therefore the server may be able = to deliver content-type 42. This one would be clearer if we rephrased the a= bove text to MUSTs for supporting servers. Then the cached response could h= ave been re-used. Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: 06 February 2013 06:40 To: core@ietf.org WG Subject: [core] Accept option and intermediaries The rules for handling the Accept option in a request are quite well defined for an origin server: - If the origin server implements the Accept option, it checks if a response with an acceptable content-format is available (in order of the client's preference) and, if yes, returns that. Otherwise, it either returns an error response or a response with an unacceptable content-format (which is basically the same, as the client doesn't get what it wants). - If the origin server does not implement the Accept option, it returns a response which either happens to have an acceptable content-format or otherwise an unacceptable content-format. But what about intermediaries? Here are three examples that I'm not sure of: 1. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 43 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? 2. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 44 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? 3. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? Best regards, Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From stokcons@xs4all.nl Wed Feb 6 00:19:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4CE21F88CA for ; Wed, 6 Feb 2013 00:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lww9HrMPS33a for ; Wed, 6 Feb 2013 00:19:27 -0800 (PST) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0D921F8702 for ; Wed, 6 Feb 2013 00:19:27 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube1.xs4all.net [194.109.20.195]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id r168JPOv010425 for ; Wed, 6 Feb 2013 09:19:25 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-72-151.w90-0.abo.wanadoo.fr ([90.0.47.151]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 06 Feb 2013 09:19:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 06 Feb 2013 09:19:25 +0100 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: <30a64b4fc85a612b82a5ed4fe685476e@xs4all.nl> <5F948749-91FB-4687-B0F6-CD0B713E3931@sensinode.com> <7e66b0ef133d031d61a4cd103108bb0f@xs4all.nl> <14303B24-14FE-4026-BA9F-CA4444E2492D@sensinode.com> <510653E8.4060109@intec.ugent.be> <031DD135F9160444ABBE3B0C36CED618B76082@011-DB3MPN2-081.MGDPHG.emi.philips.com> Message-ID: <8c4f33fb3d4e52a11ad22c7a8328f69e@xs4all.nl> X-Sender: stokcons@xs4all.nl (XmhPfY+U66qQYTHOOH88l4sD5F6gXbiE) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [core] resource-directory-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 08:19:28 -0000 Hi Zach, This is certainly a more clear and consistent approach, thanks, peter Zach Shelby schreef op 2013-02-05 14:32: > Esko, > > On Jan 28, 2013, at 2:03 PM, "Dijk, Esko" > wrote: > >>> I don't agree that this a contradiction, the last line of 5.32 >>> refers to the URI query parameters that are passed on (e.g. con, rt >>> and lt) and not the CoAP Payload. So in my view this shouldn't be >>> altered. Enforcing this on the payload as well, would seem to imply >>> that the payload would be a patch of some sort (which seems to be out >>> of the scope of the document). >> >> To me it’s not clear from the text whether the PUT request to do an >> update overwrites the previous entries entirely (which would be most >> RESTful) or that “update” implies that only new and/or changed >> resources are included in the payload. (Then I would expect a POST >> rather than PUT) >> Maybe an idea is allowing both PUT (to overwrite existing) or POST >> (to update existing) ? > > In an effort to simplify this more, as in large M2M systems the > Update load can get really high, I am actually going to propose not > including a payload at all in Updates. But instead using the Update > only to update registration parameters and refresh the entry timeout. > If you need to change your links, just Register again. > > This also aligns with the OMA Lightweight standard which this RD > design has become part of. > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Wed Feb 6 01:41:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C0321F8934 for ; Wed, 6 Feb 2013 01:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q+zr6jqcj-t for ; Wed, 6 Feb 2013 01:41:40 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D358721F87FE for ; Wed, 6 Feb 2013 01:41:39 -0800 (PST) Received: from localhost ([127.0.0.1]:48176 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U31Va-0002Lo-Rc; Wed, 06 Feb 2013 10:41:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Wed, 06 Feb 2013 09:41:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/281 Message-ID: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> X-Trac-Ticket-ID: 281 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130206094139.D358721F87FE@ietfa.amsl.com> Resent-Date: Wed, 6 Feb 2013 01:41:39 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 09:41:40 -0000 #281: Safe-to-forward options A GET request with an Observe Option to an intermediary can contain options that the intermediary doesn't recognise. Up to coap-11, this wasn't a problem, because these options were rejected/removed, so the request to the origin server didn't contain them. Since coap-12, options can be "safe to forward". An intermediary can include these in a request to the server even if it doesn't recognised them. This is a problem, because each of the options could affect the observation relationship between intermediary and server in a way that makes the notifications unsuitable for sharing between clients with different unrecognised options in their requests. Since the intermediary doesn't recognise the options, it can also not tell if the request will lead to a new observation relationship or override an existing one. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-07 Component: observe | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: core From hartke@tzi.org Wed Feb 6 04:23:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CDB21F855F for ; Wed, 6 Feb 2013 04:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7Ii4UHGTwTR for ; Wed, 6 Feb 2013 04:23:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9C56B21F8793 for ; Wed, 6 Feb 2013 04:23:18 -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 r16CN93S026637 for ; Wed, 6 Feb 2013 13:23:09 +0100 (CET) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5C7A66D1 for ; Wed, 6 Feb 2013 13:23:09 +0100 (CET) Received: by mail-la0-f43.google.com with SMTP id ek20so1290317lab.16 for ; Wed, 06 Feb 2013 04:23:08 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.133.133 with SMTP id pc5mr26313319lab.32.1360153388796; Wed, 06 Feb 2013 04:23:08 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 04:23:08 -0800 (PST) In-Reply-To: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> Date: Wed, 6 Feb 2013 14:23:08 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 12:23:19 -0000 I have no idea how to tackle this yet. Input is appreciated. Klaus On 6 February 2013 11:41, core issue tracker wrote: > #281: Safe-to-forward options > > A GET request with an Observe Option to an intermediary can contain > options that the intermediary doesn't recognise. > > Up to coap-11, this wasn't a problem, because these options were > rejected/removed, so the request to the origin server didn't contain them. > > Since coap-12, options can be "safe to forward". An intermediary can > include these in a request to the server even if it doesn't recognised > them. > > This is a problem, because each of the options could affect the > observation relationship between intermediary and server in a way that > makes the notifications unsuitable for sharing between clients with > different unrecognised options in their requests. > > Since the intermediary doesn't recognise the options, it can also not tell > if the request will lead to a new observation relationship or override an > existing one. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-core- > hartke@tzi.org | observe@tools.ietf.org > Type: protocol | Status: new > defect | Milestone: post-WGLC-1 > Priority: minor | Version: observe-07 > Component: observe | Keywords: > Severity: In WG Last | > Call | > -------------------------+------------------------------------------------- > > Ticket URL: > core From tho@koanlogic.com Wed Feb 6 04:38:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA9221F8B02 for ; Wed, 6 Feb 2013 04:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3vG3Oj8TyvV for ; Wed, 6 Feb 2013 04:38:19 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFCB21F88CA for ; Wed, 6 Feb 2013 04:38:18 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id s4so1150538lbc.35 for ; Wed, 06 Feb 2013 04:38:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=HhJ6nTE37hTAJY0wKdwX6f1XGT4FilXreucijM038oY=; b=REcceXdPBUsyhX2L/EfNOKjCy/IS6WOGiRU4y5m7apwpVmDfmt/sGOP5xO4Z68S/Bn poBe5dkRwJB1UuxR/5EuPTH6PBRLYw9T2q0bzYBOEYad10UbYOP6hhmPIpZjGJWrgFjk KYm9uJUBa+E81H0qj6UzZppjjdBM5jLS/u46bRaldCHG5aCAUE/FLXnu2IkoQI8p3OuF P2vty7rIJZIqkn4wjukW0Z+JBKM7RiJ+8M8DDm/9TZ3Vy6NrUsTimuJ0H+RJus/cIZ1j 3GNwfOS4DKZMeVjwIBq6cTy9NQBFrJFQnQaWa2V+9/ZaI8mviQrJLJqturFV8ybXQ1eY FLug== MIME-Version: 1.0 X-Received: by 10.152.133.133 with SMTP id pc5mr26359111lab.32.1360154298006; Wed, 06 Feb 2013 04:38:18 -0800 (PST) Received: by 10.114.82.2 with HTTP; Wed, 6 Feb 2013 04:38:17 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> Date: Wed, 6 Feb 2013 12:38:17 +0000 Message-ID: From: Thomas Fossati To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmzEFRsqYRTIpHjwGAjD6aK9wPdZne7odtGPQMekouSVGdwVB0I8Ei5ostRSLOapuBnGJLT Cc: core@ietf.org Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 12:38:20 -0000 On Wed, Feb 6, 2013 at 12:23 PM, Klaus Hartke wrote: >> Since the intermediary doesn't recognise the options, it can also not tell >> if the request will lead to a new observation relationship or override an >> existing one. Would it be safe to treat the whole set of unknown but "safe to forward" options as a key to identify same-observations ? Suppose X, Y and Z are StF options, and the following events happen at a proxy P: (1) Client A requests an observation for resource r on server S, appending X and Y and Z; (2) Client B requests an observation for resource r on server S, appending X and Y; (3) Client C requests an observation for resource r on server S, appending X and Y and Z. At (1) P will create a new observation for resource r on server S. At (2) P will create a brand new observation towards S. At (3) P can reuse observation created at (1). From hartke@tzi.org Wed Feb 6 04:56:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E07B21F85BC for ; Wed, 6 Feb 2013 04:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ-usekx1+2u for ; Wed, 6 Feb 2013 04:56:57 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 706CA21F8445 for ; Wed, 6 Feb 2013 04:56:55 -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 r16CulwC015576 for ; Wed, 6 Feb 2013 13:56:47 +0100 (CET) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9D751715 for ; Wed, 6 Feb 2013 13:56:47 +0100 (CET) Received: by mail-la0-f53.google.com with SMTP id fr10so1305843lab.40 for ; Wed, 06 Feb 2013 04:56:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.38.98 with SMTP id f2mr11174593lbk.61.1360155407133; Wed, 06 Feb 2013 04:56:47 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 04:56:47 -0800 (PST) In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> Date: Wed, 6 Feb 2013 14:56:47 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 12:56:58 -0000 Thomas Fossati wrote: >> Since the intermediary doesn't recognise the options, it can also not tell >> if the request will lead to a new observation relationship or override an >> existing one. > > Would it be safe to treat the whole set of unknown but "safe to > forward" options as a key to identify same-observations ? How does the server know which options are unrecognised by the intermediary? Klaus From esko.dijk@philips.com Wed Feb 6 05:02:42 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F0621F8622 for ; Wed, 6 Feb 2013 05:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.919 X-Spam-Level: X-Spam-Status: No, score=-4.919 tagged_above=-999 required=5 tests=[AWL=1.680, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6uf1c0WzCmN for ; Wed, 6 Feb 2013 05:02:41 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEE321F8468 for ; Wed, 6 Feb 2013 05:02:41 -0800 (PST) Received: from mail188-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE011.bigfish.com (10.236.130.74) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Feb 2013 13:02:40 +0000 Received: from mail188-co9 (localhost [127.0.0.1]) by mail188-co9-R.bigfish.com (Postfix) with ESMTP id 7AB2036043E; Wed, 6 Feb 2013 13:02:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz217bI15d6O9251J542Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail188-co9 (localhost.localdomain [127.0.0.1]) by mail188-co9 (MessageSwitch) id 1360155718866961_7869; Wed, 6 Feb 2013 13:01:58 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.251]) by mail188-co9.bigfish.com (Postfix) with ESMTP id D0960AE004A; Wed, 6 Feb 2013 13:01:58 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Feb 2013 13:01:58 +0000 Received: from 011-DB3MMR1-023.MGDPHG.emi.philips.com (10.128.28.107) by 011-DB3MMR1-007.MGDPHG.emi.philips.com (10.128.28.57) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 6 Feb 2013 13:01:56 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.86]) by 011-DB3MMR1-023.MGDPHG.emi.philips.com ([fe80::e485:97aa:9b41:86e3%11]) with mapi id 14.02.0318.003; Wed, 6 Feb 2013 13:01:55 +0000 From: "Dijk, Esko" To: Bert Greevenbosch , Klaus Hartke , "core@ietf.org WG" Thread-Topic: [core] Accept option and intermediaries Thread-Index: AQHOA/HKYBN1NefeEE2+sSHAN3j4oZhsGGMAgACyT+A= Date: Wed, 6 Feb 2013 13:01:55 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B7896C@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB63D5830BE@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D5830BE@szxeml558-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 13:02:42 -0000 +1 for Bert's answers. It would be clearer to rephrase 5.10.4. to (if this is meant, in fact): - servers not supporting Accept just ignore it - servers that do support Accept: "MUST return one of the preferred Conten= t-Formats if available. If none of the preferred Content-Formats can be returned, then a 4.06 "Not Acceptable" = MUST be sent as a response. For question #1 indeed the intermediary would make an implementation-specif= ic choice, as more detailed guidance on this choice is not in core-coap rig= ht now. I assume that's not an issue since the client can understand the le= ss-preferred format too. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ber= t Greevenbosch Sent: Wednesday 6 February 2013 3:18 To: Klaus Hartke; core@ietf.org WG Subject: Re: [core] Accept option and intermediaries Hi Claus, I think your examples do not have a fixed answer. Especially, Section 5.10.= 4 in the CoAP spec uses "SHOULD" in the text about returning an error when = the requested content-format cannot be used: { The server SHOULD return one of the preferred Content-Formats if available. If none of the preferred Content-Formats can be returned, then a 4.06 "Not Acceptable" SHOULD be sent as a response. Note that as a server might not support the Accept option (and thus would ignore it as it is elective), the client needs to be prepared to receive a representation in a different Content-Format. The client can simply discard a representation it cannot make use of. } This means that you cannot reliably determine whether a response in another= content-type than was requested through the "accept" option is due to the = server not supporting the "accept" option, or due to it not being able to d= eliver the requested content-type. As for why is it is a "SHOULD" here I am not certain. Maybe the "SHOULD" is= to ensure non-supporting servers do not violate normative text. This would= make this an editorial issue. Having said that, I think the following behaviour would make most sense: { 1. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 43 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? } The intermediary MAY return the cached response. Even though the content-fo= rmat 42 may be more suitable, the client will be fine with receiving 43. Ho= wever, the intermediary should be allowed to choose, as it may know that co= ntent-format 42 is better than 43. { 2. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 44 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? } Forward to the server. The cached response with content-format 44 is irrele= vant for this request. { 3. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have to make a request to the server? } Forward to the server, as we don't know if the server does not support cont= ent-type 43 or does not support "accept". Therefore the server may be able = to deliver content-type 42. This one would be clearer if we rephrased the a= bove text to MUSTs for supporting servers. Then the cached response could h= ave been re-used. Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: 06 February 2013 06:40 To: core@ietf.org WG Subject: [core] Accept option and intermediaries The rules for handling the Accept option in a request are quite well define= d for an origin server: - If the origin server implements the Accept option, it checks if a respons= e with an acceptable content-format is available (in order of the client's = preference) and, if yes, returns that. Otherwise, it either returns an erro= r response or a response with an unacceptable content-format (which is basi= cally the same, as the client doesn't get what it wants). - If the origin server does not implement the Accept option, it returns a r= esponse which either happens to have an acceptable content-format or otherw= ise an unacceptable content-format. But what about intermediaries? Here are three examples that I'm not sure of: 1. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 43 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have = to make a request to the server? 2. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 44 Is the intermediary allowed to return the stored response, or does it have = to make a request to the server? 3. The client sends a request with Accept: 42 Accept: 43 The intermediary has a stored response with Content-Format: 44 in its cache as the result of a request with Accept: 43 Is the intermediary allowed to return the stored response, or does it have = to make a request to the server? Best regards, Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From hartke@tzi.org Wed Feb 6 05:35:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D5B21F85F7 for ; Wed, 6 Feb 2013 05:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuuaGEY1Jm25 for ; Wed, 6 Feb 2013 05:35:39 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 24B1E21F85F3 for ; Wed, 6 Feb 2013 05:35:38 -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 r16DZWfH008250 for ; Wed, 6 Feb 2013 14:35:32 +0100 (CET) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DF9CA769 for ; Wed, 6 Feb 2013 14:35:31 +0100 (CET) Received: by mail-lb0-f176.google.com with SMTP id s4so1174585lbc.21 for ; Wed, 06 Feb 2013 05:35:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.38.228 with SMTP id j4mr11399083lbk.1.1360157731325; Wed, 06 Feb 2013 05:35:31 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 05:35:31 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B7896C@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB63D5830BE@szxeml558-mbx.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618B7896C@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Wed, 6 Feb 2013 15:35:31 +0200 Message-ID: From: Klaus Hartke To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 13:35:40 -0000 Esko Dijk wrote: > +1 for Bert's answers. I agree with Bert's conclusions on the examples as well. But it looks like implementing this properly in an intermediary could become quite complex. The outcome does not only seem to depend on the Content-Format of the stored response(s), but also on the Accept Options of the requests that led to the stored responses. I'd like to see this more fleshed out, not necessarily in the draft. Has anyone implemented this already and can share their experience? > It would be clearer to rephrase 5.10.4. to (if this is meant, in fact): > - servers not supporting Accept just ignore it > - servers that do support Accept: "MUST return one of the preferred Content-Formats if available. If none of the > preferred Content-Formats can be returned, then a 4.06 "Not Acceptable" MUST be sent as a response. There is nothing that stops a server from supporting a feature for one request and not supporting it for the next request... Klaus From cabo@tzi.org Wed Feb 6 05:49:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CF621F8727 for ; Wed, 6 Feb 2013 05:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifmqdy3UnGCM for ; Wed, 6 Feb 2013 05:49:56 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 398C521F8573 for ; Wed, 6 Feb 2013 05:49:56 -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 r16DnmZe017248 for ; Wed, 6 Feb 2013 14:49:48 +0100 (CET) Received: from [192.168.217.108] (p548927BC.dip.t-dialin.net [84.137.39.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ADD0B78B; Wed, 6 Feb 2013 14:49:47 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 6 Feb 2013 14:49:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 13:49:57 -0000 > The rules for handling the Accept option in a request are quite well > defined for an origin server: >=20 > - If the origin server implements the Accept option, it checks if a > response with an acceptable content-format is available (in order of > the client's preference) and, if yes, returns that. Otherwise, it > either returns an error response or a response with an unacceptable > content-format (which is basically the same, as the client doesn't get > what it wants). >=20 > - If the origin server does not implement the Accept option, it > returns a response which either happens to have an acceptable > content-format or otherwise an unacceptable content-format. >=20 > But what about intermediaries? I think it is pretty clear that an intermediary must treat Accept as a = cache-key. (This is also consistent with coap-13 marking it neither UnSafe nor = NoCacheKey. Yes, this only governs the case where an intermediary does not = understand the option, but it is still good to know it's consistent.) > Here are three examples that I'm not sure of: >=20 > 1. > The client sends a request with > Accept: 42 > Accept: 43 > The intermediary has a stored response with > Content-Format: 43 > in its cache as the result of a request with > Accept: 43 > Is the intermediary allowed to return the stored response, or does it > have to make a request to the server? Not without checking that the request that gave it the 43 also asked for = [42,43]. Practical example: 43 may be a "fallback representation" that only contains some of the = data. The previous request that gave us the cache entry may have asked for = [43] only, so the server was forced to send back the 43. (Well, it was allowed to ignore the Accept, but of course that is not = the intention of the request, so a good implementation would not do = that.) The server may well be able to send a 42 if allowed to do so by the = request. > 2. > The client sends a request with > Accept: 42 > Accept: 43 > The intermediary has a stored response with > Content-Format: 44 > in its cache as the result of a request with > Accept: 44 > Is the intermediary allowed to return the stored response, or does it > have to make a request to the server? No and yes. > 3. > The client sends a request with > Accept: 42 > Accept: 43 > The intermediary has a stored response with > Content-Format: 44 > in its cache as the result of a request with > Accept: 43 > Is the intermediary allowed to return the stored response, or does it > have to make a request to the server? No and yes. Gr=FC=DFe, Carsten PS.: Re Bert's and Esko's response: The MUST certainly is what we want a server implementation developer to = understand here. It is just hard to enforce this in the protocol (and it is thus hard for = peers to rely on this property, which is the whole point of a MUST): As Klaus said, the server can decide to support Accept only on Tuesdays = or in odd seconds or based on some specific property of the request that = is hard for a client to make out. So it would not really be useful for a client to try to divine whether = the server supports Accept (i.e., promises to always honor an Accept) or = not, even if this were possible in a reliable way in the first place. Add intermediaries in the mix if you aren't convinced yet. So the MUST (=3D can rely on) is not what we want a client = implementation developer to understand here! From hartke@tzi.org Wed Feb 6 06:03:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B1921F848B for ; Wed, 6 Feb 2013 06:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP9ppEp321vi for ; Wed, 6 Feb 2013 06:03:25 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1694C21F853A for ; Wed, 6 Feb 2013 06:03: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 r16E3EL9027232 for ; Wed, 6 Feb 2013 15:03:14 +0100 (CET) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 317917AF for ; Wed, 6 Feb 2013 15:03:14 +0100 (CET) Received: by mail-la0-f44.google.com with SMTP id eb20so1409929lab.3 for ; Wed, 06 Feb 2013 06:03:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.106.5 with SMTP id gq5mr26869911lab.5.1360159393375; Wed, 06 Feb 2013 06:03:13 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 06:03:13 -0800 (PST) In-Reply-To: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> Date: Wed, 6 Feb 2013 16:03:13 +0200 Message-ID: From: Klaus Hartke To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:03:26 -0000 Carsten Bormann wrote: > I think it is pretty clear that an intermediary must treat Accept as a cache-key. So, in other words, a resource is identified by the tuple (scheme, host, port, path segments, query arguments, acceptable formats) and not (scheme, host, port, path segments, query arguments), and a response that was obtained from one set of Accept options MUST NOT be used to satisfy a request for another set of Accept options? Klaus From tho@koanlogic.com Wed Feb 6 06:09:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C574921F853A for ; Wed, 6 Feb 2013 06:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGbDCGoWdySF for ; Wed, 6 Feb 2013 06:09:27 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7B83421F8417 for ; Wed, 6 Feb 2013 06:09:27 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id j14so1196657lbo.24 for ; Wed, 06 Feb 2013 06:09:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=8bFIcPGVVu9YP8HKzs7qiSljD/1LvT+uv72sXqQk+c4=; b=cj3yLrO8Twh81T/5JQCVS/w6Eqn2DWIo9HqORV26qkxx/vbeu1fkDeVQoF/L45gYLm J0+ad1++5lGot8QXZPGx3bO5heT1XEC01CqKjoE4dHxzL6LhvI05v2JeovWqcYnHWpzI Q3oUc9PKO/SMyRKZbKN/HfatzUIv1VLpQfkUm+uCWmY4yqW0alWTRrC4dp2Lhfb/FCZK mdp2r2OSjcW5E38bylQ/vPcU2eJWKffxCdPb+0UfntW3rk7pXFN3H8QYycPHtJwPBOvp GMyJftmO1FZxUKo+o6uL5tWll6dpVMHfAB3OTH6XpjHO6fHb9EpfDOkoowSWQvkguz2J yTxA== MIME-Version: 1.0 X-Received: by 10.152.110.228 with SMTP id id4mr26764963lab.34.1360159766197; Wed, 06 Feb 2013 06:09:26 -0800 (PST) Received: by 10.114.82.2 with HTTP; Wed, 6 Feb 2013 06:09:26 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> Date: Wed, 6 Feb 2013 14:09:26 +0000 Message-ID: From: Thomas Fossati To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkqtc8g1UW1B8UFptaPii/Jya8noETuH6ocR05UNgMyaQziqGUxowgojUruUmM4uk+LQXEq Cc: core@ietf.org Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:09:28 -0000 On Wed, Feb 6, 2013 at 12:56 PM, Klaus Hartke wrote: > Thomas Fossati wrote: >>> Since the intermediary doesn't recognise the options, it can also not tell >>> if the request will lead to a new observation relationship or override an >>> existing one. >> >> Would it be safe to treat the whole set of unknown but "safe to >> forward" options as a key to identify same-observations ? > > How does the server know which options are unrecognised by the intermediary? I'm probably missing something, but: why is it important for the server to know what the intermediary thinks about the StF options ? If their semantics will trigger some special handling, the important thing is that this is made visible to the client. How can the proxy interfere with that if it clearly separates the non-equivalent flows ? From hartke@tzi.org Wed Feb 6 06:11:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB44F21F8EBD for ; Wed, 6 Feb 2013 06:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6Od46tFP4BM for ; Wed, 6 Feb 2013 06:11:46 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECB821F8E2E for ; Wed, 6 Feb 2013 06:11:45 -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 r16EBduW003558 for ; Wed, 6 Feb 2013 15:11:39 +0100 (CET) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 156D47BE for ; Wed, 6 Feb 2013 15:11:39 +0100 (CET) Received: by mail-lb0-f172.google.com with SMTP id n8so1233133lbj.3 for ; Wed, 06 Feb 2013 06:11:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.133.133 with SMTP id pc5mr26648340lab.32.1360159898566; Wed, 06 Feb 2013 06:11:38 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 06:11:38 -0800 (PST) In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> Date: Wed, 6 Feb 2013 16:11:38 +0200 Message-ID: From: Klaus Hartke To: Thomas Fossati Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:11:47 -0000 Thomas Fossati wrote: >> How does the server know which options are unrecognised by the intermediary? > > I'm probably missing something, but: why is it important for the > server to know what the intermediary thinks about the StF options ? Taking your example: Let's say the server recognises X, Y, and Z, and only X is actually part of the "observe key". Then At (1) P requests a new observation for resource r on server S. S creates the observation with key (P, r, X) and sends notifications affected by X, Y and Z. At (2) P thinks it cannot reuse observation created at (1) and requests a new observation towards S. S notes that an observation already exists for key (P, r, X), replaces the entry and sends notifications affected by X and Y but not by Z. Client A no longer receives notifications. At (3) P thinks it can reuse the observation created at (1). Client A and C receive no notifications. So things go wrong if the intermediary and the client do not agree an how an observation is identified. Or maybe it's me who's missing something? Klaus From tho@koanlogic.com Wed Feb 6 06:18:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3177221F84CC for ; Wed, 6 Feb 2013 06:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyeAqf2122Rq for ; Wed, 6 Feb 2013 06:18:01 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7388B21F8484 for ; Wed, 6 Feb 2013 06:18:01 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so1427129lab.29 for ; Wed, 06 Feb 2013 06:18:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ojt4YDBGSIYrEu96vJgcP1Bygz84rH6m3kxmcTFg0Yo=; b=OU91LY3W6+bu83xKHWJFgGuf7ugtjCRuWllYopE4q36JMnOHebDOwJj/CDTVDD3JUX IhtM93SSKuqwZ4QeTEWrguJb/PMKBMu6EnbLa9REDFfDm63ZIDHLMktBjEMDqmVldia9 rJ8SFk5nrTtqW92cxxnIkOesJHBPyDJwfHxjvhhNmb0Mthi/MKQW6/ZTcwv3GHdZdstA WYLxltJoK1GdRDv5YYirqGK7ILM0BMGhoqYnjFyjmNXprT25ZQUcNmovl/NQOD49s4on UZBq60iiN/pKutd4qufNUw/2H4zezn5wLXbG4hbk9HFAuix79WViO+VfWMZ0ReuAJGDT sk4Q== MIME-Version: 1.0 X-Received: by 10.112.43.198 with SMTP id y6mr11532536lbl.93.1360160280242; Wed, 06 Feb 2013 06:18:00 -0800 (PST) Received: by 10.114.82.2 with HTTP; Wed, 6 Feb 2013 06:18:00 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> Date: Wed, 6 Feb 2013 14:18:00 +0000 Message-ID: From: Thomas Fossati To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmE5cXALzXdZ5uGwes/+DWyNAy1QZjw+lpXNvhhAFhLAc+XJlmVscgBJtv+wASn2VyyCeBv Cc: core@ietf.org Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:18:02 -0000 On Wed, Feb 6, 2013 at 1:21 PM, Klaus Hartke wrote: > Maybe it's me who's missing something? Ok, let's rewind a bit the discussion. How many concurrent observations may exist between a proxy and a server for a given resource ? If only one, we're basically doomed. If more than one, we need a mechanism to allow the server and the proxy to agree on their number and accurate identification. From hartke@tzi.org Wed Feb 6 06:27:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5DB21F84D3 for ; Wed, 6 Feb 2013 06:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaFy+ftCQF9s for ; Wed, 6 Feb 2013 06:27:23 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C51DE21F84CA for ; Wed, 6 Feb 2013 06:27:22 -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 r16ERFAk012019 for ; Wed, 6 Feb 2013 15:27:15 +0100 (CET) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D707F7E6 for ; Wed, 6 Feb 2013 15:27:14 +0100 (CET) Received: by mail-lb0-f175.google.com with SMTP id n3so1242716lbo.34 for ; Wed, 06 Feb 2013 06:27:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.98.226 with SMTP id el2mr11278423lbb.59.1360160834377; Wed, 06 Feb 2013 06:27:14 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 06:27:14 -0800 (PST) In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> Date: Wed, 6 Feb 2013 16:27:14 +0200 Message-ID: From: Klaus Hartke To: Thomas Fossati Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:27:23 -0000 Thomas Fossati wrote: > How many concurrent observations may exist between a proxy and a > server for a given resource ? Currently, it is one per (client endpoint, request URI). Ticket #258 proposes to change this to one per (client endpoint, request URI, list of accept options). > If only one, we're basically doomed. > > If more than one, we need a mechanism to allow the server and the > proxy to agree on their number and accurate identification. Yes, the client (or an intermediary in the client role) and the server need to agree on the identification of an observation. If they don't do this, it doesn't work. There should be at most one observation per identifiable observation. I.e., having more than one would only mean receiving duplicates of the same notifications. I've wondered for a while now if it wouldn't be better if this wasn't enforced by the server, though, because the GET requests affecting each other breaks REST. But the client (or intermediary in the client role) should still (and must be able to) bundle multiple observations into one wherever possible. Klaus From floris.vandenabeele@intec.ugent.be Wed Feb 6 06:31:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207AE21F868D for ; Wed, 6 Feb 2013 06:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Nnln-Luevjd for ; Wed, 6 Feb 2013 06:31:32 -0800 (PST) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 515FC21F8645 for ; Wed, 6 Feb 2013 06:31:32 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 81B29C1AE; Wed, 6 Feb 2013 15:31:30 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id pLBI7gRzk1PX; Wed, 6 Feb 2013 15:31:29 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp3.ugent.be (Postfix) with ESMTP id A2F82C1A9; Wed, 6 Feb 2013 15:31:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id B2B5A1F; Wed, 6 Feb 2013 15:31:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6ehTo42Pdny; Wed, 6 Feb 2013 15:31:29 +0100 (CET) Received: from [157.193.135.239] (dhcp-zdpt-239.intec.ugent.be [157.193.135.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 879011E; Wed, 6 Feb 2013 15:31:29 +0100 (CET) Message-ID: <5112693F.6030705@intec.ugent.be> Date: Wed, 06 Feb 2013 15:31:27 +0100 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Klaus Hartke References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at jchkm3 with ID 51126941.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51126941.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51126941.000 on smtp3.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: core@ietf.org Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:31:33 -0000 I think the fundamental problem is that an observation request can not be identified by the CoAP endpoint and the request URI alone. The presence of some types of options will also lead to a new observation relationship (e.g. an accept option or a block2 option). The workaround now would be to establish new observation relationships from different source ports for these cases. Aggregation can then be performed across all ports. An alternative would be to include other options besides the request-URI inside the identification of an observation relationship. One problem then is how to distinguish between notifications from observe requests with different options, one could simply echo all the options inside each notification or provide an ETag-like mechanism. Floris Op 06-02-13 15:27, Klaus Hartke schreef: > Thomas Fossati wrote: >> How many concurrent observations may exist between a proxy and a >> server for a given resource ? > Currently, it is one per (client endpoint, request URI). > > Ticket #258 proposes to change this to one per (client endpoint, > request URI, list of accept options). > >> If only one, we're basically doomed. >> >> If more than one, we need a mechanism to allow the server and the >> proxy to agree on their number and accurate identification. > Yes, the client (or an intermediary in the client role) and the server > need to agree on the identification of an observation. If they don't > do this, it doesn't work. > > There should be at most one observation per identifiable observation. > I.e., having more than one would only mean receiving duplicates of the > same notifications. > > I've wondered for a while now if it wouldn't be better if this wasn't > enforced by the server, though, because the GET requests affecting > each other breaks REST. But the client (or intermediary in the client > role) should still (and must be able to) bundle multiple observations > into one wherever possible. > > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Wed Feb 6 06:36:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865FE21F8645 for ; Wed, 6 Feb 2013 06:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGLAd7ONJKfK for ; Wed, 6 Feb 2013 06:36:48 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BBF1821F85CC for ; Wed, 6 Feb 2013 06:36:47 -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 r16Eaeur018064 for ; Wed, 6 Feb 2013 15:36:40 +0100 (CET) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3C38D7F8 for ; Wed, 6 Feb 2013 15:36:40 +0100 (CET) Received: by mail-la0-f52.google.com with SMTP id fs12so1451720lab.11 for ; Wed, 06 Feb 2013 06:36:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.144.103 with SMTP id sl7mr26615777lab.23.1360161399638; Wed, 06 Feb 2013 06:36:39 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 06:36:39 -0800 (PST) In-Reply-To: <5112693F.6030705@intec.ugent.be> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> Date: Wed, 6 Feb 2013 16:36:39 +0200 Message-ID: From: Klaus Hartke To: Floris Van den Abeele Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:36:48 -0000 Floris Van den Abeele wrote: > An alternative would be to include other options besides the request-URI > inside the identification of an observation relationship. One problem then > is how to distinguish between notifications from observe requests with > different options That's what we have tokens for. So distinguishing between the notifications is not a problem. The problem is the identification of the observation relationship in the presence of unrecognised options. Klaus From cabo@tzi.org Wed Feb 6 06:48:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2293321F873D for ; Wed, 6 Feb 2013 06:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBy8atOOTcq0 for ; Wed, 6 Feb 2013 06:48:40 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA521F8472 for ; Wed, 6 Feb 2013 06:48:40 -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 r16EmXCr026443 for ; Wed, 6 Feb 2013 15:48:33 +0100 (CET) Received: from [192.168.217.108] (p548927BC.dip.t-dialin.net [84.137.39.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0FF52812; Wed, 6 Feb 2013 15:48:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 6 Feb 2013 15:48:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:48:41 -0000 On Feb 6, 2013, at 15:03, Klaus Hartke wrote: > Carsten Bormann wrote: >> I think it is pretty clear that an intermediary must treat Accept as = a cache-key. >=20 > So, in other words, a resource is identified by the tuple (scheme, > host, port, path segments, query arguments, acceptable formats) and > not (scheme, host, port, path segments, query arguments), Well, it is still the same resource, it's just the the request included = information about the specific representation desired. This information cannot be ignored by a cache. =20 (That's also why most Options that aren't UnSafe aren't NoCacheKey.) > and a > response that was obtained from one set of Accept options MUST NOT be > used to satisfy a request for another set of Accept options? That is what I'm saying, indeed. So, what is the practical impact of not being able to perform the = optimization that you seem to be implying here? In the HTTP world, there are two uses of Accept that I have seen: 1) Indicating client capabilities in a browser. This doesn't scale = (browsers support a lot of media types now) and has largely been = abandoned. 2) Asking for a specific media type that is different from the default = media type, e.g., for a JSON representation instead of an HTML = representation. In 2, I haven't seen more than one media type asked for. So the case = you have been presenting wouldn't really occur in that usage. Of course, HTTP usage is not necessarily indicative of CoAP usage. I = would expect we include media type capabilities in our discovery = frameworks (indeed, RFC 6690 already has ct=3D) so there is little need = for guesswork. So I think it is even more likely that a CoAP client = will request exactly the media type that it wants, based on what it = already knows about the server. This makes including that media-type = into the cache-key the obviously desirable thing to do. Second-guessing = by intermediaries then never provides a performance improvement. So = let's not spend effort doing that. Gr=FC=DFe, Carsten PS.: yeah, s/media type/content format/ for the CoAP side... But the = point is the same. From cabo@tzi.org Wed Feb 6 07:15:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CD321F8566 for ; Wed, 6 Feb 2013 07:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H30tl6lfF1g for ; Wed, 6 Feb 2013 07:15:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E0A9021F8481 for ; Wed, 6 Feb 2013 07:15: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 r16FFndd012516; Wed, 6 Feb 2013 16:15:49 +0100 (CET) Received: from [192.168.217.108] (p548927BC.dip.t-dialin.net [84.137.39.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B621B844; Wed, 6 Feb 2013 16:15:48 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 6 Feb 2013 16:15:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 15:15:58 -0000 On Feb 6, 2013, at 15:36, Klaus Hartke wrote: > Floris Van den Abeele wrote: >> An alternative would be to include other options besides the = request-URI >> inside the identification of an observation relationship. One problem = then >> is how to distinguish between notifications from observe requests = with >> different options >=20 > That's what we have tokens for. So distinguishing between the > notifications is not a problem. The problem is the identification of > the observation relationship in the presence of unrecognised options. I think the latter one is what Floris was really after. We seem to have two places in the CoAP universe where we install state = in the server that is keyed to the installing endpoint and to some (not = yet very clearly defined set of) request options: 1) -observe: The observation relationship; 2) -block: The reassembly buffer in the stateful version of Block1. Now, these two kinds of state item have quite different purposes = lifetimes, so it may not be a good idea to handle them the same way. For now, I'm assuming there will be some commonality. Right now, an endpoint that wants to have multiple instances of the = state has to a) become multiple endpoints, e.g., by varying the port number. b) vary some of those request options. a is expensive with DTLS. b is influenced by what request options actually go into the identifier = of this state. Robert Quattlebaum seems to suggest adding a "stoken" to enable b when = there is no other request option to vary. Inversely, an endpoint that has changed in some way (new IP address, new = DTLS connection) has no way of picking up the state of its previous = incarnation. For 2, this might be about continuing to send blocks for POSTing during = an address change. Maybe not that likely. For 1, this might be about redirecting an existing observation = relationship to a new address. Hmm. There are obvious security implications to enabling this kind of = tampering (but of course the endpoint information isn't securely = transmitted anyway even now). I haven't really made up my mind whether this is a problem worth solving = in a general way. Except that we do need to define what is included in the set of request = options (b). For 2, intermediaries don't actually combine requests, so there is = little problem in including more request options in the differentiating = set (except where these are manipulated in an unpredictable way by an = intermediary, which would jeopardize putting the pieces together at the = server). For 1, we would like to be able to combine observation relationships. As we have seen with Accept, that is tricky when the request options = differ. So the fallback, again, should probably be inclusive. This needs more thinking. Gr=FC=DFe, Carsten From hartke@tzi.org Wed Feb 6 07:21:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DEB21F8A22 for ; Wed, 6 Feb 2013 07:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7ogoPjBv4xP for ; Wed, 6 Feb 2013 07:21:32 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC9721F88B6 for ; Wed, 6 Feb 2013 07:21:32 -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 r16FLPS6017187 for ; Wed, 6 Feb 2013 16:21:25 +0100 (CET) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6B3EE851 for ; Wed, 6 Feb 2013 16:21:25 +0100 (CET) Received: by mail-la0-f47.google.com with SMTP id fj20so1474104lab.6 for ; Wed, 06 Feb 2013 07:21:24 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.29.229 with SMTP id n5mr11224058lbh.2.1360164084872; Wed, 06 Feb 2013 07:21:24 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 07:21:24 -0800 (PST) In-Reply-To: References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> Date: Wed, 6 Feb 2013 17:21:24 +0200 Message-ID: From: Klaus Hartke To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 15:21:33 -0000 Carsten Bormann wrote: > 2) Asking for a specific media type that is different from the default media type, e.g., for a JSON representation instead of an HTML representation. > > In 2, I haven't seen more than one media type asked for. Maybe we can tweak the Accept option a bit more into that direction? Something along the lines of - If the client doesn't ask for a specific media type, the server returns the default media type + a set of of alternate media types available at the request URI - The client can ask for a specific media type using a critical, non-repeatable If-Content-Format request option which causes the server to return the specific media type or an error. If the server doesn't want to support If-Content-Format, it wouldn't advertise alternate media types. Klaus From kovatsch@inf.ethz.ch Wed Feb 6 07:46:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C09721F897A for ; Wed, 6 Feb 2013 07:46:48 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SyigBrVVqY8 for ; Wed, 6 Feb 2013 07:46:48 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id A1D1021F8976 for ; Wed, 6 Feb 2013 07:46:46 -0800 (PST) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 6 Feb 2013 16:46:26 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.02.0298.004; Wed, 6 Feb 2013 16:46:44 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , Carsten Bormann Thread-Topic: [core] Accept option and intermediaries Thread-Index: AQHOA/HOvR1fkeTn9U+lByHJvtWP2JhsyP+AgAADwYCAAAyqgIAACS4AgAAUg9A= Date: Wed, 6 Feb 2013 15:46:42 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DBB68B@MBX10.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> In-Reply-To: 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 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 15:46:48 -0000 Hi > Carsten Bormann wrote: > > 2) Asking for a specific media type that is different from the default = media > type, e.g., for a JSON representation instead of an HTML representation. > > > > In 2, I haven't seen more than one media type asked for. This is also my experience and a while back Guido (AFAIR) and I were in fav= or of making the Accept option non-repeatable. It reduces complexity and us= ually constrained implementations cannot choose from a variety of available= parsers. I also think that using the Link Format to list available Content= -Formats is the way to go. > - The client can ask for a specific media type using a critical, non-repe= atable > If-Content-Format request option which causes the server to return the > specific media type or an error. What about simply keeping the Accept option and "If none of the preferred C= ontent-Formats can be returned, then a 4.06 "Not Acceptable" MUST be sent a= s a response." (When the server supports the elective Accept option.) Ciao Matthias From kovatsch@inf.ethz.ch Wed Feb 6 08:21:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222CE21F879E for ; Wed, 6 Feb 2013 08:21:15 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKEEMUUlrKJn for ; Wed, 6 Feb 2013 08:21:12 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2D87621F8715 for ; Wed, 6 Feb 2013 08:21:12 -0800 (PST) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 6 Feb 2013 17:20:47 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.02.0298.004; Wed, 6 Feb 2013 17:21:04 +0100 From: "Kovatsch Matthias" To: Robert Quattlebaum , Maciej Wasilak Thread-Topic: [core] Apparent race condition in draft-ietf-core-block-08 Thread-Index: AQHOAX4E3oucihpdpkOwh+/EsKY3ZJhs5E8g Date: Wed, 6 Feb 2013 16:21:03 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DBB70D@MBX10.d.ethz.ch> References: <76B4185D-C1CF-4DF8-89C2-8C610D7A3669@gmail.com> In-Reply-To: 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 Cc: IETF CoRE Working Group Subject: Re: [core] Apparent race condition in draft-ietf-core-block-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 16:21:15 -0000 Dear all I see this race condition as a problem that should be fixed in a cleaner wa= y than providing workarounds like an additional option or even temporary re= sources. This stoken would enable cookies for CoAP, which might go a bit to= o far for constrained environments. The mentioned keeping of state is alrea= dy provided in a limited way through the byte offset provided by the block = options. But maybe there are other scenarios for cookies? The main reason to disentangle the token and block options was that it did = appear "obscure" that a client would perform multiple concurrent PUT/POST r= equests. The token dependency only introduced complexity that we could get = rid of. In Robert's scenario, however, concurrent transfers is exactly what= the proxy would do in its client role (let's assume congestion control is = obeyed); and it does make sense for POSTs that result in the creation of ne= w resources. The natural thing would be that the proxy assigns different to= kens to the open requests, so the proxy can also distinguish the responses = and send them back to the correct clients. This would mean that we need to revert back to the (IP, port, Uri-Path, tok= en) tuple to identify ongoing transfers. An alternative would be to put mor= e complexity onto the proxy: it would have to cache and serialize the incom= ing requests. I believe the origin server must have some means to ensure its resources do= not corrupt in normal operation and to decide if they did, e.g., because o= f a client crash in the middle of a transfer. For more powerful servers, th= is is atomic processing. For constrained servers, I would (in Erbium I actu= ally do) only allow one ongoing transfer and send a 5.03 "Service Unavailab= le" response to all others. Both will need a timeout to detect incomplete t= ransfers. This goes in hand with reverting to the use of the token, as orig= in servers cannot trust proxies to get the serialization right. Are there a= ny objections, comments, or agreements on that? Not corrupting resources is also related to the random access feature throu= gh blockwise transfers. For Block2 it enables a resume feature for free, so= that is okay. But for Block1, this feature does not make much sense in my = eyes. One would always have to deal with padding like whitespaces in JSON t= o have a random access behavior. It makes much more sense to use queries to= access specific parts of a resource! Thus, I still request to enforce in-order transfers of blocks, always start= ing at zero for Block1. Ciao Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Robert Quattlebaum > Sent: Samstag, 2. Februar 2013 20:46 > To: Maciej Wasilak > Cc: IETF CoRE Working Group > Subject: Re: [core] Apparent race condition in draft-ietf-core-block-08 >=20 > Hello Maciej. Sorry for the late reply. >=20 > On Jan 23, 2013, at 12:31 PM, Maciej Wasilak wrote: >=20 > > As far as I understand all stateful blockwise transfers should be ident= ified > now by a tuple (client, uri_path), where client is another tuple (address= , > port). I agree that introducing proxies might lead to race conditions. It= is true > for PUT/POST transfers, but also for stateful GET transfers (as in draft-= ietf- > core-block-10: "The server may identify the sequence by the combination o= f > the requesting end-point and the URI being the same in each block-wise > request."). So if two GET requests (for example with different uri-query)= are > sent through a proxy, server also won't be able to tell them apart. >=20 > This is true as well, but with GET transfers there are mechanisms that ca= n be > used to work around this, such as caching. However, a non-caching proxy > server could easily run afoul of this problem with a blockwise GET. >=20 > > Some practical workaround might be sending POST/PUT requests to > subresources instead of a base resource: > > POST /data-sink/sensor1 > > POST /data-sink/sensor2 > > where sensor1 and sensor2 are temporary labels, instead of: > > POST /data-sink > > However both proxy and server need to understand these labels, which > might be complicated. >=20 > Yes, you could work around this issue at the application level, but it wo= uld be > profoundly unfortunate for such a hack to be necessary in the first place= . If > we have the opportunity to truly fix this at this level before the drafts > become standards, I think we should. > An ideal solution would require no changes for transfers which > disambiguation is not necessary. >=20 > I have bounced a few ideas for solutions off of Carsten, but he seems to = be > rather busy lately. The solution I brought up was to add a new option cal= led a > 'stoken'. The solution has the following pros and cons: >=20 > ### Pros ### >=20 > * Appears to solve all of the problems I described earlier. > * Has additional benefits for constrained servers serving dynamic > content. > * Client doesn't need prior knowledge if the option is necessary > because the client only uses the option when told to by the server. > * Works with both block1 and block2. > * Not conceptually limited to the block protocol. For example, it > could be used for canceling individual observations (although that > would only really be a problem if you were using a non-caching > proxy as far as I can tell) > * Option would only be used by the server when required, so > constrained clients may leave it out and still continue to work > in the majority of cases. > * Constrained Clients which don't implement the stoken option (and > have an NSTART of 1) could still benefit from the use of the option > by using a proxy which supported the stoken option. >=20 > ### Cons ### >=20 > * Adds yet another option. > * Clients wanting to implement this would need to be able to store > an additional ~10 bytes of state between receipt of a response and > the sending of the next related request. >=20 > A more formalized explanation of the semantics of the option are describe= d > below. I'd love some feedback, especially about any potential edge cases = or > other issues. >=20 > -------------------- >=20 > * Option Name: `Stoken` > * Option Number: TBD > * Critical: TBD > * Unsafe: No > * Data: Opaque 0-8 bytes > * Default value: Empty >=20 > The `stoken` option is used when a server needs to associate a subsequent > request as being definitively related to a specific prior request. The sp= ecific > value of the stoken option is meaningful only to the server and is entire= ly > opaque to the client. Only sequential requests can be related using this > mechanism. >=20 > If a server receives a request that it needs to definitively associate wi= th a > subsequent request, it will add a stoken option to the response (the spec= ific > value of which is implementation specific). > When the client sends the next request in the series, it will include the > stoken option from the previously received response. The server can then > use the stoken value to relate the current request to the previous reques= t. > This process can associate an indefinite number of requests. The server i= s not > restricted to using the same stoken value for each response in the series= . >=20 > CLIENT SERVER > | | > | CON [MID=3D1234], GET, /status ------> | > | | > | <------ ACK [MID=3D1234], 2.05 Content | > | Stoken:5678 Block2:0/1/128 | > | | > | CON [MID=3D1235], GET, /status ------> | > | Stoken:5678 Block2:1/1/128 | > | | > | <------ ACK [MID=3D1235], 2.05 Content | > | Stoken:9012 Block2:1/1/128 | > | | > | CON [MID=3D1236], GET, /status ------> | > | Stoken:9012 Block2:2/0/128 | > | | > | <------ ACK [MID=3D1236], 2.05 Content | > | Block2:2/0/128 | > Figure 1. Block2 with Stoken >=20 >=20 > CLIENT SERVER > | | > | CON [MID=3D1237], PUT, /options ------> | > | Block1:0/1/128 | > | | > | <------ ACK [MID=3D1237], 2.05 Content | > | Stoken:1111 Block1:0/1/128 | > | | > | CON [MID=3D1238], PUT, /options ------> | > | Stoken:1111 Block1:1/1/128 | > | | > | <------ ACK [MID=3D1238], 2.05 Content | > | Stoken:2222 Block1:1/1/128 | > | | > | CON [MID=3D1239], PUT, /options ------> | > | Stoken:2222 Block1:2/0/128 | > | | > | <------ ACK [MID=3D1239], 2.05 Content | > | Block1:1/0/128 | > Figure 2. Block1 with Stoken >=20 > From a different perspective, the stoken option may be used to store serv= er > state about the ongoing transaction, without actually storing any state i= n the > server. This is especially useful when serving potentially large content-= --like > link-formats---dynamically, without server-side state. >=20 > Example: Let's say we have a large list of links that is dynamically gene= rated. > Each link entry is a variable size. With the stoken parameter, we can > implement this efficiently without any state on the server by storing the > index of the last item along with the number of bytes from the last item = we > managed to add to the end of the returned block. When the client sends th= e > request for the next block, we will know exactly where we left off from. > Without the stoken parameter we would have either had to start over from > scratch on each request (dramatically increasing the resources required t= o > serve later requests) or store the state for each transaction, keyed off = of the > client IP address and port (Which I have just shown to be somewhat > unreliable). >=20 > -- Robert >=20 > > > > Best Regards > > > > Maciej Wasilak > > 2012/12/24 Robert Quattlebaum > >> Hello everyone, > >> > >> I just wanted to bring up a race condition apparently present in the > >> current blockwise transfer draft. However, even if you are not > >> interested in draft-ietf-core-block, you may want to read over this > >> email anyway: Similar problems may be present in protocols which need > >> the server to associate multiple messages as being a part of the same > >> logical request. For now I'll limit the discussion to > >> draft-ietf-core-block-10. > >> > >> Previously, the token field (as well as the source IP address and > >> port) could be used by the server to correlate multiple messages that > >> were a part of the same logical request ("token-affinity"). > >> In this sense the token field was not really opaque because the > >> server was relying on the value of the token to not change between > >> subsequent messages in the same logical request. However, this > >> semantic-entanglement had the benefit of ensuring truly atomic > >> behavior of requests which consist of multiple messages, without > >> depending on artificial limitations on how the protocol should be > >> used or the behavior of a specific transport layer. > >> > >> At some point over the past year (Forgive me, I haven't been paying > >> attention), the semantics of the token parameter was clarified to be > >> entirely opaque (meaning that only the client's address/port could be > >> used for determining which messages are a part of the same blocked > >> request). This was a reasonable change because it allows client > >> implementations to be more flexible. However, without further > >> clarification or additional mechanisms, this change leads to > >> undefined/unreliable behavior in certain cases. > >> > >> Consider the case where you have a LoWPAN where nodes regularly > dump > >> gathered information to a CoAP server in "the cloud" via a CoAP-CoAP > >> proxy. If two (or more) nodes try to perform a large POST (using > >> Block1) to the same CoAP URL thru the proxy at the same time, the > >> destination machine in the cloud has no way to differentiate the > >> messages as being two independent atomic requests. > >> > >> In a previous discussion off-list, Carsten suggested that the proxy > >> could identify the start of subsequent requests as potentially > >> conflicting and use a different source port for each conflicting > >> request sent from the proxy, but this technique only works if the > >> cloud-side transport layer uses the UDP/IP transport---this technique > >> would not work if the proxy was sending requests to the cloud via > >> CoAP-over-SMS, as described in section 14 of > >> draft-becker-core-coap-sms-gprs-02. > >> > >> I think the root of this problem is the reliance on information from > >> the transport layer in determining which individual messages belong > >> to the same logical request. Doing this just happens to work out in > >> most cases. However, because these edge cases are transient in > >> nature, diagnosing such problems in the field may be very difficult > >> and frustrating. Sure, there are work-arounds, but they have specific > >> disadvantages which may not be obvious. > >> > >> The bottom line is that by refining the semantics of the token field > >> to no longer allow the server to use token-affinity to associate > >> multiple messages to logical requests, a race condition has been > >> introduced into the protocol. This race condition was hidden by the > >> fact that, by using the address/port information from the transport > >> layer, things *usually* work just fine. Usually, but not always. > >> > >> All that being said, I don't necessarily believe that reverting the > >> token behavior is necessarily the right solution to this problem: > >> Allowing the client to use the token to keep track of state on a > >> message-per-message basis is useful. The trick is giving the same > >> flexibility to the server: If we can't rely entirely on the transport > >> layer information to associate logically-related messages (and we > >> can't use the token) then what should be used? > >> > >> We could always simply document this class of problems in the draft > >> so that implementors are aware that they may need to work around it, > >> but I worry that this may be the first of a class of similar race > >> conditions if this issue is not addressed directly. > >> > >> Thoughts? > >> >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From kovatsch@inf.ethz.ch Wed Feb 6 08:36:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4FA21F8759 for ; Wed, 6 Feb 2013 08:36:43 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW3xt2JcIiA6 for ; Wed, 6 Feb 2013 08:36:43 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2042D21F8585 for ; Wed, 6 Feb 2013 08:36:42 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 6 Feb 2013 17:36:23 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Wed, 6 Feb 2013 17:36:41 +0100 From: "Kovatsch Matthias" To: IETF CoRE Working Group Thread-Topic: uint option with length zero Thread-Index: Ac4EhzsTwr3ISIq3Smunr/WkGPK1VA== Date: Wed, 6 Feb 2013 16:36:39 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DBB76A@MBX10.d.ethz.ch> 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: [core] uint option with length zero X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 16:36:44 -0000 Dear list Due to a bit of confusion on the Contiki mailing list, I wondered if it sho= uld be made explicit in core-coap that a uint value of zero SHOULD be encod= ed with an option length of zero. At the moment it is somewhat fuzzy with t= he text on leading zeros (a single zero is not really a leading zero). Or maybe I just missed it? I would expect it in 3.2. Option Value Formats..= . Ciao Matthias From cabo@tzi.org Wed Feb 6 13:25:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA6C21F85ED for ; Wed, 6 Feb 2013 13:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Htz7tzI7GBhi for ; Wed, 6 Feb 2013 13:25:54 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDB021F85B2 for ; Wed, 6 Feb 2013 13:25:53 -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 r16LPemA012845; Wed, 6 Feb 2013 22:25:40 +0100 (CET) Received: from [192.168.217.105] (p548927BC.dip.t-dialin.net [84.137.39.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40D3BA0A; Wed, 6 Feb 2013 22:25:40 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514DBB76A@MBX10.d.ethz.ch> Date: Wed, 6 Feb 2013 22:25:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514DBB76A@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1499) Cc: IETF CoRE Working Group Subject: Re: [core] uint option with length zero X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 21:25:55 -0000 On Feb 6, 2013, at 17:36, "Kovatsch Matthias" = wrote: > Dear list >=20 > Due to a bit of confusion on the Contiki mailing list, I wondered if = it should be made explicit in core-coap that a uint value of zero SHOULD = be encoded with an option length of zero. It never hurts to add an example. I added: For example, the number 0 is represented with an empty option value (a zero-length sequence of bytes), and the number 1 by a single byte with the numerical value of 1 (bit combination 00000001 in most significant bit first notation). I also changed "zeros" into "zero bytes" to make the term less = mistakable. In SVN as [1218]. Thanks! Gr=FC=DFe, Carsten From hartke@tzi.org Wed Feb 6 17:36:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EB421F8552 for ; Wed, 6 Feb 2013 17:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bcWIFll5OA1 for ; Wed, 6 Feb 2013 17:36:17 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4985221F8546 for ; Wed, 6 Feb 2013 17:36:17 -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 r171aALm007195 for ; Thu, 7 Feb 2013 02:36:10 +0100 (CET) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CF3B6A60 for ; Thu, 7 Feb 2013 02:36:09 +0100 (CET) Received: by mail-lb0-f174.google.com with SMTP id l12so1729536lbo.19 for ; Wed, 06 Feb 2013 17:36:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.121.212 with SMTP id lm20mr28287508lab.42.1360200969315; Wed, 06 Feb 2013 17:36:09 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 17:36:09 -0800 (PST) In-Reply-To: <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> Date: Thu, 7 Feb 2013 03:36:09 +0200 Message-ID: From: Klaus Hartke To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 01:36:18 -0000 What about something like this: * A client (or intermediary in the client role) must bundle multiple observations into one wherever possible, but a server (or intermediary in the server role) does not enforce this. Each GET request with an Observe Option adds the client one time to the list of observers and does not replace any existing entry. This solves the problem of clients inadvertently causing servers to cancel an observation if they don't agree on what makes two requests the same, and it liberates -observe from the unRESTfulness. * A client (or intermediary in the client role) can reuse an existing observation if and only if the cache key matches. This may lead to some redundant observations if the client does not recognise an option, but if the option is part of the cache key then the likelihood of exactly identical notifications should be low. This is consistent with when a client reuses an existing response from its cache. Klaus From Bert.Greevenbosch@huawei.com Wed Feb 6 22:13:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654D221F8651 for ; Wed, 6 Feb 2013 22:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A0wXm0vZxd9 for ; Wed, 6 Feb 2013 22:13:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0AC21F84D8 for ; Wed, 6 Feb 2013 22:13:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APM80578; Thu, 07 Feb 2013 06:13:23 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 06:12:26 +0000 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 06:13:22 +0000 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.007; Thu, 7 Feb 2013 14:13:16 +0800 From: Bert Greevenbosch To: Klaus Hartke , "core@ietf.org WG" Thread-Topic: [core] #281: Safe-to-forward options Thread-Index: AQHOBGTD8q9v0AFZgUWmx2wypghaCphsPsaAgAAFLICAABRMAIAAAJ0AgAAByACAAAKUAIAAAS6AgAABdICAAArwAIAArVOAgADRr0A= Date: Thu, 7 Feb 2013 06:13:15 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 06:13:26 -0000 Hi Klaus, Carsten, Floris, Thomas, all, Currently, the client can modify the observation relationship by doing anot= her GET, with modified options. However, if we apply the mechanism below, the client must at least include = all cache-key options it used before. Am I correct that this means that the= client cannot change the values of these options (or their existence) by j= ust sending a new GET with "observe" option and modified other options? In = other words, if the client wants to change a cache-key option, should it fi= rst de-register using RST and then re-register with the new cache-key optio= n? Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: 07 February 2013 09:36 To: core@ietf.org WG Subject: Re: [core] #281: Safe-to-forward options What about something like this: * A client (or intermediary in the client role) must bundle multiple observations into one wherever possible, but a server (or intermediary in the server role) does not enforce this. Each GET request with an Observe Option adds the client one time to the list of observers and does not replace any existing entry. This solves the problem of clients inadvertently causing servers to cancel an observation if they don't agree on what makes two requests the same, and it liberates -observe from the unRESTfulness. * A client (or intermediary in the client role) can reuse an existing observation if and only if the cache key matches. This may lead to some redundant observations if the client does not recognise an option, but if the option is part of the cache key then the likelihood of exactly identical notifications should be low. This is consistent with when a client reuses an existing response from its cache. Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Wed Feb 6 22:32:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1185A21F8539 for ; Wed, 6 Feb 2013 22:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpS05jNgbH7x for ; Wed, 6 Feb 2013 22:32:06 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C7D1321F84E4 for ; Wed, 6 Feb 2013 22:32:05 -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 r176Vwt3022211 for ; Thu, 7 Feb 2013 07:31:58 +0100 (CET) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 46F23A86 for ; Thu, 7 Feb 2013 07:31:58 +0100 (CET) Received: by mail-lb0-f177.google.com with SMTP id go11so1865938lbb.36 for ; Wed, 06 Feb 2013 22:31:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.144.103 with SMTP id sl7mr182425lab.23.1360218717731; Wed, 06 Feb 2013 22:31:57 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 22:31:57 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> Date: Thu, 7 Feb 2013 08:31:57 +0200 Message-ID: From: Klaus Hartke To: Bert Greevenbosch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 06:32:07 -0000 Bert Greevenbosch wrote: > Currently, the client can modify the observation relationship by doing an= other GET, with modified options. > > However, if we apply the mechanism below, the client must at least includ= e all cache-key options it used before. Am I correct that this means that t= he client cannot change the values of these options (or their existence) by= just sending a new GET with "observe" option and modified other options? I= n other words, if the client wants to change a cache-key option, should it = first de-register using RST and then re-register with the new cache-key opt= ion? Yes, that's correct. The only other solution I came up with so far: If a GET request contains an Observe Option, treat any unrecognised options that are safe-to-forward like options that are not safe, i.e., remove them or reject the option with an error response depending on elective/critical. I wouldn't be very happy with this solution. Klaus From Bert.Greevenbosch@huawei.com Wed Feb 6 22:39:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3821F84CC for ; Wed, 6 Feb 2013 22:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYUIQZZqVDLK for ; Wed, 6 Feb 2013 22:39:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D72421F84CA for ; Wed, 6 Feb 2013 22:39:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APM82241; Thu, 07 Feb 2013 06:39:19 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 06:38:22 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 06:39:18 +0000 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.007; Thu, 7 Feb 2013 14:39:15 +0800 From: Bert Greevenbosch To: "trac+core@grenache.tools.ietf.org" , "draft-ietf-core-observe@tools.ietf.org" , "hartke@tzi.org" Thread-Topic: eTag safe to forward? (was: RE: [core] #281: Safe-to-forward options) Thread-Index: AQHOBP3ZPL21qYRZqEKhIZouY2WkIA== Date: Thu, 7 Feb 2013 06:39:15 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D58396D@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> In-Reply-To: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: [core] eTag safe to forward? (was: RE: #281: Safe-to-forward options) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 06:39:21 -0000 Hi all, Another option currently marked as "safe to forward" is eTag. In case a reverse-proxy aggregates information from several servers, and de= livers it to a client as a single resource, it should not forward the eTags= from the servers. Also, if the client includes an eTag in a request and th= e proxy forwards it to the several servers, interesting errors will occur. I guess the proxy not forwarding the eTag from any server will also resolve= the second problem, as the client wouldn't know which eTag to include anyw= ay. Also, a smart aggregating reverse-proxy should understand eTag and hand= le it appropriately, like described in section 5.7.3. But more in general, what should aggregating reverse-proxies do with safe-t= o-forward options? They may make sense only for individual responses, so ma= ybe aggregating reverse-proxies shouldn't forward any unknown options, even= when they are "safe to forward". Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of cor= e issue tracker Sent: 06 February 2013 17:42 To: draft-ietf-core-observe@tools.ietf.org; hartke@tzi.org Cc: core@ietf.org Subject: [core] #281: Safe-to-forward options #281: Safe-to-forward options A GET request with an Observe Option to an intermediary can contain options that the intermediary doesn't recognise. Up to coap-11, this wasn't a problem, because these options were rejected/removed, so the request to the origin server didn't contain them. Since coap-12, options can be "safe to forward". An intermediary can include these in a request to the server even if it doesn't recognised them. This is a problem, because each of the options could affect the observation relationship between intermediary and server in a way that makes the notifications unsuitable for sharing between clients with different unrecognised options in their requests. Since the intermediary doesn't recognise the options, it can also not tell if the request will lead to a new observation relationship or override an existing one. --=20 -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-07 Component: observe | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Wed Feb 6 22:41:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A1121F84CC for ; Wed, 6 Feb 2013 22:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2dvZNaqbCpr for ; Wed, 6 Feb 2013 22:41:23 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EDE9621F84CA for ; Wed, 6 Feb 2013 22:41:22 -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 r176fG13026392 for ; Thu, 7 Feb 2013 07:41:16 +0100 (CET) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EC487A89 for ; Thu, 7 Feb 2013 07:41:15 +0100 (CET) Received: by mail-lb0-f169.google.com with SMTP id m4so1884045lbo.0 for ; Wed, 06 Feb 2013 22:41:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.38.228 with SMTP id j4mr316408lbk.1.1360219275478; Wed, 06 Feb 2013 22:41:15 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 22:41:15 -0800 (PST) In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> Date: Thu, 7 Feb 2013 08:41:15 +0200 Message-ID: From: Klaus Hartke To: Bert Greevenbosch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 06:41:23 -0000 Klaus Hartke wrote: > Bert Greevenbosch wrote: >> However, if we apply the mechanism below, the client must at least inclu= de all cache-key options it used before. Am I correct that this means that = the client cannot change the values of these options (or their existence) b= y just sending a new GET with "observe" option and modified other options? = In other words, if the client wants to change a cache-key option, should it= first de-register using RST and then re-register with the new cache-key op= tion? > > Yes, that's correct. But is it a problem? If it is, the client could include the token of a previously created observation in its request. This would signal to the server to update/replace the existing entry. If there is no token in the request or the token doesn't match any existing list entry, a new entry is created. Klaus From Bert.Greevenbosch@huawei.com Wed Feb 6 22:53:16 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBED21F863C for ; Wed, 6 Feb 2013 22:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fShlL0wxapWg for ; Wed, 6 Feb 2013 22:53:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7121F85CC for ; Wed, 6 Feb 2013 22:53:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APM83164; Thu, 07 Feb 2013 06:53:13 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 06:52:16 +0000 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 06:53:12 +0000 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.007; Thu, 7 Feb 2013 14:53:09 +0800 From: Bert Greevenbosch To: Klaus Hartke Thread-Topic: [core] #281: Safe-to-forward options Thread-Index: AQHOBGTD8q9v0AFZgUWmx2wypghaCphsPsaAgAAFLICAABRMAIAAAJ0AgAAByACAAAKUAIAAAS6AgAABdICAAArwAIAArVOAgADRr0D//4D2gIAAApmAgACHf3A= Date: Thu, 7 Feb 2013 06:53:08 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 06:53:16 -0000 Hi Klaus, > But is it a problem? Maybe. It means more checking at registration of an observe relationship, a= s the server now needs to do bookkeeping of all options that were included = at request time, and verify these options when it receives a new request. Linking this somehow to the token seems to be a better solution. The server= currently already keeps track of the token, as it needs to include it in t= he messages associated with an observation relationship anyway. So includin= g the token in the (ip,port,resource) tupple to indentify the observation r= elationship seems to be easier to implement than adding bookkeeping for var= ious cache-key options. What do you think? Best regards, Bert -----Original Message----- From: Klaus Hartke [mailto:hartke@tzi.org]=20 Sent: 07 February 2013 14:41 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: Re: [core] #281: Safe-to-forward options Klaus Hartke wrote: > Bert Greevenbosch wrote: >> However, if we apply the mechanism below, the client must at least inclu= de all cache-key options it used before. Am I correct that this means that = the client cannot change the values of these options (or their existence) b= y just sending a new GET with "observe" option and modified other options? = In other words, if the client wants to change a cache-key option, should it= first de-register using RST and then re-register with the new cache-key op= tion? > > Yes, that's correct. But is it a problem? If it is, the client could include the token of a previously created observation in its request. This would signal to the server to update/replace the existing entry. If there is no token in the request or the token doesn't match any existing list entry, a new entry is created. Klaus From hartke@tzi.org Wed Feb 6 23:00:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EA721F865B for ; Wed, 6 Feb 2013 23:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCciRtwQVeN4 for ; Wed, 6 Feb 2013 23:00:18 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23721F8652 for ; Wed, 6 Feb 2013 23:00:15 -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 r17709iF004034 for ; Thu, 7 Feb 2013 08:00:09 +0100 (CET) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DB91AA90 for ; Thu, 7 Feb 2013 08:00:08 +0100 (CET) Received: by mail-lb0-f173.google.com with SMTP id gf7so1884369lbb.18 for ; Wed, 06 Feb 2013 23:00:08 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.133.133 with SMTP id pc5mr223855lab.32.1360220408196; Wed, 06 Feb 2013 23:00:08 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 23:00:08 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> Date: Thu, 7 Feb 2013 09:00:08 +0200 Message-ID: From: Klaus Hartke To: Bert Greevenbosch Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 07:00:19 -0000 Bert Greevenbosch wrote: > It means more checking at registration of an observe relationship, as the server now needs to do bookkeeping of all options that were included at request time, and verify these options when it receives a new request. The proposal was that the server doesn't perform any checking at all. If a GET request with Observe Option comes in, it adds a new entry to the list of observers. But if a proxy observes a resource on behalf of a client, and then another client also wants to observe something through the proxy, the proxy has to decide if it can reuse the existing observation relationship or if it has to create a new one. The proposal was that the server uses the cache-key for this. This requires some bookkeeping at the proxy, but not at the server. Klaus From darconeous@gmail.com Wed Feb 6 23:04:06 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C579221F869F for ; Wed, 6 Feb 2013 23:04:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id my-2wRB9OPxB for ; Wed, 6 Feb 2013 23:04:06 -0800 (PST) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE0321F869A for ; Wed, 6 Feb 2013 23:04:06 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id p5so1062700dak.33 for ; Wed, 06 Feb 2013 23:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=PSwR+sRPHygXtrtKD/BAkprLyrqdi2buiOpe7bLd5v0=; b=ySysiDV+VPQiUYwBzYIpU89WWfg9gPp1jCkICcztOXgLIkaJRCpE4JidY2pRvw3LvD YwFB5VHUDLder+jFY9iXP4q/ZdAYzBP7WsotxiKgfYJFWiXLqq9+EfhexQVkUzgJJeS+ 35OEDobMDoTsKRcPqpJyAIp4fh0hBnYzcNGuhV4pfjju7sB4rWBNTuX0GR0BfiwxcucI agNzQbAkOdLZqk5nfJUq4ZsI5WYdiYl610+VAhP5V7CsIgYU1/kdXoGE3R3O3HryAMkA Qj+1hey/qqvNdEXqH2TIowi9TN8XfLUnZRwW9k9KYX/JxPLOIet/KANiyjA5o8D6hKpx Q3Yw== X-Received: by 10.66.83.6 with SMTP id m6mr2763166pay.52.1360220645884; Wed, 06 Feb 2013 23:04:05 -0800 (PST) Received: from [172.30.96.30] (c-67-174-221-32.hsd1.ca.comcast.net. [67.174.221.32]) by mx.google.com with ESMTPS id x2sm43649656paw.8.2013.02.06.23.04.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 23:04:05 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514DBB70D@MBX10.d.ethz.ch> Date: Wed, 6 Feb 2013 23:04:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3DCF59BD-133B-49D6-8102-777A4E215C0C@gmail.com> References: <76B4185D-C1CF-4DF8-89C2-8C610D7A3669@gmail.com> <55877B3AFB359744BA0F2140E36F52B514DBB70D@MBX10.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1499) Cc: IETF CoRE Working Group Subject: Re: [core] Apparent race condition in draft-ietf-core-block-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 07:04:06 -0000 Hello Kovatsch, I just wanted to clarify one point: On Feb 6, 2013, at 8:21 AM, Kovatsch Matthias = wrote: > I see this race condition as a problem that should be fixed in a = cleaner way than providing workarounds like an additional option or even = temporary resources. This stoken would enable cookies for CoAP, which = might go a bit too far for constrained environments. The mentioned = keeping of state is already provided in a limited way through the byte = offset provided by the block options. But maybe there are other = scenarios for cookies? Cookies, to me anyway, imply storage and potentially other complex = mechanisms. The `stoken` option makes for a lousy cookie. It's only = purpose is to relate different requests as being apart of a single = logical operation. If present in a server response, it is used only once = in a subsequent related request (if any). After that it is discarded (or = replaced with a new stoken). -- Robert From Bert.Greevenbosch@huawei.com Wed Feb 6 23:15:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FCD21F869A for ; Wed, 6 Feb 2013 23:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVQcWRqcjOKT for ; Wed, 6 Feb 2013 23:15:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C3AD121F8599 for ; Wed, 6 Feb 2013 23:15:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOF93829; Thu, 07 Feb 2013 07:15:55 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 07:15:53 +0000 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 07:15:55 +0000 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Thu, 7 Feb 2013 15:15:46 +0800 From: Bert Greevenbosch To: Klaus Hartke Thread-Topic: [core] #281: Safe-to-forward options Thread-Index: AQHOBGTD8q9v0AFZgUWmx2wypghaCphsPsaAgAAFLICAABRMAIAAAJ0AgAAByACAAAKUAIAAAS6AgAABdICAAArwAIAArVOAgADRr0D//4D2gIAAApmAgACHf3D//33IAIAAhtCA Date: Thu, 7 Feb 2013 07:15:46 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 07:15:57 -0000 Hi Klaus, I am still a bit confused about the cache-key. See also one of my comment 1= 9 from the link below. I wrote: http://www.ietf.org/mail-archive/web/core/current/msg03976.html { The cache key seems to be the collection of options that are needed to iden= tify a particular representation of a resource. After much reading, I under= stand that when a request contains options that are in the cache key, and t= he proxy does not have a cached representation for exactly those values of = the cache key options, then it needs to acquire the related representation,= whereas if all options are proxy-safe and not in the cache key, the proxy = can ignore them and provide the cached response. } The above text is my current understanding of the cache-key. Is it correct? If so, I guess the server does not need to maintain bookkeeping of the cach= e-key, as the cache-key is designed for the proxy. The server simply return= s whatever when it gets a request; it probably does not maintain a cache it= self. But maybe I misunderstand your e-mail below. Do you mean the proxy does the= cache-key bookkeeping, and considers whether it needs to establish a new o= bservation relationship or not, and not the server? So the server still mai= ntains the (ip,port,resource) tuple and the proxy starts a new one e.g. thr= ough using a different port? Best regards, Bert -----Original Message----- From: Klaus Hartke [mailto:hartke@tzi.org]=20 Sent: 07 February 2013 15:00 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: Re: [core] #281: Safe-to-forward options Bert Greevenbosch wrote: > It means more checking at registration of an observe relationship, as the= server now needs to do bookkeeping of all options that were included at re= quest time, and verify these options when it receives a new request. The proposal was that the server doesn't perform any checking at all. If a GET request with Observe Option comes in, it adds a new entry to the list of observers. But if a proxy observes a resource on behalf of a client, and then another client also wants to observe something through the proxy, the proxy has to decide if it can reuse the existing observation relationship or if it has to create a new one. The proposal was that the server uses the cache-key for this. This requires some bookkeeping at the proxy, but not at the server. Klaus From darconeous@gmail.com Wed Feb 6 23:18:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEF021F8599 for ; Wed, 6 Feb 2013 23:18:34 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os7KhnyINXLv for ; Wed, 6 Feb 2013 23:18:34 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0879B21F84F8 for ; Wed, 6 Feb 2013 23:18:33 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id hz1so1257696pad.10 for ; Wed, 06 Feb 2013 23:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=6Yqz+dZ9XT2QHVcnSNi1GV/1/TFhNGwoqErSbgjk4OY=; b=UQbZcdtOncaVQflhqPz83nngx+VGxUSAttgG0hHWW70YYfSJnWpBAQj8ztv/ReEN8i FHBFclCuhR5eI77d8O2QazsW9ZXk1XS9vyDQaZWBScLKQ68WxZ6D1/RNBHaeI1ebCsqg CGML4fYTUZrIsUxznELJk0KsqsV0ndQVB1aKKlYQ4cTaVKnprdJR1x5XstNKjiPPPY2J vfpxKgKe+xPkdU4E5Y3Gmyz1Xbrdzjajlx0LRBQpP7Gcx/vHfhxVie21zCpq9EkDhJKX 9UQ3vhk1DXIn5GapweZVeMC71YpVUUaw1h8xjv+HfwH7+3Q2ILvhUFd8BcU2VduNq1NN ijdA== X-Received: by 10.66.85.73 with SMTP id f9mr3087743paz.13.1360221513599; Wed, 06 Feb 2013 23:18:33 -0800 (PST) Received: from [172.30.96.30] (c-67-174-221-32.hsd1.ca.comcast.net. [67.174.221.32]) by mx.google.com with ESMTPS id d1sm43739127pav.6.2013.02.06.23.18.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 23:18:32 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> Date: Wed, 6 Feb 2013 23:18:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <63008E6F-D316-4312-8391-22F003159B44@gmail.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1 DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 07:18:35 -0000 On Feb 6, 2013, at 10:53 PM, Bert Greevenbosch = wrote: > Hi Klaus, >=20 >> But is it a problem? >=20 > Maybe. It means more checking at registration of an observe = relationship, as the server now needs to do bookkeeping of all options = that were included at request time, and verify these options when it = receives a new request. >=20 > Linking this somehow to the token seems to be a better solution. The = server currently already keeps track of the token, as it needs to = include it in the messages associated with an observation relationship = anyway. So including the token in the (ip,port,resource) tupple to = indentify the observation relationship seems to be easier to implement = than adding bookkeeping for various cache-key options. >=20 > What do you think? For observing, I think this proposal makes the most sense. It's simple, = self contained, no muss, no fuss. I think any confusion that could come = from this perceived semantic entanglement would be minimal. As Carsten mentioned, this problem stems from the same root problem as = -block, but in this case simply using the token solves the problem = without adding any complexity or losing any flexibility. I don't think = both problems necessarily need the same solution. -- Robert From cabo@tzi.org Wed Feb 6 23:25:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CE621F879A for ; Wed, 6 Feb 2013 23:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.23 X-Spam-Level: X-Spam-Status: No, score=-106.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n2z7XjAJMua for ; Wed, 6 Feb 2013 23:25:21 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35521F8715 for ; Wed, 6 Feb 2013 23:25:21 -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 r177P5M2014308; Thu, 7 Feb 2013 08:25:05 +0100 (CET) Received: from [192.168.217.105] (p548927BC.dip.t-dialin.net [84.137.39.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 98048AA4; Thu, 7 Feb 2013 08:25:04 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D58396D@szxeml558-mbx.china.huawei.com> Date: Thu, 7 Feb 2013 08:25:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <46A1DF3F04371240B504290A071B4DB63D58396D@szxeml558-mbx.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "draft-ietf-core-observe@tools.ietf.org" , "trac+core@grenache.tools.ietf.org" , "core@ietf.org" , "hartke@tzi.org" Subject: Re: [core] eTag safe to forward? (was: RE: #281: Safe-to-forward options) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 07:25:22 -0000 On Feb 7, 2013, at 07:39, Bert Greevenbosch = wrote: > But more in general, what should aggregating reverse-proxies do with = safe-to-forward options? They may make sense only for individual = responses, so maybe aggregating reverse-proxies shouldn't forward any = unknown options, even when they are "safe to forward". I think that an "aggregating reverse-proxy" is necessarily even more = coupled*) to the origin server(s) than reverse proxies already are. First of all, we don't even have an application-independent way of = aggregating responses; if we develop one, we should think about a way to = aggregate response options as well. One of the points of marking a request option safe-to-forward is being = able to rely on that option making it unharmed to an origin server. If you want a proxy to be allowed to swallow them anyway, then you need = the consent of the origin servers. (You may be able to get that for the more coupled case of = reverse-proxies.) Gr=FC=DFe, Carsten *) http://en.wikipedia.org/wiki/Coupling_(computer_programming) From hartke@tzi.org Wed Feb 6 23:52:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560E321F8589 for ; Wed, 6 Feb 2013 23:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3VXVyL8-Lmo for ; Wed, 6 Feb 2013 23:52:14 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7F65521F8809 for ; Wed, 6 Feb 2013 23:52:14 -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 r177q5lu026697 for ; Thu, 7 Feb 2013 08:52:05 +0100 (CET) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D8BECB2C for ; Thu, 7 Feb 2013 08:52:04 +0100 (CET) Received: by mail-la0-f47.google.com with SMTP id fj20so2257512lab.6 for ; Wed, 06 Feb 2013 23:52:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.108.195 with SMTP id hm3mr379303lab.17.1360223524186; Wed, 06 Feb 2013 23:52:04 -0800 (PST) Received: by 10.112.58.13 with HTTP; Wed, 6 Feb 2013 23:52:03 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> Date: Thu, 7 Feb 2013 09:52:03 +0200 Message-ID: From: Klaus Hartke To: Bert Greevenbosch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 07:52:15 -0000 Bert Greevenbosch wrote: > I am still a bit confused about the cache-key. See also one of my comment= 19 from the link below. I wrote: > > http://www.ietf.org/mail-archive/web/core/current/msg03976.html > { > The cache key seems to be the collection of options that are needed to id= entify a particular representation of a resource. After much reading, I und= erstand that when a request contains options that are in the cache key, and= the proxy does not have a cached representation for exactly those values o= f the cache key options, then it needs to acquire the related representatio= n, whereas if all options are proxy-safe and not in the cache key, the prox= y can ignore them and provide the cached response. > } > > The above text is my current understanding of the cache-key. Is it correc= t? Almost, if I understand your comment correctly. The algorithm for an incoming request looks approximately like this: 1. Does the request contain an unrecognised, critical option that is not safe-to-forward? If yes, return an error response; done. 2. Does the request contain an unrecognised, elective option that is not safe-to-forward? If yes, remove it from the request. 3. Create the cache-key for the request. The cache-key includes - the request method, - the options that are recognised and specified in the draft/RFC to be part of the cache-key, - the options that are not recognised and have an option number which indicates that the option is part of the cache-key. Since the set of options recognised by a cache can vary between different implementations, there can be different results for the cache-key. 4. Does the cache contain a response with the same cache-key? If yes and the response is fresh, return it to the client; done. 5. Make a request to the server. Does that clear things up? > If so, I guess the server does not need to maintain bookkeeping of the ca= che-key, as the cache-key is designed for the proxy. The server simply retu= rns whatever when it gets a request; it probably does not maintain a cache = itself. > > But maybe I misunderstand your e-mail below. Do you mean the proxy does t= he cache-key bookkeeping, and considers whether it needs to establish a new= observation relationship or not, and not the server? So the server still m= aintains the (ip,port,resource) tuple and the proxy starts a new one e.g. t= hrough using a different port? I'm not fully sure what I mean yet :-) I think what I mean is that the proxy does the cache-key bookkeeping, and considers whether it needs to establish a new observation relationship or not, and not the server. The server maintains a (ip,port,resource,token) tuple and the proxy starts a new one through using a different token. Does that make sense? Klaus From Bert.Greevenbosch@huawei.com Thu Feb 7 00:02:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCD521F88DD for ; Thu, 7 Feb 2013 00:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwCb35xEno0r for ; Thu, 7 Feb 2013 00:02:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F40D121F8893 for ; Thu, 7 Feb 2013 00:02:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APM88300; Thu, 07 Feb 2013 08:02:13 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 08:01:15 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 08:02:12 +0000 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Thu, 7 Feb 2013 16:02:07 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: [core] eTag safe to forward? (was: RE: #281: Safe-to-forward options) Thread-Index: AQHOBQRLUoFyfYr4SEGwsEDG2zacr5huAZIA Date: Thu, 7 Feb 2013 08:02:06 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D583A31@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <46A1DF3F04371240B504290A071B4DB63D58396D@szxeml558-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-core-observe@tools.ietf.org" , "trac+core@grenache.tools.ietf.org" , "core@ietf.org" , "hartke@tzi.org" Subject: Re: [core] eTag safe to forward? (was: RE: #281: Safe-to-forward options) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 08:02:15 -0000 Hi Carsten, I agree that the behaviour of "reverse aggregating proxies" highly depends = on the particular application, and that it is hard to set general guideline= s. I guess most of these proxies will know exactly what they are doing, and= thus not blindly forward unknown options - even if when these options are = "safe to forward".=20 I think the specialist behaviour of these proxy servers makes it infeasible= to standardise how they should aggregate responses and response options in= general. The consent from the origin server to the proxy is also highly de= pendent on the particular application. Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 07 February 2013 15:25 To: Bert Greevenbosch Cc: trac+core@grenache.tools.ietf.org; draft-ietf-core-observe@tools.ietf.o= rg; hartke@tzi.org; core@ietf.org Subject: Re: [core] eTag safe to forward? (was: RE: #281: Safe-to-forward o= ptions) On Feb 7, 2013, at 07:39, Bert Greevenbosch = wrote: > But more in general, what should aggregating reverse-proxies do with safe= -to-forward options? They may make sense only for individual responses, so = maybe aggregating reverse-proxies shouldn't forward any unknown options, ev= en when they are "safe to forward". I think that an "aggregating reverse-proxy" is necessarily even more couple= d*) to the origin server(s) than reverse proxies already are. First of all, we don't even have an application-independent way of aggregat= ing responses; if we develop one, we should think about a way to aggregate = response options as well. One of the points of marking a request option safe-to-forward is being able= to rely on that option making it unharmed to an origin server. If you want a proxy to be allowed to swallow them anyway, then you need the= consent of the origin servers. (You may be able to get that for the more coupled case of reverse-proxies.) Gr=FC=DFe, Carsten *) http://en.wikipedia.org/wiki/Coupling_(computer_programming) From Bert.Greevenbosch@huawei.com Thu Feb 7 00:19:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A833C21F886A for ; Thu, 7 Feb 2013 00:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZMCuYdfYaXa for ; Thu, 7 Feb 2013 00:19:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 757AF21F84E4 for ; Thu, 7 Feb 2013 00:19:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APM89668; Thu, 07 Feb 2013 08:19:28 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 08:18:31 +0000 Received: from SZXEML461-HUB.china.huawei.com (10.82.67.204) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 08:19:27 +0000 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml461-hub.china.huawei.com ([10.82.67.204]) with mapi id 14.01.0323.007; Thu, 7 Feb 2013 16:19:20 +0800 From: Bert Greevenbosch To: Klaus Hartke Thread-Topic: [core] #281: Safe-to-forward options Thread-Index: AQHOBGTD8q9v0AFZgUWmx2wypghaCphsPsaAgAAFLICAABRMAIAAAJ0AgAAByACAAAKUAIAAAS6AgAABdICAAArwAIAArVOAgADRr0D//4D2gIAAApmAgACHf3D//33IAIAAhtCA//+HsYAAER/kIA== Date: Thu, 7 Feb 2013 08:19:20 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D583A5C@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 08:19:30 -0000 Hi Klaus, OK, that makes sense. So for the server, the token is going to be part of i= dentification of the observation relationship, but apart from that the serv= er doesn't need to do any more bookkeeping. I like that a lot, especially s= ince it allows usage of the same client port for multiple observation relat= ionships, independently of any options. Thanks for your explanation on the cache key, indeed it clears things up. I agree that it is up to the proxy to determine whether it can use an alrea= dy existent observation relationship, or needs to establish a new observati= on relationship. This choice indeed depends on the cache-key options. Best regards, Bert -----Original Message----- From: Klaus Hartke [mailto:hartke@tzi.org]=20 Sent: 07 February 2013 15:52 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: Re: [core] #281: Safe-to-forward options Bert Greevenbosch wrote: > I am still a bit confused about the cache-key. See also one of my comment= 19 from the link below. I wrote: > > http://www.ietf.org/mail-archive/web/core/current/msg03976.html > { > The cache key seems to be the collection of options that are needed to id= entify a particular representation of a resource. After much reading, I und= erstand that when a request contains options that are in the cache key, and= the proxy does not have a cached representation for exactly those values o= f the cache key options, then it needs to acquire the related representatio= n, whereas if all options are proxy-safe and not in the cache key, the prox= y can ignore them and provide the cached response. > } > > The above text is my current understanding of the cache-key. Is it correc= t? Almost, if I understand your comment correctly. The algorithm for an incoming request looks approximately like this: 1. Does the request contain an unrecognised, critical option that is not safe-to-forward? If yes, return an error response; done. 2. Does the request contain an unrecognised, elective option that is not safe-to-forward? If yes, remove it from the request. 3. Create the cache-key for the request. The cache-key includes - the request method, - the options that are recognised and specified in the draft/RFC to be part of the cache-key, - the options that are not recognised and have an option number which indicates that the option is part of the cache-key. Since the set of options recognised by a cache can vary between different implementations, there can be different results for the cache-key. 4. Does the cache contain a response with the same cache-key? If yes and the response is fresh, return it to the client; done. 5. Make a request to the server. Does that clear things up? > If so, I guess the server does not need to maintain bookkeeping of the ca= che-key, as the cache-key is designed for the proxy. The server simply retu= rns whatever when it gets a request; it probably does not maintain a cache = itself. > > But maybe I misunderstand your e-mail below. Do you mean the proxy does t= he cache-key bookkeeping, and considers whether it needs to establish a new= observation relationship or not, and not the server? So the server still m= aintains the (ip,port,resource) tuple and the proxy starts a new one e.g. t= hrough using a different port? I'm not fully sure what I mean yet :-) I think what I mean is that the proxy does the cache-key bookkeeping, and considers whether it needs to establish a new observation relationship or not, and not the server. The server maintains a (ip,port,resource,token) tuple and the proxy starts a new one through using a different token. Does that make sense? Klaus From floris.vandenabeele@intec.ugent.be Thu Feb 7 01:18:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDEC21F8470 for ; Thu, 7 Feb 2013 01:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMCYUly1AF8W for ; Thu, 7 Feb 2013 01:18:54 -0800 (PST) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7636021F8468 for ; Thu, 7 Feb 2013 01:18:50 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 83376C1B6; Thu, 7 Feb 2013 10:18:49 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id EBcq_0Sromcr; Thu, 7 Feb 2013 10:18:48 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp3.ugent.be (Postfix) with ESMTP id 27A05C1B2; Thu, 7 Feb 2013 10:18:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 12C2D1F; Thu, 7 Feb 2013 10:18:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAnHOEzB7Z-j; Thu, 7 Feb 2013 10:18:48 +0100 (CET) Received: from [157.193.135.239] (dhcp-zdpt-239.intec.ugent.be [157.193.135.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id DB3D61E; Thu, 7 Feb 2013 10:18:47 +0100 (CET) Message-ID: <51137177.9040700@intec.ugent.be> Date: Thu, 07 Feb 2013 10:18:47 +0100 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bert Greevenbosch References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D583A5C@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D583A5C@szxeml558-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------050905030603030706060903" X-Miltered: at jchkm3 with ID 51137178.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51137178.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51137178.000 on smtp3.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 09:18:55 -0000 This is a multi-part message in MIME format. --------------050905030603030706060903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Klaus and Bert, I like the idea of using tokens to enable more than 1 observation relationship from a CoAP endpoint. With this approach a client doesn't have to revert to using different sockets for new observe relationships with the same resource. Fixing the mechanism for a client (or proxy) to determine whether or not two observation relationships are combinable to using Cache-Keys seems to be too restricting. Would this allow a proxy to exclude an unknown, elective, safe-to-forward option that is marked as being part of the Cache-Key from said determination ? For example, a proxy might know that the resource on the server doesn't support the unknown, safe-to-forward, elective option anyway (using draft-greevenbosch-core-profile-description-01 or other similar knowledge), and might choose to exclude this option for determining whether to combine relationships. For a server it doesn't matter anyway how the aggregation is actually performed. It just matters that the aggregation is maximal, which might not be the case when the mechanism should get fixed in the future. To summarize: I feel that using the Cache-keys options for relationship aggregation can be a fair 'default' approach but that implementers should have to freedom to deviate from this approach when they deem it necessary. Regards, Floris Op do 07 feb 2013 09:19:20 CET, Bert Greevenbosch schreef: > > Hi Klaus, > > OK, that makes sense. So for the server, the token is going to be part > of identification of the observation relationship, but apart from that > the server doesn't need to do any more bookkeeping. I like that a lot, > especially since it allows usage of the same client port for multiple > observation relationships, independently of any options. > > Thanks for your explanation on the cache key, indeed it clears things up. > > I agree that it is up to the proxy to determine whether it can use an > already existent observation relationship, or needs to establish a new > observation relationship. This choice indeed depends on the cache-key > options. > > Best regards, > Bert > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------050905030603030706060903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Klaus and Bert,

I like the idea of using tokens to enable more than 1 observation relationship from a CoAP endpoint. With this approach a client doesn't have to revert to using different sockets for new observe relationships with the same resource.

Fixing the mechanism for a client (or proxy) to determine whether or not two observation relationships are combinable to using Cache-Keys seems to be too restricting. Would this allow a proxy to exclude an unknown, elective, safe-to-forward option that is marked as being part of the Cache-Key from said determination ? For example, a proxy might know that the resource on the server doesn't support the unknown, safe-to-forward, elective option anyway (using draft-greevenbosch-core-profile-description-01 or other similar knowledge), and might choose to exclude this option for determining whether to combine relationships. For a server it doesn't matter anyway how the aggregation is actually performed. It just matters that the aggregation is maximal, which might not be the case when the mechanism should get fixed in the future.
To summarize: I feel that using the Cache-keys options for relationship aggregation can be a fair 'default' approach but that implementers should have to freedom to deviate from this approach when they deem it necessary.

Regards,
Floris

Op do 07 feb 2013 09:19:20 CET, Bert Greevenbosch schreef:

Hi Klaus,

OK, that makes sense. So for the server, the token is going to be part of identification of the observation relationship, but apart from that the server doesn't need to do any more bookkeeping. I like that a lot, especially since it allows usage of the same client port for multiple observation relationships, independently of any options.

Thanks for your explanation on the cache key, indeed it clears things up.

I agree that it is up to the proxy to determine whether it can use an already existent observation relationship, or needs to establish a new observation relationship. This choice indeed depends on the cache-key options.

Best regards,
Bert

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------050905030603030706060903-- From jeroen.hoebeke@intec.ugent.be Thu Feb 7 01:35:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C1921F85C4 for ; Thu, 7 Feb 2013 01:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1js9UJH+1Ef4 for ; Thu, 7 Feb 2013 01:35:01 -0800 (PST) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC721F85CC for ; Thu, 7 Feb 2013 01:35:00 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 2C965C234; Thu, 7 Feb 2013 10:35:00 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id VC1G0qwxv7C7; Thu, 7 Feb 2013 10:34:59 +0100 (CET) Received: from dhcp-zdpt-149.intec.ugent.be (dhcp-zdpt-149.intec.ugent.be [157.193.135.149]) (Authenticated sender: jjhoebek) by smtp3.ugent.be (Postfix) with ESMTPSA id 9C0E3C1E6; Thu, 7 Feb 2013 10:34:59 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Jeroen Hoebeke In-Reply-To: Date: Thu, 7 Feb 2013 10:35:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1 DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) X-Miltered: at jchkm1 with ID 51137543.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51137543.000 from dhcp-zdpt-149.intec.ugent.be/dhcp-zdpt-149.intec.ugent.be/157.193.135.149/dhcp-zdpt-149.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51137543.000 on smtp3.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 09:35:02 -0000 Hi Klaus, Bert, On 07 Feb 2013, at 08:52, Klaus Hartke wrote: >>=20 >> The above text is my current understanding of the cache-key. Is it = correct? >=20 > Almost, if I understand your comment correctly. The algorithm for an > incoming request looks approximately like this: >=20 > 1. Does the request contain an unrecognised, critical option that is > not safe-to-forward? If yes, return an error response; done. >=20 > 2. Does the request contain an unrecognised, elective option that is > not safe-to-forward? If yes, remove it from the request. >=20 > 3. Create the cache-key for the request. The cache-key includes > - the request method, > - the options that are recognised and specified in the draft/RFC to be > part of the cache-key, > - the options that are not recognised and have an option number which > indicates that the option is part of the cache-key. > Since the set of options recognised by a cache can vary between > different implementations, there can be different results for the > cache-key. >=20 > 4. Does the cache contain a response with the same cache-key? If yes > and the response is fresh, return it to the client; done. >=20 > 5. Make a request to the server. >=20 > Does that clear things up? When applied to observe:=20 - an incoming request with observe option=20 - the intermediary does not have the resulting cache key=20 - the intermediary establishes an observe relationship with the server = on behalf of the client and, internally, stores that it has established = this relationship on behalf of the client (+ link with cache-key) What would be the desired behaviour when the same client makes a new = request (using same port) with different options that result in a = different cache key? If there was no intermediary, this would result in = an update of the observe relationship. With an intermediary, you would = like to have the same behaviour. So, the intermediary should also check whether the observe request comes = from a known IP,port(,token). In that case, it should remove the old = relationship (related to the different cache key). Right? >> If so, I guess the server does not need to maintain bookkeeping of = the cache-key, as the cache-key is designed for the proxy. The server = simply returns whatever when it gets a request; it probably does not = maintain a cache itself. >>=20 >> But maybe I misunderstand your e-mail below. Do you mean the proxy = does the cache-key bookkeeping, and considers whether it needs to = establish a new observation relationship or not, and not the server? So = the server still maintains the (ip,port,resource) tuple and the proxy = starts a new one e.g. through using a different port? >=20 > I'm not fully sure what I mean yet :-) I think what I mean is that the > proxy does the cache-key bookkeeping, and considers whether it needs > to establish a new observation relationship or not, and not the > server. The server maintains a (ip,port,resource,token) tuple and the > proxy starts a new one through using a different token. Different port or also different token? If token is used, a client can have multiple relationships from the same = port using different tokens. Since the server has to store the token = anyway, this does not seem to introduce much additional complexity and = could make life of a client easier. In that case, there is also almost = no restriction to the number of relations an intermediary can maintain = on behalf of clients. Assuming tokens are used: In that case: would an unrelated GET from the = same port cancel them all? Or would you use a normal GET with the same = token to cancel a specific relationship? Kind regards, Jeroen From hartke@tzi.org Thu Feb 7 01:43:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E41921F8554 for ; Thu, 7 Feb 2013 01:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSLqbcOm-lIw for ; Thu, 7 Feb 2013 01:43:47 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1E83E21F854C for ; Thu, 7 Feb 2013 01:43:39 -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 r179hXCa026975 for ; Thu, 7 Feb 2013 10:43:33 +0100 (CET) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BFCECC38 for ; Thu, 7 Feb 2013 10:43:32 +0100 (CET) Received: by mail-la0-f50.google.com with SMTP id ec20so2404714lab.9 for ; Thu, 07 Feb 2013 01:43:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.27.34 with SMTP id q2mr496609lbg.56.1360230211951; Thu, 07 Feb 2013 01:43:31 -0800 (PST) Received: by 10.112.58.13 with HTTP; Thu, 7 Feb 2013 01:43:31 -0800 (PST) In-Reply-To: <51137177.9040700@intec.ugent.be> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D583990@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D583A5C@szxeml558-mbx.china.huawei.com> <51137177.9040700@intec.ugent.be> Date: Thu, 7 Feb 2013 11:43:31 +0200 Message-ID: From: Klaus Hartke To: Floris Van den Abeele Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 09:43:48 -0000 Floris Van den Abeele wrote: > Would this allow a proxy to exclude an unknown, elective, > safe-to-forward option that is marked as being part of the Cache-Key from > said determination ? For example, a proxy might know that the resource on > the server doesn't support the unknown, safe-to-forward, elective option If the proxy has such a knowledge about the option, then the options is not really unrecognised, isn't it? :-) > To summarize: I feel that using the Cache-keys options for relationship > aggregation can be a fair 'default' approach but that implementers should > have to freedom to deviate from this approach when they deem it necessary. A proxy must still meet the expectations of a client that observes a resource through it for interoperability. So a proxy implementation can not arbitrarily deviate from this. But if it has knowledge about how the server will process an option, it can of course act accordingly. Klaus From hartke@tzi.org Thu Feb 7 02:23:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839AE21F8472 for ; Thu, 7 Feb 2013 02:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQUllas1Zcje for ; Thu, 7 Feb 2013 02:23:48 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3CB21F846E for ; Thu, 7 Feb 2013 02:23:48 -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 r17ANfqx020606 for ; Thu, 7 Feb 2013 11:23:41 +0100 (CET) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 532F0CBE for ; Thu, 7 Feb 2013 11:23:41 +0100 (CET) Received: by mail-lb0-f175.google.com with SMTP id n3so1957828lbo.6 for ; Thu, 07 Feb 2013 02:23:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.29.229 with SMTP id n5mr548112lbh.2.1360232620702; Thu, 07 Feb 2013 02:23:40 -0800 (PST) Received: by 10.112.58.13 with HTTP; Thu, 7 Feb 2013 02:23:40 -0800 (PST) In-Reply-To: <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> Date: Thu, 7 Feb 2013 12:23:40 +0200 Message-ID: From: Klaus Hartke To: Jeroen Hoebeke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 10:23:49 -0000 Jeroen Hoebeke wrote: > What would be the desired behaviour when the same client makes a new requ= est (using same port) with different options that result in a different cac= he key? If there was no intermediary, this would result in an update of the= observe relationship. With an intermediary, you would like to have the sam= e behaviour. It's the client(-half of an intermediary) that performs the aggregation, not the server(-half of the intermediary). 1. Client A makes a GET request with Observe option and token X to proxy P. 2. Proxy P unconditionally creates the observation relationship between A and P, using the token X for notifications. 3. Proxy P calculates the cache-key for the request and looks for an existing observation relationship between P and server S. There is none, so it makes a GET request with Observe option and token V to server S. 4. Server S unconditionally creates the observation relationship between P and S, using the token V for notifications. 5. Client B makes a GET request with Observe option and token Y to proxy P. 6. Proxy P unconditionally creates the observation relationship between B and P, using the token Y for notifications. 7. Proxy P calculates the cache-key for the request and looks for an existing observation relationship between P and server S. Assuming the cache-key is equal to the cache-key in step 3, the proxy can reuse the existing observation relationship between P and S, and does not need to create a new one. 8. Client A makes a GET request with Observe option and token Z to proxy P. 9. Proxy P unconditionally creates the observation relationship between A and P, using the token Z for notifications. 10. Proxy P calculates the cache-key for the request and looks for an existing observation relationship between P and server S. Assuming the cache-key is different from the cache-key in step 3, it makes a GET request with Observe option and token W to server S. 11. Server S unconditionally creates the observation relationship between P and S, using the token W for notifications. > So, the intermediary should also check whether the observe request comes = from a known IP,port(,token). In that case, it should remove the old relati= onship (related to the different cache key). Right? You mean something like this? 1. Client A makes a GET request with Observe option and token X to proxy P. 2. Proxy P unconditionally creates the observation relationship between A and P, using the token X for notifications. 3. Proxy P calculates cache-key, etc. 4. Client A makes a GET request with Observe option and token X to proxy P. The client shouldn't use token X for a second request while it's still in u= se. > Assuming tokens are used: In that case: would an unrelated GET from the s= ame port cancel them all? Or would you use a normal GET with the same token= to cancel a specific relationship? Since one of the goals is that a request doesn't interfere with any other request at all (that's what REST calls "stateless communication"), a GET request wouldn't cancel anything. 1. Client A makes a GET request with Observe option and token X to proxy P. 2. Proxy P unconditionally creates the observation relationship between A and P, using the token X for notifications. 3. Proxy P calculates cache-key, etc. 4. Client A makes a GET request *without* Observe option and token Y to pro= xy P. 5. Proxy P calculates the cache-key for the request and looks for an existing response in its cache. If there is none, it makes a GET request without Observe option to server S. Best regards, Klaus PS: By the way, thanks to all who have contributed to this so far. It looks like we're really quickly converging on a working solution! :-D From jeroen.hoebeke@intec.ugent.be Thu Feb 7 03:31:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2164621F8633 for ; Thu, 7 Feb 2013 03:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySZmKcXjeJJ2 for ; Thu, 7 Feb 2013 03:31:25 -0800 (PST) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 3553B21F8630 for ; Thu, 7 Feb 2013 03:31:24 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 88E3412C120; Thu, 7 Feb 2013 12:31:23 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id f3gcHZInYNel; Thu, 7 Feb 2013 12:31:23 +0100 (CET) Received: from dhcp-zdpt-149.intec.ugent.be (dhcp-zdpt-149.intec.ugent.be [157.193.135.149]) (Authenticated sender: jjhoebek) by smtp2.ugent.be (Postfix) with ESMTPSA id 140AA12C0D9; Thu, 7 Feb 2013 12:31:23 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Jeroen Hoebeke In-Reply-To: Date: Thu, 7 Feb 2013 12:31:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) X-Miltered: at jchkm1 with ID 5113908A.006 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 5113908A.006 from dhcp-zdpt-149.intec.ugent.be/dhcp-zdpt-149.intec.ugent.be/157.193.135.149/dhcp-zdpt-149.intec.ugent.be/ X-j-chkmail-Score: MSGID : 5113908A.006 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 11:31:26 -0000 On 07 Feb 2013, at 11:23, Klaus Hartke wrote: > Jeroen Hoebeke wrote: >> What would be the desired behaviour when the same client makes a new = request (using same port) with different options that result in a = different cache key? If there was no intermediary, this would result in = an update of the observe relationship. With an intermediary, you would = like to have the same behaviour. >=20 > It's the client(-half of an intermediary) that performs the > aggregation, not the server(-half of the intermediary). >=20 > 1. Client A makes a GET request with Observe option and token X to = proxy P. >=20 > 2. Proxy P unconditionally creates the observation relationship > between A and P, using the token X for notifications. >=20 > 3. Proxy P calculates the cache-key for the request and looks for an > existing observation relationship between P and server S. There is > none, so it makes a GET request with Observe option and token V to > server S. >=20 > 4. Server S unconditionally creates the observation relationship > between P and S, using the token V for notifications. >=20 > 5. Client B makes a GET request with Observe option and token Y to = proxy P. >=20 > 6. Proxy P unconditionally creates the observation relationship > between B and P, using the token Y for notifications. >=20 > 7. Proxy P calculates the cache-key for the request and looks for an > existing observation relationship between P and server S. Assuming the > cache-key is equal to the cache-key in step 3, the proxy can reuse the > existing observation relationship between P and S, and does not need > to create a new one. >=20 > 8. Client A makes a GET request with Observe option and token Z to = proxy P. >=20 > 9. Proxy P unconditionally creates the observation relationship > between A and P, using the token Z for notifications. >=20 > 10. Proxy P calculates the cache-key for the request and looks for an > existing observation relationship between P and server S. Assuming the > cache-key is different from the cache-key in step 3, it makes a GET > request with Observe option and token W to server S. >=20 > 11. Server S unconditionally creates the observation relationship > between P and S, using the token W for notifications. I agree. >=20 >> So, the intermediary should also check whether the observe request = comes from a known IP,port(,token). In that case, it should remove the = old relationship (related to the different cache key). Right? >=20 > You mean something like this? >=20 > 1. Client A makes a GET request with Observe option and token X to = proxy P. >=20 > 2. Proxy P unconditionally creates the observation relationship > between A and P, using the token X for notifications. >=20 > 3. Proxy P calculates cache-key, etc. >=20 > 4. Client A makes a GET request with Observe option and token X to = proxy P. >=20 > The client shouldn't use token X for a second request while it's still = in use. OK, in that case it should be made explicit that updating (not = refreshing) an existing relationship means stopping the existing one and = establishing a new one (must use new token). The use of tokens to = identify relationships (in addition to the port) makes this easier. Else, the above scenario could result into the following: - If A does perform step 4, Proxy P detects the relationship exists and = wants to create an answer. Since the cache key differs, P could create a = second relationship for A (unless some check is being done), which is = definitely not the intention. So, the proxy should detect this behaviour or the client should be = forbidden to exhibit such behaviour. >=20 >> Assuming tokens are used: In that case: would an unrelated GET from = the same port cancel them all? Or would you use a normal GET with the = same token to cancel a specific relationship? >=20 > Since one of the goals is that a request doesn't interfere with any > other request at all (that's what REST calls "stateless > communication"), a GET request wouldn't cancel anything. >=20 > 1. Client A makes a GET request with Observe option and token X to = proxy P. >=20 > 2. Proxy P unconditionally creates the observation relationship > between A and P, using the token X for notifications. >=20 > 3. Proxy P calculates cache-key, etc. >=20 > 4. Client A makes a GET request *without* Observe option and token Y = to proxy P. >=20 > 5. Proxy P calculates the cache-key for the request and looks for an > existing response in its cache. If there is none, it makes a GET > request without Observe option to server S. OK, but how do you stop the relationship established in step 2 (section = 3.5 of observe draft) when using tokens to identify relationships? - RST on confirmable notification? - RST on non-confirmable notification (not guaranteed) - Get without observe using same port + token - ... Kind regards, jeroen From hartke@tzi.org Fri Feb 8 02:18:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A741321F8A2F for ; Fri, 8 Feb 2013 02:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVkE3ZQo+bBA for ; Fri, 8 Feb 2013 02:18:49 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D44AF21F877A for ; Fri, 8 Feb 2013 02:18:48 -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 r18AIaej007173 for ; Fri, 8 Feb 2013 11:18:36 +0100 (CET) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A6557375 for ; Fri, 8 Feb 2013 11:18:36 +0100 (CET) Received: by mail-la0-f46.google.com with SMTP id fq12so3604027lab.33 for ; Fri, 08 Feb 2013 02:18:36 -0800 (PST) X-Received: by 10.112.38.228 with SMTP id j4mr2091714lbk.1.1360318716130; Fri, 08 Feb 2013 02:18:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Fri, 8 Feb 2013 02:18:15 -0800 (PST) In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> From: Klaus Hartke Date: Fri, 8 Feb 2013 12:18:15 +0200 Message-ID: To: Jeroen Hoebeke Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 10:18:49 -0000 Jeroen Hoebeke wrote: >> The client shouldn't use token X for a second request while it's still in use. > > So, the proxy should detect this behaviour or the client should be forbidden to exhibit such behaviour. Section 5.3.1 of -coap already specifies that "the client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique." I'm not sure if much more is needed; if a client wants to reuse a token that is currently in use, it has to suffer the consequences of implementation defined behaviour. An interesting question is, of course: when stops a token being in use? For example, if a client is no longer interested in a resource and it just "forgets" the observation relationship (so the next notification will yield a Reset), the token is still in use by the server for a while. Klaus From hartke@tzi.org Fri Feb 8 02:44:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0182821F86F5 for ; Fri, 8 Feb 2013 02:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rphZj3jfwAQv for ; Fri, 8 Feb 2013 02:44:36 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DAD2B21F876E for ; Fri, 8 Feb 2013 02:44:29 -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 r18AiOZD023729 for ; Fri, 8 Feb 2013 11:44:24 +0100 (CET) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5A2F43C7 for ; Fri, 8 Feb 2013 11:44:24 +0100 (CET) Received: by mail-la0-f46.google.com with SMTP id fq12so3626537lab.33 for ; Fri, 08 Feb 2013 02:44:23 -0800 (PST) X-Received: by 10.112.98.226 with SMTP id el2mr2063528lbb.59.1360320263799; Fri, 08 Feb 2013 02:44:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Fri, 8 Feb 2013 02:44:03 -0800 (PST) In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> From: Klaus Hartke Date: Fri, 8 Feb 2013 12:44:03 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 10:44:37 -0000 I'm not entirely happy with the proposed solution yet. One strong reason why -observe was designed such that a GET request refreshes an existing observation relationship, was that this makes the creation if the observation relationship idempotent and observation relationships self-healing: If there is a disagreement between the client and server on whether an observation relationship exists or not, the next GET request clears that up. With the proposed solution, if the client believes that a observation relationship doesn't exist although it does, it will create a new observation relationship and the existing one will keep going. Klaus From kovatsch@inf.ethz.ch Mon Feb 11 03:42:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B76021F852B for ; Mon, 11 Feb 2013 03:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSDM9MwBMbMh for ; Mon, 11 Feb 2013 03:42:37 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 27DE821F8523 for ; Mon, 11 Feb 2013 03:42:35 -0800 (PST) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 11 Feb 2013 12:42:21 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Mon, 11 Feb 2013 12:42:22 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , "core@ietf.org WG" Thread-Topic: [core] #281: Safe-to-forward options Thread-Index: AQHOBGTF/vOV5HydnU+2YK4RJR/K/5hstB+AgAAFK4CAABRNAIAAAJ0AgAABxwCAAAKVAIAAAS2AgAABdICAAArxAIAArVOAgABNa4CAAAU6gIAAApmAgAADUgCAAAH1AIAABF4AgAAKI4CAABzFgIAADZcAgAAS7QCAAX3lgIAABzWAgAHJGAA= Date: Mon, 11 Feb 2013 11:42:21 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DC15B3@MBX10.d.ethz.ch> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 11:42:38 -0000 Dear list I have a bad feeling about the complexity all this introduces. My main prob= lem is that we are preparing for options that make a single resource behave= in different ways depending on some yet unknown, maybe vendor-defined opti= on (brace yourselves for RPC-like CoAP...). If people want to have different behaviors, they should model this with dif= ferent resources (or queries). That would definitely simplify the identific= ation and merging of observe relationships. I like the current proposal with the idempotence and self-healing propertie= s Klaus mentioned. Another good simplification would be a non-repeatable Ac= cept option. Then intermediaries do not have to care about various combinat= ions that might end up with the same format in the notifications. If someon= e worries about efficiency because a client might need to probe the right C= ontent-Format with several requests, just use the Link Format information. Ciao Matthias From darconeous@gmail.com Mon Feb 11 09:51:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68F21F8938 for ; Mon, 11 Feb 2013 09:51:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHQtthxDBWrk for ; Mon, 11 Feb 2013 09:51:51 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id A353A21F8916 for ; Mon, 11 Feb 2013 09:51:51 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id v40so2820412dad.21 for ; Mon, 11 Feb 2013 09:51:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=CjZgkxq5ZJHQ7PW5DnC0oTBlfb22FT42z++Kf1xz1UI=; b=nr+GH5HgdksEs5l0d8PGqQb5KenUQ09qGnow6NGk+okbnAK7MAqTXbZ3rTE9zukCGe fEwtgafd3k/1w80rIfC/poeh61Y4jv5JvNod3WeT1zN1ZwM0OQsehfAPYRO4CGkLS70m DnzsYatV1RWrdYqccYqCCfyYkfVy4kJBjgqtMiE64IjEotmbvIMQvyV15KhZPjnIYgWA qk9KA8Y/1juoGhIe+guQSNLmeCnWg3JDntabivlZUPZYbkquMq9oQNQ86KtcQ+1C2Y6i hFPw2ALAHkRb2oU1SPPgfXFuRRaFMqjaegdU4eqKHfHKVASBP/jKfuMGflSw/CYfhZ/9 XNRw== X-Received: by 10.66.79.202 with SMTP id l10mr42807772pax.36.1360605108946; Mon, 11 Feb 2013 09:51:48 -0800 (PST) Received: from [172.30.96.30] (c-67-174-221-32.hsd1.ca.comcast.net. [67.174.221.32]) by mx.google.com with ESMTPS id d8sm68186716pax.23.2013.02.11.09.51.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 09:51:48 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Robert Quattlebaum In-Reply-To: Date: Mon, 11 Feb 2013 09:51:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1 DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 17:51:52 -0000 Couldn't a client achieve the self-healing properties you describe by = simply always using the same token?=20 On Feb 8, 2013, at 2:44 AM, Klaus Hartke wrote: > I'm not entirely happy with the proposed solution yet. One strong > reason why -observe was designed such that a GET request refreshes an > existing observation relationship, was that this makes the creation if > the observation relationship idempotent and observation relationships > self-healing: If there is a disagreement between the client and server > on whether an observation relationship exists or not, the next GET > request clears that up. With the proposed solution, if the client > believes that a observation relationship doesn't exist although it > does, it will create a new observation relationship and the existing > one will keep going. >=20 > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From wasilak@gmail.com Tue Feb 12 00:20:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63CC21F8CAC for ; Tue, 12 Feb 2013 00:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_12=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORNYqwz5RNHN for ; Tue, 12 Feb 2013 00:20:20 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 862B021F8C87 for ; Tue, 12 Feb 2013 00:20:19 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hi8so4073123wib.13 for ; Tue, 12 Feb 2013 00:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Jtg32soUozzMsYa86EY3YtYd3fItUBp40RYmONrPgdE=; b=MG+RWkkrgS494/kTr9bJRS/tP5mx49Lvw8WyhgevT+46cfu6saT7JZVd51AhzTYm+r m04aj7Rxn+u9svq5g8L5DcR3+92uIeYlUS5ajeiKsDYfsBgJjQHw04ijFZ5G8T/6v4bZ I7wg6gGHTiohcjKgwb8ZDsuSkvKdEcAfbngU5tFvUboyoXwsM1Udfx1DNuc7dQNVnzZI TOnFiaw+qBrLft0MqcDe+RpJJdTLBRLGqdQTXQLu53vGdXsNTCBfQ5h1vZFudOIMRzPL W2tW0CjxbbGS0GaSAccBXrrFTBvlVNr6MAt3bt9N1X8c6BoOVTbc6lxkkCwP3liiCI2H h4dA== MIME-Version: 1.0 X-Received: by 10.180.77.9 with SMTP id o9mr1029014wiw.16.1360657218620; Tue, 12 Feb 2013 00:20:18 -0800 (PST) Received: by 10.216.240.9 with HTTP; Tue, 12 Feb 2013 00:20:18 -0800 (PST) In-Reply-To: <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> Date: Tue, 12 Feb 2013 09:20:18 +0100 Message-ID: From: Maciej Wasilak To: "core@ietf.org WG" Content-Type: multipart/alternative; boundary=f46d043d66c32d4c6e04d582b2f6 Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 08:20:21 -0000 --f46d043d66c32d4c6e04d582b2f6 Content-Type: text/plain; charset=UTF-8 Hello All, I think we should check real-life proxy usecases and take them into consideration when talking about the preferred behavior. There might be different conditions for forward proxy and reverse proxy. Example for reverse proxy: Server: 1. battery-powered room temperature sensor Proxy: 1. mains-powered linux box Observing clients: 1. heating controller (needs update only when T<20, content-type: SenML or something similar) 2. air conditioning (needs update only when T>28, content-type: text ) 3. control panel (needs all updates, content-type: JSON based proprietary format) In that case the intention for using proxy is preserving server's battery power and increasing flexibility (server may not support all content-types). I think the intended behavior is that proxy should receive all updates from server, and it should pass only required updates to clients (with correct content-type). Therefore it's not necessary to use any options from the original requests in the proxy request. Can someone come up with a decent case for forward-proxy observe relationship? Best Regards Maciek 2013/2/11 Robert Quattlebaum > Couldn't a client achieve the self-healing properties you describe by > simply always using the same token? > > On Feb 8, 2013, at 2:44 AM, Klaus Hartke wrote: > > > I'm not entirely happy with the proposed solution yet. One strong > > reason why -observe was designed such that a GET request refreshes an > > existing observation relationship, was that this makes the creation if > > the observation relationship idempotent and observation relationships > > self-healing: If there is a disagreement between the client and server > > on whether an observation relationship exists or not, the next GET > > request clears that up. With the proposed solution, if the client > > believes that a observation relationship doesn't exist although it > > does, it will create a new observation relationship and the existing > > one will keep going. > > > > Klaus > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --f46d043d66c32d4c6e04d582b2f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello All,

I think we should check real-life proxy usecases and take= them into consideration when talking about the preferred behavior. There m= ight be different conditions for forward proxy and reverse proxy. Example f= or reverse proxy:

Server:
1. battery-powered room temperature sensor

Proxy:
= 1. mains-powered linux box

Observing clients:
1. heating controll= er (needs update only when T<20, content-type: SenML or something simila= r)
2. air conditioning (needs update only when T>28, content-type: text )3. control panel (needs all updates, content-type: JSON based proprietary= format)

In that case the intention for using proxy is preserving se= rver's battery power and increasing flexibility (server may not support= all content-types). I think the intended behavior is that proxy should rec= eive all updates from server, and it should pass only required updates to c= lients (with correct content-type). Therefore it's not necessary to use= any options from the original requests in the proxy request.

Can someone come up with a decent case for forward-proxy observe relati= onship?
Best Regards
Maciek

2013/2/= 11 Robert Quattlebaum <darconeous@gmail.com>
Couldn't a client achieve the self-heali= ng properties you describe by simply always using the same token?

On Feb 8, 2013, at 2:44 AM, Klaus Hartke <hartke@tzi.org> wrote:

> I'm not entirely happy with the proposed solution yet. One strong<= br> > reason why -observe was designed such that a GET request refreshes an<= br> > existing observation relationship, was that this makes the creation if=
> the observation relationship idempotent and observation relationships<= br> > self-healing: If there is a disagreement between the client and server=
> on whether an observation relationship exists or not, the next GET
> request clears that up. With the proposed solution, if the client
> believes that a observation relationship doesn't exist although it=
> does, it will create a new observation relationship and the existing > one will keep going.
>
> Klaus
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

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

--f46d043d66c32d4c6e04d582b2f6-- From stokcons@xs4all.nl Tue Feb 12 02:12:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224C221F8727 for ; Tue, 12 Feb 2013 02:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHv3gKaG1KkE for ; Tue, 12 Feb 2013 02:12:45 -0800 (PST) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by ietfa.amsl.com (Postfix) with ESMTP id EE08021F8635 for ; Tue, 12 Feb 2013 02:12:44 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube10.xs4all.net [194.109.20.208]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id r1CACd3x089242; Tue, 12 Feb 2013 11:12:40 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-221-34.w109-210.abo.wanadoo.fr ([109.210.220.34]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 12 Feb 2013 11:12:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Feb 2013 11:12:39 +0100 From: peter van der Stok To: akbar rahman , esko dijk , Core Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <4c523fcc97cb76088432f6ef8b8a979a@xs4all.nl> X-Sender: stokcons@xs4all.nl (KMQgAAhuM4gD4sdIDjyMglOclhAVUj66) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] core-groupcomm-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 10:12:46 -0000 Hi Akbar and Esko, many thanks for the 5th version of the group comm draft. I do have a few remarks, where the text is not clear to me. section 3.3 second alinea group communication will not work if there is diversity.... I assume that you mean "multicast based" group communication. The alternative based on unicast wil work perfectly with diversity section 3.5 point 2. It took me 3 readings before I mastered its meaning. section 3.6 Here I do not understand. I thought that multicast message are recommended to be non-confirmable. Why do you need to suppress 4.xx, 2.05 , etc responses? When a response is wanted the multicast receiver sends a message with some delay, or possibly a RST when not multicast aware. Consequently, for me the relation of the text of 3.6 with coap-13 is unclear. Secondly, the concept of "IP stack interface" is rather vague. I would expect more concrete text. section 3.9 Does the text say that MPL cannot be used when RPL is set to "non-storing mode"? section 4 I should like to suggest a different approach with two network technologies (A) and (B). (A) mesh based Keep the two mesh subnets and assume the RTR-1 and RTR-2 are on the same ethernet link. (1) Assume Rtr-1 and RTr-2 are MPL enabled. In that case there is a single multicast domain and then all group members are reached with one multicast invocation. (2) Assume that Rtr-1 and RTr-2 are not part of one MPL domain. In that case I would suggest to use two MCast invocations, one for subnet-1 and one for subnet-2. Within a subnet MPL is used, non-encapsulated when source is in same subnet, and encapsulated when source is in different subnet. (B) ethernet based Assuming that the subnets are 802.11 or ethernet based, it may be useful to look at how UPnP uses IP Mcast for eventing. It has the advantage of being used in the field. I hope this helps, Peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From hartke@tzi.org Thu Feb 14 00:55:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661DD21F86AE for ; Thu, 14 Feb 2013 00:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6mSAtSQAJLj for ; Thu, 14 Feb 2013 00:55:10 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD521F84FD for ; Thu, 14 Feb 2013 00:55:06 -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 r1E8sPwt012691 for ; Thu, 14 Feb 2013 09:55:06 +0100 (CET) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 45E1D231A for ; Thu, 14 Feb 2013 09:32:53 +0100 (CET) Received: by mail-la0-f44.google.com with SMTP id eb20so2046763lab.3 for ; Thu, 14 Feb 2013 00:32:52 -0800 (PST) X-Received: by 10.112.98.226 with SMTP id el2mr246310lbb.59.1360830772569; Thu, 14 Feb 2013 00:32:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Thu, 14 Feb 2013 00:32:32 -0800 (PST) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514DC15B3@MBX10.d.ethz.ch> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63D5839C5@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> <55877B3AFB359744BA0F2140E36F52B514DC15B3@MBX10.d.ethz.ch> From: Klaus Hartke Date: Thu, 14 Feb 2013 10:32:32 +0200 Message-ID: To: Kovatsch Matthias Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:55:11 -0000 Matthias Kovatsch wrote: > I have a bad feeling about the complexity all this introduces. CoAP is a complex protocol. This particular complexity was introduced by safe-to-forward options. Unless we remove these from -coap again, I don't think there's solution for -observe that is not slightly more complex than it was before safe-to-forward options. > My main problem is that we are preparing for options that make a single resource behave in different ways depending on some yet unknown, maybe vendor-defined option But that's actually what most options do: they modify the request such that the server makes the target resource behave slightly different depending on the options. Accept, ETag, If-Match, If-None-Match, Observe and Block* are instances of this. I don't think it would be useful to preclude the addition of such options in the future. > I like the current proposal with the idempotence and self-healing properties Klaus mentioned. Yes, I'd like to keep these properties as well. But I'd also like GET requests to not affect each other. I've done a bit of experimentation in the last few days and think that merging the observations at the client-side is a step in the right direction. It aligns naturally with merging normal GET requests made through a cache. Klaus From hartke@tzi.org Thu Feb 14 00:55:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35CB21F86C3 for ; Thu, 14 Feb 2013 00:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuE2dM4KzjGN for ; Thu, 14 Feb 2013 00:55:17 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCCB21F84FD for ; Thu, 14 Feb 2013 00:55:17 -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 r1E8sQ7i012696 for ; Thu, 14 Feb 2013 09:55:10 +0100 (CET) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A53752244 for ; Thu, 14 Feb 2013 09:29:11 +0100 (CET) Received: by mail-la0-f50.google.com with SMTP id ec20so2064272lab.9 for ; Thu, 14 Feb 2013 00:29:11 -0800 (PST) X-Received: by 10.112.27.34 with SMTP id q2mr248470lbg.56.1360830551098; Thu, 14 Feb 2013 00:29:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Thu, 14 Feb 2013 00:28:50 -0800 (PST) In-Reply-To: <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> From: Klaus Hartke Date: Thu, 14 Feb 2013 10:28:50 +0200 Message-ID: To: Robert Quattlebaum Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:55:18 -0000 Robert Quattlebaum wrote: > Couldn't a client achieve the self-healing properties you describe by simply always using the same token? No. The token functions as a generation identifier for the sequence numbers, so you always need to use a new token if you want to refresh an existing observation. Klaus From esko.dijk@philips.com Thu Feb 14 01:30:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6A321F853A for ; Thu, 14 Feb 2013 01:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5WSTXziXOAF for ; Thu, 14 Feb 2013 01:30:09 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA5B21F8526 for ; Thu, 14 Feb 2013 01:30:06 -0800 (PST) Received: from mail38-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Feb 2013 09:30:06 +0000 Received: from mail38-ch1 (localhost [127.0.0.1]) by mail38-ch1-R.bigfish.com (Postfix) with ESMTP id 0C846260125; Thu, 14 Feb 2013 09:30:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz217bI98dI15d6O9251J542Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail38-ch1 (localhost.localdomain [127.0.0.1]) by mail38-ch1 (MessageSwitch) id 1360834203764286_17187; Thu, 14 Feb 2013 09:30:03 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail38-ch1.bigfish.com (Postfix) with ESMTP id B82F2440043; Thu, 14 Feb 2013 09:30:03 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Feb 2013 09:30:02 +0000 Received: from 011-DB3MMR1-014.MGDPHG.emi.philips.com (10.128.28.98) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 14 Feb 2013 09:29:45 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.76]) by 011-DB3MMR1-014.MGDPHG.emi.philips.com ([10.128.28.98]) with mapi id 14.02.0318.003; Thu, 14 Feb 2013 09:29:45 +0000 From: "Dijk, Esko" To: Klaus Hartke , Robert Quattlebaum Thread-Topic: [core] #281: Safe-to-forward options Thread-Index: AQHOBGX+t6JYp8uFzkikYG5aKaMxZJhsxOCAgAAFK4CAABRNAIAAAJ0AgAAByACAAAKUAIAAAS6AgAABc4CAAArxAIAArVOAgABNa4CAAAU6gIAAApmAgAADUgCAAAH1AIAABF4AgAAKI4CAABzFgIAADZgAgAAS7ACAAX3lgIAABzWAgAUufoCABBm4AIAADcRQ Date: Thu, 14 Feb 2013 09:29:44 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B95919@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 09:30:10 -0000 > No. The token functions as a generation identifier for the sequence numbe= rs, so you always need > to use a new token if you want to refresh an existing observation. To me it's not yet clear why the sequence numbers need to be "reset" by the= server upon refresh (i.e. new generation). Couldn't it just keep counting = on? In any case, there's no requirement for the server to start at a specif= ic number, or not? If so it could just keep counting. I was thinking of the use case where the client reboots, loses state, so fo= rgets about its ongoing observation relation and starts a new one. (At leas= t it thinks its new and not a refresh.) Then it would typically use the sam= e token again if the client is programmed to keep only one observation rela= tion (e.g. default Token). Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: Thursday 14 February 2013 9:29 To: Robert Quattlebaum Cc: core@ietf.org WG Subject: Re: [core] #281: Safe-to-forward options Robert Quattlebaum wrote: > Couldn't a client achieve the self-healing properties you describe by sim= ply always using the same token? No. The token functions as a generation identifier for the sequence numbers= , so you always need to use a new token if you want to refresh an existing = observation. Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From hartke@tzi.org Thu Feb 14 01:42:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FF321F86F0 for ; Thu, 14 Feb 2013 01:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDrh6mqE5+JE for ; Thu, 14 Feb 2013 01:42:53 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 93E3A21F86DD for ; Thu, 14 Feb 2013 01:42:52 -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 r1E9gl1Z002292 for ; Thu, 14 Feb 2013 10:42:50 +0100 (CET) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B49A62610 for ; Thu, 14 Feb 2013 10:41:16 +0100 (CET) Received: by mail-la0-f43.google.com with SMTP id ek20so2073427lab.2 for ; Thu, 14 Feb 2013 01:41:16 -0800 (PST) X-Received: by 10.112.38.98 with SMTP id f2mr325658lbk.61.1360834876134; Thu, 14 Feb 2013 01:41:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Thu, 14 Feb 2013 01:40:56 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B95919@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> <031DD135F9160444ABBE3B0C36CED618B95919@011-DB3MPN2-083.MGDPHG.emi.philips.com> From: Klaus Hartke Date: Thu, 14 Feb 2013 11:40:56 +0200 Message-ID: To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 09:42:53 -0000 Esko Dijk wrote: >> No. The token functions as a generation identifier for the sequence numb= ers, so you always need >> to use a new token if you want to refresh an existing observation. > > To me it's not yet clear why the sequence numbers need to be "reset" by t= he server upon refresh (i.e. new generation). Couldn't it just keep countin= g on? In any case, there's no requirement for the server to start at a spec= ific number, or not? If so it could just keep counting. Yes, the server could keep counting on; then it wouldn't be a problem. But currently the server is *not required* to keep counting on. The client must use a token to give the server the freedom of choosing between whether it counts on or not. Counting on may be difficult if the server reboots and loses state. Klaus From hartke@tzi.org Thu Feb 14 02:10:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2399821F866D for ; Thu, 14 Feb 2013 02:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.127 X-Spam-Level: X-Spam-Status: No, score=-5.127 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, J_BACKHAIR_12=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp6d5SLIQ5LB for ; Thu, 14 Feb 2013 02:10:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41821F8659 for ; Thu, 14 Feb 2013 02:10: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 r1EAAqE2028025 for ; Thu, 14 Feb 2013 11:10:52 +0100 (CET) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9EADB2676 for ; Thu, 14 Feb 2013 11:10:52 +0100 (CET) Received: by mail-lb0-f177.google.com with SMTP id go11so1636098lbb.8 for ; Thu, 14 Feb 2013 02:10:52 -0800 (PST) X-Received: by 10.112.39.138 with SMTP id p10mr374217lbk.31.1360836652134; Thu, 14 Feb 2013 02:10:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Thu, 14 Feb 2013 02:10:31 -0800 (PST) In-Reply-To: References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> From: Klaus Hartke Date: Thu, 14 Feb 2013 12:10:31 +0200 Message-ID: To: Maciej Wasilak Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:10:59 -0000 Maciej Wasilak wrote: > Example for reverse proxy: [...] Your scenario can be implemented in three ways: 1. The server exposes three resources: - one that changes only when T<20, content-type: SenML - one that changes only when T>28, content-type: text - one that changes whenever T changes, content-type: JSON based proprietary format The proxy creates one observation relationships for each of the three clients. 2. The server exposes three resources: - one that changes only when T<20, content-type: SenML - one that changes only when T>28, content-type: SenML - one that changes whenever T changes, content-type: SenML The proxy creates one observation relationships for each of the three clients, but translates between content types as needed. 3. The server exposes one resource: - one that changes whenever T changes, content-type: SenML The proxy exposes three resources itself which. These provide customized "views" of the original resource; the proxy filters and projects the temperature values as needed. These three ways provide different levels of coupling between the proxy and the server. In the first case, the proxy is completely application-agnostic, while in the third case it actually provides part of the application functionality itself. If the proxy is so strongly coupled to the server that it knows whether the server recognises an option or not (so it can fill in the support for it if not), then the proxy indeed does not have to forward unrecognised options. It should still be possible to observe a resource through a proxy that doesn't have such a knowledge though. Klaus From mehmet.ersue@nsn.com Thu Feb 14 09:11:35 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E920521F841F; Thu, 14 Feb 2013 09:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKbsScXNWf1G; Thu, 14 Feb 2013 09:11:31 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6C13A21F8419; Thu, 14 Feb 2013 09:11:31 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r1EHBJ3v030681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Feb 2013 18:11:22 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r1EHBJKJ008880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Feb 2013 18:11:19 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 14 Feb 2013 18:11:19 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.02.0328.009; Thu, 14 Feb 2013 18:11:19 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "coman@ietf.org" , "core@ietf.org" , "lwig-chairs@tools.ietf.org" , "opsawg@ietf.org" Thread-Topic: Review of draft-ersue-constrained-mgmt-03 on "Management of Networks with Constrained Devices: Problem Statement, Use Cases and Requirements" Thread-Index: Ac4K1k19fsSHyM+zSJKg/BwqfIncew== Date: Thu, 14 Feb 2013 17:11:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1392 X-purgate-ID: 151667::1360861882-0000215D-9B6B866E/0-0/0-0 Subject: [core] Review of draft-ersue-constrained-mgmt-03 on "Management of Networks with Constrained Devices: Problem Statement, Use Cases and Requirements" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 17:11:36 -0000 Hi All, based on the agreement in the OPS-DIR meeting in IETF 83 and the support of= the O&M AD Benoit Claise we set up the Coman (COnstrained MANanagement) ac= tivity and the corresponding maillist on May 16, 2012. Since then quite a number of people worked on the document on "Management o= f Networks with Constrained Devices: Problem Statement, Use Cases and Requi= rements" with their text contributions and comments. Many thanks to all who= helped getting it to the current stage. http://tools.ietf.org/html/draft-ersue-constrained-mgmt-03 With this email we would like to start a review of the draft above. Please provide your comments to any of the maillists on the Too-list (pleas= e CC Coman maillist). We hope on a useful discussion concerning the problem statement, use cases = and requirements. As the next step, we decided during IETF 85 to provide a new draft with a g= ap analysis on missing standards at the IETF for the purpose of Constrained= Device&Network Management with the goal to highlight new work at IETF. Thi= s draft will be written just after getting the above document more stable b= ased on your comments. Thank you in advance. Cheers, Mehmet Coman maillist info: List address: coman@ietf.org Archive: http://www.ietf.org/mail-archive/web/coman/ To subscribe: https://www.ietf.org/mailman/listinfo/coman From trac+core@trac.tools.ietf.org Fri Feb 15 08:23:54 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB8421F89DC for ; Fri, 15 Feb 2013 08:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z9pgSF4e19F for ; Fri, 15 Feb 2013 08:23:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 465FF21F896B for ; Fri, 15 Feb 2013 08:23:52 -0800 (PST) Received: from localhost ([127.0.0.1]:57288 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U6O4k-0001uH-22; Fri, 15 Feb 2013 17:23:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Fri, 15 Feb 2013 16:23:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/242#comment:1 Message-ID: <068.33f32087ecbfddb590e674ca8a0232b3@trac.tools.ietf.org> References: <053.2fba3369918f47f69e8b96d49e45848b@trac.tools.ietf.org> X-Trac-Ticket-ID: 242 In-Reply-To: <053.2fba3369918f47f69e8b96d49e45848b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130215162352.465FF21F896B@ietfa.amsl.com> Resent-Date: Fri, 15 Feb 2013 08:23:52 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #242: Wait for acknowledgement before sending new notification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:23:54 -0000 #242: Wait for acknowledgement before sending new notification Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1224]: Closes #242 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: closed defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-05 Component: observe | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Feb 15 09:02:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838E521F87DC for ; Fri, 15 Feb 2013 09:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxPlbyBuYY-d for ; Fri, 15 Feb 2013 09:02:14 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BC1CB21F87CA for ; Fri, 15 Feb 2013 09:02:14 -0800 (PST) Received: from localhost ([127.0.0.1]:32958 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U6Ofu-0004nh-0G; Fri, 15 Feb 2013 18:02:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: hartke@tzi.org X-Trac-Project: core Date: Fri, 15 Feb 2013 17:02:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/234#comment:1 Message-ID: <066.706d158dcb50a1a6bf6fbaab52fdd52f@trac.tools.ietf.org> References: <051.7f6b17ebe0c298d7c5f4c03ceeb1a742@trac.tools.ietf.org> X-Trac-Ticket-ID: 234 In-Reply-To: <051.7f6b17ebe0c298d7c5f4c03ceeb1a742@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #234: Editorial updates to -observe examples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 17:02:15 -0000 #234: Editorial updates to -observe examples Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed -- -----------------------------+----------------------------- Reporter: cabo@tzi.org | Owner: hartke@tzi.org Type: editorial | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+----------------------------- Ticket URL: core From hartke@tzi.org Sat Feb 16 00:43:32 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FEB21F854C for ; Sat, 16 Feb 2013 00:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.605 X-Spam-Level: X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb+ycanKsbd4 for ; Sat, 16 Feb 2013 00:43:31 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 753F821F854A for ; Sat, 16 Feb 2013 00:43:31 -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 r1G8hK7g013325 for ; Sat, 16 Feb 2013 09:43:20 +0100 (CET) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E9B7F318F for ; Sat, 16 Feb 2013 09:43:19 +0100 (CET) Received: by mail-la0-f41.google.com with SMTP id fo12so4127077lab.28 for ; Sat, 16 Feb 2013 00:43:19 -0800 (PST) X-Received: by 10.112.17.194 with SMTP id q2mr3122809lbd.7.1361004199328; Sat, 16 Feb 2013 00:43:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Sat, 16 Feb 2013 00:42:56 -0800 (PST) In-Reply-To: References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> From: Klaus Hartke Date: Sat, 16 Feb 2013 10:42:56 +0200 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 08:43:32 -0000 Is there anything that can be done with Proactive Negotiation [1] that cannot be done with Reactive Negotiation [2]? That is, do we need Accept at all? See also http://trac.tools.ietf.org/wg/httpbis/trac/ticket/81 Klaus [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-3.4.1 [2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-3.4.2 From hartke@tzi.org Sat Feb 16 00:50:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B0C21F86AD for ; Sat, 16 Feb 2013 00:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.606 X-Spam-Level: X-Spam-Status: No, score=-5.606 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWLrMhibgmOy for ; Sat, 16 Feb 2013 00:50:25 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2E621F86A6 for ; Sat, 16 Feb 2013 00:50:18 -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 r1G8BVYq003125 for ; Sat, 16 Feb 2013 09:11:31 +0100 (CET) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2964B3187 for ; Sat, 16 Feb 2013 09:11:31 +0100 (CET) Received: by mail-la0-f51.google.com with SMTP id fo13so4128196lab.10 for ; Sat, 16 Feb 2013 00:11:30 -0800 (PST) X-Received: by 10.152.146.199 with SMTP id te7mr4533603lab.23.1361002290551; Sat, 16 Feb 2013 00:11:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Sat, 16 Feb 2013 00:11:10 -0800 (PST) In-Reply-To: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> From: Klaus Hartke Date: Sat, 16 Feb 2013 10:11:10 +0200 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 08:50:26 -0000 Carsten Bormann wrote: > I think it is pretty clear that an intermediary must treat Accept as a cache-key. What about PUT? PUT replaces all representations of the resource with the new representation. It doesn't just replace the first representation that matches the Accept option. (The Accept option in a PUT request actually negotiates the content-format of the action result representation, not the representation that the request should be applied to.) So a cache needs to be "smart" about Accept and cannot simply treat Accept as a cache-key. Klaus From kovatsch@inf.ethz.ch Sat Feb 16 07:16:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5591621F8930 for ; Sat, 16 Feb 2013 07:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmXETRUXtlzK for ; Sat, 16 Feb 2013 07:16:49 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8EABA21F887D for ; Sat, 16 Feb 2013 07:16:48 -0800 (PST) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sat, 16 Feb 2013 16:16:37 +0100 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.02.0298.004; Sat, 16 Feb 2013 16:16:43 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , Carsten Bormann Thread-Topic: [core] Accept option and intermediaries Thread-Index: AQHOA/HOvR1fkeTn9U+lByHJvtWP2JhsyP+AgAADwYCAAAyqgIAPUSoAgAB3NeA= Date: Sat, 16 Feb 2013 15:16:41 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 15:16:50 -0000 > Klaus Hartke: > Is there anything that can be done with Proactive Negotiation [1] that ca= nnot be > done with Reactive Negotiation [2]? >=20 > That is, do we need Accept at all? Two problems I see is that having one URI per Content-Type blows up the lin= k format a lot and weakens the resource abstraction. The latter results in = a problem for PUT for instance: If we update one Content-Type resource via = PUT, what does this mean for the other related resources? With a single res= ource and different supported representations this is clear. Ciao Matthias From kovatsch@inf.ethz.ch Sat Feb 16 07:27:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25BD21F888C for ; Sat, 16 Feb 2013 07:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcPe6bu+lpS8 for ; Sat, 16 Feb 2013 07:27:11 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1010421F8836 for ; Sat, 16 Feb 2013 07:27:11 -0800 (PST) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sat, 16 Feb 2013 16:26:57 +0100 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.02.0298.004; Sat, 16 Feb 2013 16:26:58 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , Carsten Bormann Thread-Topic: [core] Accept option and intermediaries Thread-Index: AQHOA/HOvR1fkeTn9U+lByHJvtWP2JhsyP+AgA9YtQCAAIjXkA== Date: Sat, 16 Feb 2013 15:26:57 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DD2CFB@MBX20.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 15:27:11 -0000 > Carsten Bormann wrote: > > I think it is pretty clear that an intermediary must treat Accept as a = cache-key. >=20 > What about PUT? Is PUT cachable or what do you mean? > PUT replaces all representations of the resource with the new representat= ion. It > doesn't just replace the first representation that matches the Accept opt= ion. > (The Accept option in a PUT request actually negotiates the content-forma= t of > the action result representation, not the representation that the request= should > be applied to.) So a cache needs to be "smart" about Accept and cannot si= mply > treat Accept as a cache-key. PUT must invalidate all cache entries anyway. Here we have a major problem = if we use separate resources for different Content-Types (cf. Reactive Nego= tiation) ... Ciao Matthias From kovatsch@inf.ethz.ch Sat Feb 16 07:40:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B6821F8763 for ; Sat, 16 Feb 2013 07:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.266 X-Spam-Level: X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1yN1hNydPNO for ; Sat, 16 Feb 2013 07:40:10 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3AA21F86AF for ; Sat, 16 Feb 2013 07:40:09 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sat, 16 Feb 2013 16:40:07 +0100 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Sat, 16 Feb 2013 16:40:08 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , Carsten Bormann Thread-Topic: [core] Accept option and intermediaries Thread-Index: AQHOA/HOvR1fkeTn9U+lByHJvtWP2JhsyP+AgA9YtQCAAIjXkIAABP+Q Date: Sat, 16 Feb 2013 15:40:06 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DD2D44@MBX20.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD2CFB@MBX20.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514DD2CFB@MBX20.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 15:40:11 -0000 > PUT must invalidate all cache entries anyway. Here we have a major proble= m if > we use separate resources for different Content-Types (cf. Reactive > Negotiation) ... Okay, I just found this: http://tools.ietf.org/html/draft-nottingham-linked= -cache-inv-04 Do we want to go that far? > Ciao > Matthias From hartke@tzi.org Sat Feb 16 08:11:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1F121F84C0 for ; Sat, 16 Feb 2013 08:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTRg0BsoOg6J for ; Sat, 16 Feb 2013 08:11:47 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8B61F21F8775 for ; Sat, 16 Feb 2013 08:11:47 -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 r1GGBe0N025355 for ; Sat, 16 Feb 2013 17:11:40 +0100 (CET) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 85A2F3226 for ; Sat, 16 Feb 2013 17:11:40 +0100 (CET) Received: by mail-la0-f42.google.com with SMTP id fe20so4362965lab.1 for ; Sat, 16 Feb 2013 08:11:39 -0800 (PST) X-Received: by 10.112.101.168 with SMTP id fh8mr16288lbb.59.1361031099918; Sat, 16 Feb 2013 08:11:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Sat, 16 Feb 2013 08:11:19 -0800 (PST) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> From: Klaus Hartke Date: Sat, 16 Feb 2013 18:11:19 +0200 Message-ID: To: Kovatsch Matthias Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 16:11:48 -0000 Matthias Kovatsch wrote: >> That is, do we need Accept at all? > > Two problems I see is that having one URI per Content-Type blows up the link format a lot and weakens the resource abstraction. Sure, there are some disadvantages; see -httpbis for more. The question is, will there actually be so many constrained devices that offer resources in multiple representation formats that the disadvantages of reactive negotiation outweigh the disadvantages of proactive negotiation? Klaus From cabo@tzi.org Sat Feb 16 08:41:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD3721F8962 for ; Sat, 16 Feb 2013 08:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-TSTZ5wmOW0 for ; Sat, 16 Feb 2013 08:41:46 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23F21F895B for ; Sat, 16 Feb 2013 08:41:45 -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 r1GGfcHr006735; Sat, 16 Feb 2013 17:41:38 +0100 (CET) Received: from [192.168.217.135] (p54893A6C.dip.t-dialin.net [84.137.58.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 738B93233; Sat, 16 Feb 2013 17:41:38 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sat, 16 Feb 2013 17:41:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 16:41:47 -0000 On Feb 16, 2013, at 17:11, Klaus Hartke wrote: > disadvantages Well, we usually won't have that much negotiation, because the selection = will more likely happen at discovery. It really comes down to whether you want servers to encode the selection = of a format into the URI, or whether you want to have a standard way to = associate multiple formats with a single URI. Clearly, this is isomorphic from a functional point of view. So, = really, the questions are: 1) how likely is a server to provide multiple formats? 2) how much do we benefit from a standard way to identify the format = that is separate from the URI? Re 1: I think is it quite likely that sensors implementing SenML will = provide multiple formats, including a text/plain style with some raw = data. The one thing that is really swaying me into keeping Accept is the = potential for converting proxies. That is impossible to do in a general way when you leave the URI = encoding of the desired format to each server. Can we simplify Accept some more? Making it a single choice is unlikely to simplify origin servers much, = as there is very little difference between rejecting a single choice and = stepping through a number of them. (i.e., this would replace a single while loop by a single if condition, = saving one jump or so.) For a cache, of course, there is additional complexity, as the = discussion here is showing. =20 Simply accepting that a cache has to treat different Accept combinations = separately reduces that complexity a lot, though. So I'm still not convinced we want to change anything. But, yes, Accept is not strictly necessary, if you don't think = application-agnostic converting proxies are valuable. And the use cases for multi-valued accept are more sparse than those for = single-valued Accept, but then the complexity is rather limited. Gr=FC=DFe, Carsten From hartke@tzi.org Sat Feb 16 09:16:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EC921F8972 for ; Sat, 16 Feb 2013 09:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfhgEtHY+Y1X for ; Sat, 16 Feb 2013 09:16:36 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEA421F8970 for ; Sat, 16 Feb 2013 09:16: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 r1GHGMj2019120 for ; Sat, 16 Feb 2013 18:16:22 +0100 (CET) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4650B3241 for ; Sat, 16 Feb 2013 18:16:22 +0100 (CET) Received: by mail-lb0-f173.google.com with SMTP id gf7so3376817lbb.18 for ; Sat, 16 Feb 2013 09:16:21 -0800 (PST) X-Received: by 10.112.49.201 with SMTP id w9mr3128205lbn.2.1361034981757; Sat, 16 Feb 2013 09:16:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Sat, 16 Feb 2013 09:16:01 -0800 (PST) In-Reply-To: <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> From: Klaus Hartke Date: Sat, 16 Feb 2013 19:16:01 +0200 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 17:16:37 -0000 Carsten Bormann wrote: > The one thing that is really swaying me into keeping Accept is the potential for converting proxies. How would that look like? Assuming a client sees a link that indicates that the link destination is available in application/senml+xml. Should it send Accept: application/senml+exi, application/senml+xml@gzip, application/senml+xml in the hopes that there is a proxy along the way that performs the conversion to one of the unavailable but preferred formats? If there is no converting proxy, then requests from clients indicating different unavailable but preferred formats would always hit the server, even though each request invariably results in the same application/senml+xml response. Klaus From cabo@tzi.org Sat Feb 16 09:20:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66B221F8468 for ; Sat, 16 Feb 2013 09:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASJkBTsqiyKI for ; Sat, 16 Feb 2013 09:20:51 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 74C7421F8464 for ; Sat, 16 Feb 2013 09:20: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 r1GHKhc7021838 for ; Sat, 16 Feb 2013 18:20:43 +0100 (CET) Received: from [192.168.217.135] (p54893A6C.dip.t-dialin.net [84.137.58.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8DF413245; Sat, 16 Feb 2013 18:20:43 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sat, 16 Feb 2013 18:20:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 17:20:53 -0000 On Feb 16, 2013, at 18:16, Klaus Hartke wrote: > How would that look like? Most likely by the proxy taking part in the resource directory game. (So, again, most likely the client is sending a single-valued Accept, = based on what it knows from discovery about the proxy.) Gr=FC=DFe, Carsten From hartke@tzi.org Sat Feb 16 09:32:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B655421F84C0 for ; Sat, 16 Feb 2013 09:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qZFy+96TaYP for ; Sat, 16 Feb 2013 09:32:50 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85121F843D for ; Sat, 16 Feb 2013 09:32:32 -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 r1GHWPh4025420 for ; Sat, 16 Feb 2013 18:32:25 +0100 (CET) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 56A443247 for ; Sat, 16 Feb 2013 18:32:25 +0100 (CET) Received: by mail-lb0-f169.google.com with SMTP id m4so3363835lbo.28 for ; Sat, 16 Feb 2013 09:32:24 -0800 (PST) X-Received: by 10.112.49.201 with SMTP id w9mr3143173lbn.2.1361035944772; Sat, 16 Feb 2013 09:32:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Sat, 16 Feb 2013 09:32:04 -0800 (PST) In-Reply-To: <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> From: Klaus Hartke Date: Sat, 16 Feb 2013 19:32:04 +0200 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 17:32:50 -0000 Carsten Bormann wrote: >> How would that look like? > > Most likely by the proxy taking part in the resource directory game. Is it still an application-agnostic converting proxy then? > (So, again, most likely the client is sending a single-valued Accept, based on what it knows from discovery about the proxy.) That sounds like an argument for reactive negotiation. Btw I'm not sure if we should rely too much on .well-known/core for discovering everything. Non-link-format documents can contain links, too. Klaus From kovatsch@inf.ethz.ch Mon Feb 18 08:49:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4724921F8C0C for ; Mon, 18 Feb 2013 08:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMhoHghFFOrW for ; Mon, 18 Feb 2013 08:49:36 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7200921F8BF6 for ; Mon, 18 Feb 2013 08:49:20 -0800 (PST) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 18 Feb 2013 17:49:10 +0100 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Mon, 18 Feb 2013 17:49:12 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , Carsten Bormann Thread-Topic: [core] Accept option and intermediaries Thread-Index: AQHOA/HOvR1fkeTn9U+lByHJvtWP2JhsyP+AgAADwYCAAAyqgIAPUSoAgAB3NeCAAAYSgIAACHeAgAAJnICAAAFPAIAAAy0AgAMgXeA= Date: Mon, 18 Feb 2013 16:49:11 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> In-Reply-To: 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 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:49:37 -0000 > > (So, again, most likely the client is sending a single-valued Accept, > > based on what it knows from discovery about the proxy.) >=20 > That sounds like an argument for reactive negotiation. I am still in favor of using a non-repeatable Accept option together with L= ink Format information. This comes pretty close to reactive negotiation wit= h having a standardized way to select the preferred Content-Format. 1) Reactive negotiation with URIs would require linked caches and the serve= r-side behavior of PUT to one of the linked resources is still undefined. A= ccept simplifies this. On the Web multiple resources make more sense, as di= fferent formats are often created manually and can evolve independently (e.= g., a (non-)Flash version of a site). In M2M, there is usually a single dat= a model behind different simple format-encoders. (Without Accept, I would probably implement some coap://example.com/some/re= source.type convention that has a single resource handler for all possible = types given through the Uri-Path. So why not Accept directly?) 2) A repeatable Accept option is prone to blowing up the number of observe = relationships through an intermediary. We already discussed the problem of = permuted Accept lists. If the client is supposed to merge observe relations= hips, as Klaus suggested, it must be able to decide which Accept combinatio= ns are equivalent. This would require probing and cancelling relationships = again. Thus, let us simplify things with a non-repeatable Accept option. 3) Currently the Accept option is the only integer array and requires its u= nique piece of code. Having implemented CoAP for constrained platforms, I w= ould be very happy to get rid of that. In my experience, and apparently Car= sten's as well, multiple Accept options are not very likely in M2M applicat= ions, anyway. > Btw I'm not sure if we should rely too much on .well-known/core for > discovering everything. Non-link-format documents can contain links, too. These links can also contain Link Format information as attributes, no? Ciao Matthias From hartke@tzi.org Mon Feb 18 11:12:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C481021F87B2 for ; Mon, 18 Feb 2013 11:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.609 X-Spam-Level: X-Spam-Status: No, score=-5.609 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPxDAK5-ch7g for ; Mon, 18 Feb 2013 11:12:31 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D7A6121F86D4 for ; Mon, 18 Feb 2013 11:12:30 -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 r1IJCNug023868 for ; Mon, 18 Feb 2013 20:12:23 +0100 (CET) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7F88D3B4F for ; Mon, 18 Feb 2013 20:12:23 +0100 (CET) Received: by mail-la0-f45.google.com with SMTP id er20so5873328lab.32 for ; Mon, 18 Feb 2013 11:12:22 -0800 (PST) X-Received: by 10.152.105.17 with SMTP id gi17mr11499504lab.46.1361214742779; Mon, 18 Feb 2013 11:12:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Mon, 18 Feb 2013 11:12:02 -0800 (PST) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> From: Klaus Hartke Date: Mon, 18 Feb 2013 21:12:02 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:12:31 -0000 OK, it seems there are two places involving content negotiation in CoAP: 1. Servers that offer resources in multiple representation formats. As Matthias said, the representations will likely source from the same data and therefore don't exhibit the problems of, e.g., multi-language web pages. 2. Intermediaries that offer additional representation formats for the resources accessed through them. If either of this is common enough, then I agree that having an Accept-parametrizable resource would be the cleanest solution. Although not part of the URI, different representations could be addressed by specifying the representation format along the URI in a link. My question is, how the client gets the best possible representation format that is available for it. One option is to provide one link for each available format. (This can be encoded very efficiently in a link-format document by creating one link with multiple ct attributes.) But then you'd would have to update all links in existence every time you add or remove a format, which may be difficult if there are links to your resource that are served by a server not under your control. For the application-agnostic converting proxy, the problem is that there naturally won't be any links with the additional formats. Carsten seemed to imply that such a proxy could rewrite .well-known/core to add additional formats. But I guess it won't rewrite all links in all formats, since it's application-agnostic. I strongly oppose the idea of having to retrieve .well-known/core before I can interact with a resource that I discovered by following a link from somewhere else. Another option is to provide the available formats in the representations of the resource, or in a CoAP option that the server sends along the representation. Then, discovery of the available formats is decoupled from the discovery of the resource itself. If a client follows a link and then discovers that the resource is also available in better formats, it can easily switch to the best one. A third option is to let the client include all supported formats in its request; the server returns the representation in the best format that is available. With this option, the client doesn't have to discover the available formats at all, and the converting proxy can easily convert a representation returned by a server to a better format. However, the list of supported formats might be quite long and overall this breaks caching. To me, the second option looks best. If there is consensus to keep the Accept option (which there seems to be), then I'd support limiting it to one instance and providing the alternate formats in the representation or along the representation in a CoAP option (without affecting the ability to specify representation formats in links). Klaus From cabo@tzi.org Mon Feb 18 11:27:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F3921F8702 for ; Mon, 18 Feb 2013 11:27:38 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6VrtdN1X+Cb for ; Mon, 18 Feb 2013 11:27:37 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3338D21F86FC for ; Mon, 18 Feb 2013 11:27:37 -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 r1IJRUPG028541 for ; Mon, 18 Feb 2013 20:27:30 +0100 (CET) Received: from [10.0.1.4] (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 51C9D3B5A; Mon, 18 Feb 2013 20:27:30 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 18 Feb 2013 20:27:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <130CC302-49D9-40D2-AD3B-05C95F541972@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:27:38 -0000 On Feb 18, 2013, at 20:12, Klaus Hartke wrote: > I strongly oppose the idea of having to retrieve .well-known/core > before I can interact with a resource that I discovered by following a > link from somewhere else. Retrieving the link-format information *after* discovery is wrong; I'd = agree with that. > Another option is to provide the available formats in the > representations of the resource, or in a CoAP option that the server > sends along the representation. Again, this information should be made available as part of the = discovery, not something that is delivered with each retrieval of a = resource representation. > Then, discovery of the available > formats is decoupled from the discovery of the resource itself. Why is that such a good thing? > If a > client follows a link and then discovers that the resource is also > available in better formats, it can easily switch to the best one. There have been several suggestions already for a "give me metadata" = type request for a resource. E.g., draft-greevenbosch-core-profile-description-01.txt; there also was = a proposal for finding out the methods that can be applied to a = resource. I'm not yet convinced we need any of these, but I'd discuss a "which = formats are you available in" request in the context of these. Gr=FC=DFe, Carsten From hartke@tzi.org Mon Feb 18 12:16:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF39B21F8CB6 for ; Mon, 18 Feb 2013 12:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7RYj9bBfv0g for ; Mon, 18 Feb 2013 12:16:50 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0C42721F8CB3 for ; Mon, 18 Feb 2013 12:16:49 -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 r1IKGhmR017737 for ; Mon, 18 Feb 2013 21:16:43 +0100 (CET) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 11EB23B7C for ; Mon, 18 Feb 2013 21:16:43 +0100 (CET) Received: by mail-lb0-f172.google.com with SMTP id n8so4605082lbj.31 for ; Mon, 18 Feb 2013 12:16:42 -0800 (PST) X-Received: by 10.112.38.98 with SMTP id f2mr6166232lbk.61.1361218602485; Mon, 18 Feb 2013 12:16:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Mon, 18 Feb 2013 12:16:22 -0800 (PST) In-Reply-To: <130CC302-49D9-40D2-AD3B-05C95F541972@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> <130CC302-49D9-40D2-AD3B-05C95F541972@tzi.org> From: Klaus Hartke Date: Mon, 18 Feb 2013 22:16:22 +0200 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 20:16:51 -0000 Carsten Bormann wrote: >> Then, discovery of the available >> formats is decoupled from the discovery of the resource itself. > > Why is that such a good thing? As I tried to explain, discovery of a resource does not necessarily happen through .well-known/core. I think it's unlikely that all links from all servers to a resource will always provide up-to-date meta-data on the link destination (size, formats, ...). In that case, indicating the available formats in the representations or in a CoAP along the representation allows the client to get the best possible representation format that is available for it, which it otherwise could only discover by retrieving .well-known/core first. > There have been several suggestions already for a "give me metadata" type request for a resource. > E.g., draft-greevenbosch-core-profile-description-01.txt; there also was a proposal for finding out the methods that can be applied to a resource. > I'm not yet convinced we need any of these Agreed. The methods allowed for a resource are typically discovered by following links in the representation of the resource. For example, a resource that is updatable would include a link in its representation that indicates where to PUT the new information and what representation formats are acceptable. So I see no need for discovering the allowed methods through .well-known/core, an OPTIONS method or any other mechanism. Klaus From sarikaya2012@gmail.com Mon Feb 18 12:21:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A00521F8CBD; Mon, 18 Feb 2013 12:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RGgfYJYvHRq; Mon, 18 Feb 2013 12:21:03 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 07BF121F8CB5; Mon, 18 Feb 2013 12:20:59 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fs13so5766063lab.8 for ; Mon, 18 Feb 2013 12:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ELGAq9AN935dw8sAdXaOeQpYyVwpc555EglErfrV7aI=; b=XdeRh4gg9z/TheKrGhfpEj5/CIJ9AFHmmZBL0qFjeb+02HovSLWxYNlgRJu/yYOs7i wyYWkFVnX5RwS33CsM58k+WEHJHYUshI1TG3KjQ4yT4FV4gz00wGqp/nn74hj0H32C0v NMK1Ipm3qgopykbGOgDiULcqVemUKETR7cqhlE8OV+nBWpEJvy/qwXOO7+usyZzbfptf 1WzPQ22jnxL7k/P0lRBjPlvBNzBUPx4IdKh6HxAxJW+F7fROrKw1eM7XS3WnUdp7fZLl +F01exFAFZmgqgIZFCZyZD7bQwBuFHrqIFhVJziNFTUOtkgmsW+AtTsTi9/bMBVb/N9C Qyow== MIME-Version: 1.0 X-Received: by 10.152.122.100 with SMTP id lr4mr11890910lab.28.1361218858802; Mon, 18 Feb 2013 12:20:58 -0800 (PST) Received: by 10.114.28.168 with HTTP; Mon, 18 Feb 2013 12:20:58 -0800 (PST) In-Reply-To: <20130218201533.23785.337.idtracker@ietfa.amsl.com> References: <20130218201533.23785.337.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 14:20:58 -0600 Message-ID: From: Behcet Sarikaya To: core WG Content-Type: multipart/alternative; boundary=f46d042ef6618a5f2f04d6057698 Cc: solace@ietf.org, lln-futures@ietf.org Subject: [core] New Version Notification for draft-sarikaya-core-secure-bootsolution-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 20:21:05 -0000 --f46d042ef6618a5f2f04d6057698 Content-Type: text/plain; charset=ISO-8859-1 Dear all, I submitted a -00 draft on secure bootstrapping solution. The draft is short. I intend to stir some discussions with the hope of commonly designing the right solution :-). Regards, Behcet A new version of I-D, draft-sarikaya-core-secure-bootsolution-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-core-secure-bootsolution Revision: 00 Title: Security Bootstrapping Solution for Resource-Constrained Devices Creation date: 2013-02-18 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-core-secure-bootsolution-00.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-core-secure-bootsolution Htmlized: http://tools.ietf.org/html/draft-sarikaya-core-secure-bootsolution-00 Abstract: We present a solution to initially configure the network of resource constrained nodes securely, a.k.a., security bootstrapping. The solution is based on EAP-TLS authentication with the use of raw public keys as certificates. The IETF Secretariat --f46d042ef6618a5f2f04d6057698 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

I submitted a -00 draft on secure bootstrapping solution. = The draft is short. I intend to stir some discussions with the hope of comm= only designing the right solution :-).

Regards,
Behcet

A new version of I-D, draft-sarikaya-core-secure-bootsolution-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sarikaya-core-secure-bootsolution
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Security Bootstrapping Solution for Resource-Con= strained Devices
Creation date: =A0 2013-02-18
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://w= ww.ietf.org/internet-drafts/draft-sarikaya-core-secure-bootsolution-00.txt<= /a>
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ie= tf.org/doc/draft-sarikaya-core-secure-bootsolution
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/htm= l/draft-sarikaya-core-secure-bootsolution-00


Abstract:
=A0 =A0We present a solution to initially configure the network of resource=
=A0 =A0constrained nodes securely, a.k.a., security bootstrapping. =A0The =A0 =A0solution is based on EAP-TLS authentication with the use of raw
=A0 =A0public keys as certificates.




The IETF Secretariat


--f46d042ef6618a5f2f04d6057698-- From Bert.Greevenbosch@huawei.com Mon Feb 18 18:11:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D3E21F8A43 for ; Mon, 18 Feb 2013 18:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iajjxIdYEoyP for ; Mon, 18 Feb 2013 18:11:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02BF921F89C0 for ; Mon, 18 Feb 2013 18:11:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APV76574; Tue, 19 Feb 2013 02:11:42 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 02:11:10 +0000 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 10:11:41 +0800 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Tue, 19 Feb 2013 10:11:36 +0800 From: Bert Greevenbosch To: Klaus Hartke , "Dijk, Esko" Thread-Topic: [core] #281: Safe-to-forward options Thread-Index: AQHOBGTD8q9v0AFZgUWmx2wypghaCphsPsaAgAAFLICAABRMAIAAAJ0AgAAByACAAAKUAIAAAS6AgAABdICAAArwAIAArVOAgADRr0D//4D2gIAAApmAgACHf3D//33IAIAAhtCA//+HsYAAA5iwgAABsvcAAAJdlQAAL7yYgAAA5quAAKXPv4AAgzbxAAACIH0AAABkIwAA++BVgA== Date: Tue, 19 Feb 2013 02:11:35 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D586F2E@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> <031DD135F9160444ABBE3B0C36CED618B95919@011-DB3MPN2-083.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 02:11:51 -0000 Hi Esko, Klaus, Robert, all, As I understand this, tokens and sequence numbers are independent. This mea= ns that the server could maintain a single counter for all resources, or ma= ybe one counter per resource, or maybe one counter per resource per subscri= ber. It is up to the server implementation how to maintain the counters, as= long as they are monotonically increasing except for the carry around 2^24= . The current proposal is to use the tokens as part of the identifier for the= observation relationship, so the tuple (ip, port, token, resource) describ= es this. To change this observation relationship, the same token should be = used. Another token would identify another observation relationship. Indeed if the server reboots and looses state, it would restart counting an= d the ordering could be messed up. However, since the server lost its state= , it is likely that the server will not send any more observation notificat= ions. When the client realises this, it can re-establish the observation re= lationship, with a token as it prefers. There indeed is a small chance that the client does not realise something h= appened to the server (e.g. reboot) that messed up the sequence numbers. I = guess the only time that this is a problem is, when the client wants to mod= ify the observation relationship without knowledge about the server's reboo= t. In this case, the client could send a GET with observe option and the pr= evious token. Instead of modifying the non-existent observation relationshi= p, the server establishes a new observation relationship. This may lead, de= pending on the server's implementation, to a restart of the counter and dis= continuity in monotonically increase. But does this have anything to do with adding token to the tuple? It seems = that taking account of the token this the problem would be similar. Corner case? If not, one could consider adding the last received sequence n= umber to the observe request too, such that the server has knowledge about = the last sequence number the client has received, and send some error when = it is inconsistent. I am not sure if it is worth the complexity though. What do you think? Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: 14 February 2013 17:41 To: Dijk, Esko Cc: core@ietf.org WG Subject: Re: [core] #281: Safe-to-forward options Esko Dijk wrote: >> No. The token functions as a generation identifier for the sequence numb= ers, so you always need >> to use a new token if you want to refresh an existing observation. > > To me it's not yet clear why the sequence numbers need to be "reset" by t= he server upon refresh (i.e. new generation). Couldn't it just keep countin= g on? In any case, there's no requirement for the server to start at a spec= ific number, or not? If so it could just keep counting. Yes, the server could keep counting on; then it wouldn't be a problem. But currently the server is *not required* to keep counting on. The client must use a token to give the server the freedom of choosing between whether it counts on or not. Counting on may be difficult if the server reboots and loses state. Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From Bert.Greevenbosch@huawei.com Mon Feb 18 18:17:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1C121E8099 for ; Mon, 18 Feb 2013 18:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpl6FUdapYs8 for ; Mon, 18 Feb 2013 18:17:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A84521E80A8 for ; Mon, 18 Feb 2013 18:17:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOO73461; Tue, 19 Feb 2013 02:17:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 02:16:19 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 02:16:59 +0000 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.230]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.007; Tue, 19 Feb 2013 10:16:52 +0800 From: Bert Greevenbosch To: Klaus Hartke , "Dijk, Esko" Thread-Topic: [core] #281: Safe-to-forward options (correction) Thread-Index: AQHOBGTD8q9v0AFZgUWmx2wypghaCphsPsaAgAAFLICAABRMAIAAAJ0AgAAByACAAAKUAIAAAS6AgAABdICAAArwAIAArVOAgADRr0D//4D2gIAAApmAgACHf3D//33IAIAAhtCA//+HsYAAA5iwgAABsvcAAAJdlQAAL7yYgAAA5quAAKXPv4AAgzbxAAACIH0AAABkIwAA++BVgAAAuo7Q Date: Tue, 19 Feb 2013 02:16:51 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D586F47@szxeml558-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: [core] FW: #281: Safe-to-forward options (correction) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 02:17:03 -0000 "It seems that taking account of the token this the problem would be simila= r." should have been "It seems that without taking account of the token the problem would be sim= ilar." --- Hi Esko, Klaus, Robert, all, As I understand this, tokens and sequence numbers are independent. This mea= ns that the server could maintain a single counter for all resources, or ma= ybe one counter per resource, or maybe one counter per resource per subscri= ber. It is up to the server implementation how to maintain the counters, as= long as they are monotonically increasing except for the carry around 2^24= . The current proposal is to use the tokens as part of the identifier for the= observation relationship, so the tuple (ip, port, token, resource) describ= es this. To change this observation relationship, the same token should be = used. Another token would identify another observation relationship. Indeed if the server reboots and looses state, it would restart counting an= d the ordering could be messed up. However, since the server lost its state= , it is likely that the server will not send any more observation notificat= ions. When the client realises this, it can re-establish the observation re= lationship, with a token as it prefers. There indeed is a small chance that the client does not realise something h= appened to the server (e.g. reboot) that messed up the sequence numbers. I = guess the only time that this is a problem is, when the client wants to mod= ify the observation relationship without knowledge about the server's reboo= t. In this case, the client could send a GET with observe option and the pr= evious token. Instead of modifying the non-existent observation relationshi= p, the server establishes a new observation relationship. This may lead, de= pending on the server's implementation, to a restart of the counter and dis= continuity in monotonically increase. But does this have anything to do with adding token to the tuple? It seems = that without taking account of the token the problem would be similar. Corner case? If not, one could consider adding the last received sequence n= umber to the observe request too, such that the server has knowledge about = the last sequence number the client has received, and send some error when = it is inconsistent. I am not sure if it is worth the complexity though. What do you think? Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: 14 February 2013 17:41 To: Dijk, Esko Cc: core@ietf.org WG Subject: Re: [core] #281: Safe-to-forward options Esko Dijk wrote: >> No. The token functions as a generation identifier for the sequence numb= ers, so you always need >> to use a new token if you want to refresh an existing observation. > > To me it's not yet clear why the sequence numbers need to be "reset" by t= he server upon refresh (i.e. new generation). Couldn't it just keep countin= g on? In any case, there's no requirement for the server to start at a spec= ific number, or not? If so it could just keep counting. Yes, the server could keep counting on; then it wouldn't be a problem. But currently the server is *not required* to keep counting on. The client must use a token to give the server the freedom of choosing between whether it counts on or not. Counting on may be difficult if the server reboots and loses state. Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Tue Feb 19 00:13:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B05821F8D64 for ; Tue, 19 Feb 2013 00:13:09 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+Mor2hyCE3N for ; Tue, 19 Feb 2013 00:13:08 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6E03E21F8450 for ; Tue, 19 Feb 2013 00:13:08 -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 r1J8Cx7P004567; Tue, 19 Feb 2013 09:12:59 +0100 (CET) Received: from zfn2-114-181.wlan.uni-bremen.de (zfn2-114-181.wlan.uni-bremen.de [134.102.114.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7A9923CBD; Tue, 19 Feb 2013 09:12:59 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514DD2CFB@MBX20.d.ethz.ch> Date: Tue, 19 Feb 2013 09:12:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9078F8D6-CABE-418A-85C6-839459B56D6D@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD2CFB@MBX20.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:13:09 -0000 On Feb 16, 2013, at 16:26, Kovatsch Matthias = wrote: > PUT must invalidate all cache entries anyway. Here we have a major = problem if we use separate resources for different Content-Types (cf. = Reactive Negotiation) ... Exactly: going towards multiple URIs for different representations of = one resource just conveniently makes PUT invalidation impossible, = "solving" this problem. PUT invalidation is a bit of a luxury item anyway. If there are two caches talking to an origin server, only the client of = one of them will benefit from PUT invalidation. (If there is any other transaction invalidating the resource as a side = effect, no one will benefit from PUT invalidation.) Any approach that *relies* on PUT invalidation to kick in is not going = to work. (According to the protocols 101 principle on when you can put in a = MUST*), this means the MUST is out of place. But I'm not arguing for = turning it into a quality of implementation note.) Gr=FC=DFe, Carsten *) You can put in a MUST in either of the two following cases: 1) the required behavior prevents the network from blowing up, a bank = from being robbed, etc. 2) the required behavior allows the protocol peer to rely on this = behavior, providing some benefit that outweighs the onus of the MUST. From cabo@tzi.org Tue Feb 19 00:16:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ACB21F8D8F for ; Tue, 19 Feb 2013 00:16:49 -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=[AWL=-0.000, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKR0ue0oGKqW for ; Tue, 19 Feb 2013 00:16:48 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2F221F8D74 for ; Tue, 19 Feb 2013 00:16:48 -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 r1J8GheZ005750 for ; Tue, 19 Feb 2013 09:16:43 +0100 (CET) Received: from zfn2-114-181.wlan.uni-bremen.de (zfn2-114-181.wlan.uni-bremen.de [134.102.114.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58BB43CC7; Tue, 19 Feb 2013 09:16:43 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 19 Feb 2013 09:16:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B665766-3322-484A-B96F-143507411C95@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> <130CC302-49D9-40D2-AD3B-05C95F541972@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:16:49 -0000 On Feb 18, 2013, at 21:16, Klaus Hartke wrote: > The methods allowed for a resource are typically discovered by > following links Why do you believe the links will expose the methods and not the format? I know HTML works this way, but is this relevant for how we expect CoAP = clients to obtain links? If it is truly beneficial to know the complete set of available formats, = other links than the ones in link-format could also supply this = information. (We already have the link target attribute for that, "ct".) Gr=FC=DFe, Carsten From hartke@tzi.org Tue Feb 19 01:56:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB2D21F8D8E for ; Tue, 19 Feb 2013 01:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUJRDIHu5ir6 for ; Tue, 19 Feb 2013 01:56:53 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D2AB821F8D8D for ; Tue, 19 Feb 2013 01:56:52 -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 r1J9ujnb028291 for ; Tue, 19 Feb 2013 10:56:45 +0100 (CET) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3844A3DA8 for ; Tue, 19 Feb 2013 10:56:45 +0100 (CET) Received: by mail-lb0-f174.google.com with SMTP id l12so4956518lbo.33 for ; Tue, 19 Feb 2013 01:56:44 -0800 (PST) X-Received: by 10.152.146.199 with SMTP id te7mr13491153lab.23.1361267804574; Tue, 19 Feb 2013 01:56:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Tue, 19 Feb 2013 01:56:24 -0800 (PST) In-Reply-To: <4B665766-3322-484A-B96F-143507411C95@tzi.org> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> <130CC302-49D9-40D2-AD3B-05C95F541972@tzi.org> <4B665766-3322-484A-B96F-143507411C95@tzi.org> From: Klaus Hartke Date: Tue, 19 Feb 2013 11:56:24 +0200 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:56:53 -0000 Carsten Bormann wrote: >> The methods allowed for a resource are typically discovered by >> following links > > Why do you believe the links will expose the methods and not the format? > I know HTML works this way, but is this relevant for how we expect CoAP clients to obtain links? > If it is truly beneficial to know the complete set of available formats, other links than the ones in link-format could also supply this information. > (We already have the link target attribute for that, "ct".) There is a difference between A) a resource making a statement about another resource (possibly on a different server), B) a resource making a statement about itself, and C) .well-known/core making a statement about a resource hosted on the same server. The state of a resource can change over time, and so does its meta-data like representation size, available representation formats and if and how the resource can be changed. When a client retrieves .well-known/core, it is fair to assume that the meta-data embedded in the links is accurate at the time of the request. So the client can, for example, select the best representation format. Similarly, if a client retrieves a representation of a resource that indicates that the resource is in a state in which it can be deleted, the client can use this information to delete the resource. But if a resource links to another resource, it's unreasonable to rely on the assumption that the embedded meta-data reflects the current state of the linked resource, in particular if the linked resource is on a different server. Unless the server retrieves the link destination or .well-known/core before generating the link, it does not know the size of the current representations, whether new (better) representation formats are available or if the resource is in a state in which it can be changed. After all, link attributes are just hints, not promises. If a link makes an outdated statement about the representation size, I can still retrieve the representation. If a link makes an outdated statement about the state of a resource, I can learn if the resource is updatable/deletable by retrieving a representation of the current state and go from there. So, if a link makes an outdated statement about available representation formats, I should be able to discover new formats that have become available in the meantime and should not be required to retrieve .well-known/core as the only way to learn them. Klaus From kovatsch@inf.ethz.ch Tue Feb 19 03:45:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6590321F8BB6 for ; Tue, 19 Feb 2013 03:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.099 X-Spam-Level: X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2jTaK5lMuSX for ; Tue, 19 Feb 2013 03:45:57 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7EB21F8A6C for ; Tue, 19 Feb 2013 03:45:57 -0800 (PST) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 19 Feb 2013 12:45:47 +0100 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.02.0298.004; Tue, 19 Feb 2013 12:45:50 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , Carsten Bormann Thread-Topic: [core] Accept option and intermediaries Thread-Index: AQHOA/HOvR1fkeTn9U+lByHJvtWP2JhsyP+AgAADwYCAAAyqgIAPUSoAgAB3NeCAAAYSgIAACHeAgAAJnICAAAFPAIAAAy0AgAMgXeCAACA7AIAABFGAgAANqQCAAMlCAIAAG9sAgAAtnzA= Date: Tue, 19 Feb 2013 11:45:49 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DDABDF@MBX20.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> <130CC302-49D9-40D2-AD3B-05C95F541972@tzi.org> <4B665766-3322-484A-B96F-143507411C95@tzi.org> In-Reply-To: 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 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 11:45:58 -0000 > The state of a resource can change over time, and so does its meta-data l= ike > representation size, available representation formats and if and how the > resource can be changed. I just want to remark that the metadata is not that likely to change, so th= ey are very good hints. The size denotes an estimated upper bound (maybe li= nked to the maximum buffer size the server can support for this resource) a= nd the format is linked to the encoders implemented in the firmware (which = despite the Block use case will not change that often :) ). Your case sound= s more like a RESTful clipboard where the server is agnostic of the data st= ored at a resource. Ciao Matthias From hartke@tzi.org Tue Feb 19 04:06:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFCC21F88F0 for ; Tue, 19 Feb 2013 04:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRqISzZEMCI5 for ; Tue, 19 Feb 2013 04:06:26 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0431F21F8806 for ; Tue, 19 Feb 2013 04:06: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 r1JC6Iuj010342 for ; Tue, 19 Feb 2013 13:06:19 +0100 (CET) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A636D3EE8 for ; Tue, 19 Feb 2013 13:06:18 +0100 (CET) Received: by mail-lb0-f181.google.com with SMTP id gm6so4997344lbb.40 for ; Tue, 19 Feb 2013 04:06:18 -0800 (PST) X-Received: by 10.152.106.5 with SMTP id gq5mr14074405lab.5.1361275578103; Tue, 19 Feb 2013 04:06:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Tue, 19 Feb 2013 04:05:57 -0800 (PST) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514DDABDF@MBX20.d.ethz.ch> References: <497C2C2B-D238-4959-A1C8-90C7D2C8D950@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD0CD1@MBX20.d.ethz.ch> <9F052A13-81C3-4E33-8C0C-7FF37870C45B@tzi.org> <2EBF8F4D-1701-4B30-8D14-5449F930CDA0@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DD7D3F@MBX20.d.ethz.ch> <130CC302-49D9-40D2-AD3B-05C95F541972@tzi.org> <4B665766-3322-484A-B96F-143507411C95@tzi.org> <55877B3AFB359744BA0F2140E36F52B514DDABDF@MBX20.d.ethz.ch> From: Klaus Hartke Date: Tue, 19 Feb 2013 14:05:57 +0200 Message-ID: To: Kovatsch Matthias Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org WG" Subject: Re: [core] Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 12:06:29 -0000 Matthias Kovatsch wrote: >> The state of a resource can change over time, and so does its meta-data like >> representation size, available representation formats and if and how the >> resource can be changed. > > I just want to remark that the metadata is not that likely to change, so they are very good hints. Not if you add application-agnostic converting proxies to the mix. And resources linking to different servers will likely not provide these hints at all. Klaus From hartke@tzi.org Sat Feb 23 06:11:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F9321F8CB3 for ; Sat, 23 Feb 2013 06:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxFfjcXEiGfr for ; Sat, 23 Feb 2013 06:11:41 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BFE1321F8B9E for ; Sat, 23 Feb 2013 06:11:39 -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 r1NEBVlX022441 for ; Sat, 23 Feb 2013 15:11:31 +0100 (CET) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2A8853012 for ; Sat, 23 Feb 2013 15:11:31 +0100 (CET) Received: by mail-lb0-f171.google.com with SMTP id gg13so1226590lbb.16 for ; Sat, 23 Feb 2013 06:11:30 -0800 (PST) X-Received: by 10.112.38.228 with SMTP id j4mr2293918lbk.1.1361628690565; Sat, 23 Feb 2013 06:11:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.58.13 with HTTP; Sat, 23 Feb 2013 06:11:10 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D586F2E@szxeml558-mbx.china.huawei.com> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> <5112693F.6030705@intec.ugent.be> <3A755D14-AEC4-46F7-B6D0-C221C870E209@tzi.org> <46A1DF3F04371240B504290A071B4DB63D5838F3@szxeml558-mbx.china.huawei.com> <9312CD3E-2E53-4513-B19F-B0C5FAFA46E3@intec.ugent.be> <24B552E0-19DD-46D3-89CA-77BAD8A51787@gmail.com> <031DD135F9160444ABBE3B0C36CED618B95919@011-DB3MPN2-083.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB63D586F2E@szxeml558-mbx.china.huawei.com> From: Klaus Hartke Date: Sat, 23 Feb 2013 16:11:10 +0200 Message-ID: To: Bert Greevenbosch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 14:11:44 -0000 Hi Bert, all, Bert Greevenbosch wrote: > The current proposal is to use the tokens as part of the identifier for t= he observation relationship, so the tuple (ip, port, token, resource) descr= ibes this. To change this observation relationship, the same token should b= e used. Another token would identify another observation relationship. I think you have a point there. We're using tokens to match notifications to a requests, so it feels right to use the token also to check if the server is still aware of the client and to tell the server to stop sending notifications. I'm not sure if labelling the messages for these two operations as GET requests is the best solution though. And I'd prefer to keep that a token functions as generation identifier for sequence numbers. Temporal serial arithmetic is complicated enough already. I'll try to implement the current ideas and see how the changes work out. The IETF86 submission deadline is quite close though, so I'll submit observe-08 soon without addressing ticket #281 for now. Klaus From sye.loong.keoh@philips.com Mon Feb 25 08:19:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EAF21F9546; Mon, 25 Feb 2013 08:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq-0TRUFF0EZ; Mon, 25 Feb 2013 08:19:16 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6426221F94B1; Mon, 25 Feb 2013 08:19:16 -0800 (PST) Received: from mail248-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 16:19:15 +0000 Received: from mail248-va3 (localhost [127.0.0.1]) by mail248-va3-R.bigfish.com (Postfix) with ESMTP id 7FC957002BB; Mon, 25 Feb 2013 16:19:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -44 X-BigFish: VPS-44(zz217bI15d6O9251J936eI542I1a09Ja65Rzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail248-va3 (localhost.localdomain [127.0.0.1]) by mail248-va3 (MessageSwitch) id 1361809152556960_2529; Mon, 25 Feb 2013 16:19:12 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.239]) by mail248-va3.bigfish.com (Postfix) with ESMTP id 83410C40088; Mon, 25 Feb 2013 16:19:12 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Feb 2013 16:19:11 +0000 Received: from 011-DB3MPN1-031.MGDPHG.emi.philips.com ([169.254.1.208]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.02.0328.011; Mon, 25 Feb 2013 16:19:05 +0000 From: "Keoh, Sye Loong" To: "lwip@ietf.org" , "core@ietf.org" , "solace@ietf.org" Thread-Topic: New Version Notification for draft-keoh-lwig-dtls-iot-01.txt Thread-Index: AQHOE3LTiRFnpst2nUe7iGkOHVg9hJiKv00Q Date: Mon, 25 Feb 2013 16:19:04 +0000 Message-ID: References: <20130225161139.6943.69315.idtracker@ietfa.amsl.com> In-Reply-To: <20130225161139.6943.69315.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] New Version Notification for draft-keoh-lwig-dtls-iot-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:19:17 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IEludGVybmV0IGRyYWZ0IHRvIHRo ZSBMV0lHIFdHIHRvIHNoYXJlIG91ciBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIG9uIHVzaW5n IERUTFMgZm9yIHZhcmlvdXMgc2VjdXJpdHkgZnVuY3Rpb25hbGl0aWVzLCBpLmUuLCBuZXR3b3Jr IGFjY2Vzcywga2V5IG1hbmFnZW1lbnQsIGFuZCBzZWN1cmUgbXVsdGljYXN0IGNvbW11bmljYXRp b24gaW4gb3JkZXIgdG8gZmFjaWxpdGF0ZSBJbnRlcm5ldCBvZiBUaGluZ3MgKElvVCkuDQoNCkNv bW1lbnRzIGFuZCBmZWVkYmFjayBhcmUgdmVyeSBtdWNoIGFwcHJlY2lhdGVkLg0KDQpNYW55IHRo YW5rcw0KU3llIExvb25nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpT ZW50OiBtYWFuZGFnIDI1IGZlYnJ1YXJpIDIwMTMgMTc6MTINClRvOiBLZW9oLCBTeWUgTG9vbmcN CkNjOiBLdW1hciwgU2FuZGVlcDsgR2FyY2lhIE1vcmNob24sIE9zY2FyDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtlb2gtbHdpZy1kdGxzLWlvdC0wMS50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta2VvaC1sd2lnLWR0bHMtaW90LTAxLnR4 dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN5ZSBMb29uZyBLZW9oIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC1r ZW9oLWx3aWctZHRscy1pb3QNClJldmlzaW9uOiAgICAgICAgMDENClRpdGxlOiAgICAgICAgICAg U2VjdXJpbmcgdGhlIElQLWJhc2VkIEludGVybmV0IG9mIFRoaW5ncyB3aXRoIERUTFMNCkNyZWF0 aW9uIGRhdGU6ICAgMjAxMy0wMi0yNQ0KR3JvdXA6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCk51bWJlciBvZiBwYWdlczogMjANClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2VvaC1sd2lnLWR0bHMtaW90LTAxLnR4dA0K U3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtl b2gtbHdpZy1kdGxzLWlvdA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1rZW9oLWx3aWctZHRscy1pb3QtMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQta2VvaC1sd2lnLWR0bHMtaW90LTAxDQoN CkFic3RyYWN0Og0KICAgVGhlIElQLWJhc2VkIEludGVybmV0IG9mIFRoaW5ncyAoSW9UKSByZWZl cnMgdG8gdGhlIHBlcnZhc2l2ZQ0KICAgaW50ZXJhY3Rpb24gb2Ygc21hcnQgZGV2aWNlcyBhbmQg cGVvcGxlIGVuYWJsaW5nIG5ldyBhcHBsaWNhdGlvbnMgYnkNCiAgIG1lYW5zIG9mIElQIHByb3Rv Y29scy4gVHJhZGl0aW9uYWwgSVAgcHJvdG9jb2xzIHdpbGwgYmUgZnVydGhlcg0KICAgY29tcGxl bWVudGVkIGJ5IDZMb1dQQU4gYW5kIENvQVAgdG8gbWFrZSB0aGUgSW9UIGZlYXNpYmxlIG9uIHNt YWxsDQogICBkZXZpY2VzLiBTZWN1cml0eSBhbmQgcHJpdmFjeSBhcmUgYSBtdXN0IGZvciBzdWNo IGFuIGVudmlyb25tZW50LiBEdWUNCiAgIHRvIG1vYmlsaXR5LCBsaW1pdGVkIGJhbmR3aWR0aCwg cmVzb3VyY2UgY29uc3RyYWludHMsIGFuZCBuZXcNCiAgIGNvbW11bmljYXRpb24gdG9wb2xvZ2ll cywgZXhpc3Rpbmcgc2VjdXJpdHkgc29sdXRpb25zIG5lZWQgdG8gYmUNCiAgIGFkYXB0ZWQuIFdl IHByb3Bvc2UgYSBzZWN1cml0eSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBJb1QgaW4gb3JkZXIgdG8N CiAgIHByb3ZpZGUgbmV0d29yayBhY2Nlc3MgY29udHJvbCB0byBzbWFydCBkZXZpY2VzLCB0aGUg bWFuYWdlbWVudCBvZg0KICAga2V5cyBhbmQgc2VjdXJpbmcgdW5pY2FzdC9tdWx0aWNhc3QgY29t bXVuaWNhdGlvbi4gRGV2aWNlcyBhcmUNCiAgIGF1dGhlbnRpY2F0ZWQgYW5kIGdyYW50ZWQgbmV0 d29yayBhY2Nlc3MgYnkgbWVhbnMgb2YgYSBwcmUtc2hhcmVkIGtleQ0KICAgKFBTSykgYmFzZWQg c2VjdXJpdHkgaGFuZHNoYWtlIHByb3RvY29sLiBUaGUgc29sdXRpb24gaXMgYmFzZWQgb24NCiAg IERhdGFncmFtIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoRFRMUykuIFRocm91Z2ggdGhlIGVz dGFibGlzaGVkDQogICBzZWN1cmUgY2hhbm5lbHMsIGtleWluZyBtYXRlcmlhbHMsIG9wZXJhdGlv bmFsIGFuZCBzZWN1cml0eQ0KICAgcGFyYW1ldGVycyBhcmUgZGlzdHJpYnV0ZWQsIGVuYWJsaW5n IGRldmljZXMgdG8gZGVyaXZlIHNlc3Npb24ga2V5cw0KICAgYW5kIGdyb3VwIGtleXMuIFRoZSBz b2x1dGlvbiByZWxpZXMgb24gdGhlIERUTFMgUmVjb3JkIExheWVyIGZvciB0aGUNCiAgIHByb3Rl Y3Rpb24gb2YgdW5pY2FzdCBhbmQgbXVsdGljYXN0IGRhdGEgZmxvd3MuIFdlIGhhdmUgcHJvdG90 eXBlZA0KICAgYW5kIGV2YWx1YXRlZCB0aGUgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlLiBUaGUgRFRM UyBhcmNoaXRlY3R1cmUgYWxsb3dzDQogICBmb3IgZWFzaWVyIGludGVyYWN0aW9uIGFuZCBpbnRl cm9wZXJhYmlsaXR5IHdpdGggdGhlIEludGVybmV0IGR1ZSB0bw0KICAgdGhlIGV4dGVuc2l2ZSB1 c2Ugb2YgVExTLiBIb3dldmVyLCBpdCBleGhpYml0cyBwZXJmb3JtYW5jZSBpc3N1ZXMNCiAgIGNv bnN0cmFpbmluZyBpdHMgZGVwbG95bWVudCBpbiBzb21lIG5ldHdvcmsgdG9wb2xvZ2llcyBhbmQg aGVuY2UNCiAgIHdvdWxkIHJlcXVpcmUgZnVydGhlciBvcHRpbWl6YXRpb25zLg0KDQoNCg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlk ZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1l c3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0 IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0 aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3Jp Z2luYWwgbWVzc2FnZS4NCg== From internet-drafts@ietf.org Mon Feb 25 11:01:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74121F938C; Mon, 25 Feb 2013 11:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12Rdr4KKpa1v; Mon, 25 Feb 2013 11:01:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECF121F9362; Mon, 25 Feb 2013 11:01:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225190129.10901.96517.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 11:01:29 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-observe-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:01:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Observing Resources in CoAP Author(s) : Klaus Hartke Filename : draft-ietf-core-observe-08.txt Pages : 31 Date : 2013-02-25 Abstract: CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best- effort approach for sending new representations to clients, and provides eventual consistency between the state observed by each client and the actual resource state at the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-observe There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-observe-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-observe-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zach@sensinode.com Mon Feb 25 14:16:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473C221E80FA for ; Mon, 25 Feb 2013 14:16:02 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ4HSxbKKUeR for ; Mon, 25 Feb 2013 14:16:00 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5F421E80F6 for ; Mon, 25 Feb 2013 14:15:59 -0800 (PST) Received: from [192.168.50.149] (38.Red-80-32-96.staticIP.rima-tde.net [80.32.96.38]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r1PMFsPa018346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Feb 2013 00:15:57 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2013 23:17:01 +0100 References: <20130225221311.17677.1216.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" Message-Id: <4E6A77E7-7F78-41B5-BE13-A261D6EA836C@sensinode.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:16:02 -0000 I have posted a new version of the RD draft, now including group = support, alignment with the OMA Lightweight M2M standards work and = improved interfaces. Thanks to Esko and Peter for help with the group = support.=20 Regards, Zach Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-shelby-core-resource-directory-05.txt > Date: February 25, 2013 11:13:11 PM GMT+01:00 > To: zach@sensinode.com > Cc: srdjan.krco@ericsson.com, cabo@tzi.org >=20 >=20 > A new version of I-D, draft-shelby-core-resource-directory-05.txt > has been successfully submitted by Zach Shelby and posted to the > IETF repository. >=20 > Filename: draft-shelby-core-resource-directory > Revision: 05 > Title: CoRE Resource Directory > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 27 > URL: = http://www.ietf.org/internet-drafts/draft-shelby-core-resource-directory-0= 5.txt > Status: = http://datatracker.ietf.org/doc/draft-shelby-core-resource-directory > Htmlized: = http://tools.ietf.org/html/draft-shelby-core-resource-directory-05 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-shelby-core-resource-directory-05= >=20 > Abstract: > In many M2M applications, direct discovery of resources is not > practical due to sleeping nodes, disperse networks, or networks = where > multicast traffic is inefficient. These problems can be solved by > employing an entity called a Resource Directory (RD), which hosts > descriptions of resources held on other servers, allowing lookups to > be performed for those resources. This document specifies the web > interfaces that a Resource Directory supports in order for web > servers to discover the RD and to register, maintain, lookup and > remove resources descriptions. Furthermore, new link attributes > useful in conjunction with an RD are defined. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From bilhanan.silverajan@tut.fi Wed Feb 27 03:17:35 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8421F8533 for ; Wed, 27 Feb 2013 03:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApZU8DD8dQem for ; Wed, 27 Feb 2013 03:17:35 -0800 (PST) Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by ietfa.amsl.com (Postfix) with SMTP id 28C0821F8522 for ; Wed, 27 Feb 2013 03:17:34 -0800 (PST) Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id 06C351BA; Wed, 27 Feb 2013 13:17:34 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 10044-40; Wed, 27 Feb 2013 13:17:33 +0200 (EET) Received: from [192.168.252.249] (unknown [192.100.124.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 2B2051B8; Wed, 27 Feb 2013 13:17:33 +0200 (EET) Message-ID: <512DEB4C.2020605@tut.fi> Date: Wed, 27 Feb 2013 13:17:32 +0200 From: Bill Silverajan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: core@ietf.org, teemu.savolainen@nokia.com References: <20130225194225.21366.82863.idtracker@ietfa.amsl.com> In-Reply-To: <20130225194225.21366.82863.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130225194225.21366.82863.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.2 Subject: [core] New Version Notification for draft-silverajan-core-coap-alternative-transports-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 11:17:36 -0000 Dear all, We posted a new version of our draft, on using CoAP over alternative transports instead of UDP. The draft outlines some use cases, discusses various ways to represent transport protocols in URIs and outlines general requirements for conveying CoAP packets. The draft isn't long and all comments/feedback are very welcome to keep improving future submissions. Regards, Bill -------- Original Message -------- Subject: New Version Notification for draft-silverajan-core-coap-alternative-transports-01.txt Date: Mon, 25 Feb 2013 11:42:25 -0800 From: internet-drafts@ietf.org To: bilhanan.silverajan@tut.fi CC: teemu.savolainen@nokia.com A new version of I-D, draft-silverajan-core-coap-alternative-transports-01.txt has been successfully submitted by Bilhanan Silverajan and posted to the IETF repository. Filename: draft-silverajan-core-coap-alternative-transports Revision: 01 Title: CoAP Communication with Alternative Transports Creation date: 2013-02-25 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-silverajan-core-coap-alternative-transports-01.txt Status: http://datatracker.ietf.org/doc/draft-silverajan-core-coap-alternative-transports Htmlized: http://tools.ietf.org/html/draft-silverajan-core-coap-alternative-transports-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-silverajan-core-coap-alternative-transports-01 Abstract: CoAP is being standardised as an application level REST-based protocol. A single CoAP message is typically encapsulated and transmitted using UDP. This draft examines the requirements and possible solutions for conveying CoAP packets to end points over alternative transports to UDP. While UDP remains an optimal solution for use in IP-based constrained environments and nodes, M2M communication using non-IP networks, NAT and firewall traversal issues and possibly mechanisms incurring a lower overhead to CoAP/ HTTP gateways provide compelling motivation for understanding how CoAP can operate in various other environments. The IETF Secretariat From kovatsch@inf.ethz.ch Thu Feb 28 09:28:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A62821F8BA4 for ; Thu, 28 Feb 2013 09:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAamS6cr+yyV for ; Thu, 28 Feb 2013 09:28:29 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 85C1721F8B8F for ; Thu, 28 Feb 2013 09:28:27 -0800 (PST) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 28 Feb 2013 18:28:18 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.02.0298.004; Thu, 28 Feb 2013 18:28:26 +0100 From: "Kovatsch Matthias" To: core WG Thread-Topic: Quick questionnaire on Web integration Thread-Index: Ac4V1yJJ4ouxI4t4Qiay8ZU/lpIjiQ== Date: Thu, 28 Feb 2013 17:28:25 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514DF1C8D@MBX10.d.ethz.ch> 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: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B514DF1C8DMBX10dethzch_" MIME-Version: 1.0 Subject: [core] Quick questionnaire on Web integration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:28:30 -0000 --_000_55877B3AFB359744BA0F2140E36F52B514DF1C8DMBX10dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear list In the course of my PhD thesis, I created a questionnaire and would be very= happy about your feedback. It is about the interaction with IoT devices an= d how Web integration helps developers and users. The second part is about my Copper (Cu) Firefox add-on, but knowing it is n= ot a requirement for the study. Please help me by filling out this short form: http://goo.gl/xFpCq Thank you very much Matthias PS: I hope as a contributor I do not offend by using the IETF mailing list = for this somewhat personal appeal. --_000_55877B3AFB359744BA0F2140E36F52B514DF1C8DMBX10dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear list

 

In the course of my PhD thesis, I created a quest= ionnaire and would be very happy about your feedback. It is about the inter= action with IoT devices and how Web integration helps developers and users.=

 

The second part is about my Copper (Cu) Firefox a= dd-on, but knowing it is not a requirement for the study.

 

Please help me by filling out this short form:

 

http://goo.gl/xFp= Cq

 

Thank you very much

Matthias

 

PS: I hope as a contributor I do not offend by using= the IETF mailing list for this somewhat personal appeal.

 

--_000_55877B3AFB359744BA0F2140E36F52B514DF1C8DMBX10dethzch_--