From mkomu@cs.hut.fi Sun Jan 1 21:46:22 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9E921F8491; Sun, 1 Jan 2012 21:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y+kXYOavBxw; Sun, 1 Jan 2012 21:46:17 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id E6D1A21F84A9; Sun, 1 Jan 2012 21:46:16 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1Rhair-0002Eq-0n; Mon, 02 Jan 2012 07:46:13 +0200 Message-ID: <4F0144A5.5030101@cs.hut.fi> Date: Mon, 02 Jan 2012 07:46:13 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: =?windows-1252?Q?Ren=E9_Hummen?= References: <04D43087-E2BF-464F-BE5E-D57FC3FFA746@cs.rwth-aachen.de> <4EC15495.3000700@gmail.com> <4EC5B600.1040700@gmail.com> <4EEF5D92.5020503@gmail.com> <02E1CC7E-A9A4-4051-A0FA-7D12E9EF371C@cs.rwth-aachen.de> In-Reply-To: <02E1CC7E-A9A4-4051-A0FA-7D12E9EF371C@cs.rwth-aachen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: hipsec@ietf.org, core Subject: Re: [core] [hiprg] Research topics discussion - meeting suggestion: Wednesday 7:30pm 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, 02 Jan 2012 05:46:22 -0000 Hi, I sent privately a number of references for Struik but here's the most essential ones. Regarding to ease-of-use considerations, and UIA [1] extends HIP-like security to user-level identities. We have also conducted some usability tests with a HIP GUI [2] earlier. Regarding to security, references [3,4] are worth checking out because they have helped to improve the security in HIP. [1] http://www.pdos.lcs.mit.edu/papers/uia:osdi06.pdf [2] Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security Management with Host Identity Protocol, published in The 7th ACS/IEEE International Conference on Computer Systems and Applications (AICCSA-2009) [3] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010. [4] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP Base Exchange Protocol", in Proceedings of 10th Australasian Conference on Information Security and Privacy, July 2003. On 31/12/11 19:04, René Hummen wrote: > Hello René, > > this email contains a few references to papers regarding the security properties and embedding of HIP in today's network environments. > > First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To be exact, it is a derivate of the basic protocol described in Section 5.1, as the HIP BEX is triggered by a separate (empty) message that is not included in the SIGMA protocol family. This allows HIP to perform DoS protection against exhaustive public key-based operations by the responder by means of cryptographic puzzles. Furthermore, the public key (A) of the responder is already sent in the first response message. However, this does not impact the security properties, but rather the anonymity of the responder. > > Regarding the usage of HIP, there is a rather comprehensive journal article [2] that describes the architecture as well as the operation system and infrastructure requirements of HIP. It also provides some pointers to further papers that may be worth reading for you. Additionally, Samu Varjonen recently published a paper on the "Secure Resolution of End-Host Identifiers for Mobile Clients" [3]. However, it seems to be inaccessible at the moment. Still, you may want to refer to it at later point in time, as it describes an approach to resolve HITs to IP addresses. > > I hope that this small selection is helping you in understanding the properties of HIP. I would also like to invite other people to contribute to this discussion, e.g., by providing further references relevant for the CoRE WG. > > Regards, > René > > > [1] Krawczyk, H.; SIGMA: The ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES IN CRYPTOLOGY - CRYPTO 2003 > Lecture Notes in Computer Science, 2003 > [2] Nikander, P.; Gurtov, A.; Henderson, T.R.; Host Identity Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over IPv4 and IPv6 Networks, Communications Surveys& Tutorials, IEEE, 2010 > [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure Resolution of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, 2011 > On 19.12.2011, at 16:51, Rene Struik wrote: > > >> Perhaps, worth some thoughts under the Christmas tree and then getting back on this one after New Year. >> >> On 17/11/2011 8:33 PM, Rene Struik wrote: >>> Hi fellow-Rene: >>> >>> If you have some papers, I would appreciate. Distributing those would also help removing hurdles to more wide-scale use of HIP (I saw the slides on lack of adoption of HIP). >>> >>> Best regards, Rene >>> >>> >>> On 14/11/2011 12:49 PM, Rene Struik wrote: >>>> Hi fellow-Rene: >>>> >>>> Just curious: is there any research paper outside IETF/IRTF realm that delves into HIP-related matter? On a tangent: same question, but now re cryptographically generated addresses? This may help people to appreciate this effort better, without having to delve into hundreds of pages of specification text that sometimes seems to obscure seeing the forest for the trees (if I translate this properly). I, for one, would love to see 2-3 academic papers that make this subject matter clearer, including security properties, ease-of-use considerations. >>>> >>>> Best regards, Rene >>>> >>>> On 14/11/2011 12:38 PM, René Hummen wrote: >>>>> Hello everyone, >>>>> >>>>> we already had a few discussions on this list about new topics and research directions that would foster collaboration within the context of the hiprg. Hierarchical HITs, IoT-related protocol variants, and middlebox awareness have been mentioned there among others. In my opinion, an informal meeting before the hiprg meeting on Thursdays would be a great opportunity to further discuss about these topics. Furthermore, such a meeting would enable us see who is interested in which field and which are the pros and cons of the different topics as perceived by people in a more comfortable and less hurried way than in an RG meeting. >>>>> >>>>> As most of us will probably be at the social event tomorrow evening, I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in order to get some discussion going. Due to the lack of knowledge about a better place, let's meet up at the entrance of the convention center (TICC). Please email me if you are interested. >>>>> >>>>> BR >>>>> René >>>>> >>>>> >>>>> >>>>> -- >>>>> Dipl.-Inform. Rene Hummen, Ph.D. Student >>>>> Chair of Communication and Distributed Systems >>>>> RWTH Aachen University, Germany >>>>> tel: +49 241 80 20772 >>>>> web: >>>>> http://www.comsys.rwth-aachen.de/team/rene-hummen/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> hiprg mailing list >>>>> >>>>> hiprg@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/hiprg >>>> >>>> >>>> -- >>>> email: >>>> rstruik.ext@gmail.com >>>> >>>> Skype: rstruik >>>> cell: +1 (647) 867-5658 >>>> USA Google voice: +1 (415) 690-7363 >>>> >>> >>> >>> -- >>> email: >>> rstruik.ext@gmail.com >>> >>> Skype: rstruik >>> cell: +1 (647) 867-5658 >>> USA Google voice: +1 (415) 690-7363 >>> >> >> >> -- >> email: >> rstruik.ext@gmail.com >> >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >> > > > > > -- > Dipl.-Inform. Rene Hummen, Ph.D. Student > Chair of Communication and Distributed Systems > RWTH Aachen University, Germany > tel: +49 241 80 20772 > web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Mon Jan 2 06:03:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1521F844A for ; Mon, 2 Jan 2012 06:03:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvsOv86dKse0 for ; Mon, 2 Jan 2012 06:03:24 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9278221F8449 for ; Mon, 2 Jan 2012 06:03:23 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q02E3JRD030580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Jan 2012 16:03:19 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jan 2012 16:03:19 +0200 References: <20120102135925.21445.16258.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" Message-Id: <811BA235-D9B6-441B-9212-6F68E7745FEB@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-00.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, 02 Jan 2012 14:03:24 -0000 http://www.ietf.org/id/draft-shelby-core-interfaces-00.txt Here is a new draft that describes a model for REST interface = descriptions for use with the link format, that I have been using in = various contexts for a long time. Now I wanted to start developing this = further in CoRE - please give it a spin in your own server design and = will be glad to hear feedback and ideas.=20 Regards, Zach=20 Begin forwarded message: > From: internet-drafts@ietf.org > Date: January 2, 2012 3:59:25 PM GMT+02:00 > To: zach@sensinode.com > Cc: zach@sensinode.com > Subject: New Version Notification for = draft-shelby-core-interfaces-00.txt >=20 > A new version of I-D, draft-shelby-core-interfaces-00.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-interfaces > Revision: 00 > Title: CoRE Interfaces > Creation date: 2012-01-02 > WG ID: Individual Submission > Number of pages: 11 >=20 > Abstract: > This document defines well-known interface descriptions for Batch, > Sensor, Parameter and Actuator types for use in contrained web > servers using the CoRE Link Format. A short reference is provided > for each type that can be efficiently included in the interface > description attribute of the CoRE Link Format. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Mon Jan 2 08:25:49 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DA621F84DF for ; Mon, 2 Jan 2012 08:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_27=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNIhDlAqCseo for ; Mon, 2 Jan 2012 08:25:48 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9347F21F84DB for ; Mon, 2 Jan 2012 08:25:47 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rhkhk-000237-IY; Mon, 02 Jan 2012 11:25:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 02 Jan 2012 16:25:44 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/180 Message-ID: <057.8012f3a0fe147380d13af23352fc572b@trac.tools.ietf.org> X-Trac-Ticket-ID: 180 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #180: Update ABNF for queries 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, 02 Jan 2012 16:25:49 -0000 #180: Update ABNF for queries Esko's comments on the link-format document got Zach and me thinking about our usage of ptoken again. In link-format-09, the syntax for the queries in the URIs says: filter-query = resource-param "=" query-pattern resource-param = "uri" / parmname query-pattern = ptoken [ "*" ] ptoken = Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, not in a URI. Looking more closely: ptoken = 1*ptokenchar ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "(" | ")" | "*" | "+" | "-" | "." | "/" | DIGIT | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "~" Oops, that actually includes "*" and "&"! There also is no mention of percent-encoding (of course not, because RFC2616 does not percent-encode headers). So what we really want to import here is RFC3986 ABNF, not RFC2616/RFC5988 ABNF. First attempt: query-pattern = search-token [ "*" ] search-token = *pchar But pchar (RFC3986) includes subdelims: pchar = unreserved / pct-encoded / sub-delims / ":" / "@" query = *( pchar / "/" / "?" ) pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" … which includes "*" and "&". So, to do this right, let's mix this properly: query-pattern = search-token [ "*" ] search-token = *search-char search-char = unreserved / pct-encoded / ":" / "@" ; from pchar / "/" / "?" ; from query / "!" / "$" / "'" / "(" / ")" / "+" / "," / ";" / "=" ; from sub-delims :@/?!$'()+,;= indeed. This makes it possible to say something like: GET /.well-known/core?rt=outdoor%20temperature After the percent-decoding defined in core-coap's URI parsing (section 6.4), the server will see: Uri-Path .well-known Uri-Path core Uri-Query rt=outdoor temperature which sounds about right. The parser in the server will now just have to 1) search for the first "=" and use that to delimit the parameter name from the search-token 2) check for a trailing "*" and remove that, if present, indicating a prefix match. Would I use spaces for rt values? Probably not, but there are still good reasons for staying general here. As the percent-decoding is already done when the server sees it, there is no cost to this generality, either. The defnition of query-pattern also needs to be updated. -- -------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: -------------------------+-------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Jan 2 08:35:10 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AD121F88AB for ; Mon, 2 Jan 2012 08:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JM3hvXFmlgzO for ; Mon, 2 Jan 2012 08:35:10 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD2521F8801 for ; Mon, 2 Jan 2012 08:35:10 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rhkqr-0006TU-Ec; Mon, 02 Jan 2012 11:35:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 02 Jan 2012 16:35:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/178#comment:1 Message-ID: <072.105461b4eae0190cd805dc738ca3506f@trac.tools.ietf.org> References: <057.844edd48abdc531fbb6f5bee1c508a7c@trac.tools.ietf.org> X-Trac-Ticket-ID: 178 In-Reply-To: <057.844edd48abdc531fbb6f5bee1c508a7c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #178: Multiple relation types 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, 02 Jan 2012 16:35:11 -0000 #178: Multiple relation types Comment (by zach@…): Done. -- ----------------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Jan 2 08:35:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F7921F8922 for ; Mon, 2 Jan 2012 08:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIdi20TTZRXb for ; Mon, 2 Jan 2012 08:35:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4621F891D for ; Mon, 2 Jan 2012 08:35:20 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rhkr2-00074U-Iv; Mon, 02 Jan 2012 11:35:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 02 Jan 2012 16:35:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/178#comment:2 Message-ID: <072.4005e409bc532bb7ec019ce77702901b@trac.tools.ietf.org> References: <057.844edd48abdc531fbb6f5bee1c508a7c@trac.tools.ietf.org> X-Trac-Ticket-ID: 178 In-Reply-To: <057.844edd48abdc531fbb6f5bee1c508a7c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #178: Multiple relation types 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, 02 Jan 2012 16:35:21 -0000 #178: Multiple relation types Changes (by zach@…): * status: new => closed * resolution: => fixed -- ----------------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Jan 2 08:38:19 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E4A21F893C for ; Mon, 2 Jan 2012 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWGpfEy3OkFq for ; Mon, 2 Jan 2012 08:38:19 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 70ABB21F87FC for ; Mon, 2 Jan 2012 08:38:19 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rhktu-0005m2-Me; Mon, 02 Jan 2012 11:38:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 02 Jan 2012 16:38:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/179#comment:1 Message-ID: <072.d3c156e619554489febdd8581e885291@trac.tools.ietf.org> References: <057.b550ac0ced2490f3acc0108f7b943113@trac.tools.ietf.org> X-Trac-Ticket-ID: 179 In-Reply-To: <057.b550ac0ced2490f3acc0108f7b943113@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #179: SHOULD NOT for multicast response repression 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, 02 Jan 2012 16:38:20 -0000 #179: SHOULD NOT for multicast response repression Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done: "When using a transfer protocol like the Constrained Application Protocol (CoAP) that supports multicast requests, special care is taken. A multicast request with a query string SHOULD NOT be responded to if filtering is not supported or if the filter does not match (to avoid a needless response storm). The exception is in cases where the IP stack interface is not able to indicate that the source address was multicast." -- ----------------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Jan 2 08:41:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FFC21F8A55 for ; Mon, 2 Jan 2012 08:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOtj5dl-YMAA for ; Mon, 2 Jan 2012 08:41:55 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7E521F8A4E for ; Mon, 2 Jan 2012 08:41:55 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RhkxO-0004Mv-Jo; Mon, 02 Jan 2012 11:41:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 02 Jan 2012 16:41:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/180#comment:1 Message-ID: <072.f6c1a206f5058a79e0ec4bd5cb408967@trac.tools.ietf.org> References: <057.8012f3a0fe147380d13af23352fc572b@trac.tools.ietf.org> X-Trac-Ticket-ID: 180 In-Reply-To: <057.8012f3a0fe147380d13af23352fc572b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #180: Update ABNF for queries 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, 02 Jan 2012 16:41:56 -0000 #180: Update ABNF for queries Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done. -- -------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: closed Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------- Ticket URL: core From zach@sensinode.com Mon Jan 2 09:15:32 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8572521F8A67 for ; Mon, 2 Jan 2012 09:15:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FedoyS2Esx2 for ; Mon, 2 Jan 2012 09:15:31 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0E421F8922 for ; Mon, 2 Jan 2012 09:15:30 -0800 (PST) Received: from [192.168.1.104] (87-95-3-112.bb.dnainternet.fi [87.95.3.112]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q02HFPcN022022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jan 2012 19:15:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 2 Jan 2012 19:15:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE4D8F8-046C-4960-9472-336258C4A4EF@tzi.org> <7C52D84C-21C5-4422-A0AF-B265B752F0BF@tzi.org> <609BD48E-4BE6-4964-BC2B-E7301E629BAD@sensinode.com> To: Herbert van de Sompel X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] application/link-format & non CoRE applications 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, 02 Jan 2012 17:15:32 -0000 Herbert, On Dec 15, 2011, at 11:50 PM, Herbert van de Sompel wrote: > 1. Approach that allows using an off-the-shelf Link header parser >=20 > This approach requires that the content of an application/link-format = document fully conforms to the "link-value" production rule of the ABNF = of RFC 5988. As a result, whatever is put in place to implement the = "sticky anchor" will be interpreted as a link.=20 >=20 > My original proposal fits into this category, but probably was = inappropriate because the add-on I proposed looked too much like a = "real" link. Maybe it's better to go for something that conforms to the = syntax of a link but doesn't really make sense as a link, i.e. does not = introduce the risk of applications interpreting it as a "real" link.=20 >=20 > Within this category, we thought the following could work: >=20 > <> ; anchor=3D"the-actual-Context-IRI" , link, link, link, ... This would apply only to that one link. But I actually think you're on = the right trail here. Let's think it through: The Context IRI needs to be assumed somehow. In HTTP Link Header it made = sense that it was the Request URI. In this Link Format we assume it is = the Base URI. Alternatively, this is overridden by the presence of the = "anchor" attribute for a single link. Now we need a way to override the = context for all the links in a document rather than a single one. In my = mind, the right way to do that would be to define a new relation type = "context" and use it to assign a new assumed context for all the links = in the document. So this would look like: ; rel=3D"context", link, link, link, ... Now the trick is that the definition of this "context" relation type = needs to assume a Context URI of that document itself, not a problem if = defined so. I am not sure that the CoRE Link Format is necessarily the right place = to define this new relation type, although I am not against that either. = It might make more sense to define this as a separate draft.=20 > 2. Approach that requires some changes to an off-the-shelf Link header = parser >=20 > In this case, we could go beyond the syntax defined in the ABNF in = order to add the "sticky anchor". Devising a solution then comes down to = finding a verbose syntax that remains easy to parse. The latter includes = deciding on an appropriate delimiter. Understanding Carsten doesn't want = "lines", maybe using e.g. a pipe character "|" as a delimiter could be = an approach: >=20 > | the-actual-Context-IRI | link, link, link, ... >=20 > or, if extensibility regarding metadata to these files would be = required, even: >=20 > | ContextIRI the-Context-IRI | Date the-date | link, link, link, ... This seems like a hack to me, would avoid it. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Wed Jan 4 01:09:34 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F1921F86D1 for ; Wed, 4 Jan 2012 01:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa2ukjZvm8Mh for ; Wed, 4 Jan 2012 01:09:33 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C0A6C21F8654 for ; Wed, 4 Jan 2012 01:09:33 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RiMqg-0002CM-J0; Wed, 04 Jan 2012 04:09:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 04 Jan 2012 09:09:29 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/core/trac/ticket/176#comment:3 Message-ID: <072.1076c5d51809bd80abc5b9edfd36ab0b@trac.tools.ietf.org> References: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #176: Removing 15 option limit (was: Uri-Path and Uri-Query) 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, 04 Jan 2012 09:09:34 -0000 #176: Removing 15 option limit Comment (by zach@…): At IETF82 in Taipei, the WG meeting found consensus on the following solution: When the value of OC is 0b1111 (then a reserved value), then the number of options is unlimited, and an "end-of-options" marker is used to indicate no more options (ob11110000). -- ----------------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Jan 4 01:19:52 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7607B21F86E6 for ; Wed, 4 Jan 2012 01:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrGqZBtJFLEm for ; Wed, 4 Jan 2012 01:19:51 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A88BB21F86CE for ; Wed, 4 Jan 2012 01:19:51 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RiN0g-0007zW-JA; Wed, 04 Jan 2012 04:19:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 04 Jan 2012 09:19:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/181 Message-ID: <057.1dd055576c61f3a0de6e843be86789a4@trac.tools.ietf.org> X-Trac-Ticket-ID: 181 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #181: Content-encoding column 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, 04 Jan 2012 09:19:52 -0000 #181: Content-encoding column In the WG meeting of IETF82 it was discussed that the CoAP media type code table needs to have a column for content-encoding, for such media types that might need that to be specified. Thus a media type code will define both the media type and content-encoding. This ticket is to add this new column to Table 5 in Section 11.3 and describe its use. -- ----------------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------------+-------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Jan 4 01:29:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F8121F8607 for ; Wed, 4 Jan 2012 01:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3QsUXVN2WAQ for ; Wed, 4 Jan 2012 01:29:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 841A321F8600 for ; Wed, 4 Jan 2012 01:29:20 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RiN9n-00037I-U3; Wed, 04 Jan 2012 04:29:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 04 Jan 2012 09:29:15 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/core/trac/ticket/171#comment:1 Message-ID: <072.3618e08cb21d2ba13c5353faf99f2ad9@trac.tools.ietf.org> References: <057.e138be52af7e75e86559cc5a5dfa0423@trac.tools.ietf.org> X-Trac-Ticket-ID: 171 In-Reply-To: <057.e138be52af7e75e86559cc5a5dfa0423@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #171: Merging of Size into Block 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, 04 Jan 2012 09:29:21 -0000 #171: Merging of Size into Block Comment (by zach@…): At the WG meeting at IETF82 in Taipei, it was decided that the Size option should be added to the Block draft from draft-li-core-coap-size-option-02 in particular. -- ----------------------------------+--------------------- Reporter: zach@… | Owner: cabo@… Type: protocol enhancement | Status: new Priority: major | Milestone: Component: block | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------- Ticket URL: core From zach@sensinode.com Wed Jan 4 01:45:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE19F21F8706 for ; Wed, 4 Jan 2012 01:45:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo4-HDNj6VJq for ; Wed, 4 Jan 2012 01:45:25 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id BC44621F8701 for ; Wed, 4 Jan 2012 01:45:24 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q049jMHj001094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 4 Jan 2012 11:45:22 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jan 2012 11:45:21 +0200 Message-Id: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> To: "core@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Moving Observe forward 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, 04 Jan 2012 09:45:26 -0000 I have been going through the IETF82 minutes = (http://tools.ietf.org/wg/core/minutes) and updating tickets etc. The = discussion on the new Max-OFE option that was added to observe-03 is = interesting reading for those of you that were not there. That discussion left me feeling like we were premature in adding this = option to Observe, as it clearly has nothing near WG consensus. I am not = convinced that we even need it at this point. Observe otherwise is in really good shape, and the WG seemed to think in = Taipei that it would be ready for WGLC if this Max-OFE problem would be = taken care of.=20 My proposal would be to dump Max-OFE into a separate personal draft for = future discussion and work, it could be standardized in that or some = other form later. That would leave the Observe WG document ready for = WGLC, but allow continued work on the idea. What do others think? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Wed Jan 4 05:01:47 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB1521F8718 for ; Wed, 4 Jan 2012 05:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-PyCnzzhaDZ for ; Wed, 4 Jan 2012 05:01:46 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id AC65621F8716 for ; Wed, 4 Jan 2012 05:01:46 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RiQTP-0007Jz-KR; Wed, 04 Jan 2012 08:01:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 04 Jan 2012 13:01:42 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/182 Message-ID: <057.eb0bec758d2a33802dc7c2d34316419b@trac.tools.ietf.org> X-Trac-Ticket-ID: 182 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #182: Piggy-backing note 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, 04 Jan 2012 13:01:47 -0000 #182: Piggy-backing note It was brought up in the IETF82 CoAP presentation, that imlpementation issues have been noticed where piggy-backing should have been used to avoid inefficient use of messages. This ticket is to propose some text to provide quality of implementation advice on when to piggy-back responses. Carsten provided the following text: "Implementation note: The _protocol_ leaves the decision whether to piggy-back a response or not (i.e., send a separate response) to the server. The client MUST be prepared to receive either. On the _quality of implementation_ level, there is a strong expectation that servers will implement code to piggy-back whenever possible -- saving resources in the network and both at the client and at the server." Which could be placed at the end of Section 5.2.1. -- -----------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: -----------------------+-------------------- Ticket URL: core From jara@um.es Wed Jan 4 06:23:16 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F0121F8780 for ; Wed, 4 Jan 2012 06:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ohd7OP5i7nU for ; Wed, 4 Jan 2012 06:23:13 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0527F21F8579 for ; Wed, 4 Jan 2012 06:23:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id DE83053606 for ; Wed, 4 Jan 2012 15:23:11 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C2qHCSvAgrnb for ; Wed, 4 Jan 2012 15:23:10 +0100 (CET) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) (Authenticated sender: jara) by xenon11.um.es (Postfix) with ESMTPA id 8CD0D53600 for ; Wed, 4 Jan 2012 15:23:08 +0100 (CET) Received: by laah2 with SMTP id h2so7228748laa.31 for ; Wed, 04 Jan 2012 06:23:07 -0800 (PST) Received: by 10.152.135.105 with SMTP id pr9mr24230352lab.19.1325686987326; Wed, 04 Jan 2012 06:23:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.6.225 with HTTP; Wed, 4 Jan 2012 06:22:26 -0800 (PST) From: Antonio Jara Date: Wed, 4 Jan 2012 15:22:26 +0100 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary=f46d04427156f6859f04b5b48d42 Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-00.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, 04 Jan 2012 14:23:16 -0000 --f46d04427156f6859f04b5b48d42 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Zach, Regarding the integration of sensors/actuator from legacy technologies and protocols which are being adapted to 6LoWPAN/IPv6. For example, in building automation a EIB/KNX device or X10 device, which is integrated in a gateway to be enabled/powered with CoAP and IPv6 access. The description of this interfaces in the gateway for the DNS-SD could be core#x10_s or something like that. Or this specification of the technology is more focused on the "resource type" parameter that in the "interface" one. Best regards, thanks so much, and happy 2012!, Antonio Jara On Mon, Jan 2, 2012 at 5:41 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/core > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send core mailing list submissions to > core@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/core > or, via email, send a message with subject or body 'help' to > core-request@ietf.org > > You can reach the person managing the list at > core-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core digest..." > > Today's Topics: > > 1. Re: [hiprg] Research topics discussion - meeting suggestion: > Wednesday 7:30pm (Miika Komu) > 2. Fwd: New Version Notification for > draft-shelby-core-interfaces-00.txt (Zach Shelby) > 3. #180: Update ABNF for queries (core issue tracker) > 4. Re: #178: Multiple relation types (core issue tracker) > 5. Re: #178: Multiple relation types (core issue tracker) > 6. Re: #179: SHOULD NOT for multicast response repression > (core issue tracker) > 7. Re: #180: Update ABNF for queries (core issue tracker) > > > ---------- Forwarded message ---------- > From: Miika Komu > To: "Ren=E9 Hummen" > Cc: hipsec@ietf.org, core > Date: Mon, 02 Jan 2012 07:46:13 +0200 > Subject: Re: [core] [hiprg] Research topics discussion - meeting > suggestion: Wednesday 7:30pm > Hi, > > I sent privately a number of references for Struik but here's the most > essential ones. Regarding to ease-of-use considerations, and UIA [1] > extends HIP-like security to user-level identities. We have also conducte= d > some usability tests with a HIP GUI [2] earlier. > > Regarding to security, references [3,4] are worth checking out because > they have helped to improve the security in HIP. > > [1] http://www.pdos.lcs.mit.edu/**papers/uia:osdi06.pdf > > [2] Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security > Management with Host Identity Protocol, published in The 7th ACS/IEEE > International Conference on Computer Systems and Applications (AICCSA-200= 9) > > [3] Krawczyk, H. and P. Eronen, "HMAC-based > Extract-and-Expand Key Derivation > Function (HKDF)", RFC 5869, May 2010. > > [4] Aura, T., Nagarajan, A., and A. Gurtov, > "Analysis of the HIP Base Exchange > Protocol", in Proceedings of 10th > Australasian Conference on Information > Security and Privacy, July 2003. > > On 31/12/11 19:04, Ren=E9 Hummen wrote: > >> Hello Ren=E9, >> >> this email contains a few references to papers regarding the security >> properties and embedding of HIP in today's network environments. >> >> First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To be >> exact, it is a derivate of the basic protocol described in Section 5.1, = as >> the HIP BEX is triggered by a separate (empty) message that is not inclu= ded >> in the SIGMA protocol family. This allows HIP to perform DoS protection >> against exhaustive public key-based operations by the responder by means= of >> cryptographic puzzles. Furthermore, the public key (A) of the responder = is >> already sent in the first response message. However, this does not impac= t >> the security properties, but rather the anonymity of the responder. >> >> Regarding the usage of HIP, there is a rather comprehensive journal >> article [2] that describes the architecture as well as the operation sys= tem >> and infrastructure requirements of HIP. It also provides some pointers t= o >> further papers that may be worth reading for you. Additionally, Samu >> Varjonen recently published a paper on the "Secure Resolution of End-Hos= t >> Identifiers for Mobile Clients" [3]. However, it seems to be inaccessibl= e >> at the moment. Still, you may want to refer to it at later point in time= , >> as it describes an approach to resolve HITs to IP addresses. >> >> I hope that this small selection is helping you in understanding the >> properties of HIP. I would also like to invite other people to contribut= e >> to this discussion, e.g., by providing further references relevant for t= he >> CoRE WG. >> >> Regards, >> Ren=E9 >> >> >> [1] Krawczyk, H.; SIGMA: The =91SIGn-and-MAc=92 Approach to Authenticate= d >> Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES IN CRYPTOLOGY = - >> CRYPTO 2003 >> Lecture Notes in Computer Science, 2003 >> [2] Nikander, P.; Gurtov, A.; Henderson, T.R.; Host Identity Protoco= l >> (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over >> IPv4 and IPv6 Networks, Communications Surveys& Tutorials, IEEE, 2010 >> [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure Resolution >> of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, 2011 >> On 19.12.2011, at 16:51, Rene Struik wrote: >> >> >> Perhaps, worth some thoughts under the Christmas tree and then getting >>> back on this one after New Year. >>> >>> On 17/11/2011 8:33 PM, Rene Struik wrote: >>> >>>> Hi fellow-Rene: >>>> >>>> If you have some papers, I would appreciate. Distributing those would >>>> also help removing hurdles to more wide-scale use of HIP (I saw the sl= ides >>>> on lack of adoption of HIP). >>>> >>>> Best regards, Rene >>>> >>>> >>>> On 14/11/2011 12:49 PM, Rene Struik wrote: >>>> >>>>> Hi fellow-Rene: >>>>> >>>>> Just curious: is there any research paper outside IETF/IRTF realm tha= t >>>>> delves into HIP-related matter? On a tangent: same question, but now = re >>>>> cryptographically generated addresses? This may help people to apprec= iate >>>>> this effort better, without having to delve into hundreds of pages of >>>>> specification text that sometimes seems to obscure seeing the forest = for >>>>> the trees (if I translate this properly). I, for one, would love to s= ee 2-3 >>>>> academic papers that make this subject matter clearer, including secu= rity >>>>> properties, ease-of-use considerations. >>>>> >>>>> Best regards, Rene >>>>> >>>>> On 14/11/2011 12:38 PM, Ren=E9 Hummen wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> we already had a few discussions on this list about new topics and >>>>>> research directions that would foster collaboration within the conte= xt of >>>>>> the hiprg. Hierarchical HITs, IoT-related protocol variants, and mid= dlebox >>>>>> awareness have been mentioned there among others. In my opinion, an >>>>>> informal meeting before the hiprg meeting on Thursdays would be a gr= eat >>>>>> opportunity to further discuss about these topics. Furthermore, such= a >>>>>> meeting would enable us see who is interested in which field and whi= ch are >>>>>> the pros and cons of the different topics as perceived by people in = a more >>>>>> comfortable and less hurried way than in an RG meeting. >>>>>> >>>>>> As most of us will probably be at the social event tomorrow evening, >>>>>> I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm = in >>>>>> order to get some discussion going. Due to the lack of knowledge abo= ut a >>>>>> better place, let's meet up at the entrance of the convention center >>>>>> (TICC). Please email me if you are interested. >>>>>> >>>>>> BR >>>>>> Ren=E9 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dipl.-Inform. Rene Hummen, Ph.D. Student >>>>>> Chair of Communication and Distributed Systems >>>>>> RWTH Aachen University, Germany >>>>>> tel: +49 241 80 20772 >>>>>> web: >>>>>> http://www.comsys.rwth-aachen.**de/team/rene-hummen/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> hiprg mailing list >>>>>> >>>>>> hiprg@irtf.org >>>>>> https://www.irtf.org/mailman/**listinfo/hiprg >>>>>> >>>>> >>>>> >>>>> -- >>>>> email: >>>>> rstruik.ext@gmail.com >>>>> >>>>> Skype: rstruik >>>>> cell: +1 (647) 867-5658 >>>>> USA Google voice: +1 (415) 690-7363 >>>>> >>>>> >>>> >>>> -- >>>> email: >>>> rstruik.ext@gmail.com >>>> >>>> Skype: rstruik >>>> cell: +1 (647) 867-5658 >>>> USA Google voice: +1 (415) 690-7363 >>>> >>>> >>> >>> -- >>> email: >>> rstruik.ext@gmail.com >>> >>> Skype: rstruik >>> cell: +1 (647) 867-5658 >>> USA Google voice: +1 (415) 690-7363 >>> >>> >> >> >> >> -- >> Dipl.-Inform. Rene Hummen, Ph.D. Student >> Chair of Communication and Distributed Systems >> RWTH Aachen University, Germany >> tel: +49 241 80 20772 >> web: http://www.comsys.rwth-aachen.**de/team/rene-hummen/ >> >> >> >> >> ______________________________**_________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/**listinfo/core >> > > > > > ---------- Forwarded message ---------- > From: Zach Shelby > To: "core@ietf.org WG" > Cc: > Date: Mon, 2 Jan 2012 16:03:19 +0200 > Subject: [core] Fwd: New Version Notification for > draft-shelby-core-interfaces-00.txt > http://www.ietf.org/id/draft-shelby-core-interfaces-00.txt > > Here is a new draft that describes a model for REST interface description= s > for use with the link format, that I have been using in various contexts > for a long time. Now I wanted to start developing this further in CoRE - > please give it a spin in your own server design and will be glad to hear > feedback and ideas. > > Regards, > Zach > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Date: January 2, 2012 3:59:25 PM GMT+02:00 > > To: zach@sensinode.com > > Cc: zach@sensinode.com > > Subject: New Version Notification for draft-shelby-core-interfaces-00.t= xt > > > > A new version of I-D, draft-shelby-core-interfaces-00.txt has been > successfully submitted by Zach Shelby and posted to the IETF repository. > > > > Filename: draft-shelby-core-interfaces > > Revision: 00 > > Title: CoRE Interfaces > > Creation date: 2012-01-02 > > WG ID: Individual Submission > > Number of pages: 11 > > > > Abstract: > > This document defines well-known interface descriptions for Batch, > > Sensor, Parameter and Actuator types for use in contrained web > > servers using the CoRE Link Format. A short reference is provided > > for each type that can be efficiently included in the interface > > description attribute of the CoRE Link Format. > > > > > > > > > > The IETF Secretariat > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:25:44 -0000 > Subject: [core] #180: Update ABNF for queries > #180: Update ABNF for queries > > Esko's comments on the link-format document got Zach and me thinking abo= ut > our usage of ptoken again. > > In link-format-09, the syntax for the queries in the URIs says: > > filter-query =3D resource-param "=3D" query-pattern > resource-param =3D "uri" / parmname > query-pattern =3D ptoken [ "*" ] > ptoken =3D > > Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, no= t > in a URI. > Looking more closely: > > ptoken =3D 1*ptokenchar > ptokenchar =3D "!" | "#" | "$" | "%" | "&" | "'" | "(" > | ")" | "*" | "+" | "-" | "." | "/" | DIGIT > | ":" | "<" | "=3D" | ">" | "?" | "@" | ALPHA > | "[" | "]" | "^" | "_" | "`" | "{" | "|" > | "}" | "~" > > Oops, that actually includes "*" and "&"! > There also is no mention of percent-encoding (of course not, because > RFC2616 does not percent-encode headers). > > So what we really want to import here is RFC3986 ABNF, not RFC2616/RFC59= 88 > ABNF. > > First attempt: > > query-pattern =3D search-token [ "*" ] > search-token =3D *pchar > > But pchar (RFC3986) includes subdelims: > > pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" > > query =3D *( pchar / "/" / "?" ) > > pct-encoded =3D "%" HEXDIG HEXDIG > unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" > sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=3D" > > =85 which includes "*" and "&". > > So, to do this right, let's mix this properly: > > query-pattern =3D search-token [ "*" ] > search-token =3D *search-char > search-char =3D unreserved / pct-encoded > / ":" / "@" ; from pchar > / "/" / "?" ; from query > / "!" / "$" / "'" / "(" / ")" > / "+" / "," / ";" / "=3D" ; from sub-delims > > > :@/?!$'()+,;=3D indeed. > > > This makes it possible to say something like: > > GET /.well-known/core?rt=3Doutdoor%20temperature > > After the percent-decoding defined in core-coap's URI parsing (section > 6.4), the server will see: > > Uri-Path .well-known > Uri-Path core > Uri-Query rt=3Doutdoor temperature > > which sounds about right. > > The parser in the server will now just have to > 1) search for the first "=3D" and use that to delimit the parameter name > from the search-token > 2) check for a trailing "*" and remove that, if present, indicating a > prefix match. > > Would I use spaces for rt values? Probably not, but there are still goo= d > reasons for staying general here. > As the percent-decoding is already done when the server sees it, there i= s > no cost to this generality, either. > > The defnition of query-pattern also needs to be updated. > > -- > -------------------------+-------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: editorial | Status: new > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Keywords: > -------------------------+-------------------- > > Ticket URL: > core > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:35:09 -0000 > Subject: Re: [core] #178: Multiple relation types > #178: Multiple relation types > > > Comment (by zach@=85): > > Done. > > -- > ----------------------------------+--------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: protocol enhancement | Status: new > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: > Keywords: | > ----------------------------------+--------------------- > > Ticket URL: > core > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:35:20 -0000 > Subject: Re: [core] #178: Multiple relation types > #178: Multiple relation types > > Changes (by zach@=85): > > * status: new =3D> closed > * resolution: =3D> fixed > > > -- > ----------------------------------+--------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: protocol enhancement | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > ----------------------------------+--------------------- > > Ticket URL: > core > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:38:18 -0000 > Subject: Re: [core] #179: SHOULD NOT for multicast response repression > #179: SHOULD NOT for multicast response repression > > Changes (by zach@=85): > > * status: new =3D> closed > * resolution: =3D> fixed > > > Comment: > > Done: > > "When using a transfer protocol like the Constrained Application Protoco= l > (CoAP) that supports multicast requests, special care is taken. A > multicast request with a query string SHOULD NOT be responded to if > filtering is not supported or if the filter does not match (to avoid a > needless response storm). The exception is in cases where the IP stack > interface is not able to indicate that the source address was multicast.= " > > -- > ----------------------------------+--------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: protocol enhancement | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > ----------------------------------+--------------------- > > Ticket URL: > core > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:41:54 -0000 > Subject: Re: [core] #180: Update ABNF for queries > #180: Update ABNF for queries > > Changes (by zach@=85): > > * status: new =3D> closed > * resolution: =3D> fixed > > > Comment: > > Done. > > -- > -------------------------+--------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: editorial | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > -------------------------+--------------------- > > Ticket URL: > core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --f46d04427156f6859f04b5b48d42 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Zach,

Regarding the integration of sensors/actuator f= rom legacy technologies and protocols which are being adapted to 6LoWPAN/IP= v6. For example, in building automation a EIB/KNX device or X10 device, whi= ch is integrated in a gateway to be enabled/powered with CoAP and IPv6 acce= ss.

The description of this interfaces in the gateway for t= he DNS-SD could be core#x10_s or something like that. Or this specification= of the technology is more focused on the "resource type" paramet= er that in the "interface" one.

Best regards, thanks so much, and happy 2012!,
Antonio Jara

On Mon, Jan 2, 2012 at 5:4= 1 PM, <core-= request@ietf.org> wrote:
If you have received this digest without all= the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send core mailing list submissions to
=A0 =A0 =A0 =A0core@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/core
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0core-request@ietf.= org

You can reach the person managing the list at
=A0 =A0 =A0 =A0core-owner@ietf.org<= /a>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of core digest..."

Today's Topics:

=A0 1. Re: [hiprg] Research topics discussion - meeting suggestion:
=A0 =A0 =A0Wednesday 7:30pm (Miika Komu)
=A0 2. Fwd: New Version Notification for
=A0 =A0 =A0draft-shelby-core-interfaces-00.txt (Zach Shelby)
=A0 3. =A0#180: Update ABNF for queries (core issue tracker)
=A0 4. Re: #178: Multiple relation types (core issue tracker)
=A0 5. Re: #178: Multiple relation types (core issue tracker)
=A0 6. Re: #179: SHOULD NOT for multicast response repression
=A0 =A0 =A0(core issue tracker)
=A0 7. Re: #180: Update ABNF for queries (core issue tracker)


---------- Forwarded message ----------
From:=A0Miika Komu <<= a href=3D"mailto:mkomu@cs.hut.fi">mkomu@cs.hut.fi>
To:=A0"Re= n=E9 Hummen" <rene= .hummen@cs.rwth-aachen.de>
Cc:=A0hipsec@ietf.org, core <core@ietf.org>
Date:=A0Mon, 02 Jan 2= 012 07:46:13 +0200
Subject:=A0Re: [core] [hiprg] Research topics discuss= ion - meeting suggestion: Wednesday 7:30pm
Hi,

I sent privately a number of references for Struik but here's the most = essential ones. Regarding to ease-of-use considerations, and UIA [1] extend= s HIP-like security to user-level identities. We have also conducted some u= sability tests with a HIP GUI [2] earlier.

Regarding to security, references [3,4] are worth checking out because they= have helped to improve the security in HIP.

[1] http://www.pdos.lcs.mit.edu/papers/uia:osdi06.pdf

[2] Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security Manag= ement with Host Identity Protocol, published in The 7th ACS/IEEE Internatio= nal Conference on Computer Systems and Applications (AICCSA-2009)

[3] Krawczyk, H. and P. Eronen, "HMAC-based
Extract-and-Expand Key Derivation
Function (HKDF)", RFC 5869, May 2010.

[4] Aura, T., Nagarajan, A., and A. Gurtov,
"Analysis of the HIP Base Exchange
Protocol", in Proceedings of 10th
Australasian Conference on Information
Security and Privacy, July 2003.

On 31/12/11 19:04, Ren=E9 Hummen wrote:
Hello Ren=E9,

this email contains a few references to papers regarding the security prope= rties and embedding of HIP in today's network environments.

First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To be exa= ct, it is a derivate of the basic protocol described in Section 5.1, as the= HIP BEX is triggered by a separate (empty) message that is not included in= the SIGMA protocol family. This allows HIP to perform DoS protection again= st exhaustive public key-based operations by the responder by means of cryp= tographic puzzles. Furthermore, the public key (A) of the responder is alre= ady sent in the first response message. However, this does not impact the s= ecurity properties, but rather the anonymity of the responder.

Regarding the usage of HIP, there is a rather comprehensive journal article= [2] that describes the architecture as well as the operation system and in= frastructure requirements of HIP. It also provides some pointers to further= papers that may be worth reading for you. Additionally, Samu Varjonen rece= ntly published a paper on the "Secure Resolution of End-Host Identifie= rs for Mobile Clients" [3]. However, it seems to be inaccessible at th= e moment. Still, you may want to refer to it at later point in time, as it = describes an approach to resolve HITs to IP addresses.

I hope that this small selection is helping you in understanding the proper= ties of HIP. I would also like to invite other people to contribute to this= discussion, e.g., by providing further references relevant for the CoRE WG= .

Regards,
Ren=E9


[1] Krawczyk, H.; SIGMA: The =91SIGn-and-MAc=92 Approach to Authenticated D= iffie-Hellman and Its Use in the IKE Protocols, ADVANCES IN CRYPTOLOGY - CR= YPTO 2003
Lecture Notes in Computer Science, 2003
[2] Nikander, P.; =A0 Gurtov, A.; =A0 Henderson, T.R.; Host Identity Protoc= ol (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over = IPv4 and IPv6 Networks, Communications Surveys& =A0Tutorials, IEEE, 201= 0
[3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure Resolution of= End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, 2011
On 19.12.2011, at 16:51, Rene Struik wrote:


Perhaps, worth some thoughts under the Christmas tree and then getting back= on this one after New Year.

On 17/11/2011 8:33 PM, Rene Struik wrote:
Hi fellow-Rene:

If you have some papers, I would appreciate. Distributing those would also = help removing hurdles to more wide-scale use of HIP (I saw the slides on la= ck of adoption of HIP).

Best regards, Rene


On 14/11/2011 12:49 PM, Rene Struik wrote:
Hi fellow-Rene:

Just curious: is there any research paper outside IETF/IRTF realm that delv= es into HIP-related matter? On a tangent: same question, but now re cryptog= raphically generated addresses? This may help people to appreciate this eff= ort better, without having to delve into hundreds of pages of specification= text that sometimes seems to obscure seeing the forest for the trees (if I= translate this properly). I, for one, would love to see 2-3 academic paper= s that make this subject matter clearer, including security properties, eas= e-of-use considerations.

Best regards, Rene

On 14/11/2011 12:38 PM, Ren=E9 Hummen wrote:
Hello everyone,

we already had a few discussions on this list about new topics and research= directions that would foster collaboration within the context of the hiprg= . Hierarchical HITs, IoT-related protocol variants, and middlebox awareness= have been mentioned there among others. In my opinion, an informal meeting= before the hiprg meeting on Thursdays would be a great opportunity to furt= her discuss about these topics. Furthermore, such a meeting would enable us= see who is interested in which field and which are the pros and cons of th= e different topics as perceived by people in a more comfortable and less hu= rried way than in an RG meeting.

As most of us will probably be at the social event tomorrow evening, I sugg= est to meet for dinner/a drink on Wednesday evening at 7:30pm in order to g= et some discussion going. Due to the lack of knowledge about a better place= , let's meet up at the entrance of the convention center (TICC). Please= email me if you are interested.

BR
Ren=E9



--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web:
http://www.comsys.rwth-aachen.de/team/rene-hummen/





_______________________________________________
hiprg mailing list

hiprg@irtf.org
h= ttps://www.irtf.org/mailman/listinfo/hiprg


--
email:
rstruik.ext@gmai= l.com

Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363



--
email:
rstruik.ext@gmai= l.com

Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363



--
email:
rstruik.ext@gmai= l.com

Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363





--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/



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




---------- Forwarded message ----------
From:=A0Zach Shelby <= zach@sensinode.com>
To:=A0&= quot;core@ietf.org WG" <core@ietf.org>
Cc:=A0
Date:=A0Mon, 2 Jan 2012 16:03:19 +0200
Subject:=A0[core] Fwd: = New Version Notification for draft-shelby-core-interfaces-00.txt
http://www.ietf.org/id/draft-shelby-core-interfaces-00.txt

Here is a new draft that describes a model for REST interface descriptions = for use with the link format, that I have been using in various contexts fo= r a long time. Now I wanted to start developing this further in CoRE - plea= se give it a spin in your own server design and will be glad to hear feedba= ck and ideas.

Regards,
Zach

Begin forwarded message:

> From: internet-drafts@ietf= .org
> Date: January 2, 2012 3:59:25 PM GMT+02:00
> To: zach@sensinode.com
> Cc: zach@sensinode.com
> Subject: New Version Notification for draft-shelby-core-interfaces-00.= txt
>
> A new version of I-D, draft-shelby-core-interfaces-00.txt has been suc= cessfully submitted by Zach Shelby and posted to the IETF repository.
>
> Filename: =A0 =A0 =A0draft-shelby-core-interfaces
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CoRE Interfaces
> Creation date: =A0 =A0 =A0 =A0 2012-01-02
> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 11
>
> Abstract:
> =A0 This document defines well-known interface descriptions for Batch,=
> =A0 Sensor, Parameter and Actuator types for use in contrained web
> =A0 servers using the CoRE Link Format. =A0A short reference is provid= ed
> =A0 for each type that can be efficiently included in the interface > =A0 description attribute of the CoRE Link Format.
>
>
>
>
> The IETF Secretariat

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




---------- Forwarded message ----------
From:=A0"core issue= tracker" <trac+= core@trac.tools.ietf.org>
To:=A0zach@sensinode.com
Cc:=A0core@ietf.org
Date:=A0Mon, 02= Jan 2012 16:25:44 -0000
Subject:=A0[core] #180: Update ABNF for querie= s
#180: Update ABNF for queries

=A0Esko's comments on the link-format document got Zach and me thinking= about
=A0our usage of ptoken again.

=A0In link-format-09, the syntax for the queries in the URIs says:

=A0 =A0 =A0 =A0filter-query =3D resource-param "=3D" query-patte= rn
=A0 =A0 =A0 =A0resource-param =3D "uri" / parmname
=A0 =A0 =A0 =A0query-pattern =3D ptoken [ "*" ]
=A0 =A0 =A0 =A0ptoken =3D <Defined in RFC5988>

=A0Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, no= t
=A0in a URI.
=A0Looking more closely:

=A0ptoken =A0 =A0 =A0 =A0 =3D 1*ptokenchar
=A0ptokenchar =A0 =A0 =3D "!" | "#" | "$" | = "%" | "&" | "'" | "("
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ")" | "*" | "+&= quot; | "-" | "." | "/" | DIGIT
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ":" | "<" | "= ;=3D" | ">" | "?" | "@" | ALPHA
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "[" | "]" | "^&= quot; | "_" | "`" | "{" | "|"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "}" | "~"

=A0Oops, that actually includes "*" and "&"!
=A0There also is no mention of percent-encoding (of course not, because
=A0RFC2616 does not percent-encode headers).

=A0So what we really want to import here is RFC3986 ABNF, not RFC2616/RFC59= 88
=A0ABNF.

=A0First attempt:

=A0 =A0 =A0 =A0query-pattern =3D search-token [ "*" ]
=A0 =A0 =A0 =A0search-token =3D *pchar

=A0But pchar (RFC3986) includes subdelims:

=A0 pchar =A0 =A0 =A0 =A0 =3D unreserved / pct-encoded / sub-delims / &quo= t;:" / "@"

=A0 query =A0 =A0 =A0 =A0 =3D *( pchar / "/" / "?" )
=A0 pct-encoded =A0 =3D "%" HEXDIG HEXDIG
=A0 unreserved =A0 =A0=3D ALPHA / DIGIT / "-" / "." / = "_" / "~"
=A0 sub-delims =A0 =A0=3D "!" / "$" / "&"= ; / "'" / "(" / ")"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "*" / "+" / ",&= quot; / ";" / "=3D"

=A0=85 which includes "*" and "&".

=A0So, to do this right, let's mix this properly:

=A0 =A0 =A0 =A0query-pattern =3D search-token [ "*" ]
=A0 =A0 =A0 =A0search-token =3D *search-char
=A0 =A0 =A0 =A0search-char =3D unreserved / pct-encoded
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ ":" / "@" =A0= ; from pchar
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ "/" / "?" =A0= ; from query
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ "!" / "$" / &= quot;'" / "(" / ")"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ "+" / "," / &= quot;;" / "=3D" =A0; from sub-delims


=A0:@/?!$'()+,;=3D indeed.


=A0This makes it possible to say something like:

=A0GET /.well-known/core?rt=3Doutdoor%20temperature

=A0After the percent-decoding defined in core-coap's URI parsing (secti= on
=A06.4), the server will see:

=A0Uri-Path =A0.well-known
=A0Uri-Path =A0core
=A0Uri-Query rt=3Doutdoor temperature

=A0which sounds about right.

=A0The parser in the server will now just have to
=A01) search for the first "=3D" and use that to delimit the para= meter name
=A0from the search-token
=A02) check for a trailing "*" and remove that, if present, indic= ating a
=A0prefix match.

=A0Would I use spaces for rt values? =A0Probably not, but there are still g= ood
=A0reasons for staying general here.
=A0As the percent-decoding is already done when the server sees it, there i= s
=A0no cost to this generality, either.

=A0The defnition of query-pattern also needs to be updated.

--
-------------------------+--------------------
=A0Reporter: =A0zach@=85 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0zach@=85
=A0 =A0 Type: =A0editorial =A0 =A0| =A0 =A0 Status: =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0Milestone:
Component: =A0link-format =A0| =A0 =A0Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
-------------------------+--------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/180>
core <http://t= ools.ietf.org/core/>




---------- Forwarded message ----------
From:=A0"core issue= tracker" <trac+= core@trac.tools.ietf.org>
To:=A0zach@sensinode.com
Cc:=A0core@ietf.org
Date:=A0Mon, 02= Jan 2012 16:35:09 -0000
Subject:=A0Re: [core] #178: Multiple relation t= ypes
#178: Multiple relation types


Comment (by zach@=85):

=A0Done.

--
----------------------------------+---------------------
=A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner= : =A0zach@=85
=A0 =A0 Type: =A0protocol enhancement =A0| =A0 =A0 =A0Status: =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0link-format =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Resolution:<= br> =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/tic= ket/178#comment:1>
core <http://t= ools.ietf.org/core/>




---------- Forwarded message ----------
From:=A0"core issue= tracker" <trac+= core@trac.tools.ietf.org>
To:=A0zach@sensinode.com
Cc:=A0core@ietf.org
Date:=A0Mon, 02= Jan 2012 16:35:20 -0000
Subject:=A0Re: [core] #178: Multiple relation t= ypes
#178: Multiple relation types

Changes (by zach@=85):

=A0* status: =A0new =3D> closed
=A0* resolution: =A0 =3D> fixed


--
----------------------------------+---------------------
=A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner= : =A0zach@=85
=A0 =A0 Type: =A0protocol enhancement =A0| =A0 =A0 =A0Status: =A0closed =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0link-format =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Resolution: = =A0fixed
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/tic= ket/178#comment:2>
core <http://t= ools.ietf.org/core/>




---------- Forwarded message ----------
From:=A0"core issue= tracker" <trac+= core@trac.tools.ietf.org>
To:=A0zach@sensinode.com
Cc:=A0core@ietf.org
Date:=A0Mon, 02= Jan 2012 16:38:18 -0000
Subject:=A0Re: [core] #179: SHOULD NOT for mult= icast response repression
#179: SHOULD NOT for multicast response repres= sion

Changes (by zach@=85):

=A0* status: =A0new =3D> closed
=A0* resolution: =A0 =3D> fixed


Comment:

=A0Done:

=A0"When using a transfer protocol like the Constrained Application Pr= otocol
=A0(CoAP) that supports multicast requests, special care is taken. A
=A0multicast request with a query string SHOULD NOT be responded to if
=A0filtering is not supported or if the filter does not match (to avoid a =A0needless response storm). The exception is in cases where the IP stack =A0interface is not able to indicate that the source address was multicast.= "

--
----------------------------------+---------------------
=A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner= : =A0zach@=85
=A0 =A0 Type: =A0protocol enhancement =A0| =A0 =A0 =A0Status: =A0closed =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0link-format =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Resolution: = =A0fixed
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/tic= ket/179#comment:1>
core <http://t= ools.ietf.org/core/>




---------- Forwarded message ----------
From:=A0"core issue= tracker" <trac+= core@trac.tools.ietf.org>
To:=A0zach@sensinode.com
Cc:=A0core@ietf.org
Date:=A0Mon, 02= Jan 2012 16:41:54 -0000
Subject:=A0Re: [core] #180: Update ABNF for que= ries
#180: Update ABNF for queries

Changes (by zach@=85):

=A0* status: =A0new =3D> closed
=A0* resolution: =A0 =3D> fixed


Comment:

=A0Done.

--
-------------------------+---------------------
=A0Reporter: =A0zach@=85 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0zach@=85
=A0 =A0 Type: =A0editorial =A0 =A0| =A0 =A0 =A0Status: =A0closed
=A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0 Milestone:
Component: =A0link-format =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution: =A0fixed
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/tic= ket/180#comment:1>
core <http://t= ools.ietf.org/core/>



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


--f46d04427156f6859f04b5b48d42-- From likepeng@huawei.com Wed Jan 4 16:33:13 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2B1F0C53 for ; Wed, 4 Jan 2012 16:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 tagged_above=-999 required=5 tests=[AWL=-1.621, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWU7ESllzAN9 for ; Wed, 4 Jan 2012 16:33:13 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D17131F0C3B for ; Wed, 4 Jan 2012 16:33:12 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXA00F7SUV65Z@szxga04-in.huawei.com> for core@ietf.org; Thu, 05 Jan 2012 08:33:07 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXA001N1UV6CI@szxga04-in.huawei.com> for core@ietf.org; Thu, 05 Jan 2012 08:33:06 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGE69273; Thu, 05 Jan 2012 08:33:06 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 08:33:00 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Thu, 05 Jan 2012 08:32:56 +0800 Date: Thu, 05 Jan 2012 00:32:56 +0000 From: Likepeng In-reply-to: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> X-Originating-IP: [10.70.109.53] To: Zach Shelby , "core@ietf.org WG" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D4F02D@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] Moving Observe forward Thread-index: AQHMysWeb/WeBzuqk0CkyDPqHAK6FpX87UOQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> Subject: Re: [core] Moving Observe forward 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, 05 Jan 2012 00:33:13 -0000 PiBNeSBwcm9wb3NhbCB3b3VsZCBiZSB0byBkdW1wIE1heC1PRkUgaW50byBhIHNlcGFyYXRlIHBl cnNvbmFsIGRyYWZ0IGZvciBmdXR1cmUgZGlzY3Vzc2lvbiBhbmQgd29yaywgaXQgY291bGQgYmUg c3RhbmRhcmRpemVkIGluIHRoYXQgb3Igc29tZSBvdGhlciBmb3JtIGxhdGVyLiBUaGF0IHdvdWxk IGxlYXZlIHRoZSBPYnNlcnZlIFdHIGRvY3VtZW50IHJlYWR5IGZvciBXR0xDLCBidXQgYWxsb3cg Y29udGludWVkIHdvcmsgb24gdGhlIGlkZWEuDQoNCisxLg0KDQpNYXliZSBpdCBjYW4gYmUgbW92 ZWQgdG8gbWlzYyBkcmFmdC4NCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCi0tLS0t08q8/tStvP4t LS0tLQ0Kt6K8/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gWmFjaCBTaGVsYnkNCreiy83KsbzkOiAyMDEyxOox1MI0yNUgMTc6NDUN CsrVvP7IyzogY29yZUBpZXRmLm9yZyBXRw0K1vfM4jogW2NvcmVdIE1vdmluZyBPYnNlcnZlIGZv cndhcmQNCg0KSSBoYXZlIGJlZW4gZ29pbmcgdGhyb3VnaCB0aGUgSUVURjgyIG1pbnV0ZXMgKGh0 dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jb3JlL21pbnV0ZXMpIGFuZCB1cGRhdGluZyB0aWNrZXRz IGV0Yy4gVGhlIGRpc2N1c3Npb24gb24gdGhlIG5ldyBNYXgtT0ZFIG9wdGlvbiB0aGF0IHdhcyBh ZGRlZCB0byBvYnNlcnZlLTAzIGlzIGludGVyZXN0aW5nIHJlYWRpbmcgZm9yIHRob3NlIG9mIHlv dSB0aGF0IHdlcmUgbm90IHRoZXJlLg0KDQpUaGF0IGRpc2N1c3Npb24gbGVmdCBtZSBmZWVsaW5n IGxpa2Ugd2Ugd2VyZSBwcmVtYXR1cmUgaW4gYWRkaW5nIHRoaXMgb3B0aW9uIHRvIE9ic2VydmUs IGFzIGl0IGNsZWFybHkgaGFzIG5vdGhpbmcgbmVhciBXRyBjb25zZW5zdXMuIEkgYW0gbm90IGNv bnZpbmNlZCB0aGF0IHdlIGV2ZW4gbmVlZCBpdCBhdCB0aGlzIHBvaW50Lg0KDQpPYnNlcnZlIG90 aGVyd2lzZSBpcyBpbiByZWFsbHkgZ29vZCBzaGFwZSwgYW5kIHRoZSBXRyBzZWVtZWQgdG8gdGhp bmsgaW4gVGFpcGVpIHRoYXQgaXQgd291bGQgYmUgcmVhZHkgZm9yIFdHTEMgaWYgdGhpcyBNYXgt T0ZFIHByb2JsZW0gd291bGQgYmUgdGFrZW4gY2FyZSBvZi4gDQoNCk15IHByb3Bvc2FsIHdvdWxk IGJlIHRvIGR1bXAgTWF4LU9GRSBpbnRvIGEgc2VwYXJhdGUgcGVyc29uYWwgZHJhZnQgZm9yIGZ1 dHVyZSBkaXNjdXNzaW9uIGFuZCB3b3JrLCBpdCBjb3VsZCBiZSBzdGFuZGFyZGl6ZWQgaW4gdGhh dCBvciBzb21lIG90aGVyIGZvcm0gbGF0ZXIuIFRoYXQgd291bGQgbGVhdmUgdGhlIE9ic2VydmUg V0cgZG9jdW1lbnQgcmVhZHkgZm9yIFdHTEMsIGJ1dCBhbGxvdyBjb250aW51ZWQgd29yayBvbiB0 aGUgaWRlYS4NCg0KV2hhdCBkbyBvdGhlcnMgdGhpbms/DQoNClphY2gNCg0KLS0gDQpaYWNoIFNo ZWxieSwgQ2hpZWYgTmVyZCwgU2Vuc2lub2RlIEx0ZC4NCmh0dHA6Ly93d3cuc2Vuc2lub2RlLmNv bQ0KaHR0cDovL3phY2hzaGVsYnkub3JnICAtIE15IGJsb2cgIk9uIHRoZSBJbnRlcm5ldCBvZiBU aGluZ3MiDQpodHRwOi8vNmxvd3Bhbi5uZXQgLSBNeSBib29rICI2TG9XUEFOOiBUaGUgV2lyZWxl c3MgRW1iZWRkZWQgSW50ZXJuZXQiDQpNb2JpbGU6ICszNTggNDAgNzc5NjI5Nw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxp c3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29yZQ0K From esko.dijk@philips.com Fri Jan 6 04:28:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7A821F8931 for ; Fri, 6 Jan 2012 04:28:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VbO7F3HXlsc for ; Fri, 6 Jan 2012 04:28:35 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB421F88A7 for ; Fri, 6 Jan 2012 04:28:32 -0800 (PST) Received: from mail37-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jan 2012 12:28:32 +0000 Received: from mail37-ch1 (localhost [127.0.0.1]) by mail37-ch1-R.bigfish.com (Postfix) with ESMTP id 635376402F0; Fri, 6 Jan 2012 12:28:32 +0000 (UTC) X-SpamScore: -44 X-BigFish: VPS-44(zz217bL15d6O9251Jc89bh542M1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail37-ch1 (localhost.localdomain [127.0.0.1]) by mail37-ch1 (MessageSwitch) id 1325852910199455_21599; Fri, 6 Jan 2012 12:28:30 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail37-ch1.bigfish.com (Postfix) with ESMTP id 21E05300046; Fri, 6 Jan 2012 12:28:30 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jan 2012 12:28:29 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.189]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.01.0355.003; Fri, 6 Jan 2012 12:29:21 +0000 From: "Dijk, Esko" To: Carsten Bormann , Salvatore Loreto , Likepeng Thread-Topic: [core] Multicast response suppression, random back-off (ticket #177) Thread-Index: AQHMzG6w4hQgK9PdAUOSjrrH2AzuAA== Date: Fri, 6 Jan 2012 12:28:27 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618045A1E@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61802BC3C@011-DB3MPN1-013.MGDPHG.emi.philips.com> <4EF21769.3090409@ericsson.com> <5292A655-FD4A-453F-A8F8-9684F51E9FBC@tzi.org> In-Reply-To: <5292A655-FD4A-453F-A8F8-9684F51E9FBC@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 06 Jan 2012 12:28:36 -0000 Hello Carsten, Salvatore, Kepeng, Some comments below. I'll use name the proposed name "Patience" from here o= n. > I was trying to argue that the two time frames (client patience, server d= ithering) are exactly the same ones: > In the multicast case, the server would try to dither within the exactly = the time frame that the requester is > prepared to wait. So there is never a good reason to indicate another tim= e frame. In our multicast lighting use case, the time values for 'client patience' a= nd 'server dithering' are typically different. For example, a client reques= ts "dithering" between 0-300 ms when doing a request to a group of lights. = But if a couple of lights in the group are slower in responding (say, up to= 1 or 2 seconds) this is still ok. No need for a server to cancel the opera= tion because some internal delay >T occurred. Phrased in terms of a "Patience" Option with a value T, I see three possibl= e types of 'patience' this Option could mean: #1 Client Patience: client indicates own patience; requester prepared to wa= it for at most time T. After T, responses are not of interest anymore. #2 Server Patience: client asks server to be patient; server should wait a = time between 0 and T, *if possible*, before responding. Responses generated= later than T are still of interest to the client. #3 Both Client and Server Patience: the union of above #1 and #2. After T, = responses are not of interest anymore. [ #2/#3 seem only relevant when applied to multicast requests? #1 is releva= nt for both unicast/multicast requests.] Semantics #3, for multicast, coincides with Carsten's proposal. In my view = #2 is easiest to specify in CoAP because we don't have to consider what to = do with cancelling POST/PUT requests, which 4.xx/5.xx errors to return when= , etc., problems mentioned in this mail thread. Plus it fits well to the mu= lticast lighting use case. And, it addresses the multicast congestion issue= s i.e. ticket #177 with minimal added complexity. My proposal: why not define a separate elective Option "Backoff" or "(Serve= r) Patience" or , with semantics #2, that SHOULD be used only i= n multicast CoAP requests ? regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Wednesday 21 December 2011 19:59 To: Salvatore Loreto Cc: core@ietf.org Subject: Re: [core] Multicast response suppression, random back-off (ticket= #177) >>> About the semantics: There is a clearly different semantics between "re= sponse is most useful before time T" and "if possible please delay your res= ponse by a random time within [0,T]". The first is an application concern, = while the second is more to 'engineer' the network traffic patterns to an a= cceptable behaviour i.e. related to the CoAP messaging 'sublayer'. Under th= e first semantics there's no reason to delay anything while under the secon= d semantics this is the key point. >> While this is true, the difference is in the unicast (reply now) vs. mul= ticast (reply with a dithered delay) semantics, not in the semantics of the= option that is giving the desired time frame. > > > just for the sake to try to understand better the scenario and the semant= ic: > could the "response is most useful before time T" semantic be somehow use= ful also for multicast request? I was trying to argue that the two time frames (client patience, server dit= hering) are exactly the same ones: In the multicast case, the server would try to dither within the exactly th= e time frame that the requester is prepared to wait. So there is never a good reason to indicate another time frame. (Note that, in all cases, the time is extended by network latency. There a= lso should be some exhortation that a retransmitting sender *should* adjust= the time if that is indeed what the sender wants.) > most likely the server can not figure it out in advance whether or not it= will be able to honor the request-timeout > it will only discover that once it has already started to elaborate the P= OST/PUT request > however both POST and PUT request are not save, POST is not idempotent wh= ile PUT is idempotent. > > so we have to think carefully how to apply the Request-Timeout (or whatev= er this option will finally named) for POST/PUT methods Right. But I'm pretty sure in the end what we write there will amount to "the serv= er should do the right thing"... The semantics are just too different in different applications and kinds of= resources. Gr=FC=DFe, Carsten PS.: Maybe "Patience" is indeed the right name for that option... _______________________________________________ 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 likepeng@huawei.com Fri Jan 6 16:20:38 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3721F85B8 for ; Fri, 6 Jan 2012 16:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.409 X-Spam-Level: X-Spam-Status: No, score=-5.409 tagged_above=-999 required=5 tests=[AWL=1.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WXTp191wYRr for ; Fri, 6 Jan 2012 16:20:33 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8621F85B7 for ; Fri, 6 Jan 2012 16:20:33 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXE00LQLJM457@szxga05-in.huawei.com> for core@ietf.org; Sat, 07 Jan 2012 08:20:28 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXE00IBTJLTVG@szxga05-in.huawei.com> for core@ietf.org; Sat, 07 Jan 2012 08:20:28 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGG73521; Sat, 07 Jan 2012 08:20:27 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 07 Jan 2012 08:20:23 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 07 Jan 2012 08:20:17 +0800 Date: Sat, 07 Jan 2012 00:20:16 +0000 From: Likepeng In-reply-to: <031DD135F9160444ABBE3B0C36CED618045A1E@011-DB3MPN1-013.MGDPHG.emi.philips.com> X-Originating-IP: [10.70.109.53] To: "Dijk, Esko" , Carsten Bormann , Salvatore Loreto Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D4F8BE@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] Multicast response suppression, random back-off (ticket #177) Thread-index: AQHMzG6w5k4/LtC+R0WV3JdIw73QmpYACi1A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61802BC3C@011-DB3MPN1-013.MGDPHG.emi.philips.com> <4EF21769.3090409@ericsson.com> <5292A655-FD4A-453F-A8F8-9684F51E9FBC@tzi.org> <031DD135F9160444ABBE3B0C36CED618045A1E@011-DB3MPN1-013.MGDPHG.emi.philips.com> Cc: "core@ietf.org" Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 07 Jan 2012 00:20:38 -0000 PiBNeSBwcm9wb3NhbDogd2h5IG5vdCBkZWZpbmUgYSBzZXBhcmF0ZSBlbGVjdGl2ZSBPcHRpb24g IkJhY2tvZmYiIG9yICIoU2VydmVyKSBQYXRpZW5jZSIgb3IgPG90aGVyIG5hbWU+LCB3aXRoIHNl bWFudGljcyAjMiwgdGhhdCBTSE9VTEQgYmUgdXNlZCBvbmx5IGluIG11bHRpY2FzdCBDb0FQIHJl cXVlc3RzID8NCg0KQW5vdGhlciBhbHRlcm5hdGl2ZSBpcyB0byBhbGxvY2F0ZSBvbmUgYml0IHRv IGRpZmZlcmVudGlhdGUgd2hldGhlciBpdCBpcyBhICJjbGllbnQgcGF0aWVuY2UiIG9yICJzZXJ2 ZXIgcGF0aWVuY2UiLiBUaGlzIHdpbGwgcmVkdWNlIHRoZSByYW5nZSBvZiB0aGUgdGltZSwgYnV0 IG1heWJlIHdlIGNhbiBhbGxvY2F0ZSB0d28gYnl0ZXMgZm9yIHRoZSBvcHRpb24sIGluc3RlYWQg b2Ygb25lIGJ5dGUuDQoNCkkgYW0gZmluZSB3aXRoIGVpdGhlciB3YXkuDQoNClRoYW5rcywNCktp bmQgUmVnYXJkcw0KS2VwZW5nDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IERp amssIEVza28gW21haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb21dIA0K5Y+R6YCB5pe26Ze0OiAy MDEy5bm0MeaciDbml6UgMjA6MjgNCuaUtuS7tuS6ujogQ2Fyc3RlbiBCb3JtYW5uOyBTYWx2YXRv cmUgTG9yZXRvOyBMaWtlcGVuZw0K5oqE6YCBOiBjb3JlQGlldGYub3JnDQrkuLvpopg6IFJFOiBb Y29yZV0gTXVsdGljYXN0IHJlc3BvbnNlIHN1cHByZXNzaW9uLCByYW5kb20gYmFjay1vZmYgKHRp Y2tldCAjMTc3KQ0KDQpIZWxsbyBDYXJzdGVuLCBTYWx2YXRvcmUsIEtlcGVuZywNCg0KU29tZSBj b21tZW50cyBiZWxvdy4gSSdsbCB1c2UgbmFtZSB0aGUgcHJvcG9zZWQgbmFtZSAiUGF0aWVuY2Ui IGZyb20gaGVyZSBvbi4NCg0KPiBJIHdhcyB0cnlpbmcgdG8gYXJndWUgdGhhdCB0aGUgdHdvIHRp bWUgZnJhbWVzIChjbGllbnQgcGF0aWVuY2UsIHNlcnZlciBkaXRoZXJpbmcpIGFyZSBleGFjdGx5 IHRoZSBzYW1lIG9uZXM6DQo+IEluIHRoZSBtdWx0aWNhc3QgY2FzZSwgdGhlIHNlcnZlciB3b3Vs ZCB0cnkgdG8gZGl0aGVyIHdpdGhpbiB0aGUgZXhhY3RseSB0aGUgdGltZSBmcmFtZSB0aGF0IHRo ZSByZXF1ZXN0ZXIgaXMNCj4gcHJlcGFyZWQgdG8gd2FpdC4gU28gdGhlcmUgaXMgbmV2ZXIgYSBn b29kIHJlYXNvbiB0byBpbmRpY2F0ZSBhbm90aGVyIHRpbWUgZnJhbWUuDQoNCkluIG91ciBtdWx0 aWNhc3QgbGlnaHRpbmcgdXNlIGNhc2UsIHRoZSB0aW1lIHZhbHVlcyBmb3IgJ2NsaWVudCBwYXRp ZW5jZScgYW5kICdzZXJ2ZXIgZGl0aGVyaW5nJyBhcmUgdHlwaWNhbGx5IGRpZmZlcmVudC4gRm9y IGV4YW1wbGUsIGEgY2xpZW50IHJlcXVlc3RzICJkaXRoZXJpbmciIGJldHdlZW4gMC0zMDAgbXMg d2hlbiBkb2luZyBhIHJlcXVlc3QgdG8gYSBncm91cCBvZiBsaWdodHMuIEJ1dCBpZiBhIGNvdXBs ZSBvZiBsaWdodHMgaW4gdGhlIGdyb3VwIGFyZSBzbG93ZXIgaW4gcmVzcG9uZGluZyAoc2F5LCB1 cCB0byAxIG9yIDIgc2Vjb25kcykgdGhpcyBpcyBzdGlsbCBvay4gTm8gbmVlZCBmb3IgYSBzZXJ2 ZXIgdG8gY2FuY2VsIHRoZSBvcGVyYXRpb24gYmVjYXVzZSBzb21lIGludGVybmFsIGRlbGF5ID5U IG9jY3VycmVkLg0KDQpQaHJhc2VkIGluIHRlcm1zIG9mIGEgIlBhdGllbmNlIiBPcHRpb24gd2l0 aCBhIHZhbHVlIFQsIEkgc2VlIHRocmVlIHBvc3NpYmxlIHR5cGVzIG9mICdwYXRpZW5jZScgdGhp cyBPcHRpb24gY291bGQgbWVhbjoNCg0KIzEgQ2xpZW50IFBhdGllbmNlOiBjbGllbnQgaW5kaWNh dGVzIG93biBwYXRpZW5jZTsgcmVxdWVzdGVyIHByZXBhcmVkIHRvIHdhaXQgZm9yIGF0IG1vc3Qg dGltZSBULiBBZnRlciBULCByZXNwb25zZXMgYXJlIG5vdCBvZiBpbnRlcmVzdCBhbnltb3JlLg0K IzIgU2VydmVyIFBhdGllbmNlOiBjbGllbnQgYXNrcyBzZXJ2ZXIgdG8gYmUgcGF0aWVudDsgc2Vy dmVyIHNob3VsZCB3YWl0IGEgdGltZSBiZXR3ZWVuIDAgYW5kIFQsICppZiBwb3NzaWJsZSosIGJl Zm9yZSByZXNwb25kaW5nLiBSZXNwb25zZXMgZ2VuZXJhdGVkIGxhdGVyIHRoYW4gVCBhcmUgc3Rp bGwgb2YgaW50ZXJlc3QgdG8gdGhlIGNsaWVudC4NCiMzIEJvdGggQ2xpZW50IGFuZCBTZXJ2ZXIg UGF0aWVuY2U6IHRoZSB1bmlvbiBvZiBhYm92ZSAjMSBhbmQgIzIuIEFmdGVyIFQsIHJlc3BvbnNl cyBhcmUgbm90IG9mIGludGVyZXN0IGFueW1vcmUuDQoNClsgIzIvIzMgc2VlbSBvbmx5IHJlbGV2 YW50IHdoZW4gYXBwbGllZCB0byBtdWx0aWNhc3QgcmVxdWVzdHM/ICMxIGlzIHJlbGV2YW50IGZv ciBib3RoIHVuaWNhc3QvbXVsdGljYXN0IHJlcXVlc3RzLl0NCg0KU2VtYW50aWNzICMzLCBmb3Ig bXVsdGljYXN0LCBjb2luY2lkZXMgd2l0aCBDYXJzdGVuJ3MgcHJvcG9zYWwuIEluIG15IHZpZXcg IzIgaXMgZWFzaWVzdCB0byBzcGVjaWZ5IGluIENvQVAgYmVjYXVzZSB3ZSBkb24ndCBoYXZlIHRv IGNvbnNpZGVyIHdoYXQgdG8gZG8gd2l0aCBjYW5jZWxsaW5nIFBPU1QvUFVUIHJlcXVlc3RzLCB3 aGljaCA0Lnh4LzUueHggZXJyb3JzIHRvIHJldHVybiB3aGVuLCBldGMuLCBwcm9ibGVtcyBtZW50 aW9uZWQgaW4gdGhpcyBtYWlsIHRocmVhZC4gUGx1cyBpdCBmaXRzIHdlbGwgdG8gdGhlIG11bHRp Y2FzdCBsaWdodGluZyB1c2UgY2FzZS4gQW5kLCBpdCBhZGRyZXNzZXMgdGhlIG11bHRpY2FzdCBj b25nZXN0aW9uIGlzc3VlcyBpLmUuIHRpY2tldCAjMTc3IHdpdGggbWluaW1hbCBhZGRlZCBjb21w bGV4aXR5Lg0KDQpNeSBwcm9wb3NhbDogd2h5IG5vdCBkZWZpbmUgYSBzZXBhcmF0ZSBlbGVjdGl2 ZSBPcHRpb24gIkJhY2tvZmYiIG9yICIoU2VydmVyKSBQYXRpZW5jZSIgb3IgPG90aGVyIG5hbWU+ LCB3aXRoIHNlbWFudGljcyAjMiwgdGhhdCBTSE9VTEQgYmUgdXNlZCBvbmx5IGluIG11bHRpY2Fz dCBDb0FQIHJlcXVlc3RzID8NCg0KcmVnYXJkcywNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogV2VkbmVzZGF5 IDIxIERlY2VtYmVyIDIwMTEgMTk6NTkNClRvOiBTYWx2YXRvcmUgTG9yZXRvDQpDYzogY29yZUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBNdWx0aWNhc3QgcmVzcG9uc2Ugc3VwcHJlc3Np b24sIHJhbmRvbSBiYWNrLW9mZiAodGlja2V0ICMxNzcpDQoNCj4+PiBBYm91dCB0aGUgc2VtYW50 aWNzOiBUaGVyZSBpcyBhIGNsZWFybHkgZGlmZmVyZW50IHNlbWFudGljcyBiZXR3ZWVuICJyZXNw b25zZSBpcyBtb3N0IHVzZWZ1bCBiZWZvcmUgdGltZSBUIiBhbmQgImlmIHBvc3NpYmxlIHBsZWFz ZSBkZWxheSB5b3VyIHJlc3BvbnNlIGJ5IGEgcmFuZG9tIHRpbWUgd2l0aGluIFswLFRdIi4gVGhl IGZpcnN0IGlzIGFuIGFwcGxpY2F0aW9uIGNvbmNlcm4sIHdoaWxlIHRoZSBzZWNvbmQgaXMgbW9y ZSB0byAnZW5naW5lZXInIHRoZSBuZXR3b3JrIHRyYWZmaWMgcGF0dGVybnMgdG8gYW4gYWNjZXB0 YWJsZSBiZWhhdmlvdXIgaS5lLiByZWxhdGVkIHRvIHRoZSBDb0FQIG1lc3NhZ2luZyAnc3VibGF5 ZXInLiBVbmRlciB0aGUgZmlyc3Qgc2VtYW50aWNzIHRoZXJlJ3Mgbm8gcmVhc29uIHRvIGRlbGF5 IGFueXRoaW5nIHdoaWxlIHVuZGVyIHRoZSBzZWNvbmQgc2VtYW50aWNzIHRoaXMgaXMgdGhlIGtl eSBwb2ludC4NCj4+IFdoaWxlIHRoaXMgaXMgdHJ1ZSwgdGhlIGRpZmZlcmVuY2UgaXMgaW4gdGhl IHVuaWNhc3QgKHJlcGx5IG5vdykgdnMuIG11bHRpY2FzdCAocmVwbHkgd2l0aCBhIGRpdGhlcmVk IGRlbGF5KSBzZW1hbnRpY3MsIG5vdCBpbiB0aGUgc2VtYW50aWNzIG9mIHRoZSBvcHRpb24gdGhh dCBpcyBnaXZpbmcgdGhlIGRlc2lyZWQgdGltZSBmcmFtZS4NCj4NCj4NCj4ganVzdCBmb3IgdGhl IHNha2UgdG8gdHJ5IHRvIHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBzY2VuYXJpbyBhbmQgdGhlIHNl bWFudGljOg0KPiBjb3VsZCB0aGUgInJlc3BvbnNlIGlzIG1vc3QgdXNlZnVsIGJlZm9yZSB0aW1l IFQiIHNlbWFudGljIGJlIHNvbWVob3cgdXNlZnVsIGFsc28gZm9yIG11bHRpY2FzdCByZXF1ZXN0 Pw0KDQpJIHdhcyB0cnlpbmcgdG8gYXJndWUgdGhhdCB0aGUgdHdvIHRpbWUgZnJhbWVzIChjbGll bnQgcGF0aWVuY2UsIHNlcnZlciBkaXRoZXJpbmcpIGFyZSBleGFjdGx5IHRoZSBzYW1lIG9uZXM6 DQpJbiB0aGUgbXVsdGljYXN0IGNhc2UsIHRoZSBzZXJ2ZXIgd291bGQgdHJ5IHRvIGRpdGhlciB3 aXRoaW4gdGhlIGV4YWN0bHkgdGhlIHRpbWUgZnJhbWUgdGhhdCB0aGUgcmVxdWVzdGVyIGlzIHBy ZXBhcmVkIHRvIHdhaXQuDQpTbyB0aGVyZSBpcyBuZXZlciBhIGdvb2QgcmVhc29uIHRvIGluZGlj YXRlIGFub3RoZXIgdGltZSBmcmFtZS4NCihOb3RlIHRoYXQsIGluIGFsbCBjYXNlcywgdGhlIHRp bWUgaXMgZXh0ZW5kZWQgYnkgbmV0d29yayBsYXRlbmN5LiAgVGhlcmUgYWxzbyBzaG91bGQgYmUg c29tZSBleGhvcnRhdGlvbiB0aGF0IGEgcmV0cmFuc21pdHRpbmcgc2VuZGVyICpzaG91bGQqIGFk anVzdCB0aGUgdGltZSBpZiB0aGF0IGlzIGluZGVlZCB3aGF0IHRoZSBzZW5kZXIgd2FudHMuKQ0K DQo+IG1vc3QgbGlrZWx5IHRoZSBzZXJ2ZXIgY2FuIG5vdCBmaWd1cmUgaXQgb3V0IGluIGFkdmFu Y2Ugd2hldGhlciBvciBub3QgaXQgd2lsbCBiZSBhYmxlIHRvIGhvbm9yIHRoZSByZXF1ZXN0LXRp bWVvdXQNCj4gaXQgd2lsbCBvbmx5IGRpc2NvdmVyIHRoYXQgb25jZSBpdCBoYXMgYWxyZWFkeSBz dGFydGVkIHRvIGVsYWJvcmF0ZSB0aGUgUE9TVC9QVVQgcmVxdWVzdA0KPiBob3dldmVyIGJvdGgg UE9TVCBhbmQgUFVUIHJlcXVlc3QgYXJlIG5vdCBzYXZlLCBQT1NUIGlzIG5vdCBpZGVtcG90ZW50 IHdoaWxlIFBVVCBpcyBpZGVtcG90ZW50Lg0KPg0KPiBzbyB3ZSBoYXZlIHRvIHRoaW5rIGNhcmVm dWxseSBob3cgdG8gYXBwbHkgdGhlIFJlcXVlc3QtVGltZW91dCAob3Igd2hhdGV2ZXIgdGhpcyBv cHRpb24gd2lsbCBmaW5hbGx5IG5hbWVkKSBmb3IgUE9TVC9QVVQgbWV0aG9kcw0KDQpSaWdodC4N CkJ1dCBJJ20gcHJldHR5IHN1cmUgaW4gdGhlIGVuZCB3aGF0IHdlIHdyaXRlIHRoZXJlIHdpbGwg YW1vdW50IHRvICJ0aGUgc2VydmVyIHNob3VsZCBkbyB0aGUgcmlnaHQgdGhpbmciLi4uDQpUaGUg c2VtYW50aWNzIGFyZSBqdXN0IHRvbyBkaWZmZXJlbnQgaW4gZGlmZmVyZW50IGFwcGxpY2F0aW9u cyBhbmQga2luZHMgb2YgcmVzb3VyY2VzLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNClBTLjogTWF5 YmUgIlBhdGllbmNlIiBpcyBpbmRlZWQgdGhlIHJpZ2h0IG5hbWUgZm9yIHRoYXQgb3B0aW9uLi4u DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3Jl IG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFs IGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2Ug aXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1 c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1l c3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVy IGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwg bWVzc2FnZS4NCg0K From zach@sensinode.com Mon Jan 9 03:43:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C6E21F8493 for ; Mon, 9 Jan 2012 03:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_20=-0.74, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x47ZGMBEcI+8 for ; Mon, 9 Jan 2012 03:43:37 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id B0C2821F86FE for ; Mon, 9 Jan 2012 03:43:36 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q09BhXPm021772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 Jan 2012 13:43:34 +0200 From: Zach Shelby Content-Type: multipart/alternative; boundary=Apple-Mail-16--90137425 Date: Mon, 9 Jan 2012 13:43:33 +0200 References: <31EEA62B6A5CC740AEE30B7640139F31782A225811@XMSCLUSTER-MBX.etsihq.org> To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: Invitation Internet of Things CoAP Plugtest, 24-25th March 2012 in Paris, France 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, 09 Jan 2012 11:43:42 -0000 --Apple-Mail-16--90137425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 ETSI is co-locating a CoAP interop event with the next IETF. It will be = open and free for anyone attending the IETF to participate in with your = CoAP client, server (or both). Welcome!=20 Zach Begin forwarded message: > From: ETSI_Events > Date: January 5, 2012 3:46:48 PM GMT+02:00 > To: undisclosed-recipients:; > Subject: Invitation Internet of Things CoAP Plugtest, 24-25th March = 2012 in Paris, France >=20 > Dear all > ETSI Plugtests, the IPSO Alliance, and the FP7 Probe-IT project are = pleased to invite you to participate to the first Internet of Things = CoAP Plugtest, taking place from 24-25th March 2012 in Paris, France. = The event is co-located with the 83rd IETF held March 26-30th. > This event is open to all and is aimed at M2M system vendors, = operators, software vendors and research institutes.=20 > The event will focus on testing the conformance and interoperability = of the IETF CoRE standards for M2M, focusing on CoAP. An event not to be = missed, if you want to be sure your products and implementations are fit = for the growing M2M market! >=20 > ETSI will assess for the interoperability of different CoAP = implementations for features including: > =D8 The base CoAP specification > =D8 CoAP Block Transfer > =D8 CoAP Observation > =D8 The CoRE Link Format > =20 > The event will focus on server and client CoAP end-point = implementations and products with these features. > =20 > For more information visit: = http://www.etsi.org/plugtests/coap/coap.htm > Should you need any further information, do not hesitate to contact: = Plugtests@etsi.org > =20 > The ETSI Plugtests Team > =20 > =20 >=20 > =20 > =20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-16--90137425 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
ETSI is co-locating a CoAP interop event = with the next IETF. It will be open and free for anyone attending the = IETF to participate in with your CoAP client, server (or both). = Welcome! 

Zach

Begi= n forwarded message:

From: ETSI_Events <ETSI_events@etsi.org>
Date: January 5, 2012 = 3:46:48 PM GMT+02:00
To: undisclosed-recipients:;
Subject: Invitation = Internet of Things CoAP Plugtest, 24-25th March 2012 in Paris, = France

 Internet of Things CoAP = Plugtest, taking place from 24-25th March = 2012 in Paris, = France. The event is co-located = with the 83rd IETF held March = 26-30th.

This event is open to all and is aimed = at M2M system vendors, operators, software vendors and research = institutes. 
The = event will focus on testing the conformance and interoperability of the = IETF CoRE standards for M2M, focusing on CoAP. An event not to be = missed, if you want to be sure your products and implementations are fit = for the growing M2M market!

ETSI will assess for the = interoperability of different CoAP implementations for features = including:
=D8 The base CoAP = specification
=D8 CoAP Block Transfer
=D8 CoAP Observation
=D8 The CoRE Link = Format
 
Should you need any further = information, do not hesitate to contact: The ETSI Plugtests = Team

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

= --Apple-Mail-16--90137425-- From internet-drafts@ietf.org Tue Jan 10 05:07:48 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E94321F86D0; Tue, 10 Jan 2012 05:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMX35m4vsIoL; Tue, 10 Jan 2012 05:07:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5921F8658; Tue, 10 Jan 2012 05:07:47 -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: 3.64p1 Message-ID: <20120110130747.27840.57152.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 05:07:47 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-00.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, 10 Jan 2012 13:07:48 -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 Work= ing Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-00.txt Pages : 32 Date : 2012-01-10 This is a working document intended to develop draft text for the CoAP protocol specification in the area of group communication. A solution based on IP multicast is proposed and detailed. Also, guidance is provided for deployment in various constrained network topologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-groupcomm-00.txt From zach@sensinode.com Wed Jan 11 13:22:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19DA11E80BB for ; Wed, 11 Jan 2012 13:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbJPoyDSbUP4 for ; Wed, 11 Jan 2012 13:22: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 579EF11E8074 for ; Wed, 11 Jan 2012 13:22:33 -0800 (PST) Received: from [10.59.3.32] (oul314-99.netplaza.fi [188.64.2.99]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q0BLJaCh018343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jan 2012 23:22:31 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: Date: Wed, 11 Jan 2012 22:06:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2734960F-BABE-4D91-91CC-E1845F8EE4EF@sensinode.com> References: To: Antonio Jara X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] New Version Notification for draft-shelby-core-interfaces-00.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, 11 Jan 2012 21:22:36 -0000 Hi Antonio, On Jan 4, 2012, at 4:22 PM, Antonio Jara wrote: > Hi Zach, >=20 > Regarding the integration of sensors/actuator from legacy technologies = and protocols which are being adapted to 6LoWPAN/IPv6. For example, in = building automation a EIB/KNX device or X10 device, which is integrated = in a gateway to be enabled/powered with CoAP and IPv6 access. Yes, Peter's draft on building automation also touches on this subject.=20= > The description of this interfaces in the gateway for the DNS-SD could = be core#x10_s or something like that. Or this specification of the = technology is more focused on the "resource type" parameter that in the = "interface" one. The interface description really should describe the REST interface of = that resource. So what you put there depends on how you map the legacy = technology to resources. To me it sounds like the resource type = parameter would be most useful for describing that this resource has = something to do with X10, and to discover it.=20 You might want to just try creating some REST mappings for those kinds = of legacy devices, and then take a shot at naming them after that.=20 Zach >=20 > Best regards, thanks so much, and happy 2012!, > Antonio Jara >=20 > On Mon, Jan 2, 2012 at 5:41 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/core >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send core mailing list submissions to > core@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/core > or, via email, send a message with subject or body 'help' to > core-request@ietf.org >=20 > You can reach the person managing the list at > core-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core digest..." >=20 > Today's Topics: >=20 > 1. Re: [hiprg] Research topics discussion - meeting suggestion: > Wednesday 7:30pm (Miika Komu) > 2. Fwd: New Version Notification for > draft-shelby-core-interfaces-00.txt (Zach Shelby) > 3. #180: Update ABNF for queries (core issue tracker) > 4. Re: #178: Multiple relation types (core issue tracker) > 5. Re: #178: Multiple relation types (core issue tracker) > 6. Re: #179: SHOULD NOT for multicast response repression > (core issue tracker) > 7. Re: #180: Update ABNF for queries (core issue tracker) >=20 >=20 > ---------- Forwarded message ---------- > From: Miika Komu > To: "Ren=E9 Hummen" > Cc: hipsec@ietf.org, core > Date: Mon, 02 Jan 2012 07:46:13 +0200 > Subject: Re: [core] [hiprg] Research topics discussion - meeting = suggestion: Wednesday 7:30pm > Hi, >=20 > I sent privately a number of references for Struik but here's the most = essential ones. Regarding to ease-of-use considerations, and UIA [1] = extends HIP-like security to user-level identities. We have also = conducted some usability tests with a HIP GUI [2] earlier. >=20 > Regarding to security, references [3,4] are worth checking out because = they have helped to improve the security in HIP. >=20 > [1] http://www.pdos.lcs.mit.edu/papers/uia:osdi06.pdf >=20 > [2] Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security = Management with Host Identity Protocol, published in The 7th ACS/IEEE = International Conference on Computer Systems and Applications = (AICCSA-2009) >=20 > [3] Krawczyk, H. and P. Eronen, "HMAC-based > Extract-and-Expand Key Derivation > Function (HKDF)", RFC 5869, May 2010. >=20 > [4] Aura, T., Nagarajan, A., and A. Gurtov, > "Analysis of the HIP Base Exchange > Protocol", in Proceedings of 10th > Australasian Conference on Information > Security and Privacy, July 2003. >=20 > On 31/12/11 19:04, Ren=E9 Hummen wrote: > Hello Ren=E9, >=20 > this email contains a few references to papers regarding the security = properties and embedding of HIP in today's network environments. >=20 > First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To = be exact, it is a derivate of the basic protocol described in Section = 5.1, as the HIP BEX is triggered by a separate (empty) message that is = not included in the SIGMA protocol family. This allows HIP to perform = DoS protection against exhaustive public key-based operations by the = responder by means of cryptographic puzzles. Furthermore, the public key = (A) of the responder is already sent in the first response message. = However, this does not impact the security properties, but rather the = anonymity of the responder. >=20 > Regarding the usage of HIP, there is a rather comprehensive journal = article [2] that describes the architecture as well as the operation = system and infrastructure requirements of HIP. It also provides some = pointers to further papers that may be worth reading for you. = Additionally, Samu Varjonen recently published a paper on the "Secure = Resolution of End-Host Identifiers for Mobile Clients" [3]. However, it = seems to be inaccessible at the moment. Still, you may want to refer to = it at later point in time, as it describes an approach to resolve HITs = to IP addresses. >=20 > I hope that this small selection is helping you in understanding the = properties of HIP. I would also like to invite other people to = contribute to this discussion, e.g., by providing further references = relevant for the CoRE WG. >=20 > Regards, > Ren=E9 >=20 >=20 > [1] Krawczyk, H.; SIGMA: The =91SIGn-and-MAc=92 Approach to = Authenticated Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES = IN CRYPTOLOGY - CRYPTO 2003 > Lecture Notes in Computer Science, 2003 > [2] Nikander, P.; Gurtov, A.; Henderson, T.R.; Host Identity = Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and = Privacy over IPv4 and IPv6 Networks, Communications Surveys& Tutorials, = IEEE, 2010 > [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure = Resolution of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, = 2011 > On 19.12.2011, at 16:51, Rene Struik wrote: >=20 >=20 > Perhaps, worth some thoughts under the Christmas tree and then getting = back on this one after New Year. >=20 > On 17/11/2011 8:33 PM, Rene Struik wrote: > Hi fellow-Rene: >=20 > If you have some papers, I would appreciate. Distributing those would = also help removing hurdles to more wide-scale use of HIP (I saw the = slides on lack of adoption of HIP). >=20 > Best regards, Rene >=20 >=20 > On 14/11/2011 12:49 PM, Rene Struik wrote: > Hi fellow-Rene: >=20 > Just curious: is there any research paper outside IETF/IRTF realm that = delves into HIP-related matter? On a tangent: same question, but now re = cryptographically generated addresses? This may help people to = appreciate this effort better, without having to delve into hundreds of = pages of specification text that sometimes seems to obscure seeing the = forest for the trees (if I translate this properly). I, for one, would = love to see 2-3 academic papers that make this subject matter clearer, = including security properties, ease-of-use considerations. >=20 > Best regards, Rene >=20 > On 14/11/2011 12:38 PM, Ren=E9 Hummen wrote: > Hello everyone, >=20 > we already had a few discussions on this list about new topics and = research directions that would foster collaboration within the context = of the hiprg. Hierarchical HITs, IoT-related protocol variants, and = middlebox awareness have been mentioned there among others. In my = opinion, an informal meeting before the hiprg meeting on Thursdays would = be a great opportunity to further discuss about these topics. = Furthermore, such a meeting would enable us see who is interested in = which field and which are the pros and cons of the different topics as = perceived by people in a more comfortable and less hurried way than in = an RG meeting. >=20 > As most of us will probably be at the social event tomorrow evening, I = suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in = order to get some discussion going. Due to the lack of knowledge about a = better place, let's meet up at the entrance of the convention center = (TICC). Please email me if you are interested. >=20 > BR > Ren=E9 >=20 >=20 >=20 > -- > Dipl.-Inform. Rene Hummen, Ph.D. Student > Chair of Communication and Distributed Systems > RWTH Aachen University, Germany > tel: +49 241 80 20772 > web: > http://www.comsys.rwth-aachen.de/team/rene-hummen/ >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > hiprg mailing list >=20 > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg >=20 >=20 > -- > email: > rstruik.ext@gmail.com >=20 > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 >=20 >=20 >=20 > -- > email: > rstruik.ext@gmail.com >=20 > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 >=20 >=20 >=20 > -- > email: > rstruik.ext@gmail.com >=20 > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 >=20 >=20 >=20 >=20 >=20 > -- > Dipl.-Inform. Rene Hummen, Ph.D. Student > Chair of Communication and Distributed Systems > RWTH Aachen University, Germany > tel: +49 241 80 20772 > web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: Zach Shelby > To: "core@ietf.org WG" > Cc:=20 > Date: Mon, 2 Jan 2012 16:03:19 +0200 > Subject: [core] Fwd: New Version Notification for = draft-shelby-core-interfaces-00.txt > http://www.ietf.org/id/draft-shelby-core-interfaces-00.txt >=20 > Here is a new draft that describes a model for REST interface = descriptions for use with the link format, that I have been using in = various contexts for a long time. Now I wanted to start developing this = further in CoRE - please give it a spin in your own server design and = will be glad to hear feedback and ideas. >=20 > Regards, > Zach >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Date: January 2, 2012 3:59:25 PM GMT+02:00 > > To: zach@sensinode.com > > Cc: zach@sensinode.com > > Subject: New Version Notification for = draft-shelby-core-interfaces-00.txt > > > > A new version of I-D, draft-shelby-core-interfaces-00.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. > > > > Filename: draft-shelby-core-interfaces > > Revision: 00 > > Title: CoRE Interfaces > > Creation date: 2012-01-02 > > WG ID: Individual Submission > > Number of pages: 11 > > > > Abstract: > > This document defines well-known interface descriptions for Batch, > > Sensor, Parameter and Actuator types for use in contrained web > > servers using the CoRE Link Format. A short reference is provided > > for each type that can be efficiently included in the interface > > description attribute of the CoRE Link Format. > > > > > > > > > > The IETF Secretariat >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:25:44 -0000 > Subject: [core] #180: Update ABNF for queries > #180: Update ABNF for queries >=20 > Esko's comments on the link-format document got Zach and me thinking = about > our usage of ptoken again. >=20 > In link-format-09, the syntax for the queries in the URIs says: >=20 > filter-query =3D resource-param "=3D" query-pattern > resource-param =3D "uri" / parmname > query-pattern =3D ptoken [ "*" ] > ptoken =3D >=20 > Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, = not > in a URI. > Looking more closely: >=20 > ptoken =3D 1*ptokenchar > ptokenchar =3D "!" | "#" | "$" | "%" | "&" | "'" | "(" > | ")" | "*" | "+" | "-" | "." | "/" | DIGIT > | ":" | "<" | "=3D" | ">" | "?" | "@" | ALPHA > | "[" | "]" | "^" | "_" | "`" | "{" | "|" > | "}" | "~" >=20 > Oops, that actually includes "*" and "&"! > There also is no mention of percent-encoding (of course not, because > RFC2616 does not percent-encode headers). >=20 > So what we really want to import here is RFC3986 ABNF, not = RFC2616/RFC5988 > ABNF. >=20 > First attempt: >=20 > query-pattern =3D search-token [ "*" ] > search-token =3D *pchar >=20 > But pchar (RFC3986) includes subdelims: >=20 > pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" >=20 > query =3D *( pchar / "/" / "?" ) >=20 > pct-encoded =3D "%" HEXDIG HEXDIG > unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" > sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=3D" >=20 > =85 which includes "*" and "&". >=20 > So, to do this right, let's mix this properly: >=20 > query-pattern =3D search-token [ "*" ] > search-token =3D *search-char > search-char =3D unreserved / pct-encoded > / ":" / "@" ; from pchar > / "/" / "?" ; from query > / "!" / "$" / "'" / "(" / ")" > / "+" / "," / ";" / "=3D" ; from sub-delims >=20 >=20 > :@/?!$'()+,;=3D indeed. >=20 >=20 > This makes it possible to say something like: >=20 > GET /.well-known/core?rt=3Doutdoor%20temperature >=20 > After the percent-decoding defined in core-coap's URI parsing = (section > 6.4), the server will see: >=20 > Uri-Path .well-known > Uri-Path core > Uri-Query rt=3Doutdoor temperature >=20 > which sounds about right. >=20 > The parser in the server will now just have to > 1) search for the first "=3D" and use that to delimit the parameter = name > from the search-token > 2) check for a trailing "*" and remove that, if present, indicating a > prefix match. >=20 > Would I use spaces for rt values? Probably not, but there are still = good > reasons for staying general here. > As the percent-decoding is already done when the server sees it, = there is > no cost to this generality, either. >=20 > The defnition of query-pattern also needs to be updated. >=20 > -- > -------------------------+-------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: editorial | Status: new > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Keywords: > -------------------------+-------------------- >=20 > Ticket URL: > core >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:35:09 -0000 > Subject: Re: [core] #178: Multiple relation types > #178: Multiple relation types >=20 >=20 > Comment (by zach@=85): >=20 > Done. >=20 > -- > ----------------------------------+--------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: protocol enhancement | Status: new > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: > Keywords: | > ----------------------------------+--------------------- >=20 > Ticket URL: = > core >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:35:20 -0000 > Subject: Re: [core] #178: Multiple relation types > #178: Multiple relation types >=20 > Changes (by zach@=85): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > -- > ----------------------------------+--------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: protocol enhancement | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > ----------------------------------+--------------------- >=20 > Ticket URL: = > core >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:38:18 -0000 > Subject: Re: [core] #179: SHOULD NOT for multicast response repression > #179: SHOULD NOT for multicast response repression >=20 > Changes (by zach@=85): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > Done: >=20 > "When using a transfer protocol like the Constrained Application = Protocol > (CoAP) that supports multicast requests, special care is taken. A > multicast request with a query string SHOULD NOT be responded to if > filtering is not supported or if the filter does not match (to avoid = a > needless response storm). The exception is in cases where the IP = stack > interface is not able to indicate that the source address was = multicast." >=20 > -- > ----------------------------------+--------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: protocol enhancement | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > ----------------------------------+--------------------- >=20 > Ticket URL: = > core >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:41:54 -0000 > Subject: Re: [core] #180: Update ABNF for queries > #180: Update ABNF for queries >=20 > Changes (by zach@=85): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > Done. >=20 > -- > -------------------------+--------------------- > Reporter: zach@=85 | Owner: zach@=85 > Type: editorial | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > -------------------------+--------------------- >=20 > Ticket URL: = > core >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From peter.van.der.stok@philips.com Thu Jan 12 03:45:09 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA9521F8486 for ; Thu, 12 Jan 2012 03:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aApuWA9MzxXf for ; Thu, 12 Jan 2012 03:45:07 -0800 (PST) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 18BB621F8480 for ; Thu, 12 Jan 2012 03:45:04 -0800 (PST) Received: from mail172-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Jan 2012 11:45:04 +0000 Received: from mail172-tx2 (localhost [127.0.0.1]) by mail172-tx2-R.bigfish.com (Postfix) with ESMTP id B803630057E; Thu, 12 Jan 2012 11:45:03 +0000 (UTC) X-SpamScore: -87 X-BigFish: VPS-87(zzbb2dI217bL15d6O9371I9251Jc89bh936eK9d9R542M1432N98dK14ffOac5Wzz1202hzz8275ch1033IL8275bh8275dh5eeeKz2dhc1ahc1bh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail172-tx2 (localhost.localdomain [127.0.0.1]) by mail172-tx2 (MessageSwitch) id 1326368701671322_32523; Thu, 12 Jan 2012 11:45:01 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.251]) by mail172-tx2.bigfish.com (Postfix) with ESMTP id 930D3140047; Thu, 12 Jan 2012 11:45:01 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Jan 2012 11:44:58 +0000 Received: from 011-DB3MPN1-062.MGDPHG.emi.philips.com ([169.254.2.250]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.01.0355.003; Thu, 12 Jan 2012 11:44:55 +0000 From: "Stok, Peter van der" To: Zach Shelby , Antonio Jara Thread-Topic: [core] New Version Notification for draft-shelby-core-interfaces-00.txt Thread-Index: AQHM0Kcp/64wO7d0vkmj8JXj/fAL+5YImovQ Date: Thu, 12 Jan 2012 11:44:54 +0000 Message-ID: References: <2734960F-BABE-4D91-91CC-E1845F8EE4EF@sensinode.com> In-Reply-To: <2734960F-BABE-4D91-91CC-E1845F8EE4EF@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.0.237.196] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] New Version Notification for draft-shelby-core-interfaces-00.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: Thu, 12 Jan 2012 11:45:09 -0000 Hi Zach and Antonio, I am quite pleased that there is an interest in legacy devices and service = descriptions. What I miss is a few lines on how this may complement service description e= fforts by SDOs. For example CABA and later OASIS have invested in the Obix standard, ZigBee= has invested in the SE2 service descriptions, DNX was extended to ACN, .. and other SDOs are making similar efforts. Looking forward to read your view, Peter -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: Wednesday 11 January 2012 21:07 To: Antonio Jara Cc: core@ietf.org Subject: Re: [core] New Version Notification for draft-shelby-core-interfac= es-00.txt Hi Antonio, On Jan 4, 2012, at 4:22 PM, Antonio Jara wrote: > Hi Zach, > > Regarding the integration of sensors/actuator from legacy technologies an= d protocols which are being adapted to 6LoWPAN/IPv6. For example, in buildi= ng automation a EIB/KNX device or X10 device, which is integrated in a gate= way to be enabled/powered with CoAP and IPv6 access. Yes, Peter's draft on building automation also touches on this subject. > The description of this interfaces in the gateway for the DNS-SD could be= core#x10_s or something like that. Or this specification of the technology= is more focused on the "resource type" parameter that in the "interface" o= ne. The interface description really should describe the REST interface of that= resource. So what you put there depends on how you map the legacy technolo= gy to resources. To me it sounds like the resource type parameter would be = most useful for describing that this resource has something to do with X10,= and to discover it. You might want to just try creating some REST mappings for those kinds of l= egacy devices, and then take a shot at naming them after that. Zach > > Best regards, thanks so much, and happy 2012!, > Antonio Jara > > On Mon, Jan 2, 2012 at 5:41 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/core > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send core mailing list submissions to > core@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/core > or, via email, send a message with subject or body 'help' to > core-request@ietf.org > > You can reach the person managing the list at > core-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core digest..." > > Today's Topics: > > 1. Re: [hiprg] Research topics discussion - meeting suggestion: > Wednesday 7:30pm (Miika Komu) > 2. Fwd: New Version Notification for > draft-shelby-core-interfaces-00.txt (Zach Shelby) > 3. #180: Update ABNF for queries (core issue tracker) > 4. Re: #178: Multiple relation types (core issue tracker) > 5. Re: #178: Multiple relation types (core issue tracker) > 6. Re: #179: SHOULD NOT for multicast response repression > (core issue tracker) > 7. Re: #180: Update ABNF for queries (core issue tracker) > > > ---------- Forwarded message ---------- > From: Miika Komu > To: "Ren=E9 Hummen" > Cc: hipsec@ietf.org, core > Date: Mon, 02 Jan 2012 07:46:13 +0200 > Subject: Re: [core] [hiprg] Research topics discussion - meeting suggesti= on: Wednesday 7:30pm > Hi, > > I sent privately a number of references for Struik but here's the most es= sential ones. Regarding to ease-of-use considerations, and UIA [1] extends = HIP-like security to user-level identities. We have also conducted some usa= bility tests with a HIP GUI [2] earlier. > > Regarding to security, references [3,4] are worth checking out because th= ey have helped to improve the security in HIP. > > [1] http://www.pdos.lcs.mit.edu/papers/uia:osdi06.pdf > > [2] Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security Man= agement with Host Identity Protocol, published in The 7th ACS/IEEE Internat= ional Conference on Computer Systems and Applications (AICCSA-2009) > > [3] Krawczyk, H. and P. Eronen, "HMAC-based > Extract-and-Expand Key Derivation > Function (HKDF)", RFC 5869, May 2010. > > [4] Aura, T., Nagarajan, A., and A. Gurtov, > "Analysis of the HIP Base Exchange > Protocol", in Proceedings of 10th > Australasian Conference on Information > Security and Privacy, July 2003. > > On 31/12/11 19:04, Ren=E9 Hummen wrote: > Hello Ren=E9, > > this email contains a few references to papers regarding the security pro= perties and embedding of HIP in today's network environments. > > First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To be e= xact, it is a derivate of the basic protocol described in Section 5.1, as t= he HIP BEX is triggered by a separate (empty) message that is not included = in the SIGMA protocol family. This allows HIP to perform DoS protection aga= inst exhaustive public key-based operations by the responder by means of cr= yptographic puzzles. Furthermore, the public key (A) of the responder is al= ready sent in the first response message. However, this does not impact the= security properties, but rather the anonymity of the responder. > > Regarding the usage of HIP, there is a rather comprehensive journal artic= le [2] that describes the architecture as well as the operation system and = infrastructure requirements of HIP. It also provides some pointers to furth= er papers that may be worth reading for you. Additionally, Samu Varjonen re= cently published a paper on the "Secure Resolution of End-Host Identifiers = for Mobile Clients" [3]. However, it seems to be inaccessible at the moment= . Still, you may want to refer to it at later point in time, as it describe= s an approach to resolve HITs to IP addresses. > > I hope that this small selection is helping you in understanding the prop= erties of HIP. I would also like to invite other people to contribute to th= is discussion, e.g., by providing further references relevant for the CoRE = WG. > > Regards, > Ren=E9 > > > [1] Krawczyk, H.; SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Dif= fie-Hellman and Its Use in the IKE Protocols, ADVANCES IN CRYPTOLOGY - CRYP= TO 2003 > Lecture Notes in Computer Science, 2003 > [2] Nikander, P.; Gurtov, A.; Henderson, T.R.; Host Identity Protocol= (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over IP= v4 and IPv6 Networks, Communications Surveys& Tutorials, IEEE, 2010 > [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure Resolution = of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, 2011 > On 19.12.2011, at 16:51, Rene Struik wrote: > > > Perhaps, worth some thoughts under the Christmas tree and then getting ba= ck on this one after New Year. > > On 17/11/2011 8:33 PM, Rene Struik wrote: > Hi fellow-Rene: > > If you have some papers, I would appreciate. Distributing those would als= o help removing hurdles to more wide-scale use of HIP (I saw the slides on = lack of adoption of HIP). > > Best regards, Rene > > > On 14/11/2011 12:49 PM, Rene Struik wrote: > Hi fellow-Rene: > > Just curious: is there any research paper outside IETF/IRTF realm that de= lves into HIP-related matter? On a tangent: same question, but now re crypt= ographically generated addresses? This may help people to appreciate this e= ffort better, without having to delve into hundreds of pages of specificati= on text that sometimes seems to obscure seeing the forest for the trees (if= I translate this properly). I, for one, would love to see 2-3 academic pap= ers that make this subject matter clearer, including security properties, e= ase-of-use considerations. > > Best regards, Rene > > On 14/11/2011 12:38 PM, Ren=E9 Hummen wrote: > Hello everyone, > > we already had a few discussions on this list about new topics and resear= ch directions that would foster collaboration within the context of the hip= rg. Hierarchical HITs, IoT-related protocol variants, and middlebox awarene= ss have been mentioned there among others. In my opinion, an informal meeti= ng before the hiprg meeting on Thursdays would be a great opportunity to fu= rther discuss about these topics. Furthermore, such a meeting would enable = us see who is interested in which field and which are the pros and cons of = the different topics as perceived by people in a more comfortable and less = hurried way than in an RG meeting. > > As most of us will probably be at the social event tomorrow evening, I su= ggest to meet for dinner/a drink on Wednesday evening at 7:30pm in order to= get some discussion going. Due to the lack of knowledge about a better pla= ce, let's meet up at the entrance of the convention center (TICC). Please e= mail me if you are interested. > > BR > Ren=E9 > > > > -- > Dipl.-Inform. Rene Hummen, Ph.D. Student > Chair of Communication and Distributed Systems > RWTH Aachen University, Germany > tel: +49 241 80 20772 > web: > http://www.comsys.rwth-aachen.de/team/rene-hummen/ > > > > > > _______________________________________________ > hiprg mailing list > > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg > > > -- > email: > rstruik.ext@gmail.com > > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > > > -- > email: > rstruik.ext@gmail.com > > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > > > -- > email: > rstruik.ext@gmail.com > > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > > > > > -- > Dipl.-Inform. Rene Hummen, Ph.D. Student > Chair of Communication and Distributed Systems > RWTH Aachen University, Germany > tel: +49 241 80 20772 > web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > > ---------- Forwarded message ---------- > From: Zach Shelby > To: "core@ietf.org WG" > Cc: > Date: Mon, 2 Jan 2012 16:03:19 +0200 > Subject: [core] Fwd: New Version Notification for draft-shelby-core-inter= faces-00.txt > http://www.ietf.org/id/draft-shelby-core-interfaces-00.txt > > Here is a new draft that describes a model for REST interface description= s for use with the link format, that I have been using in various contexts = for a long time. Now I wanted to start developing this further in CoRE - pl= ease give it a spin in your own server design and will be glad to hear feed= back and ideas. > > Regards, > Zach > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Date: January 2, 2012 3:59:25 PM GMT+02:00 > > To: zach@sensinode.com > > Cc: zach@sensinode.com > > Subject: New Version Notification for draft-shelby-core-interfaces-00.t= xt > > > > A new version of I-D, draft-shelby-core-interfaces-00.txt has been succ= essfully submitted by Zach Shelby and posted to the IETF repository. > > > > Filename: draft-shelby-core-interfaces > > Revision: 00 > > Title: CoRE Interfaces > > Creation date: 2012-01-02 > > WG ID: Individual Submission > > Number of pages: 11 > > > > Abstract: > > This document defines well-known interface descriptions for Batch, > > Sensor, Parameter and Actuator types for use in contrained web > > servers using the CoRE Link Format. A short reference is provided > > for each type that can be efficiently included in the interface > > description attribute of the CoRE Link Format. > > > > > > > > > > The IETF Secretariat > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:25:44 -0000 > Subject: [core] #180: Update ABNF for queries > #180: Update ABNF for queries > > Esko's comments on the link-format document got Zach and me thinking abo= ut > our usage of ptoken again. > > In link-format-09, the syntax for the queries in the URIs says: > > filter-query =3D resource-param "=3D" query-pattern > resource-param =3D "uri" / parmname > query-pattern =3D ptoken [ "*" ] > ptoken =3D > > Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, no= t > in a URI. > Looking more closely: > > ptoken =3D 1*ptokenchar > ptokenchar =3D "!" | "#" | "$" | "%" | "&" | "'" | "(" > | ")" | "*" | "+" | "-" | "." | "/" | DIGIT > | ":" | "<" | "=3D" | ">" | "?" | "@" | ALPHA > | "[" | "]" | "^" | "_" | "`" | "{" | "|" > | "}" | "~" > > Oops, that actually includes "*" and "&"! > There also is no mention of percent-encoding (of course not, because > RFC2616 does not percent-encode headers). > > So what we really want to import here is RFC3986 ABNF, not RFC2616/RFC59= 88 > ABNF. > > First attempt: > > query-pattern =3D search-token [ "*" ] > search-token =3D *pchar > > But pchar (RFC3986) includes subdelims: > > pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" > > query =3D *( pchar / "/" / "?" ) > > pct-encoded =3D "%" HEXDIG HEXDIG > unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" > sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=3D" > > ... which includes "*" and "&". > > So, to do this right, let's mix this properly: > > query-pattern =3D search-token [ "*" ] > search-token =3D *search-char > search-char =3D unreserved / pct-encoded > / ":" / "@" ; from pchar > / "/" / "?" ; from query > / "!" / "$" / "'" / "(" / ")" > / "+" / "," / ";" / "=3D" ; from sub-delims > > > :@/?!$'()+,;=3D indeed. > > > This makes it possible to say something like: > > GET /.well-known/core?rt=3Doutdoor%20temperature > > After the percent-decoding defined in core-coap's URI parsing (section > 6.4), the server will see: > > Uri-Path .well-known > Uri-Path core > Uri-Query rt=3Doutdoor temperature > > which sounds about right. > > The parser in the server will now just have to > 1) search for the first "=3D" and use that to delimit the parameter name > from the search-token > 2) check for a trailing "*" and remove that, if present, indicating a > prefix match. > > Would I use spaces for rt values? Probably not, but there are still goo= d > reasons for staying general here. > As the percent-decoding is already done when the server sees it, there i= s > no cost to this generality, either. > > The defnition of query-pattern also needs to be updated. > > -- > -------------------------+-------------------- > Reporter: zach@... | Owner: zach@... > Type: editorial | Status: new > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Keywords: > -------------------------+-------------------- > > Ticket URL: > core > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:35:09 -0000 > Subject: Re: [core] #178: Multiple relation types > #178: Multiple relation types > > > Comment (by zach@...): > > Done. > > -- > ----------------------------------+--------------------- > Reporter: zach@... | Owner: zach@... > Type: protocol enhancement | Status: new > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: > Keywords: | > ----------------------------------+--------------------- > > Ticket URL: > core > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:35:20 -0000 > Subject: Re: [core] #178: Multiple relation types > #178: Multiple relation types > > Changes (by zach@...): > > * status: new =3D> closed > * resolution: =3D> fixed > > > -- > ----------------------------------+--------------------- > Reporter: zach@... | Owner: zach@... > Type: protocol enhancement | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > ----------------------------------+--------------------- > > Ticket URL: > core > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:38:18 -0000 > Subject: Re: [core] #179: SHOULD NOT for multicast response repression > #179: SHOULD NOT for multicast response repression > > Changes (by zach@...): > > * status: new =3D> closed > * resolution: =3D> fixed > > > Comment: > > Done: > > "When using a transfer protocol like the Constrained Application Protoco= l > (CoAP) that supports multicast requests, special care is taken. A > multicast request with a query string SHOULD NOT be responded to if > filtering is not supported or if the filter does not match (to avoid a > needless response storm). The exception is in cases where the IP stack > interface is not able to indicate that the source address was multicast.= " > > -- > ----------------------------------+--------------------- > Reporter: zach@... | Owner: zach@... > Type: protocol enhancement | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > ----------------------------------+--------------------- > > Ticket URL: > core > > > > > ---------- Forwarded message ---------- > From: "core issue tracker" > To: zach@sensinode.com > Cc: core@ietf.org > Date: Mon, 02 Jan 2012 16:41:54 -0000 > Subject: Re: [core] #180: Update ABNF for queries > #180: Update ABNF for queries > > Changes (by zach@...): > > * status: new =3D> closed > * resolution: =3D> fixed > > > Comment: > > Done. > > -- > -------------------------+--------------------- > Reporter: zach@... | Owner: zach@... > Type: editorial | Status: closed > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Resolution: fixed > Keywords: | > -------------------------+--------------------- > > Ticket URL: > core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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 zach@sensinode.com Thu Jan 12 11:02:27 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A935E21F86E2 for ; Thu, 12 Jan 2012 11:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEVZddWwB4rH for ; Thu, 12 Jan 2012 11:02:26 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 518CD21F85A1 for ; Thu, 12 Jan 2012 11:02:24 -0800 (PST) Received: from [192.168.1.102] (87-95-232-17.bb.dnainternet.fi [87.95.232.17]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q0CJ1tqm015440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jan 2012 21:02:21 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: Date: Thu, 12 Jan 2012 17:29:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16098F5F-97E1-4E01-A9B2-487C11971389@sensinode.com> References: <2734960F-BABE-4D91-91CC-E1845F8EE4EF@sensinode.com> To: "Stok, Peter van der" X-Mailer: Apple Mail (2.1084) Cc: Antonio Jara , "core@ietf.org" Subject: Re: [core] New Version Notification for draft-shelby-core-interfaces-00.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: Thu, 12 Jan 2012 19:02:27 -0000 On Jan 12, 2012, at 1:44 PM, Stok, Peter van der wrote: > Hi Zach and Antonio, >=20 > I am quite pleased that there is an interest in legacy devices and = service descriptions. > What I miss is a few lines on how this may complement service = description efforts by SDOs. > For example CABA and later OASIS have invested in the Obix standard, = ZigBee has invested in the SE2 service descriptions, DNX was extended to = ACN, .. > and other SDOs are making similar efforts. These are by no means legacy, and already make use of REST. For example = SE2 has service types that we can already make use of in Resource Type = fields in link descriptions (we have already defined this for SE2). = Although oBix doesn't have this defined, it would be straightforward to = assign a Resource Type to identify oBix resources or make a URI = reference (we are working on that in an EU project). DNX/ACN I am not = familiar with.=20 I think this is more difficult for legacy technologies, where a REST = mapping needs to be defined in the first place in addition to resource = naming.=20 Zach >=20 > Looking forward to read your view, >=20 > Peter >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Zach Shelby > Sent: Wednesday 11 January 2012 21:07 > To: Antonio Jara > Cc: core@ietf.org > Subject: Re: [core] New Version Notification for = draft-shelby-core-interfaces-00.txt >=20 > Hi Antonio, >=20 > On Jan 4, 2012, at 4:22 PM, Antonio Jara wrote: >=20 >> Hi Zach, >>=20 >> Regarding the integration of sensors/actuator from legacy = technologies and protocols which are being adapted to 6LoWPAN/IPv6. For = example, in building automation a EIB/KNX device or X10 device, which is = integrated in a gateway to be enabled/powered with CoAP and IPv6 access. >=20 > Yes, Peter's draft on building automation also touches on this = subject. >=20 >> The description of this interfaces in the gateway for the DNS-SD = could be core#x10_s or something like that. Or this specification of the = technology is more focused on the "resource type" parameter that in the = "interface" one. >=20 > The interface description really should describe the REST interface of = that resource. So what you put there depends on how you map the legacy = technology to resources. To me it sounds like the resource type = parameter would be most useful for describing that this resource has = something to do with X10, and to discover it. >=20 > You might want to just try creating some REST mappings for those kinds = of legacy devices, and then take a shot at naming them after that. >=20 > Zach >=20 >>=20 >> Best regards, thanks so much, and happy 2012!, >> Antonio Jara >>=20 >> On Mon, Jan 2, 2012 at 5:41 PM, wrote: >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >>=20 >> https://www.ietf.org/mailman/listinfo/core >>=20 >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >>=20 >>=20 >>=20 >> Send core mailing list submissions to >> core@ietf.org >>=20 >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/core >> or, via email, send a message with subject or body 'help' to >> core-request@ietf.org >>=20 >> You can reach the person managing the list at >> core-owner@ietf.org >>=20 >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of core digest..." >>=20 >> Today's Topics: >>=20 >> 1. Re: [hiprg] Research topics discussion - meeting suggestion: >> Wednesday 7:30pm (Miika Komu) >> 2. Fwd: New Version Notification for >> draft-shelby-core-interfaces-00.txt (Zach Shelby) >> 3. #180: Update ABNF for queries (core issue tracker) >> 4. Re: #178: Multiple relation types (core issue tracker) >> 5. Re: #178: Multiple relation types (core issue tracker) >> 6. Re: #179: SHOULD NOT for multicast response repression >> (core issue tracker) >> 7. Re: #180: Update ABNF for queries (core issue tracker) >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: Miika Komu >> To: "Ren=E9 Hummen" >> Cc: hipsec@ietf.org, core >> Date: Mon, 02 Jan 2012 07:46:13 +0200 >> Subject: Re: [core] [hiprg] Research topics discussion - meeting = suggestion: Wednesday 7:30pm >> Hi, >>=20 >> I sent privately a number of references for Struik but here's the = most essential ones. Regarding to ease-of-use considerations, and UIA = [1] extends HIP-like security to user-level identities. We have also = conducted some usability tests with a HIP GUI [2] earlier. >>=20 >> Regarding to security, references [3,4] are worth checking out = because they have helped to improve the security in HIP. >>=20 >> [1] http://www.pdos.lcs.mit.edu/papers/uia:osdi06.pdf >>=20 >> [2] Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security = Management with Host Identity Protocol, published in The 7th ACS/IEEE = International Conference on Computer Systems and Applications = (AICCSA-2009) >>=20 >> [3] Krawczyk, H. and P. Eronen, "HMAC-based >> Extract-and-Expand Key Derivation >> Function (HKDF)", RFC 5869, May 2010. >>=20 >> [4] Aura, T., Nagarajan, A., and A. Gurtov, >> "Analysis of the HIP Base Exchange >> Protocol", in Proceedings of 10th >> Australasian Conference on Information >> Security and Privacy, July 2003. >>=20 >> On 31/12/11 19:04, Ren=E9 Hummen wrote: >> Hello Ren=E9, >>=20 >> this email contains a few references to papers regarding the security = properties and embedding of HIP in today's network environments. >>=20 >> First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To = be exact, it is a derivate of the basic protocol described in Section = 5.1, as the HIP BEX is triggered by a separate (empty) message that is = not included in the SIGMA protocol family. This allows HIP to perform = DoS protection against exhaustive public key-based operations by the = responder by means of cryptographic puzzles. Furthermore, the public key = (A) of the responder is already sent in the first response message. = However, this does not impact the security properties, but rather the = anonymity of the responder. >>=20 >> Regarding the usage of HIP, there is a rather comprehensive journal = article [2] that describes the architecture as well as the operation = system and infrastructure requirements of HIP. It also provides some = pointers to further papers that may be worth reading for you. = Additionally, Samu Varjonen recently published a paper on the "Secure = Resolution of End-Host Identifiers for Mobile Clients" [3]. However, it = seems to be inaccessible at the moment. Still, you may want to refer to = it at later point in time, as it describes an approach to resolve HITs = to IP addresses. >>=20 >> I hope that this small selection is helping you in understanding the = properties of HIP. I would also like to invite other people to = contribute to this discussion, e.g., by providing further references = relevant for the CoRE WG. >>=20 >> Regards, >> Ren=E9 >>=20 >>=20 >> [1] Krawczyk, H.; SIGMA: The 'SIGn-and-MAc' Approach to Authenticated = Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES IN CRYPTOLOGY = - CRYPTO 2003 >> Lecture Notes in Computer Science, 2003 >> [2] Nikander, P.; Gurtov, A.; Henderson, T.R.; Host Identity = Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and = Privacy over IPv4 and IPv6 Networks, Communications Surveys& Tutorials, = IEEE, 2010 >> [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure = Resolution of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, = 2011 >> On 19.12.2011, at 16:51, Rene Struik wrote: >>=20 >>=20 >> Perhaps, worth some thoughts under the Christmas tree and then = getting back on this one after New Year. >>=20 >> On 17/11/2011 8:33 PM, Rene Struik wrote: >> Hi fellow-Rene: >>=20 >> If you have some papers, I would appreciate. Distributing those would = also help removing hurdles to more wide-scale use of HIP (I saw the = slides on lack of adoption of HIP). >>=20 >> Best regards, Rene >>=20 >>=20 >> On 14/11/2011 12:49 PM, Rene Struik wrote: >> Hi fellow-Rene: >>=20 >> Just curious: is there any research paper outside IETF/IRTF realm = that delves into HIP-related matter? On a tangent: same question, but = now re cryptographically generated addresses? This may help people to = appreciate this effort better, without having to delve into hundreds of = pages of specification text that sometimes seems to obscure seeing the = forest for the trees (if I translate this properly). I, for one, would = love to see 2-3 academic papers that make this subject matter clearer, = including security properties, ease-of-use considerations. >>=20 >> Best regards, Rene >>=20 >> On 14/11/2011 12:38 PM, Ren=E9 Hummen wrote: >> Hello everyone, >>=20 >> we already had a few discussions on this list about new topics and = research directions that would foster collaboration within the context = of the hiprg. Hierarchical HITs, IoT-related protocol variants, and = middlebox awareness have been mentioned there among others. In my = opinion, an informal meeting before the hiprg meeting on Thursdays would = be a great opportunity to further discuss about these topics. = Furthermore, such a meeting would enable us see who is interested in = which field and which are the pros and cons of the different topics as = perceived by people in a more comfortable and less hurried way than in = an RG meeting. >>=20 >> As most of us will probably be at the social event tomorrow evening, = I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in = order to get some discussion going. Due to the lack of knowledge about a = better place, let's meet up at the entrance of the convention center = (TICC). Please email me if you are interested. >>=20 >> BR >> Ren=E9 >>=20 >>=20 >>=20 >> -- >> Dipl.-Inform. Rene Hummen, Ph.D. Student >> Chair of Communication and Distributed Systems >> RWTH Aachen University, Germany >> tel: +49 241 80 20772 >> web: >> http://www.comsys.rwth-aachen.de/team/rene-hummen/ >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> hiprg mailing list >>=20 >> hiprg@irtf.org >> https://www.irtf.org/mailman/listinfo/hiprg >>=20 >>=20 >> -- >> email: >> rstruik.ext@gmail.com >>=20 >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >>=20 >>=20 >>=20 >> -- >> email: >> rstruik.ext@gmail.com >>=20 >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >>=20 >>=20 >>=20 >> -- >> email: >> rstruik.ext@gmail.com >>=20 >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> Dipl.-Inform. Rene Hummen, Ph.D. Student >> Chair of Communication and Distributed Systems >> RWTH Aachen University, Germany >> tel: +49 241 80 20772 >> web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: Zach Shelby >> To: "core@ietf.org WG" >> Cc: >> Date: Mon, 2 Jan 2012 16:03:19 +0200 >> Subject: [core] Fwd: New Version Notification for = draft-shelby-core-interfaces-00.txt >> http://www.ietf.org/id/draft-shelby-core-interfaces-00.txt >>=20 >> Here is a new draft that describes a model for REST interface = descriptions for use with the link format, that I have been using in = various contexts for a long time. Now I wanted to start developing this = further in CoRE - please give it a spin in your own server design and = will be glad to hear feedback and ideas. >>=20 >> Regards, >> Zach >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: January 2, 2012 3:59:25 PM GMT+02:00 >>> To: zach@sensinode.com >>> Cc: zach@sensinode.com >>> Subject: New Version Notification for = draft-shelby-core-interfaces-00.txt >>>=20 >>> A new version of I-D, draft-shelby-core-interfaces-00.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >>>=20 >>> Filename: draft-shelby-core-interfaces >>> Revision: 00 >>> Title: CoRE Interfaces >>> Creation date: 2012-01-02 >>> WG ID: Individual Submission >>> Number of pages: 11 >>>=20 >>> Abstract: >>> This document defines well-known interface descriptions for Batch, >>> Sensor, Parameter and Actuator types for use in contrained web >>> servers using the CoRE Link Format. A short reference is provided >>> for each type that can be efficiently included in the interface >>> description attribute of the CoRE Link Format. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >>=20 >>=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: "core issue tracker" >> To: zach@sensinode.com >> Cc: core@ietf.org >> Date: Mon, 02 Jan 2012 16:25:44 -0000 >> Subject: [core] #180: Update ABNF for queries >> #180: Update ABNF for queries >>=20 >> Esko's comments on the link-format document got Zach and me thinking = about >> our usage of ptoken again. >>=20 >> In link-format-09, the syntax for the queries in the URIs says: >>=20 >> filter-query =3D resource-param "=3D" query-pattern >> resource-param =3D "uri" / parmname >> query-pattern =3D ptoken [ "*" ] >> ptoken =3D >>=20 >> Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, = not >> in a URI. >> Looking more closely: >>=20 >> ptoken =3D 1*ptokenchar >> ptokenchar =3D "!" | "#" | "$" | "%" | "&" | "'" | "(" >> | ")" | "*" | "+" | "-" | "." | "/" | DIGIT >> | ":" | "<" | "=3D" | ">" | "?" | "@" | ALPHA >> | "[" | "]" | "^" | "_" | "`" | "{" | "|" >> | "}" | "~" >>=20 >> Oops, that actually includes "*" and "&"! >> There also is no mention of percent-encoding (of course not, because >> RFC2616 does not percent-encode headers). >>=20 >> So what we really want to import here is RFC3986 ABNF, not = RFC2616/RFC5988 >> ABNF. >>=20 >> First attempt: >>=20 >> query-pattern =3D search-token [ "*" ] >> search-token =3D *pchar >>=20 >> But pchar (RFC3986) includes subdelims: >>=20 >> pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" >>=20 >> query =3D *( pchar / "/" / "?" ) >>=20 >> pct-encoded =3D "%" HEXDIG HEXDIG >> unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" >> sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" >> / "*" / "+" / "," / ";" / "=3D" >>=20 >> ... which includes "*" and "&". >>=20 >> So, to do this right, let's mix this properly: >>=20 >> query-pattern =3D search-token [ "*" ] >> search-token =3D *search-char >> search-char =3D unreserved / pct-encoded >> / ":" / "@" ; from pchar >> / "/" / "?" ; from query >> / "!" / "$" / "'" / "(" / ")" >> / "+" / "," / ";" / "=3D" ; from sub-delims >>=20 >>=20 >> :@/?!$'()+,;=3D indeed. >>=20 >>=20 >> This makes it possible to say something like: >>=20 >> GET /.well-known/core?rt=3Doutdoor%20temperature >>=20 >> After the percent-decoding defined in core-coap's URI parsing = (section >> 6.4), the server will see: >>=20 >> Uri-Path .well-known >> Uri-Path core >> Uri-Query rt=3Doutdoor temperature >>=20 >> which sounds about right. >>=20 >> The parser in the server will now just have to >> 1) search for the first "=3D" and use that to delimit the parameter = name >> from the search-token >> 2) check for a trailing "*" and remove that, if present, indicating a >> prefix match. >>=20 >> Would I use spaces for rt values? Probably not, but there are still = good >> reasons for staying general here. >> As the percent-decoding is already done when the server sees it, = there is >> no cost to this generality, either. >>=20 >> The defnition of query-pattern also needs to be updated. >>=20 >> -- >> -------------------------+-------------------- >> Reporter: zach@... | Owner: zach@... >> Type: editorial | Status: new >> Priority: minor | Milestone: >> Component: link-format | Version: >> Severity: - | Keywords: >> -------------------------+-------------------- >>=20 >> Ticket URL: >> core >>=20 >>=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: "core issue tracker" >> To: zach@sensinode.com >> Cc: core@ietf.org >> Date: Mon, 02 Jan 2012 16:35:09 -0000 >> Subject: Re: [core] #178: Multiple relation types >> #178: Multiple relation types >>=20 >>=20 >> Comment (by zach@...): >>=20 >> Done. >>=20 >> -- >> ----------------------------------+--------------------- >> Reporter: zach@... | Owner: zach@... >> Type: protocol enhancement | Status: new >> Priority: minor | Milestone: >> Component: link-format | Version: >> Severity: - | Resolution: >> Keywords: | >> ----------------------------------+--------------------- >>=20 >> Ticket URL: = >> core >>=20 >>=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: "core issue tracker" >> To: zach@sensinode.com >> Cc: core@ietf.org >> Date: Mon, 02 Jan 2012 16:35:20 -0000 >> Subject: Re: [core] #178: Multiple relation types >> #178: Multiple relation types >>=20 >> Changes (by zach@...): >>=20 >> * status: new =3D> closed >> * resolution: =3D> fixed >>=20 >>=20 >> -- >> ----------------------------------+--------------------- >> Reporter: zach@... | Owner: zach@... >> Type: protocol enhancement | Status: closed >> Priority: minor | Milestone: >> Component: link-format | Version: >> Severity: - | Resolution: fixed >> Keywords: | >> ----------------------------------+--------------------- >>=20 >> Ticket URL: = >> core >>=20 >>=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: "core issue tracker" >> To: zach@sensinode.com >> Cc: core@ietf.org >> Date: Mon, 02 Jan 2012 16:38:18 -0000 >> Subject: Re: [core] #179: SHOULD NOT for multicast response = repression >> #179: SHOULD NOT for multicast response repression >>=20 >> Changes (by zach@...): >>=20 >> * status: new =3D> closed >> * resolution: =3D> fixed >>=20 >>=20 >> Comment: >>=20 >> Done: >>=20 >> "When using a transfer protocol like the Constrained Application = Protocol >> (CoAP) that supports multicast requests, special care is taken. A >> multicast request with a query string SHOULD NOT be responded to if >> filtering is not supported or if the filter does not match (to avoid = a >> needless response storm). The exception is in cases where the IP = stack >> interface is not able to indicate that the source address was = multicast." >>=20 >> -- >> ----------------------------------+--------------------- >> Reporter: zach@... | Owner: zach@... >> Type: protocol enhancement | Status: closed >> Priority: minor | Milestone: >> Component: link-format | Version: >> Severity: - | Resolution: fixed >> Keywords: | >> ----------------------------------+--------------------- >>=20 >> Ticket URL: = >> core >>=20 >>=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: "core issue tracker" >> To: zach@sensinode.com >> Cc: core@ietf.org >> Date: Mon, 02 Jan 2012 16:41:54 -0000 >> Subject: Re: [core] #180: Update ABNF for queries >> #180: Update ABNF for queries >>=20 >> Changes (by zach@...): >>=20 >> * status: new =3D> closed >> * resolution: =3D> fixed >>=20 >>=20 >> Comment: >>=20 >> Done. >>=20 >> -- >> -------------------------+--------------------- >> Reporter: zach@... | Owner: zach@... >> Type: editorial | Status: closed >> Priority: minor | Milestone: >> Component: link-format | Version: >> Severity: - | Resolution: fixed >> Keywords: | >> -------------------------+--------------------- >>=20 >> Ticket URL: = >> core >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ________________________________ > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From internet-drafts@ietf.org Thu Jan 12 15:29:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F20021F8688; Thu, 12 Jan 2012 15:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8oHuYlGn+Hn; Thu, 12 Jan 2012 15:29:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2157521F8588; Thu, 12 Jan 2012 15:29:54 -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: 3.64p1 Message-ID: <20120112232954.15845.45058.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 15:29:54 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-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: Thu, 12 Jan 2012 23:29:54 -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 Work= ing Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-05.txt Pages : 27 Date : 2012-01-12 CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-block-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-block-05.txt From trac+core@trac.tools.ietf.org Thu Jan 12 15:29:55 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DCA21F8609 for ; Thu, 12 Jan 2012 15:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKdEexTKiJ2d for ; Thu, 12 Jan 2012 15:29:54 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DA30C21F85E0 for ; Thu, 12 Jan 2012 15:29:54 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RlU5e-00022a-GF; Thu, 12 Jan 2012 18:29:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: cabo@tzi.org X-Trac-Project: core Date: Thu, 12 Jan 2012 23:29:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/169#comment:1 Message-ID: <072.1a5a14b19b02233771d0b1c5aa97e912@trac.tools.ietf.org> References: <057.e04ba9c35463383e966ae8516dc094a1@trac.tools.ietf.org> X-Trac-Ticket-ID: 169 In-Reply-To: <057.e04ba9c35463383e966ae8516dc094a1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #169: Draft re-write 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: Thu, 12 Jan 2012 23:29:55 -0000 #169: Draft re-write Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed in [477]: -05 (Friday 13th edition): Fix #169 -- the great rewrite. (Editorial only -- no technical changes intended.) -- -----------------------+--------------------- Reporter: zach@… | Owner: cabo@… Type: editorial | Status: closed Priority: major | Milestone: Component: block | Version: Severity: - | Resolution: fixed Keywords: | -----------------------+--------------------- Ticket URL: core From cabo@tzi.org Thu Jan 12 15:44:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1584D21F86DB for ; Thu, 12 Jan 2012 15:44:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0ehCF3FCKPN for ; Thu, 12 Jan 2012 15:44: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 22D5021F86A8 for ; Thu, 12 Jan 2012 15:44: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 q0CNiSib026904 for ; Fri, 13 Jan 2012 00:44:28 +0100 (CET) Received: from [192.168.217.117] (p5489B0DB.dip.t-dialin.net [84.137.176.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C61914C5; Fri, 13 Jan 2012 00:44:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20120112232954.15845.45058.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 00:44:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120112232954.15845.45058.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1251.1) Subject: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-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: Thu, 12 Jan 2012 23:44:42 -0000 A day late (the old draft expired 15.5 hours ago, oops): Here is the Friday 13th edition of -block. =20 I hope that is not too scary :-) block-05 is trying to solve the editorial problems (#169). No technical changes are intended from the July 11th version, -04. Please read this version again and indicate whether this is still = near-unreadable. The draft is now deliberately preferring redundancy over unreadable = terseness. This blew up the actual specification part (section 2) to 7 pages. =20 Oh well, it is still a very simple mechanism. If we want to, we can fix the small remaining technical issues #170 and = #171 in the next couple of days when we have the editorial stuff behind = us. Enjoy! Gr=FC=DFe, Carsten On Jan 13, 2012, at 00:29, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Blockwise transfers in CoAP > Author(s) : Carsten Bormann > Zach Shelby > Filename : draft-ietf-core-block-05.txt > Pages : 27 > Date : 2012-01-12 >=20 > CoAP is a RESTful transfer protocol for constrained nodes and > networks. Basic CoAP messages work well for the small payloads we > expect from temperature sensors, light switches, and similar > building-automation devices. Occasionally, however, applications > will need to transfer larger payloads -- for instance, for firmware > updates. With HTTP, TCP does the grunt work of slicing large > payloads up into multiple packets and ensuring that they all arrive > and are handled in the right order. >=20 > CoAP is based on datagram transports such as UDP or DTLS, which > limits the maximum size of resource representations that can be > transferred without too much fragmentation. Although UDP supports > larger payloads through IP fragmentation, it is limited to 64 KiB > and, more importantly, doesn't really work well for constrained > applications and networks. >=20 > Instead of relying on IP fragmentation, this specification extends > basic CoAP with a pair of "Block" options, for transferring multiple > blocks of information from a resource representation in multiple > request-response pairs. In many important cases, the Block options > enable a server to be truly stateless: the server can handle each > block transfer separately, with no need for a connection setup or > other server-side memory of previous block transfers. >=20 > In summary, the Block options provide a minimal way to transfer > larger representations in a block-wise fashion. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-core-block-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-block-05.txt >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From Bert.Greevenbosch@huawei.com Thu Jan 12 18:40:52 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE3221F8503 for ; Thu, 12 Jan 2012 18:40:52 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFQBBar1FmKy for ; Thu, 12 Jan 2012 18:40:51 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6A721F84F2 for ; Thu, 12 Jan 2012 18:40:51 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXP002YMU3T6Y@szxga04-in.huawei.com> for core@ietf.org; Fri, 13 Jan 2012 10:40:41 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXP00CV5U3TGX@szxga04-in.huawei.com> for core@ietf.org; Fri, 13 Jan 2012 10:40:41 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGK41545; Fri, 13 Jan 2012 10:40:40 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 10:40:30 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.21]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 13 Jan 2012 10:40:31 +0800 Date: Fri, 13 Jan 2012 02:40:30 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.135] To: "core@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB62321FB85@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/evjCcYRjZ6xRWeMddb00Q)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: Block GETs beyond resource size Thread-index: AczRnLXaaZMvoXioQwySY9Pyy0KS0Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BdT3 B01J CACQ CFmP Cn1A CtKG EG1P FJz1 FSd/ GEoI GQ8m HBO5 HDfJ HX+m KEBZ KK4y; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {72CCDE51-093C-490A-87C6-22A420E96140}; YgBlAHIAdAAuAGcAcgBlAGUAdgBlAG4AYgBvAHMAYwBoAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 13 Jan 2012 02:40:28 GMT; QgBsAG8AYwBrACAARwBFAFQAcwAgAGIAZQB5AG8AbgBkACAAcgBlAHMAbwB1AHIAYwBlACAAcwBpAHoAZQA= x-cr-puzzleid: {72CCDE51-093C-490A-87C6-22A420E96140} X-CFilter-Loop: Reflected Subject: [core] Block GETs beyond resource size 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, 13 Jan 2012 02:40:52 -0000 --Boundary_(ID_/evjCcYRjZ6xRWeMddb00Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, While reviewing the Block draft, I noticed that there are not yet much error cases considered. I am particularly wondering about a GET request from the client to the server, for a block beyond the size of the resource. For example, what will the server do when it receives a (BLOCK2, block size=512, block number=3) GET for a resource with a size of only 800 bytes? It seems obvious that the server should send an error code. But which one? "4.00 Bad Request", "4.02 Bad Option", "4.04 Not Found", "4.06 Not Acceptable" all seem appropriate, though none of them is descriptive about the particular error. I found that there used to be a "4.13 Request Block Error" code, but that was changed to "4.13 Request Entity to Large". Do folks think we need to add some text about this to the Block draft, or may even need to define a new error code? Best regards, Bert --Boundary_(ID_/evjCcYRjZ6xRWeMddb00Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

While reviewing the Block draft, I noticed that there are not yet much error cases considered.

 

I am particularly wondering about a GET request from the client to the server, for a block beyond the size of the resource. For example, what will the server do when it receives a (BLOCK2, block size=512, block number=3) GET for a resource with a size of only 800 bytes?

 

It seems obvious that the server should send an error code. But which one? "4.00 Bad Request", "4.02 Bad Option", "4.04 Not Found", "4.06 Not Acceptable" all seem appropriate, though none of them is descriptive about the particular error.

 

I found that there used to be a "4.13 Request Block Error" code, but that was changed to "4.13 Request Entity to Large".

 

Do folks think we need to add some text about this to the Block draft, or may even need to define a new error code?

 

Best regards,

Bert

 

--Boundary_(ID_/evjCcYRjZ6xRWeMddb00Q)-- From cabo@tzi.org Thu Jan 12 23:01:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC98621F85D7 for ; Thu, 12 Jan 2012 23:01:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve3D0lcANcaq for ; Thu, 12 Jan 2012 23:01:01 -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 1C5DF21F854B for ; Thu, 12 Jan 2012 23:00: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 q0D70j3n008541; Fri, 13 Jan 2012 08:00:45 +0100 (CET) Received: from [192.168.217.112] (p5489B0DB.dip.t-dialin.net [84.137.176.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B4F304EF; Fri, 13 Jan 2012 08:00:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB62321FB85@szxeml509-mbx.china.huawei.com> Date: Fri, 13 Jan 2012 08:00:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <937BAA79-93AE-4C3B-B547-54127B1F1351@tzi.org> References: <46A1DF3F04371240B504290A071B4DB62321FB85@szxeml509-mbx.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org" Subject: Re: [core] Block GETs beyond resource size 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, 13 Jan 2012 07:01:02 -0000 Bert, good point. On Jan 13, 2012, at 03:40, Bert Greevenbosch wrote: > It seems obvious that the server should send an error code. One other way to handle this would be to respond with a 2.05 with an = empty payload and M=3D0. In UNIX, this is what you get when you seek behind the EOF and try to = read. Clearly, when you GET exactly at the end (e.g., have 1024 bytes of = payload and do a GET with Block2/2/0/512), you get back a zero-length = payload, so there already need to be code paths handling these. I really don't have a strong feeling whether this "seeking/reading = beyond the end" needs another error code or is "normal" as it would be = in UNIX. When can this happen? If clients follow the sequential protocol, this = can only happen when the size of the resource has changed. This should = lead to a new ETag, so the client knows it cannot use the current = assembly, so it will have to restart from 0. The only adverse effect of = an empty 2.05 could be that a not so bright client might allocate a new = buffer to the size of the current seek position (as it meaningfully = would do if it did get data). If you "don't do that"=99, there is no = problem. Once we have a Size option, sending this back in conjunction with an = empty 2.05 might a nice way to respond to a Block2 seek beyond the end. With Block1 (and PUT), seeking beyond the end might be an immediate 4.08 = error for an atomic server, or it might also simply be executed (with = UNIX' hole-filling semantics) by a stateless server, so I think we are = covered there. Interesting discussion! Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Fri Jan 13 01:48:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CB321F8592 for ; Fri, 13 Jan 2012 01:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3BtNggw4rbX for ; Fri, 13 Jan 2012 01:48:33 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 68B1C21F8578 for ; Fri, 13 Jan 2012 01:48:33 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RldkN-0000Ku-Nc; Fri, 13 Jan 2012 04:48:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 13 Jan 2012 09:48:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/174#comment:2 Message-ID: <068.ba2fceff6eb02865994d6682984294a2@trac.tools.ietf.org> References: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #174: Robust observation relationships 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, 13 Jan 2012 09:48:33 -0000 #174: Robust observation relationships Changes (by cabo@…): * status: closed => reopened * resolution: fixed => Comment: In Taipei, we had a discussion about the complexity caused by Max-OFE. Instead of coupling the hold-off for re-establishing observation relationships to freshness, we should keep the two concepts separate. An option sent by the server to the client could indicate the amount of time the server promises not to give up the observation relationship. Making this time relative to the point in time when freshness runs out allows a convenient default of 0. -- -----------------------------------+----------------------- Reporter: hartke@… | Owner: hartke@… Type: protocol defect | Status: reopened Priority: major | Milestone: Component: observe | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+----------------------- Ticket URL: core From esko.dijk@philips.com Fri Jan 13 01:58:07 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5516D21F85D8 for ; Fri, 13 Jan 2012 01:58:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18kySm7aH-tl for ; Fri, 13 Jan 2012 01:58:06 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id E68FB21F85D4 for ; Fri, 13 Jan 2012 01:58:05 -0800 (PST) Received: from mail61-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jan 2012 09:58:04 +0000 Received: from mail61-am1 (localhost [127.0.0.1]) by mail61-am1-R.bigfish.com (Postfix) with ESMTP id 0BE83200663; Fri, 13 Jan 2012 09:58:03 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz8275ch1033IL8275bh8275dhz2dhc1ahc1bh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail61-am1 (localhost.localdomain [127.0.0.1]) by mail61-am1 (MessageSwitch) id 1326448682911514_22407; Fri, 13 Jan 2012 09:58:02 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.244]) by mail61-am1.bigfish.com (Postfix) with ESMTP id CFF79680045; Fri, 13 Jan 2012 09:58:02 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jan 2012 09:57:59 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.189]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.01.0355.003; Fri, 13 Jan 2012 09:58:59 +0000 From: "Dijk, Esko" To: Zach Shelby Thread-Topic: [core] Moving Observe forward Thread-Index: AQHMysWZhYE+g/QC0U+Bxa9bQGex6pYKFLRQ Date: Fri, 13 Jan 2012 09:57:58 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180485D8@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> In-Reply-To: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: 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] Moving Observe forward 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, 13 Jan 2012 09:58:07 -0000 Hello Zach, The discussion in the minutes shows a tension between two design views for = this option: 1) "extend freshness" view as in RFC 5861; allow to serve stale content ; w= hich is currently the view of Max-OFE 2) defining Max-Age and "refresh after time T" options (with T < Max-Age) ;= stale content is never served. Both views seem to amount to the same thing, once implemented? In both case= s it gives a cache some well-defined time period to try and re-establish an= observe relation before the content in the cache finally "really" expires. Without a Max-OFE option or similar, a cache can still implement such beha= viour but has to estimate the right time (when to try re-establish an obser= ve relation) itself. If this is correct I'm ok with removing the option for= the time being. regards Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: Wednesday 4 January 2012 10:45 To: core@ietf.org WG Subject: [core] Moving Observe forward I have been going through the IETF82 minutes (http://tools.ietf.org/wg/core= /minutes) and updating tickets etc. The discussion on the new Max-OFE optio= n that was added to observe-03 is interesting reading for those of you that= were not there. That discussion left me feeling like we were premature in adding this optio= n to Observe, as it clearly has nothing near WG consensus. I am not convinc= ed that we even need it at this point. Observe otherwise is in really good shape, and the WG seemed to think in Ta= ipei that it would be ready for WGLC if this Max-OFE problem would be taken= care of. My proposal would be to dump Max-OFE into a separate personal draft for fut= ure discussion and work, it could be standardized in that or some other for= m later. That would leave the Observe WG document ready for WGLC, but allow= continued work on the idea. What do others think? Zach -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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 esko.dijk@philips.com Fri Jan 13 02:43:31 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E4D21F85F8 for ; Fri, 13 Jan 2012 02:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYEODhqB-heE for ; Fri, 13 Jan 2012 02:43:31 -0800 (PST) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 992A521F85F7 for ; Fri, 13 Jan 2012 02:43:20 -0800 (PST) Received: from mail58-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jan 2012 10:43:20 +0000 Received: from mail58-va3 (localhost [127.0.0.1]) by mail58-va3-R.bigfish.com (Postfix) with ESMTP id EC2C95C02FA for ; Fri, 13 Jan 2012 10:43:19 +0000 (UTC) X-SpamScore: -41 X-BigFish: VPS-41(zz217bL15d6O9251J936eK542Mzz1202hzz1033IL8275dhz2dhc1ahc1bh2a8h668h839h93fh) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail58-va3 (localhost.localdomain [127.0.0.1]) by mail58-va3 (MessageSwitch) id 1326451399193704_31896; Fri, 13 Jan 2012 10:43:19 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.251]) by mail58-va3.bigfish.com (Postfix) with ESMTP id 1F5D9280065 for ; Fri, 13 Jan 2012 10:43:19 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jan 2012 10:43:19 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.189]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.01.0355.003; Fri, 13 Jan 2012 10:44:19 +0000 From: "Dijk, Esko" To: "core@ietf.org WG" Thread-Topic: New Version Notification for draft-dijk-core-groupcomm-misc-00.txt Thread-Index: AQHM0d4dRi8qU8c4W0GRFGrOk1k2/JYKG95Q Date: Fri, 13 Jan 2012 10:43:18 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618048650@011-DB3MPN1-013.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] New Version Notification for draft-dijk-core-groupcomm-misc-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 10:43:31 -0000 RGVhciBhbGwsDQoNCmZvbGxvd2luZyB0aGUgc3VnZ2VzdGlvbiBtYWRlIGR1cmluZyB0aGUgSUVU RiA4MiBtZWV0aW5nLCB0aGUgcGFydHMgcmVtb3ZlZCBmcm9tIHRoZSBHcm91cENvbW0gSS1EIGFy ZSBub3cgcHV0IGluIGEgc2VwYXJhdGUgZG9jdW1lbnQgZm9yIHJlZmVyZW5jZQ0KaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kaWprLWNvcmUtZ3JvdXBjb21tLW1pc2MvDQoN CnJlZ2FyZHMsDQpFc2tvIGFuZCBBa2Jhcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KU2VudDogRnJpZGF5IDEzIEphbnVhcnkgMjAxMiAxMToyOQ0KVG86IERpamssIEVz a28NCkNjOiBha2Jhci5yYWhtYW5AaW50ZXJkaWdpdGFsLmNvbTsgRGlqaywgRXNrbw0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kaWprLWNvcmUtZ3JvdXBjb21t LW1pc2MtMDAudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kaWprLWNvcmUtZ3Jv dXBjb21tLW1pc2MtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRXNr byBEaWprIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAg ICAgICBkcmFmdC1kaWprLWNvcmUtZ3JvdXBjb21tLW1pc2MNClJldmlzaW9uOiAgICAgICAgMDAN ClRpdGxlOiAgICAgICAgICAgTWlzY2VsbGFuZW91cyBDb0FQIEdyb3VwIENvbW11bmljYXRpb24g VG9waWNzDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTItMDEtMTMNCldHIElEOiAgICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDkNCg0KQWJzdHJhY3Q6DQogICBU aGlzIGRvY3VtZW50IGNvbnRhaW5zIG1pc2NlbGxhbmVvdXMgdGV4dCBhcm91bmQgdGhlIHRvcGlj IG9mIGdyb3VwDQogICBjb21tdW5pY2F0aW9uIGZvciB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRp b24gUHJvdG9jb2wgKENvQVApLiAgVGhlDQogICBmaXJzdCBwYXJ0IGNvbnRhaW5zLCBmb3IgcmVm ZXJlbmNlLCB0ZXh0IHRoYXQgd2FzIHJlbW92ZWQgZnJvbSB0aGUNCiAgIEdyb3VwIENvbW11bmlj YXRpb24gZm9yIENvQVAgZHJhZnQuICBUaGUgc2Vjb25kIHBhcnQgZGVzY3JpYmVzIGdyb3VwDQog ICBjb21tdW5pY2F0aW9uIGFuZCBtdWx0aWNhc3QgZnVuY3Rpb25hbGl0eSB0aGF0IG1heSBiZSBp bnB1dCB0byBmdXR1cmUNCiAgIHN0YW5kYXJkaXphdGlvbiBpbiB0aGUgQ29SRSBXRy4NCg0KDQoN Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25m aWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUg bWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9m IHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRo ZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBv cmlnaW5hbCBtZXNzYWdlLg0K From zach@sensinode.com Fri Jan 13 03:40:03 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04B021F852B for ; Fri, 13 Jan 2012 03:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ozGYpZ9bfKp for ; Fri, 13 Jan 2012 03:40:03 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AA8B421F8516 for ; Fri, 13 Jan 2012 03:40:02 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q0DBdxb7031028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jan 2012 13:39:59 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180485D8@011-DB3MPN1-013.MGDPHG.emi.philips.com> Date: Fri, 13 Jan 2012 13:39:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CB90C67-17DC-4A50-AA22-A1CDD0A4FBB5@sensinode.com> References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <031DD135F9160444ABBE3B0C36CED6180485D8@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] Moving Observe forward 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, 13 Jan 2012 11:40:04 -0000 Hi, On Jan 13, 2012, at 11:57 AM, Dijk, Esko wrote: > Hello Zach, >=20 > The discussion in the minutes shows a tension between two design views = for this option: > 1) "extend freshness" view as in RFC 5861; allow to serve stale = content ; which is currently the view of Max-OFE > 2) defining Max-Age and "refresh after time T" options (with T < = Max-Age) ; stale content is never served. Except 2) isn't really useful in the Observe relationship. Someone just = threw out that idea during the meeting as a possible Max-OFE = alternative. The main tension was just that people really didn't agree = with adding the Max-OFE option in the first place. But then again we = were told at a previous meeting (Quebec?) to go solve this problem...=20 > Both views seem to amount to the same thing, once implemented? In both = cases it gives a cache some well-defined time period to try and = re-establish an observe relation before the content in the cache finally = "really" expires. >=20 > Without a Max-OFE option or similar, a cache can still implement such = behaviour but has to estimate the right time (when to try re-establish = an observe relation) itself. If this is correct I'm ok with removing the = option for the time being. Correct.=20 Now, Carsten brings up an interesting idea in re-opening Ticket #174, = that these things could be decoupled from each other. Let's explore if = that makes any sense.=20 Zach=20 >=20 > regards > Esko >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Zach Shelby > Sent: Wednesday 4 January 2012 10:45 > To: core@ietf.org WG > Subject: [core] Moving Observe forward >=20 > I have been going through the IETF82 minutes = (http://tools.ietf.org/wg/core/minutes) and updating tickets etc. The = discussion on the new Max-OFE option that was added to observe-03 is = interesting reading for those of you that were not there. >=20 > That discussion left me feeling like we were premature in adding this = option to Observe, as it clearly has nothing near WG consensus. I am not = convinced that we even need it at this point. >=20 > Observe otherwise is in really good shape, and the WG seemed to think = in Taipei that it would be ready for WGLC if this Max-OFE problem would = be taken care of. >=20 > My proposal would be to dump Max-OFE into a separate personal draft = for future discussion and work, it could be standardized in that or some = other form later. That would leave the Observe WG document ready for = WGLC, but allow continued work on the idea. >=20 > What do others think? >=20 > Zach >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ________________________________ > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From internet-drafts@ietf.org Fri Jan 13 03:54:08 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3166F21F85CD; Fri, 13 Jan 2012 03:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2Km4K8INvio; Fri, 13 Jan 2012 03:54:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A4321F85A5; Fri, 13 Jan 2012 03:54:07 -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: 3.64p1 Message-ID: <20120113115407.9398.35513.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 03:54:07 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-link-format-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 11:54:08 -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 Work= ing Group of the IETF. Title : CoRE Link Format Author(s) : Zach Shelby Filename : draft-ietf-core-link-format-10.txt Pages : 20 Date : 2012-01-13 This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-10.txt From zach@sensinode.com Fri Jan 13 04:16:26 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FE221F8565; Fri, 13 Jan 2012 04:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SlvXLpz19tS; Fri, 13 Jan 2012 04:16:25 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8699D21F852B; Fri, 13 Jan 2012 04:16:25 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q0DCGKqo006049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jan 2012 14:16:24 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <20120113115407.9398.35513.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 14:16:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5FFB87E6-7A07-49C8-9EC1-AAE080CBD2ED@sensinode.com> References: <20120113115407.9398.35513.idtracker@ietfa.amsl.com> To: Internet-Drafts@ietf.org X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] I-D Action: draft-ietf-core-link-format-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 12:16:26 -0000 This new version of the draft now closes all the tickets and editorial = comments resulting from WGLC. Zach On Jan 13, 2012, at 1:54 PM, Internet-Drafts@ietf.org wrote: >=20 > 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. >=20 > Title : CoRE Link Format > Author(s) : Zach Shelby > Filename : draft-ietf-core-link-format-10.txt > Pages : 20 > Date : 2012-01-13 >=20 > This document defines Web Linking using a link format for use by > constrained web servers to describe hosted resources, their > attributes and other relationships between links. Based on the HTTP > Link Header format defined in RFC5988, the CoRE Link Format is > carried as a payload and is assigned an Internet media type. A = well- > known URI is defined as a default entry-point for requesting the > links hosted by a server. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-10.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-10.txt >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From esko.dijk@philips.com Fri Jan 13 05:49:07 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E559F21F86A0 for ; Fri, 13 Jan 2012 05:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAz2-PFqCgMS for ; Fri, 13 Jan 2012 05:49:04 -0800 (PST) Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id D31B821F869F for ; Fri, 13 Jan 2012 05:49:02 -0800 (PST) Received: from mail132-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jan 2012 13:49:01 +0000 Received: from mail132-tx2 (localhost [127.0.0.1]) by mail132-tx2-R.bigfish.com (Postfix) with ESMTP id CB034600783; Fri, 13 Jan 2012 13:49:01 +0000 (UTC) X-SpamScore: -51 X-BigFish: VPS-51(zz217bL15d6O9371I9251J936eK542M1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2dhc1ahc1bh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail132-tx2 (localhost.localdomain [127.0.0.1]) by mail132-tx2 (MessageSwitch) id 1326462541625168_6283; Fri, 13 Jan 2012 13:49:01 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.240]) by mail132-tx2.bigfish.com (Postfix) with ESMTP id 8824F54004B; Fri, 13 Jan 2012 13:49:01 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jan 2012 13:48:59 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.189]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.01.0355.003; Fri, 13 Jan 2012 13:49:59 +0000 From: "Dijk, Esko" To: Zach Shelby Thread-Topic: [core] I-D Action: draft-ietf-core-link-format-10.txt Thread-Index: AQHM0epLbfI/kKzpYEaV1N+XXmcoS5YKNnOAgAAWNzA= Date: Fri, 13 Jan 2012 13:48:57 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180486C5@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <20120113115407.9398.35513.idtracker@ietfa.amsl.com> <5FFB87E6-7A07-49C8-9EC1-AAE080CBD2ED@sensinode.com> In-Reply-To: <5FFB87E6-7A07-49C8-9EC1-AAE080CBD2ED@sensinode.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: 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] I-D Action: draft-ietf-core-link-format-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 13:49:08 -0000 Just one remark left ;) "The exception is in cases where the IP stack interface is not able to in= dicate that the source address was multicast." -> it should be "destination address was multicast". Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: Friday 13 January 2012 13:16 To: Internet-Drafts@ietf.org Cc: core@ietf.org WG Subject: Re: [core] I-D Action: draft-ietf-core-link-format-10.txt This new version of the draft now closes all the tickets and editorial comm= ents resulting from WGLC. Zach On Jan 13, 2012, at 1:54 PM, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Constrained RESTful Environments Wo= rking Group of the IETF. > > Title : CoRE Link Format > Author(s) : Zach Shelby > Filename : draft-ietf-core-link-format-10.txt > Pages : 20 > Date : 2012-01-13 > > This document defines Web Linking using a link format for use by > constrained web servers to describe hosted resources, their > attributes and other relationships between links. Based on the HTTP > Link Header format defined in RFC5988, the CoRE Link Format is > carried as a payload and is assigned an Internet media type. A well- > known URI is defined as a default entry-point for requesting the > links hosted by a server. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-10.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-10.txt > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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 salvatore.loreto@ericsson.com Mon Jan 16 00:45:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8510C21F83EF for ; Mon, 16 Jan 2012 00:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMGrYu4BRo0y for ; Mon, 16 Jan 2012 00:45:28 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA6B21F84A2 for ; Mon, 16 Jan 2012 00:45:28 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-4a-4f13e3a733c0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.E3.09514.7A3E31F4; Mon, 16 Jan 2012 09:45:27 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 16 Jan 2012 09:45:26 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3F2E1231D for ; Mon, 16 Jan 2012 10:45:26 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 08D5751BC2 for ; Mon, 16 Jan 2012 10:45:26 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B8BC651843 for ; Mon, 16 Jan 2012 10:45:25 +0200 (EET) Message-ID: <4F13E3A5.3040704@ericsson.com> Date: Mon, 16 Jan 2012 10:45:25 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: core@ietf.org References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <031DD135F9160444ABBE3B0C36CED6180485D8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <2CB90C67-17DC-4A50-AA22-A1CDD0A4FBB5@sensinode.com> In-Reply-To: <2CB90C67-17DC-4A50-AA22-A1CDD0A4FBB5@sensinode.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Moving Observe forward 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, 16 Jan 2012 08:45:30 -0000 Hi Zach, I agree with you analysis that the Max-OFE option has been added prematurely to the draft without any discussion in the mailing list before doing it. Sorry, bu I am not convinced yet of the need for a second parameter; but happy and ready to change my mind in the case. Carsten replied me that it is necessary because both only the server will have something to base a statistical calculation on (e.g. related to the updates frequency) and also is the server that intends to act on the observation relationship; but I don't understand then because all of those can not be reflected in the Max-Age value About the idea present in the reopened ticket #174 an option sent by the server to the client indicating the amount of time the time the server promise not to give up the observation relationship looks to me quite similar to the "Lifetime" option, even if in this proposal is the server to decide the duration and not anymore the client to require it. cheers Salvatore On 1/13/12 1:39 PM, Zach Shelby wrote: > Hi, > > On Jan 13, 2012, at 11:57 AM, Dijk, Esko wrote: > >> Hello Zach, >> >> The discussion in the minutes shows a tension between two design views for this option: >> 1) "extend freshness" view as in RFC 5861; allow to serve stale content ; which is currently the view of Max-OFE >> 2) defining Max-Age and "refresh after time T" options (with T< Max-Age) ; stale content is never served. > Except 2) isn't really useful in the Observe relationship. Someone just threw out that idea during the meeting as a possible Max-OFE alternative. The main tension was just that people really didn't agree with adding the Max-OFE option in the first place. But then again we were told at a previous meeting (Quebec?) to go solve this problem... > >> Both views seem to amount to the same thing, once implemented? In both cases it gives a cache some well-defined time period to try and re-establish an observe relation before the content in the cache finally "really" expires. >> >> Without a Max-OFE option or similar, a cache can still implement such behaviour but has to estimate the right time (when to try re-establish an observe relation) itself. If this is correct I'm ok with removing the option for the time being. > Correct. > > Now, Carsten brings up an interesting idea in re-opening Ticket #174, that these things could be decoupled from each other. Let's explore if that makes any sense. > > Zach > >> regards >> Esko >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zach Shelby >> Sent: Wednesday 4 January 2012 10:45 >> To: core@ietf.org WG >> Subject: [core] Moving Observe forward >> >> I have been going through the IETF82 minutes (http://tools.ietf.org/wg/core/minutes) and updating tickets etc. The discussion on the new Max-OFE option that was added to observe-03 is interesting reading for those of you that were not there. >> >> That discussion left me feeling like we were premature in adding this option to Observe, as it clearly has nothing near WG consensus. I am not convinced that we even need it at this point. >> >> Observe otherwise is in really good shape, and the WG seemed to think in Taipei that it would be ready for WGLC if this Max-OFE problem would be taken care of. >> >> My proposal would be to dump Max-OFE into a separate personal draft for future discussion and work, it could be standardized in that or some other form later. That would leave the Observe WG document ready for WGLC, but allow continued work on the idea. >> >> What do others think? >> >> Zach >> >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> -- Salvatore Loreto www.sloreto.com From cabo@tzi.org Mon Jan 16 01:20:11 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F44F21F855E for ; Mon, 16 Jan 2012 01:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.804 X-Spam-Level: X-Spam-Status: No, score=-105.804 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HXR7CYaIwtD for ; Mon, 16 Jan 2012 01:20: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 872C321F855D for ; Mon, 16 Jan 2012 01:20:10 -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 q0G9K0kS008142; Mon, 16 Jan 2012 10:20:00 +0100 (CET) Received: from [192.168.217.112] (p5B3E6537.dip.t-dialin.net [91.62.101.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 62720CFF; Mon, 16 Jan 2012 10:20:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F13E3A5.3040704@ericsson.com> Date: Mon, 16 Jan 2012 10:19:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5BD81D4B-2731-499B-9C50-BD3834BE5AD6@tzi.org> References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <031DD135F9160444ABBE3B0C36CED6180485D8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <2CB90C67-17DC-4A50-AA22-A1CDD0A4FBB5@sensinode.com> <4F13E3A5.3040704@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1251.1) Cc: core@ietf.org Subject: Re: [core] Moving Observe forward 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, 16 Jan 2012 09:20:11 -0000 On Jan 16, 2012, at 09:45, Salvatore Loreto wrote: > About the idea present in the reopened ticket #174 > an option sent by the server to the client indicating the amount of = time the time the server > promise not to give up the observation relationship > looks to me quite similar to the "Lifetime" option, even if in this = proposal is the server to decide the duration > and not anymore the client to require it. The difference you mentioned plus the difference that a lifetime simple = runs out and requires re-establishing the observation relationship while = this "promise" can be renewed by the server in its every vital sign. Gr=FC=DFe, Carsten From salvatore.loreto@ericsson.com Mon Jan 16 03:32:14 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B3C21F85B9 for ; Mon, 16 Jan 2012 03:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr0UpalcDzHa for ; Mon, 16 Jan 2012 03:32:13 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0721F85B8 for ; Mon, 16 Jan 2012 03:32:13 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-7e-4f140abc830d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E1.02.23425.CBA041F4; Mon, 16 Jan 2012 12:32:12 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 16 Jan 2012 12:32:12 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 45FFD231D; Mon, 16 Jan 2012 13:32:12 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1264C51C95; Mon, 16 Jan 2012 13:32:12 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BCBD451843; Mon, 16 Jan 2012 13:32:11 +0200 (EET) Message-ID: <4F140ABB.9030002@ericsson.com> Date: Mon, 16 Jan 2012 13:32:11 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Carsten Bormann References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <031DD135F9160444ABBE3B0C36CED6180485D8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <2CB90C67-17DC-4A50-AA22-A1CDD0A4FBB5@sensinode.com> <4F13E3A5.3040704@ericsson.com> <5BD81D4B-2731-499B-9C50-BD3834BE5AD6@tzi.org> In-Reply-To: <5BD81D4B-2731-499B-9C50-BD3834BE5AD6@tzi.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "core@ietf.org" Subject: Re: [core] Moving Observe forward 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, 16 Jan 2012 11:32:14 -0000 Hi Carsten, yes I see the differences, but your proposal still implies some extra effort on the server even if minor that the one required when we had "Lifetime" option. However I don't get the need for an explicit signal. If I am and Observer and I receive back from the server an update with a Max-Age I assume that the server has set the Max-Age to that value, not randomly, but because it knows (based on some internal statistics) that after that that resource value will be different or because it want to force me to check with it anyway; so in the case I, as observer, don't receive anything I can resonable assume that I am not subscribe any more to the Server or something bad has happened to the server. of course a server can send a notification that does not contain Max-Age but that is another problem. -- Salvatore Loreto www.sloreto.com On 1/16/12 11:19 AM, Carsten Bormann wrote: > On Jan 16, 2012, at 09:45, Salvatore Loreto wrote: > >> About the idea present in the reopened ticket #174 >> an option sent by the server to the client indicating the amount of time the time the server >> promise not to give up the observation relationship >> looks to me quite similar to the "Lifetime" option, even if in this proposal is the server to decide the duration >> and not anymore the client to require it. > The difference you mentioned plus the difference that a lifetime simple runs out and requires re-establishing the observation relationship while this "promise" can be renewed by the server in its every vital sign. > > Grüße, Carsten > From tianlinyi@huawei.com Mon Jan 16 03:48:50 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04D21F85C0 for ; Mon, 16 Jan 2012 03:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf37vFcGS0k6 for ; Mon, 16 Jan 2012 03:48:49 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C4DE621F85BE for ; Mon, 16 Jan 2012 03:48:48 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00I2K3GR2T@szxga05-in.huawei.com> for core@ietf.org; Mon, 16 Jan 2012 19:48:27 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00FS93GRPF@szxga05-in.huawei.com> for core@ietf.org; Mon, 16 Jan 2012 19:48:27 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGI52621; Mon, 16 Jan 2012 19:48:25 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jan 2012 19:48:19 +0800 Received: from SZXEML513-MBS.china.huawei.com ([169.254.6.148]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Mon, 16 Jan 2012 19:48:19 +0800 Date: Mon, 16 Jan 2012 11:48:18 +0000 From: TianLinyi In-reply-to: <4F13E3A5.3040704@ericsson.com> X-Originating-IP: [172.24.1.45] To: Salvatore Loreto , "core@ietf.org" Message-id: <3615F3CCD55F054395A882F51C6E5FDA18241FAD@szxeml513-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] Moving Observe forward Thread-index: AQHMysWgFMNWDk8RXEW0EPtSP4WQMpYJmAAAgAAcgYCABIY4gIAAuE/B X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <031DD135F9160444ABBE3B0C36CED6180485D8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <2CB90C67-17DC-4A50-AA22-A1CDD0A4FBB5@sensinode.com> <4F13E3A5.3040704@ericsson.com> Subject: Re: [core] Moving Observe forward 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, 16 Jan 2012 11:48:50 -0000 SGksIEFsbA0KDQpJIGFtIHdvbmRlcmluZyB3aHkgdGhlIGNsaWVudCB3YW50cyB0byBleHRlbmQg dGhlIHBlcmlvZCByYXRoZXIgdGhhbiByZS1zdWJzY3JpYmUgdGhlIHJlbGF0aW9uc2hpcCBpZiBp dCByZWFsbHkgbmVlZHMuIFdoYXQgaXMgdGhlIGxvc3QgaWYgdGhlIGNsaWVudCBkb2Vzbid0IGRv IHNvPyANCg0KQ2hlZXJzLA0KTGlueWkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kt6K8/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW2NvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBTYWx2YXRvcmUgTG9yZXRvIFtzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29u LmNvbV0NCreiy83KsbzkOiAyMDEyxOox1MIxNsjVIDE2OjQ1DQq1vTogY29yZUBpZXRmLm9yZw0K 1vfM4jogUmU6IFtjb3JlXSBNb3ZpbmcgT2JzZXJ2ZSBmb3J3YXJkDQoNCkhpIFphY2gsDQoNCkkg YWdyZWUgd2l0aCB5b3UgYW5hbHlzaXMgdGhhdCB0aGUgTWF4LU9GRSBvcHRpb24gaGFzIGJlZW4g YWRkZWQNCnByZW1hdHVyZWx5IHRvIHRoZSBkcmFmdA0Kd2l0aG91dCBhbnkgZGlzY3Vzc2lvbiBp biB0aGUgbWFpbGluZyBsaXN0IGJlZm9yZSBkb2luZyBpdC4NClNvcnJ5LCBidSBJIGFtIG5vdCBj b252aW5jZWQgeWV0IG9mIHRoZSBuZWVkIGZvciBhIHNlY29uZCBwYXJhbWV0ZXI7IGJ1dA0KaGFw cHkgYW5kIHJlYWR5IHRvIGNoYW5nZSBteSBtaW5kIGluIHRoZSBjYXNlLg0KQ2Fyc3RlbiByZXBs aWVkIG1lIHRoYXQgaXQgaXMgbmVjZXNzYXJ5IGJlY2F1c2UgYm90aCBvbmx5IHRoZSBzZXJ2ZXIN CndpbGwgaGF2ZSBzb21ldGhpbmcgdG8gYmFzZSBhIHN0YXRpc3RpY2FsIGNhbGN1bGF0aW9uIG9u DQooZS5nLiByZWxhdGVkIHRvIHRoZSB1cGRhdGVzIGZyZXF1ZW5jeSkgYW5kIGFsc28gaXMgdGhl IHNlcnZlciB0aGF0DQppbnRlbmRzIHRvIGFjdCBvbiB0aGUgb2JzZXJ2YXRpb24gcmVsYXRpb25z aGlwOw0KYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGVuIGJlY2F1c2UgYWxsIG9mIHRob3NlIGNh biBub3QgYmUgcmVmbGVjdGVkIGluDQp0aGUgTWF4LUFnZSB2YWx1ZQ0KDQoNCkFib3V0IHRoZSBp ZGVhIHByZXNlbnQgaW4gdGhlIHJlb3BlbmVkIHRpY2tldCAjMTc0DQphbiBvcHRpb24gc2VudCBi eSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQgaW5kaWNhdGluZyB0aGUgYW1vdW50IG9mIHRpbWUN CnRoZSB0aW1lIHRoZSBzZXJ2ZXINCnByb21pc2Ugbm90IHRvIGdpdmUgdXAgdGhlIG9ic2VydmF0 aW9uIHJlbGF0aW9uc2hpcA0KbG9va3MgdG8gbWUgcXVpdGUgc2ltaWxhciB0byB0aGUgIkxpZmV0 aW1lIiBvcHRpb24sIGV2ZW4gaWYgaW4gdGhpcw0KcHJvcG9zYWwgaXMgdGhlIHNlcnZlciB0byBk ZWNpZGUgdGhlIGR1cmF0aW9uDQphbmQgbm90IGFueW1vcmUgdGhlIGNsaWVudCB0byByZXF1aXJl IGl0Lg0KDQpjaGVlcnMNClNhbHZhdG9yZQ0KDQpPbiAxLzEzLzEyIDE6MzkgUE0sIFphY2ggU2hl bGJ5IHdyb3RlOg0KPiBIaSwNCj4NCj4gT24gSmFuIDEzLCAyMDEyLCBhdCAxMTo1NyBBTSwgRGlq aywgRXNrbyB3cm90ZToNCj4NCj4+IEhlbGxvIFphY2gsDQo+Pg0KPj4gVGhlIGRpc2N1c3Npb24g aW4gdGhlIG1pbnV0ZXMgc2hvd3MgYSB0ZW5zaW9uIGJldHdlZW4gdHdvIGRlc2lnbiB2aWV3cyBm b3IgdGhpcyBvcHRpb246DQo+PiAxKSAiZXh0ZW5kIGZyZXNobmVzcyIgdmlldyBhcyBpbiBSRkMg NTg2MTsgYWxsb3cgdG8gc2VydmUgc3RhbGUgY29udGVudCA7IHdoaWNoIGlzIGN1cnJlbnRseSB0 aGUgdmlldyBvZiBNYXgtT0ZFDQo+PiAyKSBkZWZpbmluZyBNYXgtQWdlIGFuZCAicmVmcmVzaCBh ZnRlciB0aW1lIFQiIG9wdGlvbnMgKHdpdGggVDwgIE1heC1BZ2UpIDsgc3RhbGUgY29udGVudCBp cyBuZXZlciBzZXJ2ZWQuDQo+IEV4Y2VwdCAyKSBpc24ndCByZWFsbHkgdXNlZnVsIGluIHRoZSBP YnNlcnZlIHJlbGF0aW9uc2hpcC4gU29tZW9uZSBqdXN0IHRocmV3IG91dCB0aGF0IGlkZWEgZHVy aW5nIHRoZSBtZWV0aW5nIGFzIGEgcG9zc2libGUgTWF4LU9GRSBhbHRlcm5hdGl2ZS4gVGhlIG1h aW4gdGVuc2lvbiB3YXMganVzdCB0aGF0IHBlb3BsZSByZWFsbHkgZGlkbid0IGFncmVlIHdpdGgg YWRkaW5nIHRoZSBNYXgtT0ZFIG9wdGlvbiBpbiB0aGUgZmlyc3QgcGxhY2UuIEJ1dCB0aGVuIGFn YWluIHdlIHdlcmUgdG9sZCBhdCBhIHByZXZpb3VzIG1lZXRpbmcgKFF1ZWJlYz8pIHRvIGdvIHNv bHZlIHRoaXMgcHJvYmxlbS4uLg0KPg0KPj4gQm90aCB2aWV3cyBzZWVtIHRvIGFtb3VudCB0byB0 aGUgc2FtZSB0aGluZywgb25jZSBpbXBsZW1lbnRlZD8gSW4gYm90aCBjYXNlcyBpdCBnaXZlcyBh IGNhY2hlIHNvbWUgd2VsbC1kZWZpbmVkIHRpbWUgcGVyaW9kIHRvIHRyeSBhbmQgcmUtZXN0YWJs aXNoIGFuIG9ic2VydmUgcmVsYXRpb24gYmVmb3JlIHRoZSBjb250ZW50IGluIHRoZSBjYWNoZSBm aW5hbGx5ICJyZWFsbHkiIGV4cGlyZXMuDQo+Pg0KPj4gV2l0aG91dCBhIE1heC1PRkUgb3B0aW9u IG9yIHNpbWlsYXIsIGEgY2FjaGUgY2FuIHN0aWxsICBpbXBsZW1lbnQgc3VjaCBiZWhhdmlvdXIg YnV0IGhhcyB0byBlc3RpbWF0ZSB0aGUgcmlnaHQgdGltZSAod2hlbiB0byB0cnkgcmUtZXN0YWJs aXNoIGFuIG9ic2VydmUgcmVsYXRpb24pIGl0c2VsZi4gSWYgdGhpcyBpcyBjb3JyZWN0IEknbSBv ayB3aXRoIHJlbW92aW5nIHRoZSBvcHRpb24gZm9yIHRoZSB0aW1lIGJlaW5nLg0KPiBDb3JyZWN0 Lg0KPg0KPiBOb3csIENhcnN0ZW4gYnJpbmdzIHVwIGFuIGludGVyZXN0aW5nIGlkZWEgaW4gcmUt b3BlbmluZyBUaWNrZXQgIzE3NCwgdGhhdCB0aGVzZSB0aGluZ3MgY291bGQgYmUgZGVjb3VwbGVk IGZyb20gZWFjaCBvdGhlci4gTGV0J3MgZXhwbG9yZSBpZiB0aGF0IG1ha2VzIGFueSBzZW5zZS4N Cj4NCj4gWmFjaA0KPg0KPj4gcmVnYXJkcw0KPj4gRXNrbw0KPj4NCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3Jl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaYWNoIFNoZWxieQ0KPj4gU2VudDogV2Vk bmVzZGF5IDQgSmFudWFyeSAyMDEyIDEwOjQ1DQo+PiBUbzogY29yZUBpZXRmLm9yZyBXRw0KPj4g U3ViamVjdDogW2NvcmVdIE1vdmluZyBPYnNlcnZlIGZvcndhcmQNCj4+DQo+PiBJIGhhdmUgYmVl biBnb2luZyB0aHJvdWdoIHRoZSBJRVRGODIgbWludXRlcyAoaHR0cDovL3Rvb2xzLmlldGYub3Jn L3dnL2NvcmUvbWludXRlcykgYW5kIHVwZGF0aW5nIHRpY2tldHMgZXRjLiBUaGUgZGlzY3Vzc2lv biBvbiB0aGUgbmV3IE1heC1PRkUgb3B0aW9uIHRoYXQgd2FzIGFkZGVkIHRvIG9ic2VydmUtMDMg aXMgaW50ZXJlc3RpbmcgcmVhZGluZyBmb3IgdGhvc2Ugb2YgeW91IHRoYXQgd2VyZSBub3QgdGhl cmUuDQo+Pg0KPj4gVGhhdCBkaXNjdXNzaW9uIGxlZnQgbWUgZmVlbGluZyBsaWtlIHdlIHdlcmUg cHJlbWF0dXJlIGluIGFkZGluZyB0aGlzIG9wdGlvbiB0byBPYnNlcnZlLCBhcyBpdCBjbGVhcmx5 IGhhcyBub3RoaW5nIG5lYXIgV0cgY29uc2Vuc3VzLiBJIGFtIG5vdCBjb252aW5jZWQgdGhhdCB3 ZSBldmVuIG5lZWQgaXQgYXQgdGhpcyBwb2ludC4NCj4+DQo+PiBPYnNlcnZlIG90aGVyd2lzZSBp cyBpbiByZWFsbHkgZ29vZCBzaGFwZSwgYW5kIHRoZSBXRyBzZWVtZWQgdG8gdGhpbmsgaW4gVGFp cGVpIHRoYXQgaXQgd291bGQgYmUgcmVhZHkgZm9yIFdHTEMgaWYgdGhpcyBNYXgtT0ZFIHByb2Js ZW0gd291bGQgYmUgdGFrZW4gY2FyZSBvZi4NCj4+DQo+PiBNeSBwcm9wb3NhbCB3b3VsZCBiZSB0 byBkdW1wIE1heC1PRkUgaW50byBhIHNlcGFyYXRlIHBlcnNvbmFsIGRyYWZ0IGZvciBmdXR1cmUg ZGlzY3Vzc2lvbiBhbmQgd29yaywgaXQgY291bGQgYmUgc3RhbmRhcmRpemVkIGluIHRoYXQgb3Ig c29tZSBvdGhlciBmb3JtIGxhdGVyLiBUaGF0IHdvdWxkIGxlYXZlIHRoZSBPYnNlcnZlIFdHIGRv Y3VtZW50IHJlYWR5IGZvciBXR0xDLCBidXQgYWxsb3cgY29udGludWVkIHdvcmsgb24gdGhlIGlk ZWEuDQo+Pg0KPj4gV2hhdCBkbyBvdGhlcnMgdGhpbms/DQo+Pg0KPj4gWmFjaA0KPj4NCj4+IC0t DQo+PiBaYWNoIFNoZWxieSwgQ2hpZWYgTmVyZCwgU2Vuc2lub2RlIEx0ZC4NCj4+IGh0dHA6Ly93 d3cuc2Vuc2lub2RlLmNvbQ0KPj4gaHR0cDovL3phY2hzaGVsYnkub3JnICAtIE15IGJsb2cgIk9u IHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MiDQo+PiBodHRwOi8vNmxvd3Bhbi5uZXQgLSBNeSBib29r ICI2TG9XUEFOOiBUaGUgV2lyZWxlc3MgRW1iZWRkZWQgSW50ZXJuZXQiDQo+PiBNb2JpbGU6ICsz NTggNDAgNzc5NjI5Nw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBjb3JlIG1haWxpbmcgbGlzdA0KPj4gY29yZUBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVk IHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9y IHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2Vt aW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQg ZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KPj4NCg0KDQotLQ0K U2FsdmF0b3JlIExvcmV0bw0Kd3d3LnNsb3JldG8uY29tDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl From cabo@tzi.org Mon Jan 16 04:33:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13F21F8574 for ; Mon, 16 Jan 2012 04:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.653 X-Spam-Level: X-Spam-Status: No, score=-104.653 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKs4zV0NDNVi for ; Mon, 16 Jan 2012 04:33:55 -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 455AF21F8570 for ; Mon, 16 Jan 2012 04:33: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 q0GCXict024069; Mon, 16 Jan 2012 13:33:44 +0100 (CET) Received: from [192.168.217.117] (p5B3E6537.dip.t-dialin.net [91.62.101.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 598F6EFF; Mon, 16 Jan 2012 13:33:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <4F140ABB.9030002@ericsson.com> Date: Mon, 16 Jan 2012 13:33:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <031DD135F9160444ABBE3B0C36CED6180485D8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <2CB90C67-17DC-4A50-AA22-A1CDD0A4FBB5@sensinode.com> <4F13E3A5.3040704@ericsson.com> <5BD81D4B-2731-499B-9C50-BD3834BE5AD6@tzi.org> <4F140ABB.9030002@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org" Subject: Re: [core] Moving Observe forward 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, 16 Jan 2012 12:33:56 -0000 On Jan 16, 2012, at 12:32, Salvatore Loreto wrote: > Hi Carsten, >=20 > yes I see the differences, > but your proposal still implies some extra effort on the server > even if minor that the one required when we had "Lifetime" option. Exactly -- announcing a value for this option is a promise by there = server to go an extra mile. > However I don't get the need for an explicit signal. >=20 > If I am and Observer and I receive back from the server an update with = a Max-Age > I assume that the server has set the Max-Age to that value, not = randomly, but because it knows (based on some internal statistics) > that after that that resource value will be different or because it = want to force me to check with it anyway; > so in the case I, as observer, don't receive anything I can resonable = assume that I am not subscribe any more to the Server > or something bad has happened to the server. This is one of those "If all you have is a hammer, everything looks like = a nail" situations. Max-Age tells a client how long the value is valid (and how long a proxy = can relay it, with a counted down max-age). Now, say, we are in an observation relationship. If no new value comes in at the end of max-age, there may be five = reasons: 1) the server is no longer operating 2) the server has rebooted and lost the state 3) the server has been trying to reach the client and is still = unsuccessful, as the network is down 4) the server tried to reach the client for a while and has given up 5) the value has not changed. We can do very little about 1 (if the server no longer is there, the = resource no longer is there, so this is unrepairable). (It would still = be nice to have a way to control the time needed for reaching this = diagnosis.) 1 is very hard to distinguish from 3. So let's treat 3 like 1 for the = moment. 2 and 4 are the cases that can be repaired by re-establishing the = observation relationship. 5 is an important optimization. Without any of this, the server must = send a new value when max-age runs out. This would be fine in a pull = model, but in a push model we can do better: If the observation = relationship still exists, the client can continue to use the old value, = because it would have received a new one if it indeed had changed. If we want to pursue the efficiencies of 5, we need to tell the client = how long it can defer action for 2/4. For this, it needs to know how impatient the server is going to be. For = a server that puts observation relationships in stable storage and never = gives up, 2 actually cannot happen (but a server might still go into = extended exponential back off for extended lengths of 4). So, for a server, the new proposed hold-off value means "after max-age = runs out, I promise not to give up on you for at least this duration". = The client can postpone observation relationship recovery to after that = value, because any gap is a relatively reliable indication of 1, 3 = (unrepairable), or 5 (no change). Avoiding 4 is exactly what hold-off = is about (Ticket 174 is about "Robust observation relationships"). 2 is = a place where we can maybe fudge a bit: A server should not give a = hold-off if it plans to reboot and forget everything frequently; if that = is infrequent (as in "battery change every 3 years"), it might benefit = from a bit of a hold-off=85 (I'm not sure how to solve this better and = still be conservative with packets.) The remaining issue is, if the client is an intermediary, what does it = tell *its* clients. If the intermediary has an observation relationship = with its client, it can provide an appropriate (independent) value for = hold-off -- there is no need for its client to become active for = observation relationship recovery just because the origin server has a = hiccup. If the ultimate client is just sending GET requests without = Observe, things become a bit more thorny. There is no business for = hold-off here. So this is where your fudge factors ("statistical = calculations") might come in again. Setting max-age to the remaining = hold-off obviously is wrong, as a new notification can come into the = intermediary every moment. Setting it to a very small value leads to a = lot of polling. So this may be the place of educated guessing. Let's go through the two examples from Taipei: 1) The ECB currency exchange reference rate. This is published by the = origin server every work day at 14:15 and carries a max-age of 86400 (or = a multiple of that to cope with non-trading days). This is a big = server, so it might well have some patience, but on the other hand wants = to get rid of dead clients relatively quickly. If the server manages to = push out all updates within 10 seconds, it should set the hold-off to = 10+max-retransmit-delay+network-latency, so, say, 60 seconds. An = intermediary that observes the origin server but does not get an update = should not continue to send out the old reference rate to its clients as = "current" for much longer. 2) a temperature sensor. This publishes a new temperature every minute, = *if* it has changed more than a threshold from the previous value (noise = suppression). It is also not very likely that the temperature will = change dramatically, still, max-age should stay at 60 seconds, as = clients polling from an intermediary should get fresh data. Hold-Off = could be something like 10 minutes, which would require the temp sensor = to send a value every ~ ten minutes as a keepalive even if the = temperature is completely stable and/or cope with eager clients trying = to recover the observation relationship. Makes sense? > of course a server can send a notification that does not contain = Max-Age but that is another problem. We have set the default value for Max-Age to 60 seconds, so the server = would have to expend extra effort to set it to 0. Gr=FC=DFe, Carsten From lohse@itm.uni-luebeck.de Mon Jan 16 07:41:39 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5882D21F8613 for ; Mon, 16 Jan 2012 07:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ABegJA8qmZk for ; Mon, 16 Jan 2012 07:41:38 -0800 (PST) Received: from ip1.rz.uni-luebeck.de (ip1.rz.uni-luebeck.de [141.83.100.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE4721F8601 for ; Mon, 16 Jan 2012 07:41:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMRDFE+NU0Rk/2dsb2JhbABDrC2BC4EFgnE9FhgDAgECAVgIAQGHeJY/ny+JKwEBBQMEDQULBAIEAQUREQwBAQYBBQclAQIBAQIDAQIBAQEBAoMFKwIGAUyDHASaYoxx Received: from itm01.itm.uni-luebeck.de ([141.83.68.100]) by ip1.rz.uni-luebeck.de with ESMTP; 16 Jan 2012 16:41:35 +0100 Received: from [141.83.171.89] (unknown [141.83.171.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by itm01.itm.uni-luebeck.de (Postfix) with ESMTPSA id E6B0E83F8E1 for ; Mon, 16 Jan 2012 16:41:34 +0100 (CET) Message-ID: <4F144529.9040200@itm.uni-luebeck.de> Date: Mon, 16 Jan 2012 16:41:29 +0100 From: Stephan Lohse User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [core] Variable length uints in CoAP 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, 16 Jan 2012 15:43:40 -0000 Hi, this might seem like a stupid question, but CoAP defines options that are of uint type and can be between 0 and 4 byte long (currently that affects Max-Age only). Does that mean, that an "odd" number of bytes, like 3 for example, is something I have to care about, or do I have to consider only option lengths that are powers of 2? The reason I'm asking is that I work with a cross plattform framework, where endianness is a concern. Regards, - Stephan Lohse From cabo@tzi.org Mon Jan 16 08:44:41 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88DD21F8690 for ; Mon, 16 Jan 2012 08:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.38 X-Spam-Level: X-Spam-Status: No, score=-105.38 tagged_above=-999 required=5 tests=[AWL=0.869, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P259UzWbyX29 for ; Mon, 16 Jan 2012 08:44: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 EE8B621F868C for ; Mon, 16 Jan 2012 08:44: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 q0GGiXgQ029803; Mon, 16 Jan 2012 17:44:33 +0100 (CET) Received: from [192.168.217.117] (p5B3E6537.dip.t-dialin.net [91.62.101.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DDCE612C; Mon, 16 Jan 2012 17:44:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F144529.9040200@itm.uni-luebeck.de> Date: Mon, 16 Jan 2012 17:44:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3BDDA833-D1E8-4BE2-9C60-14F58C380AFC@tzi.org> References: <4F144529.9040200@itm.uni-luebeck.de> To: Stephan Lohse X-Mailer: Apple Mail (2.1251.1) Cc: core@ietf.org Subject: Re: [core] Variable length uints in CoAP 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, 16 Jan 2012 16:44:41 -0000 > Does that mean, that an "odd" number of bytes, like 3 for example, is > something I have to care about, or do I have to consider only option > lengths that are powers of 2? Yes, uints can be any number of bytes (as limited by the specification = of the option), see core-coap appendix A. > The reason I'm asking is that I work with a cross plattform framework, > where endianness is a concern. Endianness never is a concern here -- everything is in network byte = order (see core-coap appendix A). Can you elaborate? As a side observation, I'm personally not very happy with the variable = length uints we have, but they seem to be an appropriate compromise = between doing this right and staying with the familiar. See the PS for = how to do this right, which I'm not proposing (not even in coap-misc = :-). Gr=FC=DFe, Carsten PS.: With our variable length uints, there are multiple representations = for every number, which runs against the principle of minimizing = unnecessary choice and interop complexity, and also wastes bytes. We = could solve the first, but not the second, by outlawing leading zeroes, = but then we have to cope with error cases caused by illegal values, = another encoding no-no. A correct and exceedingly simple way to solve = both would be to have each byte in the base-256 place-value system stand = for a number between 1 and 256 instead of 0 to 255; 0 would always be = encoded in zero bytes; 1 to 256 would be one byte, 257 (0x101) to 65792 = (0x10100) would be two bytes, 65793 (0x10101) to 16843008 (0x1010100) = would be three bytes, etc. But that would be a completely new thought = for most implementers (who rarely think about number representation), so = I never went ahead and actually proposed this. 0 -> 0x'' -> 0 1 -> 0x'00' -> 1 2 -> 0x'01' -> 2 3 -> 0x'02' -> 3 255 -> 0x'fe' -> 255 256 -> 0x'ff' -> 256 257 -> 0x'0000' -> 257 258 -> 0x'0001' -> 258 65534 -> 0x'fefd' -> 65534 65535 -> 0x'fefe' -> 65535 65536 -> 0x'feff' -> 65536 65792 -> 0x'ffff' -> 65792 65793 -> 0x'000000' -> 65793 65794 -> 0x'000001' -> 65794 From Bert.Greevenbosch@huawei.com Mon Jan 16 21:33:59 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F99921F8532 for ; Mon, 16 Jan 2012 21:33:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkg45589TfQy for ; Mon, 16 Jan 2012 21:33:58 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDF221F858E for ; Mon, 16 Jan 2012 21:33:58 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXX008KKGSDS5@szxga03-in.huawei.com> for core@ietf.org; Tue, 17 Jan 2012 13:33:49 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXX00D67GS0I5@szxga03-in.huawei.com> for core@ietf.org; Tue, 17 Jan 2012 13:33:49 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGI96479; Tue, 17 Jan 2012 13:33:48 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Jan 2012 13:33:40 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.186]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 17 Jan 2012 13:33:41 +0800 Date: Tue, 17 Jan 2012 05:33:40 +0000 From: Bert Greevenbosch In-reply-to: <937BAA79-93AE-4C3B-B547-54127B1F1351@tzi.org> X-Originating-IP: [10.70.109.135] To: Carsten Bormann Message-id: <46A1DF3F04371240B504290A071B4DB62323EAE4@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-GB, zh-CN, en-US Thread-topic: [core] Block GETs beyond resource size Thread-index: AczRnLXaaZMvoXioQwySY9Pyy0KS0f//wpsA//sltYA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <46A1DF3F04371240B504290A071B4DB62321FB85@szxeml509-mbx.china.huawei.com> <937BAA79-93AE-4C3B-B547-54127B1F1351@tzi.org> Cc: "core@ietf.org" Subject: Re: [core] Block GETs beyond resource size 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, 17 Jan 2012 05:33:59 -0000 Hi Carsten, Thank you for your response. I agree that the "UNIX solution" would be a fix to the problem too. As for when it should happen, clearly the client shouldn't send such a requ= est in the first place. It can refrain from it, when it sends the requests = sequentially, i.e. a GET request for the next block is sent only after the = GET response for the previous block was received. If the client doesn't wait for the response and sends a bunch of GETs for m= ultiple blocks shortly after each other, it becomes more complicated. If th= e "size" option is included, at least it can know the number of blocks in a= dvance, after the initial block size negotiation has taken place. If not, i= t may end up sending GETs beyond the last block. With PUT, the server can detect PUTs of blocks beyond the end of the file b= y inspecting the "more" flag of the previous blocks, inspecting the "size" = option, or by secondary means such as inspecting the payload format. In the= se cases, indeed it can return an error code, but it should really not happ= en, as the sending client knows the resource size. Could you explain why th= e 4.08 "Request Entity Incomplete" error code is appropriate for this case? Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 13 January 2012 15:01 To: Bert Greevenbosch Cc: core@ietf.org Subject: Re: [core] Block GETs beyond resource size Bert, good point. On Jan 13, 2012, at 03:40, Bert Greevenbosch wrote: > It seems obvious that the server should send an error code. One other way to handle this would be to respond with a 2.05 with an empty = payload and M=3D0. In UNIX, this is what you get when you seek behind the EOF and try to read. Clearly, when you GET exactly at the end (e.g., have 1024 bytes of payload = and do a GET with Block2/2/0/512), you get back a zero-length payload, so t= here already need to be code paths handling these. I really don't have a strong feeling whether this "seeking/reading beyond t= he end" needs another error code or is "normal" as it would be in UNIX. When can this happen? If clients follow the sequential protocol, this can = only happen when the size of the resource has changed. This should lead to= a new ETag, so the client knows it cannot use the current assembly, so it = will have to restart from 0. The only adverse effect of an empty 2.05 coul= d be that a not so bright client might allocate a new buffer to the size of= the current seek position (as it meaningfully would do if it did get data)= . If you "don't do that"T, there is no problem. Once we have a Size option, sending this back in conjunction with an empty = 2.05 might a nice way to respond to a Block2 seek beyond the end. With Block1 (and PUT), seeking beyond the end might be an immediate 4.08 er= ror for an atomic server, or it might also simply be executed (with UNIX' h= ole-filling semantics) by a stateless server, so I think we are covered the= re. Interesting discussion! Gr=FC=DFe, Carsten From stpeter@stpeter.im Tue Jan 17 09:25:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A57A11E8072 for ; Tue, 17 Jan 2012 09:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLYKJvLtkQbH for ; Tue, 17 Jan 2012 09:25:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 747D95E8001 for ; Tue, 17 Jan 2012 09:25:20 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3AD2A40058 for ; Tue, 17 Jan 2012 10:34:40 -0700 (MST) Message-ID: <4F15AF04.1010002@stpeter.im> Date: Tue, 17 Jan 2012 10:25:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: core WG X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [core] preparing for Paris 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, 17 Jan 2012 17:25:21 -0000 Just a friendly reminder that WG sessions for IETF 83 need to be scheduled less than 2 weeks from now: http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 Peter -- Peter Saint-Andre http://stpeter.im/ From alper.yegin@yegin.org Wed Jan 18 09:27:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E8121F8634 for ; Wed, 18 Jan 2012 09:27: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzWM6WHoEyuJ for ; Wed, 18 Jan 2012 09:27:30 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 251B821F8617 for ; Wed, 18 Jan 2012 09:27:23 -0800 (PST) Received: from [217.167.117.10] ([217.167.117.10]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MOwCV-1RhGhC0WAh-0067Pi; Wed, 18 Jan 2012 12:27:22 -0500 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2012 19:27:18 +0200 Message-Id: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> To: core WG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Provags-ID: V02:K0:+hR+Tcv3PMFfmtN0O4ClIVhICxPWsIH49YfYFep8lpU dhKFW/fMFi61/SsZnFce0lfugoLZOOAKQbcnKsReb4+/uCYMCU kQjoMnQxRrqRnRLGSyh00P9SsPy1d41rmar2mh4Iiigm8DtpQw 0NOKy7+A7NGhNVweek7892Gd38FEfztHc2Fsx5X3x0yJM5f81m Ykn7nMztfMwLcGEUFy1qUzTInoL+8pMUV/Sopj7OhNBUiC/4T9 FmKIli+7it2AEO42FOkk4iBXjfxFBGsQJI1LCDUZA/RgEDCGiV UNPORvw0HWJSQeClRue5aj/BdEMdgu+84mfh2YI9KEP3EZXKj0 oGxqI53Rg2MBa3cPRrhgYo3gNiPPTJB7xc2RaYQ+xbCJqxJSng GJK0bnDJS7CTA== Subject: [core] Vendor-specific 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, 18 Jan 2012 17:27:30 -0000 Hello, Is there a specific reason why vendor-specific options are not supported = by CoAP? Shall that be added? Alper From likepeng@huawei.com Wed Jan 18 16:26:00 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2AB11E80D9 for ; Wed, 18 Jan 2012 16:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vlPp8J5Hu2r for ; Wed, 18 Jan 2012 16:26:00 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 42EE111E80D7 for ; Wed, 18 Jan 2012 16:26:00 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY00069SRV3L4@szxga04-in.huawei.com> for core@ietf.org; Thu, 19 Jan 2012 08:25:52 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY000GTXRV3XG@szxga04-in.huawei.com> for core@ietf.org; Thu, 19 Jan 2012 08:25:51 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGM73026; Thu, 19 Jan 2012 08:25:49 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jan 2012 08:25:42 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.249]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Thu, 19 Jan 2012 08:25:39 +0800 Date: Thu, 19 Jan 2012 00:25:38 +0000 From: Likepeng In-reply-to: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> X-Originating-IP: [10.70.109.53] To: Alper Yegin , core WG Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2017DFA4D@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] Vendor-specific options Thread-index: AQHM1gaL6a5i5TyT0U+rJucto+Ts+ZYS08NA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> Subject: Re: [core] Vendor-specific 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, 19 Jan 2012 00:26:00 -0000 SGksDQoNCj4gSXMgdGhlcmUgYSBzcGVjaWZpYyByZWFzb24gd2h5IHZlbmRvci1zcGVjaWZpYyBv cHRpb25zIGFyZSBub3Qgc3VwcG9ydGVkIGJ5IENvQVA/DQoNClZlbmRvcnMgY2FuIGNob29zZSBh bnkgdW51c2VkIG51bWJlcnMgZm9yIHZlbmRvci1zcGVjaWZpYyBvcHRpb25zLiBJIGNhbiBzYXks IGl0IGlzIGFscmVhZHkgc3VwcG9ydGVkLiANCg0KPiBTaGFsbCB0aGF0IGJlIGFkZGVkPw0KDQpE byB5b3UgbWVhbiwgc3RhbmRhcmRpemUgYSBzcGVjaWZpYyBudW1iZXIgZm9yIHRoaXMgcHVycG9z ZT8gSSBkb26hr3Qgc2VlIHRoZSBuZWVkLg0KDQpUaGFua3MsDQpLaW5kIFJlZ2FyZHMNCktlcGVu Zw0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBBbHBlciBZZWdpbg0Kt6LLzcqxvOQ6IDIw MTLE6jHUwjE5yNUgMToyNw0KytW8/sjLOiBjb3JlIFdHDQrW98ziOiBbY29yZV0gVmVuZG9yLXNw ZWNpZmljIG9wdGlvbnMNCg0KSGVsbG8sDQoNCklzIHRoZXJlIGEgc3BlY2lmaWMgcmVhc29uIHdo eSB2ZW5kb3Itc3BlY2lmaWMgb3B0aW9ucyBhcmUgbm90IHN1cHBvcnRlZCBieSBDb0FQPw0KU2hh bGwgdGhhdCBiZSBhZGRlZD8NCg0KQWxwZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From tianlinyi@huawei.com Wed Jan 18 21:54:16 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C874B21F8603 for ; Wed, 18 Jan 2012 21:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9qkk+yfycFA for ; Wed, 18 Jan 2012 21:54:15 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9451321F85AD for ; Wed, 18 Jan 2012 21:54:15 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY1004C1729KX@szxga04-in.huawei.com> for core@ietf.org; Thu, 19 Jan 2012 13:54:09 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY1003QU729Q4@szxga04-in.huawei.com> for core@ietf.org; Thu, 19 Jan 2012 13:54:09 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGK63597; Thu, 19 Jan 2012 13:54:09 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jan 2012 13:53:58 +0800 Received: from SZXEML513-MBS.china.huawei.com ([169.254.6.148]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 19 Jan 2012 13:53:50 +0800 Date: Thu, 19 Jan 2012 05:53:49 +0000 From: TianLinyi In-reply-to: <34966E97BE8AD64EAE9D3D6E4DEE36F2017DFA4D@szxeml525-mbs.china.huawei.com> X-Originating-IP: [10.70.109.82] To: Likepeng , Alper Yegin , core WG Message-id: <3615F3CCD55F054395A882F51C6E5FDA182431B7@szxeml513-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] Vendor-specific options Thread-index: AQHM1gaKGb+ebHmKeEWELKxIIY9l7pYST5IAgADhnSA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <34966E97BE8AD64EAE9D3D6E4DEE36F2017DFA4D@szxeml525-mbs.china.huawei.com> Subject: Re: [core] Vendor-specific 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, 19 Jan 2012 05:54:16 -0000 SGksIEFscGVyDQoNCkRvIHlvdSBtZWFuIHJlc2VydmUgYSByYW5nZSBvZiBvcHRpb24gbnVtYmVy cyBmb3IgdmVuZG9yIHNwZWNpZmljIGV4dGVuc2lvbnM/DQoNCkNoZWVycywNCkxpbnlpDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaWtlcGVuZw0KU2VudDog VGh1cnNkYXksIEphbnVhcnkgMTksIDIwMTIgODoyNiBBTQ0KVG86IEFscGVyIFllZ2luOyBjb3Jl IFdHDQpTdWJqZWN0OiBSZTogW2NvcmVdIFZlbmRvci1zcGVjaWZpYyBvcHRpb25zDQoNCkhpLA0K DQo+IElzIHRoZXJlIGEgc3BlY2lmaWMgcmVhc29uIHdoeSB2ZW5kb3Itc3BlY2lmaWMgb3B0aW9u cyBhcmUgbm90IHN1cHBvcnRlZCBieSBDb0FQPw0KDQpWZW5kb3JzIGNhbiBjaG9vc2UgYW55IHVu dXNlZCBudW1iZXJzIGZvciB2ZW5kb3Itc3BlY2lmaWMgb3B0aW9ucy4gSSBjYW4gc2F5LCBpdCBp cyBhbHJlYWR5IHN1cHBvcnRlZC4gDQoNCj4gU2hhbGwgdGhhdCBiZSBhZGRlZD8NCg0KRG8geW91 IG1lYW4sIHN0YW5kYXJkaXplIGEgc3BlY2lmaWMgbnVtYmVyIGZvciB0aGlzIHB1cnBvc2U/IEkg ZG9uoa90IHNlZSB0aGUgbmVlZC4NCg0KVGhhbmtzLA0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCi0t LS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpj b3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQWxwZXIgWWVnaW4NCreiy83KsbzkOiAyMDEyxOox 1MIxOcjVIDE6MjcNCsrVvP7IyzogY29yZSBXRw0K1vfM4jogW2NvcmVdIFZlbmRvci1zcGVjaWZp YyBvcHRpb25zDQoNCkhlbGxvLA0KDQpJcyB0aGVyZSBhIHNwZWNpZmljIHJlYXNvbiB3aHkgdmVu ZG9yLXNwZWNpZmljIG9wdGlvbnMgYXJlIG5vdCBzdXBwb3J0ZWQgYnkgQ29BUD8NClNoYWxsIHRo YXQgYmUgYWRkZWQ/DQoNCkFscGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From cabo@tzi.org Wed Jan 18 22:43:09 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7D21F85B4 for ; Wed, 18 Jan 2012 22:43: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZu2qPLnBpAy for ; Wed, 18 Jan 2012 22:43: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 8B7C421F859B for ; Wed, 18 Jan 2012 22:43: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 q0J6h0f4010356; Thu, 19 Jan 2012 07:43:00 +0100 (CET) Received: from [192.168.217.112] (p5489B242.dip.t-dialin.net [84.137.178.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B76DCDFB; Thu, 19 Jan 2012 07:42:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> Date: Thu, 19 Jan 2012 07:43:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1251.1) Cc: core WG Subject: Re: [core] Vendor-specific 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, 19 Jan 2012 06:43:09 -0000 On Jan 18, 2012, at 18:27, Alper Yegin wrote: > Is there a specific reason why vendor-specific options are not = supported by CoAP? I have proposed one way to do them in coap-misc, section 4. If the WG believes that this is a necessary mechanism (and that the = specific way I have proposed to do it is the right way), we should move = it over to core-coap. Gr=FC=DFe, Carsten From alper.yegin@yegin.org Thu Jan 19 02:52:04 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3E921F85C2 for ; Thu, 19 Jan 2012 02:52:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJD5n+2804pt for ; Thu, 19 Jan 2012 02:52:04 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 178BA21F84B8 for ; Thu, 19 Jan 2012 02:52:04 -0800 (PST) Received: from [10.10.12.1] (cu1119.etsipublic.org [217.167.116.25]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MfnvY-1Rzq5Z0xpE-00NE7q; Thu, 19 Jan 2012 05:46:33 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: Date: Thu, 19 Jan 2012 12:46:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1251.1) X-Provags-ID: V02:K0:6bzxgSYNU9v/a9MRSZgDWvivvTKT+4zEt0F0w5NGsnB KPVAdrMQvMNewMcHFXdJsWg4d0yPBYSoloK3p0uHBAgEIg2R4a C6R44m62ehHBWZspoBE4cKyXBdKNMFzgiMWKhkeitRfXYIK6eC VQXIyZhLGFUBHlAOab/2r7pjk0GdocIYLyJvUF8f8zJ97Bx/sr WaxxPTfAFCU6k6hrhAsJ1KlbJV7uGXMGEy1hceDDa6kjNSmncY sQuIg/5soNBKvn8H/9dW1xOq30JPUFUkVf5rI1s/NcL2zuQQa4 nz93cve3IwhkeyHyDbBV6EDxr8bMWZfyesS9UxPaOfBzy800Zb GrkQLJtK2FSO72v+bEzSyTepJlTT3OMklkOOWoz7V Cc: core WG Subject: Re: [core] Vendor-specific 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, 19 Jan 2012 10:52:04 -0000 On Jan 19, 2012, at 8:43 AM, Carsten Bormann wrote: > On Jan 18, 2012, at 18:27, Alper Yegin wrote: >=20 >> Is there a specific reason why vendor-specific options are not = supported by CoAP? >=20 > I have proposed one way to do them in coap-misc, section 4. > If the WG believes that this is a necessary mechanism (and that the = specific way I have proposed to do it is the right way), we should move = it over to core-coap. I think this makes sense. Let's call it vendor-specific option, not = user-defined option though. Alper From cabo@tzi.org Thu Jan 19 03:29:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3321F85B4 for ; Thu, 19 Jan 2012 03:29:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ3DJ-X1izyo for ; Thu, 19 Jan 2012 03:29: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 F378E21F85AE for ; Thu, 19 Jan 2012 03:29:12 -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 q0JBT52c024146; Thu, 19 Jan 2012 12:29:06 +0100 (CET) Received: from [192.168.217.117] (p5489B242.dip.t-dialin.net [84.137.178.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E88D01A; Thu, 19 Jan 2012 12:29:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Thu, 19 Jan 2012 12:29:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1251.1) Cc: core WG Subject: Re: [core] Vendor-specific 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, 19 Jan 2012 11:29:18 -0000 On Jan 19, 2012, at 11:46, Alper Yegin wrote: > Let's call it vendor-specific option, not user-defined option though. (Option names are a bike shed color decision, so I'm sorry for = responding to this, but: You don't have to sell anything to define such an option :-) But given all the "vendoring" that is going on, I don't have a strong = opinion.) .oOo. Now back to the question: > I think this makes sense. Are there other people who want to do something in this space? .oOo. Let me quickly explain why I think the obvious approaches don't work: 1) Just squatting on option numbers. This creates a lot of problems in other protocols. Products that use squatted-on option numbers get deployed and make the = number unavailable for any further use (even if the product then fades = out). Squatting is somewhat more acceptable for text-named options (lower = probability of collision), but works very badly for a small number = space. Even more so as there are "good" and "worse" numbers (amount of fence = posting required): the small numbers will be quickly squatted away for = vendor vanity options, and we get to assign 93 for the next = standards-based option. There is a reason why coap-core defines the option number space as: The IANA policy for future additions to this registry is "IETF Review" as described in [RFC5226]. 2) Defining a small "experimental" range. This essentially means all the squatting is focused on a small range. This works so badly in practice that tcpm has a draft trying to define a = way to survive their current setup. draft-touch-tcpm-experimental-options-00.txt TCP options and CoAP options pose related requirements, but are not the = same. I think Joe and I developed our proposals in parallel, from the same = kind of thinking. Joe is prepared to spend 32 bits for option identification, I'm *trying* = to be a bit more frugal, but that works only very well for vendors (here = they are again) that have been in play for long enough to have a 14-bit = or smaller enterprise ID. (16384 is "California State Polytechnic University, Pomona"=85) Creating a new registry for CoAP option vendor-IDs would be possible, = but I'm not convinced yet we want to set this up. Among other considerations, most companies in this space already need an = enterprise number, so it is much more stealthy to use this instead of = applying for a number out of a focused registry... Gr=FC=DFe, Carsten From cabo@tzi.org Thu Jan 19 06:36:08 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E858C21F8624; Thu, 19 Jan 2012 06:36:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIcfjaT3WZD3; Thu, 19 Jan 2012 06:36: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 C698221F861F; Thu, 19 Jan 2012 06:36:07 -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 q0JEZvR8020602; Thu, 19 Jan 2012 15:35:57 +0100 (CET) Received: from [192.168.217.117] (p5489B242.dip.t-dialin.net [84.137.178.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1DFA1161; Thu, 19 Jan 2012 15:35:57 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Carsten Bormann Date: Thu, 19 Jan 2012 15:35:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <666B33A3-CD9C-47C9-8DB5-25A3234572A0@tzi.org> References: <9E2944CA-16CF-4985-9DA6-B7A1A03EFF10@gmx.net> To: 6lowpan <6lowpan@ietf.org>, core WG , lwip@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: [core] Fwd: Smart Object Security Workshop Announcement 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, 19 Jan 2012 14:36:09 -0000 This workshop should be of interest to the whole constrained = node/network cluster of working groups*) If you plan to come to Paris, plan to go to: -- Fri 2012-03-23: Smart Object Security Workshop -- Sat/Sun -24/-25: ETSI CoRE plugtest -- Mon-Fri -26..-30: IETF83 If you don't have an implementation with you, you get a nice free = weekend in Paris :-) Please see below for the link to the announcement. Gr=FC=DFe, Carsten *) If you wonder why ROLL is not in the To:-list: The ROLL mailing list = already got it's own copy due to an attentive AD in the right time zone = :-) Begin forwarded message: > From: Hannes Tschofenig > Subject: Smart Object Security Workshop Announcement > Date: January 19, 2012 11:21:57 +0100 > To: IETF-Discussion list >=20 > Hi all, >=20 > we would like to make you aware of a workshop on Smart Object Security = on the 23rd March 2012 in Paris (attached to the IETF meeting). >=20 > We are seeking input from participants to share their thoughts about = the ability to utilize existing and widely deployed security mechanisms = for smart objects. >=20 > In particular, we are interested to hear about: > =95 What techniques for issuing credentials have been deployed? > =95 What extensions are useful to make existing security = protocols more suitable for smart objects? > =95 What type of credentials are frequently used? > =95 What experience has been gained when implementing and = deploying application layer, transport layer, network layer, and link = layer security mechanisms (or a mixture of all of them)? > =95 How can =93clever=94 implementations make security protocols = a better fit for constrained devices? > =95 Are there lessons we can learn from existing deployments? >=20 > More workshop details can be found on the webpage of our host: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ >=20 > If you plan to participate at the workshop please drop us a message = (with a short description of what you are planning to contribute) and we = can give you an early notice regarding your participation.=20 >=20 > Greetings > The Workshop Organizers >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From kerlyn2001@gmail.com Thu Jan 19 07:14:15 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390D321F85DA for ; Thu, 19 Jan 2012 07:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOUPu2ku9ehs for ; Thu, 19 Jan 2012 07:14:14 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5B9B21F85C9 for ; Thu, 19 Jan 2012 07:14:06 -0800 (PST) Received: by lagj5 with SMTP id j5so10928lag.31 for ; Thu, 19 Jan 2012 07:14:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=hONcQhAVJvPopBwZiOJ4hcMM6HpM4QyBsJTEm1fQCG8=; b=ZjG7Db+NDjT7q87UcM5kbjqYwVcJgcMIw8JtEHMEFY5pDDcvyQDwfOCuFgADFZkfby F1p7ar322Zu5+MiWxtAbZU8wmBBsraUa8MuLhsiLgydMIXAnKEQZilrcayRW9YjBm7q5 TbkwXhZ7iUUTlpORKeHyyeHo29Id02cE+KTQ4= MIME-Version: 1.0 Received: by 10.152.145.101 with SMTP id st5mr5364918lab.1.1326986045695; Thu, 19 Jan 2012 07:14:05 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.8.106 with HTTP; Thu, 19 Jan 2012 07:14:05 -0800 (PST) In-Reply-To: <4F03B818.6000100@gmail.com> References: <4F03B818.6000100@gmail.com> Date: Thu, 19 Jan 2012 10:14:05 -0500 X-Google-Sender-Auth: MzriUltkDrFmuSZM4Sr1X30oGVU Message-ID: From: Kerry Lynn To: core Content-Type: multipart/alternative; boundary=e89a8f234399e0283104b6e3037e Subject: [core] Fwd: Reviews requested: draft-carpenter-6man-uri-zoneid-00.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: Thu, 19 Jan 2012 15:14:15 -0000 --e89a8f234399e0283104b6e3037e Content-Type: text/plain; charset=ISO-8859-1 Greetings, I am cross-posting this request from Brian Carpenter as it seems to have particular relevance to the Application area and constrained environments. The referenced draft adds zone identifiers to the URI syntax, making it "legal" for browsers to accept link-local URIs. If you have an opinion on Brian's questions, please respond to him directly. Regards, -K- ---------- Forwarded message ---------- From: Brian E Carpenter Date: Tue, Jan 3, 2012 at 9:23 PM Subject: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt To: 6man Representing IPv6 Zone Identifiers in Uniform Resource Identifiers We'd like feedback on this. In particular, which of the two options proposed do people prefer? OPTION 1: The existing syntax of IPv6address is extended by adding a specific option for the case of link-local addresses. OPTION 2: The existing syntax of IPv6address is retained, and a zone identifier may be added optionally to any literal address. This allows flexibility for unknown future uses. - Brian & Bob -------- Original Message -------- Subject: I-D Action: draft-carpenter-6man-uri-zoneid-00.txt Date: Tue, 06 Dec 2011 17:27:00 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-carpenter-6man-uri-zoneid-00.txt Pages : 6 Date : 2011-12-06 This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-6man-uri-zoneid-00.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --e89a8f234399e0283104b6e3037e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

I am cross-posting this request from Brian Ca= rpenter as it seems to have
particular relevance to the Applicati= on area and constrained environments.
The referenced draft adds z= one identifiers to the URI syntax, making it
"legal"=A0for browsers to accept link-local URIs.
=
If you have an opinion on Brian's questions, please resp= ond to him directly.

Regards, -K-


---------- Forwarded message ----------
F= rom: Brian E Carpenter = <brian.e.carpenter@gmail.= com>
Date: Tue, Jan 3, 2012 at 9:23 PM
Subject: Reviews requested: draft-carp= enter-6man-uri-zoneid-00.txt
To: 6man <ipv6@ietf.org>


Representing IPv6 Zone Identifiers in U= niform Resource Identifiers

We'd like feedback on this. In particular, which of the two options
proposed do people prefer?

=A0 OPTION 1:

=A0 The existing syntax of IPv6address is extended by adding a specific =A0 option for the case of link-local addresses.

=A0 OPTION 2:

=A0 The existing syntax of IPv6address is retained, and a zone identifier<= br> =A0 may be added optionally to any literal address. =A0This allows
=A0 flexibility for unknown future uses.

=A0- Brian & Bob

-------- Original Message --------
Subject: I-D Action: draft-carpenter-6man-uri-zoneid-00.txt
Date: Tue, 06 Dec 2011 17:27:00 -0800
From: internet-drafts@ietf.org<= /a>
Reply-To: internet-drafts@ietf.= org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Representing IPv6 Zone Identifi= ers in Uniform Resource Identifiers
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Carpenter
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Robert M. Hinden
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-carpenter-6man-uri-zoneid-0= 0.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 6
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-12-06

=A0 This document describes how the Zone Identifier of an IPv6 scoped
=A0 address can be represented in a Uniform Resource Identifier that
=A0 includes a literal IPv6 address. =A0It updates RFC 3986 and RFC 4007.<= br>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-car= penter-6man-uri-zoneid-00.txt


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--e89a8f234399e0283104b6e3037e-- From tianlinyi@huawei.com Thu Jan 19 08:10:52 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461EA21F8675 for ; Thu, 19 Jan 2012 08:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.413 X-Spam-Level: X-Spam-Status: No, score=-4.413 tagged_above=-999 required=5 tests=[AWL=2.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgbc8XMW7Vu9 for ; Thu, 19 Jan 2012 08:10:51 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 89BB421F868A for ; Thu, 19 Jan 2012 08:10:51 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY100IGIZLS2A@szxga05-in.huawei.com> for core@ietf.org; Fri, 20 Jan 2012 00:10:40 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY100CBKZLSZ8@szxga05-in.huawei.com> for core@ietf.org; Fri, 20 Jan 2012 00:10:40 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGL07997; Fri, 20 Jan 2012 00:10:40 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jan 2012 00:10:32 +0800 Received: from SZXEML513-MBS.china.huawei.com ([169.254.6.148]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 20 Jan 2012 00:10:29 +0800 Date: Thu, 19 Jan 2012 16:10:28 +0000 From: TianLinyi In-reply-to: <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> X-Originating-IP: [172.24.1.45] To: Carsten Bormann , Alper Yegin Message-id: <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [core] Vendor-specific options Thread-index: AQHM1gaKGb+ebHmKeEWELKxIIY9l7pYSuQIAgABEAQCAAAvsAIAAzwVJ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> Cc: core WG Subject: Re: [core] Vendor-specific 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, 19 Jan 2012 16:10:52 -0000 >Are there other people who want to do something in this space?=0A= =0A= Not very much. They can do it in CoAP payload anyway. The vendor option c= an't convey enough info and may also be complex.=0A= =0A= =0A= > Creating a new registry for CoAP option vendor-IDs would be possible, but= I'm not convinced yet we want to set this up.=0A= > Among other considerations, most companies in this space already need an = enterprise number, so it is much more stealthy to use this instead of apply= ing for a number out of a focused registry...=0A= This would cause too much effort for not very important thing. (again it ca= n be done in CoAP payload)=0A= =0A= Gr=FC=DFe, Carsten=0A= =0A= _______________________________________________=0A= core mailing list=0A= core@ietf.org=0A= https://www.ietf.org/mailman/listinfo/core=0A= From esko.dijk@philips.com Fri Jan 20 06:31:07 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E69721F8579 for ; Fri, 20 Jan 2012 06:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89KMEg2H5N2r for ; Fri, 20 Jan 2012 06:31:06 -0800 (PST) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 13A9A21F8576 for ; Fri, 20 Jan 2012 06:31:06 -0800 (PST) Received: from mail49-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jan 2012 14:31:02 +0000 Received: from mail49-va3 (localhost [127.0.0.1]) by mail49-va3-R.bigfish.com (Postfix) with ESMTP id EA4BB4400ED; Fri, 20 Jan 2012 14:30:54 +0000 (UTC) X-SpamScore: -57 X-BigFish: VPS-57(zz217bL15d6O9251Jc89bh936eK542M1432N98dK14ffOzz1202hzz1033IL8275dhz2dhc1bhc31hc1ah2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail49-va3 (localhost.localdomain [127.0.0.1]) by mail49-va3 (MessageSwitch) id 1327069852221544_6953; Fri, 20 Jan 2012 14:30:52 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.252]) by mail49-va3.bigfish.com (Postfix) with ESMTP id 3185940045; Fri, 20 Jan 2012 14:30:52 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jan 2012 14:30:59 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-001.MGDPHG.emi.philips.com (10.128.28.51) with Microsoft SMTP Server (TLS) id 14.1.355.3; Fri, 20 Jan 2012 14:32:05 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.28]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.01.0355.003; Fri, 20 Jan 2012 14:30:57 +0000 From: "Dijk, Esko" To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-05.txt) Thread-Index: AQHM0YROlTzEHqcNSEGN8/cEozCI+JYVTmUA Date: Fri, 20 Jan 2012 14:30:56 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618056925@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <20120112232954.15845.45058.idtracker@ietfa.amsl.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.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-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: Fri, 20 Jan 2012 14:31:07 -0000 Dear Carsten, all, I would say the readability is improved, as intended. Below some remarks on= the new text: Questions - Table 1: should a length of 0 B be possible for both options? I would ass= ume a zero-length Block1/Block2 option value is possible and then it indica= tes the default value of 0. - section 2.1 "(The block size given is irrelevant if M is unset)." Isn't a correct SZX required e.g. for a stateless server, even if M is un= set? At least all the examples set the SZX when M=3D0 the same as the previ= ous blocks in the same sequence. Minor items - section 1 "process loads the lower layers with" -> maybe "burdens" is bet= ter here; "loads" has some other technical connotations that may confuse a = reader at this point. - section 2 "limit the size datagrams" -> size of datagrams - section 2 mentions "6LoWPAN" -> informative reference needed maybe? - section 2 "still this size will be given as the block size even for the f= inal block." -> a bit unclear. Maybe "still the chosen power-of-two block s= ize will be specified in the size field of the Block option that accompanie= s the final block" is better? Best regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Friday 13 January 2012 0:44 To: core@ietf.org WG Subject: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-= block-05.txt) A day late (the old draft expired 15.5 hours ago, oops): Here is the Friday 13th edition of -block. I hope that is not too scary :-) block-05 is trying to solve the editorial problems (#169). No technical changes are intended from the July 11th version, -04. Please read this version again and indicate whether this is still near-unre= adable. The draft is now deliberately preferring redundancy over unreadable tersene= ss. This blew up the actual specification part (section 2) to 7 pages. Oh well, it is still a very simple mechanism. If we want to, we can fix the small remaining technical issues #170 and #17= 1 in the next couple of days when we have the editorial stuff behind us. Enjoy! Gr=FC=DFe, Carsten On Jan 13, 2012, at 00:29, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Constrained RESTful Environments Wo= rking Group of the IETF. > > Title : Blockwise transfers in CoAP > Author(s) : Carsten Bormann > Zach Shelby > Filename : draft-ietf-core-block-05.txt > Pages : 27 > Date : 2012-01-12 > > CoAP is a RESTful transfer protocol for constrained nodes and > networks. Basic CoAP messages work well for the small payloads we > expect from temperature sensors, light switches, and similar > building-automation devices. Occasionally, however, applications > will need to transfer larger payloads -- for instance, for firmware > updates. With HTTP, TCP does the grunt work of slicing large > payloads up into multiple packets and ensuring that they all arrive > and are handled in the right order. > > CoAP is based on datagram transports such as UDP or DTLS, which > limits the maximum size of resource representations that can be > transferred without too much fragmentation. Although UDP supports > larger payloads through IP fragmentation, it is limited to 64 KiB > and, more importantly, doesn't really work well for constrained > applications and networks. > > Instead of relying on IP fragmentation, this specification extends > basic CoAP with a pair of "Block" options, for transferring multiple > blocks of information from a resource representation in multiple > request-response pairs. In many important cases, the Block options > enable a server to be truly stateless: the server can handle each > block transfer separately, with no need for a connection setup or > other server-side memory of previous block transfers. > > In summary, the Block options provide a minimal way to transfer > larger representations in a block-wise fashion. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-core-block-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-block-05.txt > > _______________________________________________ > 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 internet-drafts@ietf.org Sat Jan 21 07:05:38 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A912021F85AE; Sat, 21 Jan 2012 07:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRZhSUFK+6El; Sat, 21 Jan 2012 07:05:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8657421F8596; Sat, 21 Jan 2012 07:05:35 -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: 3.64p1 Message-ID: <20120121150535.26280.95535.idtracker@ietfa.amsl.com> Date: Sat, 21 Jan 2012 07:05:35 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-06.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: Sat, 21 Jan 2012 15:05:38 -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 Work= ing Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-06.txt Pages : 27 Date : 2012-01-21 CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-block-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-block-06.txt From cabo@tzi.org Sat Jan 21 07:05:58 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6D321F85B6 for ; Sat, 21 Jan 2012 07:05:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDGb8C2bV4Ng for ; Sat, 21 Jan 2012 07:05:55 -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 4669521F85B7 for ; Sat, 21 Jan 2012 07:05: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 q0LF5jF6004925; Sat, 21 Jan 2012 16:05:45 +0100 (CET) Received: from [192.168.217.117] (p5489B6FB.dip.t-dialin.net [84.137.182.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4A30982E; Sat, 21 Jan 2012 16:05:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618056925@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Sat, 21 Jan 2012 16:05:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <473636A6-DE45-4CB2-9124-9A5867B7E03D@tzi.org> References: <20120112232954.15845.45058.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618056925@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org WG" Subject: Re: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-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: Sat, 21 Jan 2012 15:05:58 -0000 On Jan 20, 2012, at 15:30, Dijk, Esko wrote: > Dear Carsten, all, >=20 > I would say the readability is improved, as intended. Thanks. > - Table 1: should a length of 0 B be possible for both options? I = would assume a zero-length Block1/Block2 option value is possible and = then it indicates the default value of 0. The design of CoAP tries to follow one principle that is important for = improving interoperability and minimizing code complexity: There should be as few ways to say the same thing as possible. Adding a way to explicitly send the default value would violate this for = no apparent gain. If you want the default value, just don't send the option. > - section 2.1 "(The block size given is irrelevant if M is unset)." > Isn't a correct SZX required e.g. for a stateless server, even if M = is unset? At least all the examples set the SZX when M=3D0 the same as = the previous blocks in the same sequence. Yes, and the text actually is wrong (SZX is not irrelevant at all as it = is still used to scale the block number into a byte offset). Good you noticed this. I changed it to: SZX does not govern the payload size if M is unset. > Minor items > - section 1 "process loads the lower layers with" -> maybe "burdens" = is better here; "loads" has some other technical connotations that may = confuse a reader at this point. > - section 2 "limit the size datagrams" -> size of datagrams > - section 2 mentions "6LoWPAN" -> informative reference needed maybe? > - section 2 "still this size will be given as the block size even for = the final block." -> a bit unclear. Maybe "still the chosen power-of-two = block size will be specified in the size field of the Block option that = accompanies the final block" is better? I have submitted a -06 with these editorial changes. Thank you! Gr=FC=DFe, Carsten From peter.van.der.stok@philips.com Mon Jan 23 00:27:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA85B21F8617 for ; Mon, 23 Jan 2012 00:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIqwTkl1INAb for ; Mon, 23 Jan 2012 00:27:56 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 180FA21F8602 for ; Mon, 23 Jan 2012 00:27:54 -0800 (PST) Received: from mail107-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Jan 2012 08:27:46 +0000 Received: from mail107-ch1 (localhost [127.0.0.1]) by mail107-ch1-R.bigfish.com (Postfix) with ESMTP id B3639A02D9; Mon, 23 Jan 2012 08:27:57 +0000 (UTC) X-SpamScore: -9 X-BigFish: VPS-9(zz217bL15d6O9251Jc85fh13e6Kzz1202hzz8275bh1264f6oz2dhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-FB-SS: 13, Received: from mail107-ch1 (localhost.localdomain [127.0.0.1]) by mail107-ch1 (MessageSwitch) id 1327307277542320_20156; Mon, 23 Jan 2012 08:27:57 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail107-ch1.bigfish.com (Postfix) with ESMTP id 75CB96C0045; Mon, 23 Jan 2012 08:27:57 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jan 2012 08:27:45 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.1.355.3; Mon, 23 Jan 2012 08:27:51 +0000 Received: from 011-DB3MPN1-061.MGDPHG.emi.philips.com ([169.254.1.80]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.01.0355.003; Mon, 23 Jan 2012 08:29:02 +0000 From: "Stok, Peter van der" To: Zach Shelby Thread-Topic: I-D:core-interfaces Thread-Index: AczZqObBHyyp/pyJQjqTsJjIs1VXtQ== Date: Mon, 23 Jan 2012 08:27:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.37.10.50] Content-Type: multipart/alternative; boundary="_000_A31CB84F6F0BFC449C6807DF752A715B029AAC011DB3MPN1061MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: [core] I-D:core-interfaces 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, 23 Jan 2012 08:27:57 -0000 --_000_A31CB84F6F0BFC449C6807DF752A715B029AAC011DB3MPN1061MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zach, Your concept of sub resource is quite central . Could you define it in the terminology section 2? I looked up RFC 5988 and found the following terms o Relation Name: chapter o Description: Refers to a chapter in a collection of resources. o Reference: [W3C.REC-html401-19991224] o Relation Name: section o Description: Refers to a section in a collection of resources. o Reference: [W3C.REC-html401-19991224 o Relation Name: subsection o Description: Refers to a resource serving as a subsection in a collection of resources. o Reference: [W3C.REC-html401-19991224] o Relation Name: start o Description: Refers to the first resource in a collection of resources. o Reference: [W3C.REC-html401-19991224] Are these related to your sub resource? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus H= TC 34 (WB) 1-067 5656 AA Eindhoven The = Netherlands phone +31 40 2749657 Fax: + = 31 40 2746321 mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_A31CB84F6F0BFC449C6807DF752A715B029AAC011DB3MPN1061MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Zach,

 

Your concept of sub resource is quite central .

Could you define it in the terminology section 2?

 

I looked up RFC 5988 and found the following terms

 

o Relation Name: chapter

o Description: Refers to a chapter in a col= lection of resources.

o Relation Name: section

o Description: Refers to a section in a col= lection of resources.

o Relation Name: subsection

o Description: Refers to a resource serving= as a subsection in a

collection of resources.

o Relation Name: start

o Description: Refers to the first resource= in a collection of

resources.

 

Peter van der Stok

Philips Research Laboratories Eind= hoven

High Tech Campus       &nb= sp;            =             &nb= sp;            =              HT= C 34 (WB) 1-067

5656 AA Eindhoven       &n= bsp;            = ;            &n= bsp;            = ;         The Netherlands

phone +31 40 2749657      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Fax: + 31 40 2746321

mailto: Peter.van.der.Stok@philips.com

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_A31CB84F6F0BFC449C6807DF752A715B029AAC011DB3MPN1061MGDP_-- From zach@sensinode.com Mon Jan 23 00:42:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E27C21F863F for ; Mon, 23 Jan 2012 00:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1-HG4ZExOur for ; Mon, 23 Jan 2012 00:42:29 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94721F863D for ; Mon, 23 Jan 2012 00:42:28 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q0N8gPCv001965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 10:42:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 23 Jan 2012 10:42:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7088F0F2-8546-4B22-A5E7-D8F4D648327D@sensinode.com> References: To: "Stok, Peter van der" X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] I-D:core-interfaces 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, 23 Jan 2012 08:42:30 -0000 Hi Peter, On Jan 23, 2012, at 10:27 AM, Stok, Peter van der wrote: > Hi Zach, > =20 > Your concept of sub resource is quite central . > Could you define it in the terminology section 2? Sure, but this is by no means "my" concept :-) A resource collection is = pretty central to REST. For example the POST method is designed to = create a resource to a collection, and DELETE to remove it. I actually = find the "RESTful Web Services" section on Wikipedia = [http://en.wikipedia.org/wiki/Representational_state_transfer] to give a = nice (or at least short) summary of the base resource, collection and = element concepts used in REST APIs. What my core-interfaces draft does is just to formalize a simple = collection definition useful for constrained devices. The batch = definition that is there right now is a pretty limited use case. I can = foresee that we would need at least 2 other collection definitions to = cover most use cases.=20 > I looked up RFC 5988 and found the following terms > =20 > o Relation Name: chapter > o Description: Refers to a chapter in a collection of resources. > o Reference: [W3C.REC-html401-19991224] > =20 > o Relation Name: section > o Description: Refers to a section in a collection of resources. > o Reference: [W3C.REC-html401-19991224 > =20 > o Relation Name: subsection > o Description: Refers to a resource serving as a subsection in a > collection of resources. > o Reference: [W3C.REC-html401-19991224] > =20 > o Relation Name: start > o Description: Refers to the first resource in a collection of > resources. > o Reference: [W3C.REC-html401-19991224] > =20 > Are these related to your sub resource? Those do refer to parts of a collection, but something pretty specific = to HTML documents that have chapters and sections.=20 Zach > =20 > Peter > =20 > Peter van der Stok > Philips Research Laboratories Eindhoven > High Tech Campus = HTC 34 (WB) 1-067 > 5656 AA Eindhoven = The Netherlands > phone +31 40 2749657 = Fax: + 31 40 2746321 > mailto: Peter.van.der.Stok@philips.com > =20 >=20 > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From esko.dijk@philips.com Mon Jan 23 02:20:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF8521F869F for ; Mon, 23 Jan 2012 02:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exWQ5FLVHSTC for ; Mon, 23 Jan 2012 02:20:41 -0800 (PST) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB521F869A for ; Mon, 23 Jan 2012 02:20:38 -0800 (PST) Received: from mail20-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Jan 2012 10:20:29 +0000 Received: from mail20-va3 (localhost [127.0.0.1]) by mail20-va3-R.bigfish.com (Postfix) with ESMTP id 34600480182; Mon, 23 Jan 2012 10:21:10 +0000 (UTC) X-SpamScore: -51 X-BigFish: VPS-51(zz217bL15d6O9251Jc89bh542M1432N98dK4015Lzz1202hzz1033IL8275dhz2dhc1bhc31hc1ah2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail20-va3 (localhost.localdomain [127.0.0.1]) by mail20-va3 (MessageSwitch) id 1327314068241298_16771; Mon, 23 Jan 2012 10:21:08 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.250]) by mail20-va3.bigfish.com (Postfix) with ESMTP id 2C12C3A0047; Mon, 23 Jan 2012 10:21:08 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jan 2012 10:20:27 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.28]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.01.0355.003; Mon, 23 Jan 2012 10:20:34 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-05.txt) Thread-Index: AQHM2E5WAlwcr+ygyEKKK2XaGz0305YZpJdw Date: Mon, 23 Jan 2012 10:21:45 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618056C32@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <20120112232954.15845.45058.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618056925@011-DB3MPN1-012.MGDPHG.emi.philips.com> <473636A6-DE45-4CB2-9124-9A5867B7E03D@tzi.org> In-Reply-To: <473636A6-DE45-4CB2-9124-9A5867B7E03D@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org WG" Subject: Re: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-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, 23 Jan 2012 10:20:42 -0000 Thanks, > The design of CoAP tries to follow one principle that is important for im= proving interoperability and minimizing code complexity: > There should be as few ways to say the same thing as possible. > Adding a way to explicitly send the default value would violate this for = no apparent gain. > If you want the default value, just don't send the option. I agree, rather not two ways to say the same thing. It's an interesting design then, that a client has no way to _not_ use a Bl= ock Option in a request. Ok for me. Btw is there (or should there be) some mention that Block1 and Block2 MUST = be included at most once in a CoAP message? Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Saturday 21 January 2012 16:06 To: Dijk, Esko Cc: core@ietf.org WG Subject: Re: [core] New version of Block spec (Re: I-D Action: draft-ietf-c= ore-block-05.txt) On Jan 20, 2012, at 15:30, Dijk, Esko wrote: > Dear Carsten, all, > > I would say the readability is improved, as intended. Thanks. > - Table 1: should a length of 0 B be possible for both options? I would a= ssume a zero-length Block1/Block2 option value is possible and then it indi= cates the default value of 0. The design of CoAP tries to follow one principle that is important for impr= oving interoperability and minimizing code complexity: There should be as few ways to say the same thing as possible. Adding a way to explicitly send the default value would violate this for no= apparent gain. If you want the default value, just don't send the option. > - section 2.1 "(The block size given is irrelevant if M is unset)." > Isn't a correct SZX required e.g. for a stateless server, even if M is u= nset? At least all the examples set the SZX when M=3D0 the same as the prev= ious blocks in the same sequence. Yes, and the text actually is wrong (SZX is not irrelevant at all as it is = still used to scale the block number into a byte offset). Good you noticed this. I changed it to: SZX does not govern the payload size if M is unset. > Minor items > - section 1 "process loads the lower layers with" -> maybe "burdens" is b= etter here; "loads" has some other technical connotations that may confuse = a reader at this point. > - section 2 "limit the size datagrams" -> size of datagrams > - section 2 mentions "6LoWPAN" -> informative reference needed maybe? > - section 2 "still this size will be given as the block size even for the= final block." -> a bit unclear. Maybe "still the chosen power-of-two block= size will be specified in the size field of the Block option that accompan= ies the final block" is better? I have submitted a -06 with these editorial changes. Thank you! Gr=FC=DFe, Carsten ________________________________ 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 prvs=4369FF28C8=guido.moritz@uni-rostock.de Mon Jan 23 02:47:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072CC21F8540 for ; Mon, 23 Jan 2012 02:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crCTVFa7w3Sf for ; Mon, 23 Jan 2012 02:47:20 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4B20F21F846C for ; Mon, 23 Jan 2012 02:47:14 -0800 (PST) From: Guido Moritz To: 'core' Date: Mon, 23 Jan 2012 11:47:24 +0100 Message-ID: <001b01ccd9bc$64dbd7b0$2e938710$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczZu+crsbyqEpgGTSmmCMeLQOsWTg== Content-Language: de X-Originating-IP: [89.247.177.3] Subject: [core] Examples for draft-ietf-core-block 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, 23 Jan 2012 10:47:21 -0000 Dear authors, some months (years?) ago we agreed that Block will be supported for both request and response at the same time (e.g. for POST with large payload in both). As I remember we also agreed to put an example for this scenario in the draft, which is unfortunately still missing. Regards, Guido From cabo@tzi.org Mon Jan 23 05:57:41 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3D221F871B for ; Mon, 23 Jan 2012 05:57:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3+aloMVaOpp for ; Mon, 23 Jan 2012 05:57: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 366F121F8718 for ; Mon, 23 Jan 2012 05:57: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 q0NDvWw3010507; Mon, 23 Jan 2012 14:57:32 +0100 (CET) Received: from [192.168.217.117] (p54899A62.dip.t-dialin.net [84.137.154.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 59A65E0B; Mon, 23 Jan 2012 14:57:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618056C32@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Mon, 23 Jan 2012 14:57:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120112232954.15845.45058.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618056925@011-DB3MPN1-012.MGDPHG.emi.philips.com> <473636A6-DE45-4CB2-9124-9A5867B7E03D@tzi.org> <031DD135F9160444ABBE3B0C36CED618056C32@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org WG" Subject: Re: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-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, 23 Jan 2012 13:57:41 -0000 On Jan 23, 2012, at 11:21, Dijk, Esko wrote: > Btw is there (or should there be) some mention that Block1 and Block2 = MUST be included at most once in a CoAP message? core-coap says: 5.4.4. Repeating Options Each definition of an option specifies whether it is defined to occur only at most once or whether it can occur multiple times. So we indeed need to say something. Now on page 7: [=85] (or the message rejected); therefore it is identified as a critical option. It MUST NOT occur more than once. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In SVN. Will be in -07. Thanks! Gr=FC=DFe, Carsten From prvs=1370D028EB=guido.moritz@uni-rostock.de Tue Jan 24 05:01:00 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808FE21F8565 for ; Tue, 24 Jan 2012 05:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3taHRXeyMKoz for ; Tue, 24 Jan 2012 05:01:00 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id B74A421F8542 for ; Tue, 24 Jan 2012 05:00:59 -0800 (PST) From: Guido Moritz To: 'core' Date: Tue, 24 Jan 2012 14:01:12 +0100 Message-ID: <003001ccda98$4011bc10$c0353430$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Aczal7K6aaAFe4OlTIuqZr+Qx5I07A== Content-Language: de X-Originating-IP: [92.230.218.201] Subject: [core] Proxy Media Type Conversion/Encoding 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, 24 Jan 2012 13:01:00 -0000 Dear WG, last year just before Christmas I started a small discussion about the conversion of the media type in the proxy (see http://www.ietf.org/mail-archive/web/core/current/msg02493.html ). Now I have tried to put my thoughts together and have written them down in an I-D. The text is far away from a comprehensive specification. But the WG may use it as the basis for a further discussion if the described mechanism is useful and/or required and how it might be realized. http://www.ietf.org/id/draft-moritz-core-proxy-encode-00.txt Abstract: The scope of this document is to propose a new option to be used in conjunction with the CoAP proxy mechanisms. Several content types can be converted stateless into each other. The conversion may result in much more efficient representation of the resource. But currently no mechanism exists to indicate the proxy to perform the compression. Feel free to give feedback! Regards, Guido From tho@koanlogic.com Tue Jan 24 13:34:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E3A21F85D1 for ; Tue, 24 Jan 2012 13:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.639 X-Spam-Level: X-Spam-Status: No, score=-3.639 tagged_above=-999 required=5 tests=[AWL=-5.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqlzDmzOM6RR for ; Tue, 24 Jan 2012 13:34:14 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6136F21F854C for ; Tue, 24 Jan 2012 13:34:10 -0800 (PST) Received: from host26-175-dynamic.40-79-r.retail.telecomitalia.it ([79.40.175.26]:53360 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1Rpo0A-00009a-Kj; Tue, 24 Jan 2012 16:34:08 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <003001ccda98$4011bc10$c0353430$@uni-rostock.de> Date: Tue, 24 Jan 2012 22:33:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003001ccda98$4011bc10$c0353430$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.40.175.26 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: 'core' Subject: Re: [core] Proxy Media Type Conversion/Encoding 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, 24 Jan 2012 21:34:19 -0000 Hi Guido, thanks for the draft. On Jan 24, 2012, at 2:01 PM, Guido Moritz wrote: > Feel free to give feedback! Just a tiny note: Pragma is deprecated in HTTPbis (see = draft-ietf-httpbis-p6-cache for details) which is going to WGLC quite = soon. I think that it's wiser not to encourage its use.= From prvs=737109518F=guido.moritz@uni-rostock.de Wed Jan 25 05:10:44 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227D621F86B6 for ; Wed, 25 Jan 2012 05:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTgjgqevCfCU for ; Wed, 25 Jan 2012 05:10:43 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id DD02E21F8699 for ; Wed, 25 Jan 2012 05:10:42 -0800 (PST) From: Guido Moritz To: 'Thomas Fossati' References: <003001ccda98$4011bc10$c0353430$@uni-rostock.de> In-Reply-To: Date: Wed, 25 Jan 2012 14:10:34 +0100 Message-ID: <003d01ccdb62$b944e600$2bceb200$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJnfmZzbIQK3nrQEhFrrrvuWjIt+gFdnwnQlNzbO4A= Content-Language: de X-Originating-IP: [139.30.201.226] Cc: 'core' Subject: Re: [core] Proxy Media Type Conversion/Encoding 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, 25 Jan 2012 13:10:44 -0000 Thanks for the hint. Indeed, I did not hat a closer look on HTTPbis, but = was more focusing on describing the general issue.=20 Guido > -----Urspr=FCngliche Nachricht----- > Von: Thomas Fossati [mailto:tho@koanlogic.com] > Gesendet: Dienstag, 24. Januar 2012 22:33 > An: Guido Moritz > Cc: 'core' > Betreff: Re: [core] Proxy Media Type Conversion/Encoding >=20 > Hi Guido, thanks for the draft. >=20 > On Jan 24, 2012, at 2:01 PM, Guido Moritz wrote: > > Feel free to give feedback! >=20 > Just a tiny note: Pragma is deprecated in HTTPbis (see draft-ietf-httpbis-p6- > cache for details) which is going to WGLC quite soon. I think that = it's wiser not > to encourage its use.=3D From internet-drafts@ietf.org Fri Jan 27 12:27:11 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701D621F84E0; Fri, 27 Jan 2012 12:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBYJXgkKl6zV; Fri, 27 Jan 2012 12:27:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F3D21F8579; Fri, 27 Jan 2012 12:27:10 -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: 3.64p1 Message-ID: <20120127202710.7490.40110.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 12:27:10 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:27:11 -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 Work= ing Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-07.txt Pages : 28 Date : 2012-01-27 CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-block-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-block-07.txt From cabo@tzi.org Fri Jan 27 12:32:38 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB4721F862F for ; Fri, 27 Jan 2012 12:32: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=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuU16fdWHwsL for ; Fri, 27 Jan 2012 12:32: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 91D7F21F857D for ; Fri, 27 Jan 2012 12:32: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 q0RKWS47029885; Fri, 27 Jan 2012 21:32:28 +0100 (CET) Received: from [192.168.217.117] (p5489A116.dip.t-dialin.net [84.137.161.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5026571B; Fri, 27 Jan 2012 21:32:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <001b01ccd9bc$64dbd7b0$2e938710$@uni-rostock.de> Date: Fri, 27 Jan 2012 21:32:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <420D7F16-84C9-41A3-866E-AE364B5B9CB3@tzi.org> References: <001b01ccd9bc$64dbd7b0$2e938710$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1251.1) Cc: 'core' Subject: Re: [core] Examples for draft-ietf-core-block 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, 27 Jan 2012 20:32:38 -0000 Thanks for the reminder. I put in a -07 with Esko's "MUST NOT occur more than once" and one = example for the case discussed below. (I also corrected a "Block2" into a "Block1" in the explanation for an = existing example, oops.) As usual, enjoy the differences at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-07 I think we are getting asymptotic now. Gr=FC=DFe, Carsten On Jan 23, 2012, at 11:47, Guido Moritz wrote: > Dear authors, >=20 > some months (years?) ago we agreed that Block will be supported for = both > request and response at the same time (e.g. for POST with large = payload in > both). As I remember we also agreed to put an example for this = scenario in > the draft, which is unfortunately still missing. >=20 > Regards, > Guido >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From internet-drafts@ietf.org Mon Jan 30 04:59:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8723621F86C7; Mon, 30 Jan 2012 04:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMeVrWjbdHHW; Mon, 30 Jan 2012 04:59:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3E821F8624; Mon, 30 Jan 2012 04:59:02 -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: 3.64p1 Message-ID: <20120130125902.15646.32249.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 04:59:02 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-link-format-11.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, 30 Jan 2012 12:59:02 -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 Work= ing Group of the IETF. Title : CoRE Link Format Author(s) : Zach Shelby Filename : draft-ietf-core-link-format-11.txt Pages : 20 Date : 2012-01-30 This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-11.txt From zach@sensinode.com Mon Jan 30 05:09:12 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC84921F856F for ; Mon, 30 Jan 2012 05:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.752 X-Spam-Level: X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPOnyj6u6LIV for ; Mon, 30 Jan 2012 05:09:10 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5211621F859B for ; Mon, 30 Jan 2012 05:09:09 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q0UD97NI018544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 30 Jan 2012 15:09:08 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Zach Shelby In-Reply-To: <20120130125902.15646.32249.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 15:09:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91947FFA-8361-4A36-B787-FCC10670A1FC@sensinode.com> References: <20120130125902.15646.32249.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1084) Subject: Re: [core] I-D Action: draft-ietf-core-link-format-11.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, 30 Jan 2012 13:09:12 -0000 This new version of the draft fixes the source/destination bug noticed = by Esko, improves some example text and imports parmname for the ABNF = from RFC5988. Thanks to Carsten for noticing the last two issues and = helping with the update. Zach On Jan 30, 2012, at 2:59 PM, Internet-Drafts@ietf.org wrote: >=20 > 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. >=20 > Title : CoRE Link Format > Author(s) : Zach Shelby > Filename : draft-ietf-core-link-format-11.txt > Pages : 20 > Date : 2012-01-30 >=20 > This document defines Web Linking using a link format for use by > constrained web servers to describe hosted resources, their > attributes and other relationships between links. Based on the HTTP > Link Header format defined in RFC5988, the CoRE Link Format is > carried as a payload and is assigned an Internet media type. A = well- > known URI is defined as a default entry-point for requesting the > links hosted by a server. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-11.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-11.txt >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Tue Jan 31 06:04:46 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1BE21F84EF for ; Tue, 31 Jan 2012 06:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.733 X-Spam-Level: X-Spam-Status: No, score=-3.733 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRiTLWEa7pMb for ; Tue, 31 Jan 2012 06:04:46 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id DACAB21F8438 for ; Tue, 31 Jan 2012 06:04:41 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q0VE4cwT027126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 31 Jan 2012 16:04:39 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jan 2012 16:04:38 +0200 References: <20120131140034.16113.99044.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" Message-Id: <45E3F318-0B61-406F-AC41-4A8ACAC830B6@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-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: Tue, 31 Jan 2012 14:04:47 -0000 A new version of the CoRE Interfaces draft is available: http://www.ietf.org/id/draft-shelby-core-interfaces-01.txt New features added to this version, thanks to Cedric, Daniel and others = who have given improvement ideas: - Read-only Parameters - Toggle feature on Actuators using POST - Defined use of Observation and new period/step query string parameters Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: January 31, 2012 4:00:34 PM GMT+02:00 > To: zach@sensinode.com > Cc: zach@sensinode.com > Subject: New Version Notification for = draft-shelby-core-interfaces-01.txt >=20 > A new version of I-D, draft-shelby-core-interfaces-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-interfaces > Revision: 01 > Title: CoRE Interfaces > Creation date: 2012-01-31 > WG ID: Individual Submission > Number of pages: 13 >=20 > Abstract: > This document defines well-known REST interface descriptions for > Batch, Sensor, Parameter and Actuator types for use in contrained = web > servers using the CoRE Link Format. A short reference is provided > for each type that can be efficiently included in the interface > description attribute of the CoRE Link Format. These descriptions > are intended to be for general use in resource designs or for > inclusion in more specific interface profiles. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297