From andrewmcgr@google.com Sun Jun 2 23:26:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2E21F8FE8 for ; Sun, 2 Jun 2013 23:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ZnJaQ8UUutJc for ; Sun, 2 Jun 2013 23:26:25 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id ED9FE21F8F61 for ; Sun, 2 Jun 2013 23:26:15 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id a11so2098343qen.22 for ; Sun, 02 Jun 2013 23:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ulwXcYfkTooU3uwV/t7DQZfwfuE/f3hwy4dVclg5SjI=; b=H0nR4vcb8voPvQeGwR75gEby4QZ9XodVfw4Z95Nfm0I4nOhedOyxww5oYsNY82D3Ru KMK4dbz5iKmvpotTxi8LTI6UJeaWK7aBL7LAoYn5c2FDDabdEd0tMGoHhPF414vSRGGJ eoLOi0iKhWYMC/MHxJNdD8WByQdCoNW1eNV0MmWegBFNuioiyCofeXhmpX0uarilThq9 1E150KS+JBPtHHyWDEYjAJdyXBzi4OxSiKhKVy1P99s+n7fB0TqilH+58qEv9GhfYDKK 2hAOldQbABQaqiiM+uD4B81zaEKs6iqsnN8vTANc3DslInTZeEwQCGy5Pw9HbP4Q4VV6 7G1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=ulwXcYfkTooU3uwV/t7DQZfwfuE/f3hwy4dVclg5SjI=; b=fXN8BSyT+T9scpw12FpdzcYFPQwvD3P+sOI770gMCmMCFyH7+40RAVTKMv2rq62yMj ddq6yfcv6JOGNscp8GBM/J1cYh+1o6pmPdjwXfsdQOqN+aMm6iJTElVJ0zvIYB9DM285 EjE0kRJ38QtgWnh2E7Sywj74x9Y0Ux0iJ+m2aeFXRcVOSjWkoL+QgJhq0rR4q17A12HR pwsA81M3MH9B614iAy2zGt94Qx5zRbPYXwDDjeTbXdkdNnVZnVcghkfekqL52d1OrPA2 diZv7Us3ZywZf+9NHGnt+BcnKexPP2MrAUOfYE1ox0TvDmVrp2Kg56laBGA+97RCxl00 /+GQ== MIME-Version: 1.0 X-Received: by 10.49.25.114 with SMTP id b18mr20323758qeg.12.1370240774870; Sun, 02 Jun 2013 23:26:14 -0700 (PDT) Received: by 10.224.26.82 with HTTP; Sun, 2 Jun 2013 23:26:14 -0700 (PDT) Date: Mon, 3 Jun 2013 16:26:14 +1000 Message-ID: From: Andrew Mcgregor To: core@ietf.org, draft-shelby-core-resource-directory@tools.ietf.org, draft-bormann-core-links-json@tools.ietf.org, draft-castellani-core-http-mapping@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b6d9d7aa4cd9304de3a0a33 X-Gm-Message-State: ALoCoQnDEhhmwyJ3O2xVM8OLiqoXD4jHP5lTqNkv6blMSMYoO3zeAv+nHCMesOEKJ916xsTZJxf2KXeYoOV/VrTw1N9t/S5zWuGWBt1QN/kwFcCydQo4a07nZM5unvl7qO4rVFsmv5cz1+ADRm6fXcfcP9z60+cGBXSwbSSvj3uTW2n4vaSdByGtw502yEOu02FmOrXoWw0x Subject: [core] CORE calls for adoption 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, 03 Jun 2013 06:26:45 -0000 --047d7b6d9d7aa4cd9304de3a0a33 Content-Type: text/plain; charset=ISO-8859-1 Following the recent calls for adoption, the chairs believe the consensus is to adopt the four documents concerned. I have pre-approved uploads of the following four drafts, authors can you please upload a version by the -00 cutoff on July 1st. This does not need to be updated except for naming and consistency, although of course ideally any outstanding edits should be applied. draft-shelby-core-resource-directory -> draft-ietf-core-resource-directory draft-castellani-core-http-mapping -> draft-ietf-core-http-mapping draft-shelby-core-interfaces -> draft-ietf-core-interfaces draft-bormann-core-links-json -> draft-ietf-core-links-json -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --047d7b6d9d7aa4cd9304de3a0a33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Following the recent calls for adoption, the chairs believ= e the consensus is to adopt the four documents concerned.

I have pre-approved uploads of the following four drafts, authors can you= please upload a version by the -00 cutoff on July 1st. =A0This does not ne= ed to be updated except for naming and consistency, although of course idea= lly any outstanding edits should be applied.

draft-shelby-core-resource-directory = -> draft-ietf-core-resource-directory
draft-castellani-core-http-mapping -> draft-ietf-core-http= -mapping
draft-shelby-core-interfaces -> draft-ietf-core-interfaces=
draft-bormann-core-links-json -> draft-ietf-core-links-jso= n

--
Andrew McGregor=A0|=A0SRE=A0|=A0andr= ewmcgr@google.com=A0|=A0+61 4 8143 7128
--047d7b6d9d7aa4cd9304de3a0a33-- From internet-drafts@ietf.org Sun Jun 2 23:43:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E2E21F92B2; Sun, 2 Jun 2013 23:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 3PWYwy3kBH3j; Sun, 2 Jun 2013 23:43:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9F21F90EF; Sun, 2 Jun 2013 23:42:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603064256.14544.63120.idtracker@ietfa.amsl.com> Date: Sun, 02 Jun 2013 23:42:56 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-links-json-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, 03 Jun 2013 06:43:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Representing CoRE Link Collections in JSON Author(s) : Carsten Bormann Filename : draft-ietf-core-links-json-00.txt Pages : 6 Date : 2013-06-02 Abstract: Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON format (RFC4627). This specification defines a common format for representing Web links in JSON format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-links-json There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-links-json-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jun 3 02:00:16 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC9821F938E; Mon, 3 Jun 2013 02:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 p2rshsvh667a; Mon, 3 Jun 2013 02:00:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA02F21F935A; Mon, 3 Jun 2013 02:00:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603090009.6859.90732.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 02:00:09 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-resource-directory-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, 03 Jun 2013 09:00:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : CoRE Resource Directory Author(s) : Zach Shelby Srdjan Krco Carsten Bormann Filename : draft-ietf-core-resource-directory-00.txt Pages : 27 Date : 2013-06-03 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-resource-directory-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jun 3 02:12:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C1121F85B8; Mon, 3 Jun 2013 02:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 aVkdDZBW8CLP; Mon, 3 Jun 2013 02:12:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FAE21F9385; Mon, 3 Jun 2013 02:11:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603091155.29595.73933.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 02:11:55 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-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, 03 Jun 2013 09:12:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : CoRE Interfaces Author(s) : Zach Shelby Matthieu Vial Filename : draft-ietf-core-interfaces-00.txt Pages : 25 Date : 2013-06-03 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. In addition, this document defines the concepts of Function Set and Binding. The former is the basis element to create RESTful profiles and the latter helps the configuration of links between resources located on one or more endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-interfaces-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jun 3 11:56:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A111E80AE; Mon, 3 Jun 2013 11:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Q9a02ippSt0p; Mon, 3 Jun 2013 11:56:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C94E321F91B7; Mon, 3 Jun 2013 11:52:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603185226.15949.37513.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 11:52:26 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-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, 03 Jun 2013 18:56:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Best Practices for HTTP-CoAP Mapping Implementation Author(s) : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-00.txt Pages : 17 Date : 2013-06-03 Abstract: This draft provides reference information for HTTP-CoAP protocol translation proxy implementors, focusing primarily on the reverse proxy case. It details deployment options, discusses possible approaches for URI mapping, and provides a set of guidelines and considerations related to protocol translation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-http-mapping-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Bert.Greevenbosch@huawei.com Mon Jun 3 18:30:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0843021F9983 for ; Mon, 3 Jun 2013 18:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq0Uytr058yy for ; Mon, 3 Jun 2013 18:30:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6835C21E80CD for ; Mon, 3 Jun 2013 17:48:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASB72699; Tue, 04 Jun 2013 00:48:53 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 4 Jun 2013 01:48:06 +0100 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 4 Jun 2013 01:48:52 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 4 Jun 2013 08:48:49 +0800 From: Bert Greevenbosch To: "core@ietf.org" Thread-Topic: Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcw== Date: Tue, 4 Jun 2013 00:48:48 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] Concerning the format in the profile draft 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, 04 Jun 2013 01:30:37 -0000 Hello all, We, the authors of the profile description draft, would like to ask feedbac= k on the draft from the WG as follows. http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile-descripti= on/ To recap: the draft provides a new resource ".well-known/profile", which gi= ves a profile description of the resource. Currently this description inclu= des supported options, content type and block size. We would like to add su= pported methods (GET/PUT/POST/DELETE) too. The profile information is espec= ially useful for automated discovery and handling of constrained resources.= A general proxy/gateway would be an example that benefits from this. Especially the following question (as suggested in Orlando) requires attent= ion: Continue using a separate JSON based ".well-known/profile" or merge with = the ".well-known/core" link format? We discussed these options internally. During that discussion, we identifie= d several arguments in favour of either option. Please find below a list of= arguments we found: In favour of JSON ".well-known/profile": - Allow hierarchical structure through nested JSON fields; - Allow usage of field types, such as integer, float and string; - Keep link format lean and simple; - Server can treat the ".well-known/profile" file as opaque data; it does n= ot need to handle or implement JSON. In favour of integration with ".well-known/core" link format: - No need to add JSON parser to client for this functionality; - Coding in link format is more compact than in JSON; - Link format is slightly simpler to parse. We were also thinking of some kind of hybrid solution, where we add an attr= ibute to ".well-known/core" that indicates if ".well-known/profile" is supp= orted. The latter will then provide the more detailed profile information. What are your thoughts? We would be happy to receive your feedback and cons= iderations! Best regards, Bert From kovatsch@inf.ethz.ch Wed Jun 5 06:31:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18FA21F9A60 for ; Wed, 5 Jun 2013 06:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs0on29V+slw for ; Wed, 5 Jun 2013 06:31:15 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2400321F9A52 for ; Wed, 5 Jun 2013 06:31:10 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 5 Jun 2013 15:31:04 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Wed, 5 Jun 2013 15:31:06 +0200 From: "Kovatsch Matthias" To: Bert Greevenbosch , "core@ietf.org" Thread-Topic: Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiA Date: Wed, 5 Jun 2013 13:31:06 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Concerning the format in the profile draft 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, 05 Jun 2013 13:31:27 -0000 Dear Bert My main concern about the profile draft is its overlap with /.well-known/co= re. I think your profile should concentrate on the endpoint in general inst= ead of individual resources. From my practical experience, information abou= t supported options and buffer sizes is independent from the resources anyw= ay. Currently, there is no way to learn about the application profile (e.g., OM= A Lightweight) an endpoint implements. Currently, a client has to guess thi= s from the resource structure or requires some out-of-band knowledge. There= are other bindings coming up, e.g., BACnet, so it would be good to provide= this information in such an endpoint profile. Ciao Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Bert Greevenbosch > Sent: Dienstag, 4. Juni 2013 02:49 > To: core@ietf.org > Subject: [core] Concerning the format in the profile draft >=20 > Hello all, >=20 > We, the authors of the profile description draft, would like to ask feedb= ack > on the draft from the WG as follows. >=20 > http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile- > description/ >=20 > To recap: the draft provides a new resource ".well-known/profile", which > gives a profile description of the resource. Currently this description i= ncludes > supported options, content type and block size. We would like to add > supported methods (GET/PUT/POST/DELETE) too. The profile information is > especially useful for automated discovery and handling of constrained > resources. A general proxy/gateway would be an example that benefits from > this. >=20 > Especially the following question (as suggested in Orlando) requires > attention: >=20 > Continue using a separate JSON based ".well-known/profile" or merge wit= h > the ".well-known/core" link format? >=20 > We discussed these options internally. During that discussion, we identif= ied > several arguments in favour of either option. Please find below a list of > arguments we found: >=20 > In favour of JSON ".well-known/profile": > - Allow hierarchical structure through nested JSON fields; > - Allow usage of field types, such as integer, float and string; > - Keep link format lean and simple; > - Server can treat the ".well-known/profile" file as opaque data; it does= not > need to handle or implement JSON. >=20 > In favour of integration with ".well-known/core" link format: > - No need to add JSON parser to client for this functionality; > - Coding in link format is more compact than in JSON; > - Link format is slightly simpler to parse. >=20 > We were also thinking of some kind of hybrid solution, where we add an > attribute to ".well-known/core" that indicates if ".well-known/profile" i= s > supported. The latter will then provide the more detailed profile informa= tion. >=20 > What are your thoughts? We would be happy to receive your feedback and > considerations! >=20 > Best regards, > Bert > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From martin.stiemerling@neclab.eu Thu Jun 6 02:23:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9190321F9808; Thu, 6 Jun 2013 02:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 yjGt9ZC3zgRQ; Thu, 6 Jun 2013 02:23:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 018BC21F96E1; Thu, 6 Jun 2013 02:23:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606092327.10772.34116.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 02:23:27 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-coap-17: (with DISCUSS) 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, 06 Jun 2013 09:23:31 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-core-coap-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated based on - 17. = A well-written document and I have a few points to discuss. = Here are the issues (based on my own review and input from Joe Touch and Michael Scharf): 1) done. 2) done. 3) done. 4) done. 5) done. 6) done. 7) done. = 8) Flow Control/Receiver Buffer The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness. = The 4.13 "Request Entity Too Large" with a protocol field that indicates the maximum data size would be fixing this. = 9) done. From esko.dijk@philips.com Thu Jun 6 04:17:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C21921F94E1 for ; Thu, 6 Jun 2013 04:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of1qk7svdXuJ for ; Thu, 6 Jun 2013 04:17:34 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE0621F91BC for ; Thu, 6 Jun 2013 04:17:34 -0700 (PDT) Received: from mail90-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE017.bigfish.com (10.243.66.80) with Microsoft SMTP Server id 14.1.225.23; Thu, 6 Jun 2013 11:17:33 +0000 Received: from mail90-co1 (localhost [127.0.0.1]) by mail90-co1-R.bigfish.com (Postfix) with ESMTP id E98F6800363; Thu, 6 Jun 2013 11:17:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz15d6O9251J542I1432I1455M14ffI217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail90-co1 (localhost.localdomain [127.0.0.1]) by mail90-co1 (MessageSwitch) id 1370517451638261_3684; Thu, 6 Jun 2013 11:17:31 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.251]) by mail90-co1.bigfish.com (Postfix) with ESMTP id 967943C0064; Thu, 6 Jun 2013 11:17:31 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 6 Jun 2013 11:17:31 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.219]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.02.0328.011; Thu, 6 Jun 2013 11:17:03 +0000 From: "Dijk, Esko" To: "Kovatsch Matthias" , Bert Greevenbosch , "core@ietf.org" Thread-Topic: Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAAC3HsHA= Date: Thu, 6 Jun 2013 11:18:44 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Concerning the format in the profile draft 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, 06 Jun 2013 11:17:39 -0000 > ...profile should concentrate on the endpoint in general instead of indiv= idual resources... Agree! I'm wondering when such a profile is needed, i.e. in what use cases would a= client have to fetch an explicit profile of an endpoint? (versus the stand= ard CoAp approach of just trial-and-error to see if an option is supported,= or not. Or versus the out-of-band approach where knowledge of a spec combi= ned with Link Format resource types gives enough information on supported o= ptions.) Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kov= atsch Matthias Sent: Wednesday, June 05, 2013 15:31 To: Bert Greevenbosch; core@ietf.org Subject: Re: [core] Concerning the format in the profile draft Dear Bert My main concern about the profile draft is its overlap with /.well-known/co= re. I think your profile should concentrate on the endpoint in general inst= ead of individual resources. From my practical experience, information abou= t supported options and buffer sizes is independent from the resources anyw= ay. Currently, there is no way to learn about the application profile (e.g., OM= A Lightweight) an endpoint implements. Currently, a client has to guess thi= s from the resource structure or requires some out-of-band knowledge. There= are other bindings coming up, e.g., BACnet, so it would be good to provide= this information in such an endpoint profile. Ciao Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of Bert Greevenbosch > Sent: Dienstag, 4. Juni 2013 02:49 > To: core@ietf.org > Subject: [core] Concerning the format in the profile draft > > Hello all, > > We, the authors of the profile description draft, would like to ask > feedback on the draft from the WG as follows. > > http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile- > description/ > > To recap: the draft provides a new resource ".well-known/profile", > which gives a profile description of the resource. Currently this > description includes supported options, content type and block size. > We would like to add supported methods (GET/PUT/POST/DELETE) too. The > profile information is especially useful for automated discovery and > handling of constrained resources. A general proxy/gateway would be an > example that benefits from this. > > Especially the following question (as suggested in Orlando) requires > attention: > > Continue using a separate JSON based ".well-known/profile" or merge > with the ".well-known/core" link format? > > We discussed these options internally. During that discussion, we > identified several arguments in favour of either option. Please find > below a list of arguments we found: > > In favour of JSON ".well-known/profile": > - Allow hierarchical structure through nested JSON fields; > - Allow usage of field types, such as integer, float and string; > - Keep link format lean and simple; > - Server can treat the ".well-known/profile" file as opaque data; it > does not need to handle or implement JSON. > > In favour of integration with ".well-known/core" link format: > - No need to add JSON parser to client for this functionality; > - Coding in link format is more compact than in JSON; > - Link format is slightly simpler to parse. > > We were also thinking of some kind of hybrid solution, where we add an > attribute to ".well-known/core" that indicates if > ".well-known/profile" is supported. The latter will then provide the more= detailed profile information. > > What are your thoughts? We would be happy to receive your feedback and > considerations! > > Best regards, > Bert > _______________________________________________ > 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 rick.bullotta@thingworx.com Thu Jun 6 04:51:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0046421F9A2F for ; Thu, 6 Jun 2013 04:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNKZeQCWjD2K for ; Thu, 6 Jun 2013 04:51:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id F08BB21F99AB for ; Thu, 6 Jun 2013 04:51:19 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB004.namprd06.prod.outlook.com (10.242.190.155) with Microsoft SMTP Server (TLS) id 15.0.702.21; Thu, 6 Jun 2013 11:51:09 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) with mapi id 15.00.0702.005; Thu, 6 Jun 2013 11:51:09 +0000 From: Rick Bullotta To: "Dijk, Esko" , "Kovatsch Matthias" , Bert Greevenbosch , "core@ietf.org" Thread-Topic: Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAAC3HsHAAAU65YA== Date: Thu, 6 Jun 2013 11:51:08 +0000 Message-ID: <3158efb9882c43acbba434e93e31cfff@BLUPR06MB001.namprd06.prod.outlook.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.59.2.242] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR06MB004; H:BLUPR06MB001.namprd06.prod.outlook.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Subject: Re: [core] Concerning the format in the profile draft 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, 06 Jun 2013 11:51:25 -0000 If I understand the situation correctly, the ability to access a device's p= rofile in this way is extremely useful in situations when a development env= ironment/platform (e.g. our ThingWorx platform) wants to access the metadat= a for a device even when the device itself is offline. It provides a durab= le catalog for this metadata information, enabling development activities t= o occur independent of connection status. Additionally, with some further = design work, this resource repository can become an excellent mechanism for= accessing and managing the definition(s) of "generic profiles" (e.g. an en= ergy meter, a traffic light, a refrigerated shipping container) and their a= ssociation to specific devices. Apologies if I misunderstood - new to the discussions! Cheers, Rick Bullotta ThingWorx -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dij= k, Esko Sent: Thursday, June 06, 2013 7:19 AM To: Kovatsch Matthias; Bert Greevenbosch; core@ietf.org Subject: Re: [core] Concerning the format in the profile draft > ...profile should concentrate on the endpoint in general instead of indiv= idual resources... Agree! I'm wondering when such a profile is needed, i.e. in what use cases would a= client have to fetch an explicit profile of an endpoint? (versus the stand= ard CoAp approach of just trial-and-error to see if an option is supported,= or not. Or versus the out-of-band approach where knowledge of a spec combi= ned with Link Format resource types gives enough information on supported o= ptions.) Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kov= atsch Matthias Sent: Wednesday, June 05, 2013 15:31 To: Bert Greevenbosch; core@ietf.org Subject: Re: [core] Concerning the format in the profile draft Dear Bert My main concern about the profile draft is its overlap with /.well-known/co= re. I think your profile should concentrate on the endpoint in general inst= ead of individual resources. From my practical experience, information abou= t supported options and buffer sizes is independent from the resources anyw= ay. Currently, there is no way to learn about the application profile (e.g., OM= A Lightweight) an endpoint implements. Currently, a client has to guess thi= s from the resource structure or requires some out-of-band knowledge. There= are other bindings coming up, e.g., BACnet, so it would be good to provide= this information in such an endpoint profile. Ciao Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf=20 > Of Bert Greevenbosch > Sent: Dienstag, 4. Juni 2013 02:49 > To: core@ietf.org > Subject: [core] Concerning the format in the profile draft > > Hello all, > > We, the authors of the profile description draft, would like to ask=20 > feedback on the draft from the WG as follows. > > http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile- > description/ > > To recap: the draft provides a new resource ".well-known/profile",=20 > which gives a profile description of the resource. Currently this=20 > description includes supported options, content type and block size. > We would like to add supported methods (GET/PUT/POST/DELETE) too. The=20 > profile information is especially useful for automated discovery and=20 > handling of constrained resources. A general proxy/gateway would be an=20 > example that benefits from this. > > Especially the following question (as suggested in Orlando) requires > attention: > > Continue using a separate JSON based ".well-known/profile" or merge=20 > with the ".well-known/core" link format? > > We discussed these options internally. During that discussion, we=20 > identified several arguments in favour of either option. Please find=20 > below a list of arguments we found: > > In favour of JSON ".well-known/profile": > - Allow hierarchical structure through nested JSON fields; > - Allow usage of field types, such as integer, float and string; > - Keep link format lean and simple; > - Server can treat the ".well-known/profile" file as opaque data; it=20 > does not need to handle or implement JSON. > > In favour of integration with ".well-known/core" link format: > - No need to add JSON parser to client for this functionality; > - Coding in link format is more compact than in JSON; > - Link format is slightly simpler to parse. > > We were also thinking of some kind of hybrid solution, where we add an=20 > attribute to ".well-known/core" that indicates if=20 > ".well-known/profile" is supported. The latter will then provide the more= detailed profile information. > > What are your thoughts? We would be happy to receive your feedback and=20 > considerations! > > Best regards, > Bert > _______________________________________________ > 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From kovatsch@inf.ethz.ch Thu Jun 6 06:28:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1383221F9A16 for ; Thu, 6 Jun 2013 06:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA28JWN0BkeC for ; Thu, 6 Jun 2013 06:27:56 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id F2C0421F9A0B for ; Thu, 6 Jun 2013 06:27:54 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 6 Jun 2013 15:27:37 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Thu, 6 Jun 2013 15:27:45 +0200 From: "Kovatsch Matthias" To: "Dijk, Esko" , Bert Greevenbosch , "core@ietf.org" Thread-Topic: Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAAC3HsHAABJWxUA== Date: Thu, 6 Jun 2013 13:27:45 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514F1F6F0@MBX10.d.ethz.ch> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Concerning the format in the profile draft 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, 06 Jun 2013 13:28:02 -0000 > I'm wondering when such a profile is needed, i.e. in what use cases would= a > client have to fetch an explicit profile of an endpoint? (versus the stan= dard > CoAp approach of just trial-and-error to see if an option is supported, o= r not. > Or versus the out-of-band approach where knowledge of a spec combined > with Link Format resource types gives enough information on supported > options.) You will not need it in closed deployments without heterogeneity (just like= what we had before). I becomes interesting, in my opinion, when you build ad hoc applications li= ke Web mashups. There the profile might be unknown a priori, but needed for= successful interaction (e.g., deciphering the OMA Object IDs). Ciao Matthias From zach@sensinode.com Thu Jun 6 09:23:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CF521F999E for ; Thu, 6 Jun 2013 09:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVjZ7SvZngCp for ; Thu, 6 Jun 2013 09:23:20 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3F21F941F for ; Thu, 6 Jun 2013 09:23:19 -0700 (PDT) Received: from [10.19.19.78] ([62.205.127.11]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r56GIOdN029430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 19:18:33 +0300 Content-Type: multipart/signed; boundary="Apple-Mail=_7E17DF57-6EB1-49D2-B031-2DE2347FE13C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> Date: Thu, 6 Jun 2013 18:18:23 +0200 Message-Id: <25DEB11B-7C44-4E69-A912-51BE7D3ECFD9@sensinode.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] Concerning the format in the profile draft 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, 06 Jun 2013 16:23:26 -0000 --Apple-Mail=_7E17DF57-6EB1-49D2-B031-2DE2347FE13C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2013, at 3:31 PM, Kovatsch Matthias = wrote: > Dear Bert >=20 > My main concern about the profile draft is its overlap with = /.well-known/core. I think your profile should concentrate on the = endpoint in general instead of individual resources. =46rom my practical = experience, information about supported options and buffer sizes is = independent from the resources anyway. I tend to agree, information about an endpoint's CoAP implementation = capabilities is separate from the list of resources it has available.=20 > Currently, there is no way to learn about the application profile = (e.g., OMA Lightweight) an endpoint implements. Currently, a client has = to guess this from the resource structure or requires some out-of-band = knowledge. There are other bindings coming up, e.g., BACnet, so it would = be good to provide this information in such an endpoint profile. Why would this be mixed with information about the CoAP implementation? = We already have a means for indicating what semantics a resource has = using the Resource Type link attribute. In the case of OMA Lightweight, = the specification actually specifies the Resource Type "oma.lwm2m" which = indicates the root resource of the Object tree: ;rt=3Doma.lwm2m,, The first link is the root of the OMA tree, and the second and third = links are Object Instances.=20 Similarly, if other REST interfaces were hosted on that endpoint, they = should probably indicate themselves with a Resource Type. So I think we = have this covered with our existing mechanisms. Zach=20 >=20 > Ciao > Matthias >=20 >=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >> Bert Greevenbosch >> Sent: Dienstag, 4. Juni 2013 02:49 >> To: core@ietf.org >> Subject: [core] Concerning the format in the profile draft >>=20 >> Hello all, >>=20 >> We, the authors of the profile description draft, would like to ask = feedback >> on the draft from the WG as follows. >>=20 >> http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile- >> description/ >>=20 >> To recap: the draft provides a new resource ".well-known/profile", = which >> gives a profile description of the resource. Currently this = description includes >> supported options, content type and block size. We would like to add >> supported methods (GET/PUT/POST/DELETE) too. The profile information = is >> especially useful for automated discovery and handling of constrained >> resources. A general proxy/gateway would be an example that benefits = from >> this. >>=20 >> Especially the following question (as suggested in Orlando) requires >> attention: >>=20 >> Continue using a separate JSON based ".well-known/profile" or merge = with >> the ".well-known/core" link format? >>=20 >> We discussed these options internally. During that discussion, we = identified >> several arguments in favour of either option. Please find below a = list of >> arguments we found: >>=20 >> In favour of JSON ".well-known/profile": >> - Allow hierarchical structure through nested JSON fields; >> - Allow usage of field types, such as integer, float and string; >> - Keep link format lean and simple; >> - Server can treat the ".well-known/profile" file as opaque data; it = does not >> need to handle or implement JSON. >>=20 >> In favour of integration with ".well-known/core" link format: >> - No need to add JSON parser to client for this functionality; >> - Coding in link format is more compact than in JSON; >> - Link format is slightly simpler to parse. >>=20 >> We were also thinking of some kind of hybrid solution, where we add = an >> attribute to ".well-known/core" that indicates if = ".well-known/profile" is >> supported. The latter will then provide the more detailed profile = information. >>=20 >> What are your thoughts? We would be happy to receive your feedback = and >> considerations! >>=20 >> Best regards, >> Bert >> _______________________________________________ >> 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 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net --Apple-Mail=_7E17DF57-6EB1-49D2-B031-2DE2347FE13C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw ggRLoAMCAQICECoFEeuyI56VQvKTVfGMSkAwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjEyMDgwMDAwMDBaFw0x MzEyMDgyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9XHvgVWAUvzoGUuYXHRSH2qT6vjO T31W2uFGX4wmCZskhrghMWrKYdosjugUlnIml+tsNlGaT7ZVPrURpJrAmlMwj9ViL+qvLd56RZqM T1sGMX2w0rCGAVWJK2AWy8J8Oub/xaiZ+MdR0LQCli0BeO9GNPEM/2kEvIOtzxjFLtyKHe7eNf5q yB2n9TWvJ/kYvhIaFAFvib8E9A705fLwu0z/mW3CBl/XLouFlPDBc0s/5CKl9+5DFya6tudTTqex xLx6rTqqKznyHdj+8PrnHTWvRtPcxucyMOoNXJQaxNtY5oZh7inZd20n/OVkZLhp/mI5p9eTziXq /iyKYxvylwIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA5OcugibLpuXR75zXjKYtS5De MSQxi/YpIE2xjS5zkLPsHSs8gVLRtiyoU+akbSguYN3f0gjEeABFz2s+BHLEWqYgREQmCC/YWVuj nvXYR7lIccC4woyWY5L0FXygx6nibxm+SlWOo1GVV77gF7BiO8PKcfZmaRYcr49u1Miov/R8fnFh 15/HmVG6/V2URo7Z6F+ZTvxvZA//O4rQgTd2hBBefs9A4jU3HYXKuYcCly8haQNvqSLUc4m67sIJ oZVO+YH/WwgiMimpA+VdJTyfJDOFdIEQsnjPHUNBzHdfg7qQwgfV/1i0fHi+w1guDXM7CGWdgrg/ GIc/dm71plzFGDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7 btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4 mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9 OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1 qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxKQDAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDYx NjE4MjRaMCMGCSqGSIb3DQEJBDEWBBQ+kh64U+Lq2efoZT8WAjSR2X1IOjCCAQMGCSsGAQQBgjcQ BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEczAhAqBRHrsiOelULyk1XxjEpAMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxK QDANBgkqhkiG9w0BAQEFAASCAQBlBf60cFbOv88NYJtUWzPBBE3zIrFrNOyy+MnIeZH0dFTw1xM8 LiXyTFa5RRAKznjut8bs6F5JCuuBfD7Kj2tnDr2eY8iPDw8S1F22MT0lPL4z3Ps5S1lo+c8qiYQN qx4LWftj0uadEjyLzZpmEoudd4V35jZcYSP4XxXcaRyUQI89b777w0pwCTpBOAQwd85Wwh8emmHy 6QiWtInrgGi5uITKFpskH6XkLUy0sk777XxRN4sYjhNyMxO39KXq7nWgUvVN0HNMe+Vwk+DtJYmz 3Jmjx+MuGA+qIaePkYUU2/tFjyTgJEF8QI/dgTbHkKh0n4U06K6HSDasFgDCO9RiAAAAAAAA --Apple-Mail=_7E17DF57-6EB1-49D2-B031-2DE2347FE13C-- From zach@sensinode.com Thu Jun 6 13:02:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3021E8054 for ; Thu, 6 Jun 2013 13:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 Di0VhuzRsC0E for ; Thu, 6 Jun 2013 13:02:18 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1621E8050 for ; Thu, 6 Jun 2013 13:02:15 -0700 (PDT) Received: from [10.222.13.33] ([82.203.205.227]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r56K2B0n006432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 23:02:12 +0300 Content-Type: multipart/signed; boundary="Apple-Mail=_38F781B9-F07C-401A-96E6-FFD7913D6309"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <3158efb9882c43acbba434e93e31cfff@BLUPR06MB001.namprd06.prod.outlook.com> Date: Thu, 6 Jun 2013 18:25:34 +0200 Message-Id: <8E442EC5-D6E4-4D9B-A25E-5960D3929CB5@sensinode.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <3158efb9882c43acbba434e93e31cfff@BLUPR06MB001.namprd06.prod.outlook.com> To: Rick Bullotta X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org WG" Subject: Re: [core] Concerning the format in the profile draft 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, 06 Jun 2013 20:02:35 -0000 --Apple-Mail=_38F781B9-F07C-401A-96E6-FFD7913D6309 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rick, On Jun 6, 2013, at 1:51 PM, Rick Bullotta = wrote: > If I understand the situation correctly, the ability to access a = device's profile in this way is extremely useful in situations when a = development environment/platform (e.g. our ThingWorx platform) wants to = access the metadata for a device even when the device itself is offline. = It provides a durable catalog for this metadata information, enabling = development activities to occur independent of connection status. =20 No, the draft that Bert et al. were discussing here is about discovering = the CoAP protocol capabilities that an endpoint supports using a special = URI that can be requested. For example does an endpoint support a = special CoAP option. "Profile" is probably a really poor term to = describe that (confuses me at least).=20 We do have a mechanism already to do what you describe. That is the CoRE = Link Format (RFC6690) format that we use to describe the resources and = their meta-data that an endpoint has available. By default these links = can be discovered from any endpoint by doing a GET request to = /.well-known/core. We also have a mechanism to post these links to a = central Resource Directory where they are available even when the = endpoint is off-line: http://tools.ietf.org/html/draft-ietf-core-resource-directory > Additionally, with some further design work, this resource repository = can become an excellent mechanism for accessing and managing the = definition(s) of "generic profiles" (e.g. an energy meter, a traffic = light, a refrigerated shipping container) and their association to = specific devices. Exactly! The new OMA Lightweight standard defines a complete Object = model and provides an Object registry, so when you see such a link, you = know exactly what the resource is about (Light Control Object, Location = Object, Device Object etc.).=20 Regards, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net --Apple-Mail=_38F781B9-F07C-401A-96E6-FFD7913D6309 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw ggRLoAMCAQICECoFEeuyI56VQvKTVfGMSkAwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjEyMDgwMDAwMDBaFw0x MzEyMDgyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9XHvgVWAUvzoGUuYXHRSH2qT6vjO T31W2uFGX4wmCZskhrghMWrKYdosjugUlnIml+tsNlGaT7ZVPrURpJrAmlMwj9ViL+qvLd56RZqM T1sGMX2w0rCGAVWJK2AWy8J8Oub/xaiZ+MdR0LQCli0BeO9GNPEM/2kEvIOtzxjFLtyKHe7eNf5q yB2n9TWvJ/kYvhIaFAFvib8E9A705fLwu0z/mW3CBl/XLouFlPDBc0s/5CKl9+5DFya6tudTTqex xLx6rTqqKznyHdj+8PrnHTWvRtPcxucyMOoNXJQaxNtY5oZh7inZd20n/OVkZLhp/mI5p9eTziXq /iyKYxvylwIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA5OcugibLpuXR75zXjKYtS5De MSQxi/YpIE2xjS5zkLPsHSs8gVLRtiyoU+akbSguYN3f0gjEeABFz2s+BHLEWqYgREQmCC/YWVuj nvXYR7lIccC4woyWY5L0FXygx6nibxm+SlWOo1GVV77gF7BiO8PKcfZmaRYcr49u1Miov/R8fnFh 15/HmVG6/V2URo7Z6F+ZTvxvZA//O4rQgTd2hBBefs9A4jU3HYXKuYcCly8haQNvqSLUc4m67sIJ oZVO+YH/WwgiMimpA+VdJTyfJDOFdIEQsnjPHUNBzHdfg7qQwgfV/1i0fHi+w1guDXM7CGWdgrg/ GIc/dm71plzFGDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7 btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4 mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9 OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1 qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxKQDAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDYx NjI1MzRaMCMGCSqGSIb3DQEJBDEWBBS733Lhv8dpCRGU86DbAX/C1N4nzjCCAQMGCSsGAQQBgjcQ BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEczAhAqBRHrsiOelULyk1XxjEpAMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxK QDANBgkqhkiG9w0BAQEFAASCAQAzAMTzsRp4bNk7uV5kzxZtqChc14jQvFdM5apQ9kCGiqF7o3/G q7CYNfGC+IBYIPI2pM8srpP7I0eqAidQAHdGZMpzqwPKr0yz+k+XNFhyu6sPNnL8eZIaFK1P3tnj P0iqQ9L3f1s/tLP2woUxdI4w4B+0bP0AI/U0dXXgfAdKulgboVZiTbX7PG+1P8OPZjCGAp4nP7dx PPaxSbbFlKDwhYxtf/BzU7W5VF5qGuD7gLvn5RdRjniEMgSUOxmDxWY9SLxiMRMRL4ci/pIxSHWd fLWtX44bdU1WuQmtzhf0obeRPOPRw6BNz8m4NKzGohqiQL8rEuLu6PFGwli3B4zrAAAAAAAA --Apple-Mail=_38F781B9-F07C-401A-96E6-FFD7913D6309-- From kovatsch@inf.ethz.ch Thu Jun 6 16:55:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8B721F9955 for ; Thu, 6 Jun 2013 16:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ccgIfXwtF3t for ; Thu, 6 Jun 2013 16:55:33 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id CCC2321F9950 for ; Thu, 6 Jun 2013 16:55:31 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 7 Jun 2013 01:55:13 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Fri, 7 Jun 2013 01:55:23 +0200 From: "Kovatsch Matthias" To: Zach Shelby Thread-Topic: [core] Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAADReo4AAE/dn0A== Date: Thu, 6 Jun 2013 23:55:22 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514F250D1@MBX10.d.ethz.ch> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <25DEB11B-7C44-4E69-A912-51BE7D3ECFD9@sensinode.com> In-Reply-To: <25DEB11B-7C44-4E69-A912-51BE7D3ECFD9@sensinode.com> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.57.171.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] Concerning the format in the profile draft 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, 06 Jun 2013 23:55:39 -0000 > Why would this be mixed with information about the CoAP implementation? W= e > already have a means for indicating what semantics a resource has using t= he > Resource Type link attribute. In the case of OMA Lightweight, the specifi= cation > actually specifies the Resource Type "oma.lwm2m" which indicates the root > resource of the Object tree: >=20 > ;rt=3Doma.lwm2m,, >=20 > The first link is the root of the OMA tree, and the second and third link= s are > Object Instances. Ah, okay. A while ago, OMA Objects were at the root, I think. This looks go= od now. > Similarly, if other REST interfaces were hosted on that endpoint, they sh= ould > probably indicate themselves with a Resource Type. So I think we have thi= s > covered with our existing mechanisms. So the remaining information for /.well-known/profile would be Options and = sizes. Nonetheless, this is covered by the corresponding error messages and= block size negotiation... Ciao Matthias From Bert.Greevenbosch@huawei.com Fri Jun 7 01:46:29 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91D421F8F29 for ; Fri, 7 Jun 2013 01:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=0.910, 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 L7b11sFYW3Mh for ; Fri, 7 Jun 2013 01:46:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A31B721F885A for ; Fri, 7 Jun 2013 01:46:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASE70753; Fri, 07 Jun 2013 08:46:21 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 09:45:24 +0100 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 16:46:17 +0800 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.007; Fri, 7 Jun 2013 16:46:05 +0800 From: Bert Greevenbosch To: "Kovatsch Matthias" , "core@ietf.org" Thread-Topic: Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAAFpC/4A= Date: Fri, 7 Jun 2013 08:46:04 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D77957C@szxeml558-mbx.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Concerning the format in the profile draft 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, 07 Jun 2013 08:46:30 -0000 SGkgTWF0dGhpYXMsDQoNCkluZGVlZCB0aGUgb3ZlcmxhcCB3aXRoICIud2VsbC1rbm93bi9jb3Jl IiBpcyBhbiBpc3N1ZS4gVGhpcyBpcyB3aHkgd2UgYXJlIGNvbnNpZGVyaW5nIG1lcmdpbmcgaXQu IEkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgYXZvaWQgc2VuZGluZyBkb3VibGUgaW5mb3JtYXRpb24s IGkuZS4gYXZvaWQgcHV0dGluZyBpbmZvcm1hdGlvbiBmcm9tICIud2VsbC1rbm93bi9jb3JlIiBp bnRvICIud2VsbC1rbm93bi9wcm9maWxlIi4gQW4gaXNzdWUgd2l0aCB0aGF0IHdvdWxkIGJlIHRo YXQgYSBjbGllbnQvcHJveHkgdGhhdCB3YW50cyB0byByZW1lbWJlciBhbGwgaW5mbyBuZWVkcyB0 byBhZ2dyZWdhdGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgdHdvIHJlc291cmNlcyB0aG91Z2guDQoN CkFzIGZvciB0aGUgZ3JhbnVsYXJpdHkgcmVzb3VyY2VzL2VuZHBvaW50cywgSSB1bmRlcnN0YW5k IHlvdXIgY29uY2Vybi4gSW5kZWVkIEkgYmVsaWV2ZSB0aGF0IG1vc3Qgb2YgdGhlIHRpbWUgYW4g ZW5kcG9pbnQgdXNlcyB0aGUgc2FtZSBvcHRpb25zL2Jsb2NrIHNpemVzIGZvciBhbGwgb2YgaXRz IHJlc291cmNlcy4gSG93ZXZlciwgdGhlcmUgbWF5IGJlIGV4Y2VwdGlvbnMuIEZvciBleGFtcGxl LCB3aGVuIHRoZSBlbmRwb2ludCBpcyBhIHBoeXNpY2FsIGRldmljZSB3aXJlZCB0byBzb21lIG90 aGVyIGRldmljZXMsIHRob3NlIG90aGVyIGRldmljZXMgbWF5IGhhdmUgZGlmZmVyZW50IGNhcGFi aWxpdGllcy4gVGhhdCBtYXkgbGVhZCB0byBzdXBwb3J0IG9yIG5vdCBmb3IgYmxvY2sgLyBvYnNl cnZlLCBkaWZmZXJlbnQgYmxvY2tzaXplcywgZXRjLg0KDQpJZiBhbGwgcmVzb3VyY2VzIG9uIHRo ZSBlbmRwb2ludCBzaGFyZSB0aGUgc2FtZSBwcm9maWxlIGluZm9ybWF0aW9uLCB0aGVuIGluICIu d2VsbC1rbm93bi9wcm9maWxlIiBhbGwgY2FuIGJlIHNpZ25hbGxlZCB1c2luZyB0aGUgZGVmYXVs dCA8Lj4gcmVzb3VyY2UuDQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogS292YXRzY2ggTWF0dGhpYXMgW21haWx0bzprb3ZhdHNjaEBp bmYuZXRoei5jaF0gDQpTZW50OiAyMDEzxOo21MI1yNUgMjE6MzENClRvOiBCZXJ0IEdyZWV2ZW5i b3NjaDsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IENvbmNlcm5pbmcgdGhlIGZvcm1hdCBp biB0aGUgcHJvZmlsZSBkcmFmdA0KDQpEZWFyIEJlcnQNCg0KTXkgbWFpbiBjb25jZXJuIGFib3V0 IHRoZSBwcm9maWxlIGRyYWZ0IGlzIGl0cyBvdmVybGFwIHdpdGggLy53ZWxsLWtub3duL2NvcmUu IEkgdGhpbmsgeW91ciBwcm9maWxlIHNob3VsZCBjb25jZW50cmF0ZSBvbiB0aGUgZW5kcG9pbnQg aW4gZ2VuZXJhbCBpbnN0ZWFkIG9mIGluZGl2aWR1YWwgcmVzb3VyY2VzLiBGcm9tIG15IHByYWN0 aWNhbCBleHBlcmllbmNlLCBpbmZvcm1hdGlvbiBhYm91dCBzdXBwb3J0ZWQgb3B0aW9ucyBhbmQg YnVmZmVyIHNpemVzIGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHJlc291cmNlcyBhbnl3YXkuDQoN CkN1cnJlbnRseSwgdGhlcmUgaXMgbm8gd2F5IHRvIGxlYXJuIGFib3V0IHRoZSBhcHBsaWNhdGlv biBwcm9maWxlIChlLmcuLCBPTUEgTGlnaHR3ZWlnaHQpIGFuIGVuZHBvaW50IGltcGxlbWVudHMu IEN1cnJlbnRseSwgYSBjbGllbnQgaGFzIHRvIGd1ZXNzIHRoaXMgZnJvbSB0aGUgcmVzb3VyY2Ug c3RydWN0dXJlIG9yIHJlcXVpcmVzIHNvbWUgb3V0LW9mLWJhbmQga25vd2xlZGdlLiBUaGVyZSBh cmUgb3RoZXIgYmluZGluZ3MgY29taW5nIHVwLCBlLmcuLCBCQUNuZXQsIHNvIGl0IHdvdWxkIGJl IGdvb2QgdG8gcHJvdmlkZSB0aGlzIGluZm9ybWF0aW9uIGluIHN1Y2ggYW4gZW5kcG9pbnQgcHJv ZmlsZS4NCg0KQ2lhbw0KTWF0dGhpYXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mDQo+IEJlcnQgR3JlZXZlbmJvc2NoDQo+IFNlbnQ6IERpZW5zdGFn LCA0LiBKdW5pIDIwMTMgMDI6NDkNCj4gVG86IGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2Nv cmVdIENvbmNlcm5pbmcgdGhlIGZvcm1hdCBpbiB0aGUgcHJvZmlsZSBkcmFmdA0KPiANCj4gSGVs bG8gYWxsLA0KPiANCj4gV2UsIHRoZSBhdXRob3JzIG9mIHRoZSBwcm9maWxlIGRlc2NyaXB0aW9u IGRyYWZ0LCB3b3VsZCBsaWtlIHRvIGFzayBmZWVkYmFjaw0KPiBvbiB0aGUgZHJhZnQgZnJvbSB0 aGUgV0cgYXMgZm9sbG93cy4NCj4gDQo+ICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1ncmVldmVuYm9zY2gtY29yZS1wcm9maWxlLQ0KPiBkZXNjcmlwdGlvbi8NCj4gDQo+ IFRvIHJlY2FwOiB0aGUgZHJhZnQgcHJvdmlkZXMgYSBuZXcgcmVzb3VyY2UgIi53ZWxsLWtub3du L3Byb2ZpbGUiLCB3aGljaA0KPiBnaXZlcyBhIHByb2ZpbGUgZGVzY3JpcHRpb24gb2YgdGhlIHJl c291cmNlLiBDdXJyZW50bHkgdGhpcyBkZXNjcmlwdGlvbiBpbmNsdWRlcw0KPiBzdXBwb3J0ZWQg b3B0aW9ucywgY29udGVudCB0eXBlIGFuZCBibG9jayBzaXplLiBXZSB3b3VsZCBsaWtlIHRvIGFk ZA0KPiBzdXBwb3J0ZWQgbWV0aG9kcyAoR0VUL1BVVC9QT1NUL0RFTEVURSkgdG9vLiBUaGUgcHJv ZmlsZSBpbmZvcm1hdGlvbiBpcw0KPiBlc3BlY2lhbGx5IHVzZWZ1bCBmb3IgYXV0b21hdGVkIGRp c2NvdmVyeSBhbmQgaGFuZGxpbmcgb2YgY29uc3RyYWluZWQNCj4gcmVzb3VyY2VzLiBBIGdlbmVy YWwgcHJveHkvZ2F0ZXdheSB3b3VsZCBiZSBhbiBleGFtcGxlIHRoYXQgYmVuZWZpdHMgZnJvbQ0K PiB0aGlzLg0KPiANCj4gRXNwZWNpYWxseSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uIChhcyBzdWdn ZXN0ZWQgaW4gT3JsYW5kbykgcmVxdWlyZXMNCj4gYXR0ZW50aW9uOg0KPiANCj4gICBDb250aW51 ZSB1c2luZyBhIHNlcGFyYXRlIEpTT04gYmFzZWQgIi53ZWxsLWtub3duL3Byb2ZpbGUiIG9yIG1l cmdlIHdpdGgNCj4gdGhlICIud2VsbC1rbm93bi9jb3JlIiBsaW5rIGZvcm1hdD8NCj4gDQo+IFdl IGRpc2N1c3NlZCB0aGVzZSBvcHRpb25zIGludGVybmFsbHkuIER1cmluZyB0aGF0IGRpc2N1c3Np b24sIHdlIGlkZW50aWZpZWQNCj4gc2V2ZXJhbCBhcmd1bWVudHMgaW4gZmF2b3VyIG9mIGVpdGhl ciBvcHRpb24uIFBsZWFzZSBmaW5kIGJlbG93IGEgbGlzdCBvZg0KPiBhcmd1bWVudHMgd2UgZm91 bmQ6DQo+IA0KPiBJbiBmYXZvdXIgb2YgSlNPTiAiLndlbGwta25vd24vcHJvZmlsZSI6DQo+IC0g QWxsb3cgaGllcmFyY2hpY2FsIHN0cnVjdHVyZSB0aHJvdWdoIG5lc3RlZCBKU09OIGZpZWxkczsN Cj4gLSBBbGxvdyB1c2FnZSBvZiBmaWVsZCB0eXBlcywgc3VjaCBhcyBpbnRlZ2VyLCBmbG9hdCBh bmQgc3RyaW5nOw0KPiAtIEtlZXAgbGluayBmb3JtYXQgbGVhbiBhbmQgc2ltcGxlOw0KPiAtIFNl cnZlciBjYW4gdHJlYXQgdGhlICIud2VsbC1rbm93bi9wcm9maWxlIiBmaWxlIGFzIG9wYXF1ZSBk YXRhOyBpdCBkb2VzIG5vdA0KPiBuZWVkIHRvIGhhbmRsZSBvciBpbXBsZW1lbnQgSlNPTi4NCj4g DQo+IEluIGZhdm91ciBvZiBpbnRlZ3JhdGlvbiB3aXRoICIud2VsbC1rbm93bi9jb3JlIiBsaW5r IGZvcm1hdDoNCj4gLSBObyBuZWVkIHRvIGFkZCBKU09OIHBhcnNlciB0byBjbGllbnQgZm9yIHRo aXMgZnVuY3Rpb25hbGl0eTsNCj4gLSBDb2RpbmcgaW4gbGluayBmb3JtYXQgaXMgbW9yZSBjb21w YWN0IHRoYW4gaW4gSlNPTjsNCj4gLSBMaW5rIGZvcm1hdCBpcyBzbGlnaHRseSBzaW1wbGVyIHRv IHBhcnNlLg0KPiANCj4gV2Ugd2VyZSBhbHNvIHRoaW5raW5nIG9mIHNvbWUga2luZCBvZiBoeWJy aWQgc29sdXRpb24sIHdoZXJlIHdlIGFkZCBhbg0KPiBhdHRyaWJ1dGUgdG8gIi53ZWxsLWtub3du L2NvcmUiIHRoYXQgaW5kaWNhdGVzIGlmICIud2VsbC1rbm93bi9wcm9maWxlIiBpcw0KPiBzdXBw b3J0ZWQuIFRoZSBsYXR0ZXIgd2lsbCB0aGVuIHByb3ZpZGUgdGhlIG1vcmUgZGV0YWlsZWQgcHJv ZmlsZSBpbmZvcm1hdGlvbi4NCj4gDQo+IFdoYXQgYXJlIHlvdXIgdGhvdWdodHM/IFdlIHdvdWxk IGJlIGhhcHB5IHRvIHJlY2VpdmUgeW91ciBmZWVkYmFjayBhbmQNCj4gY29uc2lkZXJhdGlvbnMh DQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IEJlcnQNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From Bert.Greevenbosch@huawei.com Fri Jun 7 02:02:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F2B21F8FEB for ; Fri, 7 Jun 2013 02:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, FRT_POSSIBLE=2.697, 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 Ct0-DX9zq56Q for ; Fri, 7 Jun 2013 02:02:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B8D2221F8B64 for ; Fri, 7 Jun 2013 02:02:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ73307; Fri, 07 Jun 2013 09:02:09 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 10:01:14 +0100 Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 10:02:06 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml462-hub.china.huawei.com ([10.82.67.205]) with mapi id 14.01.0323.007; Fri, 7 Jun 2013 17:01:58 +0800 From: Bert Greevenbosch To: "Dijk, Esko" , "Kovatsch Matthias" , "core@ietf.org" Thread-Topic: Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAAC3HsHAAK2BpkA== Date: Fri, 7 Jun 2013 09:01:57 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D77959A@szxeml558-mbx.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Concerning the format in the profile draft 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, 07 Jun 2013 09:02:24 -0000 SGkgRXNrbywNCg0KPiBJJ20gd29uZGVyaW5nIHdoZW4gc3VjaCBhIHByb2ZpbGUgaXMgbmVlZGVk LCBpLmUuIGluIHdoYXQgdXNlIGNhc2VzIHdvdWxkIGEgY2xpZW50IGhhdmUgdG8gZmV0Y2ggYW4g ZXhwbGljaXQgcHJvZmlsZSBvZiBhbiBlbmRwb2ludD8gKHZlcnN1cyB0aGUgc3RhbmRhcmQgQ29B cCBhcHByb2FjaCBvZiBqdXN0IHRyaWFsLWFuZC1lcnJvciB0byBzZWUgaWYgYW4gb3B0aW9uIGlz IHN1cHBvcnRlZCwgb3Igbm90LiBPciB2ZXJzdXMgdGhlIG91dC1vZi1iYW5kIGFwcHJvYWNoIHdo ZXJlIGtub3dsZWRnZSBvZiBhIHNwZWMgY29tYmluZWQgd2l0aCBMaW5rIEZvcm1hdCByZXNvdXJj ZSB0eXBlcyBnaXZlcyBlbm91Z2ggaW5mb3JtYXRpb24gb24gc3VwcG9ydGVkIG9wdGlvbnMuKQ0K DQpUaGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2suDQoNCkkgd291bGRuJ3QgbGlrZSB0byBiZSBk ZXBlbmRlbnQgb24gdHJpYWwtYW5kLWVycm9yIGluIGFsbCBjYXNlcy4gRm9yIGV4YW1wbGUsIHdo ZW4gdXNpbmcgYmxvY2ssIGl0IGlzIHVzZWZ1bCB0byBrbm93IHRoZSBtYXguIGJsb2Nrc2l6ZSBp biBhZHZhbmNlLiBPdGhlcndpc2UgdGhlIGNsaWVudCB3b3VsZCBmaXJzdCBuZWVkIHRvIHJlY2Vp dmUgYSA0LjEzICJFbnRpdHkgdG8gbGFyZ2UiIGVycm9yLCB0aGVuIGRpYWdub3NlIHRoYXQgaXQg bmVlZHMgdG8gaW5jbHVkZSBhIGJsb2NrIG9wdGlvbiBvciB1c2UgYSBzbWFsbGVyIGJsb2NrIHNp emUgKGF0IHRoaXMgcG9pbnQsIGRvZXMgdGhlIGNsaWVudCBrbm93IHRoZSBzZXJ2ZXIgc3VwcG9y dHMgYmxvY2sgYXQgYWxsPyksIGFuZCB0cnkgYWdhaW4uIE1vcmUgZGV0YWlsZWQga25vd2xlZGdl IGFib3V0IHRoZSBzZXJ2ZXIncyBjYXBhYmlsaXR5IHdvdWxkIHJlZHVjZSB3YXN0aW5nIG1lc3Nh Z2VzLCBhbmQgd291bGQgcmVkdWNlIHRoZSBudW1iZXIgb2YgcG9zc2liaWxlIGRpYWdub3NlcyB3 aGVuIGFuIGVycm9yIGhhcyBiZWVuIHJlY2VpdmVkIHRvby4NCg0KV2l0aCBhbiBleHBlY3RhdGlv biB0aGF0IG1vcmUgYW5kIG1vcmUgb3B0aW9ucyB3aWxsIGJlIGRlZmluZWQgKGFmdGVyIGFsbCwg d2UgcmVzZXJ2ZWQgcXVpdGUgYSBsYXJnZSBvcHRpb24gbnVtYmVyIHNwYWNlKSwgaXQgd2lsbCBi ZWNvbWUgaGFyZGVyIGFuZCBoYXJkZXIgdG8gZmluZCB0aGUgb3B0aW1hbCBzZXR0aW5ncyBqdXN0 IGJ5IHRyeWluZy4gQXMgaW5kaWNhdGVkIGluIHRoZSBleGFtcGxlIGFib3ZlLCB0aGUgbGltaXRl ZCBudW1iZXIgb2YgcG9zc2libGUgZXJyb3JzIHdvdWxkIGFsc28gY29tcGxpY2F0ZSB0aGUgZGlh Z25vc3RpYyBwcm9jZXNzIHdoZW4gbW9yZSBvcHRpb25zIGJlY29tZSBzcGVjaWZpZWQuDQoNCkJl c3QgcmVnYXJkcywNCkJlcnQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog RGlqaywgRXNrbyBbbWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbV0gDQpTZW50OiAyMDEzxOo2 1MI2yNUgMTk6MTkNClRvOiBLb3ZhdHNjaCBNYXR0aGlhczsgQmVydCBHcmVldmVuYm9zY2g7IGNv cmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBDb25jZXJuaW5nIHRoZSBmb3JtYXQgaW4gdGhlIHBy b2ZpbGUgZHJhZnQNCg0KPiAuLi5wcm9maWxlIHNob3VsZCBjb25jZW50cmF0ZSBvbiB0aGUgZW5k cG9pbnQgaW4gZ2VuZXJhbCBpbnN0ZWFkIG9mIGluZGl2aWR1YWwgcmVzb3VyY2VzLi4uDQoNCkFn cmVlIQ0KDQpJJ20gd29uZGVyaW5nIHdoZW4gc3VjaCBhIHByb2ZpbGUgaXMgbmVlZGVkLCBpLmUu IGluIHdoYXQgdXNlIGNhc2VzIHdvdWxkIGEgY2xpZW50IGhhdmUgdG8gZmV0Y2ggYW4gZXhwbGlj aXQgcHJvZmlsZSBvZiBhbiBlbmRwb2ludD8gKHZlcnN1cyB0aGUgc3RhbmRhcmQgQ29BcCBhcHBy b2FjaCBvZiBqdXN0IHRyaWFsLWFuZC1lcnJvciB0byBzZWUgaWYgYW4gb3B0aW9uIGlzIHN1cHBv cnRlZCwgb3Igbm90LiBPciB2ZXJzdXMgdGhlIG91dC1vZi1iYW5kIGFwcHJvYWNoIHdoZXJlIGtu b3dsZWRnZSBvZiBhIHNwZWMgY29tYmluZWQgd2l0aCBMaW5rIEZvcm1hdCByZXNvdXJjZSB0eXBl cyBnaXZlcyBlbm91Z2ggaW5mb3JtYXRpb24gb24gc3VwcG9ydGVkIG9wdGlvbnMuKQ0KDQpFc2tv DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLb3ZhdHNjaCBN YXR0aGlhcw0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDA1LCAyMDEzIDE1OjMxDQpUbzogQmVydCBH cmVldmVuYm9zY2g7IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gQ29uY2Vybmlu ZyB0aGUgZm9ybWF0IGluIHRoZSBwcm9maWxlIGRyYWZ0DQoNCkRlYXIgQmVydA0KDQpNeSBtYWlu IGNvbmNlcm4gYWJvdXQgdGhlIHByb2ZpbGUgZHJhZnQgaXMgaXRzIG92ZXJsYXAgd2l0aCAvLndl bGwta25vd24vY29yZS4gSSB0aGluayB5b3VyIHByb2ZpbGUgc2hvdWxkIGNvbmNlbnRyYXRlIG9u IHRoZSBlbmRwb2ludCBpbiBnZW5lcmFsIGluc3RlYWQgb2YgaW5kaXZpZHVhbCByZXNvdXJjZXMu IEZyb20gbXkgcHJhY3RpY2FsIGV4cGVyaWVuY2UsIGluZm9ybWF0aW9uIGFib3V0IHN1cHBvcnRl ZCBvcHRpb25zIGFuZCBidWZmZXIgc2l6ZXMgaXMgaW5kZXBlbmRlbnQgZnJvbSB0aGUgcmVzb3Vy Y2VzIGFueXdheS4NCg0KQ3VycmVudGx5LCB0aGVyZSBpcyBubyB3YXkgdG8gbGVhcm4gYWJvdXQg dGhlIGFwcGxpY2F0aW9uIHByb2ZpbGUgKGUuZy4sIE9NQSBMaWdodHdlaWdodCkgYW4gZW5kcG9p bnQgaW1wbGVtZW50cy4gQ3VycmVudGx5LCBhIGNsaWVudCBoYXMgdG8gZ3Vlc3MgdGhpcyBmcm9t IHRoZSByZXNvdXJjZSBzdHJ1Y3R1cmUgb3IgcmVxdWlyZXMgc29tZSBvdXQtb2YtYmFuZCBrbm93 bGVkZ2UuIFRoZXJlIGFyZSBvdGhlciBiaW5kaW5ncyBjb21pbmcgdXAsIGUuZy4sIEJBQ25ldCwg c28gaXQgd291bGQgYmUgZ29vZCB0byBwcm92aWRlIHRoaXMgaW5mb3JtYXRpb24gaW4gc3VjaCBh biBlbmRwb2ludCBwcm9maWxlLg0KDQpDaWFvDQpNYXR0aGlhcw0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgQmVydCBHcmVldmVuYm9zY2gNCj4g U2VudDogRGllbnN0YWcsIDQuIEp1bmkgMjAxMyAwMjo0OQ0KPiBUbzogY29yZUBpZXRmLm9yZw0K PiBTdWJqZWN0OiBbY29yZV0gQ29uY2VybmluZyB0aGUgZm9ybWF0IGluIHRoZSBwcm9maWxlIGRy YWZ0DQo+DQo+IEhlbGxvIGFsbCwNCj4NCj4gV2UsIHRoZSBhdXRob3JzIG9mIHRoZSBwcm9maWxl IGRlc2NyaXB0aW9uIGRyYWZ0LCB3b3VsZCBsaWtlIHRvIGFzaw0KPiBmZWVkYmFjayBvbiB0aGUg ZHJhZnQgZnJvbSB0aGUgV0cgYXMgZm9sbG93cy4NCj4NCj4gICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWdyZWV2ZW5ib3NjaC1jb3JlLXByb2ZpbGUtDQo+IGRlc2NyaXB0 aW9uLw0KPg0KPiBUbyByZWNhcDogdGhlIGRyYWZ0IHByb3ZpZGVzIGEgbmV3IHJlc291cmNlICIu d2VsbC1rbm93bi9wcm9maWxlIiwNCj4gd2hpY2ggZ2l2ZXMgYSBwcm9maWxlIGRlc2NyaXB0aW9u IG9mIHRoZSByZXNvdXJjZS4gQ3VycmVudGx5IHRoaXMNCj4gZGVzY3JpcHRpb24gaW5jbHVkZXMg c3VwcG9ydGVkIG9wdGlvbnMsIGNvbnRlbnQgdHlwZSBhbmQgYmxvY2sgc2l6ZS4NCj4gV2Ugd291 bGQgbGlrZSB0byBhZGQgc3VwcG9ydGVkIG1ldGhvZHMgKEdFVC9QVVQvUE9TVC9ERUxFVEUpIHRv by4gVGhlDQo+IHByb2ZpbGUgaW5mb3JtYXRpb24gaXMgZXNwZWNpYWxseSB1c2VmdWwgZm9yIGF1 dG9tYXRlZCBkaXNjb3ZlcnkgYW5kDQo+IGhhbmRsaW5nIG9mIGNvbnN0cmFpbmVkIHJlc291cmNl cy4gQSBnZW5lcmFsIHByb3h5L2dhdGV3YXkgd291bGQgYmUgYW4NCj4gZXhhbXBsZSB0aGF0IGJl bmVmaXRzIGZyb20gdGhpcy4NCj4NCj4gRXNwZWNpYWxseSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9u IChhcyBzdWdnZXN0ZWQgaW4gT3JsYW5kbykgcmVxdWlyZXMNCj4gYXR0ZW50aW9uOg0KPg0KPiAg IENvbnRpbnVlIHVzaW5nIGEgc2VwYXJhdGUgSlNPTiBiYXNlZCAiLndlbGwta25vd24vcHJvZmls ZSIgb3IgbWVyZ2UNCj4gd2l0aCB0aGUgIi53ZWxsLWtub3duL2NvcmUiIGxpbmsgZm9ybWF0Pw0K Pg0KPiBXZSBkaXNjdXNzZWQgdGhlc2Ugb3B0aW9ucyBpbnRlcm5hbGx5LiBEdXJpbmcgdGhhdCBk aXNjdXNzaW9uLCB3ZQ0KPiBpZGVudGlmaWVkIHNldmVyYWwgYXJndW1lbnRzIGluIGZhdm91ciBv ZiBlaXRoZXIgb3B0aW9uLiBQbGVhc2UgZmluZA0KPiBiZWxvdyBhIGxpc3Qgb2YgYXJndW1lbnRz IHdlIGZvdW5kOg0KPg0KPiBJbiBmYXZvdXIgb2YgSlNPTiAiLndlbGwta25vd24vcHJvZmlsZSI6 DQo+IC0gQWxsb3cgaGllcmFyY2hpY2FsIHN0cnVjdHVyZSB0aHJvdWdoIG5lc3RlZCBKU09OIGZp ZWxkczsNCj4gLSBBbGxvdyB1c2FnZSBvZiBmaWVsZCB0eXBlcywgc3VjaCBhcyBpbnRlZ2VyLCBm bG9hdCBhbmQgc3RyaW5nOw0KPiAtIEtlZXAgbGluayBmb3JtYXQgbGVhbiBhbmQgc2ltcGxlOw0K PiAtIFNlcnZlciBjYW4gdHJlYXQgdGhlICIud2VsbC1rbm93bi9wcm9maWxlIiBmaWxlIGFzIG9w YXF1ZSBkYXRhOyBpdA0KPiBkb2VzIG5vdCBuZWVkIHRvIGhhbmRsZSBvciBpbXBsZW1lbnQgSlNP Ti4NCj4NCj4gSW4gZmF2b3VyIG9mIGludGVncmF0aW9uIHdpdGggIi53ZWxsLWtub3duL2NvcmUi IGxpbmsgZm9ybWF0Og0KPiAtIE5vIG5lZWQgdG8gYWRkIEpTT04gcGFyc2VyIHRvIGNsaWVudCBm b3IgdGhpcyBmdW5jdGlvbmFsaXR5Ow0KPiAtIENvZGluZyBpbiBsaW5rIGZvcm1hdCBpcyBtb3Jl IGNvbXBhY3QgdGhhbiBpbiBKU09OOw0KPiAtIExpbmsgZm9ybWF0IGlzIHNsaWdodGx5IHNpbXBs ZXIgdG8gcGFyc2UuDQo+DQo+IFdlIHdlcmUgYWxzbyB0aGlua2luZyBvZiBzb21lIGtpbmQgb2Yg aHlicmlkIHNvbHV0aW9uLCB3aGVyZSB3ZSBhZGQgYW4NCj4gYXR0cmlidXRlIHRvICIud2VsbC1r bm93bi9jb3JlIiB0aGF0IGluZGljYXRlcyBpZg0KPiAiLndlbGwta25vd24vcHJvZmlsZSIgaXMg c3VwcG9ydGVkLiBUaGUgbGF0dGVyIHdpbGwgdGhlbiBwcm92aWRlIHRoZSBtb3JlIGRldGFpbGVk IHByb2ZpbGUgaW5mb3JtYXRpb24uDQo+DQo+IFdoYXQgYXJlIHlvdXIgdGhvdWdodHM/IFdlIHdv dWxkIGJlIGhhcHB5IHRvIHJlY2VpdmUgeW91ciBmZWVkYmFjayBhbmQNCj4gY29uc2lkZXJhdGlv bnMhDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gQmVydA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGlu ZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxl Z2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9y d2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBp cyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0 dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdl Lg0KDQo= From Bert.Greevenbosch@huawei.com Fri Jun 7 02:04:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2AE21F8FCB for ; Fri, 7 Jun 2013 02:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.792, 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 yhsM+89s7iIW for ; Fri, 7 Jun 2013 02:04:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 651FD21F8F6E for ; Fri, 7 Jun 2013 02:04:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASE72397; Fri, 07 Jun 2013 09:04:25 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 10:03:28 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 17:04:24 +0800 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Fri, 7 Jun 2013 17:04:18 +0800 From: Bert Greevenbosch To: "Kovatsch Matthias" , "Dijk, Esko" , "core@ietf.org" Thread-Topic: Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAAC3HsHAABJWxUAAoaqig Date: Fri, 7 Jun 2013 09:04:17 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D7795A7@szxeml558-mbx.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514F1F6F0@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514F1F6F0@MBX10.d.ethz.ch> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Concerning the format in the profile draft 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, 07 Jun 2013 09:04:32 -0000 SGkgTWF0dGhpYXMsDQoNCkluZGVlZCBtYXNoLXVwcyBhbmQgYWdncmVnYXRpbmcgcHJveGllcyBh cmUgc29tZSBvZiB0aGUgZW50aXRpZXMgdGhhdCBjYW4gYmVuZWZpdCBmcm9tIHRoaXMuDQoNCkFs dGhvdWdoIGNsb3NlZCBkZXBsb3ltZW50cyBhcmUgY2VydGFpbmx5IGltcG9ydGFudCwgdGhlIElu dGVybmV0IG9mIFRoaW5ncyBpcyBhbHNvIHN1cHBvc2VkIHRvIHByb3ZpZGUgZm9yIG9wZW4gYXJj aGl0ZWN0dXJlcy4gQWZ0ZXIgYWxsLCB0aGlzIGlzIHdoZXJlIHN0YW5kYXJkaXNhdGlvbiBiZW5l Zml0cyB1cyBtb3N0LiBTbyBJIGFncmVlIHRoYXQgdGhlIHByb2ZpbGUgZHJhZnQgaXMgbW9zdCB1 c2VmdWwgZm9yIGRlcGxveW1lbnRzIHdoZXJlIGVudGl0aWVzIG5lZWQgdG8gZ2V0IHRvIGtub3cg ZWFjaCBvdGhlciBiZWZvcmUgdGhleSBjYW4gcGVyZm9ybSBvcHRpbWFsIGNvbW11bmljYXRpb24u DQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogS292YXRzY2ggTWF0dGhpYXMgW21haWx0bzprb3ZhdHNjaEBpbmYuZXRoei5jaF0gDQpT ZW50OiAyMDEzxOo21MI2yNUgMjE6MjgNClRvOiBEaWprLCBFc2tvOyBCZXJ0IEdyZWV2ZW5ib3Nj aDsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IENvbmNlcm5pbmcgdGhlIGZvcm1hdCBpbiB0 aGUgcHJvZmlsZSBkcmFmdA0KDQo+IEknbSB3b25kZXJpbmcgd2hlbiBzdWNoIGEgcHJvZmlsZSBp cyBuZWVkZWQsIGkuZS4gaW4gd2hhdCB1c2UgY2FzZXMgd291bGQgYQ0KPiBjbGllbnQgaGF2ZSB0 byBmZXRjaCBhbiBleHBsaWNpdCBwcm9maWxlIG9mIGFuIGVuZHBvaW50PyAodmVyc3VzIHRoZSBz dGFuZGFyZA0KPiBDb0FwIGFwcHJvYWNoIG9mIGp1c3QgdHJpYWwtYW5kLWVycm9yIHRvIHNlZSBp ZiBhbiBvcHRpb24gaXMgc3VwcG9ydGVkLCBvciBub3QuDQo+IE9yIHZlcnN1cyB0aGUgb3V0LW9m LWJhbmQgYXBwcm9hY2ggd2hlcmUga25vd2xlZGdlIG9mIGEgc3BlYyBjb21iaW5lZA0KPiB3aXRo IExpbmsgRm9ybWF0IHJlc291cmNlIHR5cGVzIGdpdmVzIGVub3VnaCBpbmZvcm1hdGlvbiBvbiBz dXBwb3J0ZWQNCj4gb3B0aW9ucy4pDQoNCllvdSB3aWxsIG5vdCBuZWVkIGl0IGluIGNsb3NlZCBk ZXBsb3ltZW50cyB3aXRob3V0IGhldGVyb2dlbmVpdHkgKGp1c3QgbGlrZSB3aGF0IHdlIGhhZCBi ZWZvcmUpLg0KSSBiZWNvbWVzIGludGVyZXN0aW5nLCBpbiBteSBvcGluaW9uLCB3aGVuIHlvdSBi dWlsZCBhZCBob2MgYXBwbGljYXRpb25zIGxpa2UgV2ViIG1hc2h1cHMuIFRoZXJlIHRoZSBwcm9m aWxlIG1pZ2h0IGJlIHVua25vd24gYSBwcmlvcmksIGJ1dCBuZWVkZWQgZm9yIHN1Y2Nlc3NmdWwg aW50ZXJhY3Rpb24gKGUuZy4sIGRlY2lwaGVyaW5nIHRoZSBPTUEgT2JqZWN0IElEcykuDQoNCkNp YW8NCk1hdHRoaWFzDQoNCg== From Bert.Greevenbosch@huawei.com Fri Jun 7 02:05:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CBC21F8F6E for ; Fri, 7 Jun 2013 02:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.634, 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 V+JiCqiYd7TS for ; Fri, 7 Jun 2013 02:05:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDF121F91BF for ; Fri, 7 Jun 2013 02:05:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ73668; Fri, 07 Jun 2013 09:05:52 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 10:04:59 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 17:05:51 +0800 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 7 Jun 2013 17:05:38 +0800 From: Bert Greevenbosch To: "Kovatsch Matthias" , Zach Shelby Thread-Topic: [core] Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAACfL/IAAD/XAAAAh2oAw Date: Fri, 7 Jun 2013 09:05:37 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D7795C1@szxeml558-mbx.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <25DEB11B-7C44-4E69-A912-51BE7D3ECFD9@sensinode.com> <55877B3AFB359744BA0F2140E36F52B514F250D1@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514F250D1@MBX10.d.ethz.ch> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] Concerning the format in the profile draft 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, 07 Jun 2013 09:05:59 -0000 SGkgTWF0dGhpYXMgYW5kIFphY2gsDQoNCkkgYWdyZWUgdGhhdCB0aGUgcmVzb3VyY2UgdHlwZSBk b2VzIGNvbnZleSBpbnRlcmVzdGluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcmVzb3VyY2UuIEkg dGhvdWdodCBpdCB3YXMgbW9yZSByZWxhdGVkIHRvIHRoZSBmb3JtYXQgb2YgbWVzc2FnZXMgaW4g dGhlIHBheWxvYWQsIHRoYW4gdG8gdGhlIENvQVAgcHJvdG9jb2wgaXRzZWxmIHRob3VnaC4gDQoN CkRvZXMgdGhlIHJlc291cmNlIHR5cGUgc3BlY2lmeSBhbGwgdGhlIENvQVAgY2FwYWJpbGl0aWVz IG9mIHRoZSByZXNvdXJjZT8gSW4gb3RoZXIgd29yZHMsIHdoZW4gYSByZXNvdXJjZSB0eXBlIGlz IGRlZmluZWQsIGlzIGFsbCBhc3NvY2lhdGVkIHByb2ZpbGUgaW5mbyBkZWZpbmVkIHdpdGggaXQ/ IFRoYXQgd291bGQgbWVhbiB0aGF0IGEgcmVzb3VyY2UgdHlwZSBkZWZpbmVzIGEgZml4ZWQgc2V0 IG9mIG9wdGlvbnMgYW5kIGEgZml4ZWQgYmxvY2sgc2l6ZS4gSG93IHRvIGRldmlhdGUgZnJvbSB0 aGlzLCBhbmQgaG93IHRvIHNpZ25hbCB0aGF0Pw0KDQpCZXN0IHJlZ2FyZHMsDQpCZXJ0DQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS292YXRzY2ggTWF0dGhpYXMgW21h aWx0bzprb3ZhdHNjaEBpbmYuZXRoei5jaF0gDQpTZW50OiAyMDEzxOo21MI3yNUgNzo1NQ0KVG86 IFphY2ggU2hlbGJ5DQpDYzogQmVydCBHcmVldmVuYm9zY2g7IGNvcmVAaWV0Zi5vcmcNClN1Ympl Y3Q6IEFXOiBbY29yZV0gQ29uY2VybmluZyB0aGUgZm9ybWF0IGluIHRoZSBwcm9maWxlIGRyYWZ0 DQoNCj4gV2h5IHdvdWxkIHRoaXMgYmUgbWl4ZWQgd2l0aCBpbmZvcm1hdGlvbiBhYm91dCB0aGUg Q29BUCBpbXBsZW1lbnRhdGlvbj8gV2UNCj4gYWxyZWFkeSBoYXZlIGEgbWVhbnMgZm9yIGluZGlj YXRpbmcgd2hhdCBzZW1hbnRpY3MgYSByZXNvdXJjZSBoYXMgdXNpbmcgdGhlDQo+IFJlc291cmNl IFR5cGUgbGluayBhdHRyaWJ1dGUuIEluIHRoZSBjYXNlIG9mIE9NQSBMaWdodHdlaWdodCwgdGhl IHNwZWNpZmljYXRpb24NCj4gYWN0dWFsbHkgc3BlY2lmaWVzIHRoZSBSZXNvdXJjZSBUeXBlICJv bWEubHdtMm0iIHdoaWNoIGluZGljYXRlcyB0aGUgcm9vdA0KPiByZXNvdXJjZSBvZiB0aGUgT2Jq ZWN0IHRyZWU6DQo+IA0KPiA8L29tYT47cnQ9b21hLmx3bTJtLDwvb21hLzIvMD4sPC9vbWEvMy8w Pg0KPiANCj4gVGhlIGZpcnN0IGxpbmsgaXMgdGhlIHJvb3Qgb2YgdGhlIE9NQSB0cmVlLCBhbmQg dGhlIHNlY29uZCBhbmQgdGhpcmQgbGlua3MgYXJlDQo+IE9iamVjdCBJbnN0YW5jZXMuDQoNCkFo LCBva2F5LiBBIHdoaWxlIGFnbywgT01BIE9iamVjdHMgd2VyZSBhdCB0aGUgcm9vdCwgSSB0aGlu ay4gVGhpcyBsb29rcyBnb29kIG5vdy4NCg0KPiBTaW1pbGFybHksIGlmIG90aGVyIFJFU1QgaW50 ZXJmYWNlcyB3ZXJlIGhvc3RlZCBvbiB0aGF0IGVuZHBvaW50LCB0aGV5IHNob3VsZA0KPiBwcm9i YWJseSBpbmRpY2F0ZSB0aGVtc2VsdmVzIHdpdGggYSBSZXNvdXJjZSBUeXBlLiBTbyBJIHRoaW5r IHdlIGhhdmUgdGhpcw0KPiBjb3ZlcmVkIHdpdGggb3VyIGV4aXN0aW5nIG1lY2hhbmlzbXMuDQoN ClNvIHRoZSByZW1haW5pbmcgaW5mb3JtYXRpb24gZm9yIC8ud2VsbC1rbm93bi9wcm9maWxlIHdv dWxkIGJlIE9wdGlvbnMgYW5kIHNpemVzLiBOb25ldGhlbGVzcywgdGhpcyBpcyBjb3ZlcmVkIGJ5 IHRoZSBjb3JyZXNwb25kaW5nIGVycm9yIG1lc3NhZ2VzIGFuZCBibG9jayBzaXplIG5lZ290aWF0 aW9uLi4uDQoNCkNpYW8NCk1hdHRoaWFzDQoNCg== From Bert.Greevenbosch@huawei.com Fri Jun 7 18:00:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC35621F99F8 for ; Fri, 7 Jun 2013 18:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.528, 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 btGY2SNHUvkt for ; Fri, 7 Jun 2013 18:00:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9921F99E9 for ; Fri, 7 Jun 2013 18:00:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR25486; Sat, 08 Jun 2013 01:00:11 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 8 Jun 2013 01:59:06 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 8 Jun 2013 09:00:04 +0800 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.007; Sat, 8 Jun 2013 09:00:00 +0800 From: Bert Greevenbosch To: Zach Shelby , Rick Bullotta Thread-Topic: [core] Concerning the format in the profile draft Thread-Index: Ac5gvUUeUeDYicgDRWeCUYZAtSNMcwBMfQiAAC3HsHAAAU65YP//x64A//5iSoA= Date: Sat, 8 Jun 2013 00:59:59 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D779AFA@szxeml558-mbx.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <3158efb9882c43acbba434e93e31cfff@BLUPR06MB001.namprd06.prod.outlook.com> <8E442EC5-D6E4-4D9B-A25E-5960D3929CB5@sensinode.com> In-Reply-To: <8E442EC5-D6E4-4D9B-A25E-5960D3929CB5@sensinode.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] Concerning the format in the profile draft 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, 08 Jun 2013 01:00:26 -0000 SGkgWmFjaCBhbmQgUmljaywNCg0KSW5kZWVkIHRoZSBwcm9maWxlIGRyYWZ0IGN1cnJlbnRseSBq dXN0IHNpZ25hbHMgc3VwcG9ydGVkIENvQVAgb3B0aW9ucywgY29udGVudCBmb3JtYXQgYW5kIGJs b2Nrc2l6ZS4gV2UgYXJlIHN0cm9uZ2x5IGNvbnNpZGVyaW5nIHJlbW92aW5nIHRoZSBjb250ZW50 IGZvcm1hdCBiZWNhdXNlIGl0IGlzIGFscmVhZHkgc2lnbmFsbGVkIGluIHRoZSBsaW5rIGZvcm1h dC4gV2Ugd291bGQgbGlrZSB0byBhZGQgc3VwcG9ydGVkIG1ldGhvZHMgR0VUL1BVVC9QT1NUL0RF TEVURS4NCg0KSSB1c2UgdGhlIHRlcm0gInByb2ZpbGUgZGVzY3JpcHRpb24iIGJlY2F1c2UgaXQg c2lnbmFscyB0aGUgc3Vic2V0IG9mIGFsbCB3aGF0IENvQVAgY2FwYWJpbGl0aWVzIHRoZSBlbnRp dHkgc3VwcG9ydHMuIEJ1dCBJIGRvbid0IHRoaW5rIHRoZSBuYW1pbmcgaXMgY3JpdGljYWwuIFdl IGNvdWxkIGFsc28gY2FsbCBpdCAiQ29BUCBjYXBhYmlsaXRpZXMgZGVzY3JpcHRpb24iIG9yIHNv bWV0aGluZy4NCg0KVGhlIHByb2ZpbGUgZHJhZnQgaXMgaW4gdGhlIHByb2Nlc3Mgb2YgZGV2ZWxv cG1lbnQsIHNvIHdlIGNhbiBjZXJ0YWlubHkgYWRkIG1vcmUgaW5mb3JtYXRpb24gYXMgcmVxdWly ZWQuDQoNCkFzIFphY2ggbWVudGlvbnMsIHRoZSBsaW5rIGZvcm1hdCBhbmQgcmVzb3VyY2UgZGly ZWN0b3J5IGFscmVhZHkgZ2l2ZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZXNvdXJjZXMu IEJ1dCBpbiBteSB2aWV3LCB0aGlzIGluZm9ybWF0aW9uIGN1cnJlbnRseSBpcyB0b28gbGltaXRl ZC4gSG93ZXZlciwgaXQgaXMgYSByZWFzb24gdGhhdCBJIHdyb3RlIGJlbG93IHRoZSBkaXNjdXNz aW9uIHBvaW50cyBhYm91dCB3aGV0aGVyIG9yIG5vdCB0byBtZXJnZSAiLndlbGwta25vd24vY29y ZSIgYW5kICIud2VsbC1rbm93bi9wcm9maWxlIi4gV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhp cz8NCg0KSSB0aGluayB0aGUgcHJvZmlsZSBpbmZvcm1hdGlvbiBpcyB1c2VmdWwgaW4gc2V2ZXJh bCBkZXBsb3ltZW50cy4gRW50aXRpZXMgdGhhdCBiZW5lZml0IGZyb20gaXQgYXJlIGUuZy4gZ2Vu ZXJhbCBwcm94aWVzL2dhdGV3YXlzIHRoYXQgdGFsayB0byBtdWx0aXBsZSBlbmRwb2ludHMsIGNs aWVudHMgdGhhdCBjYW4gZmluZCBvdXQgYWJvdXQgd2hldGhlciBvciBub3QgcHJveHktdW5zYWZl IG9wdGlvbnMgYXJlIHN1cHBvcnRlZCBieSB0aGUgcHJveHksIG9yIHdoaWNoIGNhcGFiaWxpdGll cyBvZiBhIHNlcnZlciB0aGV5IGNhbiBleHBsb2l0LCBhbmQgc2VydmVycyByZWNlaXZpbmcgbGVz cyBtZXNzYWdlcyB0aGF0IHRoZXkgY2Fubm90IGhhbmRsZS4gRmluYWxseSwgdGhlIGluZm9ybWF0 aW9uIGNhbiBiZSB1c2VkIGZvciBkZWJ1Z2dpbmcvZGlhZ25vc3RpYyBwdXJwb3Nlcy4NCg0KVGhh bmtzIGEgbG90IGZvciB5b3VyIGZlZWRiYWNrIGFuZCBjb25zaWRlcmF0aW9ucyEgV2hhdCBpcyB5 b3VyIG9waW5pb24/DQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmFjaCBTaGVsYnkNClNlbnQ6IDIwMTPE6jbUwjfI 1SAwOjI2DQpUbzogUmljayBCdWxsb3R0YQ0KQ2M6IGNvcmVAaWV0Zi5vcmcgV0cNClN1YmplY3Q6 IFJlOiBbY29yZV0gQ29uY2VybmluZyB0aGUgZm9ybWF0IGluIHRoZSBwcm9maWxlIGRyYWZ0DQoN CkhpIFJpY2ssDQoNCk9uIEp1biA2LCAyMDEzLCBhdCAxOjUxIFBNLCBSaWNrIEJ1bGxvdHRhIDxy aWNrLmJ1bGxvdHRhQHRoaW5nd29yeC5jb20+IHdyb3RlOg0KDQo+IElmIEkgdW5kZXJzdGFuZCB0 aGUgc2l0dWF0aW9uIGNvcnJlY3RseSwgdGhlIGFiaWxpdHkgdG8gYWNjZXNzIGEgZGV2aWNlJ3Mg cHJvZmlsZSBpbiB0aGlzIHdheSBpcyBleHRyZW1lbHkgdXNlZnVsIGluIHNpdHVhdGlvbnMgd2hl biBhIGRldmVsb3BtZW50IGVudmlyb25tZW50L3BsYXRmb3JtIChlLmcuIG91ciBUaGluZ1dvcngg cGxhdGZvcm0pIHdhbnRzIHRvIGFjY2VzcyB0aGUgbWV0YWRhdGEgZm9yIGEgZGV2aWNlIGV2ZW4g d2hlbiB0aGUgZGV2aWNlIGl0c2VsZiBpcyBvZmZsaW5lLiAgSXQgcHJvdmlkZXMgYSBkdXJhYmxl IGNhdGFsb2cgZm9yIHRoaXMgbWV0YWRhdGEgaW5mb3JtYXRpb24sIGVuYWJsaW5nIGRldmVsb3Bt ZW50IGFjdGl2aXRpZXMgdG8gb2NjdXIgaW5kZXBlbmRlbnQgb2YgY29ubmVjdGlvbiBzdGF0dXMu ICANCg0KTm8sIHRoZSBkcmFmdCB0aGF0IEJlcnQgZXQgYWwuIHdlcmUgZGlzY3Vzc2luZyBoZXJl IGlzIGFib3V0IGRpc2NvdmVyaW5nIHRoZSBDb0FQIHByb3RvY29sIGNhcGFiaWxpdGllcyB0aGF0 IGFuIGVuZHBvaW50IHN1cHBvcnRzIHVzaW5nIGEgc3BlY2lhbCBVUkkgdGhhdCBjYW4gYmUgcmVx dWVzdGVkLiBGb3IgZXhhbXBsZSBkb2VzIGFuIGVuZHBvaW50IHN1cHBvcnQgYSBzcGVjaWFsIENv QVAgb3B0aW9uLiAiUHJvZmlsZSIgaXMgcHJvYmFibHkgYSByZWFsbHkgcG9vciB0ZXJtIHRvIGRl c2NyaWJlIHRoYXQgKGNvbmZ1c2VzIG1lIGF0IGxlYXN0KS4gDQoNCldlIGRvIGhhdmUgYSBtZWNo YW5pc20gYWxyZWFkeSB0byBkbyB3aGF0IHlvdSBkZXNjcmliZS4gVGhhdCBpcyB0aGUgQ29SRSBM aW5rIEZvcm1hdCAoUkZDNjY5MCkgZm9ybWF0IHRoYXQgd2UgdXNlIHRvIGRlc2NyaWJlIHRoZSBy ZXNvdXJjZXMgYW5kIHRoZWlyIG1ldGEtZGF0YSB0aGF0IGFuIGVuZHBvaW50IGhhcyBhdmFpbGFi bGUuIEJ5IGRlZmF1bHQgdGhlc2UgbGlua3MgY2FuIGJlIGRpc2NvdmVyZWQgZnJvbSBhbnkgZW5k cG9pbnQgYnkgZG9pbmcgYSBHRVQgcmVxdWVzdCB0byAvLndlbGwta25vd24vY29yZS4gV2UgYWxz byBoYXZlIGEgbWVjaGFuaXNtIHRvIHBvc3QgdGhlc2UgbGlua3MgdG8gYSBjZW50cmFsIFJlc291 cmNlIERpcmVjdG9yeSB3aGVyZSB0aGV5IGFyZSBhdmFpbGFibGUgZXZlbiB3aGVuIHRoZSBlbmRw b2ludCBpcyBvZmYtbGluZToNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeQ0KDQo+IEFkZGl0aW9uYWxseSwgd2l0aCBzb21lIGZ1 cnRoZXIgZGVzaWduIHdvcmssIHRoaXMgcmVzb3VyY2UgcmVwb3NpdG9yeSBjYW4gYmVjb21lIGFu IGV4Y2VsbGVudCBtZWNoYW5pc20gZm9yIGFjY2Vzc2luZyBhbmQgbWFuYWdpbmcgdGhlIGRlZmlu aXRpb24ocykgb2YgImdlbmVyaWMgcHJvZmlsZXMiIChlLmcuIGFuIGVuZXJneSBtZXRlciwgYSB0 cmFmZmljIGxpZ2h0LCBhIHJlZnJpZ2VyYXRlZCBzaGlwcGluZyBjb250YWluZXIpIGFuZCB0aGVp ciBhc3NvY2lhdGlvbiB0byBzcGVjaWZpYyBkZXZpY2VzLg0KDQpFeGFjdGx5ISBUaGUgbmV3IE9N QSBMaWdodHdlaWdodCBzdGFuZGFyZCBkZWZpbmVzIGEgY29tcGxldGUgT2JqZWN0IG1vZGVsIGFu ZCBwcm92aWRlcyBhbiBPYmplY3QgcmVnaXN0cnksIHNvIHdoZW4geW91IHNlZSBzdWNoIGEgbGlu aywgeW91IGtub3cgZXhhY3RseSB3aGF0IHRoZSByZXNvdXJjZSBpcyBhYm91dCAoTGlnaHQgQ29u dHJvbCBPYmplY3QsIExvY2F0aW9uIE9iamVjdCwgRGV2aWNlIE9iamVjdCBldGMuKS4gDQoNClJl Z2FyZHMsDQpaYWNoDQoNCi0tIA0KWmFjaCBTaGVsYnksIENoaWVmIE5lcmQsIFNlbnNpbm9kZSBM dGQuDQpodHRwOi8vd3d3LnNlbnNpbm9kZS5jb20gQFNlbnNpbm9kZUlvVA0KTW9iaWxlOiArMzU4 IDQwIDc3OTYyOTcNClR3aXR0ZXI6IEB6YWNoX3NoZWxieQ0KTGlua2VkSW46IGh0dHA6Ly9maS5s aW5rZWRpbi5jb20vaW4vemFjaHNoZWxieQ0KNkxvV1BBTiBCb29rOiBodHRwOi8vNmxvd3Bhbi5u ZXQNCg0KDQoNCg0K From jeroen.hoebeke@intec.ugent.be Sun Jun 9 12:28:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AC021F8E93 for ; Sun, 9 Jun 2013 12:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5NemlTRR0DL0 for ; Sun, 9 Jun 2013 12:28:04 -0700 (PDT) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2136D21F8A68 for ; Sun, 9 Jun 2013 12:28:03 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 56555C288; Sun, 9 Jun 2013 21:28:02 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id tJCEP0dsmBSa; Sun, 9 Jun 2013 21:28:01 +0200 (CEST) Received: from [192.168.123.13] (78-21-5-56.access.telenet.be [78.21.5.56]) (Authenticated sender: jjhoebek) by smtp3.ugent.be (Postfix) with ESMTPSA id D5ED3C264; Sun, 9 Jun 2013 21:28:00 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=GB2312 From: Jeroen Hoebeke In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D779AFA@szxeml558-mbx.china.huawei.com> Date: Sun, 9 Jun 2013 21:28:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <557DE811-6808-4DE2-8B39-A586CB5E6922@intec.ugent.be> References: <46A1DF3F04371240B504290A071B4DB63D7759F6@szxeml558-mbx.china.huawei.com> <55877B3AFB359744BA0F2140E36F52B514F19DC8@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C5828C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <3158efb9882c43acbba434e93e31cfff@BLUPR06MB001.namprd06.prod.outlook.com> <8E442EC5-D6E4-4D9B-A25E-5960D3929CB5@sensinode.com> <46A1DF3F04371240B504290A071B4DB63D779AFA@szxeml558-mbx.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1503) X-Miltered: at jchkm3 with ID 51B4D740.001 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51B4D740.001 from 78-21-5-56.access.telenet.be/78-21-5-56.access.telenet.be/78.21.5.56/[192.168.123.13]/ X-j-chkmail-Score: MSGID : 51B4D740.001 on smtp3.ugent.be : j-chkmail score : X : R=. U=. O=### B=0.000 -> S=0.249 X-j-chkmail-Status: Ham Cc: "core@ietf.org WG" Subject: Re: [core] Concerning the format in the profile draft 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: Sun, 09 Jun 2013 19:28:09 -0000 On 08 Jun 2013, at 02:59, Bert Greevenbosch = wrote: > Hi Zach and Rick, >=20 > Indeed the profile draft currently just signals supported CoAP = options, content format and blocksize. We are strongly considering = removing the content format because it is already signalled in the link = format. We would like to add supported methods GET/PUT/POST/DELETE. At this moment the draft indeed only signals supported CoAP options. = However, more information than supported CoAP options could be conveyed = such as CoAP protocol parameters used by the server. The ability to = retrieve this information via a well-defined mechanism is less = cumbersome than having to use trial-and-error at all times. An = out-of-band approach is suitable for retrieving whether an endpoint = implements e.g. a Light object model, but will not tell everything about = the options supported by the endpoint or the individual resources. A = profile as proposed in the draft can help. Regarding the discussion whether the profile should only express = information about the endpoint and not about the individual resources: Even when the endpoint supports a CoAP option, this does not imply that = the option can be applied to a specific resource hosted by that endpoint = (e.g. observe option). Of course, indicating that an option is supported = by a resource can be done by adding an attribute to /.well-known/core. = However, anticipating that more and more options will appear, it may = become inconvenient to embed everything in /.well-known/core and = inflating the size of this resource. Any thoughts about that?=20 Finally, the profile concept could be used to provide other resource = specific information that cannot be retrieved easily out-of-band. A = quick example based on the core-interfaces draft: for a linked batch = resource, the resource profile could list the current resources that are = part of the linked batch or a resource profile could list the supported = resource observation attributes.=20 Kind regards, Jeroen =20 >=20 > I use the term "profile description" because it signals the subset of = all what CoAP capabilities the entity supports. But I don't think the = naming is critical. We could also call it "CoAP capabilities = description" or something. >=20 > The profile draft is in the process of development, so we can = certainly add more information as required. >=20 > As Zach mentions, the link format and resource directory already give = some information about the resources. But in my view, this information = currently is too limited. However, it is a reason that I wrote below the = discussion points about whether or not to merge ".well-known/core" and = ".well-known/profile". What do you think about this? >=20 > I think the profile information is useful in several deployments. = Entities that benefit from it are e.g. general proxies/gateways that = talk to multiple endpoints, clients that can find out about whether or = not proxy-unsafe options are supported by the proxy, or which = capabilities of a server they can exploit, and servers receiving less = messages that they cannot handle. Finally, the information can be used = for debugging/diagnostic purposes. >=20 > Thanks a lot for your feedback and considerations! What is your = opinion? >=20 > Best regards, > Bert >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Zach Shelby > Sent: 2013=C4=EA6=D4=C27=C8=D5 0:26 > To: Rick Bullotta > Cc: core@ietf.org WG > Subject: Re: [core] Concerning the format in the profile draft >=20 > Hi Rick, >=20 > On Jun 6, 2013, at 1:51 PM, Rick Bullotta = wrote: >=20 >> If I understand the situation correctly, the ability to access a = device's profile in this way is extremely useful in situations when a = development environment/platform (e.g. our ThingWorx platform) wants to = access the metadata for a device even when the device itself is offline. = It provides a durable catalog for this metadata information, enabling = development activities to occur independent of connection status. =20 >=20 > No, the draft that Bert et al. were discussing here is about = discovering the CoAP protocol capabilities that an endpoint supports = using a special URI that can be requested. For example does an endpoint = support a special CoAP option. "Profile" is probably a really poor term = to describe that (confuses me at least).=20 >=20 > We do have a mechanism already to do what you describe. That is the = CoRE Link Format (RFC6690) format that we use to describe the resources = and their meta-data that an endpoint has available. By default these = links can be discovered from any endpoint by doing a GET request to = /.well-known/core. We also have a mechanism to post these links to a = central Resource Directory where they are available even when the = endpoint is off-line: >=20 > http://tools.ietf.org/html/draft-ietf-core-resource-directory >=20 >> Additionally, with some further design work, this resource repository = can become an excellent mechanism for accessing and managing the = definition(s) of "generic profiles" (e.g. an energy meter, a traffic = light, a refrigerated shipping container) and their association to = specific devices. >=20 > Exactly! The new OMA Lightweight standard defines a complete Object = model and provides an Object registry, so when you see such a link, you = know exactly what the resource is about (Light Control Object, Location = Object, Device Object etc.).=20 >=20 > Regards, > Zach >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Sun Jun 9 23:36:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E614821F8FB3 for ; Sun, 9 Jun 2013 23:36:31 -0700 (PDT) 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 9kXNLt8im3gk for ; Sun, 9 Jun 2013 23:36:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D924021F8F61 for ; Sun, 9 Jun 2013 23:36:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:32883 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UlviH-0001Xf-P0; Mon, 10 Jun 2013 08:36:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 10 Jun 2013 06:36:21 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/330 Message-ID: <060.1ddf0f9d1715d9905182676da2f0559f@trac.tools.ietf.org> X-Trac-Ticket-ID: 330 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com Resent-Message-Id: <20130610063630.D924021F8F61@ietfa.amsl.com> Resent-Date: Sun, 9 Jun 2013 23:36:30 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #330: Include HTTP-CoAP URI mapping proposals sent to WG list 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, 10 Jun 2013 06:36:32 -0000 #330: Include HTTP-CoAP URI mapping proposals sent to WG list Include HTTP-CoAP URI mapping proposals sent to WG list: see http://www.ietf.org/mail-archive/web/core/current/msg04413.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: major | Version: Component: http- | Keywords: mapping | Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Tue Jun 11 22:58:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8D521F9C0F for ; Tue, 11 Jun 2013 22:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.49 X-Spam-Level: X-Spam-Status: No, score=-4.49 tagged_above=-999 required=5 tests=[AWL=2.108, 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 Q9GP41HXiJQ7 for ; Tue, 11 Jun 2013 22:58:06 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4A42D21F9C0A for ; Tue, 11 Jun 2013 22:58:06 -0700 (PDT) Received: from mail117-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Jun 2013 05:58:05 +0000 Received: from mail117-co9 (localhost [127.0.0.1]) by mail117-co9-R.bigfish.com (Postfix) with ESMTP id C46D5300235 for ; Wed, 12 Jun 2013 05:58:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz15d6Oc85fh9251I217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail117-co9 (localhost.localdomain [127.0.0.1]) by mail117-co9 (MessageSwitch) id 1371016683897406_11576; Wed, 12 Jun 2013 05:58:03 +0000 (UTC) Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.225]) by mail117-co9.bigfish.com (Postfix) with ESMTP id D8874D8004F for ; Wed, 12 Jun 2013 05:58:03 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Jun 2013 05:58:00 +0000 Received: from 011-DB3MMR1-016.MGDPHG.emi.philips.com (10.128.28.100) by 011-DB3MMR1-001.MGDPHG.emi.philips.com (10.128.28.51) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 12 Jun 2013 05:57:58 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.219]) by 011-DB3MMR1-016.MGDPHG.emi.philips.com ([10.128.28.100]) with mapi id 14.02.0328.011; Wed, 12 Jun 2013 05:59:26 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: Sleepy devices in CoAP - Requirements Thread-Index: Ac5nMFSPAFvgh+7KQa+UWFPeiSCffQ== Date: Wed, 12 Jun 2013 05:59:26 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C5A2AA@011-DB3MPN2-082.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: [188.207.99.238] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618C5A2AA011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] Sleepy devices in CoAP - Requirements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 05:58:11 -0000 --_000_031DD135F9160444ABBE3B0C36CED618C5A2AA011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, as input to last year's discussion on 'sleepy devices' in CoAP I have uploa= ded an I-D that aims to capture the requirements for sleepy devices. As discussed in the IETF 83 CoRE meeting, we can create a solution once the= requirements are sufficiently clear. The I-D is: http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00 Also I've uploaded a second I-D to provide possible solutions to meet these= requirements, based on an architecture that uses a specific type of interm= ediary to interface to the sleepy devices: http://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01 regards, Esko ________________________________ 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_031DD135F9160444ABBE3B0C36CED618C5A2AA011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

as input to last year’s discussion on ‘s= leepy devices’ in CoAP I have uploaded an I-D that aims to capture th= e requirements for sleepy devices.

As discussed in the IETF 83 CoRE meeting, we can cre= ate a solution once the requirements are sufficiently clear. The I-D is:

http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00=

 

Also I’ve uploaded a second I-D to provide pos= sible solutions to meet these requirements, based on an architecture that u= ses a specific type of intermediary to interface to the sleepy devices:

http://tools.ietf.org/html/draft-dijk-core-sleepy-so= lutions-01

 

regards,

Esko


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_031DD135F9160444ABBE3B0C36CED618C5A2AA011DB3MPN2082MGDP_-- From trac+core@trac.tools.ietf.org Wed Jun 12 00:46:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9DF21F9AF8 for ; Wed, 12 Jun 2013 00:46:14 -0700 (PDT) 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 vRO65WaKYFRT for ; Wed, 12 Jun 2013 00:46:13 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 532F421F9AF7 for ; Wed, 12 Jun 2013 00:46:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:37635 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Umfkt-0000zs-5c; Wed, 12 Jun 2013 09:46:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 12 Jun 2013 07:46:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/331 Message-ID: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> X-Trac-Ticket-ID: 331 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130612074610.532F421F9AF7@ietfa.amsl.com> Resent-Date: Wed, 12 Jun 2013 00:46:09 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #331: No way to indicate preferred size in a 4.13 error 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, 12 Jun 2013 07:46:14 -0000 #331: No way to indicate preferred size in a 4.13 error Martin Stiemerling notes (msg04557): Section 4.6 8) Flow Control/Receiver Buffer The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness. The 4.13 "Request Entity Too Large" with a protocol field that indicates the maximum data size would be fixing this. Carsten says: The design rules for CoAP would put such a "protocol field" into an Option (type uint) that would be sent back with the 4.13 response. This would be an elective option, as the 4.13 response is still valid information even if the option is not understood. Now, we already have two related mechanisms in -block: »The error code 4.13 (Request Entity Too Large) can be returned at any time by a server that does not currently have the resources to store blocks for a block-wise request payload transfer that it would intend to implement in an atomic fashion. (Note that a 4.13 response to a request that does not employ Block1 is a hint for the client to try sending Block1, and a 4.13 response with a smaller SZX in its Block1 option than requested is a hint to try a smaller SZX.)« So we can use SZX in Block1 for the "datagram too large" situation. Since that is only sent for a request that specified Block1, there may be two exchanges before a good datagram size is arrived at, if the requesting endpoint does support Block1, which is suboptimal, but probably acceptable for a multi-exchange Block1 transfer. With the Block1 case taken care of, we still don't have anything to indicate the desired size of the *entire* request payload. -block defines a Size option that is used for exchanging information about payload sizes. The Size option is currently artfully split between request and response semantics based on the presence of other options and some heuristics (just as Block was before it was split into Block1 and Block2). Can we shoehorn in the required semantics, e.g. by giving it special semantics for the 4.13 case? Or should there be a Size1 and a Size2? And, independent of how exactly we solve this problem with -block: Is it a requirement that this meaning/variant of Size be included in the base protocol? Or can we wait with this for a couple of months until -block is done? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: protocol | Milestone: post-IESG-1 enhancement | Version: coap-17 Priority: major | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Jun 12 01:07:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4FC21F9C13 for ; Wed, 12 Jun 2013 01:07:53 -0700 (PDT) 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 HE4EyQGK6Gy4 for ; Wed, 12 Jun 2013 01:07:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E67FF21F9C12 for ; Wed, 12 Jun 2013 01:07:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:39380 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Umg5u-0006JU-JW; Wed, 12 Jun 2013 10:07:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 12 Jun 2013 08:07:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/331#comment:1 Message-ID: <066.3acb1402966e018d8defc3682d25d0aa@trac.tools.ietf.org> References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> X-Trac-Ticket-ID: 331 In-Reply-To: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130612080752.E67FF21F9C12@ietfa.amsl.com> Resent-Date: Wed, 12 Jun 2013 01:07:52 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 12 Jun 2013 08:07:53 -0000 #331: No way to indicate preferred size in a 4.13 error Comment (by cabo@tzi.org): From [1404]: Prepare ticket 331. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: post-IESG-1 Priority: major | Version: coap-17 Component: coap | Resolution: Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From rick.bullotta@thingworx.com Wed Jun 12 07:01:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1FA21F9BC7 for ; Wed, 12 Jun 2013 07:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 USLNMDsjuRwV for ; Wed, 12 Jun 2013 07:01:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7F21F9B8F for ; Wed, 12 Jun 2013 07:01:52 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB004.namprd06.prod.outlook.com (10.242.190.155) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 12 Jun 2013 14:01:50 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) with mapi id 15.00.0702.005; Wed, 12 Jun 2013 14:01:50 +0000 From: Rick Bullotta To: "Dijk, Esko" , "core (core@ietf.org)" Thread-Topic: Sleepy devices in CoAP - Requirements Thread-Index: Ac5nMFSPAFvgh+7KQa+UWFPeiSCffQARIpzw Date: Wed, 12 Jun 2013 14:01:49 +0000 Message-ID: <95ea11740e1b429ab403b856e5a6f1b5@BLUPR06MB001.namprd06.prod.outlook.com> References: <031DD135F9160444ABBE3B0C36CED618C5A2AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C5A2AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [96.245.114.98] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR06MB004; H:BLUPR06MB001.namprd06.prod.outlook.com; LANG:en; Content-Type: multipart/alternative; boundary="_000_95ea11740e1b429ab403b856e5a6f1b5BLUPR06MB001namprd06pro_" MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Subject: Re: [core] Sleepy devices in CoAP - Requirements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:01:59 -0000 --_000_95ea11740e1b429ab403b856e5a6f1b5BLUPR06MB001namprd06pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Esko. Where would a device that is "somewhat sleepy" (e.g. a cellular or satelli= te gateway with support for SMS, RF or other "shoulder tap") fall in this s= cenario? In some aspects, it is a SEP (from the standpoint of the primary = radio and communications) but it is also a NSEP from the perspective of lis= tening on an SMS or other low power/low bandwidth channel for external "wak= e up". Rick ThingWorx From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dij= k, Esko Sent: Wednesday, June 12, 2013 1:59 AM To: core (core@ietf.org) Subject: [core] Sleepy devices in CoAP - Requirements Dear all, as input to last year's discussion on 'sleepy devices' in CoAP I have uploa= ded an I-D that aims to capture the requirements for sleepy devices. As discussed in the IETF 83 CoRE meeting, we can create a solution once the= requirements are sufficiently clear. The I-D is: http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00 Also I've uploaded a second I-D to provide possible solutions to meet these= requirements, based on an architecture that uses a specific type of interm= ediary to interface to the sleepy devices: http://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01 regards, Esko ________________________________ 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_95ea11740e1b429ab403b856e5a6f1b5BLUPR06MB001namprd06pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Esko.

 

Where would a device t= hat is “somewhat sleepy” (e.g.  a cellular or satellite ga= teway with support for SMS, RF or other “shoulder tap”) fall in= this scenario?  In some aspects, it is a SEP (from the standpoint of the primary radio and communications) but it is also a NSEP from the pe= rspective of listening on an SMS or other low power/low bandwidth channel f= or external “wake up”.

 

Rick=

ThingWorx

 

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko
Sent: Wednesday, June 12, 2013 1:59 AM
To: core (core@ietf.org)
Subject: [core] Sleepy devices in CoAP - Requirements

 

Dear all,

 

as input to last year’s discussion on ‘s= leepy devices’ in CoAP I have uploaded an I-D that aims to capture th= e requirements for sleepy devices.

As discussed in the IETF 83 CoRE meeting, we can cre= ate a solution once the requirements are sufficiently clear. The I-D is:

http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00=

 

Also I’ve uploaded a second I-D to provide pos= sible solutions to meet these requirements, based on an architecture that u= ses a specific type of intermediary to interface to the sleepy devices:

http://tools.ietf.org/html/draft-dijk-core-sleepy-so= lutions-01

 

regards,

Esko

 

The information contained in th= is 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 proh= ibited and may be unlawful. If you are not the intended recipient, please c= ontact the sender by return e-mail and destroy all copies of the original message.

--_000_95ea11740e1b429ab403b856e5a6f1b5BLUPR06MB001namprd06pro_-- From esko.dijk@philips.com Wed Jun 12 09:13:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC0B11E80DE for ; Wed, 12 Jun 2013 09:13:58 -0700 (PDT) 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.499, 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 hiTUCrXKsvG1 for ; Wed, 12 Jun 2013 09:13:53 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id EAF5311E80BA for ; Wed, 12 Jun 2013 09:13:52 -0700 (PDT) Received: from mail159-co9-R.bigfish.com (10.236.132.230) by CO9EHSOBE023.bigfish.com (10.236.130.86) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Jun 2013 16:13:49 +0000 Received: from mail159-co9 (localhost [127.0.0.1]) by mail159-co9-R.bigfish.com (Postfix) with ESMTP id D4BDF4028B for ; Wed, 12 Jun 2013 16:13:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz15d6O9371Ic85fh1418I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail159-co9 (localhost.localdomain [127.0.0.1]) by mail159-co9 (MessageSwitch) id 1371053627894457_27741; Wed, 12 Jun 2013 16:13:47 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.252]) by mail159-co9.bigfish.com (Postfix) with ESMTP id CDDB220059; Wed, 12 Jun 2013 16:13:47 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Jun 2013 16:13:47 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 12 Jun 2013 16:13:02 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.219]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.02.0328.011; Wed, 12 Jun 2013 16:12:32 +0000 From: "Dijk, Esko" To: Rick Bullotta , "core (core@ietf.org)" Thread-Topic: Sleepy devices in CoAP - Requirements Thread-Index: Ac5nMFSPAFvgh+7KQa+UWFPeiSCffQARIpzwAARESEA= Date: Wed, 12 Jun 2013 16:14:30 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C5B5F6@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618C5A2AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <95ea11740e1b429ab403b856e5a6f1b5@BLUPR06MB001.namprd06.prod.outlook.com> In-Reply-To: <95ea11740e1b429ab403b856e5a6f1b5@BLUPR06MB001.namprd06.prod.outlook.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.194.123] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618C5B5F6011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Sleepy devices in CoAP - Requirements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 16:13:58 -0000 --_000_031DD135F9160444ABBE3B0C36CED618C5B5F6011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rick, I think that if a device sleeps part of the time and can be woken by extern= al triggers that are not sent over the communication interface over which C= oAP runs (e.g. wake by sensor input, SMS received, FM radio data broadcast,= button push, etc.) we should consider it a SEP. However, in case a CoAP client could always send e.g. an SMS first to wake = the SEP before initiating a CoAP request, the requirements would change a b= it. E.g. the R3.1 "Read via Proxy" and R4.1 "Write via Proxy" may not be needed= anymore since the reading/writing can always be done by first waking the S= EP and then doing the CoAP request. Esko From: Rick Bullotta [mailto:rick.bullotta@thingworx.com] Sent: Wednesday, June 12, 2013 16:02 To: Dijk, Esko; core (core@ietf.org) Subject: RE: Sleepy devices in CoAP - Requirements Hi, Esko. Where would a device that is "somewhat sleepy" (e.g. a cellular or satelli= te gateway with support for SMS, RF or other "shoulder tap") fall in this s= cenario? In some aspects, it is a SEP (from the standpoint of the primary = radio and communications) but it is also a NSEP from the perspective of lis= tening on an SMS or other low power/low bandwidth channel for external "wak= e up". Rick ThingWorx From: core-bounces@ietf.org [mailto:core-boun= ces@ietf.org] On Behalf Of Dijk, Esko Sent: Wednesday, June 12, 2013 1:59 AM To: core (core@ietf.org) Subject: [core] Sleepy devices in CoAP - Requirements Dear all, as input to last year's discussion on 'sleepy devices' in CoAP I have uploa= ded an I-D that aims to capture the requirements for sleepy devices. As discussed in the IETF 83 CoRE meeting, we can create a solution once the= requirements are sufficiently clear. The I-D is: http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00 Also I've uploaded a second I-D to provide possible solutions to meet these= requirements, based on an architecture that uses a specific type of interm= ediary to interface to the sleepy devices: http://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01 regards, Esko ________________________________ 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_031DD135F9160444ABBE3B0C36CED618C5B5F6011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Rick,=

 

I think that if a devi= ce sleeps part of the time and can be woken by external triggers that are n= ot sent over the communication interface over which CoAP runs (e.g. wake by= sensor input, SMS received, FM radio data broadcast, button push, etc.) we should consider it a SEP.

 

However, in case a CoA= P client could always send e.g. an SMS first to wake the SEP before initiat= ing a CoAP request, the requirements would change a bit.<= /p>

E.g. the R3.1 “R= ead via Proxy” and R4.1 “Write via Proxy” may not be need= ed anymore since the reading/writing can always be done by first waking the= SEP and then doing the CoAP request.

 

Esko=

 

From: Rick Bul= lotta [mailto:rick.bullotta@thingworx.com]
Sent: Wednesday, June 12, 2013 16:02
To: Dijk, Esko; core (core@ietf.org)
Subject: RE: Sleepy devices in CoAP - Requirements=

 

Hi, Esko.

 

Where would a device t= hat is “somewhat sleepy” (e.g.  a cellular or satellite ga= teway with support for SMS, RF or other “shoulder tap”) fall in= this scenario?  In some aspects, it is a SEP (from the standpoint of the primary radio and communications) but it is also a NSEP from the pe= rspective of listening on an SMS or other low power/low bandwidth channel f= or external “wake up”.

 

Rick=

ThingWorx

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko
Sent: Wednesday, June 12, 2013 1:59 AM
To: core (core@ietf.org)
Subject: [core] Sleepy devices in CoAP - Requirements

 

Dear all,

 

as input to last year’s discussion on ‘s= leepy devices’ in CoAP I have uploaded an I-D that aims to capture th= e requirements for sleepy devices.

As discussed in the IETF 83 CoRE meeting, we can cre= ate a solution once the requirements are sufficiently clear. The I-D is:

http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00=

 

Also I’ve uploaded a second I-D to provide pos= sible solutions to meet these requirements, based on an architecture that u= ses a specific type of intermediary to interface to the sleepy devices:

http://tools.ietf.org/html/draft-dijk-core-sleepy-so= lutions-01

 

regards,

Esko

 

The information contained in th= is 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 proh= ibited and may be unlawful. If you are not the intended recipient, please c= ontact the sender by return e-mail and destroy all copies of the original message.

--_000_031DD135F9160444ABBE3B0C36CED618C5B5F6011DB3MPN2082MGDP_-- From Akbar.Rahman@InterDigital.com Sun Jun 16 17:20:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8BB21F9CD6 for ; Sun, 16 Jun 2013 17:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVKsU4HKJccO for ; Sun, 16 Jun 2013 17:20:42 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id AA42E21F9C7A for ; Sun, 16 Jun 2013 17:20:41 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jun 2013 20:20:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 16 Jun 2013 20:20:38 -0400 Message-ID: In-Reply-To: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: Ac5nQSOCmiyQGoUyTA6GZ2dLzDhb1ADrukSQ References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 17 Jun 2013 00:20:39.0957 (UTC) FILETIME=[7F3AAC50:01CE6AF0] Cc: draft-ietf-core-coap@tools.ietf.org, trac+core@trac.tools.ietf.org, core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 00:20:46 -0000 SGkgQ2Fyc3RlbiwNCg0KDQoNCldpdGggcmVzcGVjdCB0byB5b3VyIHF1ZXN0aW9uOg0KDQoiQW5k LCBpbmRlcGVuZGVudCBvZiBob3cgZXhhY3RseSB3ZSBzb2x2ZSB0aGlzIHByb2JsZW0gd2l0aCAt YmxvY2s6IElzIGl0IGEgIHJlcXVpcmVtZW50IHRoYXQgdGhpcyBtZWFuaW5nL3ZhcmlhbnQgb2Yg U2l6ZSBiZSBpbmNsdWRlZCBpbiB0aGUgYmFzZSAgcHJvdG9jb2w/ICBPciBjYW4gd2Ugd2FpdCB3 aXRoIHRoaXMgZm9yIGEgY291cGxlIG9mIG1vbnRocyB1bnRpbCAtYmxvY2sgaXMgIGRvbmU/Ig0K DQoNCk15IHZvdGUgaXMgdGhhdCwgeWVzLCB3ZSBkbyBzb2x2ZSBpdCBpbiB0aGUgYmFzZSBkcmFm dCAoYW5kIG5vdCB3YWl0IHVudGlsIC1ibG9jayBpcyBkb25lKS4gIEkgdGhpbmsgTWFydGluIGFs c28gd2FudHMgdGhlIChvciBhdCBsZWFzdCAiYSIpIHNvbHV0aW9uIGluIHRoZSBiYXNlIGRyYWZ0 Lg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQoNCkFrYmFyDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgY29yZSBpc3N1ZSB0cmFja2VyDQpTZW50OiBXZWRu ZXNkYXksIEp1bmUgMTIsIDIwMTMgMzo0NiBBTQ0KVG86IGRyYWZ0LWlldGYtY29yZS1jb2FwQHRv b2xzLmlldGYub3JnOyBjYWJvQHR6aS5vcmcNCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBb Y29yZV0gIzMzMTogTm8gd2F5IHRvIGluZGljYXRlIHByZWZlcnJlZCBzaXplIGluIGEgNC4xMyBl cnJvcg0KDQojMzMxOiBObyB3YXkgdG8gaW5kaWNhdGUgcHJlZmVycmVkIHNpemUgaW4gYSA0LjEz IGVycm9yDQoNCiBNYXJ0aW4gU3RpZW1lcmxpbmcgbm90ZXMgKG1zZzA0NTU3KToNCg0KIFNlY3Rp b24gNC42DQoNCiA4KSBGbG93IENvbnRyb2wvUmVjZWl2ZXIgQnVmZmVyIFRoZSBwcm90b2NvbCBk b2VzIG5vdCBoYXZlIGFueSByZWFsIG1lYW5zICBmb3IgdGhlIHJlY2VpdmVyIHRvIGNvbnRyb2wg dGhlIGFtb3VudCBvZiBkYXRhIHRoYXQgaXMgYmVpbmcgc2VudCB0byBpdC4gSSAgY2FuIHVuZGVy c3RhbmQgdGhlIGF0dGVtcHQgdG8gcHJvdmlkZSBhIHNpbXBsZSBwcm90b2NvbCwgYnV0IGFkZGlu ZyBhIHZlcnkgIGJhc2ljIGZsb3cgY29udHJvbCBtZWNoYW5pc20gd2lsbCBub3QgcHJvaGliaXRp dmVseSBpbmNyZWFzZSB0aGUgIGNvbXBsZXhpdHkgb2YgdGhlIHByb3RvY29sLCB3aGlsZSBpbXBy b3Zpbmcgcm9idXN0bmVzcy4gVGhlIDQuMTMgIlJlcXVlc3QgIEVudGl0eSBUb28gTGFyZ2UiIHdp dGggYSBwcm90b2NvbCBmaWVsZCB0aGF0IGluZGljYXRlcyB0aGUgbWF4aW11bSBkYXRhICBzaXpl IHdvdWxkIGJlIGZpeGluZyB0aGlzLg0KDQogQ2Fyc3RlbiBzYXlzOg0KDQogVGhlIGRlc2lnbiBy dWxlcyBmb3IgQ29BUCB3b3VsZCBwdXQgc3VjaCBhICJwcm90b2NvbCBmaWVsZCIgaW50byBhbiBP cHRpb24gICh0eXBlIHVpbnQpIHRoYXQgd291bGQgYmUgc2VudCBiYWNrIHdpdGggdGhlIDQuMTMg cmVzcG9uc2UuIFRoaXMgd291bGQgYmUgIGFuIGVsZWN0aXZlIG9wdGlvbiwgYXMgdGhlIDQuMTMg cmVzcG9uc2UgaXMgc3RpbGwgdmFsaWQgaW5mb3JtYXRpb24gZXZlbiAgaWYgdGhlIG9wdGlvbiBp cyBub3QgdW5kZXJzdG9vZC4NCg0KIE5vdywgd2UgYWxyZWFkeSBoYXZlIHR3byByZWxhdGVkIG1l Y2hhbmlzbXMgaW4gLWJsb2NrOg0KDQogwrtUaGUgZXJyb3IgY29kZSA0LjEzIChSZXF1ZXN0IEVu dGl0eSBUb28gTGFyZ2UpIGNhbiBiZSByZXR1cm5lZCBhdCBhbnkgIHRpbWUgYnkgYSBzZXJ2ZXIg dGhhdCBkb2VzIG5vdCBjdXJyZW50bHkgaGF2ZSB0aGUgcmVzb3VyY2VzIHRvIHN0b3JlICBibG9j a3MgZm9yIGEgYmxvY2std2lzZSByZXF1ZXN0IHBheWxvYWQgdHJhbnNmZXIgdGhhdCBpdCB3b3Vs ZCBpbnRlbmQgdG8gIGltcGxlbWVudCBpbiBhbiBhdG9taWMgZmFzaGlvbi4gIChOb3RlIHRoYXQg YSA0LjEzIHJlc3BvbnNlIHRvIGEgcmVxdWVzdCAgdGhhdCBkb2VzIG5vdCBlbXBsb3kgQmxvY2sx IGlzIGEgaGludCBmb3IgdGhlIGNsaWVudCB0byB0cnkgc2VuZGluZyAgQmxvY2sxLCBhbmQgYSA0 LjEzIHJlc3BvbnNlIHdpdGggYSBzbWFsbGVyIFNaWCBpbiBpdHMgQmxvY2sxIG9wdGlvbiB0aGFu ICByZXF1ZXN0ZWQgaXMgYSBoaW50IHRvIHRyeSBhIHNtYWxsZXIgU1pYLinCqw0KDQogU28gd2Ug Y2FuIHVzZSBTWlggaW4gQmxvY2sxIGZvciB0aGUgImRhdGFncmFtIHRvbyBsYXJnZSIgc2l0dWF0 aW9uLiAgU2luY2UgIHRoYXQgaXMgb25seSBzZW50IGZvciBhIHJlcXVlc3QgdGhhdCBzcGVjaWZp ZWQgQmxvY2sxLCB0aGVyZSBtYXkgYmUgdHdvICBleGNoYW5nZXMgYmVmb3JlIGEgZ29vZCBkYXRh Z3JhbSBzaXplIGlzIGFycml2ZWQgYXQsIGlmIHRoZSByZXF1ZXN0aW5nICBlbmRwb2ludCBkb2Vz IHN1cHBvcnQgQmxvY2sxLCB3aGljaCBpcyBzdWJvcHRpbWFsLCBidXQgcHJvYmFibHkgYWNjZXB0 YWJsZSAgZm9yIGEgbXVsdGktZXhjaGFuZ2UgQmxvY2sxIHRyYW5zZmVyLg0KDQogV2l0aCB0aGUg QmxvY2sxIGNhc2UgdGFrZW4gY2FyZSBvZiwgd2Ugc3RpbGwgZG9uJ3QgaGF2ZSBhbnl0aGluZyB0 byAgaW5kaWNhdGUgdGhlIGRlc2lyZWQgc2l6ZSBvZiB0aGUgKmVudGlyZSogcmVxdWVzdCBwYXls b2FkLiAtYmxvY2sgZGVmaW5lcyAgYSBTaXplIG9wdGlvbiB0aGF0IGlzIHVzZWQgZm9yIGV4Y2hh bmdpbmcgaW5mb3JtYXRpb24gYWJvdXQgcGF5bG9hZCBzaXplcy4NCiBUaGUgU2l6ZSBvcHRpb24g aXMgY3VycmVudGx5IGFydGZ1bGx5IHNwbGl0IGJldHdlZW4gcmVxdWVzdCBhbmQgcmVzcG9uc2Ug IHNlbWFudGljcyBiYXNlZCBvbiB0aGUgcHJlc2VuY2Ugb2Ygb3RoZXIgb3B0aW9ucyBhbmQgc29t ZSBoZXVyaXN0aWNzIChqdXN0ICBhcyBCbG9jayB3YXMgYmVmb3JlIGl0IHdhcyBzcGxpdCBpbnRv IEJsb2NrMSBhbmQgQmxvY2syKS4gIENhbiB3ZSBzaG9laG9ybiAgaW4gdGhlIHJlcXVpcmVkIHNl bWFudGljcywgZS5nLiBieSBnaXZpbmcgaXQgc3BlY2lhbCBzZW1hbnRpY3MgZm9yIHRoZQ0KIDQu MTMgY2FzZT8gIE9yIHNob3VsZCB0aGVyZSBiZSBhIFNpemUxIGFuZCBhIFNpemUyPw0KDQogQW5k LCBpbmRlcGVuZGVudCBvZiBob3cgZXhhY3RseSB3ZSBzb2x2ZSB0aGlzIHByb2JsZW0gd2l0aCAt YmxvY2s6IElzIGl0IGEgIHJlcXVpcmVtZW50IHRoYXQgdGhpcyBtZWFuaW5nL3ZhcmlhbnQgb2Yg U2l6ZSBiZSBpbmNsdWRlZCBpbiB0aGUgYmFzZSAgcHJvdG9jb2w/ICBPciBjYW4gd2Ugd2FpdCB3 aXRoIHRoaXMgZm9yIGEgY291cGxlIG9mIG1vbnRocyB1bnRpbCAtYmxvY2sgaXMgIGRvbmU/DQoN Ci0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KIFJl cG9ydGVyOiAgICAgICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0LWlldGYtY29yZS1jb2Fw QHRvb2xzLmlldGYub3JnDQogIGNhYm9AdHppLm9yZyAgICAgICAgICAgfCAgICAgU3RhdHVzOiAg bmV3DQogICAgIFR5cGU6ICBwcm90b2NvbCAgICAgfCAgTWlsZXN0b25lOiAgcG9zdC1JRVNHLTEN CiAgZW5oYW5jZW1lbnQgICAgICAgICAgICB8ICAgIFZlcnNpb246ICBjb2FwLTE3DQogUHJpb3Jp dHk6ICBtYWpvciAgICAgICAgfCAgIEtleXdvcmRzOg0KQ29tcG9uZW50OiAgY29hcCAgICAgICAg IHwNCiBTZXZlcml0eTogIFN1Ym1pdHRlZCAgICB8DQogIFdHIERvY3VtZW50ICAgICAgICAgICAg fA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNr ZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvY29yZS90cmFjL3RpY2tldC8z MzE+DQpjb3JlIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvY29yZS8+DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29y ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From Akbar.Rahman@InterDigital.com Sun Jun 16 20:13:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03D21F9DE4 for ; Sun, 16 Jun 2013 20:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 KUE46cQOEx9i for ; Sun, 16 Jun 2013 20:13:32 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id AA99021F9DE1 for ; Sun, 16 Jun 2013 20:13:31 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jun 2013 23:13:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE6B08.A44B2275" Date: Sun, 16 Jun 2013 23:13:19 -0400 Message-ID: In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C5A2AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Sleepy devices in CoAP - Requirements Thread-Index: Ac5nMFSPAFvgh+7KQa+UWFPeiSCffQDvDAxQ References: <031DD135F9160444ABBE3B0C36CED618C5A2AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> From: "Rahman, Akbar" To: "Dijk, Esko" X-OriginalArrivalTime: 17 Jun 2013 03:13:30.0033 (UTC) FILETIME=[A446B210:01CE6B08] Cc: core@ietf.org Subject: Re: [core] Sleepy devices in CoAP - Requirements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 03:13:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE6B08.A44B2275 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Esko, =20 =20 Thanks for the excellent input to the Sleepy Devices space. I have the following initial feedback on your I-Ds: =20 * draft-dijk-core-sleepy-reqs-00 o The I-D seems to have a majority of requirements that can very realistically be addressed at the COAP application level (which is very good). But also it has some other requirements that most likely would need to be addressed at some lower level than CoAP (e.g. section 4.3, item 6 - Client location). Is my observation accurate, and if so should this duality be clearly indicated in the I-D? =20 o Do you think that it would be worthwhile to note that there are two classes of sleep patterns for sleepy devices (SEPs)? Namely, some SEPs may have predictable (e.g. scheduled) sleep cycles and others may have completely unpredictable (e.g. external event driven) sleep schedules. Maybe you had captured the concept in the text but it did not stand out for me at least. At least section 4.7 (item 1- Configurable sleep interval) seems to imply only support of fully scheduled sleep cycles to me ... =20 o I think we need to support more than just S0 class devices as SEP (section 1.2). For example, S1 is probably an important class of devices to also support as SEPs.=20 =20 * draft-dijk-core-sleepy-solutions-01 o It would be nice if you included http://tools.ietf.org/html/draft-rahman-core-sleepy-02 in your survey! =20 =20 =20 Best Regards, =20 =20 Akbar =20 =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko Sent: Wednesday, June 12, 2013 1:59 AM To: core (core@ietf.org) Subject: [core] Sleepy devices in CoAP - Requirements =20 Dear all, =20 as input to last year's discussion on 'sleepy devices' in CoAP I have uploaded an I-D that aims to capture the requirements for sleepy devices. As discussed in the IETF 83 CoRE meeting, we can create a solution once the requirements are sufficiently clear. The I-D is: http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00 =20 Also I've uploaded a second I-D to provide possible solutions to meet these requirements, based on an architecture that uses a specific type of intermediary to interface to the sleepy devices: http://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01 =20 regards, Esko =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. ------_=_NextPart_001_01CE6B08.A44B2275 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear Esko,

 

 

Thanks for the excellent = input to the Sleepy Devices space.  I have the following initial = feedback on your I-Ds:

 

·         = draft-dijk-core-sleepy-reqs-00

o   = The I-D seems to have a majority of requirements = that can very realistically be addressed at the COAP application level = (which is very good).  But also it has some other requirements that = most likely would need to be addressed at some lower level than CoAP = (e.g. section 4.3, item 6 – Client location).  Is my = observation accurate, and if so should this duality be clearly indicated = in the I-D?

 

o   = Do you think that it would be worthwhile to note = that there are two classes of sleep patterns for sleepy devices = (SEPs)?  Namely, some SEPs may have predictable (e.g. scheduled) = sleep cycles and others may have completely unpredictable (e.g. external = event driven) sleep schedules.   Maybe you had captured the = concept in the text but it did not stand out for me at least.  At = least section 4.7 (item 1- Configurable sleep interval) seems to imply = only support of fully scheduled sleep cycles to me = …

 

o   = I = think we need to support more than just S0 class devices as SEP (section = 1.2).  For example, S1 is probably an important class of devices to = also support as SEPs.

 

·         = draft-dijk-core-sleepy-solutions-01=

o   = It would be nice if you included http://to= ols.ietf.org/html/draft-rahman-core-sleepy-02 in your = survey!

 
 

 

Best = Regards,

 

 

Akbar

 

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] = On Behalf Of Dijk, Esko
Sent: Wednesday, June 12, 2013 = 1:59 AM
To: core (core@ietf.org)
Subject: = [core] Sleepy devices in CoAP - = Requirements

 

Dear = all,

 

as input to last year’s discussion on = ‘sleepy devices’ in CoAP I have uploaded an I-D that aims to = capture the requirements for sleepy devices.

As discussed in the IETF 83 CoRE meeting, we can = create a solution once the requirements are sufficiently clear. The I-D = is:

http:/= /tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00

 

Also = I’ve uploaded a second I-D to provide possible solutions to meet = these requirements, based on an architecture that uses a specific type = of intermediary to interface to the sleepy devices:

h= ttp://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01

 

regards,

Esko

 

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.

------_=_NextPart_001_01CE6B08.A44B2275-- From esko.dijk@philips.com Sun Jun 16 23:42:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19CD21F9A90 for ; Sun, 16 Jun 2013 23:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, 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 dqFP6HX2JZou for ; Sun, 16 Jun 2013 23:42:05 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id D371521F9A8E for ; Sun, 16 Jun 2013 23:42:04 -0700 (PDT) Received: from mail175-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Jun 2013 06:42:02 +0000 Received: from mail175-ch1 (localhost [127.0.0.1]) by mail175-ch1-R.bigfish.com (Postfix) with ESMTP id 8A5DB6012D for ; Mon, 17 Jun 2013 06:42:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz15d6O9371Ic85fh9251I1447I217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail175-ch1 (localhost.localdomain [127.0.0.1]) by mail175-ch1 (MessageSwitch) id 1371451319993588_3871; Mon, 17 Jun 2013 06:41:59 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail175-ch1.bigfish.com (Postfix) with ESMTP id EF5433E008B; Mon, 17 Jun 2013 06:41:59 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Jun 2013 06:41:59 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.190]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.02.0328.011; Mon, 17 Jun 2013 06:40:49 +0000 From: "Dijk, Esko" To: "Rahman, Akbar" Thread-Topic: [core] Sleepy devices in CoAP - Requirements Thread-Index: Ac5nMFSPAFvgh+7KQa+UWFPeiSCffQDvDAxQAA1iGLA= Date: Mon, 17 Jun 2013 06:41:22 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C6F511@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618C5A2AA@011-DB3MPN2-082.MGDPHG.emi.philips.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: [92.69.202.215] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618C6F511011DB3MPN2083MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Sleepy devices in CoAP - Requirements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 06:42:10 -0000 --_000_031DD135F9160444ABBE3B0C36CED618C6F511011DB3MPN2083MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Akbar, thanks for the feedback; here my comments: * draft-dijk-core-sleepy-reqs-00 o The I-D seems to have a majority of requirements that can very realisti= cally be addressed at the COAP application level (which is very good). But= also it has some other requirements that most likely would need to be addr= essed at some lower level than CoAP (e.g. section 4.3, item 6 - Client loca= tion). Is my observation accurate, and if so should this duality be clearl= y indicated in the I-D? -> Yes, there are requirements that influence on several levels, e.g. CoAP = level or below that. I think it's good to clearly indicate this. Some requi= rements can even be irrelevant for a solution in the CoAP space. o Do you think that it would be worthwhile to note that there are two cla= sses of sleep patterns for sleepy devices (SEPs)? Namely, some SEPs may ha= ve predictable (e.g. scheduled) sleep cycles and others may have completely= unpredictable (e.g. external event driven) sleep schedules. Maybe you ha= d captured the concept in the text but it did not stand out for me at least= . At least section 4.7 (item 1- Configurable sleep interval) seems to impl= y only support of fully scheduled sleep cycles to me ... -> Yes, that could be explicitly mentioned, agree. Also a mix between event= -driven and timer-driven can be expected, for example in the described 'hea= rtbeat' mechanism. o I think we need to support more than just S0 class devices as SEP (sect= ion 1.2). For example, S1 is probably an important class of devices to als= o support as SEPs. -> I was assuming S1 is not relevant because regular CoAP can be used with = those devices. However, if the "high latency" mentioned for S1 class device= s because sufficiently large there may be so much timeouts in CoAP that the= protocol effectively stops functioning. In this case we have at least two = solution directions to follow: 1) change timing parameters of CoAP protocol (requires the non-sleepy CoAP = device to also know about, and use, the new timing parameters) 2) use the same solution as is used for S0 devices. We should check whether to update the 'sleepy-reqs' I-D with such considera= tions, or to have these in the 'sleepy-problem-statement' I-D. * draft-dijk-core-sleepy-solutions-01 o It would be nice if you included http://tools.ietf.org/html/draft-rahma= n-core-sleepy-02 in your survey! -> well, this document is not really a survey but it tries to construct a s= pecific solution with some variations on how to implement the interfaces th= at are part of that solution. There could be a similar document made with the solution of rahman-core-sle= epy-02 integrated, I think. Esko From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] Sent: Monday, June 17, 2013 05:13 To: Dijk, Esko Cc: core@ietf.org Subject: RE: [core] Sleepy devices in CoAP - Requirements Dear Esko, Thanks for the excellent input to the Sleepy Devices space. I have the fol= lowing initial feedback on your I-Ds: * draft-dijk-core-sleepy-reqs-00 o The I-D seems to have a majority of requirements that can very realisti= cally be addressed at the COAP application level (which is very good). But= also it has some other requirements that most likely would need to be addr= essed at some lower level than CoAP (e.g. section 4.3, item 6 - Client loca= tion). Is my observation accurate, and if so should this duality be clearl= y indicated in the I-D? o Do you think that it would be worthwhile to note that there are two cla= sses of sleep patterns for sleepy devices (SEPs)? Namely, some SEPs may ha= ve predictable (e.g. scheduled) sleep cycles and others may have completely= unpredictable (e.g. external event driven) sleep schedules. Maybe you ha= d captured the concept in the text but it did not stand out for me at least= . At least section 4.7 (item 1- Configurable sleep interval) seems to impl= y only support of fully scheduled sleep cycles to me ... o I think we need to support more than just S0 class devices as SEP (sect= ion 1.2). For example, S1 is probably an important class of devices to als= o support as SEPs. * draft-dijk-core-sleepy-solutions-01 o It would be nice if you included http://tools.ietf.org/html/draft-rahma= n-core-sleepy-02 in your survey! Best Regards, Akbar From: core-bounces@ietf.org [mailto:core-boun= ces@ietf.org] On Behalf Of Dijk, Esko Sent: Wednesday, June 12, 2013 1:59 AM To: core (core@ietf.org) Subject: [core] Sleepy devices in CoAP - Requirements Dear all, as input to last year's discussion on 'sleepy devices' in CoAP I have uploa= ded an I-D that aims to capture the requirements for sleepy devices. As discussed in the IETF 83 CoRE meeting, we can create a solution once the= requirements are sufficiently clear. The I-D is: http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00 Also I've uploaded a second I-D to provide possible solutions to meet these= requirements, based on an architecture that uses a specific type of interm= ediary to interface to the sleepy devices: http://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01 regards, Esko ________________________________ 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_031DD135F9160444ABBE3B0C36CED618C6F511011DB3MPN2083MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Akbar,

 

thanks for the feedbac= k; here my comments:

·       &nb= sp; draft-dijk-core-sleepy-reqs-00=

o   Th= e I-D seems to have a majority of requirements that can very realistically = be addressed at the COAP application level (which is very good).  But = also it has some other requirements that most likely would need to be addressed at some lower level than CoAP (e.g.= section 4.3, item 6 – Client location).  Is my observation accu= rate, and if so should this duality be clearly indicated in the I-D?

-> Yes,= there are requirements that influence on several levels, e.g. CoAP level o= r below that. I think it’s good to clearly indicate this. Some requir= ements can even be irrelevant for a solution in the CoAP space.

 = ;

o   Do= you think that it would be worthwhile to note that there are two classes o= f sleep patterns for sleepy devices (SEPs)?  Namely, some SEPs may hav= e predictable (e.g. scheduled) sleep cycles and others may have completely unpredictable (e.g. external event driven) = sleep schedules.   Maybe you had captured the concept in the text= but it did not stand out for me at least.  At least section 4.7 (item= 1- Configurable sleep interval) seems to imply only support of fully scheduled sleep cycles to me …

-> Yes,= that could be explicitly mentioned, agree. Also a mix between event-driven= and timer-driven can be expected, for example in the described ‘hear= tbeat’ mechanism.

 

o   I = think we need to support more than just S0 class devices as SEP (section 1.= 2).  For example, S1 is probably an important class of devices to also= support as SEPs.

-> I was assuming S= 1 is not relevant because regular CoAP can be used with those devices. Howe= ver, if the “high latency” mentioned for S1 class devices becau= se sufficiently large there may be so much timeouts in CoAP that the protocol effectively stops functioning. In this case we h= ave at least two solution directions to follow:

1) change timing param= eters of CoAP protocol (requires the non-sleepy CoAP device to also know ab= out, and use, the new timing parameters)

2) use the same soluti= on as is used for S0 devices.

 

We should check whethe= r to update the ‘sleepy-reqs’ I-D with such considerations, or = to have these in the ‘sleepy-problem-statement’ I-D.=

 

<= ![if !supportLists]>·    &nb= sp;    draft-dijk-core-sleepy-solutions-01

o   It= would be nice if you included http://t= ools.ietf.org/html/draft-rahman-core-sleepy-02 in your survey!

-> well, this docum= ent is not really a survey but it tries to construct a specific solution wi= th some variations on how to implement the interfaces that are part of that= solution.

There could be a simil= ar document made with the solution of rahman-core-sleepy-02 integrated, I t= hink. 

 

Esko=

From: Rahman, = Akbar [mailto:Akbar.Rahman@InterDigital.com]
Sent: Monday, June 17, 2013 05:13
To: Dijk, Esko
Cc: core@ietf.org
Subject: RE: [core] Sleepy devices in CoAP - Requirements=

 

Dear Esko,<= /span>

 

 

Thanks for the excelle= nt input to the Sleepy Devices space.  I have the following initial fe= edback on your I-Ds:

 

·       &nb= sp; draft-dijk-core-sleepy-reqs-00=

o   Th= e I-D seems to have a majority of requirements that can very realistically = be addressed at the COAP application level (which is very good).  But = also it has some other requirements that most likely would need to be addressed at some lower level than CoAP (e.g.= section 4.3, item 6 – Client location).  Is my observation accu= rate, and if so should this duality be clearly indicated in the I-D?

 

o   Do= you think that it would be worthwhile to note that there are two classes o= f sleep patterns for sleepy devices (SEPs)?  Namely, some SEPs may hav= e predictable (e.g. scheduled) sleep cycles and others may have completely unpredictable (e.g. external event driven) = sleep schedules.   Maybe you had captured the concept in the text= but it did not stand out for me at least.  At least section 4.7 (item= 1- Configurable sleep interval) seems to imply only support of fully scheduled sleep cycles to me …

 

o   I = think we need to support more than just S0 class devices as SEP (section 1.= 2).  For example, S1 is probably an important class of devices to also= support as SEPs.

 

<= ![if !supportLists]>·    &nb= sp;    draft-dijk-core-sleepy-solutions-01

o   It= would be nice if you included http://t= ools.ietf.org/html/draft-rahman-core-sleepy-02 in your survey!

 
 <=
/pre>

 


Best Regards,


 


 


Akbar


 


 






From:
core-bounces@ietf.org [mailto:core-bounces@ietf.org]
On Behalf Of Dijk, Esko

Sent: Wednesday, June 12, 2013 1:59 AM

To: core (core@ietf.org)

Subject: [core] Sleepy devices in CoAP - Requirements






 




Dear all,


 


as input to last year’s discussion on ‘s=
leepy devices’ in CoAP I have uploaded an I-D that aims to capture th=
e requirements for sleepy devices.


As discussed in the IETF 83 CoRE meeting, we can cre=
ate a solution once the requirements are sufficiently clear. The I-D is:


http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00=



 


Also I’ve uploaded a second I-D to provide pos=
sible solutions to meet these requirements, based on an architecture that u=
ses a specific type of intermediary to interface to the sleepy devices:


http://tools.ietf.org/html/draft-dijk-core-sleepy-so=
lutions-01


 


regards,


Esko




 








The information contained in th=
is 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 proh=
ibited and may be unlawful. If you are not the intended recipient, please c=
ontact the sender by return e-mail
 and destroy all copies of the original message.
--_000_031DD135F9160444ABBE3B0C36CED618C6F511011DB3MPN2083MGDP_-- From esko.dijk@philips.com Sun Jun 16 23:47:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C06921F9A77 for ; Sun, 16 Jun 2013 23:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=1.125, 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 Pax5c6wQfqtB for ; Sun, 16 Jun 2013 23:47:40 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04B21F9A8E for ; Sun, 16 Jun 2013 23:47:40 -0700 (PDT) Received: from mail98-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Jun 2013 06:47:39 +0000 Received: from mail98-tx2 (localhost [127.0.0.1]) by mail98-tx2-R.bigfish.com (Postfix) with ESMTP id 7CD5B3A00F7; Mon, 17 Jun 2013 06:47:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(z10d0kz15d6O9371Ic89bh542I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail98-tx2 (localhost.localdomain [127.0.0.1]) by mail98-tx2 (MessageSwitch) id 1371451656828266_31350; Mon, 17 Jun 2013 06:47:36 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.247]) by mail98-tx2.bigfish.com (Postfix) with ESMTP id BAF443E004F; Mon, 17 Jun 2013 06:47:36 +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; Mon, 17 Jun 2013 06:47:33 +0000 Received: from 011-DB3MMR1-017.MGDPHG.emi.philips.com (10.128.28.102) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 17 Jun 2013 06:46:49 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.190]) by 011-DB3MMR1-017.MGDPHG.emi.philips.com ([10.128.28.102]) with mapi id 14.02.0328.011; Mon, 17 Jun 2013 06:46:14 +0000 From: "Dijk, Esko" To: "Rahman, Akbar" , "cabo@tzi.org" Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: AQHOavCHQ3fUK6vnakKCWJpCEZE4gZk5bikw Date: Mon, 17 Jun 2013 06:46:47 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.202.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "draft-ietf-core-coap@tools.ietf.org" , "trac+core@trac.tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 06:47:45 -0000 PiBNeSB2b3RlIGlzIHRoYXQsIHllcywgd2UgZG8gc29sdmUgaXQgaW4gdGhlIGJhc2UgZHJhZnQg KGFuZCBub3Qgd2FpdCB1bnRpbCAtYmxvY2sgaXMgZG9uZSkuICBJIHRoaW5rIE1hcnRpbiBhbHNv IHdhbnRzIHRoZSAob3IgYXQgbGVhc3QgImEiKSBzb2x1dGlvbiBpbiB0aGUgYmFzZSBkcmFmdC4N CkFncmVlLCBpdCBsb29rcyBsaWtlIE1hcnRpbidzIHJlcXVlc3QgaXMgdG8gaGF2ZSBpdCBzb2x2 ZWQgaW4gdGhlIGJhc2UgZHJhZnQuIChXaGV0aGVyIG5vdyBvciBpbiBhIGZldyBtb250aHMgdGlt ZS4pDQoNCkJ1dCBvZiBjb3Vyc2UgdGhlIGNob2ljZSBvZiBhICdTaXplJyBvcHRpb24gb3IgJ1Np emUxL1NpemUyJyBvcHRpb25zIHNvbHV0aW9uIG1heSBiZSBsaW5rZWQgdG8gY29yZS1ibG9jayB3 aGljaCBub3cgZGVmaW5lcyB0aGUgU2l6ZSBvcHRpb24uDQpBbiBlbGVjdGl2ZSBTaXplL1NpemUq IG9wdGlvbiB3b3VsZCBiZSBiZXN0IHRvIHNvbHZlIHRoaXMgd2l0aCBtaW5pbWFsIGNvbXBsZXhp dHkgaW1wYWN0IG9uIHRoZSBjbGllbnQuDQoNCihBbmQ6IE1VU1Qgb3IgU0hPVUxEIG9yIE1BWSBh IENvQVAgc2VydmVyIHNlbmQgdGhlIFNpemUgb3B0aW9uIGJhY2sgIHdpdGggYSA0LjEzLi4uPykN Cg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFo bWFuLCBBa2Jhcg0KU2VudDogTW9uZGF5LCBKdW5lIDE3LCAyMDEzIDAyOjIxDQpUbzogY2Fib0B0 emkub3JnDQpDYzogZHJhZnQtaWV0Zi1jb3JlLWNvYXBAdG9vbHMuaWV0Zi5vcmc7IHRyYWMrY29y ZUB0cmFjLnRvb2xzLmlldGYub3JnOyBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVd ICMzMzE6IE5vIHdheSB0byBpbmRpY2F0ZSBwcmVmZXJyZWQgc2l6ZSBpbiBhIDQuMTMgZXJyb3IN Cg0KSGkgQ2Fyc3RlbiwNCg0KDQoNCldpdGggcmVzcGVjdCB0byB5b3VyIHF1ZXN0aW9uOg0KDQoi QW5kLCBpbmRlcGVuZGVudCBvZiBob3cgZXhhY3RseSB3ZSBzb2x2ZSB0aGlzIHByb2JsZW0gd2l0 aCAtYmxvY2s6IElzIGl0IGEgIHJlcXVpcmVtZW50IHRoYXQgdGhpcyBtZWFuaW5nL3ZhcmlhbnQg b2YgU2l6ZSBiZSBpbmNsdWRlZCBpbiB0aGUgYmFzZSAgcHJvdG9jb2w/ICBPciBjYW4gd2Ugd2Fp dCB3aXRoIHRoaXMgZm9yIGEgY291cGxlIG9mIG1vbnRocyB1bnRpbCAtYmxvY2sgaXMgIGRvbmU/ Ig0KDQoNCk15IHZvdGUgaXMgdGhhdCwgeWVzLCB3ZSBkbyBzb2x2ZSBpdCBpbiB0aGUgYmFzZSBk cmFmdCAoYW5kIG5vdCB3YWl0IHVudGlsIC1ibG9jayBpcyBkb25lKS4gIEkgdGhpbmsgTWFydGlu IGFsc28gd2FudHMgdGhlIChvciBhdCBsZWFzdCAiYSIpIHNvbHV0aW9uIGluIHRoZSBiYXNlIGRy YWZ0Lg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQoNCkFrYmFyDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgY29yZSBpc3N1ZSB0cmFja2VyDQpTZW50OiBX ZWRuZXNkYXksIEp1bmUgMTIsIDIwMTMgMzo0NiBBTQ0KVG86IGRyYWZ0LWlldGYtY29yZS1jb2Fw QHRvb2xzLmlldGYub3JnOyBjYWJvQHR6aS5vcmcNCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0 OiBbY29yZV0gIzMzMTogTm8gd2F5IHRvIGluZGljYXRlIHByZWZlcnJlZCBzaXplIGluIGEgNC4x MyBlcnJvcg0KDQojMzMxOiBObyB3YXkgdG8gaW5kaWNhdGUgcHJlZmVycmVkIHNpemUgaW4gYSA0 LjEzIGVycm9yDQoNCiBNYXJ0aW4gU3RpZW1lcmxpbmcgbm90ZXMgKG1zZzA0NTU3KToNCg0KIFNl Y3Rpb24gNC42DQoNCiA4KSBGbG93IENvbnRyb2wvUmVjZWl2ZXIgQnVmZmVyIFRoZSBwcm90b2Nv bCBkb2VzIG5vdCBoYXZlIGFueSByZWFsIG1lYW5zICBmb3IgdGhlIHJlY2VpdmVyIHRvIGNvbnRy b2wgdGhlIGFtb3VudCBvZiBkYXRhIHRoYXQgaXMgYmVpbmcgc2VudCB0byBpdC4gSSAgY2FuIHVu ZGVyc3RhbmQgdGhlIGF0dGVtcHQgdG8gcHJvdmlkZSBhIHNpbXBsZSBwcm90b2NvbCwgYnV0IGFk ZGluZyBhIHZlcnkgIGJhc2ljIGZsb3cgY29udHJvbCBtZWNoYW5pc20gd2lsbCBub3QgcHJvaGli aXRpdmVseSBpbmNyZWFzZSB0aGUgIGNvbXBsZXhpdHkgb2YgdGhlIHByb3RvY29sLCB3aGlsZSBp bXByb3Zpbmcgcm9idXN0bmVzcy4gVGhlIDQuMTMgIlJlcXVlc3QgIEVudGl0eSBUb28gTGFyZ2Ui IHdpdGggYSBwcm90b2NvbCBmaWVsZCB0aGF0IGluZGljYXRlcyB0aGUgbWF4aW11bSBkYXRhICBz aXplIHdvdWxkIGJlIGZpeGluZyB0aGlzLg0KDQogQ2Fyc3RlbiBzYXlzOg0KDQogVGhlIGRlc2ln biBydWxlcyBmb3IgQ29BUCB3b3VsZCBwdXQgc3VjaCBhICJwcm90b2NvbCBmaWVsZCIgaW50byBh biBPcHRpb24gICh0eXBlIHVpbnQpIHRoYXQgd291bGQgYmUgc2VudCBiYWNrIHdpdGggdGhlIDQu MTMgcmVzcG9uc2UuIFRoaXMgd291bGQgYmUgIGFuIGVsZWN0aXZlIG9wdGlvbiwgYXMgdGhlIDQu MTMgcmVzcG9uc2UgaXMgc3RpbGwgdmFsaWQgaW5mb3JtYXRpb24gZXZlbiAgaWYgdGhlIG9wdGlv biBpcyBub3QgdW5kZXJzdG9vZC4NCg0KIE5vdywgd2UgYWxyZWFkeSBoYXZlIHR3byByZWxhdGVk IG1lY2hhbmlzbXMgaW4gLWJsb2NrOg0KDQogwrtUaGUgZXJyb3IgY29kZSA0LjEzIChSZXF1ZXN0 IEVudGl0eSBUb28gTGFyZ2UpIGNhbiBiZSByZXR1cm5lZCBhdCBhbnkgIHRpbWUgYnkgYSBzZXJ2 ZXIgdGhhdCBkb2VzIG5vdCBjdXJyZW50bHkgaGF2ZSB0aGUgcmVzb3VyY2VzIHRvIHN0b3JlICBi bG9ja3MgZm9yIGEgYmxvY2std2lzZSByZXF1ZXN0IHBheWxvYWQgdHJhbnNmZXIgdGhhdCBpdCB3 b3VsZCBpbnRlbmQgdG8gIGltcGxlbWVudCBpbiBhbiBhdG9taWMgZmFzaGlvbi4gIChOb3RlIHRo YXQgYSA0LjEzIHJlc3BvbnNlIHRvIGEgcmVxdWVzdCAgdGhhdCBkb2VzIG5vdCBlbXBsb3kgQmxv Y2sxIGlzIGEgaGludCBmb3IgdGhlIGNsaWVudCB0byB0cnkgc2VuZGluZyAgQmxvY2sxLCBhbmQg YSA0LjEzIHJlc3BvbnNlIHdpdGggYSBzbWFsbGVyIFNaWCBpbiBpdHMgQmxvY2sxIG9wdGlvbiB0 aGFuICByZXF1ZXN0ZWQgaXMgYSBoaW50IHRvIHRyeSBhIHNtYWxsZXIgU1pYLinCqw0KDQogU28g d2UgY2FuIHVzZSBTWlggaW4gQmxvY2sxIGZvciB0aGUgImRhdGFncmFtIHRvbyBsYXJnZSIgc2l0 dWF0aW9uLiAgU2luY2UgIHRoYXQgaXMgb25seSBzZW50IGZvciBhIHJlcXVlc3QgdGhhdCBzcGVj aWZpZWQgQmxvY2sxLCB0aGVyZSBtYXkgYmUgdHdvICBleGNoYW5nZXMgYmVmb3JlIGEgZ29vZCBk YXRhZ3JhbSBzaXplIGlzIGFycml2ZWQgYXQsIGlmIHRoZSByZXF1ZXN0aW5nICBlbmRwb2ludCBk b2VzIHN1cHBvcnQgQmxvY2sxLCB3aGljaCBpcyBzdWJvcHRpbWFsLCBidXQgcHJvYmFibHkgYWNj ZXB0YWJsZSAgZm9yIGEgbXVsdGktZXhjaGFuZ2UgQmxvY2sxIHRyYW5zZmVyLg0KDQogV2l0aCB0 aGUgQmxvY2sxIGNhc2UgdGFrZW4gY2FyZSBvZiwgd2Ugc3RpbGwgZG9uJ3QgaGF2ZSBhbnl0aGlu ZyB0byAgaW5kaWNhdGUgdGhlIGRlc2lyZWQgc2l6ZSBvZiB0aGUgKmVudGlyZSogcmVxdWVzdCBw YXlsb2FkLiAtYmxvY2sgZGVmaW5lcyAgYSBTaXplIG9wdGlvbiB0aGF0IGlzIHVzZWQgZm9yIGV4 Y2hhbmdpbmcgaW5mb3JtYXRpb24gYWJvdXQgcGF5bG9hZCBzaXplcy4NCiBUaGUgU2l6ZSBvcHRp b24gaXMgY3VycmVudGx5IGFydGZ1bGx5IHNwbGl0IGJldHdlZW4gcmVxdWVzdCBhbmQgcmVzcG9u c2UgIHNlbWFudGljcyBiYXNlZCBvbiB0aGUgcHJlc2VuY2Ugb2Ygb3RoZXIgb3B0aW9ucyBhbmQg c29tZSBoZXVyaXN0aWNzIChqdXN0ICBhcyBCbG9jayB3YXMgYmVmb3JlIGl0IHdhcyBzcGxpdCBp bnRvIEJsb2NrMSBhbmQgQmxvY2syKS4gIENhbiB3ZSBzaG9laG9ybiAgaW4gdGhlIHJlcXVpcmVk IHNlbWFudGljcywgZS5nLiBieSBnaXZpbmcgaXQgc3BlY2lhbCBzZW1hbnRpY3MgZm9yIHRoZQ0K IDQuMTMgY2FzZT8gIE9yIHNob3VsZCB0aGVyZSBiZSBhIFNpemUxIGFuZCBhIFNpemUyPw0KDQog QW5kLCBpbmRlcGVuZGVudCBvZiBob3cgZXhhY3RseSB3ZSBzb2x2ZSB0aGlzIHByb2JsZW0gd2l0 aCAtYmxvY2s6IElzIGl0IGEgIHJlcXVpcmVtZW50IHRoYXQgdGhpcyBtZWFuaW5nL3ZhcmlhbnQg b2YgU2l6ZSBiZSBpbmNsdWRlZCBpbiB0aGUgYmFzZSAgcHJvdG9jb2w/ICBPciBjYW4gd2Ugd2Fp dCB3aXRoIHRoaXMgZm9yIGEgY291cGxlIG9mIG1vbnRocyB1bnRpbCAtYmxvY2sgaXMgIGRvbmU/ DQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tDQog UmVwb3J0ZXI6ICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1jb3JlLWNv YXBAdG9vbHMuaWV0Zi5vcmcNCiAgY2Fib0B0emkub3JnICAgICAgICAgICB8ICAgICBTdGF0dXM6 ICBuZXcNCiAgICAgVHlwZTogIHByb3RvY29sICAgICB8ICBNaWxlc3RvbmU6ICBwb3N0LUlFU0ct MQ0KICBlbmhhbmNlbWVudCAgICAgICAgICAgIHwgICAgVmVyc2lvbjogIGNvYXAtMTcNCiBQcmlv cml0eTogIG1ham9yICAgICAgICB8ICAgS2V5d29yZHM6DQpDb21wb25lbnQ6ICBjb2FwICAgICAg ICAgfA0KIFNldmVyaXR5OiAgU3VibWl0dGVkICAgIHwNCiAgV0cgRG9jdW1lbnQgICAgICAgICAg ICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tDQoNClRp Y2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9jb3JlL3RyYWMvdGlja2V0 LzMzMT4NCmNvcmUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9jb3JlLz4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpj b3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1h aWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFu ZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2Us IGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3Nh Z2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVz c2FnZS4NCg== From isam.ishaq@intec.ugent.be Mon Jun 17 03:41:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A69721F9452 for ; Mon, 17 Jun 2013 03:41:51 -0700 (PDT) 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 VI4xuI2Iln0f for ; Mon, 17 Jun 2013 03:41:45 -0700 (PDT) Received: from smtp1.ugent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB621F9B90 for ; Mon, 17 Jun 2013 03:40:41 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp1.ugent.be (Postfix) with ESMTP id D586880A3 for ; Mon, 17 Jun 2013 12:40:39 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp1.ugent.be ([157.193.71.182]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 2Sr6ON8TL5Rq for ; Mon, 17 Jun 2013 12:40:36 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp1.ugent.be (Postfix) with ESMTP id 364E08073 for ; Mon, 17 Jun 2013 12:40:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 00A2D20 for ; Mon, 17 Jun 2013 12:40:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4vd-CPcHZbH for ; Mon, 17 Jun 2013 12:40:35 +0200 (CEST) Received: from [127.0.0.1] (visitors.ibbt.be [193.191.148.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: iishaq) by mail2.intec.ugent.be (Postfix) with ESMTPSA id A64FE1F for ; Mon, 17 Jun 2013 12:40:35 +0200 (CEST) Message-ID: <51BEE7A2.6000009@intec.ugent.be> Date: Mon, 17 Jun 2013 12:40:34 +0200 From: Isam Ishaq User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "core@ietf.org" References: <20130617093944.23608.83617.idtracker@ietfa.amsl.com> In-Reply-To: <20130617093944.23608.83617.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130617093944.23608.83617.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080604010409000608060006" X-Antivirus: avast! (VPS 130616-1, 06/16/2013), Outbound message X-Antivirus-Status: Clean X-Miltered: at jchkm1 with ID 51BEE7A3.007 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51BEE7A3.007 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51BEE7A3.007 on smtp1.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: [core] Fwd: New Version Notification for draft-ishaq-core-entities-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, 17 Jun 2013 10:41:53 -0000 This is a multi-part message in MIME format. --------------080604010409000608060006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear All, I have just submitted a new I-D that describes a format to create entities that can be used for group communication using CoAP unicast messages. The groupcomm I-D relies on multicasts for group communication. However, in some cases the use of multicast might be not feasible or provide a suboptimal solution. Therefore, in this I-D we propose an alternative unicast-based approach for communication with a group of resources across multiple nodes. Your feedback and suggestions for improvement are highly appreciated. Best Regards, Isam Ishaq -------- Original Message -------- Subject: New Version Notification for draft-ishaq-core-entities-00.txt Date: Mon, 17 Jun 2013 02:39:44 -0700 From: internet-drafts@ietf.org To: Floris Van den Abeele , Isam Ishaq , Jeroen Hoebeke A new version of I-D, draft-ishaq-core-entities-00.txt has been successfully submitted by Isam Ishaq and posted to the IETF repository. Filename: draft-ishaq-core-entities Revision: 00 Title: CoAP Entities Creation date: 2013-06-17 Group: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-ishaq-core-entities-00.txt Status: http://datatracker.ietf.org/doc/draft-ishaq-core-entities Htmlized: http://tools.ietf.org/html/draft-ishaq-core-entities-00 Abstract: This document describes a format to create entities that can be used for group communication using CoAP unicast messages. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. The IETF Secretariat --------------080604010409000608060006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear All,

I have just submitted a new I-D that describes a format to create entities that can be used for group communication using CoAP unicast messages.

The groupcomm I-D relies on multicasts for group communication. However, in some cases the use of multicast might be not feasible or provide a suboptimal solution. Therefore, in this I-D we propose an alternative unicast-based approach for communication with a group of resources across multiple nodes.

Your feedback  and suggestions for improvement are highly appreciated.

Best Regards,
Isam Ishaq


-------- Original Message --------
Subject: New Version Notification for draft-ishaq-core-entities-00.txt
Date: Mon, 17 Jun 2013 02:39:44 -0700
From: internet-drafts@ietf.org
To: Floris Van den Abeele <floris.vandenabeele@intec.ugent.be>, Isam Ishaq <isam.ishaq@intec.ugent.be>, Jeroen Hoebeke <jeroen.hoebeke@intec.ugent.be> 


A new version of I-D, draft-ishaq-core-entities-00.txt
has been successfully submitted by Isam Ishaq and posted to the
IETF repository.

Filename:	 draft-ishaq-core-entities
Revision:	 00
Title:		 CoAP Entities
Creation date:	 2013-06-17
Group:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-ishaq-core-entities-00.txt
Status:          http://datatracker.ietf.org/doc/draft-ishaq-core-entities
Htmlized:        http://tools.ietf.org/html/draft-ishaq-core-entities-00


Abstract:
   This document describes a format to create entities that can be used
   for group communication using CoAP unicast messages.

Note

   Discussion and suggestions for improvement are requested, and should
   be sent to core@ietf.org.

                                                                                  


The IETF Secretariat


--------------080604010409000608060006-- From cabo@tzi.org Mon Jun 17 09:35:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709D721F9D59 for ; Mon, 17 Jun 2013 09:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 v7puZxUHa15R for ; Mon, 17 Jun 2013 09:35:15 -0700 (PDT) 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 9F1D321F9D58 for ; Mon, 17 Jun 2013 09:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5HGYwfX017128; Mon, 17 Jun 2013 18:34:58 +0200 (CEST) Received: from [192.168.217.105] (p54893B55.dip0.t-ipconnect.de [84.137.59.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7F3A53C06; Mon, 17 Jun 2013 18:34:57 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Mon, 17 Jun 2013 18:34:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 16:35:21 -0000 > Agree, it looks like Martin's request is to have it solved in the base = draft. (Whether now or in a few months time.) Yes, and our job as a WG is to find out whether that is a reasonable = request and, if yes, implement it (or, if no, supply good arguments for = why not). > But of course the choice of a 'Size' option or 'Size1/Size2' options = solution may be linked to core-block which now defines the Size option. > An elective Size/Size* option would be best to solve this with minimal = complexity impact on the client. Right. So here is my proposal: -- We update -block to split Size into Size1 and Size2. The current text says: =BBThe Size Option may be used for three purposes: * in a request, to ask the server to provide a size estimate along with the usual response ("size request"). For this usage, the = value MUST be set to 0. * in a response carrying a Block2 Option, to indicate the current estimate the server has of the total size of the resource representation. * in a request carrying a Block1 Option, to indicate the current estimate the client has of the total size of the resource representation. In the latter two cases ("size indication"), the value of the option is the current estimate, measured in bytes. A size request can be easily distinguished from a size indication, = as the third case is not useful for a GET or DELETE, and an actual size indication of 0 would either be overridden by the actual size of the payload for a PUT or POST or would not be useful.=AB Adding the 4.13 feedback semantics as another special case to this slighly cluttered usage of a single is theoretically possible, but becomes harder and harder to justify. So, instead, we start to distinguish a Size1, which is always about the resource representation in the request, and Size2, which is always about the one in the response. Both are elective, safe-to-forward, no-cache-key. We can get rid of the "easily distinguished" text above. For handling the discuss, we only need Size1. I'm assuming most people who have implemented Size use it in Size2 semantics, so a minimum change addition to -block is: | Type | C | U | N | R | Name | Format | Length | Default | |------+---+---+---+---+-------+--------+--------+---------| | 60 | - | - | N | - | Size1 | uint | 0-4 B | (none) | | 28 | - | - | N | - | Size2 | uint | 0-4 B | (none) | (The somewhat weirdly high option number 60 =3D 0b1_111_00 results from us only allocating 1/8 of the safe-to-forward space to no-cache-key.) -- We introduce the Size1 option into the base spec. Add to table 4 in 5.10: | Type | C | U | N | R | Name | Format | Length | Default | |------+---+---+---+---+-------+--------+--------+---------| | 60 | | | x | | Size1 | uint | 0-4 | (none) | (Yes, we have to adopt the updated table notation from -coap in -block as well at some point.) Add a new section 5.10.9: The Size1 option provides size information about the resource representation in a request. The option value is an integer number of bytes. Its main use is with block-wise transfers [I-D.ietf-core-block]. In the present specification, it is used in 4.13 responses to indicate the maximum size of request entity that the server is able and willing to handle. Add to the end of 5.9.2.9. 4.13 Request Entity Too Large: The response SHOULD include a Size1 Option to indicate the maximum size of request entity the server is able and willing to handle, unless the server is not in a position to make this information available. oOo Is this the right thing to do? Is the SHOULD the right level of requirement? Do people think they would be implementing this? Are there any obstacles to implementation we haven't thought about? Gr=FC=DFe, Carsten From zach@sensinode.com Mon Jun 17 10:26:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5988221F9D80 for ; Mon, 17 Jun 2013 10:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyWzH+BUQo5j for ; Mon, 17 Jun 2013 10:26:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6379221F9D4C for ; Mon, 17 Jun 2013 10:26:37 -0700 (PDT) Received: from [172.20.10.4] (84-231-228-28.elisa-mobile.fi [84.231.228.28]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r5HHQKcx029208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 20:26:26 +0300 Content-Type: multipart/signed; boundary="Apple-Mail=_A745D1C1-3757-401A-BF45-86332481A7DD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> Date: Mon, 17 Jun 2013 20:26:19 +0300 Message-Id: References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 17:26:43 -0000 --Apple-Mail=_A745D1C1-3757-401A-BF45-86332481A7DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Regarding if this should be handled in the base CoAP specification or = Block=85. My strong preference would be to do this in Block, as it is = not useful (and could be confusing) in the base CoAP specification. I don't see any practical reasons or use cases for having a Size field = without the use of Block transfer. CoAP is a lock-step protocol with a = typical maximum message size of 1152 bytes. IPv6 devices are required to = support the minimum MTU, therefore there is really no use for size = feedback.=20 Now, I do see several applications with Block transfer, both when a node = prefers very small blocks to avoid 6LoWPAN fragmentation or when limited = buffer space is available for larger blocks. Considering the = interactions between Size1, Size2 and 4.13, that level of specification = is anyways best done in Block. Zach =20 On Jun 17, 2013, at 7:34 PM, Carsten Bormann wrote: >> Agree, it looks like Martin's request is to have it solved in the = base draft. (Whether now or in a few months time.) >=20 > Yes, and our job as a WG is to find out whether that is a reasonable = request and, if yes, implement it (or, if no, supply good arguments for = why not). >=20 >> But of course the choice of a 'Size' option or 'Size1/Size2' options = solution may be linked to core-block which now defines the Size option. >> An elective Size/Size* option would be best to solve this with = minimal complexity impact on the client. >=20 > Right. So here is my proposal: >=20 > -- We update -block to split Size into Size1 and Size2. >=20 > The current text says: >=20 > =BBThe Size Option may be used for three purposes: >=20 > * in a request, to ask the server to provide a size estimate along > with the usual response ("size request"). For this usage, the = value MUST be set to > 0. > * in a response carrying a Block2 Option, to indicate the current > estimate the server has of the total size of the resource > representation. > * in a request carrying a Block1 Option, to indicate the current > estimate the client has of the total size of the resource > representation. >=20 > In the latter two cases ("size indication"), the value of the = option > is the current estimate, measured in bytes. >=20 > A size request can be easily distinguished from a size indication, = as > the third case is not useful for a GET or DELETE, and an > actual size indication of 0 would either be overridden by the = actual > size of the payload for a PUT or POST or would not be useful.=AB >=20 > Adding the 4.13 feedback semantics as another special case to this > slighly cluttered usage of a single is theoretically possible, but > becomes harder and harder to justify. >=20 > So, instead, we start to distinguish a Size1, which is always about > the resource representation in the request, and Size2, which is always > about the one in the response. Both are elective, safe-to-forward, > no-cache-key. We can get rid of the "easily distinguished" text = above. >=20 > For handling the discuss, we only need Size1. > I'm assuming most people who have implemented Size use it in Size2 > semantics, so a minimum change addition to -block is: >=20 > | Type | C | U | N | R | Name | Format | Length | Default | > |------+---+---+---+---+-------+--------+--------+---------| > | 60 | - | - | N | - | Size1 | uint | 0-4 B | (none) | > | 28 | - | - | N | - | Size2 | uint | 0-4 B | (none) | >=20 > (The somewhat weirdly high option number 60 =3D 0b1_111_00 results = from > us only allocating 1/8 of the safe-to-forward space to no-cache-key.) >=20 > -- We introduce the Size1 option into the base spec. >=20 > Add to table 4 in 5.10: >=20 >=20 > | Type | C | U | N | R | Name | Format | Length | Default | > |------+---+---+---+---+-------+--------+--------+---------| > | 60 | | | x | | Size1 | uint | 0-4 | (none) | >=20 > (Yes, we have to adopt the updated table notation from -coap in -block > as well at some point.) >=20 > Add a new section 5.10.9: >=20 > The Size1 option provides size information about the resource > representation in a request. The option value is an integer number of > bytes. Its main use is with block-wise transfers > [I-D.ietf-core-block]. In the present specification, it is used in > 4.13 responses to indicate the maximum size of request entity that the > server is able and willing to handle. >=20 > Add to the end of 5.9.2.9. 4.13 Request Entity Too Large: >=20 > The response SHOULD include a Size1 Option to indicate the maximum > size of request entity the server is able and willing to handle, > unless the server is not in a position to make this information > available. >=20 >=20 > oOo >=20 > Is this the right thing to do? > Is the SHOULD the right level of requirement? > Do people think they would be implementing this? > Are there any obstacles to implementation we haven't thought about? >=20 > Gr=FC=DFe, Carsten >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net --Apple-Mail=_A745D1C1-3757-401A-BF45-86332481A7DD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw ggRLoAMCAQICECoFEeuyI56VQvKTVfGMSkAwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjEyMDgwMDAwMDBaFw0x MzEyMDgyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9XHvgVWAUvzoGUuYXHRSH2qT6vjO T31W2uFGX4wmCZskhrghMWrKYdosjugUlnIml+tsNlGaT7ZVPrURpJrAmlMwj9ViL+qvLd56RZqM T1sGMX2w0rCGAVWJK2AWy8J8Oub/xaiZ+MdR0LQCli0BeO9GNPEM/2kEvIOtzxjFLtyKHe7eNf5q yB2n9TWvJ/kYvhIaFAFvib8E9A705fLwu0z/mW3CBl/XLouFlPDBc0s/5CKl9+5DFya6tudTTqex xLx6rTqqKznyHdj+8PrnHTWvRtPcxucyMOoNXJQaxNtY5oZh7inZd20n/OVkZLhp/mI5p9eTziXq /iyKYxvylwIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA5OcugibLpuXR75zXjKYtS5De MSQxi/YpIE2xjS5zkLPsHSs8gVLRtiyoU+akbSguYN3f0gjEeABFz2s+BHLEWqYgREQmCC/YWVuj nvXYR7lIccC4woyWY5L0FXygx6nibxm+SlWOo1GVV77gF7BiO8PKcfZmaRYcr49u1Miov/R8fnFh 15/HmVG6/V2URo7Z6F+ZTvxvZA//O4rQgTd2hBBefs9A4jU3HYXKuYcCly8haQNvqSLUc4m67sIJ oZVO+YH/WwgiMimpA+VdJTyfJDOFdIEQsnjPHUNBzHdfg7qQwgfV/1i0fHi+w1guDXM7CGWdgrg/ GIc/dm71plzFGDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7 btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4 mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9 OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1 qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxKQDAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTcx NzI2MTlaMCMGCSqGSIb3DQEJBDEWBBSfe4ad7rCvNGwiwhqHBEC7Q+71jTCCAQMGCSsGAQQBgjcQ BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEczAhAqBRHrsiOelULyk1XxjEpAMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxK QDANBgkqhkiG9w0BAQEFAASCAQAOduL1F51tEZOypUv4HxaaLCG//uCUZW7CFyaXdBkwgXWap1P5 BPIqzxqh8oWApOkJTJcEiLmoR3RZfcdh6uhozZjBR8LxJN5U33X+MABap1A+DhJTRhndsgMw/CDO dMMRBm2zuhR0FyL6d34hRqSZWd5SDxxH6pOpXqzH26Aqo0e8ElIhb8YKsmwKl97WGdtcyYjGyyIy UEIkBBl+kRxUcbitYbqgJiXNL426ENjiRFd0lylZUYtdobz9rPdvbl0jrk7E+teL2EHtOmOaEM3i FoAlpFteYD1dqibhbJR2JXi5x9vwId41FowCfYICzMNziTtTcaowEpd5geSi5eAFAAAAAAAA --Apple-Mail=_A745D1C1-3757-401A-BF45-86332481A7DD-- From Akbar.Rahman@InterDigital.com Mon Jun 17 12:30:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0E21F9B79 for ; Mon, 17 Jun 2013 12:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SAVELE=2.3] 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 lKFJ6q43eE9A for ; Mon, 17 Jun 2013 12:30:36 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id DC63B21F9B5E for ; Mon, 17 Jun 2013 12:30:32 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 15:30:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2013 15:30:30 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: Ac5rf+jBwrPWMvMCTs2yRyku62glfQADtT2A References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> From: "Rahman, Akbar" To: "Zach Shelby" X-OriginalArrivalTime: 17 Jun 2013 19:30:31.0282 (UTC) FILETIME=[21436D20:01CE6B91] Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 19:30:40 -0000 Hi Zach, Just to clarify and sync with you. I understood that Martin's 4.13 = related comment was made on section 4.6 (Message Size) which is where = the 4.13 processing is discussed (in an Implementation Note). In that = section it says: =20 "Implementations receiving a datagram into a buffer that is too small are usually able to determine if the trailing portion of a datagram was discarded and to retrieve the initial portion. So, if not all of the payload, at least the CoAP header and options are likely to fit within the buffer. A server can thus fully interpret a request and return a 4.13 (Request Entity Too Large, see Section 5.9.2.9) response code if the payload was truncated. A client sending an idempotent request and receiving a response larger than would fit in the buffer can repeat the request with a suitable value for the Block Option [I-D.ietf-core-block]." Then Martin goes on to suggest that: "The 4.13 "Request Entity Too Large" with a protocol field that = indicates the maximum data size would be fixing this." So, actually, according to the current text it does seem like you could = have a problem before Block was invoked. Do you agree? Best Regards, Akbar -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Monday, June 17, 2013 1:26 PM To: Carsten Bormann Cc: Dijk, Esko; Rahman, Akbar; draft-ietf-core-coap@tools.ietf.org; = trac+core@trac.tools.ietf.org; core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 = error Regarding if this should be handled in the base CoAP specification or = Block.... My strong preference would be to do this in Block, as it is = not useful (and could be confusing) in the base CoAP specification. I don't see any practical reasons or use cases for having a Size field = without the use of Block transfer. CoAP is a lock-step protocol with a = typical maximum message size of 1152 bytes. IPv6 devices are required to = support the minimum MTU, therefore there is really no use for size = feedback.=20 Now, I do see several applications with Block transfer, both when a node = prefers very small blocks to avoid 6LoWPAN fragmentation or when limited = buffer space is available for larger blocks. Considering the = interactions between Size1, Size2 and 4.13, that level of specification = is anyways best done in Block. Zach =20 On Jun 17, 2013, at 7:34 PM, Carsten Bormann wrote: >> Agree, it looks like Martin's request is to have it solved in the = base draft. (Whether now or in a few months time.) >=20 > Yes, and our job as a WG is to find out whether that is a reasonable = request and, if yes, implement it (or, if no, supply good arguments for = why not). >=20 >> But of course the choice of a 'Size' option or 'Size1/Size2' options = solution may be linked to core-block which now defines the Size option. >> An elective Size/Size* option would be best to solve this with = minimal complexity impact on the client. >=20 > Right. So here is my proposal: >=20 > -- We update -block to split Size into Size1 and Size2. >=20 > The current text says: >=20 > =BBThe Size Option may be used for three purposes: >=20 > * in a request, to ask the server to provide a size estimate along > with the usual response ("size request"). For this usage, the = value MUST be set to > 0. > * in a response carrying a Block2 Option, to indicate the current > estimate the server has of the total size of the resource > representation. > * in a request carrying a Block1 Option, to indicate the current > estimate the client has of the total size of the resource > representation. >=20 > In the latter two cases ("size indication"), the value of the = option > is the current estimate, measured in bytes. >=20 > A size request can be easily distinguished from a size indication, = as > the third case is not useful for a GET or DELETE, and an > actual size indication of 0 would either be overridden by the = actual > size of the payload for a PUT or POST or would not be useful.=AB >=20 > Adding the 4.13 feedback semantics as another special case to this > slighly cluttered usage of a single is theoretically possible, but > becomes harder and harder to justify. >=20 > So, instead, we start to distinguish a Size1, which is always about > the resource representation in the request, and Size2, which is always > about the one in the response. Both are elective, safe-to-forward, > no-cache-key. We can get rid of the "easily distinguished" text = above. >=20 > For handling the discuss, we only need Size1. > I'm assuming most people who have implemented Size use it in Size2 > semantics, so a minimum change addition to -block is: >=20 > | Type | C | U | N | R | Name | Format | Length | Default | > |------+---+---+---+---+-------+--------+--------+---------| > | 60 | - | - | N | - | Size1 | uint | 0-4 B | (none) | > | 28 | - | - | N | - | Size2 | uint | 0-4 B | (none) | >=20 > (The somewhat weirdly high option number 60 =3D 0b1_111_00 results = from > us only allocating 1/8 of the safe-to-forward space to no-cache-key.) >=20 > -- We introduce the Size1 option into the base spec. >=20 > Add to table 4 in 5.10: >=20 >=20 > | Type | C | U | N | R | Name | Format | Length | Default | > |------+---+---+---+---+-------+--------+--------+---------| > | 60 | | | x | | Size1 | uint | 0-4 | (none) | >=20 > (Yes, we have to adopt the updated table notation from -coap in -block > as well at some point.) >=20 > Add a new section 5.10.9: >=20 > The Size1 option provides size information about the resource > representation in a request. The option value is an integer number of > bytes. Its main use is with block-wise transfers > [I-D.ietf-core-block]. In the present specification, it is used in > 4.13 responses to indicate the maximum size of request entity that the > server is able and willing to handle. >=20 > Add to the end of 5.9.2.9. 4.13 Request Entity Too Large: >=20 > The response SHOULD include a Size1 Option to indicate the maximum > size of request entity the server is able and willing to handle, > unless the server is not in a position to make this information > available. >=20 >=20 > oOo >=20 > Is this the right thing to do? > Is the SHOULD the right level of requirement? > Do people think they would be implementing this? > Are there any obstacles to implementation we haven't thought about? >=20 > Gr=FC=DFe, Carsten >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From cabo@tzi.org Mon Jun 17 12:32:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC9621E8053 for ; Mon, 17 Jun 2013 12:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.193 X-Spam-Level: X-Spam-Status: No, score=-106.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 iiIZfuro8DK5 for ; Mon, 17 Jun 2013 12:32:26 -0700 (PDT) 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 51BA321E8054 for ; Mon, 17 Jun 2013 12:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5HJWLwx020375; Mon, 17 Jun 2013 21:32:21 +0200 (CEST) Received: from [192.168.217.135] (p54893B55.dip0.t-ipconnect.de [84.137.59.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6AFE73CCB; Mon, 17 Jun 2013 21:32:21 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 17 Jun 2013 21:32:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 19:32:33 -0000 On Jun 17, 2013, at 21:30, "Rahman, Akbar" = wrote: > you could have a problem before Block was invoked Yes, but how would you solve it except by using Block or a block-like = protocol? Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Mon Jun 17 12:43:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203CD21F9E0C for ; Mon, 17 Jun 2013 12:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599] 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 ZtavNGsxi7Qb for ; Mon, 17 Jun 2013 12:43:39 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id C58B621F9E00 for ; Mon, 17 Jun 2013 12:43:39 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 15:43:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2013 15:43:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: Ac5rkXou5oSYL/7vSKadHl+b/K2d/gAAFkbQ References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 17 Jun 2013 19:43:38.0486 (UTC) FILETIME=[F6793960:01CE6B92] Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 19:43:49 -0000 Well, at least the Client could stop trying to re-send the payload if it = knew the maximum allowable size of the payload but was not willing/able = to reduce it. This would at least throttles (stops) the transaction = that was causing congestion. That is of course the simplest (brute = force) flow control mechanism you can design. =20 But it at least solves one end of the spectrum of flow control that = Martin was worried about. The more sophisticated solution of course = will be in Block but the point is that is that the base CoAP spec should = be self-consistent and not require Block to at least stop simple = congestion scenarios. Best Regards, Akbar -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Monday, June 17, 2013 3:32 PM To: Rahman, Akbar Cc: Zach Shelby; Dijk, Esko; draft-ietf-core-coap@tools.ietf.org; = trac+core@trac.tools.ietf.org; core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 = error On Jun 17, 2013, at 21:30, "Rahman, Akbar" = wrote: > you could have a problem before Block was invoked Yes, but how would you solve it except by using Block or a block-like = protocol? Gr=FC=DFe, Carsten From cabo@tzi.org Mon Jun 17 13:19:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7421F9D5C for ; Mon, 17 Jun 2013 13:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.195 X-Spam-Level: X-Spam-Status: No, score=-106.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 PrlZP6dW9X8S for ; Mon, 17 Jun 2013 13:19:23 -0700 (PDT) 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 C147221F9D48 for ; Mon, 17 Jun 2013 13:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5HKJIJ9010951; Mon, 17 Jun 2013 22:19:18 +0200 (CEST) Received: from [192.168.217.135] (p54893B55.dip0.t-ipconnect.de [84.137.59.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 920423CF7; Mon, 17 Jun 2013 22:19:17 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 17 Jun 2013 22:19:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 20:19:29 -0000 On Jun 17, 2013, at 21:43, "Rahman, Akbar" = wrote: > Well, at least the Client could stop trying to re-send the payload if = it knew the maximum allowable size of the payload but was not = willing/able to reduce it. =20 That is already covered by 4.13 as it is -- after all the client has = received an error and has no reason to believe a retry will fix it (that = is the general semantics of a 4.xx). Adding a Size option would allow the client to re-try while reducing the = request payload size based on information from the server. But, I'm still curious: what would be the use case for such a reduction = outside of a block-wise protocol? Gr=FC=DFe, Carsten From zach@sensinode.com Mon Jun 17 13:30:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4046A21F9D64 for ; Mon, 17 Jun 2013 13:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAKuCGeSHVV5 for ; Mon, 17 Jun 2013 13:30:10 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9D21F9E12 for ; Mon, 17 Jun 2013 13:30:08 -0700 (PDT) Received: from [192.168.1.102] (188-67-21-191.bb.dnainternet.fi [188.67.21.191]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r5HKTrnD000651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 23:29:55 +0300 Content-Type: multipart/signed; boundary="Apple-Mail=_05351A4A-B6D3-4D1A-9B89-51E50D839EC9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Mon, 17 Jun 2013 23:29:52 +0300 Message-Id: References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 20:30:14 -0000 --Apple-Mail=_05351A4A-B6D3-4D1A-9B89-51E50D839EC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 17, 2013, at 11:19 PM, Carsten Bormann wrote: > On Jun 17, 2013, at 21:43, "Rahman, Akbar" = wrote: >=20 >> Well, at least the Client could stop trying to re-send the payload if = it knew the maximum allowable size of the payload but was not = willing/able to reduce it. =20 >=20 > That is already covered by 4.13 as it is -- after all the client has = received an error and has no reason to believe a retry will fix it (that = is the general semantics of a 4.xx). >=20 > Adding a Size option would allow the client to re-try while reducing = the request payload size based on information from the server. >=20 > But, I'm still curious: what would be the use case for such a = reduction outside of a block-wise protocol? That is exactly my point, I haven't been able to find a use case for = this (size) without block.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net --Apple-Mail=_05351A4A-B6D3-4D1A-9B89-51E50D839EC9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw ggRLoAMCAQICECoFEeuyI56VQvKTVfGMSkAwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjEyMDgwMDAwMDBaFw0x MzEyMDgyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9XHvgVWAUvzoGUuYXHRSH2qT6vjO T31W2uFGX4wmCZskhrghMWrKYdosjugUlnIml+tsNlGaT7ZVPrURpJrAmlMwj9ViL+qvLd56RZqM T1sGMX2w0rCGAVWJK2AWy8J8Oub/xaiZ+MdR0LQCli0BeO9GNPEM/2kEvIOtzxjFLtyKHe7eNf5q yB2n9TWvJ/kYvhIaFAFvib8E9A705fLwu0z/mW3CBl/XLouFlPDBc0s/5CKl9+5DFya6tudTTqex xLx6rTqqKznyHdj+8PrnHTWvRtPcxucyMOoNXJQaxNtY5oZh7inZd20n/OVkZLhp/mI5p9eTziXq /iyKYxvylwIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA5OcugibLpuXR75zXjKYtS5De MSQxi/YpIE2xjS5zkLPsHSs8gVLRtiyoU+akbSguYN3f0gjEeABFz2s+BHLEWqYgREQmCC/YWVuj nvXYR7lIccC4woyWY5L0FXygx6nibxm+SlWOo1GVV77gF7BiO8PKcfZmaRYcr49u1Miov/R8fnFh 15/HmVG6/V2URo7Z6F+ZTvxvZA//O4rQgTd2hBBefs9A4jU3HYXKuYcCly8haQNvqSLUc4m67sIJ oZVO+YH/WwgiMimpA+VdJTyfJDOFdIEQsnjPHUNBzHdfg7qQwgfV/1i0fHi+w1guDXM7CGWdgrg/ GIc/dm71plzFGDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7 btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4 mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9 OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1 qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxKQDAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTcy MDI5NTNaMCMGCSqGSIb3DQEJBDEWBBSfLZKUdWdD/b6qthv1e/uds02r/DCCAQMGCSsGAQQBgjcQ BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEczAhAqBRHrsiOelULyk1XxjEpAMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxK QDANBgkqhkiG9w0BAQEFAASCAQAinYsjNC4P295ZheaHZ67+8SspBNnvQ0UT9JJhlc15uv0y+ZPP Ql9goMrmUNyZVhYKw73TatuXbEbhF2Dzl5OZPa8ZoX51UBt24mNdGyysCG7NpdQ4Qqh+vEAOSnTU 71bTMESrIr4lUuzFu8bmId60xAnzOerAbXWGmL3HuLJygNAIhvUmEGJE9WaNKy2KtUnl9US4R6mL if1Wa/IpKl+/wR+/0WLPAhQnkLP2VliD+o3bJLjxWc28QfWQL5NULgSA+tkBvv2qsjPiyBVjtbiO mgDyL6lE/fZ/BUqloNWC4Eg3ZLvL2Z8MtKOM+v1AGgip9n7+3TqKE5wqsP02lDFiAAAAAAAA --Apple-Mail=_05351A4A-B6D3-4D1A-9B89-51E50D839EC9-- From Akbar.Rahman@InterDigital.com Mon Jun 17 13:38:04 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00F221F8EB3 for ; Mon, 17 Jun 2013 13:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] 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 4+D20Bdw+qUW for ; Mon, 17 Jun 2013 13:37:55 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D259221F9DB4 for ; Mon, 17 Jun 2013 13:37:54 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 16:37:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2013 16:37:52 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: Ac5rmAirpKrvnLGtRoeVgQbCuWqZsgAAd6Qg References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 17 Jun 2013 20:37:53.0533 (UTC) FILETIME=[8AA1FAD0:01CE6B9A] Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 17 Jun 2013 20:38:04 -0000 There is nothing in the current text (I think) to stop a silly client = from retrying to send the payload (with old-size -1) after receiving a = 4.13 error (and then keep looping if that also results in another 4.13 = error). I think we have all seen silly implementations like this in = other protocol implementations. =20 I am not trying to justify this behavior, I am just saying that this is = what I think that Martin means by a simple fix. -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Monday, June 17, 2013 4:19 PM To: Rahman, Akbar Cc: Zach Shelby; Dijk, Esko; draft-ietf-core-coap@tools.ietf.org; = trac+core@trac.tools.ietf.org; core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 = error On Jun 17, 2013, at 21:43, "Rahman, Akbar" = wrote: > Well, at least the Client could stop trying to re-send the payload if = it knew the maximum allowable size of the payload but was not = willing/able to reduce it. =20 That is already covered by 4.13 as it is -- after all the client has = received an error and has no reason to believe a retry will fix it (that = is the general semantics of a 4.xx). Adding a Size option would allow the client to re-try while reducing the = request payload size based on information from the server. But, I'm still curious: what would be the use case for such a reduction = outside of a block-wise protocol? Gr=FC=DFe, Carsten From esko.dijk@philips.com Mon Jun 17 22:56:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5873021F92FC for ; Mon, 17 Jun 2013 22:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 rQ9dyTftFB6o for ; Mon, 17 Jun 2013 22:55:56 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6C21F909A for ; Mon, 17 Jun 2013 22:55:52 -0700 (PDT) Received: from mail156-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE040.bigfish.com (10.243.66.105) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 05:55:51 +0000 Received: from mail156-co1 (localhost [127.0.0.1]) by mail156-co1-R.bigfish.com (Postfix) with ESMTP id 7B9FFA40247; Tue, 18 Jun 2013 05:55:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(z10d0kz98dI15d6O9371I542I1432I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah1954cbh8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail156-co1 (localhost.localdomain [127.0.0.1]) by mail156-co1 (MessageSwitch) id 1371534949694643_17824; Tue, 18 Jun 2013 05:55:49 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.228]) by mail156-co1.bigfish.com (Postfix) with ESMTP id 9D0C3DC0070; Tue, 18 Jun 2013 05:55:49 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Jun 2013 05:55:49 +0000 Received: from 011-DB3MMR1-012.MGDPHG.emi.philips.com (10.128.28.96) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 18 Jun 2013 05:57:25 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.190]) by 011-DB3MMR1-012.MGDPHG.emi.philips.com ([10.128.28.96]) with mapi id 14.02.0328.011; Tue, 18 Jun 2013 05:55:47 +0000 From: "Dijk, Esko" To: Zach Shelby , Carsten Bormann Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: AQHOavCHQ3fUK6vnakKCWJpCEZE4gZk5bikwgACtKQCAAA5bgIAAIrIAgAAAhACAAAMngIAACfSAgAAC+ACAAJzDoA== Date: Tue, 18 Jun 2013 05:55:47 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C75950@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.201.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "draft-ietf-core-coap@tools.ietf.org" , "trac+core@trac.tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 18 Jun 2013 05:56:00 -0000 Use cases can always be found ;) One is a client using the "Batch" concept from core-interfaces (http://tool= s.ietf.org/html/draft-ietf-core-interfaces-00#section-5.2 ) to update (PUT)= multiple resources. A 4.13 is returned, so the client decides to update th= e individual resources with multiple PUTs instead. Esko -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Monday, June 17, 2013 22:30 To: Carsten Bormann Cc: Rahman, Akbar; Dijk, Esko; draft-ietf-core-coap@tools.ietf.org; trac+co= re@trac.tools.ietf.org; core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error On Jun 17, 2013, at 11:19 PM, Carsten Bormann wrote: > On Jun 17, 2013, at 21:43, "Rahman, Akbar" wrote: > >> Well, at least the Client could stop trying to re-send the payload if it= knew the maximum allowable size of the payload but was not willing/able to= reduce it. > > That is already covered by 4.13 as it is -- after all the client has rece= ived an error and has no reason to believe a retry will fix it (that is the= general semantics of a 4.xx). > > Adding a Size option would allow the client to re-try while reducing the = request payload size based on information from the server. > > But, I'm still curious: what would be the use case for such a reduction o= utside of a block-wise protocol? That is exactly my point, I haven't been able to find a use case for this (= size) without block. Zach -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net ________________________________ 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 Mon Jun 17 23:10:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9B21F8168 for ; Mon, 17 Jun 2013 23:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ur-enZfhieR for ; Mon, 17 Jun 2013 23:10:34 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id F36B121F9104 for ; Mon, 17 Jun 2013 23:10:32 -0700 (PDT) Received: from [10.128.9.218] (line-21396.dyn.kponet.fi [213.145.192.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r5I6AOV3018042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 09:10:25 +0300 Content-Type: multipart/signed; boundary="Apple-Mail=_A59489DD-3566-41E6-A314-831B079CE589"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C75950@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Tue, 18 Jun 2013 09:10:24 +0300 Message-Id: References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> <031DD135F9160444ABBE3B0C36CED618C75950@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1503) Cc: "draft-ietf-core-coap@tools.ietf.org" , "trac+core@trac.tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 18 Jun 2013 06:10:38 -0000 --Apple-Mail=_A59489DD-3566-41E6-A314-831B079CE589 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 18, 2013, at 8:55 AM, "Dijk, Esko" wrote: > One is a client using the "Batch" concept from core-interfaces = (http://tools.ietf.org/html/draft-ietf-core-interfaces-00#section-5.2 ) = to update (PUT) multiple resources. A 4.13 is returned, so the client = decides to update the individual resources with multiple PUTs instead. But why would the endpoint even support the Batch resource type and a = batch media type such as SenML if it can't process it? Instead the = endpoint would only make individual text/plain resources available in = the first place, so the client knows not to try and use Batch.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net --Apple-Mail=_A59489DD-3566-41E6-A314-831B079CE589 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw ggRLoAMCAQICECoFEeuyI56VQvKTVfGMSkAwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjEyMDgwMDAwMDBaFw0x MzEyMDgyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9XHvgVWAUvzoGUuYXHRSH2qT6vjO T31W2uFGX4wmCZskhrghMWrKYdosjugUlnIml+tsNlGaT7ZVPrURpJrAmlMwj9ViL+qvLd56RZqM T1sGMX2w0rCGAVWJK2AWy8J8Oub/xaiZ+MdR0LQCli0BeO9GNPEM/2kEvIOtzxjFLtyKHe7eNf5q yB2n9TWvJ/kYvhIaFAFvib8E9A705fLwu0z/mW3CBl/XLouFlPDBc0s/5CKl9+5DFya6tudTTqex xLx6rTqqKznyHdj+8PrnHTWvRtPcxucyMOoNXJQaxNtY5oZh7inZd20n/OVkZLhp/mI5p9eTziXq /iyKYxvylwIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA5OcugibLpuXR75zXjKYtS5De MSQxi/YpIE2xjS5zkLPsHSs8gVLRtiyoU+akbSguYN3f0gjEeABFz2s+BHLEWqYgREQmCC/YWVuj nvXYR7lIccC4woyWY5L0FXygx6nibxm+SlWOo1GVV77gF7BiO8PKcfZmaRYcr49u1Miov/R8fnFh 15/HmVG6/V2URo7Z6F+ZTvxvZA//O4rQgTd2hBBefs9A4jU3HYXKuYcCly8haQNvqSLUc4m67sIJ oZVO+YH/WwgiMimpA+VdJTyfJDOFdIEQsnjPHUNBzHdfg7qQwgfV/1i0fHi+w1guDXM7CGWdgrg/ GIc/dm71plzFGDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7 btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4 mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9 OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1 qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxKQDAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MTgw NjEwMjVaMCMGCSqGSIb3DQEJBDEWBBSu+foPuUW/9d7fiU2FhVZB4bsilDCCAQMGCSsGAQQBgjcQ BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEczAhAqBRHrsiOelULyk1XxjEpAMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQKgUR67IjnpVC8pNV8YxK QDANBgkqhkiG9w0BAQEFAASCAQCno88qhUX+/1+2csPWIEvbZkLd86mksb/en06qEi/15SvcJYfb bjHVFss6xfLpXzlX6qEKE//CbYZHjvkQy723+H8IQ4bNVADJg6+y1mAPu6A6PwLoeFIxTwj1rSLE q2x5HbnBwyg2hXETh2BHOpbh0RIBbcy3clkGuVk81Z/P2R83WvHQI/NXLgMvNx1LPyW70A+7hlrX yNEgKbyjbGSA4ufeiUPwyl7ghZiIcXplshOtljoo20ILyVgzmjFAiJvvz8fEDqyGVx+U1BtyZke3 XXpUISf7iZ0MhPPFx+4eLArb/x0jm8LsQ2ySKc3MDCH0o8+rhGY8Q6vNkt1Sde+PAAAAAAAA --Apple-Mail=_A59489DD-3566-41E6-A314-831B079CE589-- From esko.dijk@philips.com Mon Jun 17 23:29:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5513321F9A44 for ; Mon, 17 Jun 2013 23:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=-2.566, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] 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 Ofkh8REr5+vq for ; Mon, 17 Jun 2013 23:29:19 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id B401021F8EB3 for ; Mon, 17 Jun 2013 23:29:18 -0700 (PDT) Received: from mail95-db9-R.bigfish.com (10.174.16.226) by DB9EHSOBE029.bigfish.com (10.174.14.92) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 06:29:17 +0000 Received: from mail95-db9 (localhost [127.0.0.1]) by mail95-db9-R.bigfish.com (Postfix) with ESMTP id 420B93000B6; Tue, 18 Jun 2013 06:29:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(z10d0kz98dI15d6O9371I542I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah1954cbh8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail95-db9 (localhost.localdomain [127.0.0.1]) by mail95-db9 (MessageSwitch) id 1371536954895849_8939; Tue, 18 Jun 2013 06:29:14 +0000 (UTC) Received: from DB9EHSMHS022.bigfish.com (unknown [10.174.16.248]) by mail95-db9.bigfish.com (Postfix) with ESMTP id D17A860048; Tue, 18 Jun 2013 06:29:14 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB9EHSMHS022.bigfish.com (10.174.14.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Jun 2013 06:29:14 +0000 Received: from 011-DB3MMR1-016.MGDPHG.emi.philips.com (10.128.28.100) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 18 Jun 2013 06:30:52 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.190]) by 011-DB3MMR1-016.MGDPHG.emi.philips.com ([10.128.28.100]) with mapi id 14.02.0328.011; Tue, 18 Jun 2013 06:30:51 +0000 From: "Dijk, Esko" To: Zach Shelby Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: AQHOavCHQ3fUK6vnakKCWJpCEZE4gZk5bikwgACtKQCAAA5bgIAAIrIAgAAAhACAAAMngIAACfSAgAAC+ACAAJzDoIAABXAAgAADBDA= Date: Tue, 18 Jun 2013 06:29:13 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C769C2@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> <031DD135F9160444ABBE3B0C36CED618C75950@011-DB3MPN2-083.MGDPHG.emi.philips.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: [92.69.201.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "draft-ietf-core-coap@tools.ietf.org" , "trac+core@trac.tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 18 Jun 2013 06:29:23 -0000 My approach is to let's think of the best use cases we can find for this si= tuation and then see whether they make sense. (If not, no solution to the p= roblem is needed probably?) The server in this use case would support batch of course, but it has a buf= fer size that is smaller (e.g. 768 bytes) than the size the client expects = (e.g. 1024 bytes payload size based on IPv6 MTU). The batching of resources works as long as the CoAP request payload is 768 = bytes or less. Normally it's used to batch only small resources. But, now t= he client, not knowing the 768 byte limit, simply puts a few more large ent= ries in the batch request, so the request payload size grows above this lim= it to e.g. 1000 bytes. Then, the server would presumably (http://tools.ietf.org/html/draft-ietf-co= re-coap-17#section-4.6) return a 4.13 response. To me this sounds like a situation that could very well happen. And there's= no mandate in CoAP to use core-block if payload size exceed ~ 100 bytes. Esko -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Tuesday, June 18, 2013 08:10 To: Dijk, Esko Cc: Carsten Bormann; Rahman, Akbar; draft-ietf-core-coap@tools.ietf.org; tr= ac+core@trac.tools.ietf.org; core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error On Jun 18, 2013, at 8:55 AM, "Dijk, Esko" wrote: > One is a client using the "Batch" concept from core-interfaces (http://to= ols.ietf.org/html/draft-ietf-core-interfaces-00#section-5.2 ) to update (PU= T) multiple resources. A 4.13 is returned, so the client decides to update = the individual resources with multiple PUTs instead. But why would the endpoint even support the Batch resource type and a batch= media type such as SenML if it can't process it? Instead the endpoint woul= d only make individual text/plain resources available in the first place, s= o the client knows not to try and use Batch. Zach -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net ________________________________ 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 cabo@tzi.org Fri Jun 21 06:29:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485D721F9E33 for ; Fri, 21 Jun 2013 06:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 DHWJoAjlxVGR for ; Fri, 21 Jun 2013 06:28:46 -0700 (PDT) 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 2158511E818A for ; Fri, 21 Jun 2013 06:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5LDSVhQ004269; Fri, 21 Jun 2013 15:28:31 +0200 (CEST) Received: from [192.168.217.135] (p5489351C.dip0.t-ipconnect.de [84.137.53.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6125F75E3; Fri, 21 Jun 2013 15:28:31 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C769C2@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Fri, 21 Jun 2013 15:21:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> <031DD135F9160444ABBE3B0C36CED618C75950@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618C769C2@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1508) Cc: "draft-ietf-core-coap@tools.ietf.org" , "core@ietf.org" , "trac+core@trac.tools.ietf.org" Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 21 Jun 2013 13:29:09 -0000 My personal summary of the conversation on this ticket so far: -- We don't have consensus that the solution solves a particularly = prominent use case. -- We don't have consensus that it is entirely useless either. -- Some of the discussion was about whether we do it now or in -block, = which is just a matter of procedure. -- Nobody has commented on the specific solution I have proposed. Given that this is one of the two remaining issues blocking CoAP from = becoming RFC, I'm inclined to just make the change. But I'd like to = hear a bit more about whether the other elements of the proposed change = (the ones that also influence -block) are right: -- Splitting Size into Size1 and Size2 (and removing some of the = heuristic stuff that we need without that); -- Using Size1 not only in a request to indicate the projected size of = the request body, but also in a 4.13 response to indicate the maximum = accepted size. I would like to submit -18 very soon, so I would be happy with some = quick responses, even if they are only temperature readings. Gr=FC=DFe, Carsten From cabo@tzi.org Fri Jun 21 06:34:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB4521E8123 for ; Fri, 21 Jun 2013 06:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.207 X-Spam-Level: X-Spam-Status: No, score=-106.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 Ii1N7IUyKsMa for ; Fri, 21 Jun 2013 06:34:00 -0700 (PDT) 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 A903E21E811E for ; Fri, 21 Jun 2013 06:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5LDXqJo014738; Fri, 21 Jun 2013 15:33:52 +0200 (CEST) Received: from [192.168.217.135] (p5489351C.dip0.t-ipconnect.de [84.137.53.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 19A6D75F3; Fri, 21 Jun 2013 15:33:52 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <066.7fcfce93944df67d37ec5059d1a2cedf@trac.tools.ietf.org> Date: Fri, 21 Jun 2013 15:33:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org> <066.7fcfce93944df67d37ec5059d1a2cedf@trac.tools.ietf.org> To: trac+core@grenache.tools.ietf.org X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-core-coap@tools.ietf.org, core@ietf.org Subject: Re: [core] #329: Ambiguity of Accept option still considered a problem 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, 21 Jun 2013 13:34:06 -0000 My summary of the discussion on this ticket: Pete doesn't like: > I have no way as a client to > say, "I really can only accept format X, and if you can't make format = X, I > don't want something else", and I have no way to distinguish that from = "I > would prefer format X, but am willing to take whatever you can give = me." Some of the ambiguity of Accept comes from the fact that it is an = elective option, so any MUST attached to it will be negated by the = server always being allowed to ignore the option. So, this sentence out of Pete's DISCUSS will always be true unless we = change Accept to be critical: > I have to be prepared to throw things away. In previous discussions, we said that this is not a big issue, as = messages are small and the cost of a 4.06 response and an unusable = response are not that far apart. However, the cost of generating a response may be higher for the server, = which is why we do have the ability for it to send a 4.06 instead. = Matthias also sees some value in it for debugging. Solution 1: If that is not a big problem, we can get rid of the 4.06. Solution 2: We add a variant of Accept that is critical, so (in HTTP = terms) we have a way to say Accept: foo, * (the elective version) as well as Accept: foo (the critical version) (Note that, while HTTP is wishy-washy about the requirements here = because it doesn't have critical options, we don't have to be.) Solution 2a: That variant is actually what we always want and it = replaces the elective Accept. Solution 3: _________ (please fill in the blank) Solution 0: We have WG consensus that we really like what we have and = try to explain to Pete why that is so. Matthias also has made the point that an admonishment might be useful = that the Content-Format of the response needs to be checked, which is = certainly a useful addition (except for Solution 2a). Again, I would like to submit -18 very soon, so I would be happy with = some quick responses, even if they are only temperature readings. Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Fri Jun 21 08:00:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B7211E81A9 for ; Fri, 21 Jun 2013 08:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] 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 P8tSt9GCz3ue for ; Fri, 21 Jun 2013 08:00:03 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id E7EA211E819E for ; Fri, 21 Jun 2013 08:00:02 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Jun 2013 11:00:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jun 2013 11:00:00 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #329: Ambiguity of Accept option still considered aproblem Thread-Index: Ac5uhE+7xqeBEjkaQw+YAflyStenqAAClTwg References: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org><066.7fcfce93944df67d37ec5059d1a2cedf@trac.tools.ietf.org> From: "Rahman, Akbar" To: "Carsten Bormann" , X-OriginalArrivalTime: 21 Jun 2013 15:00:01.0387 (UTC) FILETIME=[0124FBB0:01CE6E90] Cc: draft-ietf-core-coap@tools.ietf.org, core@ietf.org Subject: Re: [core] #329: Ambiguity of Accept option still considered aproblem 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, 21 Jun 2013 15:00:10 -0000 Hi Carsten, My vote is for: Solution 2a: That variant is actually what we always want and it = replaces the elective Accept. Reasoning: We are in a constrained environment so we should be as simple = and precise as possible in client-server interactions and avoid any = wasted transactions (of which the equivalent in HTTP may be more = tolerable). Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Carsten Bormann Sent: Friday, June 21, 2013 9:34 AM To: trac+core@grenache.tools.ietf.org Cc: draft-ietf-core-coap@tools.ietf.org; core@ietf.org Subject: Re: [core] #329: Ambiguity of Accept option still considered = aproblem My summary of the discussion on this ticket: Pete doesn't like: > I have no way as a client to > say, "I really can only accept format X, and if you can't make format=20 > X, I don't want something else", and I have no way to distinguish that = > from "I would prefer format X, but am willing to take whatever you can = give me." Some of the ambiguity of Accept comes from the fact that it is an = elective option, so any MUST attached to it will be negated by the = server always being allowed to ignore the option. So, this sentence out of Pete's DISCUSS will always be true unless we = change Accept to be critical: > I have to be prepared to throw things away. In previous discussions, we said that this is not a big issue, as = messages are small and the cost of a 4.06 response and an unusable = response are not that far apart. However, the cost of generating a response may be higher for the server, = which is why we do have the ability for it to send a 4.06 instead. = Matthias also sees some value in it for debugging. Solution 1: If that is not a big problem, we can get rid of the 4.06. Solution 2: We add a variant of Accept that is critical, so (in HTTP = terms) we have a way to say Accept: foo, * (the elective version) as well as Accept: foo (the critical version) (Note that, while HTTP is wishy-washy about the requirements here = because it doesn't have critical options, we don't have to be.) Solution 2a: That variant is actually what we always want and it = replaces the elective Accept. Solution 3: _________ (please fill in the blank) Solution 0: We have WG consensus that we really like what we have and = try to explain to Pete why that is so. Matthias also has made the point that an admonishment might be useful = that the Content-Format of the response needs to be checked, which is = certainly a useful addition (except for Solution 2a). Again, I would like to submit -18 very soon, so I would be happy with = some quick responses, even if they are only temperature readings. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Sun Jun 23 05:09:54 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0133F21F9D7F for ; Sun, 23 Jun 2013 05:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7DVcsdVuYcV for ; Sun, 23 Jun 2013 05:09:47 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFE421F9D0B for ; Sun, 23 Jun 2013 05:09:46 -0700 (PDT) Received: from mail202-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Sun, 23 Jun 2013 12:09:44 +0000 Received: from mail202-va3 (localhost [127.0.0.1]) by mail202-va3-R.bigfish.com (Postfix) with ESMTP id 5B62C200112; Sun, 23 Jun 2013 12:09:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(z10d0kz15d6Oc89bh542I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail202-va3 (localhost.localdomain [127.0.0.1]) by mail202-va3 (MessageSwitch) id 1371989382488446_11147; Sun, 23 Jun 2013 12:09:42 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.236]) by mail202-va3.bigfish.com (Postfix) with ESMTP id 737B150004D; Sun, 23 Jun 2013 12:09:42 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 23 Jun 2013 12:09:42 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.190]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.02.0328.011; Sun, 23 Jun 2013 12:09:40 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: AQHOavCHQ3fUK6vnakKCWJpCEZE4gZk5bikwgACtKQCAAA5bgIAAIrIAgAAAhACAAAMngIAACfSAgAAC+ACAAJzDoIAABXAAgAADBDCABSxaAIAACBPA Date: Sun, 23 Jun 2013 12:09:01 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C7AB7E@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> <031DD135F9160444ABBE3B0C36CED618C75950@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618C769C2@011-DB3MPN2-083.MGDPHG.emi.philips.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: [83.83.116.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "draft-ietf-core-coap@tools.ietf.org" , "core@ietf.org" , "trac+core@trac.tools.ietf.org" Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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: Sun, 23 Jun 2013 12:09:54 -0000 Hi Carsten, the proposed changes sound ok. I can't judge whether the 'heuristic stuff' = you mention leads to code complexity today, or not. It looks as if using Si= ze1/Size2 instead of a single 'Size' option would not matter that much for = current implementations. Maybe it is important though to be prepared better= for future extensions of CoAP (just like split between Block1/Block2 becam= e necessary at some point to support the POST case.) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Friday, June 21, 2013 15:21 To: Dijk, Esko Cc: Zach Shelby; Rahman, Akbar; draft-ietf-core-coap@tools.ietf.org; trac+c= ore@trac.tools.ietf.org; core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error My personal summary of the conversation on this ticket so far: -- We don't have consensus that the solution solves a particularly prominen= t use case. -- We don't have consensus that it is entirely useless either. -- Some of the discussion was about whether we do it now or in -block, whic= h is just a matter of procedure. -- Nobody has commented on the specific solution I have proposed. Given that this is one of the two remaining issues blocking CoAP from becom= ing RFC, I'm inclined to just make the change. But I'd like to hear a bit = more about whether the other elements of the proposed change (the ones that= also influence -block) are right: -- Splitting Size into Size1 and Size2 (and removing some of the heuristic = stuff that we need without that); -- Using Size1 not only in a request to indicate the projected size of the = request body, but also in a 4.13 response to indicate the maximum accepted = size. I would like to submit -18 very soon, so I would be happy with some quick r= esponses, even if they are only temperature readings. 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 Akbar.Rahman@InterDigital.com Sun Jun 23 15:36:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCC721F92BB for ; Sun, 23 Jun 2013 15:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] 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 TTU0JnMyT863 for ; Sun, 23 Jun 2013 15:36:34 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2F54421F919D for ; Sun, 23 Jun 2013 15:36:34 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 23 Jun 2013 18:36:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 23 Jun 2013 18:36:32 -0400 Message-ID: In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C7AB7E@011-DB3MPN2-083.MGDPHG.emi.philips.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #331: No way to indicate preferred size in a 4.13 error Thread-Index: AQHOavCHQ3fUK6vnakKCWJpCEZE4gZk5bikwgACtKQCAAA5bgIAAIrIAgAAAhACAAAMngIAACfSAgAAC+ACAAJzDoIAABXAAgAADBDCABSxaAIAACBPAgAO3thA= References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> <031DD135F9160444ABBE3B0C36CED618C75950@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618C769C2@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618C7AB7E@011-DB3MPN2-083.MGDPHG.emi.philips.com> From: "Rahman, Akbar" To: "Dijk, Esko" , "Carsten Bormann" X-OriginalArrivalTime: 23 Jun 2013 22:36:33.0327 (UTC) FILETIME=[1CD6D3F0:01CE7062] Cc: draft-ietf-core-coap@tools.ietf.org, "trac+core@trac.tools.ietf.org" , core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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: Sun, 23 Jun 2013 22:36:46 -0000 +1 -----Original Message----- From: Dijk, Esko [mailto:esko.dijk@philips.com]=20 Sent: Sunday, June 23, 2013 8:09 AM To: Carsten Bormann Cc: Zach Shelby; Rahman, Akbar; draft-ietf-core-coap@tools.ietf.org; = trac+core@trac.tools.ietf.org; core@ietf.org Subject: RE: [core] #331: No way to indicate preferred size in a 4.13 = error Hi Carsten, the proposed changes sound ok. I can't judge whether the 'heuristic = stuff' you mention leads to code complexity today, or not. It looks as = if using Size1/Size2 instead of a single 'Size' option would not matter = that much for current implementations. Maybe it is important though to = be prepared better for future extensions of CoAP (just like split = between Block1/Block2 became necessary at some point to support the POST = case.) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Friday, June 21, 2013 15:21 To: Dijk, Esko Cc: Zach Shelby; Rahman, Akbar; draft-ietf-core-coap@tools.ietf.org; = trac+core@trac.tools.ietf.org; core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 = error My personal summary of the conversation on this ticket so far: -- We don't have consensus that the solution solves a particularly = prominent use case. -- We don't have consensus that it is entirely useless either. -- Some of the discussion was about whether we do it now or in -block, = which is just a matter of procedure. -- Nobody has commented on the specific solution I have proposed. Given that this is one of the two remaining issues blocking CoAP from = becoming RFC, I'm inclined to just make the change. But I'd like to = hear a bit more about whether the other elements of the proposed change = (the ones that also influence -block) are right: -- Splitting Size into Size1 and Size2 (and removing some of the = heuristic stuff that we need without that); -- Using Size1 not only in a request to indicate the projected size of = the request body, but also in a 4.13 response to indicate the maximum = accepted size. I would like to submit -18 very soon, so I would be happy with some = quick responses, even if they are only temperature readings. Gr=FC=DFe, Carsten ________________________________ 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. From lishitao@huawei.com Sun Jun 23 18:20:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F031A11E80F0 for ; Sun, 23 Jun 2013 18:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38PBkpb725n8 for ; Sun, 23 Jun 2013 18:20:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 46DC911E80F7 for ; Sun, 23 Jun 2013 18:20:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AST83248; Mon, 24 Jun 2013 01:20:28 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 02:18:46 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 02:19:21 +0100 Received: from NKGEML501-MBX.china.huawei.com ([169.254.1.244]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 09:19:14 +0800 From: Lishitao To: "core@ietf.org" Thread-Topic: New Version Notification for draft-li-core-conditional-observe-04.txt Thread-Index: AQHOcHY5/mxp8aDPyUe20woOtLaMx5lEDRvA Date: Mon, 24 Jun 2013 01:19:13 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.92] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] FW: New Version Notification for draft-li-core-conditional-observe-04.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, 24 Jun 2013 01:20:38 -0000 SGkNClRoZSBhdXRob3JzIGhhdmUgc3VibWl0IGEgbmV3IHZlcnNpb24gZm9yIGRyYWZ0LWxpLWNv cmUtY29uZGl0aW9uYWwtb2JzZXJ2ZS4NCg0KSW4gQXBwZW5kaXggYywgdGhlIGNoYW5nZSBsb2cg aGFzIGluZGljYXRlZCB0aGUgbWFpbiBjaGFuZ2UgaW4gdGhpcyBuZXcgdmVyc2lvbi4NCg0KdGhl IG1haW4gY2hhbmdlcyBhcmU6DQoNCiAgICBUb29rIHJlcXVlc3QgVVJJIGludG8gY29uc2lkZXJh dGlvbiBmb3IgQ2FuY2VsbGF0aW9uLg0KDQogICAgRXhwbGljaXRseSBzdGF0ZWQgdGhhdCB0aGUg dGltaW5nIGNvbmRpdGlvbnMgYWxsb3cgYSBjbGllbnQgdG8NCnVzZSBhIHJlcHJlc2VudGF0aW9u IHRoYXQgaXMgb2xkZXIgdGhhbiBNYXgtQWdlIHdpdGhvdXQNCnZlcmlmeWluZyB0aGUgcmVwcmVz ZW50YXRpb24gZmlyc3QuIFRoaXMgY29sbGlkZXMgd2l0aCBhIE1VU1QNCk5PVCBmcm9tIHRoZSBv YnNlcnZlIGRyYWZ0Lg0KDQogICAgU3RhdGVkIHRoYXQgYSBzZXJ2ZXIgc2hvdWxkIGZvbGxvdyB0 aGUgdGV4dCBmcm9tIHRoZSBvYnNlcnZlDQpkcmFmdCBmb3IgYW4gdW5hY2tub3dsZWRnZWQgbm90 aWZpY2F0aW9uIGluIHJlZ2FyZHMgdG8gdGhlDQp0cmFuc21pc3Npb24gb2YgbmV3IG5vdGlmaWNh dGlvbnMgYW5kIHRoZSBjYW5jZWxsYXRpb24gb2YNCmV4aXN0aW5nIHJlbGF0aW9uc2hpcHMuDQoN CiAgIEFkZGVkIHNlY3Rpb24gMi4xIGNvbXBhcmluZyB0aGUgUkVTVGZ1bCBhcHByb2FjaCBmcm9t IGRyYWZ0LQ0Kc2hlbGJ5LWNvcmUtaW50ZXJmYWNlcyB0byBvdXIgYXBwcm9hY2ggZm9yIGNvbmRp dGlvbmFsDQpvYnNlcnZhdGlvbnMuDQoNCiAgIENsYXJpZmllZCB3aHkgIkFORCIgc2VtYW50aWNz IGFyZSBwcmVmZXJyZWQgb3ZlciAiT1IiIHNlbWFudGljcyBpbg0KY2FzZSBvZiBtdWx0aXBsZSBD b25kaXRpb24gb3B0aW9ucy4NCg0KICAgQ2xhcmlmaWVkIHRoYXQgdGhlIFIgZmxhZyBkb2Vzbid0 IHZpb2xhdGUgdGhlIGJlaGF2aW91ciBkZWZpbmVkIGluDQp0aGUgT2JzZXJ2ZSBkcmFmdC4NCg0K ICAgQ2xhcmlmaWVkIHRoYXQgYSBjbGllbnQgbWlnaHQgb3B0IHRvIHVzZSByZXByZXNlbnRhdGlv bnMgb2xkZXINCnRoYW4gTWF4LUFnZSB3aXRob3V0IHZhbGlkYXRpbmcgdGhlc2UgZmlyc3QgaW4g Y2FzZSBvZiBtb3N0IG9mIHRoZQ0KdGltaW5nIGNvbmRpdGlvbnMuIEEgc2VydmVyIGhhcyB0aGUg YWJpbGl0eSB0byBkZW55IHRoZSBjbGllbnQNCnRoaXMgc29ydCBvZiBiZWhhdmlvdXIgaG93ZXZl ci4NCg0KICAgVXBkYXRlZCBzb3VyY2UgZW5kcG9pbnQgdGVybWlub2xvZ3kuDQogIA0KICAgQWRk aW5nIE9NQSBMV00yTSBzcGVjaWZpY2F0aW9ucyBmb3IgcmVmZXJlbmNlLg0KDQpIb3BlZnVsbHks IHdlIGNhbiBoYXZlIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLg0KDQpSZWdhcmRzDQoN CnNoaXRhbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1v bmRheSwgSnVuZSAyNCwgMjAxMyA5OjAwIEFNDQpUbzogTGlzaGl0YW87IEFudG9uaW8gSi4gSmFy YTsgRmxvcmlzIFZhbiBkZW4gQWJlZWxlOyBKZXJvZW4gSG9lYmVrZQ0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1jb3JlLWNvbmRpdGlvbmFsLW9ic2VydmUt MDQudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpLWNvcmUtY29uZGl0aW9u YWwtb2JzZXJ2ZS0wNC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2hp dGFvIExpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkg ZHJhZnQtbGktY29yZS1jb25kaXRpb25hbC1vYnNlcnZlDQpSZXZpc2lvbjoJIDA0DQpUaXRsZToJ CSBDb25kaXRpb25hbCBvYnNlcnZlIGluIENvQVANCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA2LTI0 DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMzENClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt bGktY29yZS1jb25kaXRpb25hbC1vYnNlcnZlLTA0LnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWNvcmUtY29uZGl0aW9uYWwtb2Jz ZXJ2ZQ0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s aS1jb3JlLWNvbmRpdGlvbmFsLW9ic2VydmUtMDQNCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGktY29yZS1jb25kaXRpb25hbC1vYnNlcnZl LTA0DQoNCkFic3RyYWN0Og0KICAgQ29BUCBpcyBhIFJFU1RmdWwgYXBwbGljYXRpb24gcHJvdG9j b2wgZm9yIGNvbnN0cmFpbmVkIG5vZGVzIGFuZA0KICAgbmV0d29ya3MuICBUaHJvdWdoIHRoZSBP YnNlcnZlIG9wdGlvbiwgY2xpZW50cyBjYW4gb2JzZXJ2ZSBjaGFuZ2VzIGluDQogICB0aGUgc3Rh dGUgb2YgcmVzb3VyY2VzIGFuZCBvYnRhaW4gYSBjdXJyZW50IHJlcHJlc2VudGF0aW9uIG9mIHRo ZQ0KICAgbGFzdCByZXNvdXJjZSBzdGF0ZS4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBt ZWNoYW5pc20gaW4gQ29BUA0KICAgT2JzZXJ2ZSBzbyB0aGF0IGEgQ29BUCBjbGllbnQgY2FuIGNv bmRpdGlvbmFsbHkgb2JzZXJ2ZSBhIHJlc291cmNlIG9uDQogICBhIENvQVAgc2VydmVyLCBvbmx5 IGJlaW5nIGluZm9ybWVkIGFib3V0IHN0YXRlIGNoYW5nZXMgbWVldGluZyBhDQogICBzcGVjaWZp YyBjb25kaXRpb24gb3Igc2V0IG9mIGNvbmRpdGlvbnMuICBUaGlzIG9mZmVycyBwb3NzaWJpbGl0 aWVzDQogICB0byBleHRlbmQgbmV0d29yayBpbnRlbGxpZ2VuY2UsIGVuaGFuY2Ugc2NhbGFiaWxp dHksIGFuZCBvcHRpbWl6ZSB0aGUNCiAgIGxpZmV0aW1lIGFuZCBwZXJmb3JtYW5jZSBpbiBvcmRl ciB0byBhZGRyZXNzIHRoZSByZXF1aXJlbWVudHMgZnJvbQ0KICAgdGhlIENvbnN0cmFpbmVkIE5v ZGVzIGFuZCBOZXR3b3Jrcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg== From qiminpeng@chinamobile.com Sun Jun 23 20:10:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA2A21E8099 for ; Sun, 23 Jun 2013 20:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.626 X-Spam-Level: *** X-Spam-Status: No, score=3.626 tagged_above=-999 required=5 tests=[AWL=3.703, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222] 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 EUnZVlblZd3h for ; Sun, 23 Jun 2013 20:10:18 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id D7A1A21E808D for ; Sun, 23 Jun 2013 20:10:17 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151c7b85cf25-eff25; Mon, 24 Jun 2013 11:09:17 +0800 (CST) X-RM-TRANSID: 2ee151c7b85cf25-eff25 Received: from RonPC (unknown[10.2.51.87]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee351c7b85ca99-7d837; Mon, 24 Jun 2013 11:09:17 +0800 (CST) X-RM-TRANSID: 2ee351c7b85ca99-7d837 From: =?utf-8?B?6b2Q5pe76bmP?= To: Date: Mon, 24 Jun 2013 11:10:07 +0800 Message-ID: <001401ce7088$54874f20$fd95ed60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5wgtAdgysqV4bRQJ6fBAPCrl+yywAAWi+Q Content-Language: zh-cn Subject: [core] FW: New Version Notification for draft-zhu-core-groupauth-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, 24 Jun 2013 03:10:22 -0000 Hi everyone, The authors have submit a new draft for the group authentication. We = will appreciate if you have a look and give us any comment or = suggestion. The link is as below. Here is a problem that for group communication there is only uni-cast = authentication instead of group authentication method can be used. This = draft wants to analyze the problem, to summarize group authentication = requirement and to provide a framework of solutions. BRs, Minpeng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B46=E6=9C=8824=E6=97=A5 = 10:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: Ye Tian; Minpeng Qi; Judy Zhu =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zhu-core-groupauth-00.txt A new version of I-D, draft-zhu-core-groupauth-00.txt has been successfully submitted by Judy Zhu and posted to the IETF repository. Filename: draft-zhu-core-groupauth Revision: 00 Title: Group Authentication Creation date: 2013-06-24 Group: Individual Submission Number of pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-zhu-core-groupauth-00.txt Status: = http://datatracker.ietf.org/doc/draft-zhu-core-groupauth Htmlized: http://tools.ietf.org/html/draft-zhu-core-groupauth-00 Abstract: The group communication is designed for the communication of Internet of Things. A threat is identified in [I-D.ietf-core-groupcomm] that current DTLS based approach is unicast oriented and there is no supporting on group authentication feature. Unicast oriented authentication will causing serious burden when a large number of terminal nodes will be involved inevitably. In another aspect, some terminals will own the same characteristics, such as owning same features, in the same place, working in the same time, etc. With this mechanism, all terminals can be authenticated together with little signaling and calculation at the same time. It will reduce the network burden and save time. This draft describes the security of group authentication and an group authentication implementation method for the Internet of things. = =20 The IETF Secretariat From zach@sensinode.com Mon Jun 24 00:06:06 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D9B11E8125 for ; Mon, 24 Jun 2013 00:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhGtQpSv-Ke8 for ; Mon, 24 Jun 2013 00:06:00 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3471211E80E0 for ; Mon, 24 Jun 2013 00:05:57 -0700 (PDT) Received: from [192.168.1.104] (87-95-149-78.bb.dnainternet.fi [87.95.149.78]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r5O75obX027642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 10:05:51 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Mon, 24 Jun 2013 10:05:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED618C70535@011-DB3MPN2-083.MGDPHG.emi.philips.com> <34D55136-CD19-43F1-8B9D-27AB40FC2808@tzi.org> <031DD135F9160444ABBE3B0C36CED618C75950@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618C769C2@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1503) Cc: "draft-ietf-core-coap@tools.ietf.org" , "trac+core@trac.tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 24 Jun 2013 07:06:06 -0000 Carsten, I am fine with just implementing this change. Zach On Jun 21, 2013, at 4:21 PM, Carsten Bormann wrote: > My personal summary of the conversation on this ticket so far: >=20 > -- We don't have consensus that the solution solves a particularly = prominent use case. > -- We don't have consensus that it is entirely useless either. > -- Some of the discussion was about whether we do it now or in -block, = which is just a matter of procedure. > -- Nobody has commented on the specific solution I have proposed. >=20 > Given that this is one of the two remaining issues blocking CoAP from = becoming RFC, I'm inclined to just make the change. But I'd like to = hear a bit more about whether the other elements of the proposed change = (the ones that also influence -block) are right: >=20 > -- Splitting Size into Size1 and Size2 (and removing some of the = heuristic stuff that we need without that); > -- Using Size1 not only in a request to indicate the projected size of = the request body, but also in a 4.13 response to indicate the maximum = accepted size. >=20 > I would like to submit -18 very soon, so I would be happy with some = quick responses, even if they are only temperature readings. >=20 > Gr=FC=DFe, Carsten >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Mon Jun 24 00:09:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FBA21E80C0 for ; Mon, 24 Jun 2013 00:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+u6BCLEi0kX for ; Mon, 24 Jun 2013 00:09:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id A69C721E80C5 for ; Mon, 24 Jun 2013 00:09:26 -0700 (PDT) Received: from [192.168.1.104] (87-95-149-78.bb.dnainternet.fi [87.95.149.78]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r5O79LOn028589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 10:09:22 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Mon, 24 Jun 2013 10:09:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <532859CC-CB4A-495A-A35C-56833CFFF8F8@sensinode.com> References: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org><066.7fcfce93944df67d37ec5059d1a2cedf@trac.tools.ietf.org> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, trac+core@grenache.tools.ietf.org, core@ietf.org Subject: Re: [core] #329: Ambiguity of Accept option still considered aproblem 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, 24 Jun 2013 07:09:31 -0000 On Jun 21, 2013, at 6:00 PM, "Rahman, Akbar" = wrote: > My vote is for: >=20 > Solution 2a: That variant is actually what we always want and it = replaces the elective Accept. >=20 > Reasoning: We are in a constrained environment so we should be as = simple and precise as possible in client-server interactions and avoid = any wasted transactions (of which the equivalent in HTTP may be more = tolerable). Well said Akbar, +1. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From Bert.Greevenbosch@huawei.com Mon Jun 24 00:51:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A9E11E8104 for ; Mon, 24 Jun 2013 00:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=-0.721, 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 u1NgV7C9VQKV for ; Mon, 24 Jun 2013 00:50:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B49DA21E80DA for ; Mon, 24 Jun 2013 00:50:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUH17146; Mon, 24 Jun 2013 07:50:32 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 08:49:53 +0100 Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 08:50:30 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 15:50:08 +0800 From: Bert Greevenbosch To: Zach Shelby , "Rahman, Akbar" Thread-Topic: [core] #329: Ambiguity of Accept option still considered aproblem Thread-Index: AQHObpANxVtmDdRLOkyn9i8xyC6iBplD8EWAgACPrUA= Date: Mon, 24 Jun 2013 07:50:07 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D782CE3@szxeml558-mbx.china.huawei.com> References: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org><066.7fcfce93944df67d37ec5059d1a2cedf@trac.tools.ietf.org> <532859CC-CB4A-495A-A35C-56833CFFF8F8@sensinode.com> In-Reply-To: <532859CC-CB4A-495A-A35C-56833CFFF8F8@sensinode.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-core-coap@tools.ietf.org" , "trac+core@grenache.tools.ietf.org" , "core@ietf.org" Subject: Re: [core] #329: Ambiguity of Accept option still considered aproblem 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, 24 Jun 2013 07:51:21 -0000 SSBhbSBpbmNsaW5lZCB0byBnbyBmb3Igb3B0aW9uIDJhIHRvby4gSG93ZXZlciwgc2luY2UgdGhl ICJhY2NlcHQiIG9wdGlvbiBjdXJyZW50bHkgaXMgbm9uLXJlcGVhdGFibGUsIHRoaXMgbWVhbnMg dGhhdCB0aGUgc2VydmVyIHdpbGwgc2VuZCB0aGUgcmVxdWVzdGVkIGNvbnRlbnQgaWYsIGFuZCBv bmx5IGlmLCB0aGUgYWNjZXB0YWJsZSBjb250ZW50LXR5cGUgaXMgYXZhaWxhYmxlLiBEb2VzIHRo aXMganVzdGlmeSBhbGxvd2luZyBtdWx0aXBsZSAiYWNjZXB0IiBvcHRpb25zIGFnYWluLCBzdWNo IHRoYXQgdGhlIHNlcnZlciBjYW4gY2hvb3NlIG91dCBvZiBtdWx0aXBsZSBhY2NlcHRhYmxlIGNv bnRlbnQtdHlwZXM/DQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmFjaCBTaGVsYnkNClNlbnQ6IDIwMTPE6jbUwjI0 yNUgMTU6MDkNClRvOiBSYWhtYW4sIEFrYmFyDQpDYzogZHJhZnQtaWV0Zi1jb3JlLWNvYXBAdG9v bHMuaWV0Zi5vcmc7IHRyYWMrY29yZUBncmVuYWNoZS50b29scy5pZXRmLm9yZzsgY29yZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSAjMzI5OiBBbWJpZ3VpdHkgb2YgQWNjZXB0IG9wdGlv biBzdGlsbCBjb25zaWRlcmVkIGFwcm9ibGVtDQoNCk9uIEp1biAyMSwgMjAxMywgYXQgNjowMCBQ TSwgIlJhaG1hbiwgQWtiYXIiIDxBa2Jhci5SYWhtYW5ASW50ZXJEaWdpdGFsLmNvbT4gd3JvdGU6 DQoNCj4gTXkgdm90ZSBpcyBmb3I6DQo+IA0KPiBTb2x1dGlvbiAyYTogVGhhdCB2YXJpYW50IGlz IGFjdHVhbGx5IHdoYXQgd2UgYWx3YXlzIHdhbnQgYW5kIGl0IHJlcGxhY2VzIHRoZSBlbGVjdGl2 ZSBBY2NlcHQuDQo+IA0KPiBSZWFzb25pbmc6IFdlIGFyZSBpbiBhIGNvbnN0cmFpbmVkIGVudmly b25tZW50IHNvIHdlIHNob3VsZCBiZSBhcyBzaW1wbGUgYW5kIHByZWNpc2UgYXMgcG9zc2libGUg aW4gY2xpZW50LXNlcnZlciBpbnRlcmFjdGlvbnMgYW5kIGF2b2lkIGFueSB3YXN0ZWQgdHJhbnNh Y3Rpb25zIChvZiB3aGljaCB0aGUgZXF1aXZhbGVudCBpbiBIVFRQIG1heSBiZSBtb3JlIHRvbGVy YWJsZSkuDQoNCldlbGwgc2FpZCBBa2JhciwgKzEuDQoNClphY2gNCg0KLS0gDQpaYWNoIFNoZWxi eSwgQ2hpZWYgTmVyZCwgU2Vuc2lub2RlIEx0ZC4NCmh0dHA6Ly93d3cuc2Vuc2lub2RlLmNvbSBA U2Vuc2lub2RlSW9UDQpNb2JpbGU6ICszNTggNDAgNzc5NjI5Nw0KVHdpdHRlcjogQHphY2hfc2hl bGJ5DQpMaW5rZWRJbjogaHR0cDovL2ZpLmxpbmtlZGluLmNvbS9pbi96YWNoc2hlbGJ5DQo2TG9X UEFOIEJvb2s6IGh0dHA6Ly82bG93cGFuLm5ldA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From trac+core@trac.tools.ietf.org Mon Jun 24 06:32:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F157421E80DC for ; Mon, 24 Jun 2013 06:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRIPntFw0XF6 for ; Mon, 24 Jun 2013 06:32:13 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4621F9A7B for ; Mon, 24 Jun 2013 06:32:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:53936 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ur6sN-0000hy-JC; Mon, 24 Jun 2013 15:32:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Mon, 24 Jun 2013 13:32:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/258#comment:1 Message-ID: <066.baf70b312cd272aacf2dafec6f35231c@trac.tools.ietf.org> References: <051.3c984165effb92092dc532973c01ed03@trac.tools.ietf.org> X-Trac-Ticket-ID: 258 In-Reply-To: <051.3c984165effb92092dc532973c01ed03@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130624133213.31D4621F9A7B@ietfa.amsl.com> Resent-Date: Mon, 24 Jun 2013 06:32:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #258: Be explicit about the "observe key" 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, 24 Jun 2013 13:32:14 -0000 #258: Be explicit about the "observe key" Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: Done in observe-09 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | observe@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: minor | Version: observe-07 Component: observe | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Jun 24 06:33:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E35121E80EA for ; Mon, 24 Jun 2013 06:33:02 -0700 (PDT) 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 KmF-VV-izrKQ for ; Mon, 24 Jun 2013 06:33:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9667321E80E9 for ; Mon, 24 Jun 2013 06:33:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:54007 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ur6sv-0002Q0-GA; Mon, 24 Jun 2013 15:32:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, hartke@tzi.org X-Trac-Project: core Date: Mon, 24 Jun 2013 13:32:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/281#comment:2 Message-ID: <068.fb2be1781888ebaba1e9c6c9af131e4f@trac.tools.ietf.org> References: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> X-Trac-Ticket-ID: 281 In-Reply-To: <053.70184317296fef3c8c92712097ae1be1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130624133301.9667321E80E9@ietfa.amsl.com> Resent-Date: Mon, 24 Jun 2013 06:33:01 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #281: Safe-to-forward options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:33:02 -0000 #281: Safe-to-forward options Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: Done in observe-09 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: closed defect | Milestone: post-WGLC-1 Priority: minor | Version: observe-07 Component: observe | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Mon Jun 24 22:11:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D814621F9F80 for ; Mon, 24 Jun 2013 22:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.215 X-Spam-Level: X-Spam-Status: No, score=-106.215 tagged_above=-999 required=5 tests=[AWL=0.034, 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 I5AjjGxHHdn1 for ; Mon, 24 Jun 2013 22:11:32 -0700 (PDT) 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 DEFB521F9F76 for ; Mon, 24 Jun 2013 22:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5P5BT0U020727 for ; Tue, 25 Jun 2013 07:11:29 +0200 (CEST) Received: from [192.168.217.105] (p54893C8A.dip0.t-ipconnect.de [84.137.60.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F0F4A3313; Tue, 25 Jun 2013 07:11:28 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann Date: Tue, 25 Jun 2013 07:11:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <695B44F3-3994-4A82-9479-95E9BC81550F@tzi.org> References: To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1508) Subject: [core] Link Hints: draft-nottingham-link-hint-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, 25 Jun 2013 05:11:37 -0000 On apps-discuss, a discussion has started on the below draft, which = defines a data model for carrying, in the HTTP Link format, additional = information about resources, solving a similar problem to the various = "profile" ideas that we have been discussing here. This is supposed to be HTTP-specific, but the very same mechanism might = be applicable to CoAP as well. It also defines an interesting convention for carrying JSON data in the = HTTP Link format. We can discuss CoRE-specific aspects here, but the discussion of the = draft should be over in apps-discuss. Gr=FC=DFe, Carsten Begin forwarded message: >> Filename: draft-nottingham-link-hint >> Revision: 00 >> Title: HTTP Link Hints >> Creation date: 2013-06-10 >> Group: Individual Submission >> Number of pages: 12 >> URL: = http://www.ietf.org/internet-drafts/draft-nottingham-link-hint-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-nottingham-link-hint >> Htmlized: = http://tools.ietf.org/html/draft-nottingham-link-hint-00 >>=20 >>=20 >> Abstract: >> This memo specifies "HTTP Link Hints", a mechanism for annotating = Web >> links to HTTP(S) resources with information that otherwise might be >> discovered by interacting with them. >>=20 >> Note to Readers >>=20 >> This draft should be discussed on the apps-discuss mailing list; see >> [apps-discuss]. From kerlyn2001@gmail.com Tue Jun 25 11:12:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C620F11E812B for ; Tue, 25 Jun 2013 11:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 acZehs7lPnpg for ; Tue, 25 Jun 2013 11:12:55 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 098B811E8128 for ; Tue, 25 Jun 2013 11:12:54 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so9666596wes.32 for ; Tue, 25 Jun 2013 11:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YF89eefWjYUKdYOUFfoZFma4fqC/3iC+oujZO9V3m7Y=; b=VmISzOLfrNK+uH9sQI2NuVHSRp4QnN8eFQkR5g/5sTV1d/ZgV6O4f2SfmlDWDprnhA Wl8FcW+5Ed+R5NXcEIn3O2Xjt5jSyAjNumr5qd+ZGWdS9gCK69lY4VpsZoGDIEBh00zp SfEfTqgIVsHVAAQa04zOpQ00IMFneISSg5fXjl0Y4xnVp9p3tBNfhuxNqbgCOh17XeZ6 KR4MQWQjvTgFc9yBIZ3HwElya5Z5CEbSk/F+y2mVEARGoJF6+YT0r0Zn/VI/aNxznw7+ x78KZVEiXGauiJBLJZm66rkD/AzTF0QVfOg4H69BDPMR1ierh9vuV1ctiId4J85qdE3W ei7A== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr159758wic.32.1372183974083; Tue, 25 Jun 2013 11:12:54 -0700 (PDT) Received: by 10.180.183.84 with HTTP; Tue, 25 Jun 2013 11:12:53 -0700 (PDT) Date: Tue, 25 Jun 2013 14:12:53 -0400 Message-ID: From: Kerry Lynn To: core Content-Type: multipart/alternative; boundary=001a11c348305781bc04dffe7af8 Subject: [core] Media type text/html? 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, 25 Jun 2013 18:12:55 -0000 --001a11c348305781bc04dffe7af8 Content-Type: text/plain; charset=ISO-8859-1 Pardon me if this is a dumb question. We have taken pains in the draft to define proxies and now have a WG draft describing CoAP/HTTP mapping best practices. However, the simplest method of connecting a coap server through a cross- proxy to the world as it exists today is to define a browser's natural media type: "text/html". Some (most?) browsers will not render text/plain. It seems this was removed in response to Cullen's : http://www.ietf.org/mail-archive/web/core/current/msg01048.html where he largely talks about "application/8bit" as being useless for determining the format of a resource (which I agree with). Was "text/html" removed for a good reason, or did we take issue #76 http://tools.ietf.org/wg/core/trac/ticket/76 a bit too literally? -K- --001a11c348305781bc04dffe7af8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pardon me if this is a dumb question.

We have taken pains in the dra= ft to define proxies and now have a WG draft
describing CoAP/HTTP mappin= g best practices.

However, the simplest method of connecting a coap = server through a cross-
proxy to the world as it exists today is to define a browser's natural = media type:
"text/html".=A0 Some (most?) browsers will not ren= der text/plain.

It seems this was removed in response to Cullen'= s <rant/>:
http://www.ietf.org/mail-archive/web/core/current/msg01048.html where = he
largely talks about "application/8bit" as being useless for= determining the
format of a resource (which I agree with).

Was "text/html"= removed for a good reason, or did we take issue #76
http://tools.ietf.org/wg/core/trac/ti= cket/76 a bit too literally?

-K-
--001a11c348305781bc04dffe7af8-- From kerlyn2001@gmail.com Tue Jun 25 11:18:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB5D21E80C5 for ; Tue, 25 Jun 2013 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 cH+HUMjO3LuJ for ; Tue, 25 Jun 2013 11:18:48 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC1021E8099 for ; Tue, 25 Jun 2013 11:18:43 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so1130562wid.3 for ; Tue, 25 Jun 2013 11:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=qqEnxzoBi9spiKRDf+RanZWIjXV2QDMLTw8w1oNufSc=; b=KgAL8vFwdAsIWpgO1mq4pBfpHOzR9+v6H5t5yv6JcuizUIqD9JYjajTeKLIho6JPw7 2R9IE9HhlHs3uAmp9fSjB8GMCtZwYpKkqAAtEaM2+QfFsAMqDUDBPXSjJ3Kq6TsijnUW Au8U95DYL4KGL9j4+raR7ZmmOmqt4ou3Tpf+s5Fg725lgsVX00PhQeSM05LRXJy95Y2g 4OEuMpkgkp3AT/vs1pIclmo4fNxgib9x1qMN+mpcuOCf5lYnViCQigknkOqsruzWxa5g 2dx2cgTFlAHx0/0pCqANGYUEW1hGk96+An6b0TuSSiaEAVlyJHeXo/crELZyscoUBJDW WW7g== MIME-Version: 1.0 X-Received: by 10.180.74.8 with SMTP id p8mr10000555wiv.32.1372184322679; Tue, 25 Jun 2013 11:18:42 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.180.183.84 with HTTP; Tue, 25 Jun 2013 11:18:42 -0700 (PDT) Date: Tue, 25 Jun 2013 14:18:42 -0400 X-Google-Sender-Auth: 7pl_47zvSa5sxGl6S7aAGn0DGhU Message-ID: From: Kerry Lynn To: core Content-Type: multipart/alternative; boundary=f46d043c7b9e1ea9ed04dffe8f0f Subject: [core] Media type text/html? 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, 25 Jun 2013 18:18:48 -0000 --f46d043c7b9e1ea9ed04dffe8f0f Content-Type: text/plain; charset=ISO-8859-1 Sorry if this is a dumb question. We have taken pains in the spec to define proxies and now have a WG draft describing CoAP/HTTP mapping best practices. However, the simplest method of connecting a coap server through a cross- proxy to the world as it exists today would appear to be by using a browser's natural media type: "text/html". Some (most?) browsers will not render text/plain. It seems text/html was removed in response to Cullen's : http://www.ietf.org/mail-archive/web/core/current/msg01048.html where he largely talks about "application/8bit" as being useless for determining the format of a resource (which I agree with). Was "text/html" removed for a good reason (e.g. nobody will ever want to host a www server on coap) or did we take issue #76 a bit too literally? http://tools.ietf.org/wg/core/trac/ticket/76 Thanks, -K- --f46d043c7b9e1ea9ed04dffe8f0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry if this is a dumb question.

We have taken pains in the spec to= define proxies and now have a WG draft
describing CoAP/HTTP mapping bes= t practices.

However, the simplest method of connecting a coap serve= r through a cross-
proxy to the world as it exists today would appear to be by using a browser= 's
natural media type: "text/html".=A0 Some (most?) browse= rs will not render text/plain.

It seems text/html was removed in res= ponse to Cullen's <rant/>:
http://www.ietf.org/mail-archive/web/core/current/msg010= 48.html where he
largely talks about "application/8bit" as= being useless for determining the
format of a resource (which I agree with).

Was "text/html"= removed for a good reason (e.g. nobody will ever want to host
a www ser= ver on coap) or did we take issue #76 a bit too literally?
http://tools.= ietf.org/wg/core/trac/ticket/76

Thanks, -K-
--f46d043c7b9e1ea9ed04dffe8f0f-- From cabo@tzi.org Tue Jun 25 14:04:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD8621E80B9 for ; Tue, 25 Jun 2013 14:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn85Chf-JJ1B for ; Tue, 25 Jun 2013 14:04:20 -0700 (PDT) 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 A9F2821E809F for ; Tue, 25 Jun 2013 14:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5PL43AL002706; Tue, 25 Jun 2013 23:04:03 +0200 (CEST) Received: from [192.168.217.105] (p54893C8A.dip0.t-ipconnect.de [84.137.60.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7C3CC3A76; Tue, 25 Jun 2013 23:04:03 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 25 Jun 2013 23:04:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kerry Lynn X-Mailer: Apple Mail (2.1508) Cc: core Subject: Re: [core] Media type text/html? 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, 25 Jun 2013 21:04:24 -0000 On Jun 25, 2013, at 20:18, Kerry Lynn wrote: > Was "text/html" removed for a good reason (e.g. nobody will ever want = to host > a www server on coap) or did we take issue #76 a bit too literally? I think we just tried to be a bit more conservative than the "everything = and the kitchen sink" approach we had in earlier versions. text/html certainly can be used in a "lightweight" fashion, so maybe we = should put it back. In Klaus' experimental semi-automated media type registry it has the = number: 2567 text/html (see http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt for the = complete list). Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Tue Jun 25 22:48:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B0721E8094 for ; Tue, 25 Jun 2013 22:48:20 -0700 (PDT) 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 VoN2AqSZQONw for ; Tue, 25 Jun 2013 22:48:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8037621E80F1 for ; Tue, 25 Jun 2013 22:48:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASW00254; Wed, 26 Jun 2013 05:48:13 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 26 Jun 2013 06:45:39 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 26 Jun 2013 06:46:31 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Wed, 26 Jun 2013 13:46:26 +0800 From: Bert Greevenbosch To: =?utf-8?B?6b2Q5pe76bmP?= , "core@ietf.org" Thread-Topic: [core] FW: New Version Notification for draft-zhu-core-groupauth-00.txt Thread-Index: Ac5wgtAdgysqV4bRQJ6fBAPCrl+yywAAWi+QAGqkD2A= Date: Wed, 26 Jun 2013 05:46:25 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D7843CC@szxeml558-mbx.china.huawei.com> References: <001401ce7088$54874f20$fd95ed60$@com> In-Reply-To: <001401ce7088$54874f20$fd95ed60$@com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] FW: New Version Notification for draft-zhu-core-groupauth-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, 26 Jun 2013 05:48:20 -0000 SGVsbG8gTWlucGVuZywNCg0KSSBoYXZlIHJldmlld2VkIHlvdXIgZHJhZnQgb24gZ3JvdXAgYXV0 aGVudGljYXRpb24uIEkgdGhpbmsgaXQgaXMgZ29vZCB0byBjb25zaWRlciB0aGlzIHRvcGljLg0K DQpJIGFsc28gbGlrZSB0aGUgbW9kdWxhciBhcHByb2FjaCwgaS5lLiBkZWZpbmUgYSBzcGVjaWFs IGVudGl0eSAoZ3JvdXAgYWdlbnQpIHRoYXQgcGVyZm9ybXMgdGhlIGF1dGhvcmlzYXRpb24gZm9y IHRoZSBvdGhlciBncm91cCBtZW1iZXJzLiBJbiB0aGlzIHdheSwgbm90IGFsbCBncm91cCBtZW1i ZXJzIG5lZWQgdG8gdGFsayBkaXJlY3RseSB0byB0aGUgbmV0d29yayBlbnRpdHksIGFuZCBiYXR0 ZXJ5IGNvc3QgYW5kIG5ldHdvcmsgdHJhZmZpYyBhcmUgcmVkdWNlZC4NCg0KSSB0aGluayB0aGUg ZHJhZnQgaXMgYSBnb29kIHN0YXJ0OyBhbHRob3VnaCBpdCB3aWxsIG5lZWQgdGhvcm91Z2ggc2Vj dXJpdHkgYW5hbHlzaXMuIEFsc28gd2UgbWF5IG5lZWQgdG8gY29uc2lkZXIgdGhlICJ0cmFuc2l0 aXZlIHRydXN0IiBuYXR1cmUgb2YgdGhlIGRyYWZ0IGFuZCB0aGluayBvZiB0aGUgZmVhc2liaWxp dHkgZm9yIHRoZSBuZXR3b3JrIGVudGl0eSB0byB2ZXJpZnkgdGhlIGluZGl2aWR1YWwgZ3JvdXAg bWVtYmVyJ3MgY3JlZGVudGlhbHMsIHdpdGggdGhlIGdyb3VwIGFnZW50IGFzIGFuIGludGVybWVk aWFyeS4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg6b2Q5pe76bmPDQpTZW50 OiAyMDEz5bm0NuaciDI05pelIDExOjEwDQpUbzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogW2Nv cmVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpodS1jb3JlLWdyb3Vw YXV0aC0wMC50eHQNCg0KSGkgZXZlcnlvbmUsDQoNClRoZSBhdXRob3JzIGhhdmUgc3VibWl0IGEg bmV3IGRyYWZ0IGZvciB0aGUgZ3JvdXAgYXV0aGVudGljYXRpb24uIFdlIHdpbGwgYXBwcmVjaWF0 ZSBpZiB5b3UgaGF2ZSBhIGxvb2sgYW5kIGdpdmUgdXMgYW55IGNvbW1lbnQgb3Igc3VnZ2VzdGlv bi4gVGhlIGxpbmsgaXMgYXMgYmVsb3cuDQoNCkhlcmUgaXMgYSBwcm9ibGVtIHRoYXQgZm9yIGdy b3VwIGNvbW11bmljYXRpb24gdGhlcmUgaXMgb25seSB1bmktY2FzdCBhdXRoZW50aWNhdGlvbiBp bnN0ZWFkIG9mIGdyb3VwIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBjYW4gYmUgdXNlZC4gVGhpcyBk cmFmdCB3YW50cyB0byBhbmFseXplIHRoZSBwcm9ibGVtLCB0byBzdW1tYXJpemUgZ3JvdXAgYXV0 aGVudGljYXRpb24gcmVxdWlyZW1lbnQgYW5kIHRvIHByb3ZpZGUgYSBmcmFtZXdvcmsgb2Ygc29s dXRpb25zLg0KDQpCUnMsDQpNaW5wZW5nDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7 tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxM+W5tDbmnIgyNOaXpSAxMDoxOQ0K5pS25Lu25Lq6 OiBZZSBUaWFuOyBNaW5wZW5nIFFpOyBKdWR5IFpodQ0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXpodS1jb3JlLWdyb3VwYXV0aC0wMC50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtemh1LWNvcmUtZ3JvdXBhdXRoLTAwLnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKdWR5IFpodSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVU RiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXpodS1jb3JlLWdyb3VwYXV0aA0KUmV2 aXNpb246CSAwMA0KVGl0bGU6CQkgR3JvdXAgQXV0aGVudGljYXRpb24NCkNyZWF0aW9uIGRhdGU6 CSAyMDEzLTA2LTI0DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBw YWdlczogMTANClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtemh1LWNvcmUtZ3JvdXBhdXRoLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpodS1jb3JlLWdyb3VwYXV0aA0K SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aHUtY29y ZS1ncm91cGF1dGgtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBncm91cCBjb21tdW5pY2F0aW9u IGlzIGRlc2lnbmVkIGZvciB0aGUgY29tbXVuaWNhdGlvbiBvZiBJbnRlcm5ldA0KICAgb2YgVGhp bmdzLiBBIHRocmVhdCBpcyBpZGVudGlmaWVkIGluIFtJLUQuaWV0Zi1jb3JlLWdyb3VwY29tbV0g dGhhdA0KICAgY3VycmVudCBEVExTIGJhc2VkIGFwcHJvYWNoIGlzIHVuaWNhc3Qgb3JpZW50ZWQg YW5kIHRoZXJlIGlzIG5vDQogICBzdXBwb3J0aW5nIG9uIGdyb3VwIGF1dGhlbnRpY2F0aW9uIGZl YXR1cmUuIFVuaWNhc3Qgb3JpZW50ZWQNCiAgIGF1dGhlbnRpY2F0aW9uIHdpbGwgY2F1c2luZyBz ZXJpb3VzIGJ1cmRlbiB3aGVuIGEgbGFyZ2UgbnVtYmVyIG9mDQogICB0ZXJtaW5hbCBub2RlcyB3 aWxsIGJlIGludm9sdmVkIGluZXZpdGFibHkuIEluIGFub3RoZXIgYXNwZWN0LCBzb21lDQogICB0 ZXJtaW5hbHMgd2lsbCBvd24gdGhlIHNhbWUgY2hhcmFjdGVyaXN0aWNzLCBzdWNoIGFzIG93bmlu ZyBzYW1lDQogICBmZWF0dXJlcywgaW4gdGhlIHNhbWUgcGxhY2UsIHdvcmtpbmcgaW4gdGhlIHNh bWUgdGltZSwgZXRjLiBXaXRoIHRoaXMNCiAgIG1lY2hhbmlzbSwgYWxsIHRlcm1pbmFscyBjYW4g YmUgYXV0aGVudGljYXRlZCB0b2dldGhlciB3aXRoIGxpdHRsZQ0KICAgc2lnbmFsaW5nIGFuZCBj YWxjdWxhdGlvbiBhdCB0aGUgc2FtZSB0aW1lLiBJdCB3aWxsIHJlZHVjZSB0aGUNCiAgIG5ldHdv cmsgYnVyZGVuIGFuZCBzYXZlIHRpbWUuIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBzZWN1cml0 eSBvZg0KICAgZ3JvdXAgYXV0aGVudGljYXRpb24gYW5kIGFuIGdyb3VwIGF1dGhlbnRpY2F0aW9u IGltcGxlbWVudGF0aW9uDQogICBtZXRob2QgZm9yIHRoZSBJbnRlcm5ldCBvZiB0aGluZ3MuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29y ZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29yZQ0K From qiminpeng@chinamobile.com Wed Jun 26 03:30:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6C21E8132 for ; Wed, 26 Jun 2013 03:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222] 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 3QiAxMYnYLpZ for ; Wed, 26 Jun 2013 03:30:10 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id F1A8A21E8133 for ; Wed, 26 Jun 2013 03:30:09 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151cac272399-27399; Wed, 26 Jun 2013 18:29:07 +0800 (CST) X-RM-TRANSID: 2ee151cac272399-27399 Received: from RonPC (unknown[10.2.51.87]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee251cac26eba5-5dc8f; Wed, 26 Jun 2013 18:29:07 +0800 (CST) X-RM-TRANSID: 2ee251cac26eba5-5dc8f From: =?utf-8?B?6b2Q5pe76bmP?= To: "'Bert Greevenbosch'" , References: <001401ce7088$54874f20$fd95ed60$@com> <46A1DF3F04371240B504290A071B4DB63D7843CC@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D7843CC@szxeml558-mbx.china.huawei.com> Date: Wed, 26 Jun 2013 18:30:03 +0800 Message-ID: <006101ce7258$1ef34130$5cd9c390$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5wgtAdgysqV4bRQJ6fBAPCrl+yywAAWi+QAGqkD2AACBujkA== Content-Language: zh-cn Subject: Re: [core] FW: New Version Notification for draft-zhu-core-groupauth-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, 26 Jun 2013 10:30:15 -0000 Hi Bert, Thanks for your comments! Our intention is to raise this issue and to call for attention on this = topic. It is a start as you said. It should be revised with comments.=20 For the feasibility for the network entity to verify the credentials, it = is the key point of our intention. Without the credential, the server = must authorize group agent to do authentication to the network entities = and must trust whatever the group agent reports. It will lose control if = the group agent becomes bad. So it is useful to include the some kind of = credentials of the group members. But as what you said, we should think = carefully about which kind of credential should be taken. If the = credential is too big, then it will not be feasible to make such = authentication. BRs, Minpeng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Bert Greevenbosch = [mailto:Bert.Greevenbosch@huawei.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B46=E6=9C=8826=E6=97=A5 = 13:46 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=BD=90=E6=97=BB=E9=B9=8F; core@ietf.org =E4=B8=BB=E9=A2=98: RE: [core] FW: New Version Notification for = draft-zhu-core-groupauth-00.txt Hello Minpeng, I have reviewed your draft on group authentication. I think it is good = to consider this topic. I also like the modular approach, i.e. define a special entity (group = agent) that performs the authorisation for the other group members. In = this way, not all group members need to talk directly to the network = entity, and battery cost and network traffic are reduced. I think the draft is a good start; although it will need thorough = security analysis. Also we may need to consider the "transitive trust" = nature of the draft and think of the feasibility for the network entity = to verify the individual group member's credentials, with the group = agent as an intermediary. What do you think? Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = =E9=BD=90=E6=97=BB=E9=B9=8F Sent: 2013=E5=B9=B46=E6=9C=8824=E6=97=A5 11:10 To: core@ietf.org Subject: [core] FW: New Version Notification for = draft-zhu-core-groupauth-00.txt Hi everyone, The authors have submit a new draft for the group authentication. We = will appreciate if you have a look and give us any comment or = suggestion. The link is as below. Here is a problem that for group communication there is only uni-cast = authentication instead of group authentication method can be used. This = draft wants to analyze the problem, to summarize group authentication = requirement and to provide a framework of solutions. BRs, Minpeng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B46=E6=9C=8824=E6=97=A5 = 10:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: Ye Tian; Minpeng Qi; Judy Zhu =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zhu-core-groupauth-00.txt A new version of I-D, draft-zhu-core-groupauth-00.txt has been successfully submitted by Judy Zhu and posted to the IETF repository. Filename: draft-zhu-core-groupauth Revision: 00 Title: Group Authentication Creation date: 2013-06-24 Group: Individual Submission Number of pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-zhu-core-groupauth-00.txt Status: = http://datatracker.ietf.org/doc/draft-zhu-core-groupauth Htmlized: http://tools.ietf.org/html/draft-zhu-core-groupauth-00 Abstract: The group communication is designed for the communication of Internet of Things. A threat is identified in [I-D.ietf-core-groupcomm] that current DTLS based approach is unicast oriented and there is no supporting on group authentication feature. Unicast oriented authentication will causing serious burden when a large number of terminal nodes will be involved inevitably. In another aspect, some terminals will own the same characteristics, such as owning same features, in the same place, working in the same time, etc. With this mechanism, all terminals can be authenticated together with little signaling and calculation at the same time. It will reduce the network burden and save time. This draft describes the security of group authentication and an group authentication implementation method for the Internet of things. = =20 The IETF Secretariat _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From kerlyn2001@gmail.com Wed Jun 26 05:27:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACA511E80E3 for ; Wed, 26 Jun 2013 05:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 wX+ew6bs44wY for ; Wed, 26 Jun 2013 05:27:32 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA921F9A71 for ; Wed, 26 Jun 2013 05:27:31 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id eh20so13049592obb.25 for ; Wed, 26 Jun 2013 05:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rJfpl8PI0ZFuTBlcCdZVxp1xwf4PYN1gx0Kq8VLtZAo=; b=hrjCExTnpq6F3VU+/1+vBK8sPKn5Q+x6Dj03PBe6lf69pB/MqBEjID1XqBq+r3tEHg xiuUVytOT7woAb0TCXr4ERomgC7YfWx4+Serv8X3YhozTMzVcKyqkehrLGvNdrY+Xdjf 6B91JGXx+J+WzMSu7saI2zGjd6w9jbWcS2SLu/4o5derpEpykdXe1Zl1Cq3ZkcKJzouX uQYoZ3sC+uZaEAEZoLLNGZOqOAJH5mj2zjAGKpqBiNLmDXTAm0okamVqsi/tad63Udid SKM3hAYezfcHGBuPtht5GyGf2xAxG4n3Ktv2hpMHL+5l+PLX8yjGQu9m/+c6aBQUqSVB Hqmg== MIME-Version: 1.0 X-Received: by 10.60.99.101 with SMTP id ep5mr342373oeb.98.1372249650968; Wed, 26 Jun 2013 05:27:30 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.94.239 with HTTP; Wed, 26 Jun 2013 05:27:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Jun 2013 08:27:30 -0400 X-Google-Sender-Auth: bCTg3aCjT6OisAYm3fKCYrAfnw4 Message-ID: From: Kerry Lynn To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7b33d0f0fd3d4e04e00dc410 Cc: core Subject: Re: [core] Media type text/html? 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, 26 Jun 2013 12:27:33 -0000 --047d7b33d0f0fd3d4e04e00dc410 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 5:04 PM, Carsten Bormann wrote: > On Jun 25, 2013, at 20:18, Kerry Lynn wrote: > > > Was "text/html" removed for a good reason (e.g. nobody will ever want t= o > host > > a www server on coap) or did we take issue #76 a bit too literally? > > I think we just tried to be a bit more conservative than the "everything > and the kitchen sink" approach we had in earlier versions. > > text/html certainly can be used in a "lightweight" fashion, so maybe we > should put it back. > In Klaus' experimental semi-automated media type registry it has the > number: > > 2567 text/html > > (see http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt for the > complete list). > > Thanks Carsten, I was unaware of that registry. That said, I would support a one-octet code for text/html at some point in the future... -K- > Gr=FC=DFe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --047d7b33d0f0fd3d4e04e00dc410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 5:04 PM, Carsten Bormann <cabo@tzi.org> w= rote:
On Jun 25, 2013, at 20:18, Kerry Lynn <kerlyn@ieee.org> wrote:

> Was "text/html" removed for a good reason (e.g. nobody will = ever want to host
> a www server on coap) or did we take issue #76 a bit too literally?
I think we just tried to be a bit more conservative than the "ev= erything and the kitchen sink" approach we had in earlier versions.
text/html certainly can be used in a "lightweight" fashion, so ma= ybe we should put it back.
In Klaus' experimental semi-automated media type registry it has the nu= mber:

=A0 =A0 =A02567 =A0 text/html

(see http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt for t= he complete list).

Thanks Carsten, I was unaware of that registry.=A0 Th= at said, I would support a one-octet
code for text/html at some point in= the future...

-K-
=A0
Gr=FC=DFe, Carsten

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

--047d7b33d0f0fd3d4e04e00dc410-- From cabo@tzi.org Wed Jun 26 05:50:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BF821F92D3 for ; Wed, 26 Jun 2013 05:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iYXY36xJFe6 for ; Wed, 26 Jun 2013 05:50:52 -0700 (PDT) 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 9DABB21F9130 for ; Wed, 26 Jun 2013 05:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5QCoeAm028454; Wed, 26 Jun 2013 14:50:40 +0200 (CEST) Received: from [192.168.217.105] (p548943E8.dip0.t-ipconnect.de [84.137.67.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 655263F4B; Wed, 26 Jun 2013 14:50:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 26 Jun 2013 14:50:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47A44CF4-CF42-45B1-A51F-813A3511A246@tzi.org> References: To: Kerry Lynn X-Mailer: Apple Mail (2.1508) Cc: core Subject: Re: [core] Media type text/html? 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, 26 Jun 2013 12:50:56 -0000 On Jun 26, 2013, at 14:27, Kerry Lynn wrote: > text/html certainly can be used in a "lightweight" fashion, so maybe = we should put it back. > In Klaus' experimental semi-automated media type registry it has the = number: >=20 > 2567 text/html >=20 > (see http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt for the = complete list). >=20 > Thanks Carsten, I was unaware of that registry. =20 One limitation of that registry is that it doesn't provide any = parameters. Not all media types have sensible default parameters. In this case, the default value for the charset parameter of US-ASCII = applies (RFC 2046). (HTTP defines a different, even less reasonable default, but fortunately = that doesn't apply here.) (See also RFC 6657 to further muddy the water.) Of course, HTML has to supply an appropriate = default value, but that is 22 more bytes of overhead to carry around. = Or you can use character references, but that is per-character overhead. > That said, I would support a one-octet > code for text/html at some point in the future... (I'm not sure that byte makes much of a difference for something as = verbose as HTML. But I agree that if there is a use case for "text/html; charset=3Dutf-8", = we should register it.) Once the IANA registry is created, you can submit a request; see the = registration policies in section 12.3 of core-coap. Gr=FC=DFe, Carsten From rick.bullotta@thingworx.com Wed Jun 26 06:00:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F5F21F9942 for ; Wed, 26 Jun 2013 06:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcXP27M4czcZ for ; Wed, 26 Jun 2013 06:00:46 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 74EC311E81BF for ; Wed, 26 Jun 2013 06:00:46 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 26 Jun 2013 13:00:44 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) with mapi id 15.00.0702.005; Wed, 26 Jun 2013 13:00:44 +0000 From: Rick Bullotta To: Carsten Bormann Thread-Topic: [core] Media type text/html? Thread-Index: AQHOcdB1WtB0YbSXhkuaDqG/gaqenZlG62gAgAECBACAAAZ4gIAAAtAj Date: Wed, 26 Jun 2013 13:00:43 +0000 Message-ID: References: , <47A44CF4-CF42-45B1-A51F-813A3511A246@tzi.org> In-Reply-To: <47A44CF4-CF42-45B1-A51F-813A3511A246@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.59.2.242] x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(377454003)(24454002)(47976001)(63696002)(50986001)(31966008)(51856001)(76796001)(76786001)(36756003)(33656001)(74876001)(53806001)(76482001)(56816003)(47446002)(15202345003)(74366001)(77096001)(79102001)(74706001)(47736001)(74502001)(74662001)(77982001)(59766001)(49866001)(4396001)(46102001)(69226001)(80022001)(54316002)(66066001)(65816001)(56776001)(81542001)(54356001)(16406001)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB001; H:BLUPR06MB001.namprd06.prod.outlook.com; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: Kerry Lynn , core Subject: Re: [core] Media type text/html? 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, 26 Jun 2013 13:00:52 -0000 Is there a range of media type code reserved for "application specific" use= ? Seems unwieldy to seek approval for each new media type. Perhaps a generi= c code for application/user-defined that would be followed by a String for = the specific type? Counting bytes at the expense of flexibility and extens= ibility seems a risky bet against Moore's law. =20 On Jun 26, 2013, at 8:51 AM, "Carsten Bormann" wrote: > On Jun 26, 2013, at 14:27, Kerry Lynn wrote: >=20 >> text/html certainly can be used in a "lightweight" fashion, so maybe we = should put it back. >> In Klaus' experimental semi-automated media type registry it has the num= ber: >>=20 >> 2567 text/html >>=20 >> (see http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt for the comple= te list). >>=20 >> Thanks Carsten, I was unaware of that registry. =20 >=20 > One limitation of that registry is that it doesn't provide any parameters= . > Not all media types have sensible default parameters. >=20 > In this case, the default value for the charset parameter of US-ASCII app= lies (RFC 2046). > (HTTP defines a different, even less reasonable default, but fortunately = that doesn't apply here.) >=20 > (See also RFC 6657 to further muddy the water.) >=20 > Of course, HTML has to supply an appropriate def= ault value, but that is 22 more bytes of overhead to carry around. Or you = can use character references, but that is per-character overhead. >=20 >> That said, I would support a one-octet >> code for text/html at some point in the future... >=20 > (I'm not sure that byte makes much of a difference for something as verbo= se as HTML. > But I agree that if there is a use case for "text/html; charset=3Dutf-8",= we should register it.) >=20 > Once the IANA registry is created, you can submit a request; see the regi= stration policies in section 12.3 of core-coap. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Wed Jun 26 06:40:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECF521E8154 for ; Wed, 26 Jun 2013 06:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llMIlNbZ+iXL for ; Wed, 26 Jun 2013 06:40:06 -0700 (PDT) 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 66E2821E814C for ; Wed, 26 Jun 2013 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5QDdgqu025273; Wed, 26 Jun 2013 15:39:43 +0200 (CEST) Received: from [192.168.217.105] (p548943E8.dip0.t-ipconnect.de [84.137.67.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7C13D3FDB; Wed, 26 Jun 2013 15:39:42 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 26 Jun 2013 15:39:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54088BD1-68E9-4F48-9F3E-A4932111543B@tzi.org> References: , <47A44CF4-CF42-45B1-A51F-813A3511A246@tzi.org> To: Rick Bullotta X-Mailer: Apple Mail (2.1508) Cc: Kerry Lynn , core Subject: Re: [core] Media type text/html? 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, 26 Jun 2013 13:40:12 -0000 On Jun 26, 2013, at 15:00, Rick Bullotta = wrote: > Is there a range of media type code reserved for "application = specific" use? How would that work? How would one endpoint find out what "application" = another endpoint is part of? That said, if you just want to play around in the lab, there is a range = reserved for experiments (65000..65535). But if you want to build something that is going to get stuck to a wall = for a decade or two, maybe the effort to get a number is manageable. > Seems unwieldy to seek approval for each new media type. The range 10000 to 64999 is "first come first served", so it is not that = hard to get a number. > Perhaps a generic code for application/user-defined that would be = followed by a String for the specific type? There already is application/octet-stream (ct=3D42) for things that the = server doesn't want to further specify. In your example, what would you put into that String? How is that name space governed? If it is a media type name, just get a number. This is so much of a no-brainer that Klaus has set up his experiment to = see whether that can't be automated. If it is something else, maybe the best place is in the data object? E.g., for JSON, there are conventions to put information about the = "context" or "profile" of the object right into it. So you could use = application/json (ct=3D50) together with that. But maybe you have a use case that we haven't properly considered yet, = and I'm eager to hear about it. Gr=FC=DFe, Carsten From rick.bullotta@thingworx.com Wed Jun 26 07:18:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF181F0D34 for ; Wed, 26 Jun 2013 07:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7g-M-oqOHjt for ; Wed, 26 Jun 2013 07:18:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE521F0D3C for ; Wed, 26 Jun 2013 07:18:12 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 26 Jun 2013 14:18:09 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) with mapi id 15.00.0702.005; Wed, 26 Jun 2013 14:18:09 +0000 From: Rick Bullotta To: Carsten Bormann Thread-Topic: [core] Media type text/html? Thread-Index: AQHOcdB1WtB0YbSXhkuaDqG/gaqenZlG62gAgAECBACAAAZ4gIAAAtAjgAAK3oCAAAlV0A== Date: Wed, 26 Jun 2013 14:18:08 +0000 Message-ID: <4b5920d435a047bd9f7891e29bb3357e@BLUPR06MB001.namprd06.prod.outlook.com> References: , <47A44CF4-CF42-45B1-A51F-813A3511A246@tzi.org> <54088BD1-68E9-4F48-9F3E-A4932111543B@tzi.org> In-Reply-To: <54088BD1-68E9-4F48-9F3E-A4932111543B@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [96.245.114.98] x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(13464003)(377454003)(24454002)(31966008)(47976001)(50986001)(63696002)(51856001)(76796001)(76786001)(33646001)(76576001)(74876001)(53806001)(76482001)(56816003)(47446002)(74366001)(77096001)(79102001)(74706001)(74316001)(47736001)(74502001)(74662001)(77982001)(59766001)(49866001)(4396001)(46102001)(69226001)(80022001)(54316002)(65816001)(66066001)(81542001)(56776001)(54356001)(16406001)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB001; H:BLUPR06MB001.namprd06.prod.outlook.com; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: Kerry Lynn , core Subject: Re: [core] Media type text/html? 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, 26 Jun 2013 14:18:24 -0000 Hi, Carsten. Personally, I think you have it nailed down fairly well "as is". It was mor= e a general question about the process of introducing new media types. Per= sonally, I'm not a big fan of lots of derivative media types/mime types (e.= g. lots of domain or usage-specific JSON or XML subtypes). I think those s= hould be in the data/content or other domain-specific headers, as you sugge= st. I do think, however, that given the COAP desire to support efficient consum= ption of resources (network and otherwise), perhaps some of the binary JSON= -like types could/will be formalized or become more stable in the near futu= re, and those may be good additions to the list of supported types. The more I dive into the COAP work that you all have done, the more impress= ed I am with the depth of thought that went into many of the aspects. I wi= ll admit that I have probably only scratched the surface of my understandin= g of the breadth of the COAP RFC's, but do plan on learning more and hopefu= lly contributing to the effort. Are there any general resources/presentat= ions/papers that you might recommend that help provide a high level view of= COAP and how the pieces fit together?=20 Cheers, Rick ThingWorx -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Wednesday, June 26, 2013 9:40 AM To: Rick Bullotta Cc: Kerry Lynn; core Subject: Re: [core] Media type text/html? On Jun 26, 2013, at 15:00, Rick Bullotta wrot= e: > Is there a range of media type code reserved for "application specific" u= se? How would that work? How would one endpoint find out what "application" an= other endpoint is part of? That said, if you just want to play around in the lab, there is a range res= erved for experiments (65000..65535). But if you want to build something that is going to get stuck to a wall for= a decade or two, maybe the effort to get a number is manageable. > Seems unwieldy to seek approval for each new media type. The range 10000 to 64999 is "first come first served", so it is not that ha= rd to get a number. > Perhaps a generic code for application/user-defined that would be followe= d by a String for the specific type? There already is application/octet-stream (ct=3D42) for things that the ser= ver doesn't want to further specify. In your example, what would you put into that String? How is that name space governed? If it is a media type name, just get a number. This is so much of a no-brainer that Klaus has set up his experiment to see= whether that can't be automated. If it is something else, maybe the best place is in the data object? E.g., for JSON, there are conventions to put information about the "context= " or "profile" of the object right into it. So you could use application/j= son (ct=3D50) together with that. But maybe you have a use case that we haven't properly considered yet, and = I'm eager to hear about it. Gr=FC=DFe, Carsten From cabo@tzi.org Wed Jun 26 07:41:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F921F9989 for ; Wed, 26 Jun 2013 07:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nR4CegDMp6pl for ; Wed, 26 Jun 2013 07:41:53 -0700 (PDT) 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 D88EE21E8126 for ; Wed, 26 Jun 2013 07:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5QEfheG016723; Wed, 26 Jun 2013 16:41:43 +0200 (CEST) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2518530B3; Wed, 26 Jun 2013 16:41:43 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4b5920d435a047bd9f7891e29bb3357e@BLUPR06MB001.namprd06.prod.outlook.com> Date: Wed, 26 Jun 2013 16:41:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <47A44CF4-CF42-45B1-A51F-813A3511A246@tzi.org> <54088BD1-68E9-4F48-9F3E-A4932111543B@tzi.org> <4b5920d435a047bd9f7891e29bb3357e@BLUPR06MB001.namprd06.prod.outlook.com> To: Rick Bullotta X-Mailer: Apple Mail (2.1508) Cc: "core \(core@ietf.org\)" Subject: Re: [core] Media type text/html? 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, 26 Jun 2013 14:41:57 -0000 Hi Rick, > Personally, I think you have it nailed down fairly well "as is".=20 Thanks! > I do think, however, that given the COAP desire to support efficient = consumption of resources (network and otherwise), perhaps some of the = binary JSON-like types could/will be formalized or become more stable in = the near future, and those may be good additions to the list of = supported types. Working on that subject right now: http://tools.ietf.org/html/draft-bormann-cbor-02 > Are there any general resources/presentations/papers that you might = recommend that help provide a high level view of COAP and how the pieces = fit together?=20 There is always the CoRE roadmap (which, however, is ripe for another = update): http://tools.ietf.org/html/draft-bormann-core-roadmap-04 If you have access to IEEE documents, you might want to look at: http://doi.ieeecomputersociety.org/10.1109/MIC.2012.29 And, of course, the best resource is this mailing list. Gr=FC=DFe, Carsten From rick.bullotta@thingworx.com Wed Jun 26 07:57:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147E921F9A03 for ; Wed, 26 Jun 2013 07:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl0TpSGOJ5LB for ; Wed, 26 Jun 2013 07:56:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id AE1E421F99E1 for ; Wed, 26 Jun 2013 07:56:27 -0700 (PDT) Received: from BLUPR06MB001.namprd06.prod.outlook.com (10.242.190.139) by BLUPR06MB004.namprd06.prod.outlook.com (10.242.190.155) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 26 Jun 2013 14:56:25 +0000 Received: from BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) by BLUPR06MB001.namprd06.prod.outlook.com ([169.254.1.125]) with mapi id 15.00.0702.005; Wed, 26 Jun 2013 14:56:25 +0000 From: Rick Bullotta To: Carsten Bormann Thread-Topic: [core] Media type text/html? Thread-Index: AQHOcdB1WtB0YbSXhkuaDqG/gaqenZlG62gAgAECBACAAAZ4gIAAAtAjgAAK3oCAAAlV0IAACAMAgAAAtIA= Date: Wed, 26 Jun 2013 14:56:25 +0000 Message-ID: References: , <47A44CF4-CF42-45B1-A51F-813A3511A246@tzi.org> <54088BD1-68E9-4F48-9F3E-A4932111543B@tzi.org> <4b5920d435a047bd9f7891e29bb3357e@BLUPR06MB001.namprd06.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [96.245.114.98] x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(41574002)(189002)(377454003)(13464003)(74662001)(56816003)(77096001)(74366001)(81342001)(66066001)(79102001)(74316001)(76786001)(74502001)(81542001)(31966008)(76576001)(76796001)(47446002)(33646001)(16406001)(74706001)(74876001)(53806001)(69226001)(54356001)(50986001)(59766001)(77982001)(4396001)(54316002)(76482001)(49866001)(47736001)(65816001)(47976001)(80022001)(51856001)(63696002)(56776001)(46102001)(15202345003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB004; H:BLUPR06MB001.namprd06.prod.outlook.com; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thingworx.com Cc: "core \(core@ietf.org\)" Subject: Re: [core] Media type text/html? 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, 26 Jun 2013 14:57:01 -0000 Hi, Carsten. Excellent! Thanks. =20 Are there separate mailing lists for each of the subtasks, or is this the p= lace to discuss things like CBOR? One other area I think is crucial to "get right" is future proofing date/ti= me handling (resolution, TZ consideration, and all of the stuff that keeps = us awake at night doing real projects). Accurate time resolution in the na= nosecond range will soon be an essential capability for IoT/M2M application= s (the energy grid is a great example), and I think the IETF/COAP seem a gr= eat place to undertake that discussion and champion a solution/recommendati= on. MfG, Rick -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Wednesday, June 26, 2013 10:42 AM To: Rick Bullotta Cc: core (core@ietf.org) Subject: Re: [core] Media type text/html? Hi Rick, > Personally, I think you have it nailed down fairly well "as is".=20 Thanks! > I do think, however, that given the COAP desire to support efficient cons= umption of resources (network and otherwise), perhaps some of the binary JS= ON-like types could/will be formalized or become more stable in the near fu= ture, and those may be good additions to the list of supported types. Working on that subject right now: http://tools.ietf.org/html/draft-bormann-cbor-02 > Are there any general resources/presentations/papers that you might recom= mend that help provide a high level view of COAP and how the pieces fit tog= ether?=20 There is always the CoRE roadmap (which, however, is ripe for another updat= e): http://tools.ietf.org/html/draft-bormann-core-roadmap-04 If you have access to IEEE documents, you might want to look at: http://doi.ieeecomputersociety.org/10.1109/MIC.2012.29 And, of course, the best resource is this mailing list. Gr=FC=DFe, Carsten From cabo@tzi.org Wed Jun 26 09:20:32 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FE411E8104 for ; Wed, 26 Jun 2013 09:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEJpiH9tl4mY for ; Wed, 26 Jun 2013 09:20:27 -0700 (PDT) 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 4E58F21F8904 for ; Wed, 26 Jun 2013 09:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5QGKOsN011001; Wed, 26 Jun 2013 18:20:24 +0200 (CEST) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D6A27315A; Wed, 26 Jun 2013 18:20:23 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 26 Jun 2013 18:20:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <47A44CF4-CF42-45B1-A51F-813A3511A246@tzi.org> <54088BD1-68E9-4F48-9F3E-A4932111543B@tzi.org> <4b5920d435a047bd9f7891e29bb3357e@BLUPR06MB001.namprd06.prod.outlook.com> To: Rick Bullotta X-Mailer: Apple Mail (2.1508) Cc: "core \(core@ietf.org\)" Subject: Re: [core] Media type text/html? 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, 26 Jun 2013 16:20:32 -0000 > Are there separate mailing lists for each of the subtasks, or is this = the place to discuss things like CBOR? The CoRE WG is chartered for the transfer protocol (CoAP) and the = related discovery and security specifications. Details: http://datatracker.ietf.org/wg/core/charter/ No IETF WG is officially chartered for CBOR; the discussion on CBOR has = so far happened in apps-discuss@ietf.org (the mailing list of the = APPAREA and APPSAWG WGs). https://www.ietf.org/mailman/listinfo/apps-discuss > One other area I think is crucial to "get right" is future proofing = date/time handling (resolution, TZ consideration, and all of the stuff = that keeps us awake at night doing real projects). Accurate time = resolution in the nanosecond range will soon be an essential capability = for IoT/M2M applications (the energy grid is a great example), Absolutely. CBOR is designed to be extensible with respect to the data formats = supported ("tags"). So far, we have tags for UTC-based time formats (both string-based and = binary) in the base document. If you need nanosecond resolution, you probably also need a monotonic = time scale (no leap seconds, e.g. on the TAI or GPS time scale). That could easily be added once we understand the requirements. > and I think the IETF/COAP seem a great place to undertake that = discussion and champion a solution/recommendation. Thanks again. We maybe have to do a bit of mailing list juggling here. When it comes to actually working on IETF specifications, we try to have = quite focused WGs. We don't have something like a general "M2M" activity. The CoRE WG is the WG that is closest to an M2M WG on the application = layer, but it is focusing on the REST aspects. CBOR may be useful outside of M2M, too, so we are having the general = CBOR discussion over in apps-discuss. But let's collect the M2M requirements right here on the CoRE mailing = list. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Wed Jun 26 11:04:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D39811E8117 for ; Wed, 26 Jun 2013 11:04:26 -0700 (PDT) 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 4ORG179wyxxW for ; Wed, 26 Jun 2013 11:04:25 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B254811E80F5 for ; Wed, 26 Jun 2013 11:04:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:60782 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uru4g-0004B8-Va; Wed, 26 Jun 2013 20:04:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, hartke@tzi.org X-Trac-Project: core Date: Wed, 26 Jun 2013 18:04:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/204#comment:4 Message-ID: <066.12a49700eddb0edec56d04c3d16db7e2@trac.tools.ietf.org> References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> X-Trac-Ticket-ID: 204 In-Reply-To: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130626180425.B254811E80F5@ietfa.amsl.com> Resent-Date: Wed, 26 Jun 2013 11:04:25 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #204: Introduce a minimal version of Pledge 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, 26 Jun 2013 18:04:26 -0000 #204: Introduce a minimal version of Pledge Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: Done in observe-09 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | observe@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: post-WGLC-1 Priority: major | Version: observe-05 Component: observe | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Jun 27 06:18:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ADC21F9D98 for ; Thu, 27 Jun 2013 06:18:23 -0700 (PDT) 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 x4wrU9Uc4DvW for ; Thu, 27 Jun 2013 06:18:23 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5D73E21F9D96 for ; Thu, 27 Jun 2013 06:18:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:38145 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UsC5Z-0004Ys-OM; Thu, 27 Jun 2013 15:18:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, zach@sensinode.com, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 27 Jun 2013 13:18:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/331#comment:13 Message-ID: <066.6bbe86b4067bd5ec9b6b93a88d0cd252@trac.tools.ietf.org> References: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> X-Trac-Ticket-ID: 331 In-Reply-To: <051.f9ce7817dd5ed61c23d61b25fca56ef0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, zach@sensinode.com, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130627131823.5D73E21F9D96@ietfa.amsl.com> Resent-Date: Thu, 27 Jun 2013 06:18:23 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #331: No way to indicate preferred size in a 4.13 error 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, 27 Jun 2013 13:18:24 -0000 #331: No way to indicate preferred size in a 4.13 error Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1413]: Fix #331 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: post-IESG-1 Priority: major | Version: coap-17 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Jun 27 06:38:42 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5C421F9D6A for ; Thu, 27 Jun 2013 06:38:42 -0700 (PDT) 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 ChIG3mvS-YWg for ; Thu, 27 Jun 2013 06:38:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1AC21F9D5F for ; Thu, 27 Jun 2013 06:38:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:39518 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UsCPE-00074u-IN; Thu, 27 Jun 2013 15:38:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, kovatsch@inf.ethz.ch, cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Thu, 27 Jun 2013 13:38:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/329#comment:4 Message-ID: <066.0ade26d8777b80179ea0d4afed7419dd@trac.tools.ietf.org> References: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org> X-Trac-Ticket-ID: 329 In-Reply-To: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, kovatsch@inf.ethz.ch, 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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130627133842.4E1AC21F9D5F@ietfa.amsl.com> Resent-Date: Thu, 27 Jun 2013 06:38:41 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #329: Ambiguity of Accept option still considered a problem 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, 27 Jun 2013 13:38:43 -0000 #329: Ambiguity of Accept option still considered a problem Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1414]: Fix #329 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: protocol | Status: closed defect | Milestone: post-IESG-1 Priority: major | Version: Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Thu Jun 27 06:48:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D2E21F9DFB for ; Thu, 27 Jun 2013 06:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.023 X-Spam-Level: X-Spam-Status: No, score=-106.023 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 O5vLf+pxhdBJ for ; Thu, 27 Jun 2013 06:48:33 -0700 (PDT) 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 9A9BE21F9E00 for ; Thu, 27 Jun 2013 06:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5RDmTTL029703 for ; Thu, 27 Jun 2013 15:48:29 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 47D0238C5; Thu, 27 Jun 2013 15:48:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jun 2013 15:48:28 +0200 To: "core (core@ietf.org)" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [core] =?utf-8?q?=F0=9F=94=94=3A_coap-18_ready_for_submission?= 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, 27 Jun 2013 13:48:38 -0000 Based on the discussions around tickets #329 and #331, I have prepared = an editors' draft for coap-18. This has two technical changes: Changes from ietf-17 to ietf-18: Address comments from the IESG reviews. o Accept is now critical. o Add Size1 option for 4.13 responses. There are also some more editorial fixes based on the IESG comments. See the diff at: http://www.tzi.org/~cabo/draft-ietf-core-coap-17-from-xx.diff.html While we have discussed these two changes extensively on the mailing = list in the context of the two tickets and seem to have reached WG = consensus on the resolution, I would like to specifically call attention = to these changes one more time. Unless there is some surprise last-minute feedback, we'll submit coap-18 = in 24 h from now and ask the IESG to reconsider their ballot positions. Gr=FC=DFe, Carsten From internet-drafts@ietf.org Thu Jun 27 06:57:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE321F9D90; Thu, 27 Jun 2013 06:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 NJ8CnLYACdQ8; Thu, 27 Jun 2013 06:57:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF7321F9D92; Thu, 27 Jun 2013 06:57:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130627135713.14212.85789.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2013 06:57:13 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-12.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, 27 Jun 2013 13:57:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-12.txt Pages : 35 Date : 2013-06-27 Abstract: 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. The present revision -11 fixes one example and adds the text and examples about the Block/Observe interaction, taken from -observe. It also adds a couple of formatting bugs from the new xml2rfc. The "grand rewrite" is next. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-block-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Thu Jun 27 07:10:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9F821F9E2A for ; Thu, 27 Jun 2013 07:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 f4Xs46FYR2Z0 for ; Thu, 27 Jun 2013 07:10:18 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4421F9E07 for ; Thu, 27 Jun 2013 07:10:18 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jun 2013 10:10:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 27 Jun 2013 10:10:15 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQ6IGNvYXAtMTggcmVhZHkgZm9yIHN1Yg==?= =?utf-8?B?bWlzc2lvbg==?= Thread-Index: Ac5zPT/yMXGB+QohSiqa3SmizOMzCQAAnAhg References: From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 27 Jun 2013 14:10:16.0918 (UTC) FILETIME=[0CBDA760:01CE7340] Cc: core@ietf.org Subject: Re: [core] =?utf-8?q?=F0=9F=94=94=3A_coap-18_ready_for_submission?= 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, 27 Jun 2013 14:10:22 -0000 SGkgQ2Fyc3RlbiwNCg0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGVzLiAgSXQgbG9va3MgZ29vZCB0 byBtZS4NCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQpBa2Jhcg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NClNlbnQ6IFRodXJz ZGF5LCBKdW5lIDI3LCAyMDEzIDk6NDggQU0NClRvOiBjb3JlIChjb3JlQGlldGYub3JnKQ0KU3Vi amVjdDogW2NvcmVdIPCflJQ6IGNvYXAtMTggcmVhZHkgZm9yIHN1Ym1pc3Npb24NCg0KQmFzZWQg b24gdGhlIGRpc2N1c3Npb25zIGFyb3VuZCB0aWNrZXRzICMzMjkgYW5kICMzMzEsIEkgaGF2ZSBw cmVwYXJlZCBhbiBlZGl0b3JzJyBkcmFmdCBmb3IgY29hcC0xOC4NCg0KVGhpcyBoYXMgdHdvIHRl Y2huaWNhbCBjaGFuZ2VzOg0KDQogICBDaGFuZ2VzIGZyb20gaWV0Zi0xNyB0byBpZXRmLTE4OiBB ZGRyZXNzIGNvbW1lbnRzIGZyb20gdGhlIElFU0cNCiAgIHJldmlld3MuDQoNCiAgIG8gIEFjY2Vw dCBpcyBub3cgY3JpdGljYWwuDQoNCiAgIG8gIEFkZCBTaXplMSBvcHRpb24gZm9yIDQuMTMgcmVz cG9uc2VzLg0KDQpUaGVyZSBhcmUgYWxzbyBzb21lIG1vcmUgZWRpdG9yaWFsIGZpeGVzIGJhc2Vk IG9uIHRoZSBJRVNHIGNvbW1lbnRzLg0KDQpTZWUgdGhlIGRpZmYgYXQ6DQoNCmh0dHA6Ly93d3cu dHppLm9yZy9+Y2Fiby9kcmFmdC1pZXRmLWNvcmUtY29hcC0xNy1mcm9tLXh4LmRpZmYuaHRtbA0K DQpXaGlsZSB3ZSBoYXZlIGRpc2N1c3NlZCB0aGVzZSB0d28gY2hhbmdlcyBleHRlbnNpdmVseSBv biB0aGUgbWFpbGluZyBsaXN0IGluIHRoZSBjb250ZXh0IG9mIHRoZSB0d28gdGlja2V0cyBhbmQg c2VlbSB0byBoYXZlIHJlYWNoZWQgV0cgY29uc2Vuc3VzIG9uIHRoZSByZXNvbHV0aW9uLCBJIHdv dWxkIGxpa2UgdG8gc3BlY2lmaWNhbGx5IGNhbGwgYXR0ZW50aW9uIHRvIHRoZXNlIGNoYW5nZXMg b25lIG1vcmUgdGltZS4NCg0KVW5sZXNzIHRoZXJlIGlzIHNvbWUgc3VycHJpc2UgbGFzdC1taW51 dGUgZmVlZGJhY2ssIHdlJ2xsIHN1Ym1pdCBjb2FwLTE4IGluIDI0IGggZnJvbSBub3cgYW5kIGFz ayB0aGUgSUVTRyB0byByZWNvbnNpZGVyIHRoZWlyIGJhbGxvdCBwb3NpdGlvbnMuDQoNCkdyw7zD n2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From stokcons@xs4all.nl Fri Jun 28 01:54:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFD121F9DEF for ; Fri, 28 Jun 2013 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZeq3x4Esn3U for ; Fri, 28 Jun 2013 01:54:32 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 973C521F9C4B for ; Fri, 28 Jun 2013 01:54:32 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube1.xs4all.net [194.109.20.195]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5S8sRKW005153 for ; Fri, 28 Jun 2013 10:54:31 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-96-23.w90-28.abo.wanadoo.fr ([90.28.135.23]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 28 Jun 2013 10:54:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Jun 2013 10:54:27 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <3423296c48c00d2b60c7a309556b46ac@xs4all.nl> X-Sender: stokcons@xs4all.nl (RGVjpyUrlNNEjgcrkwlBamPIPRvG9wxg) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 08:54:43 -0000 A new version of I-D, draft-vanderstok-core-comi-00.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Filename: draft-vanderstok-core-comi Revision: 00 Title: CoAp Management Interfaces Creation date: 2013-06-28 Group: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-00.txt Status: http://datatracker.ietf.org/doc/draft-vanderstok-core-comi Htmlized: http://tools.ietf.org/html/draft-vanderstok-core-comi-00 Abstract: The draft describes an interface based on CoAP to manage constrained devices. Access to existing MIBs is included. The proposed integration of CoAP with SNMP reduces the code size by removing an important part of the SNMP code. The draft lists a set of CoMI objects that describe the operational settings of the applications on the device. A majority of them is taken over from other drafts to provide one uniform CoMI based access. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. The IETF Secretariat From internet-drafts@ietf.org Fri Jun 28 09:13:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304FF21F9C59; Fri, 28 Jun 2013 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 w-1UzG9KNz-e; Fri, 28 Jun 2013 09:13:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC30421F9BBE; Fri, 28 Jun 2013 09:13:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628161308.12367.57258.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 09:13:08 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-18.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, 28 Jun 2013 16:13:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Constrained Application Protocol (CoAP) Author(s) : Zach Shelby Klaus Hartke Carsten Bormann Filename : draft-ietf-core-coap-18.txt Pages : 118 Date : 2013-06-28 Abstract: The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-coap-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jun 28 09:13:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F08621F9C29 for ; Fri, 28 Jun 2013 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 5t3syVpUL+ap; Fri, 28 Jun 2013 09:13:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2921F9C3A; Fri, 28 Jun 2013 09:13:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org, barryleiba@computer.org, martin.stiemerling@neclab.eu, presnick@qti.qualcomm.com, turners@ieca.com X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628161308.12367.46159.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 09:13:08 -0700 Subject: [core] New Version Notification - draft-ietf-core-coap-18.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, 28 Jun 2013 16:13:09 -0000 A new version (-18) has been submitted for draft-ietf-core-coap: http://www.ietf.org/internet-drafts/draft-ietf-core-coap-18.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-18 IETF Secretariat. From presnick@qti.qualcomm.com Fri Jun 28 11:56:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1421F9C20; Fri, 28 Jun 2013 11:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 MB+z1cn-Jph9; Fri, 28 Jun 2013 11:56:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC4621F9A82; Fri, 28 Jun 2013 11:56:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628185607.19566.66789.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 11:56:07 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Pete Resnick's Yes on draft-ietf-core-coap-18: (with COMMENT) 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, 28 Jun 2013 18:56:14 -0000 Pete Resnick has entered the following ballot position for draft-ietf-core-coap-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my more serious concerns. Nothing blocking, but for your consideration: By section number: 4.2/4.3: "Reject" in the sense it is talked about in these sections is an internal state change. That's confusing to me, as the normal sense of the English word implies a party that "hears about" the rejection. (It's hard to me to think of a circumstance where someone or something was "rejected" and only the rejector ever knew about it.) In your use, "silently ignore" is one possible form of rejection. That's just weird. If you're going to do this, I'd define the term up front. Maybe even capitalize "Reject" wherever you use it. Either way, in both 4.2 and 4.3, "MUST reject" is probably wrong (since that's an internal state and nothing a protocol requirement is useful for) and "MAY involve sending" is a strange construction. 4.5: I think the MAYs confuse things and might encourage implementers to take that path. Instead of: This rule MAY be relaxed in case the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples for relaxed message deduplication: = I suggest: "Exceptions to this are when the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples of these exceptions:". Also: As a general rule that MAY be relaxed based on the specific semantics of a message, the recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once. = I suggest: "The recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once, though the specific semantics of the message might dictate an exception." 4.6: I feel like this section is really one big implementation note: Because it is a layer violation, it's not clear to me that any implementer has the ability to figure out much of this. (For example, the idea that an implementer would be willing to -- or even know how to -- set the Do Not Fragment bit or figure out the Path MTU is a bit hopeful.) I have no objection to this section, but it might be better as an implementation note rather than a set of protocol instructions. 5.3.2: Change "the client will likely send a Reset message so it does not receive any more retransmissions" to "the client will send". A client that has lost state that receives what it will see as a random CON message will always send back a Reset. 5.4.6: If it were me, I would have put the NoCacheKey bits in the high four bits of the most significant byte so that you could simply do a <224 test for cache-matching options. I suppose this ship has sailed. 5.5.1: The implementation note notwithstanding, I don't understand why Content-Format is not a SHOULD. 8.1: A server SHOULD be aware that a request arrived via multicast, e.g. by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if available. That SHOULD is not meaningful. It is useful, not required with exceptions (as SHOULD indicates), for the server to know that it is using multicast. This also gives a reason not to allow RST on *any* NON messages. 12.1: I think it would be much easier to figure these out if you separated out the bit fields of code type and code, and then had sub-registries for request codes, success codes, client error codes, and server error codes.