From nobody Wed Apr 5 19:07:43 2017 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8E21271DF; Wed, 5 Apr 2017 19:07:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Thomson To: Cc: alto@ietf.org, ietf@ietf.org, draft-ietf-alto-multi-cost.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149144445494.22036.11923880719369865745@ietfa.amsl.com> Date: Wed, 05 Apr 2017 19:07:34 -0700 Archived-At: Subject: [art] Artart telechat review of draft-ietf-alto-multi-cost-08 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 02:07:35 -0000 Reviewer: Martin Thomson Review result: Ready with Issues Document: draft-ietf-alto-multi-cost-08 Date: 2017-04-06 Reviewer: Martin Thomson This document describes how ALTO can be used to acquire cost maps with multiple cost metric instead of a single metric. The document very carefully deals with backwards compatibility with existing ALTO servers and clients. I don't anticipate many issues arising from the deployment of this protocol. I started reading -07, but finished with -08. I checked that the issues I raise still exist, but I'm not infallible. Apologies if I get something wrong. Minor issues: I've identified a few issues that are more than nits, these are marked "IMPORTANT" below. The abstract includes considerable justificiation. An abstract only needs to describe the *what*, not the *why*. Thus, what is there could be simplified considerably, e.g., This document defines a new method for retrieving multiple cost metrics in a single request for an ALTO filtered cost map. It also defines improvements to the constraints that can be used for filtered cost maps. Section 1 The introduction uses a bunch of odd terms. Some of these are recognizable from the ALTO specification, but some of the jargon seems unnecessary. In particular, "Internet View", "Provider Network region" and "Vector costs". All of which I think that I understand, but they make the doc hard to follow. Generally, I found the introduction quite hard to follow, both for that reason and structurally. The introduction could be a lot shorter and more concise: 1. ALTO defines multiple cost types (and more are being defined). 2. Clients sometimes consume multiple cost types. 3. Requesting multiple cost types at the same time is more efficient (for several reasons). 4. This document defines how to do that. 5. Separately, when multiple cost types are present, more sophisticated filtering can improve efficiency further. 6. This document defines how to do that too. Section 2 There are several items in the list here that are not used: Application Client, Network Service Provider, maybe more. Please check and remove those that don't apply. The RFC 7285 section reference thing is unnecessary. This document doesn't cite RFC 2119, but it uses the keywords. Section 3.1 The example shows an empty cost-type, but the schema you define allows it to be absent. You REALLY need to pick one. I don't believe that this is a compatibility issue: once you have determined that a client supports multi-cost, then you can do anything you like, just be clear about it. Section 3.2 I found the argument about the ease of writing a parser to be quite unconvincing. However, a new media type that is largely the same as the existing media type won't necessarily result in code duplication. Just say what it is you expect to happen and don't try to be apologetic about it. What you have appears to be a workable design. Section 3.5 This section is confusing. You only need to say that you are not altering full cost map resources in any way and that clients need to use filtered cost maps if they want multiple costs at the same time. (Obviously you could have, but creating multiple resources with the full combinatorial mess caused by combining many cost types is unwieldy.) At a minimum, the second paragraph here can be removed. Section 3.6.2 IMPORTANT: You don't define what happens when a client provides "or-constraints" and "constraints" at the same time. There are several valid options, but you need to choose. Section 3.6.3 It is probably worth explicitly noting that if "testable-cost-types" does not include values from "multi-cost-types", then those types can't be included in "constraints"/"or-constraints". Please explain the default value for the index for the "constraints"/"or-constraints" express in this section in addition to where it is hidden in a note later in the document. Section 3.6.5 Uppercase for "must not" in the second paragraph. (The "may" later in the paragraph might be better as "can".) In the example, the resource named "filtered-multicost-map" is provided for legacy reasons only. Why bother including "max-cost-types" and "cost-type-names" at all when "filtered-cost-map-extended" includes all that and more? Section 4.1.1 The definition of the schema here (and later) actually redefines the object completely. I found that confusing initially. It would be good to identify the *changes* from the base specification somehow. Can testable-cost-type-names be present and empty if cost-constraints is false? The first part of the definition permits that, the second forbids it. Section 4.1.2 The redefinition of PIDFilter is unnecessary. IMPORTANT: pids is optional in RFC 7285. Why the change? I find the redefinition of the optionality of cost-type to be worthy of special note. In the definition of "or-constraints", you use a "database query" where words would suffice. Section 4.1.3 I find the choice of value for "cost-type" to be problematic. It is a string in the base protocol, so changing to an empty object is likely to cause more issues than simply omitting it. Section 4.2 contains mismatched braces/parens for section references. Section 4.2.2 IMPORTANT: This provides a definition for ReqFilteredCostMap that is very different to that in the base specification. I think that this should have been ReqEndpointCostMap. As before, repeating the definition of EndpointFilter is unnecessary. Section 4.2.3 - see comment on 4.1.3 Section 5 I would be more comfortable if the examples used obviously-spurious metrics (e.g., "cattle-head-count", "smell", "shoe-size", etc...) than these metrics that are pretty plausible. More so when you claim that they are widely valued, which implies some sort of validity. It should be relatively easy to populate Content-Length now that the examples are "final". Section 5.1 You have unmatched braces in "meta" due to the comment. Section 5.2 Do you want to show one of the examples as having no cost values at all across all the cost types? From nobody Thu Apr 6 02:44:56 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608651293E4; Thu, 6 Apr 2017 02:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9VMWphqXuoW; Thu, 6 Apr 2017 02:44:40 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10091.outbound.protection.outlook.com [40.107.1.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31040127B31; Thu, 6 Apr 2017 02:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ty2qw21hKkS5GMbsMLX9Z3oBZImmX/jsWU6KoM8POC0=; b=dyLBiXCDmuK+z1caEkf0UF52KkeXvEh+eUh3hEcBIF6oPAFwkwQeIyemT1sqsdmVug2vCIS10SMUcurAovgMqGkvxe7T3xSNXc+ANYb+O3aTK0TWCVxRu4FbtU71iHcpeFD3MadfkuirDZuvDACtW/NHisxRTJQPtQ/U8i5nrxo= Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) by DB6PR0701MB2453.eurprd07.prod.outlook.com (10.168.75.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 09:44:37 +0000 Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) by DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) with mapi id 15.01.1019.021; Thu, 6 Apr 2017 09:44:37 +0000 From: "Randriamasy, Sabine (Nokia - FR/Nozay)" To: Martin Thomson , "art@ietf.org" CC: "alto@ietf.org" , "ietf@ietf.org" , "draft-ietf-alto-multi-cost.all@ietf.org" Thread-Topic: Artart telechat review of draft-ietf-alto-multi-cost-08 Thread-Index: AQHSrnqQeK8CFgpYuE64kjZYAubM4qG4F1CQ Date: Thu, 6 Apr 2017 09:44:36 +0000 Message-ID: References: <149144445494.22036.11923880719369865745@ietfa.amsl.com> In-Reply-To: <149144445494.22036.11923880719369865745@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.212.27] x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2453; 7:Wbk6gNXKv+vaGMZHY3U2CdDSgoz8YqQx1XWNBQvezsFYanZBj3f23hleRVX3IuGcg2rvemjDob2Vo3BhM/qOegYpJJGVFytN83gmXEZbVcpr18xsFB3gXTQJQzn6QEu8OKksLfBJZnu2cd56NFBOJgJM0yMr9oXq325IWcaFDhyRrZivmnNYNMj2No7k0h4FolrEHhxnBchfFG9FtCBQKqfdGcVZCa1CP4q5EtB7hpHkJB+XTknu4xz4URC9e3Zcu1agm1zbDCUL2WpPnQtFAeAXTmKqDjj79VsXO0WwP4RC8wQBq5c6NtTFK0HsTkHjeNxw9nX/8O+gdPlpeZZjbw== x-ms-office365-filtering-correlation-id: 27756a60-56e2-4099-c426-08d47cd189fe x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB6PR0701MB2453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:DB6PR0701MB2453; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2453; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39410400002)(39840400002)(39400400002)(39450400003)(13464003)(51444003)(377424004)(25786009)(8676002)(7696004)(39060400002)(38730400002)(54906002)(6246003)(8936002)(7736002)(77096006)(3660700001)(9686003)(55016002)(81166006)(305945005)(2501003)(74316002)(66066001)(4326008)(2950100002)(99286003)(229853002)(2900100001)(6436002)(76176999)(3846002)(6116002)(102836003)(86362001)(2906002)(50986999)(33656002)(5660300001)(3280700002)(230783001)(54356999)(122556002)(189998001)(53936002)(6506006)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2453; H:DB6PR0701MB2454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 09:44:36.9104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2453 Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-alto-multi-cost-08 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:44:43 -0000 SGVsbG8gTWFydGluLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgcmV2aWV3LiBUaGUgZHJhZnQg d2lsbCBiZSB1cGRhdGVkIHNvIGFzIHRvIGFkZHJlc3MgdGhlbS4NCkJlc3QgcmVnYXJkcywNClNh YmluZQ0KDQoNCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogTWFydGluIFRo b21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQo+PlNlbnQ6IDA2IEFwcmls IDIwMTcgMDQ6MDgNCj4+VG86IGFydEBpZXRmLm9yZw0KPj5DYzogYWx0b0BpZXRmLm9yZzsgaWV0 ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hbHRvLW11bHRpLWNvc3QuYWxsQGlldGYub3JnDQo+PlN1 YmplY3Q6IEFydGFydCB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hbHRvLW11bHRpLWNv c3QtMDgNCj4+DQo+PlJldmlld2VyOiBNYXJ0aW4gVGhvbXNvbg0KPj5SZXZpZXcgcmVzdWx0OiBS ZWFkeSB3aXRoIElzc3Vlcw0KPj4NCj4+RG9jdW1lbnQ6IGRyYWZ0LWlldGYtYWx0by1tdWx0aS1j b3N0LTA4DQo+PkRhdGU6IDIwMTctMDQtMDYNCj4+UmV2aWV3ZXI6IE1hcnRpbiBUaG9tc29uDQo+ Pg0KPj5UaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgQUxUTyBjYW4gYmUgdXNlZCB0byBhY3F1 aXJlIGNvc3QgbWFwcyB3aXRoDQo+Pm11bHRpcGxlIGNvc3QgbWV0cmljIGluc3RlYWQgb2YgYSBz aW5nbGUgbWV0cmljLg0KPj4NCj4+VGhlIGRvY3VtZW50IHZlcnkgY2FyZWZ1bGx5IGRlYWxzIHdp dGggYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZw0KPj5BTFRPIHNlcnZlcnMg YW5kIGNsaWVudHMuICBJIGRvbid0IGFudGljaXBhdGUgbWFueSBpc3N1ZXMgYXJpc2luZyBmcm9t IHRoZQ0KPj5kZXBsb3ltZW50IG9mIHRoaXMgcHJvdG9jb2wuDQo+Pg0KPj5JIHN0YXJ0ZWQgcmVh ZGluZyAtMDcsIGJ1dCBmaW5pc2hlZCB3aXRoIC0wOC4gIEkgY2hlY2tlZCB0aGF0IHRoZSBpc3N1 ZXMgSSByYWlzZQ0KPj5zdGlsbCBleGlzdCwgYnV0IEknbSBub3QgaW5mYWxsaWJsZS4gIEFwb2xv Z2llcyBpZiBJIGdldCBzb21ldGhpbmcgd3JvbmcuDQo+Pg0KPj5NaW5vciBpc3N1ZXM6IEkndmUg aWRlbnRpZmllZCBhIGZldyBpc3N1ZXMgdGhhdCBhcmUgbW9yZSB0aGFuIG5pdHMsIHRoZXNlIGFy ZQ0KPj5tYXJrZWQgIklNUE9SVEFOVCIgYmVsb3cuDQo+Pg0KPj4NCj4+VGhlIGFic3RyYWN0IGlu Y2x1ZGVzIGNvbnNpZGVyYWJsZSBqdXN0aWZpY2lhdGlvbi4gIEFuIGFic3RyYWN0IG9ubHkgbmVl ZHMgdG8NCj4+ZGVzY3JpYmUgdGhlICp3aGF0Kiwgbm90IHRoZSAqd2h5Ki4gIFRodXMsIHdoYXQg aXMgdGhlcmUgY291bGQgYmUgc2ltcGxpZmllZA0KPj5jb25zaWRlcmFibHksIGUuZy4sDQo+Pg0K Pj4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgbWV0aG9kIGZvciByZXRyaWV2aW5nIG11 bHRpcGxlIGNvc3QgbWV0cmljcyBpbg0KPj5hDQo+PiAgIHNpbmdsZSByZXF1ZXN0IGZvciBhbiBB TFRPIGZpbHRlcmVkIGNvc3QgbWFwLiAgSXQgYWxzbyBkZWZpbmVzIGltcHJvdmVtZW50cw0KPj4g ICB0byB0aGUgY29uc3RyYWludHMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgZmlsdGVyZWQgY29zdCBt YXBzLg0KPj4NCj4+U2VjdGlvbiAxDQo+Pg0KPj5UaGUgaW50cm9kdWN0aW9uIHVzZXMgYSBidW5j aCBvZiBvZGQgdGVybXMuICBTb21lIG9mIHRoZXNlIGFyZSByZWNvZ25pemFibGUNCj4+ZnJvbSB0 aGUgQUxUTyBzcGVjaWZpY2F0aW9uLCBidXQgc29tZSBvZiB0aGUgamFyZ29uIHNlZW1zIHVubmVj ZXNzYXJ5LiAgSW4NCj4+cGFydGljdWxhciwgIkludGVybmV0IFZpZXciLCAiUHJvdmlkZXIgTmV0 d29yayByZWdpb24iIGFuZCAiVmVjdG9yIGNvc3RzIi4NCj4+QWxsIG9mIHdoaWNoIEkgdGhpbmsg dGhhdCBJIHVuZGVyc3RhbmQsIGJ1dCB0aGV5IG1ha2UgdGhlIGRvYyBoYXJkIHRvIGZvbGxvdy4N Cj4+DQo+PkdlbmVyYWxseSwgSSBmb3VuZCB0aGUgaW50cm9kdWN0aW9uIHF1aXRlIGhhcmQgdG8g Zm9sbG93LCBib3RoIGZvciB0aGF0IHJlYXNvbg0KPj5hbmQgc3RydWN0dXJhbGx5LiAgVGhlIGlu dHJvZHVjdGlvbiBjb3VsZCBiZSBhIGxvdCBzaG9ydGVyIGFuZCBtb3JlDQo+PmNvbmNpc2U6DQo+ Pg0KPj4xLiBBTFRPIGRlZmluZXMgbXVsdGlwbGUgY29zdCB0eXBlcyAoYW5kIG1vcmUgYXJlIGJl aW5nIGRlZmluZWQpLg0KPj4yLiBDbGllbnRzIHNvbWV0aW1lcyBjb25zdW1lIG11bHRpcGxlIGNv c3QgdHlwZXMuDQo+PjMuIFJlcXVlc3RpbmcgbXVsdGlwbGUgY29zdCB0eXBlcyBhdCB0aGUgc2Ft ZSB0aW1lIGlzIG1vcmUgZWZmaWNpZW50IChmb3INCj4+ICAgc2V2ZXJhbCByZWFzb25zKS4NCj4+ NC4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGhvdyB0byBkbyB0aGF0Lg0KPj41LiBTZXBhcmF0ZWx5 LCB3aGVuIG11bHRpcGxlIGNvc3QgdHlwZXMgYXJlIHByZXNlbnQsIG1vcmUgc29waGlzdGljYXRl ZA0KPj4gICBmaWx0ZXJpbmcgY2FuIGltcHJvdmUgZWZmaWNpZW5jeSBmdXJ0aGVyLg0KPj42LiBU aGlzIGRvY3VtZW50IGRlZmluZXMgaG93IHRvIGRvIHRoYXQgdG9vLg0KPj4NCj4+U2VjdGlvbiAy DQo+Pg0KPj5UaGVyZSBhcmUgc2V2ZXJhbCBpdGVtcyBpbiB0aGUgbGlzdCBoZXJlIHRoYXQgYXJl IG5vdCB1c2VkOg0KPj5BcHBsaWNhdGlvbiBDbGllbnQsDQo+Pk5ldHdvcmsgU2VydmljZSBQcm92 aWRlciwgbWF5YmUgbW9yZS4gIFBsZWFzZSBjaGVjayBhbmQgcmVtb3ZlIHRob3NlDQo+PnRoYXQg ZG9uJ3QgYXBwbHkuDQo+Pg0KPj5UaGUgUkZDIDcyODUgc2VjdGlvbiByZWZlcmVuY2UgdGhpbmcg aXMgdW5uZWNlc3NhcnkuDQo+Pg0KPj5UaGlzIGRvY3VtZW50IGRvZXNuJ3QgY2l0ZSBSRkMgMjEx OSwgYnV0IGl0IHVzZXMgdGhlIGtleXdvcmRzLg0KPj4NCj4+U2VjdGlvbiAzLjENCj4+DQo+PlRo ZSBleGFtcGxlIHNob3dzIGFuIGVtcHR5IGNvc3QtdHlwZSwgYnV0IHRoZSBzY2hlbWEgeW91IGRl ZmluZSBhbGxvd3MgaXQNCj4+dG8gYmUgYWJzZW50LiAgWW91IFJFQUxMWSBuZWVkIHRvIHBpY2sg b25lLiAgSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhpcyBpcyBhDQo+PmNvbXBhdGliaWxpdHkgaXNz dWU6IG9uY2UgeW91IGhhdmUgZGV0ZXJtaW5lZCB0aGF0IGEgY2xpZW50IHN1cHBvcnRzIG11bHRp LQ0KPj5jb3N0LCB0aGVuIHlvdSBjYW4gZG8gYW55dGhpbmcgeW91IGxpa2UsIGp1c3QgYmUgY2xl YXIgYWJvdXQgaXQuDQo+Pg0KPj5TZWN0aW9uIDMuMg0KPj4NCj4+SSBmb3VuZCB0aGUgYXJndW1l bnQgYWJvdXQgdGhlIGVhc2Ugb2Ygd3JpdGluZyBhIHBhcnNlciB0byBiZSBxdWl0ZQ0KPj51bmNv bnZpbmNpbmcuICBIb3dldmVyLCBhIG5ldyBtZWRpYSB0eXBlIHRoYXQgaXMgbGFyZ2VseSB0aGUg c2FtZSBhcyB0aGUNCj4+ZXhpc3RpbmcgbWVkaWEgdHlwZSB3b24ndCBuZWNlc3NhcmlseSByZXN1 bHQgaW4gY29kZSBkdXBsaWNhdGlvbi4NCj4+DQo+Pkp1c3Qgc2F5IHdoYXQgaXQgaXMgeW91IGV4 cGVjdCB0byBoYXBwZW4gYW5kIGRvbid0IHRyeSB0byBiZSBhcG9sb2dldGljIGFib3V0DQo+Pml0 LiAgV2hhdCB5b3UgaGF2ZSBhcHBlYXJzIHRvIGJlIGEgd29ya2FibGUgZGVzaWduLg0KPj4NCj4+ U2VjdGlvbiAzLjUNCj4+DQo+PlRoaXMgc2VjdGlvbiBpcyBjb25mdXNpbmcuICBZb3Ugb25seSBu ZWVkIHRvIHNheSB0aGF0IHlvdSBhcmUgbm90IGFsdGVyaW5nIGZ1bGwNCj4+Y29zdCBtYXAgcmVz b3VyY2VzIGluIGFueSB3YXkgYW5kIHRoYXQgY2xpZW50cyBuZWVkIHRvIHVzZSBmaWx0ZXJlZCBj b3N0IG1hcHMNCj4+aWYgdGhleSB3YW50IG11bHRpcGxlIGNvc3RzIGF0IHRoZSBzYW1lIHRpbWUu ICAoT2J2aW91c2x5IHlvdSBjb3VsZCBoYXZlLCBidXQNCj4+Y3JlYXRpbmcgbXVsdGlwbGUgcmVz b3VyY2VzIHdpdGggdGhlIGZ1bGwgY29tYmluYXRvcmlhbCBtZXNzIGNhdXNlZCBieQ0KPj5jb21i aW5pbmcgbWFueSBjb3N0IHR5cGVzIGlzIHVud2llbGR5LikgIEF0IGEgbWluaW11bSwgdGhlIHNl Y29uZA0KPj5wYXJhZ3JhcGggaGVyZSBjYW4gYmUgcmVtb3ZlZC4NCj4+DQo+PlNlY3Rpb24gMy42 LjINCj4+DQo+PklNUE9SVEFOVDogWW91IGRvbid0IGRlZmluZSB3aGF0IGhhcHBlbnMgd2hlbiBh IGNsaWVudCBwcm92aWRlcyAib3ItDQo+PmNvbnN0cmFpbnRzIg0KPj5hbmQgImNvbnN0cmFpbnRz IiBhdCB0aGUgc2FtZSB0aW1lLiAgVGhlcmUgYXJlIHNldmVyYWwgdmFsaWQgb3B0aW9ucywgYnV0 IHlvdQ0KPj5uZWVkIHRvIGNob29zZS4NCj4+DQo+PlNlY3Rpb24gMy42LjMNCj4+DQo+Pkl0IGlz IHByb2JhYmx5IHdvcnRoIGV4cGxpY2l0bHkgbm90aW5nIHRoYXQgaWYgInRlc3RhYmxlLWNvc3Qt dHlwZXMiDQo+PmRvZXMgbm90DQo+PmluY2x1ZGUgdmFsdWVzIGZyb20gIm11bHRpLWNvc3QtdHlw ZXMiLCB0aGVuIHRob3NlIHR5cGVzIGNhbid0IGJlIGluY2x1ZGVkIGluDQo+PiJjb25zdHJhaW50 cyIvIm9yLWNvbnN0cmFpbnRzIi4NCj4+DQo+PlBsZWFzZSBleHBsYWluIHRoZSBkZWZhdWx0IHZh bHVlIGZvciB0aGUgaW5kZXggZm9yIHRoZSAiY29uc3RyYWludHMiLyJvci0NCj4+Y29uc3RyYWlu dHMiIGV4cHJlc3MgaW4gdGhpcyBzZWN0aW9uIGluIGFkZGl0aW9uIHRvIHdoZXJlIGl0IGlzIGhp ZGRlbiBpbiBhIG5vdGUNCj4+bGF0ZXIgaW4gdGhlIGRvY3VtZW50Lg0KPj4NCj4+U2VjdGlvbiAz LjYuNQ0KPj4NCj4+VXBwZXJjYXNlIGZvciAibXVzdCBub3QiIGluIHRoZSBzZWNvbmQgcGFyYWdy YXBoLiAgKFRoZSAibWF5IiBsYXRlciBpbiB0aGUNCj4+cGFyYWdyYXBoIG1pZ2h0IGJlIGJldHRl ciBhcyAiY2FuIi4pDQo+Pg0KPj5JbiB0aGUgZXhhbXBsZSwgdGhlIHJlc291cmNlIG5hbWVkICJm aWx0ZXJlZC1tdWx0aWNvc3QtbWFwIiBpcyBwcm92aWRlZCBmb3INCj4+bGVnYWN5IHJlYXNvbnMg b25seS4gIFdoeSBib3RoZXIgaW5jbHVkaW5nICJtYXgtY29zdC10eXBlcyIgYW5kICJjb3N0LXR5 cGUtDQo+Pm5hbWVzIiBhdCBhbGwgd2hlbiAiZmlsdGVyZWQtY29zdC1tYXAtZXh0ZW5kZWQiIGlu Y2x1ZGVzIGFsbCB0aGF0IGFuZCBtb3JlPw0KPj4NCj4+U2VjdGlvbiA0LjEuMQ0KPj4NCj4+VGhl IGRlZmluaXRpb24gb2YgdGhlIHNjaGVtYSBoZXJlIChhbmQgbGF0ZXIpIGFjdHVhbGx5IHJlZGVm aW5lcyB0aGUgb2JqZWN0DQo+PmNvbXBsZXRlbHkuICBJIGZvdW5kIHRoYXQgY29uZnVzaW5nIGlu aXRpYWxseS4gIEl0IHdvdWxkIGJlIGdvb2QgdG8gaWRlbnRpZnkgdGhlDQo+PipjaGFuZ2VzKiBm cm9tIHRoZSBiYXNlIHNwZWNpZmljYXRpb24gc29tZWhvdy4NCj4+DQo+PkNhbiB0ZXN0YWJsZS1j b3N0LXR5cGUtbmFtZXMgYmUgcHJlc2VudCBhbmQgZW1wdHkgaWYgY29zdC1jb25zdHJhaW50cyBp cw0KPj5mYWxzZT8NCj4+VGhlIGZpcnN0IHBhcnQgb2YgdGhlIGRlZmluaXRpb24gcGVybWl0cyB0 aGF0LCB0aGUgc2Vjb25kIGZvcmJpZHMgaXQuDQo+Pg0KPj5TZWN0aW9uIDQuMS4yDQo+Pg0KPj5U aGUgcmVkZWZpbml0aW9uIG9mIFBJREZpbHRlciBpcyB1bm5lY2Vzc2FyeS4NCj4+DQo+PklNUE9S VEFOVDogcGlkcyBpcyBvcHRpb25hbCBpbiBSRkMgNzI4NS4gIFdoeSB0aGUgY2hhbmdlPw0KPj4N Cj4+SSBmaW5kIHRoZSByZWRlZmluaXRpb24gb2YgdGhlIG9wdGlvbmFsaXR5IG9mIGNvc3QtdHlw ZSB0byBiZSB3b3J0aHkgb2Ygc3BlY2lhbA0KPj5ub3RlLg0KPj4NCj4+SW4gdGhlIGRlZmluaXRp b24gb2YgIm9yLWNvbnN0cmFpbnRzIiwgeW91IHVzZSBhICJkYXRhYmFzZSBxdWVyeSINCj4+d2hl cmUgd29yZHMNCj4+d291bGQgc3VmZmljZS4NCj4+DQo+PlNlY3Rpb24gNC4xLjMNCj4+DQo+Pkkg ZmluZCB0aGUgY2hvaWNlIG9mIHZhbHVlIGZvciAiY29zdC10eXBlIiB0byBiZSBwcm9ibGVtYXRp Yy4gIEl0IGlzIGEgc3RyaW5nIGluIHRoZQ0KPj5iYXNlIHByb3RvY29sLCBzbyBjaGFuZ2luZyB0 byBhbiBlbXB0eSBvYmplY3QgaXMgbGlrZWx5IHRvIGNhdXNlIG1vcmUgaXNzdWVzDQo+PnRoYW4g c2ltcGx5IG9taXR0aW5nIGl0Lg0KPj4NCj4+U2VjdGlvbiA0LjIgY29udGFpbnMgbWlzbWF0Y2hl ZCBicmFjZXMvcGFyZW5zIGZvciBzZWN0aW9uIHJlZmVyZW5jZXMuDQo+Pg0KPj5TZWN0aW9uIDQu Mi4yDQo+Pg0KPj5JTVBPUlRBTlQ6IFRoaXMgcHJvdmlkZXMgYSBkZWZpbml0aW9uIGZvciBSZXFG aWx0ZXJlZENvc3RNYXAgdGhhdCBpcyB2ZXJ5DQo+PmRpZmZlcmVudCB0byB0aGF0IGluIHRoZSBi YXNlIHNwZWNpZmljYXRpb24uICBJIHRoaW5rIHRoYXQgdGhpcyBzaG91bGQgaGF2ZSBiZWVuDQo+ PlJlcUVuZHBvaW50Q29zdE1hcC4NCj4+DQo+PkFzIGJlZm9yZSwgcmVwZWF0aW5nIHRoZSBkZWZp bml0aW9uIG9mIEVuZHBvaW50RmlsdGVyIGlzIHVubmVjZXNzYXJ5Lg0KPj4NCj4+U2VjdGlvbiA0 LjIuMyAtIHNlZSBjb21tZW50IG9uIDQuMS4zDQo+Pg0KPj5TZWN0aW9uIDUNCj4+DQo+Pkkgd291 bGQgYmUgbW9yZSBjb21mb3J0YWJsZSBpZiB0aGUgZXhhbXBsZXMgdXNlZCBvYnZpb3VzbHktc3B1 cmlvdXMNCj4+bWV0cmljcyAoZS5nLiwgImNhdHRsZS1oZWFkLWNvdW50IiwgInNtZWxsIiwgInNo b2Utc2l6ZSIsIGV0Yy4uLikgdGhhbiB0aGVzZQ0KPj5tZXRyaWNzIHRoYXQgYXJlIHByZXR0eSBw bGF1c2libGUuICBNb3JlIHNvIHdoZW4geW91IGNsYWltIHRoYXQgdGhleSBhcmUNCj4+d2lkZWx5 IHZhbHVlZCwgd2hpY2ggaW1wbGllcyBzb21lIHNvcnQgb2YgdmFsaWRpdHkuDQo+Pg0KPj5JdCBz aG91bGQgYmUgcmVsYXRpdmVseSBlYXN5IHRvIHBvcHVsYXRlIENvbnRlbnQtTGVuZ3RoIG5vdyB0 aGF0IHRoZQ0KPj5leGFtcGxlcyBhcmUgImZpbmFsIi4NCj4+DQo+PlNlY3Rpb24gNS4xDQo+Pg0K Pj5Zb3UgaGF2ZSB1bm1hdGNoZWQgYnJhY2VzIGluICJtZXRhIiBkdWUgdG8gdGhlIGNvbW1lbnQu DQo+Pg0KPj5TZWN0aW9uIDUuMg0KPj4NCj4+RG8geW91IHdhbnQgdG8gc2hvdyBvbmUgb2YgdGhl IGV4YW1wbGVzIGFzIGhhdmluZyBubyBjb3N0IHZhbHVlcyBhdCBhbGwNCj4+YWNyb3NzIGFsbCB0 aGUgY29zdCB0eXBlcz8NCj4+DQoNCg== From nobody Fri Apr 7 04:57:49 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4991270B4 for ; Sun, 26 Mar 2017 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEyOR4s45uPd for ; Sun, 26 Mar 2017 11:18:45 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64475126579 for ; Sun, 26 Mar 2017 11:18:45 -0700 (PDT) Received: from dhcp-8ee2.meeting.ietf.org (unknown [31.133.142.226]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 40BD2509B8; Sun, 26 Mar 2017 14:18:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Mark Nottingham In-Reply-To: <20170324110136.GC6356@biggiebuntu> Date: Sun, 26 Mar 2017 13:18:43 -0500 Cc: IETF Apps Discuss Content-Transfer-Encoding: quoted-printable Message-Id: <1CBCB1EF-983B-4470-8BD6-437193C86175@mnot.net> References: <5CB15D9F-D50F-4A78-8AC0-21B835534D23@mnot.net> <20170324110136.GC6356@biggiebuntu> To: Stian Soiland-Reyes X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Fri, 07 Apr 2017 04:57:48 -0700 Subject: Re: [art] "Home" documents for HTTP APIs X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 18:18:48 -0000 Hi, As mentioned in the appendix, the focus here is different; it's = targeting APIs that have multiple deployments and multiple consumer = implementations, all uncoordinated -- i.e., the sort of thing that we = generally create in standards.=20 Cheers, > On 24 Mar 2017, at 6:01 am, Stian Soiland-Reyes = wrote: >=20 > On Wed, 15 Mar 2017 16:17:07 +1100, Mark Nottingham = wrote: >> Hi art[-discuss], >>=20 >> I've had a document on the back burner for a while about a "home = document" for non-brower uses of HTTP. >>=20 >> https://datatracker.ietf.org/doc/draft-nottingham-json-home/ >> https://mnot.github.io/I-D/json-home/ >>=20 >> The idea is to promote good practice, especially regarding allowing = the server to control its own URLs (as per RFC7320) -- especially in the = case where there are likely to be multiple implementations, multiple = servers and multiple clients deployed (i.e., standards). >>=20 >> This differentiates it from other "HTTP API description formats" that = you might have come across. See the Introduction for a more full = explanation. >>=20 >> It's come to a point where there's a non-trival (but not huge) = community of folks interested in it and implementing it; e.g., see:=20 >> https://github.com/mnot/I-D/wiki/json-home >> https://github.com/mnot/I-D/issues?utf8=3D=E2=9C=93&q=3Dlabel%3Ajson-h= ome%20 >>=20 >> However, I'm not sure about next steps. What I'd like to hear from = folks here is whether people think defining this would help IETF = protocols that use HTTP (of which there seem to be more every day). >>=20 >> Any thoughts? >=20 > Is there a good reason why say a Swagger/Open API specification = document > is not appropriate as the "JSON Home" document? It seems that as you > start defining URI templates and so on, you are stepping into that > territory. >=20 > https://www.openapis.org/ >=20 >=20 > What I think Open API does not have is a way to identify the (type) of > service/endpoint by URI, as your tag: examples. >=20 >=20 > --=20 > Stian Soiland-Reyes > The University of Manchester > http://www.esciencelab.org.uk/ > http://orcid.org/0000-0001-9842-9718 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sun Apr 9 21:07:06 2017 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8905A129415; Sun, 9 Apr 2017 21:07:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mark Nottingham To: Cc: draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149179722452.3118.982908107963516290@ietfa.amsl.com> Date: Sun, 09 Apr 2017 21:07:04 -0700 Archived-At: Subject: [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 04:07:05 -0000 Reviewer: Mark Nottingham Review result: Not Ready First, a general comment. I have been concerned about the duplication of effort that COAP represents for some time, and that concern grows significantly upon reading this draft. COAP is now specifying multiple "bindings" to underlying application and transport protocols, re-inventing message framing, congestion control in UDP, etc. The introduction justifies this development over the reuse of HTTP/2 (and presumably QUIC, once available) based upon the relative availability of implementations for constrained devices. Whether that remains true will only be judged by the market -- unfortunately after all of the cost of development and standardisation is sunk. The introduction motivates the layering of COAP over WebSockets to allow it to be used in a network that only allows external access through a HTTP proxy. In fact, it is not necessary to use WebSockets to do so; HTTP CONNECT provides a tunnel in this scenario. WebSockets is a specialised protocol that allows bidirectional, stream-based transport from a Web browser -- it is effectively TCP wrapped into the Web browser's security model, to make doing so safe. Using it for other purposes (i.e., non-browser use cases) isn't really appropriate. I'd suggest either removing the WebSockets binding, or changing its motivation in the Introduction. Section 7 defines a number of new URI schemes for COAP protocols. Syntactically, they use "+" to separate "coap" from the underlying transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This syntax is allowed by RFC3986, but is unprecedented, and implies a sub-syntax convention similar to those used in media types, etc. Is there an expectation that other URI schemes starting with "coap+" are reserved? Defining URI schemes that switch transport protocol based upon their name deserves wider review as well; this has been a contentious topic in the past, and it would be good to understand what tradeoffs are being made by doing so. Locking identifiers into a specific transport protocol sacrifices much of the power of URLs. Furthermore, creating "coap+ws" to denote a specific protocol over WebSockets (which has its own URI scheme) is questionable; taken to its natural conclusion, we'll have a proliferation of URI schemes for things over WebSockets. Will COAP take the same approach for HTTP? I would suggest a wider discussion of these issues on art@ / uri@. Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" URI, using a well-known URI in the "wss" scheme. However, "wss" is not defined to use well-known URIs, so this is an invalid use. I'm not sure how to address this, other than removing the WebSockets binding. Section 8.1 makes it Mandatory to Implement the protocol without any security ("NoSec"). This seems counter to best practice in the IETF, but I'll defer to the Security Area review. From nobody Mon Apr 10 02:46:52 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760E412946D; Mon, 10 Apr 2017 02:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laIirY-Qwsht; Mon, 10 Apr 2017 02:46:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6762B129469; Mon, 10 Apr 2017 02:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3A9kf6R029982; Mon, 10 Apr 2017 11:46:41 +0200 (CEST) Received: from client-0078.vpn.uni-bremen.de (client-0078.vpn.uni-bremen.de [134.102.107.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w1lh10PjCzDJ1N; Mon, 10 Apr 2017 11:46:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149179722452.3118.982908107963516290@ietfa.amsl.com> Date: Mon, 10 Apr 2017 11:46:40 +0200 Cc: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 513510400.415103-770b8e04c4ebcf4e77d1fedbfcf44f5f Content-Transfer-Encoding: quoted-printable Message-Id: <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:46:50 -0000 Hi Mark, thank you for this thoughtful review. This message will focus on a few technical points; I=E2=80=99ll leave = aside the philosophical issues about whether the IETF should have a = constrained node stack. > WebSockets > is a specialised protocol that allows bidirectional, stream-based > transport from a Web browser -- it is effectively TCP wrapped into the > Web browser's security model, to make doing so safe. Indeed, that is the use case that was motivating this part. > Using it for > other purposes (i.e., non-browser use cases) isn't really appropriate. > I'd suggest either removing the WebSockets binding, or changing its > motivation in the Introduction. I agree that the introduction should focus on the Browser use case and = keep out of the firewall traversal jungle. > Section 7 defines a number of new URI schemes for COAP protocols. > Syntactically, they use "+" to separate "coap" from the underlying > transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This > syntax is allowed by RFC3986, but is unprecedented, and implies a > sub-syntax convention similar to those used in media types, etc. Is > there an expectation that other URI schemes starting with "coap+" are > reserved?=20 There is no such expectation. We did have the discussion about reserved URI scheme prefixes in the = IETF, and as I recall, the result was that there are none. While it = would be a bit weird to register a URI scheme starting with coap+ or = coaps+ that is unrelated to CoAP, only the slightly boggled response = from an expert review is in the way of that happening. Would the scheme names be more palatable with a dash instead of a plus? Careful choice of the scheme name mostly benefits the implementer, so it = can be changed in the spec (at the cost of changing existing = implementations). > Defining URI schemes that switch transport protocol based upon their > name deserves wider review as well; this has been a contentious topic > in the past, and it would be good to understand what tradeoffs are > being made by doing so. Locking identifiers into a specific transport > protocol sacrifices much of the power of URLs. The =E2=80=9Csiloing=E2=80=9D of URIs along schemes is indeed a problem, = which started for CoAP with the separation of the coap:/coaps: name = spaces. The CoRE WG did not see it as its task to address this = shortcoming. So, for now, we=E2=80=99ll have to live with it; = approaches such as draft-silverajan-core-coap-protocol-negotiation are = trying to address its practicalities. > Furthermore, creating > "coap+ws" to denote a specific protocol over WebSockets (which has its > own URI scheme) is questionable; taken to its natural conclusion, > we'll have a proliferation of URI schemes for things over WebSockets. I=E2=80=99m not sure that a proliferation will happen =E2=80=94 = WebSockets is mostly used for tightly bound proprietary protocols = between a JavaScript mobile code client and a server that provides this = mobile code client. On the other hand, deciding to never use URIs to = refer to resources available over a WebSockets protocol strikes me as an = unnecessary restriction. > Will COAP take the same approach for HTTP? Not sure what this question is leading into. (We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075. But maybe this is about something different.) > I would suggest a wider discussion of these issues on art@ / uri@. Indeed, a wider discussion of these longstanding issues would be useful. I=E2=80=99m not sure that waiting for their resolution is blocking this = spec. > Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" > URI, using a well-known URI in the "wss" scheme. However, "wss" is not > defined to use well-known URIs, so this is an invalid use.=20 This incorrect use of RFC 5785 is indeed embarrassing. More about that = later. > Section 8.1 makes it Mandatory to Implement the protocol without any > security ("NoSec"). This seems counter to best practice in the IETF, > but I'll defer to the Security Area review. Since it is the implementers who will decide whether they implement = this, this co-author could live with making implementing NoSec = completely optional. (It will be anyway, in practice, at the level of = what is actually configured.) The important point(*) from the WG = perspective here is that TLS is mandatory to implement, with the = specifics depending on the security mode needed (cf. RFC 7925). (Note = also that there are other ways to provide security with CoAP.) Gr=C3=BC=C3=9Fe, Carsten (*) = https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e935424= 2012afb28dc60 From nobody Mon Apr 10 17:39:28 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EC91293F8; Mon, 10 Apr 2017 17:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u01rQ2Qe3umb; Mon, 10 Apr 2017 17:39:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB501294C4; Mon, 10 Apr 2017 17:39:24 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2753B22E253; Mon, 10 Apr 2017 20:39:21 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> Date: Tue, 11 Apr 2017 10:39:18 +1000 Cc: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 00:39:27 -0000 Hi Carsten, Couple of quic responses below. On 10 Apr 2017, at 7:46 pm, Carsten Bormann wrote: > I agree that the introduction should focus on the Browser use case and = keep out of the firewall traversal jungle. OK. Just curious -- is there a strong motivation here? It seems very odd = to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over = WebSockets over HTTP again, rather than just using HTTP (which AIUI you = already have a mapping to). >> Section 7 defines a number of new URI schemes for COAP protocols. >> Syntactically, they use "+" to separate "coap" from the underlying >> transport(-ish) protocol that they're bound to; e.g., "coap+tcp". = This >> syntax is allowed by RFC3986, but is unprecedented, and implies a >> sub-syntax convention similar to those used in media types, etc. Is >> there an expectation that other URI schemes starting with "coap+" are >> reserved?=20 >=20 > There is no such expectation. >=20 > We did have the discussion about reserved URI scheme prefixes in the = IETF, and as I recall, the result was that there are none. While it = would be a bit weird to register a URI scheme starting with coap+ or = coaps+ that is unrelated to CoAP, only the slightly boggled response = from an expert review is in the way of that happening. >=20 > Would the scheme names be more palatable with a dash instead of a = plus? > Careful choice of the scheme name mostly benefits the implementer, so = it can be changed in the spec (at the cost of changing existing = implementations). OK. I'm mostly noting this in case other folks feel that this is a bad = precedent for URI schemes; I think the bigger concern is the one below. >> Defining URI schemes that switch transport protocol based upon their >> name deserves wider review as well; this has been a contentious topic >> in the past, and it would be good to understand what tradeoffs are >> being made by doing so. Locking identifiers into a specific transport >> protocol sacrifices much of the power of URLs. >=20 > The =E2=80=9Csiloing=E2=80=9D of URIs along schemes is indeed a = problem, which started for CoAP with the separation of the coap:/coaps: = name spaces. The CoRE WG did not see it as its task to address this = shortcoming. So, for now, we=E2=80=99ll have to live with it; = approaches such as draft-silverajan-core-coap-protocol-negotiation are = trying to address its practicalities. By defining multiple URI schemes for different transports of the same = protocol, the WG has taken a position as to what the solution is. I'm = finding it difficult to square this with the continuing characterisation = of CORE as "RESTful". >> Furthermore, creating >> "coap+ws" to denote a specific protocol over WebSockets (which has = its >> own URI scheme) is questionable; taken to its natural conclusion, >> we'll have a proliferation of URI schemes for things over WebSockets. >=20 > I=E2=80=99m not sure that a proliferation will happen =E2=80=94 = WebSockets is mostly used for tightly bound proprietary protocols = between a JavaScript mobile code client and a server that provides this = mobile code client. On the other hand, deciding to never use URIs to = refer to resources available over a WebSockets protocol strikes me as an = unnecessary restriction. >=20 >> Will COAP take the same approach for HTTP? >=20 > Not sure what this question is leading into. > (We do have a defined relationship with HTTP, in RFC 7252 and RFC = 8075. > But maybe this is about something different.) I mean to ask whether there will be a need for a "coap+http" URI scheme; = it seems like a logical conclusion of the approach taken here.=20 >> I would suggest a wider discussion of these issues on art@ / uri@. >=20 > Indeed, a wider discussion of these longstanding issues would be = useful. > I=E2=80=99m not sure that waiting for their resolution is blocking = this spec. >=20 >> Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" >> URI, using a well-known URI in the "wss" scheme. However, "wss" is = not >> defined to use well-known URIs, so this is an invalid use.=20 >=20 > This incorrect use of RFC 5785 is indeed embarrassing. More about = that later. OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, = but I think that would take a separate RFC that updates their scheme = registrations. Not sure whether there would be any pushback in that = community (but I can't see any immediate reason why there would be). >> Section 8.1 makes it Mandatory to Implement the protocol without any >> security ("NoSec"). This seems counter to best practice in the IETF, >> but I'll defer to the Security Area review. >=20 > Since it is the implementers who will decide whether they implement = this, this co-author could live with making implementing NoSec = completely optional. (It will be anyway, in practice, at the level of = what is actually configured.) The important point(*) from the WG = perspective here is that TLS is mandatory to implement, with the = specifics depending on the security mode needed (cf. RFC 7925). (Note = also that there are other ways to provide security with CoAP.) Ack. Again, this was mostly a note to bring it to others' attention; the = use of the phrase "Mandatory to Implement" when applied to "no security" = just seems odd. Cheers, >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) = https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e935424= 2012afb28dc60 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Apr 10 20:50:03 2017 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADADC129A9F; Mon, 10 Apr 2017 20:49:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mark Nottingham To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149188258769.15738.17473942496982365590@ietfa.amsl.com> Date: Mon, 10 Apr 2017 20:49:47 -0700 Archived-At: Subject: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 03:49:48 -0000 Reviewer: Mark Nottingham Review result: Ready with Issues This specification is a relatively straightforward mapping of the format described in RFC6690 (itself a serialisation of RFC5988bis links) into JSON and CBOR. I don't have deep knowledge of CBOR, but given the editorship of the document, I trust it's seen adequate review in that regard. The only potential issue is how this is achieved. Rather than defining two new serialisations of RFC5988bis links (into JSON and CBOR), it describes how to re-serialise RFC6690 documents into JSON and CBOR. This means that any constraints upon RFC6690 documents are also mirrored into these formats; e.g., the target IRI is constrained to be a URI in 6690, and therefore can also only be a URI in JSON and CBOR, despite these formats' ability to easily convey non-ASCII content. In other words, the specification currently defines these link formats in terms of the Link header (as defined in section 5 of RFC5988) -- along with all of the foibles of HTTP header syntax -- rather than their abstract model (defined in Section 3). Whether or not this is a problem depends on what's desired; if 6690 is seen as effectively a profile of 5988, then it makes sense to express it in those terms. If the full range of links capable of being expressed in 5988 is desired, creating new serialisations of 5988 links (without a hop through 6690) is preferable. If the current approach is kept, it'd be nice to clarify this situation a bit in the Introduction. From nobody Tue Apr 11 00:33:57 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9E1128954; Tue, 11 Apr 2017 00:33:55 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em0Bphy2FgcI; Tue, 11 Apr 2017 00:33:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D55F1272E1; Tue, 11 Apr 2017 00:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3B7XiVi016689; Tue, 11 Apr 2017 09:33:44 +0200 (CEST) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w2Jh80fd0zDGv9; Tue, 11 Apr 2017 09:33:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149188258769.15738.17473942496982365590@ietfa.amsl.com> Date: Tue, 11 Apr 2017 09:33:43 +0200 Cc: art@ietf.org, ietf@ietf.org, core@ietf.org, draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 513588823.52644-849855f363bc0cd0868f57315eaebce9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 07:33:55 -0000 Hi Mark, thank you a lot for another thoughtful review. I don=E2=80=99t have an opinion yet on what we should do here, so I=E2=80=99= ll supply some more background first. The present spec is first and foremost intended to round-trip with RFC = 6690, which is indeed stuck a bit on HTTP Link header field syntax. = However, the way this is used in practice is not meant to inherit the = complexities of HTTP header field coding. E.g., for CoRE Resource = Directory and its DNS-SD compatibility, we want to represent a DNS-SD = instance identifier (which is UTF-8) as a link attribute. This is not a = problem in JSON or CBOR, but also not in the way RFC 6690 is being used, = i.e. as a UTF-8 based format. I haven=E2=80=99t checked yet what 5988bis brings to the table and how = to track this in 6690 or possibly a 6690bis. There is no point in Big = Web and Thing Web diverging here, so we should follow the lead. But = maybe that would touch both 6690 and the present document once 5988bis = is done. More importantly, we haven=E2=80=99t really put a lot of thinking into = IRI support. The CoAP data type =E2=80=9Cstring=E2=80=9D which is used = for URI components such as Uri-Path is UTF-8, so we could embrace them = by extending the rules in section 6 of RFC 7252 to cover IRIs. I=E2=80=99= m sure that, in practice, CoAP implementations already do this =E2=80=94 = it is not distinguishable in the CoAP packet whether the (decomposed) = CoAP Uri components have been derived from URIs or IRIs. But the = metadata formats (6690 and its JSON/CBOR representations; various other = JSON and CBOR based formats, e.g. from OCF) are still based on RFC 3986 = URIs, except where they also use the CoAP decomposed form (e.g., CORAL). While this is outside the scope of the CoRE WG, I personally would like = to explore how link-format+cbor/+json could be useful for the Big Web. = If embracing IRIs there is all we need to make this happen, maybe that = can be added with a warning that IRIs have to be converted back to URIs = for 6690 link-format. Gr=C3=BC=C3=9Fe, Carsten > On Apr 11, 2017, at 05:49, Mark Nottingham wrote: >=20 > Reviewer: Mark Nottingham > Review result: Ready with Issues >=20 > This specification is a relatively straightforward mapping of the > format described in RFC6690 (itself a serialisation of RFC5988bis > links) into JSON and CBOR. I don't have deep knowledge of CBOR, but > given the editorship of the document, I trust it's seen adequate > review in that regard. >=20 > The only potential issue is how this is achieved. Rather than defining > two new serialisations of RFC5988bis links (into JSON and CBOR), it > describes how to re-serialise RFC6690 documents into JSON and CBOR. > This means that any constraints upon RFC6690 documents are also > mirrored into these formats; e.g., the target IRI is constrained to be > a URI in 6690, and therefore can also only be a URI in JSON and CBOR, > despite these formats' ability to easily convey non-ASCII content. >=20 > In other words, the specification currently defines these link formats > in terms of the Link header (as defined in section 5 of RFC5988) -- > along with all of the foibles of HTTP header syntax -- rather than > their abstract model (defined in Section 3). >=20 > Whether or not this is a problem depends on what's desired; if 6690 is > seen as effectively a profile of 5988, then it makes sense to express > it in those terms. If the full range of links capable of being > expressed in 5988 is desired, creating new serialisations of 5988 > links (without a hop through 6690) is preferable. >=20 > If the current approach is kept, it'd be nice to clarify this > situation a bit in the Introduction. >=20 >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art >=20 From nobody Tue Apr 11 19:42:42 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903D5126CD8; Tue, 11 Apr 2017 19:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcrNX87zLUnb; Tue, 11 Apr 2017 19:42:29 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401621242F5; Tue, 11 Apr 2017 19:42:29 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CFC6822E253; Tue, 11 Apr 2017 22:42:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham X-Priority: 3 In-Reply-To: <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> Date: Wed, 12 Apr 2017 12:42:16 +1000 Cc: Carsten Bormann , art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> To: weigengyu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 02:42:33 -0000 So, is COAP using WebSockets for browser access, or for firewall = traversal? The paper below seems to indicate the latter, and so the = original question remains. Also, the assertions about firewalls are interesting; we're hearing very = different assertions in the discussions of QUIC (e.g,. 90%+ success = rates for UDP protocols). Cheers, > On 12 Apr 2017, at 12:38 pm, weigengyu wrote: >=20 > Hi Mark, >=20 >> OK. Just curious -- is there a strong motivation here? >> It seems very odd to tunnel HTTP-like semantics over a custom UDP = protocol (COAP) over WebSockets over HTTP again, >> rather than just using HTTP (which AIUI you already have a mapping = to). >=20 > It is meaningful and interesting. > CoAP/UDP/IPv6 protocl stack can run well within CoRE environments. > But if CoAP/UDP is tried in the Internet, it will be blocked due to = NAT/firewall etcs based on tests done here a few years ago. > CoAP/TCP or CoAP/WSS could help CoAP messages and applications = available around Internet. >=20 > We have done some works about this topics. > The following are two abstracts of my master course students' theses, = in which may be interested. >=20 > THE RESEARCH AND DEVELOPMENT OF CoAP over TCP > ABSTRACT > The CoAP protocol is a restricted resource application protocol. In = the CoAP protocol research and application, the default CoAP protocol > stack use UDP as the transport layer=E3=80=82In the Ethernet = environment, data transmission will be affected because of the existence = of the firewall . > For the reason that CoAP can be better applied to the current Internet = environment and cloud environment, IETF working group proposed CoAP over = TCP, > CoAP protocol stack use TCP as the transport layer .In this context, = CoAP over TCP is studied and CoAP over TCP is implemented based on the > open source framework Californium. The CoAP over TCP is implemented as = a client in the real Internet environment and the function of the > implementation is evaluated. CoAP over TCP is the Internet of Things = cloud platform services, so AWS environment is used to achieve CoAP over = TLS/TCP > and the default protocol stack performance comparison. > In this paper, the significance of CoAP over TCP is expatiated, and = CoAP over TCP is studied. After that, the overall architecture of = Californium framework > is deeply analyzed, and the design scheme of CoAP over TCP is = proposed. The transport layer is extended on the basis of the original = frame structure. > Based on the design scheme, the modules are designed and designed in = detail. On the core of the class through the class diagram describes the = expansion > of the relationship between the various modules. The network layer, = protocol layer and application layer implementation process are analyzed = in detail. > Afterwards, we study the proxy between CoAP over TCP and default = protocol stack, and propose the message type conversion problem and = solution of CoAPToCoAP proxy. > The paper concludes the relevant work, and puts forward the research = direction of the next step. > KEY WORDS: CoAP over TCP Proxy Californium Frame >=20 > THE DESIGN AND IMPLEMENTATION OF COAP OVER WEBSOCKET > ABSTRACT > The concept of Internet of Things (IoT) was originally proposed almost = twenty years ago. Over the past many years, IoT has gone through huge = and rapid development, > and the field of Wireless Sensor Network (WSN) has witnessed = remarkable advancement in particular. Compared to the progress of WSN, = the practical service > and application of IoT still has a very long way to go. Although = current industry standards can meet those equipments like smart phones, = they are not quite suitable > for constrained nodes which are often battery supported and has = relatively lower processing ability. Driven by such demands, the IETF = set up CoRE working group > to design a RESTful application protocol which can perform better = among constrained nodes in constrained environments. > The protocol was named Constrained Application Protocol (CoAP) and it = was later standardized as RFC 7252. > This paper analizes the features and defect of the HTTP/CoAP proxy = proposed in RFC 7252, and explains the CoAP over WebSocket proxy as well = as its advantages over > the HTTP/CoAP proxy. Then a design and implementation of CoAP over = WebSocket based on Californium open-source framework is given. = Performance tests and > experiments have shown that the CoAP over WebSocket approach has some = significant advantages over HTTP/CoAP proxy in term of response time and = high concurrency > requests processing ability. > KEY WORDS: computer network, iot, coap, network proxy, websocket >=20 >=20 > Regards, >=20 > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Mark Nottingham > Sent: Tuesday, April 11, 2017 8:39 AM > To: Carsten Bormann > Cc: art@ietf.org ; draft-ietf-core-coap-tcp-tls.all@ietf.org ; = ietf@ietf.org ; core@ietf.org > Subject: Re: [core] Artart last call review of = draft-ietf-core-coap-tcp-tls-07 >=20 > Hi Carsten, >=20 > Couple of quic responses below. >=20 > On 10 Apr 2017, at 7:46 pm, Carsten Bormann wrote: >=20 >> I agree that the introduction should focus on the Browser use case = and keep out of the firewall traversal jungle. >=20 > OK. Just curious -- is there a strong motivation here? It seems very = odd to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over = WebSockets over HTTP again, rather than just using HTTP (which AIUI you = already have a mapping to). >=20 >=20 >>> Section 7 defines a number of new URI schemes for COAP protocols. >>> Syntactically, they use "+" to separate "coap" from the underlying >>> transport(-ish) protocol that they're bound to; e.g., "coap+tcp". = This >>> syntax is allowed by RFC3986, but is unprecedented, and implies a >>> sub-syntax convention similar to those used in media types, etc. Is >>> there an expectation that other URI schemes starting with "coap+" = are >>> reserved? >>=20 >> There is no such expectation. >>=20 >> We did have the discussion about reserved URI scheme prefixes in the = IETF, and as I recall, the result was that there are none. While it = would be a bit weird to register a URI scheme starting with coap+ or = coaps+ that is unrelated to CoAP, only the slightly boggled response = from an expert review is in the way of that happening. >>=20 >> Would the scheme names be more palatable with a dash instead of a = plus? >> Careful choice of the scheme name mostly benefits the implementer, so = it can be changed in the spec (at the cost of changing existing = implementations). >=20 > OK. I'm mostly noting this in case other folks feel that this is a bad = precedent for URI schemes; I think the bigger concern is the one below. >=20 >=20 >>> Defining URI schemes that switch transport protocol based upon their >>> name deserves wider review as well; this has been a contentious = topic >>> in the past, and it would be good to understand what tradeoffs are >>> being made by doing so. Locking identifiers into a specific = transport >>> protocol sacrifices much of the power of URLs. >>=20 >> The =E2=80=9Csiloing=E2=80=9D of URIs along schemes is indeed a = problem, which started for CoAP with the separation of the coap:/coaps: = name spaces. The CoRE WG did not see it as its task to address this = shortcoming. So, for now, we=E2=80=99ll have to live with it; = approaches such as draft-silverajan-core-coap-protocol-negotiation are = trying to address its practicalities. >=20 > By defining multiple URI schemes for different transports of the same = protocol, the WG has taken a position as to what the solution is. I'm = finding it difficult to square this with the continuing characterisation = of CORE as "RESTful". >=20 >=20 >>> Furthermore, creating >>> "coap+ws" to denote a specific protocol over WebSockets (which has = its >>> own URI scheme) is questionable; taken to its natural conclusion, >>> we'll have a proliferation of URI schemes for things over = WebSockets. >>=20 >> I=E2=80=99m not sure that a proliferation will happen =E2=80=94 = WebSockets is mostly used for tightly bound proprietary protocols = between a JavaScript mobile code client and a server that provides this = mobile code client. On the other hand, deciding to never use URIs to = refer to resources available over a WebSockets protocol strikes me as an = unnecessary restriction. >>=20 >>> Will COAP take the same approach for HTTP? >>=20 >> Not sure what this question is leading into. >> (We do have a defined relationship with HTTP, in RFC 7252 and RFC = 8075. >> But maybe this is about something different.) >=20 > I mean to ask whether there will be a need for a "coap+http" URI = scheme; it seems like a logical conclusion of the approach taken here. >=20 >=20 >>> I would suggest a wider discussion of these issues on art@ / uri@. >>=20 >> Indeed, a wider discussion of these longstanding issues would be = useful. >> I=E2=80=99m not sure that waiting for their resolution is blocking = this spec. >>=20 >>> Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" >>> URI, using a well-known URI in the "wss" scheme. However, "wss" is = not >>> defined to use well-known URIs, so this is an invalid use. >>=20 >> This incorrect use of RFC 5785 is indeed embarrassing. More about = that later. >=20 > OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, = but I think that would take a separate RFC that updates their scheme = registrations. Not sure whether there would be any pushback in that = community (but I can't see any immediate reason why there would be). >=20 >=20 >>> Section 8.1 makes it Mandatory to Implement the protocol without any >>> security ("NoSec"). This seems counter to best practice in the IETF, >>> but I'll defer to the Security Area review. >>=20 >> Since it is the implementers who will decide whether they implement = this, this co-author could live with making implementing NoSec = completely optional. (It will be anyway, in practice, at the level of = what is actually configured.) The important point(*) from the WG = perspective here is that TLS is mandatory to implement, with the = specifics depending on the security mode needed (cf. RFC 7925). (Note = also that there are other ways to provide security with CoAP.) >=20 > Ack. Again, this was mostly a note to bring it to others' attention; = the use of the phrase "Mandatory to Implement" when applied to "no = security" just seems odd. >=20 > Cheers, >=20 >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> (*) = https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e935424= 2012afb28dc60 >>=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 11 19:43:31 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936A112762F for ; Tue, 11 Apr 2017 19:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFlsyiuoGsmu for ; Tue, 11 Apr 2017 19:43:28 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA5E1293F4 for ; Tue, 11 Apr 2017 19:43:19 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.36]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9CE6A19F380; Wed, 12 Apr 2017 10:37:56 +0800 (HKT) Message-ID: <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> From: "weigengyu" To: "Mark Nottingham" , "Carsten Bormann" Cc: , , , References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> In-Reply-To: <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> Date: Wed, 12 Apr 2017 10:38:12 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 02:43:29 -0000 Hi Mark, > OK. Just curious -- is there a strong motivation here? > It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol > (COAP) over WebSockets over HTTP again, > rather than just using HTTP (which AIUI you already have a mapping to). It is meaningful and interesting. CoAP/UDP/IPv6 protocl stack can run well within CoRE environments. But if CoAP/UDP is tried in the Internet, it will be blocked due to NAT/firewall etcs based on tests done here a few years ago. CoAP/TCP or CoAP/WSS could help CoAP messages and applications available around Internet. We have done some works about this topics. The following are two abstracts of my master course students' theses, in which may be interested. THE RESEARCH AND DEVELOPMENT OF CoAP over TCP ABSTRACT The CoAP protocol is a restricted resource application protocol. In the CoAP protocol research and application, the default CoAP protocol stack use UDP as the transport layer。In the Ethernet environment, data transmission will be affected because of the existence of the firewall . For the reason that CoAP can be better applied to the current Internet environment and cloud environment, IETF working group proposed CoAP over TCP, CoAP protocol stack use TCP as the transport layer .In this context, CoAP over TCP is studied and CoAP over TCP is implemented based on the open source framework Californium. The CoAP over TCP is implemented as a client in the real Internet environment and the function of the implementation is evaluated. CoAP over TCP is the Internet of Things cloud platform services, so AWS environment is used to achieve CoAP over TLS/TCP and the default protocol stack performance comparison. In this paper, the significance of CoAP over TCP is expatiated, and CoAP over TCP is studied. After that, the overall architecture of Californium framework is deeply analyzed, and the design scheme of CoAP over TCP is proposed. The transport layer is extended on the basis of the original frame structure. Based on the design scheme, the modules are designed and designed in detail. On the core of the class through the class diagram describes the expansion of the relationship between the various modules. The network layer, protocol layer and application layer implementation process are analyzed in detail. Afterwards, we study the proxy between CoAP over TCP and default protocol stack, and propose the message type conversion problem and solution of CoAPToCoAP proxy. The paper concludes the relevant work, and puts forward the research direction of the next step. KEY WORDS: CoAP over TCP Proxy Californium Frame THE DESIGN AND IMPLEMENTATION OF COAP OVER WEBSOCKET ABSTRACT The concept of Internet of Things (IoT) was originally proposed almost twenty years ago. Over the past many years, IoT has gone through huge and rapid development, and the field of Wireless Sensor Network (WSN) has witnessed remarkable advancement in particular. Compared to the progress of WSN, the practical service and application of IoT still has a very long way to go. Although current industry standards can meet those equipments like smart phones, they are not quite suitable for constrained nodes which are often battery supported and has relatively lower processing ability. Driven by such demands, the IETF set up CoRE working group to design a RESTful application protocol which can perform better among constrained nodes in constrained environments. The protocol was named Constrained Application Protocol (CoAP) and it was later standardized as RFC 7252. This paper analizes the features and defect of the HTTP/CoAP proxy proposed in RFC 7252, and explains the CoAP over WebSocket proxy as well as its advantages over the HTTP/CoAP proxy. Then a design and implementation of CoAP over WebSocket based on Californium open-source framework is given. Performance tests and experiments have shown that the CoAP over WebSocket approach has some significant advantages over HTTP/CoAP proxy in term of response time and high concurrency requests processing ability. KEY WORDS: computer network, iot, coap, network proxy, websocket Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Mark Nottingham Sent: Tuesday, April 11, 2017 8:39 AM To: Carsten Bormann Cc: art@ietf.org ; draft-ietf-core-coap-tcp-tls.all@ietf.org ; ietf@ietf.org ; core@ietf.org Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Hi Carsten, Couple of quic responses below. On 10 Apr 2017, at 7:46 pm, Carsten Bormann wrote: > I agree that the introduction should focus on the Browser use case and > keep out of the firewall traversal jungle. OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over HTTP again, rather than just using HTTP (which AIUI you already have a mapping to). >> Section 7 defines a number of new URI schemes for COAP protocols. >> Syntactically, they use "+" to separate "coap" from the underlying >> transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This >> syntax is allowed by RFC3986, but is unprecedented, and implies a >> sub-syntax convention similar to those used in media types, etc. Is >> there an expectation that other URI schemes starting with "coap+" are >> reserved? > > There is no such expectation. > > We did have the discussion about reserved URI scheme prefixes in the IETF, > and as I recall, the result was that there are none. While it would be a > bit weird to register a URI scheme starting with coap+ or coaps+ that is > unrelated to CoAP, only the slightly boggled response from an expert > review is in the way of that happening. > > Would the scheme names be more palatable with a dash instead of a plus? > Careful choice of the scheme name mostly benefits the implementer, so it > can be changed in the spec (at the cost of changing existing > implementations). OK. I'm mostly noting this in case other folks feel that this is a bad precedent for URI schemes; I think the bigger concern is the one below. >> Defining URI schemes that switch transport protocol based upon their >> name deserves wider review as well; this has been a contentious topic >> in the past, and it would be good to understand what tradeoffs are >> being made by doing so. Locking identifiers into a specific transport >> protocol sacrifices much of the power of URLs. > > The “siloing” of URIs along schemes is indeed a problem, which started > for CoAP with the separation of the coap:/coaps: name spaces. The CoRE WG > did not see it as its task to address this shortcoming. So, for now, we’ll > have to live with it; approaches such as > draft-silverajan-core-coap-protocol-negotiation are trying to address its > practicalities. By defining multiple URI schemes for different transports of the same protocol, the WG has taken a position as to what the solution is. I'm finding it difficult to square this with the continuing characterisation of CORE as "RESTful". >> Furthermore, creating >> "coap+ws" to denote a specific protocol over WebSockets (which has its >> own URI scheme) is questionable; taken to its natural conclusion, >> we'll have a proliferation of URI schemes for things over WebSockets. > > I’m not sure that a proliferation will happen — WebSockets is mostly > used for tightly bound proprietary protocols between a JavaScript mobile > code client and a server that provides this mobile code client. On the > other hand, deciding to never use URIs to refer to resources available > over a WebSockets protocol strikes me as an unnecessary restriction. > >> Will COAP take the same approach for HTTP? > > Not sure what this question is leading into. > (We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075. > But maybe this is about something different.) I mean to ask whether there will be a need for a "coap+http" URI scheme; it seems like a logical conclusion of the approach taken here. >> I would suggest a wider discussion of these issues on art@ / uri@. > > Indeed, a wider discussion of these longstanding issues would be useful. > I’m not sure that waiting for their resolution is blocking this spec. > >> Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" >> URI, using a well-known URI in the "wss" scheme. However, "wss" is not >> defined to use well-known URIs, so this is an invalid use. > > This incorrect use of RFC 5785 is indeed embarrassing. More about that > later. OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, but I think that would take a separate RFC that updates their scheme registrations. Not sure whether there would be any pushback in that community (but I can't see any immediate reason why there would be). >> Section 8.1 makes it Mandatory to Implement the protocol without any >> security ("NoSec"). This seems counter to best practice in the IETF, >> but I'll defer to the Security Area review. > > Since it is the implementers who will decide whether they implement this, > this co-author could live with making implementing NoSec completely > optional. (It will be anyway, in practice, at the level of what is > actually configured.) The important point(*) from the WG perspective here > is that TLS is mandatory to implement, with the specifics depending on the > security mode needed (cf. RFC 7925). (Note also that there are other ways > to provide security with CoAP.) Ack. Again, this was mostly a note to bring it to others' attention; the use of the phrase "Mandatory to Implement" when applied to "no security" just seems odd. Cheers, > > Grüße, Carsten > > (*) > https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60 > -- Mark Nottingham https://www.mnot.net/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 11 21:05:02 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8563126B71; Tue, 11 Apr 2017 21:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyZA3icPqMiG; Tue, 11 Apr 2017 21:04:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFD012009C; Tue, 11 Apr 2017 21:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3C44YFs013672; Wed, 12 Apr 2017 06:04:34 +0200 (CEST) Received: from client-0052.vpn.uni-bremen.de (client-0052.vpn.uni-bremen.de [134.102.107.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w2r0L04mjzDHMj; Wed, 12 Apr 2017 06:04:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> Date: Wed, 12 Apr 2017 06:04:33 +0200 Cc: weigengyu , art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 513662673.384077-8d9577bc6a7635a03537385cb9593471 Content-Transfer-Encoding: quoted-printable Message-Id: <9302A268-50CF-4688-A79D-8343E5B9B7CE@tzi.org> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 04:04:46 -0000 On Apr 12, 2017, at 04:42, Mark Nottingham wrote: >=20 > So, is COAP using WebSockets for browser access, or for firewall = traversal? The paper below seems to indicate the latter, and so the = original question remains. Can=E2=80=99t answer that for Gengyu, but the term =E2=80=9Cfirewall=E2=80= =9D occurs in the CoAP over TCP abstract, not in the CoAP over = WebSockets one. I continue to maintain that for CoAP over WebSockets the access to CoAP = proxies from browsers is the motivating case. (Yes, these could also be = HTTP to CoAP cross-protocol proxies, but there are impedance mismatches = here; e.g., for a browser application that wants to observe a CoAP = resource.) > Also, the assertions about firewalls are interesting; we're hearing = very different assertions in the discussions of QUIC (e.g,. 90%+ success = rates for UDP protocols). Apart from the backend motivation, the main motivation for CoAP over TCP = was easier NAT traversal (UDP bindings are timed out much faster in most = NATs). This may extend to other middleboxes, including firewalls that = build (and then time out) UDP-based state. I=E2=80=99m not sure the QUIC numbers transfer to this use case very = well, as QUIC is mostly used for web page access from browsers, so short = NAT binding timeouts don=E2=80=99t matter that much. For a sensor that = needs to be accessed every 30 minutes, these are much more of an issue. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 12 02:51:53 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF77A131511; Wed, 12 Apr 2017 02:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AV3p0dfm7GK; Wed, 12 Apr 2017 02:51:42 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C3131526; Wed, 12 Apr 2017 02:51:41 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 12 Apr 2017 11:51:35 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 11:51:39 +0200 From: "Kovatsch Matthias" To: Mark Nottingham , Carsten Bormann CC: "art@ietf.org" , "draft-ietf-core-coap-tcp-tls.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsbAL4XGhCj4NBUOslxkUkswmRKG+Oc0AgAD5ZgCAAkm54A== Date: Wed, 12 Apr 2017 09:51:38 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> In-Reply-To: <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.195.112.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 09:51:45 -0000 RGVhciBNYXJrDQoNCj4gT0suIEp1c3QgY3VyaW91cyAtLSBpcyB0aGVyZSBhIHN0cm9uZyBtb3Rp dmF0aW9uIGhlcmU/IEl0IHNlZW1zIHZlcnkgb2RkIHRvIHR1bm5lbA0KPiBIVFRQLWxpa2Ugc2Vt YW50aWNzIG92ZXIgYSBjdXN0b20gVURQIHByb3RvY29sIChDT0FQKSBvdmVyIFdlYlNvY2tldHMg b3Zlcg0KPiBIVFRQIGFnYWluLCByYXRoZXIgdGhhbiBqdXN0IHVzaW5nIEhUVFAgKHdoaWNoIEFJ VUkgeW91IGFscmVhZHkgaGF2ZSBhIG1hcHBpbmcNCj4gdG8pLg0KDQpUaGUgbW90aXZhdGlvbiBp cyB0byBjb25uZWN0IHRoZSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCB0byB0aGUgV2ViIGJyb3dz ZXIuIElkZWFsbHksIG9uZSB3b3VsZCB1c2UgSFRUUCBmcm9tIHRoZSBicm93c2VyIHRvIHRhbGsg dG8gYSBIVFRQLUNvQVAgY3Jvc3MtcHJveHksIHdoaWNoIGluIHR1cm4gdGFsa3MgdG8gdGhlIGNv bnN0cmFpbmVkIGRldmljZS4gVGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0IEhUVFAgbmV2ZXIgcHJv cGVybHkgYW5kIHVuaXF1ZWx5IHNvbHZlZCBzZXJ2ZXIgcHVzaCwgd2hpY2ggaXMgcXVpdGUgY3J1 Y2lhbCBmb3IgcmVzb3VyY2UtY29uc3RyYWluZWQgZGV2aWNlcyBhbmQgSW9UIHVzZSBjYXNlcy4g VGh1cy0tLWV2ZW4gYmV5b25kIHRoZSBDb1JFIHVzZSBjYXNlLS0tcGVvcGxlIHJlc29ydCB0byBX ZWJTb2NrZXRzLiBTaW5jZSBXZWJTb2NrZXRzIGFyZSBqdXN0IGEgYnJvd3NlciB2ZXJzaW9uIG9m IFRDUCwgcGVvcGxlIGFsc28gaGF2ZSB0byBpbnZlbnQgdGhlaXIgb3duIHByb3RvY29sIGV2ZXJ5 IHRpbWUuLi4gVGhpcyBpcyB3aGVyZSBDb0FQLW92ZXItV2ViU29ja2V0cyBoZWxwcywgb2YgY291 cnNlIHdpdGggdGhlIHByaW1hcnkgZm9jdXMgdG8gc2VhbWxlc3NseSBjb25uZWN0IHRvIGNvbnN0 cmFpbmVkIGRldmljZXMuDQoNCkkgYW0gbm90IHN1cmUgd2hhdCBpcyB0aGUgcHJlZmVycmVkIHdh eSB0byBzb2x2ZSB0aGUgYXN5bmMgY29tbXVuaWNhdGlvbiBpc3N1ZSBvZiBIVFRQLiBTZXJ2ZXIg U2VudCBFdmVudHMsIGZvciBpbnN0YW5jZSwgYXJlIGFscmVhZHkgcHJldHR5IGNsb3NlIHRvIHRo ZSBPYnNlcnZlIG1lY2hhbmlzbS4gTWF5YmUgd2UgY291bGQgcHJvcGVybHkgZml4IHRoZSBwdXNo IHN1cHBvcnQgb2YgSFRUUCB0byBjb3VudGVyIHRoZSBlbmRsZXNzIHN0YWNraW5nIG9mIHByb3Rv Y29scyBhIGJpdD8NCg0KQmVzdCByZWdhcmRzDQpNYXR0aGlhcw0K From nobody Wed Apr 12 03:06:33 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6F7131559; Wed, 12 Apr 2017 03:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUfiBIwyP8fX; Wed, 12 Apr 2017 03:06:25 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFBD131546; Wed, 12 Apr 2017 03:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491991584; d=isode.com; s=june2016; i=@isode.com; bh=+GpEPL5/0zpcK40iiymiYtDj5GeLhe4qhSu0Wkc4aac=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ohEPv9wp6nyWJwNXZ0bjUkzYIdlpY0CaIisF+xe4aG23DPHpU1NwXByoSReA1oGYUUAwyp UxyimK903SkKTHpS4d6p7E7aclHKu8HAp8mBxg8aHupooA9IEH6M/6XxhS8AY4lCZHr8/x 2QeFD/SRfeOCviPvkZJ2jDHhYTerdfk=; Received: from [172.20.1.215] ((unknown) [62.232.206.186]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 12 Apr 2017 11:06:24 +0100 X-SMTP-Protocol-Errors: NORDNS To: Kovatsch Matthias , Mark Nottingham , Carsten Bormann References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> Cc: "art@ietf.org" , "draft-ietf-core-coap-tcp-tls.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" From: Alexey Melnikov Message-ID: Date: Wed, 12 Apr 2017 11:06:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:06:27 -0000 Hi Matthias, On 12/04/2017 10:51, Kovatsch Matthias wrote: > Dear Mark > >> OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel >> HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over >> HTTP again, rather than just using HTTP (which AIUI you already have a mapping >> to). > The motivation is to connect the constrained environment to the Web browser. Ideally, one would use HTTP from the browser to talk to a HTTP-CoAP cross-proxy, which in turn talks to the constrained device. The problem here is that HTTP never properly and uniquely solved server push, which is quite crucial for resource-constrained devices and IoT use cases. Thus---even beyond the CoRE use case---people resort to WebSockets. Since WebSockets are just a browser version of TCP, people also have to invent their own protocol every time... This is where CoAP-over-WebSockets helps, of course with the primary focus to seamlessly connect to constrained devices. > > I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly fix the push support of HTTP to counter the endless stacking of protocols a bit? We have a WG for this: https://datatracker.ietf.org/wg/webpush/about/ From nobody Wed Apr 12 03:09:49 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE47131546; Wed, 12 Apr 2017 03:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWnK_MNT7dyb; Wed, 12 Apr 2017 03:09:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6304131574; Wed, 12 Apr 2017 03:09:37 -0700 (PDT) Received: from [192.168.3.100] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4AD4B22E261; Wed, 12 Apr 2017 06:09:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Wed, 12 Apr 2017 20:09:21 +1000 Cc: Kovatsch Matthias , Carsten Bormann , "art@ietf.org" , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:09:41 -0000 [ cutting down the CC a bit ] > On 12 Apr 2017, at 8:06 pm, Alexey Melnikov = wrote: >=20 > Hi Matthias, >=20 >=20 > On 12/04/2017 10:51, Kovatsch Matthias wrote: >> Dear Mark >>=20 >>> OK. Just curious -- is there a strong motivation here? It seems very = odd to tunnel >>> HTTP-like semantics over a custom UDP protocol (COAP) over = WebSockets over >>> HTTP again, rather than just using HTTP (which AIUI you already have = a mapping >>> to). >> The motivation is to connect the constrained environment to the Web = browser. Ideally, one would use HTTP from the browser to talk to a = HTTP-CoAP cross-proxy, which in turn talks to the constrained device. = The problem here is that HTTP never properly and uniquely solved server = push, which is quite crucial for resource-constrained devices and IoT = use cases. Thus---even beyond the CoRE use case---people resort to = WebSockets. Since WebSockets are just a browser version of TCP, people = also have to invent their own protocol every time... This is where = CoAP-over-WebSockets helps, of course with the primary focus to = seamlessly connect to constrained devices. >>=20 >> I am not sure what is the preferred way to solve the async = communication issue of HTTP. Server Sent Events, for instance, are = already pretty close to the Observe mechanism. Maybe we could properly = fix the push support of HTTP to counter the endless stacking of = protocols a bit? > We have a WG for this: > https://datatracker.ietf.org/wg/webpush/about/ Well, yes and no. My understanding is that web push is designed for a = very specific use case / deployment scenario, and it is likely not = appropriate for other uses. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 12 03:17:06 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7C13156F; Wed, 12 Apr 2017 03:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wIti_YFikCH; Wed, 12 Apr 2017 03:17:02 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D410128AB0; Wed, 12 Apr 2017 03:16:59 -0700 (PDT) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 12 Apr 2017 12:16:53 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 12:16:57 +0200 From: "Kovatsch Matthias" To: Mark Nottingham , Alexey Melnikov CC: Carsten Bormann , "art@ietf.org" , "core@ietf.org" Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSs3TkWi82eiIOykGDazObnipNOqHBg/mw Date: Wed, 12 Apr 2017 10:16:56 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B558B2B97A@MBX210.d.ethz.ch> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.195.112.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:17:04 -0000 > >> I am not sure what is the preferred way to solve the async communicati= on > issue of HTTP. Server Sent Events, for instance, are already pretty close= to the > Observe mechanism. Maybe we could properly fix the push support of HTTP t= o > counter the endless stacking of protocols a bit? > > We have a WG for this: > > https://datatracker.ietf.org/wg/webpush/about/ >=20 > Well, yes and no. My understanding is that web push is designed for a ver= y > specific use case / deployment scenario, and it is likely not appropriate= for other > uses. This is also my conclusion about this variant of HTTP push. Best wishes Matthias From nobody Wed Apr 12 03:53:30 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2EA1315FD; Wed, 12 Apr 2017 03:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tutfi.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suNNgl9JGG52; Wed, 12 Apr 2017 03:53:17 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0106.outbound.protection.outlook.com [104.47.0.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C33131601; Wed, 12 Apr 2017 03:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tutfi.onmicrosoft.com; s=selector1-tut-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r95wy0QdwwLsVIXJegmBBR+rVOAzHNUNSAeIy09VDLM=; b=fE/g04rNgjUrtN7mP+0OUgm92UmPfBUeFBYUDIrD4wQ8j5qkyl6rtk2lnK5SgUlB/o5+cvxsR6jhN7xP1bAVGppOuj9uiSjdF36KtzR+07EkbCKe7AqEfNIdRivLHyoz1niuXU+nak3x8Ue7Ie80c7Rlsf/wOLIT9konyjKdumg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=tut.fi; Received: from Bilhanans-MacBook-Pro.local (88.114.43.235) by AM3PR02MB1074.eurprd02.prod.outlook.com (2a01:111:e400:c405::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Wed, 12 Apr 2017 10:53:08 +0000 To: Carsten Bormann , Mark Nottingham References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> <9302A268-50CF-4688-A79D-8343E5B9B7CE@tzi.org> CC: weigengyu , , , , From: Bill Silverajan Message-ID: Date: Wed, 12 Apr 2017 13:53:05 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9302A268-50CF-4688-A79D-8343E5B9B7CE@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [88.114.43.235] X-ClientProxiedBy: VI1PR0802CA0004.eurprd08.prod.outlook.com (2603:10a6:800:aa::14) To AM3PR02MB1074.eurprd02.prod.outlook.com (2a01:111:e400:c405::16) X-MS-Office365-Filtering-Correlation-Id: edff1787-f36b-456c-3983-08d481921b7c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM3PR02MB1074; X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 3:8YiXnG6Au1lTLkEQLBHF2M+cZXcy9DR5jI2SPVqvhMrZ4Xp2MPT1yxTywzAZWBY1yYCz6vJdOa50AcPboFBbA6pbh4M2ofAW7vzUulttbdCKHRAMQlsliErc9HGHfza0olvTiq++AdVlcOUweY58g3/EFD5dHqm8WVbb0XxNMOlTqwiYKmE89lJ4fgmLnTRZ48EA+P5ZYpC2BaNVpkzd7iQuDYXYeQ/RpjTTT5ahDAuqZRm/eCMsnmbtquOWrBMJ73HkqI7ODc2qh+TnwEuMfnashWVUHQcQIgqy6w1RQ3npH/4YBdP1uQc2VZi4K4Y600tRMhucXBCQZgamVS5KPQ==; 25:qZUsMtca7ILoKCKS/oO1AU1LuiKfNixAJnt48bfZR3yABqg4qXDwTz3mMZBfNxdLq/qQK8/1JhBXjcIWzsNMD2lTxvlfzZoFALf6zgGLgQPukYN+3iX42tqByTDVjuSwbQv1IMsID3CXQYQL+URvS6YP2bKJVW/+nrQi0PG+I9wNYreGyakCo08as8kQKcpvY3o17nqCfHpAnj+ep6d8+Q7ojBWQ/q6+UXgT5iXP6QsTRFcjEzv1RwGuUgk/PfuyV3cI3chGYD+8U3yDW415WIvoNIE5UqLsSNL14FkV062cJkFRFnmJnTk+828AncGl+lkQaRnvp78eIz8nhobaoX2PBrAn5PkazVcorSMmu6x8+Zlmlrswm90jDZjfCGwDchOHIHx2TqyQ358ceEBXnDNEh9KEeNAhnAxPWf1hUyze+vNemTrRDzR3N+h2c+c4HvVkuGB9GRi2nJkQpBLAoA== X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 31:iBJN8djrE6b4Sxq2D1rC52XvAe9fpeaHsQpUB/VWLmXY4Gh8hDjPHtPkMBkZ+J6svGURSdHBZ9RmHI7so9mRsOZlS01102f9KCNohSfhwpbYAtfFPyDGrDns2aeRZbV/+MaZnV1sfs41cT73fLEAL4fKa6XP276FQbJArOj+7iQplGEYR+ieSiWunWbrrtBh1UN1385EIS/P3O+fWoQlrPcC8FnjptF+FUtune5LCZuANUQqX/TwbX/k5cbj9WF7; 20:H1QAz0S7U6ARvGBK6IguwHiDOHtWzFjPVK9wQAm0lslKXQCJXCq1GGRlR6cZqj96xh4KMmcQ95XlBQVDUaV2j9beFdYI7nMfPw83bOyXoksDJCfnyKlBkeJV4AqeDr6v9ORjNje9TO4+Wt8jzH89LFT+bUOr1cx/ihaYOd2vTzmOEPI9uVXWxYTyWQEDpvCsHFXiBJCbnC09FYme22K3B6wwrRnq1rLhZ4CTERUJLt2MtkYrvQVkIJGb9jjqkt5z X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(190756311086443)(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM3PR02MB1074; BCL:0; PCL:0; RULEID:; SRVR:AM3PR02MB1074; X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 4:P4EvM01zvSlXwAn4K2bwO33lfK4rF0+RWgaXZZerGSzrkdpt4678Qfncwdmvu7g3hIcoPtzIIUPPyXlsWv3GTbf2SQXDi7/kafgEr2wkKO73fEq5EyABGJTTsfa8xJR00+opISC84T8fjNmqanz0exai14wswUNDYsSGN30u12NgjqFSV45J4/xatIk/Js52SXSvFuw15mF4IjEgp+AUfOdDRMdUCyuiIeQEFMNbNzxGUKr8C05+Z4x5ZTX282HTpIYzVvkaASEM3jaCqJPWtnpdFdtf/b4DbO7sGPb5PTfb53+1GCehaetSaZsO27lDVQ64AMXBwPwrreEJmdW5gsaI1Ecb0IsPwQjlkIAoCzk5hLDTA5uDlcbD/WNYOg3IZQEmcbw34Q45DrCwms9LxXjG04Pl19NAPQ6NB0v2ng0QeISG6vWOOTS1b5Ct3NbNAmC0V+VpDapfSjQKb87OAJjyEm6xcDi/OibXFqcS8BQwVvBTTZYkgzjbdNPuuYWdmRkoDXeNxZ+kaDk8WINYapMB8sUJ6ELmNuCEhTms1wg3CdxbxLGGPm1ifJFY9ExrPcCjiEW86vYhh5NElxydVcUjKD5kbpgJuiAgpPK8pm1W0MhgFYK4MONOb0xL8CU5CCUd8HJ2aOTk5YKB+22nuA0zun8eBqdOzu0cS2v4JO2engROFuCJ73eWf6WXt/OFQk0LBsQA1fMq+nYclGWSKKq3nN1fZwOIcxhw6qz0qmz/bIkuac4nfrELjw/2ZzrKvyIcbY7yZgmcAIRhHfT50ntUzQQWjaIT0AokF9ErZYka2L3jQKgEKNBJxw3TT7FFw/h3AO/cE1IfEppE5nyj2g== X-Forefront-PRVS: 027578BB13 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(24454002)(4326008)(230783001)(50466002)(6506006)(38730400002)(50986999)(7736002)(31696002)(81166006)(54356999)(76176999)(86362001)(8676002)(74482002)(305945005)(31686004)(6246003)(42186005)(6116002)(3846002)(5660300001)(53936002)(6486002)(6512007)(54906002)(229853002)(6666003)(2950100002)(33646002)(4001350100001)(66066001)(2906002)(53546009)(2870700001)(25786009)(189998001)(36756003)(47776003)(23676002)(83506001)(65806001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR02MB1074; H:Bilhanans-MacBook-Pro.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTNQUjAyTUIxMDc0OzIzOkJMYjBZeWhrU0F6dmt3WjVGM1c5bGxTUmYz?= =?utf-8?B?b1Ird0FJY1F6ZFR0VzhVYXQ0TENyM2VBeTFlNmhMOENKSnNhYmdiYUhUQU9U?= =?utf-8?B?L25YYm1aVlo4MmxTTldqU0lyS0M1aElhQkQrb0NUYkF3Y3NyVzVPUkRRNFVY?= =?utf-8?B?YmM2V2RIOVIxdXBhTEc0QUxvTjV5VzF2Yi9keUI4VmdsS2xySjlBcXp6RkhR?= =?utf-8?B?Mjk4T0FoWXpRMlBaNlNKZ2F6SEd2eFp3Wlk1VzVSZzJITFg1WTIxTHR5NEdl?= =?utf-8?B?N21Iam1kZzhGdUxJSit1NXhEWVYwa3VVTElVYUUyRWpDUmJ6bFpia2x4RXlF?= =?utf-8?B?Z1Q0LzhmQUR1UTF2ZUJ3RDkrNm9CbS9QREh4NGJuTkloU0VIQngwcEVZcVhQ?= =?utf-8?B?Z0ZyVUI3ZXd1dWRuVE1XZm56a2VrdzNmb0t6c0xwMWxpYzlYQThHZE4ydzBK?= =?utf-8?B?QlNDWTQyNVJPOTU4RFA0aHNicnlPSGpqVmJtWTJUMzY1MVF6OTkwRG5McFlF?= =?utf-8?B?SWlTRXZEYU5sck9lYTN6RmpFeDJxQTBuWG8vS2hFR3k5eTZNckYzdFNCa2xy?= =?utf-8?B?UDZwMDI1S1VjOEZMM1MwRHlDVGduVjhOY3NpUFBjQUxPaVppa3k2RC9aRE4z?= =?utf-8?B?UzNOVmdqMXBqUlBOV2FKeXRpYWxndEhPTm0yajNiN1pQVkdYaHgzYjJrM1o3?= =?utf-8?B?bUVlOGNrb3J4UnV0NTRybW5tdGNVaUkvakMzRlJxcmV5M0Q0SW04K3B1dm5R?= =?utf-8?B?d1VtcDhwaVpacHhpV0Z4MC9OaW1VVno2Nm9PeFdtaW9hUjQ3Y2tUazNaRHdx?= =?utf-8?B?bVRJV0FUaldJa0xJZWt0MVhlNTBMZko2OUxLRHgrN3M2ZXZvekNiTjJ4d3Nl?= =?utf-8?B?L3FaalVXTXJrdEUxRzJNNHpxZUZWV1BpSFhPN2h6SzdsR2YzdTdJa1lxN2tI?= =?utf-8?B?Mzhwd3FmSzZXNHhsMHAwWkZmaWxRTnRObG1SdkVhQ2VlN3pxT1pkZW5aNklT?= =?utf-8?B?VHA0NitjaWRpV1c1SUZEQ1o0MGdtWnBsTENDUUcyUU56UW82a2ZhZCtGQk1W?= =?utf-8?B?dnhBMHlRQmgwL2lYOUppNlZIQWJRWGNJM2dpTElEYmR1UkxLTnUzL0xNcUx0?= =?utf-8?B?THVOMHlMd2NvTDhqUVJCNDhnb1FsZCswTldNSDJoalBOMmo4aWRCNlFwank1?= =?utf-8?B?TnZpOUJ1akp5Z1QxZ3g2ZngrNTJzd2pwZUp0MlkvTDNscFJXZGdwUE5aeWYy?= =?utf-8?B?Ui9VVS8xdW9ETjdYcThXcXo1SjhVcFFwcEJqKzNIODMwbjBVY1ZxcG5vS3RK?= =?utf-8?B?VEFkZEtQbENtY2REcGdpNGdqVWpTSkVranhSS3h5Y1JyQURVZWE0eVdueGZV?= =?utf-8?B?YktCZGEzak5wbGtsZktmNnhIeFFyNlJkTjBZRHlqK082RlFqSm5sN1QrclJJ?= =?utf-8?B?TnUwSWRJWkNFUnBFWnVhdnpqa0NhU1l4aG85Qms5cDFWZW1FSktiQjR1Nkls?= =?utf-8?B?MjR0Y3grcGRPdTEwalp4NlEvTnpROHZlSG16RGlPUGI5NFB2M2VSRVY3eTVV?= =?utf-8?Q?zsSXRm2Ev2RQulgagqf+xGZ1rwv/r6vlVc7MBn7Fxn/M=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 6:TRVc5W4Ukguue5/CDr9bG1N5RyqL2cBy4m2Xxkqm9KAmut0+FV9h3IsoH52DDf54TtQN3Tb/lIVfwWJMzg792fuZxjvmsEVAA7YWXm0a2KjgOqUwmJFElKUDcttcPNSt7tT7AIXkraKrCHRRniCysN6BeGm5Fla14AxhpVCbK1FQHfTB6IIrMQPMCGqJg9ZVYYeQbQ7CkyQuCovQMmPd8Q24ClYX3fub9JRhJrHOisK26XaNIylBmaaWyxm00AIeQnfdMJeW+1t/RX3c0iqbx5XOHlYk5UOpQzArtJtg38j1coCDS/2vVo4sTG1GTA1mLH64Nyam4vqRCqRvjRtygUjie8CWwDNPjkrgzHNbN/EhReQmZ+cUhDVaq3U19SXEZdL7j7YC8dy/PAKZSWdZQ7dE8AkBZJ7Pkj+mcTPerxmuNKhxU6oALnVtzJf4KaHsuEV+GRU6wDP0h2rNMtxWRQ==; 5:f+DyIRWpqnCA0KOOt68qNU6mhFAlc3VS/wrWObmIq3+a+tZ2+3X8N3FjYWiFJJlTN5UJic3geI/vPKttITzjoxDJ3Qf8D7XR3TbwDdn9Sb785KFAEfds5QmVsxU1qutWitpOQ/24UkI2QkwD1ywtTg==; 24:Ho1j5gdevsUmkWKEP5Z5eYOrJSizLiL+lBzsSy43FMoNi4TjkJrZqrnw0q6OWXpYwLiERnAZJpYQBpy7Xi0G2r0zZtNNyfaxq1nRDAA58H4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM3PR02MB1074; 7:BMWymjTfhiQi18T7YTRc8Yd0bLZFD/MF/mjEnFR8QKqZUdUkaRp1n7Y+MLJYmh+TTJRyBOh5sbJDyPlgRQnjPdYm5zCLBMerylL/q/PEPoH953B3q9bmzyeFVJfSBnoAp752gC3UbEXO5KkzPuT1VOyoAHXWO51f7eJXFy/EWr2IbwmVPz8jfudCAaSjSaT+eyttdKMCvjBXOdpVD2m1idTvD0+D75Sacy2VnzQRNN6YQaqQG14PEPKIvEjwOQwwo8VF+SNft5axw9Z2v8utUlROTzty0fjja45klACcjZtpM/lHn38ybQde9hGUzVuFn8x3plvemCouiBa1IhNG1A== X-OriginatorOrg: tut.fi X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2017 10:53:08.5800 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR02MB1074 Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:53:19 -0000 Hello, On 12/04/17 07:04, Carsten Bormann wrote: > On Apr 12, 2017, at 04:42, Mark Nottingham wrote: >> So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains. > Can’t answer that for Gengyu, but the term “firewall” occurs in the CoAP over TCP abstract, not in the CoAP over WebSockets one. > > I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case. (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are impedance mismatches here; e.g., for a browser application that wants to observe a CoAP resource.) > Carsten's right. The primary use case which motivated us to undertake the work were for browser access, and for sandboxed web applications that want to use CoAP-based communication to a end-point, but are restricted from using system-level APIs such as TCP or UDP socket libraries. Matthias (in a forked version of this message thread) also mentioned where we saw benefits in allowing CoAP over Websockets to reach constrained devices. While the work was progressing however, we did become aware of minor use cases where using CoAP over Websockets can provide an advantage: Reaching constrained nodes residing in domains where end users may lack the authority to configure middleboxes to allow new services over TCP/UDP. This is commonplace in particularly restrictive and firewalled networks that otherwise allow traditional messaging, email and web-based services. However, I need to emphasise this is a minor use case. Best regards, Bill From nobody Thu Apr 13 07:47:20 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6CD129481; Thu, 13 Apr 2017 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucrBtVSv0t8N; Thu, 13 Apr 2017 07:47:05 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56624129409; Thu, 13 Apr 2017 07:47:04 -0700 (PDT) X-AuditID: c1b4fb30-abffb70000006667-8c-58ef8f65d397 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 66.C0.26215.56F8FE85; Thu, 13 Apr 2017 16:47:02 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.253]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Thu, 13 Apr 2017 16:47:00 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: Mark Nottingham CC: weigengyu , Carsten Bormann , "art@ietf.org" , "draft-ietf-core-coap-tcp-tls.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsa/qwMrkOzw42UWHLUrHT1G7O6G+Oc0AgAD5ZwCAAbONAIAAASMAgAJc0QA= Date: Thu, 13 Apr 2017 14:47:00 +0000 Message-ID: <180A6A3D-2242-4D71-AAC7-4180284398E4@ericsson.com> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <52AFE50B189544AFB2744028519A173D@WeiGengyuPC> <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> In-Reply-To: <7D33923C-AB67-43F1-9417-08574DCC62A3@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_180A6A3D22424D71AAC74180284398E4ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM2K7rm5a//sIgxWL5SxW3PWwODLlLqvF vrfrmS32vXnHYvFs43wWi/WfHjNaTJn5id2B3aPx1F42jyVLfjJ5bFz8ndVj2qLMAJYoLpuU 1JzMstQifbsErowNq46wFbyWqFjxOL6BsUmii5GTQ0LARGLj2U+sXYxcHEIC6xklfl79ygbh LGGU6Gn9xQRSxSbgLPHpWSM7iC0ioCzxff4SFpAiZoFWJomWrdPBEsICARJL224ANXAAFQVK bDmkD1HvJ7Hk6TRmEJtFQFVi0Zw2sHJeAXuJyc/mQ21uZ5KY+X4P2DJOARuJWy+eMILYjAJi Et9PrQGLMwuIS9x6Mp8J4mwBiSV7zjND2KISLx//Y4WwlSQalzxhhahPlvh+9TUjxDJBiZMz n7BMYBSZhWTULCRls5CUzQJ6gVlAU2L9Ln2IEkWJKd0P2SFsDYnWOXOhbGuJpkWnWJDVLGDk WMUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGLEHt/w22MH48rnjIUYBDkYlHt6ElvcRQqyJ ZcWVuYcYJTiYlUR4p7UBhXhTEiurUovy44tKc1KLDzFKc7AoifM67rsQISSQnliSmp2aWpBa BJNl4uCUamDUMZ5vWszzU/z/sdVyZfF3FpboXLkjE+A982v6Mv8NO0smbN+z59RC3z///z7d l1Y2e2f2kvPtfzt6chZIbaxT1awLK2V7IPdm0fKnh2wmZk5+k1H/+X30lfLyiOP1RywtDtyd +1DveJbAOvOqSymnNxy871L/WzpNu+zvN3HJ7x2R3krOSka/lFiKMxINtZiLihMBtD8nhNQC AAA= Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 14:47:06 -0000 --_000_180A6A3D22424D71AAC74180284398E4ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCmNvdWxkIHlvdSBzaGFyZSBkYXRhIHNvdXJjZSBvbiB0aGF0IHBscz8gSXTigJlkIGNv bWUgaW4gaGFuZHkuDQoNCkNpYW8hDQotIC0gSmFpbWUgSmltw6luZXoNCg0KT24gMTIgQXByIDIw MTcsIGF0IDUuNDIsIE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBt bm90Lm5ldD4+IHdyb3RlOg0KDQooZS5nLC4gOTAlKyBzdWNjZXNzIHJhdGVzIGZvciBVRFAgcHJv dG9jb2xzKS4NCg0K --_000_180A6A3D22424D71AAC74180284398E4ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4FBEA9501C975747B32AB3369FEF09FA@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5jb3VsZCB5b3Ugc2hhcmUgZGF0YSBz b3VyY2Ugb24gdGhhdCBwbHM/IEl04oCZZCBjb21lIGluIGhhbmR5LjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2lhbyE8YnIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCi0gLSBKYWltZSBKaW3DqW5lejwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTIgQXByIDIwMTcsIGF0IDUuNDIsIE1hcmsg Tm90dGluZ2hhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1ub3RAbW5vdC5uZXQiIGNsYXNzPSIiPm1u b3RAbW5vdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj aGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj4oZS5nLC4NCiA5MCUmIzQzOyBzdWNjZXNzIHJhdGVzIGZvciBVRFAg cHJvdG9jb2xzKS48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_180A6A3D22424D71AAC74180284398E4ericssoncom_-- From nobody Mon Apr 17 14:33:13 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F372E129480 for ; Mon, 17 Apr 2017 14:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUfDoTSY-7MF for ; Mon, 17 Apr 2017 14:33:11 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493D41242F7 for ; Mon, 17 Apr 2017 14:33:11 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HLWvqA023040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 14:32:57 -0700 (PDT) To: art@ietf.org References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> From: Joe Touch Message-ID: <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> Date: Mon, 17 Apr 2017 14:32:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3HLWvqA023040 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:33:13 -0000 Hi, all, I've completed an update that rolls in the changes below as well as a few other issues raised off-list. Joe A new version of I-D, draft-touch-time-02.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-time Revision: 02 Title: Resolving Multiple Time Scales in the Internet Document date: 2017-04-17 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-touch-time-02.txt Status: https://datatracker.ietf.org/doc/draft-touch-time/ Htmlized: https://tools.ietf.org/html/draft-touch-time-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-time-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-time-02 Abstract: Internet systems use a variety of time scales, which can complicate time comparisons and calculations. This document explains these various ways of indicating time and explains how they can be used together safely. This document is intended as a companion to Internet time as discussed in RFC 3339. On 3/29/2017 9:43 AM, Joe Touch wrote: > Hi, all, > > So I have a set of things to update so far. Please let me know if I > missed something. I will have an update out by the end of this week. > > I'm hoping this update can help us converge... > > Joe > --------- > > - clarify TAI as a post-facto average > - clarify prev definition of astronomical second as instantaneous: > > 1/31556925.9747 of the tropical year as of the instant > 1900 January 0 at 12:00:00 Ephemeris Time. > > - clarify UT1 as a a measure of the orientation angle of the earth upon > which international agreement bases the notion of calendar days. > - consider cleaning up the UT definitions, noting mostly that UT1 is the > only one in use (and not getting into the detail of UT0 and UT2) > - clean up the POSIX definition (it's not solar; more like a local clock) > - this is all at mean sea level (we're ignoring relativistic effects) > - reminder that the POSIX "equation" is approximate > - a light discussion about implementation issues (e.g., struct timeval > vs struct tm vs. ISO 8601) > - fix NTP epoch to 1900-01-01 > - clarify the two solar times as "apparent" vs "mean" > - reminder that timers either end on a date or specify an interval > - reminder that future times in UTC are indeterminate > - UTC is known only into some future (e.g., a few months) that you know > about scheduled leaps > - earth rotation, not orbit, causes most of solar time variation > > One other thing that came up is the difference between "POSIX time" > (previously called Unix time) and the POSIX time API. The API can access > a variety of time scales, including UTC (e.g., when NTP is running), an > emulation of UTC, an emulation of Unix time, or direct access to a > monotonic counter (which may or may not be reset on reboot). I think > this is Nico's issue with data types, and it's worth clarifying. > > ----- From nobody Tue Apr 18 05:47:40 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45B312EB88; Tue, 18 Apr 2017 05:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkQQnjBunmpA; Tue, 18 Apr 2017 05:47:29 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FDF12420B; Tue, 18 Apr 2017 05:47:29 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id c45so123688668qtb.1; Tue, 18 Apr 2017 05:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lsAj+8l6lI8C4/5VmvmY1YQ0PuxbxkFimPzx4OG+Ucg=; b=kVFBzdI8Y3UxFPQ4GjXLSxNulNR1YSu2SfzzFqQNUhqE6gA1vAjRd5o01rOHd0nkr2 13M6SH4iucDzFh3qSIDYffOIOM/e5km9lAiltLu4uz3ijwfT9z0MIct5SWEwYGl0bHr4 bu5O4HSpP8I1o56sjGLjt22+UPd5tBIE6T4iXDk7pgW6vRuDQUhzkiOU+MXENw7edYS9 dR5OmkiWAdRnEIl58XcnOQPo9cXegxGL5+9Jx68df/DTjTurJDZMimh4jEbR6vz6sDbC 16qiXV0BcAr9HPSBztgmj9RRpYxtnw+3wyckMM4PKkzDfIgHuVF4V/wFuJYMk58NevpH +org== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lsAj+8l6lI8C4/5VmvmY1YQ0PuxbxkFimPzx4OG+Ucg=; b=KoyG2fW14GBjX661JMEBcreXt1stXg6fDfqnpouh+zj87evLXqdPeerOAjTVafXkHW +jn8ing+XbMO3mYSQ3C0e91YfsQYlAYvg+kw8lL90IFNbgtb3XG5sb75EhcHsR+aq5vy Q3w9jEAEafYIeDot1BAOqxAgNMzwbg8ReC9rSQpBR/8cW3ttcADMIFW/BRNrMMHpqXYW 0bX1rJKu0pZclpU7Ydbk3jhBiK8aXy1MAGjCX/9F3v2SzGnQXYb0Lk/zXL/1Q4jqOzsz Wu/rmT0va25mNOVydGNyGW0EIDA7HwpgBnVfzduDJGsW5KZ3AbSE2Bc3CMR7rQjgVMpk uJwQ== X-Gm-Message-State: AN3rC/40XV7Wzb/BZU4TZ/6sGhyJfb0y61pZHSDWiVUTYHgpgeq/1Vzo 6ck9kpbqab704nMg6Qhy6A9yJg7AGg== X-Received: by 10.200.36.240 with SMTP id t45mr12970125qtt.230.1492519648189; Tue, 18 Apr 2017 05:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.45.162 with HTTP; Tue, 18 Apr 2017 05:47:27 -0700 (PDT) In-Reply-To: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> From: Herbert Van de Sompel Date: Tue, 18 Apr 2017 14:47:27 +0200 Message-ID: To: Carsten Bormann Cc: Mark Nottingham , art@ietf.org, ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org, Herbert Van de Sompel Content-Type: multipart/alternative; boundary=001a1140eede73628d054d704f68 Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 12:47:32 -0000 --001a1140eede73628d054d704f68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi Mark, Carsten, Sorry to be a bit late to the game. Two things: 1. I would be very interested in documents serialized according to application/link-format+json as described in the I-D, especially in the context of an I-D Erik Wilde and I are authoring regarding Link Sets, see https://datatracker.ietf.org/doc/draft-wilde-linkset-link-rel/ 2. Regarding Mark's comment "This means that any constraints upon RFC6690 documents are also mirrored into these formats": Mark mentions IRIs as a concern. I am also concerned about the rules for interpretation of (the Context IRI of) links as described in Section 2.1 of 6690 ( https://tools.ietf.org/html/rfc6690#section-2.1). It seems to me that these also introduce constraints that go beyond 5988. I may be mistaken with that regard because I have never fully understood that section of 6690 (i.e. the use of "base URI", "origin", "Context URI"). But, when compared to 5988, the section comes across as imposing constraints that are intended to allow the straightforward use of relative URIs in constrained environments as a means to decrease the payload. If my interpretation is correct, then I would very much favor spec-ing the json link format in terms of 5988 rather than 6690. Cheers Herbert Van de Sompel On Tue, Apr 11, 2017 at 9:33 AM, Carsten Bormann wrote: > Hi Mark, > > thank you a lot for another thoughtful review. > > I don=E2=80=99t have an opinion yet on what we should do here, so I=E2=80= =99ll supply some > more background first. > > The present spec is first and foremost intended to round-trip with RFC > 6690, which is indeed stuck a bit on HTTP Link header field syntax. > However, the way this is used in practice is not meant to inherit the > complexities of HTTP header field coding. E.g., for CoRE Resource > Directory and its DNS-SD compatibility, we want to represent a DNS-SD > instance identifier (which is UTF-8) as a link attribute. This is not a > problem in JSON or CBOR, but also not in the way RFC 6690 is being used, > i.e. as a UTF-8 based format. > > I haven=E2=80=99t checked yet what 5988bis brings to the table and how to= track > this in 6690 or possibly a 6690bis. There is no point in Big Web and Thi= ng > Web diverging here, so we should follow the lead. But maybe that would > touch both 6690 and the present document once 5988bis is done. > > More importantly, we haven=E2=80=99t really put a lot of thinking into IR= I > support. The CoAP data type =E2=80=9Cstring=E2=80=9D which is used for U= RI components such > as Uri-Path is UTF-8, so we could embrace them by extending the rules in > section 6 of RFC 7252 to cover IRIs. I=E2=80=99m sure that, in practice,= CoAP > implementations already do this =E2=80=94 it is not distinguishable in th= e CoAP > packet whether the (decomposed) CoAP Uri components have been derived fro= m > URIs or IRIs. But the metadata formats (6690 and its JSON/CBOR > representations; various other JSON and CBOR based formats, e.g. from OCF= ) > are still based on RFC 3986 URIs, except where they also use the CoAP > decomposed form (e.g., CORAL). > > While this is outside the scope of the CoRE WG, I personally would like t= o > explore how link-format+cbor/+json could be useful for the Big Web. If > embracing IRIs there is all we need to make this happen, maybe that can b= e > added with a warning that IRIs have to be converted back to URIs for 6690 > link-format. > > Gr=C3=BC=C3=9Fe, Carsten > > > > On Apr 11, 2017, at 05:49, Mark Nottingham wrote: > > > > Reviewer: Mark Nottingham > > Review result: Ready with Issues > > > > This specification is a relatively straightforward mapping of the > > format described in RFC6690 (itself a serialisation of RFC5988bis > > links) into JSON and CBOR. I don't have deep knowledge of CBOR, but > > given the editorship of the document, I trust it's seen adequate > > review in that regard. > > > > The only potential issue is how this is achieved. Rather than defining > > two new serialisations of RFC5988bis links (into JSON and CBOR), it > > describes how to re-serialise RFC6690 documents into JSON and CBOR. > > This means that any constraints upon RFC6690 documents are also > > mirrored into these formats; e.g., the target IRI is constrained to be > > a URI in 6690, and therefore can also only be a URI in JSON and CBOR, > > despite these formats' ability to easily convey non-ASCII content. > > > > In other words, the specification currently defines these link formats > > in terms of the Link header (as defined in section 5 of RFC5988) -- > > along with all of the foibles of HTTP header syntax -- rather than > > their abstract model (defined in Section 3). > > > > Whether or not this is a problem depends on what's desired; if 6690 is > > seen as effectively a profile of 5988, then it makes sense to express > > it in those terms. If the full range of links capable of being > > expressed in 5988 is desired, creating new serialisations of 5988 > > links (without a hop through 6690) is preferable. > > > > If the current approach is kept, it'd be nice to clarify this > > situation a bit in the Introduction. > > > > > > _______________________________________________ > > art mailing list > > art@ietf.org > > https://www.ietf.org/mailman/listinfo/art > > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --=20 Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ http://orcid.org/0000-0002-0715-6126 =3D=3D --001a1140eede73628d054d704f68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
hi Mark, Carsten,

Sorry to be a bit lat= e to the game.

Two things:

1. I would be very interested in documents serialized according to applic= ation/link-format+json as described in the I-D, especially in the context o= f an I-D Erik Wilde and I are authoring regarding Link Sets, see https://da= tatracker.ietf.org/doc/draft-wilde-linkset-link-rel/

2. Regarding Mark's comment "This means that any constraints upon RFC6690 documents are alsomirrored into these formats": Mar= k mentions IRIs as a concern. I am also concerned about the rules for inter= pretation of (the Context IRI of) links as described in Section 2.1 of 6690= (https://tools= .ietf.org/html/rfc6690#section-2.1). It seems to me that these also int= roduce constraints that go beyond 5988. I may be mistaken with that regard = because I have never fully understood that section of 6690 (i.e. the use of= "base URI", "origin", "Context URI"). But, w= hen compared to 5988, the section comes across as imposing constraints that= are intended to allow the straightforward use of relative URIs in constrai= ned environments=C2=A0as a means to decrease the payload. If my interpretat= ion is correct, then I would very much favor spec-ing the json link format = in terms of 5988 rather than 6690.

Cheers

Herbert Van de Sompel

=C2= =A0

On Tue, Apr 11, 2017 at 9:33 AM, Carsten Bormann <= ;cabo@tzi.org> wrote:
Hi Mark,

thank you a lot for another thoughtful review.

I don=E2=80=99t have an opinion yet on what we should do here, so I=E2=80= =99ll supply some more background first.

The present spec is first and foremost intended to round-trip with RFC 6690= , which is indeed stuck a bit on HTTP Link header field syntax.=C2=A0 Howev= er, the way this is used in practice is not meant to inherit the complexiti= es of HTTP header field coding.=C2=A0 E.g., for CoRE Resource Directory and= its DNS-SD compatibility, we want to represent a DNS-SD instance identifie= r (which is UTF-8) as a link attribute.=C2=A0 This is not a problem in JSON= or CBOR, but also not in the way RFC 6690 is being used, i.e. as a UTF-8 b= ased format.

I haven=E2=80=99t checked yet what 5988bis brings to the table and how to t= rack this in 6690 or possibly a 6690bis.=C2=A0 There is no point in Big Web= and Thing Web diverging here, so we should follow the lead.=C2=A0 But mayb= e that would touch both 6690 and the present document once 5988bis is done.=

More importantly, we haven=E2=80=99t really put a lot of thinking into IRI = support.=C2=A0 The CoAP data type =E2=80=9Cstring=E2=80=9D which is used fo= r URI components such as Uri-Path is UTF-8, so we could embrace them by ext= ending the rules in section 6 of RFC 7252 to cover IRIs.=C2=A0 I=E2=80=99m = sure that, in practice, CoAP implementations already do this =E2=80=94 it i= s not distinguishable in the CoAP packet whether the (decomposed) CoAP Uri = components have been derived from URIs or IRIs.=C2=A0 But the metadata form= ats (6690 and its JSON/CBOR representations; various other JSON and CBOR ba= sed formats, e.g. from OCF) are still based on RFC 3986 URIs, except where = they also use the CoAP decomposed form (e.g., CORAL).

While this is outside the scope of the CoRE WG, I personally would like to = explore how link-format+cbor/+json could be useful for the Big Web.=C2=A0 I= f embracing IRIs there is all we need to make this happen, maybe that can b= e added with a warning that IRIs have to be converted back to URIs for 6690= link-format.

Gr=C3=BC=C3=9Fe, Carsten


> On Apr 11, 2017, at 05:49, Mark Nottingham <mnot@mnot.net> wrote:
>
> Reviewer: Mark Nottingham
> Review result: Ready with Issues
>
> This specification is a relatively straightforward mapping of the
> format described in RFC6690 (itself a serialisation of RFC5988bis
> links) into JSON and CBOR. I don't have deep knowledge of CBOR, bu= t
> given the editorship of the document, I trust it's seen adequate > review in that regard.
>
> The only potential issue is how this is achieved. Rather than defining=
> two new serialisations of RFC5988bis links (into JSON and CBOR), it > describes how to re-serialise RFC6690 documents into JSON and CBOR. > This means that any constraints upon RFC6690 documents are also
> mirrored into these formats; e.g., the target IRI is constrained to be=
> a URI in 6690, and therefore can also only be a URI in JSON and CBOR,<= br> > despite these formats' ability to easily convey non-ASCII content.=
>
> In other words, the specification currently defines these link formats=
> in terms of the Link header (as defined in section 5 of RFC5988) -- > along with all of the foibles of HTTP header syntax -- rather than
> their abstract model (defined in Section 3).
>
> Whether or not this is a problem depends on what's desired; if 669= 0 is
> seen as effectively a profile of 5988, then it makes sense to express<= br> > it in those terms. If the full range of links capable of being
> expressed in 5988 is desired, creating new serialisations of 5988
> links (without a hop through 6690) is preferable.
>
> If the current approach is kept, it'd be nice to clarify this
> situation a bit in the Introduction.
>
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>

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



--
=
Herbert V= an de Sompel
Digital Library Research & Prototyping
Los Alamos Na= tional Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.or= g/0000-0002-0715-6126

=3D=3D
--001a1140eede73628d054d704f68-- From nobody Tue Apr 18 07:47:14 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6849A12EBE4 for ; Tue, 18 Apr 2017 07:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqaU3awGa2B8 for ; Tue, 18 Apr 2017 07:47:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 8451E1273E2 for ; Tue, 18 Apr 2017 07:47:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1d0UPH-0000DqC; Tue, 18 Apr 2017 16:47:03 +0200 Message-Id: To: art@ietf.org Cc: Joe Touch From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> In-reply-to: Your message of "Mon, 17 Apr 2017 14:32:57 -0700 ." <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> Date: Tue, 18 Apr 2017 16:47:02 +0200 Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 14:47:12 -0000 In your letter dated Mon, 17 Apr 2017 14:32:57 -0700 you wrote: >A new version of I-D, draft-touch-time-02.txt I wonder if I should read this. In the terminology section Solar day is now defined as two different things. But worse, the term 'solar day' is used unqualified throughout the document. The '25ns' sillyness of GPS with respect to TAI is still there. I now have an idea where the 100ms for NTP is coming from. That's really sad. With this kind of silly stuff still in there it is not worth trying to make sense of the document. From nobody Tue Apr 18 08:04:14 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7695128D40 for ; Tue, 18 Apr 2017 08:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxR40i42mN0Y for ; Tue, 18 Apr 2017 08:04:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED1412EC59 for ; Tue, 18 Apr 2017 08:04:10 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3IF3dK6017545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 08:03:49 -0700 (PDT) To: Philip Homburg , art@ietf.org References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> From: Joe Touch Message-ID: <0751aeaa-56ae-e953-3b76-308a6a3478b4@isi.edu> Date: Tue, 18 Apr 2017 08:03:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:04:13 -0000 Hi, Philip, On 4/18/2017 7:47 AM, Philip Homburg wrote: > In your letter dated Mon, 17 Apr 2017 14:32:57 -0700 you wrote: >> A new version of I-D, draft-touch-time-02.txt > I wonder if I should read this. Probably it would be useful before commenting. It's at least IETF custom. > In the terminology section Solar day is now > defined as two different things. But worse, the term 'solar day' is used > unqualified throughout the document. I will check and fix that. > The '25ns' sillyness of GPS with respect to TAI is still there. I now have > an idea where the 100ms for NTP is coming from. That's really sad. can you clarify? The 25ns of GPS is the result of a claim in the GPS spec. The 100ms is from a claim in NTP documentation. If you'd like to provide further feedback based on the contents, I'd be glad to consider them. Joe From nobody Tue Apr 18 08:29:20 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7591412EC55 for ; Tue, 18 Apr 2017 08:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiNHQVwapKZu for ; Tue, 18 Apr 2017 08:29:17 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8903812EC23 for ; Tue, 18 Apr 2017 08:29:17 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-06v.sys.comcast.net with SMTP id 0V20d33jAl4eq0V48dxbwU; Tue, 18 Apr 2017 15:29:16 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with SMTP id 0V46dzATdY10N0V48dYu7P; Tue, 18 Apr 2017 15:29:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v3IFTDRc015637; Tue, 18 Apr 2017 11:29:13 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v3IFTDpn015634; Tue, 18 Apr 2017 11:29:13 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Joe Touch Cc: art@ietf.org In-Reply-To: <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> (touch@isi.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 18 Apr 2017 11:29:12 -0400 Message-ID: <87vaq1u43b.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCsnIF+yzuhmEAPhJ4pvmvCn3uWGi/61Y+jelLBTEPtz7WhJG4SgnfyxbISrrcG9PXWVLsVviRuxh/FQ85ZOEA2P6cQ0/JUR7tSPTJkSQRmOGe93K3bO P8JjIpjBK0iysnAG1BSJzmiSn20EFC+or7zNUkV4NTq/FE5S0774ujvqH9wlCUSiPGfqcaE3quq+IA== Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:29:18 -0000 Joe Touch writes: > I've completed an update that rolls in the changes below as well as a > few other issues raised off-list. I can see this as being valuable, but it seems to me that the writing needs to be clarified and made more exact in many places. A typical example is that "civil time" appears in the Introduction and other places, but it isn't listed in either "Terminology" or "Time scales". But since the whole point of the draft is making the use of time clearer and more exact, this is a critical matter. Dale From nobody Tue Apr 18 08:55:18 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAE129439 for ; Tue, 18 Apr 2017 08:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGwKCrZ5uaJ0 for ; Tue, 18 Apr 2017 08:55:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E453120727 for ; Tue, 18 Apr 2017 08:55:16 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3IFsRnE002518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 08:54:37 -0700 (PDT) To: "Dale R. Worley" References: <87vaq1u43b.fsf@hobgoblin.ariadne.com> Cc: art@ietf.org From: Joe Touch Message-ID: <71586348-3643-7750-dcf3-5c701e61629b@isi.edu> Date: Tue, 18 Apr 2017 08:54:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87vaq1u43b.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:55:17 -0000 Hi, Dale, Thanks for the catch. I'll fix that in the next update. It's a complex document so I would not be surprised if my first attempt to organize the information had bugs. I'm glad to fix them if you have other suggestions. Joe On 4/18/2017 8:29 AM, Dale R. Worley wrote: > Joe Touch writes: >> I've completed an update that rolls in the changes below as well as a >> few other issues raised off-list. > I can see this as being valuable, but it seems to me that the writing > needs to be clarified and made more exact in many places. A typical > example is that "civil time" appears in the Introduction and other > places, but it isn't listed in either "Terminology" or "Time scales". > But since the whole point of the draft is making the use of time clearer > and more exact, this is a critical matter. > > Dale From nobody Tue Apr 18 11:14:23 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB56212EC63 for ; Tue, 18 Apr 2017 11:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zJAgRuZyzXK for ; Tue, 18 Apr 2017 11:14:17 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05ADF12EBC6 for ; Tue, 18 Apr 2017 11:14:16 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-08v.sys.comcast.net with SMTP id 0Xdkdj3L2AfZs0XdodPrPs; Tue, 18 Apr 2017 18:14:16 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with SMTP id 0Xdmdm0QAngy30XdndRL2R; Tue, 18 Apr 2017 18:14:15 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v3IIEEoC026683; Tue, 18 Apr 2017 14:14:14 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v3IIEDQR026680; Tue, 18 Apr 2017 14:14:13 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Joe Touch Cc: art@ietf.org In-Reply-To: <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> (touch@isi.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 18 Apr 2017 14:14:13 -0400 Message-ID: <87bmrttwga.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHv92V4OyjrpO7/svSpnEdRHvnnYTP9kjQZPaKD8rJbmUrLFrNaIMfBTkooyEJnT/u4bpQvxfk2YBsnBnccGu+nP3RsMIHhPUKPR9OZLsh/aydZj3NSi LNppHfGK0qnSL02rRJB5FeIy085NlYcNrUVEFvBFFGoFK3TUmSHTJNYZS+/yCx975DI0kf/xbsRwJQ== Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:14:18 -0000 (BTW, "draft-time-touch" in the subject line is incorrect! I made it hard for me to find your message again.) I was thinking again... What is the purpose of this draft? It seems to me (having only skimmed it) that the essence is the seven recommendations given at the end of the Introduction. But a lot of the text is taken up with assessing various existing time scales in details which aren't directly relevant to the recommendations. If you pared down the draft to what is needed to support the recommendations (and possibly the task of assisting the designer to choose a good primary time scale for an application), how much complexity would be avoided? Dale From nobody Tue Apr 18 11:26:18 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED64712896F for ; Tue, 18 Apr 2017 11:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv712nt4jY2G for ; Tue, 18 Apr 2017 11:26:14 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55341129329 for ; Tue, 18 Apr 2017 11:26:10 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3IIPg9U002404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 11:25:42 -0700 (PDT) To: "Dale R. Worley" References: <87bmrttwga.fsf@hobgoblin.ariadne.com> Cc: art@ietf.org From: Joe Touch Message-ID: Date: Tue, 18 Apr 2017 11:25:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87bmrttwga.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3IIPg9U002404 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:26:16 -0000 On 4/18/2017 11:14 AM, Dale R. Worley wrote: > (BTW, "draft-time-touch" in the subject line is incorrect! I made it > hard for me to find your message again.) Sorry - not enough coffee... The next version will be draft-touch-art-time, keeping with the convention that also includes the intended WG of interest... > I was thinking again... What is the purpose of this draft? I tried to indicate that in the abstract/intro. It originated in response to two different threads on "hey, the IETF should standardize some new time scale" - one to be purely monotonic and the other to standardize Google-like leapsecond smear. The point of the doc is to encourage people to use existing solutions and not believe there's a shortcut that gets around needing to know/deal with leap seconds, time zones, and coordination. > It seems to > me (having only skimmed it) that the essence is the seven > recommendations given at the end of the Introduction. But a lot of the > text is taken up with assessing various existing time scales in details > which aren't directly relevant to the recommendations. Yeah - that's intended to be background. > If you pared > down the draft to what is needed to support the recommendations (and > possibly the task of assisting the designer to choose a good primary > time scale for an application), how much complexity would be avoided? I'm open to suggestions on how far back to pull that background. The reason for including it is to have the doc be somewhat self-contained in justifying the recommendations. Joe From nobody Tue Apr 18 15:01:57 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16EB124282 for ; Tue, 18 Apr 2017 15:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjHaCXf_04Ka for ; Tue, 18 Apr 2017 15:01:53 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0051.outbound.protection.outlook.com [104.47.38.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4933129485 for ; Tue, 18 Apr 2017 15:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=em2Ed573j9WpwvIrh8kR/CqaaeHIZPK2AyJhAiHJOQA=; b=tZppB98QnkS7C/tjm9be4PWoq1BeiOgDop+wMJpsqo11hpI1NJbeT1C0nSsA5pwJltwNSxEHFf3LVaxEW/HnXd2VuFaSXt7sUBvLPq3uam+1taXdlHt4UvZ4YvvHz0e05522t1VQ93pPCuRhdft/Vtu4N8Hukt+usnfwq4n9umg= Received: from DM5PR02MB2329.namprd02.prod.outlook.com (10.168.174.141) by DM5PR02MB2332.namprd02.prod.outlook.com (10.168.174.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Tue, 18 Apr 2017 22:01:50 +0000 Received: from DM5PR02MB2329.namprd02.prod.outlook.com ([10.168.174.141]) by DM5PR02MB2329.namprd02.prod.outlook.com ([10.168.174.141]) with mapi id 15.01.1034.015; Tue, 18 Apr 2017 22:01:49 +0000 From: Michael Thornburgh To: Joe Touch , "art@ietf.org" Thread-Topic: [art] summary of updates - draft-time-touch Thread-Index: AQHSqKuvI5heQzzEHkmZx16gfGn8JKHKMwSAgAGAXNU= Date: Tue, 18 Apr 2017 22:01:49 +0000 Message-ID: References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu>, <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> In-Reply-To: <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isi.edu; dkim=none (message not signed) header.d=none;isi.edu; dmarc=none action=none header.from=adobe.com; x-originating-ip: [25.168.111.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR02MB2332; 7:Kk5MVnitybFqh8jpPBGSyJL10omnSckcapVdP64JrIIKGf0yeNmuEnvzWhoV0Y4mG4olX59Wec8wRg2DNXPwbkW+bQWUzVcLkqSb7GYDOW21Ga2X3ojnrJjMNwUkzg+yat8KGJ7kW6UbdP7IOZPKGVsUWl8KiEgQP3Y/2Yga3ZYPYmTMIo2+Hz0p+OY/UG5aTcZbXkSrYMJy6HUBWEFP/xU7UGE2XfeRaGxa64AfiVjhYoj6eZ/rpzS16PsrE1IAQKsU7GBTG/T1QTBPvWCsoDH2Oz9GcVCudvxJaoS/6UsJUsslQ6+hypaN2rZaky9R/VYILVUhMga0OaJK5gdl1w==; 20:FM/o/E+RN4TD9CCOfC+7LrKxoot5AaGXLiPlB5X3Nbl+2IIPnJDxThJ4fivFBdZN+TsJpeWEtw4EGOIUyb/H+rZCQmYbRMAjZBkEOtt1Y7LcAO+uyFWedZVNmidt673Vjso0UWogSkKvnG7GysAwVT1GS5Lj/Ydmo4ByHSdAJPY= x-ms-office365-filtering-correlation-id: b7b1153b-7862-4d5e-dc14-08d486a683c7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM5PR02MB2332; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:DM5PR02MB2332; BCL:0; PCL:0; RULEID:; SRVR:DM5PR02MB2332; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(39860400002)(377424004)(377454003)(74316002)(305945005)(7736002)(2900100001)(2906002)(3280700002)(15650500001)(7696004)(10090500001)(6116002)(2950100002)(25786009)(50986999)(53546009)(8936002)(81166006)(102836003)(3660700001)(8676002)(3846002)(54356999)(76176999)(66066001)(2501003)(99286003)(9686003)(86362001)(38730400002)(229853002)(6246003)(33656002)(77096006)(53936002)(6506006)(6436002)(2171002)(55016002)(93886004)(5660300001)(189998001)(122556002)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR02MB2332; H:DM5PR02MB2329.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2017 22:01:49.5055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2332 Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 22:01:56 -0000 Joe, all. i have several problems with this draft. as others have mentioned, i think= it's too long and complicated. also, i feel that several of the definitio= ns in section 3 Terminology are inaccurate or imprecise. below are my proposals for some of the Terms: o Instant: a point in time. o Time scale: the assignment of names to points in time. o Date: the name of an instant in a time scale. alternatively: the name o= f a day in a calendar. o Unit of time: this is unnecessary o Epoch: a point in time that is the anchor/origin/beginning of a time sca= le. o Clock: an apparatus that measures (and typically reports) the passage of= time. a clock may report the time according to a time scale. o Solar day: TL;DR. please make more concise. "mean solar day" would be = useful to UT1 and therefore UTC. o Tropical year: TL;DR. is this necessary if you have "mean solar day"? o Second: the basic unit of time, having multiple different definitions: * 1/86400 of a day / mean solar day. * SI second: 9192631770 periods of the radiation corresponding to the hy= perfine transition of the ground state of cesium 133 at 0K. (note that sea= level is NOT part of the definition of the SI second) o Leap second: an extra second irregularly inserted into or removed from t= he Coordinated Universal Time time scale to keep it within 0.9 seconds of U= T1. o Leap day: this is unnecessary. section 4.2 Time scales:=20 o TAI (International Atomic Time): an ensemble coordinate time scale based= on the SI second at mean sea level ("on the geoid"), determined after-the-= fact by the weighted contributions of numerous atomic clocks in laboratorie= s around the world, adjusted to account for gravitational time dilation cau= sed by the altitude of each clock (among other gravitational effects). TAI= may appear to tick faster or slower than the SI second depending on the lo= cation (especially altitude) of the observer; therefore, free-running atomi= c clocks may diverge from TAI. only approximations of TAI are available in= real-time. i think it's important to make the above points about TAI because it illust= rates why having an atomic clock on your desk or in your computer isn't goo= d enough. o UTC (Coordinated Universal Time): an approximation of UT1 based on TAI *= adjusted* with leap seconds. later, in section 5, there is the implication that UTC is discontinuous. U= TC is continuous and ticks at the same rate as TAI. leap seconds are not d= iscontinuities. the counting is non-uniform in that occasionally and irreg= ularly there are minutes that don't have the *usual* number of seconds in t= hem. POSIX time has discontinuities because it is fundamentally flawed. there are other problems with the document, but i think dealing with them w= ill be easier once the issues above are addressed. -mike ________________________________________ From: art [art-bounces@ietf.org] on behalf of Joe Touch [touch@isi.edu] Sent: Monday, April 17, 2017 2:32 PM To: art@ietf.org Subject: Re: [art] summary of updates - draft-time-touch Hi, all, I've completed an update that rolls in the changes below as well as a few other issues raised off-list. Joe A new version of I-D, draft-touch-time-02.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-time Revision: 02 Title: Resolving Multiple Time Scales in the Internet Document date: 2017-04-17 Group: Individual Submission Pages: 17 URL: [mangled URL removed] Status: [mangled URL removed] Htmlized: [mangled URL removed] Htmlized: [mangled URL removed] Diff: [mangled URL removed] Abstract: Internet systems use a variety of time scales, which can complicate time comparisons and calculations. This document explains these various ways of indicating time and explains how they can be used together safely. This document is intended as a companion to Internet time as discussed in RFC 3339. From nobody Tue Apr 18 15:36:26 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7061314C5 for ; Tue, 18 Apr 2017 15:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOSqLqAyCSTq for ; Tue, 18 Apr 2017 15:36:15 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997A5126DFB for ; Tue, 18 Apr 2017 15:36:15 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3IMZoBd015725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 15:35:50 -0700 (PDT) To: Michael Thornburgh , "art@ietf.org" References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> From: Joe Touch Message-ID: <9603e464-3931-1c4d-a12c-1afac82d1a47@isi.edu> Date: Tue, 18 Apr 2017 15:35:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3IMZoBd015725 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 22:36:24 -0000 Hi, Michael,. Thanks for the detailed feedback. Can you clarify as per below? On 4/18/2017 3:01 PM, Michael Thornburgh wrote: > Joe, all. > > i have several problems with this draft. as others have mentioned, i think it's too long and complicated. also, i feel that several of the definitions in section 3 Terminology are inaccurate or imprecise. > > below are my proposals for some of the Terms: > > o Instant: a point in time. Why is point more precise or accurate than moment? > o Time scale: the assignment of names to points in time. A time scale is the set of all such assignments according to a single system, not just the act of making the assignment, e.g.: Time scale: a system for assigning names to instants and intervals. (the latter because time scales include names of intervals) > o Date: the name of an instant in a time scale. alternatively: the name of a day in a calendar. Those names are indicated as intervals from an epoch, so this can be combined as: Date: the name of an instant in a time scale, indicated as an interval from an epoch. I disagree with the alternate definition. "Monday" isn't a date. > o Unit of time: this is unnecessary OK. > o Epoch: a point in time that is the anchor/origin/beginning of a time scale. Again, we ought to use "instant" here... and "origin" seems the closest IMO: Epoch: an instant used as the origin of a time scale > o Clock: an apparatus that measures (and typically reports) the passage of time. a clock may report the time according to a time scale. I disagree. Clocks don't report time passage; timers do. Clocks report only the current value, and always in a time scale (what would a clock be if it didn't? it might be a timer, but not a clock). > o Solar day: TL;DR. please make more concise. "mean solar day" would be useful to UT1 and therefore UTC. I'm glad to hear suggestions. The trouble with this definition - and the entire list, and the entire doc - is that for everyone who thinks its too long, there's someone else who points out something to add. UT1 isn't specified in terms of any mean. > o Tropical year: TL;DR. is this necessary if you have "mean solar day"? Both are needed because both are used for different definitions of a second. > o Second: the basic unit of time, having multiple different definitions: > > * 1/86400 of a day / mean solar day. > > * SI second: 9192631770 periods of the radiation corresponding to the hyperfine transition of the ground state of cesium 133 at 0K. (note that sea level is NOT part of the definition of the SI second) Good point. It is TAI refers to sea level (you fix that later). > o Leap second: an extra second irregularly inserted into or removed from the Coordinated Universal Time time scale to keep it within 0.9 seconds of UT1. I was hesitant to claim that this term was exclusive to UTC, but if we agree, then OK. > o Leap day: this is unnecessary. Probably... > section 4.2 Time scales: > > o TAI (International Atomic Time): an ensemble coordinate time scale based on the SI second at mean sea level ("on the geoid"), determined after-the-fact by the weighted contributions of numerous atomic clocks in laboratories around the world, adjusted to account for gravitational time dilation caused by the altitude of each clock (among other gravitational effects). TAI may appear to tick faster or slower than the SI second depending on the location (especially altitude) of the observer; therefore, free-running atomic clocks may diverge from TAI. only approximations of TAI are available in real-time. > > i think it's important to make the above points about TAI because it illustrates why having an atomic clock on your desk or in your computer isn't good enough. OK.... > o UTC (Coordinated Universal Time): an approximation of UT1 based on TAI *adjusted* with leap seconds. > > later, in section 5, there is the implication that UTC is discontinuous. UTC is continuous and ticks at the same rate as TAI. leap seconds are not discontinuities. the counting is non-uniform in that occasionally and irregularly there are minutes that don't have the *usual* number of seconds in them. Good point. I'll fix that. > POSIX time has discontinuities because it is fundamentally flawed. I tried to clarify that POSIX is really two different things: - an API to a variety of time scales or approximations thereof (some flawed) - Unix time, the counting of (undefined seconds) in fixed numbers of seconds per day since a particular epoch > there are other problems with the document, but i think dealing with them will be easier once the issues above are addressed. OK - let me know what you think of the above and I'll work on a rev once we converge. --- From nobody Tue Apr 18 17:48:38 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467AF129416; Tue, 18 Apr 2017 17:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP7w0aeHxg73; Tue, 18 Apr 2017 17:48:20 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0118.outbound.protection.outlook.com [104.47.40.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E401250B8; Tue, 18 Apr 2017 17:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4B6KXpPBLm61WrTUxH+Ze62Fe+lw3X7Gf/vxddMmao0=; b=aHcF6szGa2jS3Lyzip3UYvE97jcxmmK+5zMScehsSmv0Lmq/SZNQ6YKEdChkc7zQ8D3qUceDwn8dUuQnh1TOcXd5C74xOWlbuiPCP7LYSZic4c6eg8ko593p8dMVeBEc4DcWYhjHxjgzuozctVtl1SilyoeUXcEimwHm6FzsXFM= Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0081.namprd21.prod.outlook.com (10.162.78.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Wed, 19 Apr 2017 00:48:18 +0000 Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1061.003; Wed, 19 Apr 2017 00:48:18 +0000 From: Brian Raymor To: Carsten Bormann , Mark Nottingham CC: "art@ietf.org" , "draft-ietf-core-coap-tcp-tls.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsa/ruYJAPgRh/k2Aqaxin65fHKG+W1UAgA2IyeA= Date: Wed, 19 Apr 2017 00:48:17 +0000 Message-ID: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> In-Reply-To: <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR21MB0081; 7:ET2ae8tLyud9HDCn+EOfPnA7KzUPQB31CkIKKmjVaSda6ksrE39XnDmSmLVaKO3WMBCHz/WvrxmDhClNuAuECYCK78HhfbT3AZMqUzTve0ai0FpsOtyPPnW87iRCoMbwqEFHNv6Ig82cJ7RGvkuwBjxiB9UrKo7Yq/6fINVX/xNn5RtUH2YUKDHJhENoyNFaRCtxrn8ZInMdWrGCoyMqViJc8l34NMSJNkbVJPot0ErHWiAtcAedlF4wze6caOH0gFRLcn/v9jrz3cvPTYSo4yGNpCauTSA7kiqUbi2opaKffIvg0z3Fl8hVwYrxaiH87WSssSEmj1/ULSxMcHGWHgVDkZKNAZYGolXBv/eIQ7I= x-ms-office365-filtering-correlation-id: 38543b9b-667b-4555-10dc-08d486bdc529 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR21MB0081; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406088)(20161123558035)(20161123560025)(6072148); SRVR:BY2PR21MB0081; BCL:0; PCL:0; RULEID:; SRVR:BY2PR21MB0081; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39860400002)(39400400002)(52314003)(24454002)(38730400002)(6506006)(54906002)(55016002)(4326008)(66066001)(99286003)(6436002)(9686003)(77096006)(74316002)(76176999)(3846002)(25786009)(6306002)(53936002)(6246003)(54356999)(8936002)(8676002)(102836003)(50986999)(2900100001)(6116002)(7696004)(81166006)(2950100002)(305945005)(7736002)(5660300001)(10290500002)(10090500001)(3660700001)(33656002)(5005710100001)(86612001)(2906002)(3280700002)(189998001)(86362001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0081; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 00:48:17.8034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0081 Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 00:48:22 -0000 VGhhbmtzIGZvciB5b3VyIHRob3VnaHRmdWwgZmVlZGJhY2ssIE1hcmsuDQoNCk1hcmsgd3JvdGU6 DQo+PiBTZWN0aW9uIDguMSBtYWtlcyBpdCBNYW5kYXRvcnkgdG8gSW1wbGVtZW50IHRoZSBwcm90 b2NvbCB3aXRob3V0IGFueSANCj4+IHNlY3VyaXR5ICgiTm9TZWMiKS4gVGhpcyBzZWVtcyBjb3Vu dGVyIHRvIGJlc3QgcHJhY3RpY2UgaW4gdGhlIElFVEYsIA0KPj4gYnV0IEknbGwgZGVmZXIgdG8g dGhlIFNlY3VyaXR5IEFyZWEgcmV2aWV3Lg0KDQpDYXJzdGVuIHJlc3BvbmRlZDoNCj4gU2luY2Ug aXQgaXMgdGhlIGltcGxlbWVudGVycyB3aG8gd2lsbCBkZWNpZGUgd2hldGhlciB0aGV5IGltcGxl bWVudCB0aGlzLCB0aGlzIGNvLWF1dGhvciBjb3VsZCBsaXZlIHdpdGggbWFraW5nIGltcGxlbWVu dGluZyBOb1NlYw0KPiBjb21wbGV0ZWx5IG9wdGlvbmFsLiAgKEl0IHdpbGwgYmUgYW55d2F5LCBp biBwcmFjdGljZSwgYXQgdGhlIGxldmVsIG9mIHdoYXQgaXMgYWN0dWFsbHkgY29uZmlndXJlZC4p ICBUaGUgaW1wb3J0YW50IHBvaW50KCopIGZyb20gdGhlIFdHDQo+IHBlcnNwZWN0aXZlIGhlcmUg aXMgdGhhdCBUTFMgaXMgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwgd2l0aCB0aGUgc3BlY2lmaWNz IGRlcGVuZGluZyBvbiB0aGUgc2VjdXJpdHkgbW9kZSBuZWVkZWQgKGNmLiBSRkMgNzkyNSkuIA0K PiAoTm90ZSBhbHNvIHRoYXQgdGhlcmUgYXJlIG90aGVyIHdheXMgdG8gcHJvdmlkZSBzZWN1cml0 eSB3aXRoIENvQVAuKQ0KDQo+ICgqKSBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRj cC10bHMvY29tbWl0L2ZlMzQ4ZjU0M2ZjNDVlOTgxZTM4ZTkzNTQyNDIwMTJhZmIyOGRjNjANCg0K U29tZSBjb250ZXh0IC0gZHVyaW5nIHRoZSBzZWN1cml0eSBkaXNjdXNzaW9ucyBpbiB0aGUgV0cs IHRoZXJlIHdhcyBhIHJlY29tbWVuZGF0aW9uIHRvICJtaXJyb3IiIHRoZSBzaW1pbGFyIHNlY3Rp b24gaW4gUkZDNzI1Mi4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjc2Vj dGlvbi05IHN0YXRlczoNCg0KICBUaGUgTm9TZWMgYW5kIFJhd1B1YmxpY0tleSBtb2RlcyBhcmUg bWFuZGF0b3J5IHRvIGltcGxlbWVudCBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQp3aGljaCBp cyB3aHkgTm9TZWMgaXMgTVRJLiANCg0KSSBhZ3JlZSB3aXRoIENhcnN0ZW4uIEknZCBiZSBoYXBw eSB0byBtYWtlIHRoaXMgY29tcGxldGVseSBvcHRpb25hbCBpZiBpdCByZXN1bHRzIGluIGxlc3Mg ZGlzc29uYW5jZSBmb3IgcmV2aWV3ZXJzIGFuZCB0aGVyZSBhcmUgbm8gb2JqZWN0aW9ucyBpbiB0 aGUgV0cuDQoNCg== From nobody Tue Apr 18 20:02:11 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A02A129417 for ; Tue, 18 Apr 2017 20:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3rLkOo4oj3i for ; Tue, 18 Apr 2017 20:02:09 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B411293F2 for ; Tue, 18 Apr 2017 20:02:08 -0700 (PDT) X-AuditID: 1209190f-667ff7000000164b-1b-58f6d32ff492 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 9B.E0.05707.F23D6F85; Tue, 18 Apr 2017 23:02:07 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v3J32639007797; Tue, 18 Apr 2017 23:02:07 -0400 Received: from localhost (contents-vnder-pressvre.mit.edu [18.9.64.11]) (authenticated bits=0) (User authenticated as jhawk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v3J3246d014105; Tue, 18 Apr 2017 23:02:05 -0400 Date: Tue, 18 Apr 2017 23:02:04 -0400 From: John Hawkinson To: Joe Touch Cc: art@ietf.org Message-ID: <20170419030204.GB87484@mit.edu> Mail-Followup-To: John Hawkinson , Joe Touch , art@ietf.org References: <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> <0751aeaa-56ae-e953-3b76-308a6a3478b4@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0751aeaa-56ae-e953-3b76-308a6a3478b4@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT0dW//C3CYEaLjsWKux4Wr6e0sFqs +zOXxYHZY8mSn0weu99vZfFY+LCHMYA5issmJTUnsyy1SN8ugStj7b1vTAWLuSrObepiaWCc wdHFyMkhIWAiMW33crYuRi4OIYE2Jom3hx8yQjgbGSVerH8J5fxhlDj9bDojSAuLgKrExh1f wWw2ARWJOd9vsoPYIgKyEg/+vAGzmQUEJC6vuwhWIyxgIfFybx8ziM0roCPxeMV9Jgg7WOLD pL1Qq88xS8x5MZ8RIiEocXLmExaIQVoSN/69BGrgALKlJZb/AzubU8BaYunyO2C7RIFumHJy G9sERsFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5qSukmRlBI c0ry72Cc0+B9iFGAg1GJh9dA/FuEEGtiWXFl7iFGSQ4mJVHemMVAIb6k/JTKjMTijPii0pzU 4kOMEhzMSiK8M7cB5XhTEiurUovyYVLSHCxK4rziGo0RQgLpiSWp2ampBalFMFkZDg4lCd47 F4EaBYtS01Mr0jJzShDSTBycIMN5gIabgtTwFhck5hZnpkPkTzEqSonzrgZJCIAkMkrz4HrB KYfTgfsVozjQK8K8s0CqeIDpCq77FdBgJqDBEQFfQAaXJCKkpBoYo3k5JEPm7ikwOjFbRq7p Rs1MzaDs1NzPC3dtn5NjtqbQq/XS7v8sZvu++lz9b8Dl7X6Eb++Gr6G8q49LF4vPm6f7UPzb +TKObGZluWWvPuT7/mHd2nL5Se5HFcvNsnuX71AXZ3e63RV1MvKX5h9dl5jrUxOe5nRH+GwU epNuubB5eVjdXsPHSizFGYmGWsxFxYkAz/AapBQDAAA= Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 03:02:10 -0000 Joe Touch wrote on Tue, 18 Apr 2017 at 08:03:38 -0700 in <0751aeaa-56ae-e953-3b76-308a6a3478b4@isi.edu>: > > The '25ns' sillyness of GPS with respect to TAI is still there. I now have > > an idea where the 100ms for NTP is coming from. That's really sad. > can you clarify? A problem here is that your ID conflates a known offset with with a typical uncertainty with a theoretical maximum uncertainty. You label the field "d-TAI" and name it a delta, but it isn't one. And the name is evocative of DUT1, which is different kind of thing. It might be better to adopt a standard name for this field (uncertainty? imprecision? +/-?; I am not sure) rather than coining your own. > The 25ns of GPS is the result of a claim in the GPS spec. You should probably cite it explicitly. > The 100ms is from a claim in NTP documentation. You should *definitely* cite this one explicitly. While I have no doubt it is there, that's not what people with untuned run-of-the-mill ntp systems encounter in the public Internet. (And I'm not sure it is really an upper bound either -- I don't think a 101ms error is appreciably less likely than a 99ms error?) And of course, people with finely tuned ntp systems easily achieve far better than 1ms. --jhawk@mit.edu John Hawkinson From nobody Tue Apr 18 20:54:43 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F224D12EBD1 for ; Tue, 18 Apr 2017 20:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaWz6yEPeF-T for ; Tue, 18 Apr 2017 20:54:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761AD126CF6 for ; Tue, 18 Apr 2017 20:54:39 -0700 (PDT) Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3J3sBfr018531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Apr 2017 20:54:22 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-19F8B5B5-C76B-4EAC-8D08-68A36A725A5E Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14E304) In-Reply-To: <20170419030204.GB87484@mit.edu> Date: Tue, 18 Apr 2017 20:54:11 -0700 Cc: art@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3EE54022-07A1-4DBC-B7D4-7FFD0BA06A8E@isi.edu> References: <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> <0751aeaa-56ae-e953-3b76-308a6a3478b4@isi.edu> <20170419030204.GB87484@mit.edu> To: John Hawkinson X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 03:54:41 -0000 --Apple-Mail-19F8B5B5-C76B-4EAC-8D08-68A36A725A5E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Apr 18, 2017, at 8:02 PM, John Hawkinson wrote: >=20 > Joe Touch wrote on Tue, 18 Apr 2017 > at 08:03:38 -0700 in <0751aeaa-56ae-e953-3b76-308a6a3478b4@isi.edu>: >=20 >>> The '25ns' sillyness of GPS with respect to TAI is still there. I now ha= ve >>> an idea where the 100ms for NTP is coming from. That's really sad. >> can you clarify? >=20 > A problem here is that your ID conflates a known offset with > with a typical uncertainty with a theoretical maximum uncertainty. > You label the field "d-TAI" and name it a delta, but it isn't one. > And the name is evocative of DUT1, which is different kind of thing. >=20 > It might be better to adopt a standard name for this field > (uncertainty? imprecision? +/-?; I am not sure) rather than coining > your own. Uncertainty sounds good. >=20 >> The 25ns of GPS is the result of a claim in the GPS spec. >=20 > You should probably cite it explicitly. I'll dig that one up. >=20 >> The 100ms is from a claim in NTP documentation. >=20 > You should *definitely* cite this one explicitly. http://www.ntp.org/ntpfaq/NTP-s-algo.htm A time difference of less than 128ms between server and client is required t= o maintain NTP synchronization. The typical accuracy on the Internetranges f= rom about 5ms to 100ms, possibly varying with network delays. A recent surve= y[2] suggests that 90% of the NTP servers have network delays below 100ms, a= nd about 99% are synchronized within one second to the synchronization peer.= (Worth noting as an upper range of what might be safely assumed) > While I have no doubt > it is there, that's not what people with untuned run-of-the-mill > ntp systems encounter in the public Internet. (And I'm not sure > it is really an upper bound either -- I don't think a 101ms error > is appreciably less likely than a 99ms error?) And of course, > people with finely tuned ntp systems easily achieve far better than 1ms. >=20 > --jhawk@mit.edu > John Hawkinson --Apple-Mail-19F8B5B5-C76B-4EAC-8D08-68A36A725A5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Apr 1= 8, 2017, at 8:02 PM, John Hawkinson <jha= wk@MIT.EDU> wrote:

= Joe Touch <touch@isi.edu> wrote o= n Tue, 18 Apr 2017
at 08:03:38 -0700 in <0751aeaa-56ae-e953-3b76-308a= 6a3478b4@isi.edu>:

The '25ns' sillyness of GPS with respect t= o TAI is still there. I now have
an idea where the 100ms f= or NTP is coming from. That's really sad.
can you clarify?

A problem here is that your ID conflates a known offset= with
with a typical uncertainty with a theoretical maximum u= ncertainty.
You label the field "d-TAI" and name it a delta,= but it isn't one.
And the name is evocative of DUT1, which i= s different kind of thing.

It might be bett= er to adopt a standard name for this field
(uncertainty? imp= recision? +/-?; I am not sure) rather than coining
your own.=

Uncertainty sounds good.

The 25ns of GPS is the result of a claim in the GPS spec.=

You should probably cite it explicit= ly.

I'll dig that one up.

The 100ms is from a claim in NTP documentation.

You should *definitely* cite this one explicit= ly.

http://www.ntp.org/ntpfaq/NTP-s-algo.htm
<= br>
A ti= me difference of less than 128ms between server and client is required to ma= intain NTP synchronization. T= he typical accuracy on the Internetranges from about 5ms t= o 100ms, possibly varying with network delays. A recent survey[2] suggests that 90% of the NTP servers have network delays below 100ms, and abo= ut 99% are synchronized within one second to the synchronization peer.

(Worth noting as an upper range of what might be safely ass= umed)

While I have no d= oubt
it is there, that's not what people with untuned run-of= -the-mill
ntp systems encounter in the public Internet. (And= I'm not sure
it is really an upper bound either -- I don't t= hink a 101ms error
is appreciably less likely than a 99ms er= ror?) And of course,
people with finely tuned ntp systems ea= sily achieve far better than 1ms.

--jhawk@mit.edu
 John Hawk= inson
= --Apple-Mail-19F8B5B5-C76B-4EAC-8D08-68A36A725A5E-- From nobody Wed Apr 19 10:59:02 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD70129BA3; Wed, 19 Apr 2017 10:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmiREgHErwgw; Wed, 19 Apr 2017 10:58:59 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23AF129B9E; Wed, 19 Apr 2017 10:58:58 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v3JHwtgX008143 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Apr 2017 19:58:56 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id v3JHwtvD001745 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Apr 2017 19:58:55 +0200 Received: from DENBGAT9ER2MSX.ww902.siemens.net (139.22.70.79) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 19 Apr 2017 19:58:55 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.107]) by DENBGAT9ER2MSX.ww902.siemens.net ([139.22.70.79]) with mapi id 14.03.0352.000; Wed, 19 Apr 2017 19:58:54 +0200 From: "Kovatsch, Matthias" To: Mark Nottingham , "cabo@tzi.org" CC: "art@ietf.org" , "core@ietf.org" Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 Thread-Index: AQHSsbAJgy90j5EPhU2Dw058Pbi54KG+Oc0AgAD5ZgCAAiynAIAABAsAgAAA6ICACvX8kA== Date: Wed, 19 Apr 2017 17:58:53 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01B4F4F7@DEFTHW99EL4MSX.ww902.siemens.net> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:59:00 -0000 Hi there I am picking up this discussion again, as I was made aware of another use c= ase for CoAP-over-WebSockets related to firewalls or shielded networks: wit= hout having looked into the details, HTTP CONNECT apparently does not allow= for OAuth, while upgrading to WebSockets can make use of OAuth to establis= h a secure channel between two edge CoAP proxies that, for instance, forwar= d requests from devices behind one firewall to devices behind another firew= all. Best wishes Matthias From nobody Wed Apr 19 12:10:46 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AAB129BC4; Wed, 19 Apr 2017 12:10:38 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AmXuEFl5DLF; Wed, 19 Apr 2017 12:10:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BCF12952E; Wed, 19 Apr 2017 12:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJAVM0007708; Wed, 19 Apr 2017 21:10:31 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7WmR5NVwzDH3K; Wed, 19 Apr 2017 21:10:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01B4F4F7@DEFTHW99EL4MSX.ww902.siemens.net> Date: Wed, 19 Apr 2017 21:10:31 +0200 Cc: Mark Nottingham , "art@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 514321831.09875-3422f4d2a22ee59edda267964266b43e Content-Transfer-Encoding: quoted-printable Message-Id: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> <4EBB3DDD0FBF694CA2A87838DF129B3C01B4F4F7@DEFTHW99EL4MSX.ww902.siemens.net> To: "Kovatsch, Matthias" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:10:39 -0000 Hi Matthias, while I can imagine uses cases like that, I don=E2=80=99t believe that a = specification has to be exhaustive in listing its use cases. The CoAP = over WebSockets work was motivated by getting full CoAP functionality = into a browser by providing a way for JavaScript code to use a proxy, = and maybe it is enough to point this out in the specification. I = don=E2=80=99t think it is expedient to add use cases that tend to press = unrelated buttons in people =E2=80=94 even if they are made possible by = the generality of the specification. Implementers will find out = anyway... Gr=C3=BC=C3=9Fe, Carsten > On Apr 19, 2017, at 19:58, Kovatsch, Matthias = wrote: >=20 > Hi there >=20 > I am picking up this discussion again, as I was made aware of another = use case for CoAP-over-WebSockets related to firewalls or shielded = networks: without having looked into the details, HTTP CONNECT = apparently does not allow for OAuth, while upgrading to WebSockets can = make use of OAuth to establish a secure channel between two edge CoAP = proxies that, for instance, forward requests from devices behind one = firewall to devices behind another firewall. >=20 > Best wishes > Matthias >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art >=20 From nobody Wed Apr 19 12:22:31 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591A4129C1A; Wed, 19 Apr 2017 12:22:11 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFzqeXD2KAZL; Wed, 19 Apr 2017 12:22:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB24D129557; Wed, 19 Apr 2017 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJM6VE017168; Wed, 19 Apr 2017 21:22:06 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7X1p4yfgzDH3W; Wed, 19 Apr 2017 21:22:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149179722452.3118.982908107963516290@ietfa.amsl.com> Date: Wed, 19 Apr 2017 21:22:05 +0200 X-Mao-Original-Outgoing-Id: 514322525.709632-e6c608bc5c2ecfb6a3a2b1b6084beadb Content-Transfer-Encoding: quoted-printable Message-Id: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> To: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, IETF , core , hybi@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:22:12 -0000 On Apr 10, 2017, at 06:07, Mark Nottingham wrote: >=20 > Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" > URI, using a well-known URI in the "wss" scheme. However, "wss" is not > defined to use well-known URIs, so this is an invalid use. Clearly, this is a bug in draft-ietf-core-coap-tcp-tls-07. I have argued that underlying this is an omission in RFC 6455: ws:/wss: URIs are translated into http:/https: URIs, and the well-known = space is already reserved in the latter, so it would be nonsensical to = try to use RFC 5785 /.well-known for something else in the ws:/wss: URI = schemes. Maybe there wasn=E2=80=99t a use case for well-known URIs in WebSockets = before, but there is one now, and we would like to remedy this omission = in the procedurally simplest possibly way. So I am proposing to add RFC 5785=E2=80=99s well-known URI mechanism to = these URI schemes in the document that needs it, = draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455. Are there any objections to this procedure? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 19 12:32:52 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9170129B0D; Wed, 19 Apr 2017 12:32:43 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2t_a9dboMM0; Wed, 19 Apr 2017 12:32:42 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DCE128C83; Wed, 19 Apr 2017 12:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJWb0V025914; Wed, 19 Apr 2017 21:32:38 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7XFx5FkyzDH3d; Wed, 19 Apr 2017 21:32:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Apr 2017 21:32:37 +0200 X-Mao-Original-Outgoing-Id: 514323157.104291-7d2be15871210d08ee22cfcf0d7a07e1 Content-Transfer-Encoding: quoted-printable Message-Id: <289231B4-3335-4CC1-A285-68E1F301360C@tzi.org> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> To: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, IETF , core , hybi@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:32:44 -0000 On Apr 19, 2017, at 21:22, Carsten Bormann wrote: >=20 > So I am proposing to add RFC 5785=E2=80=99s well-known URI mechanism = to these URI schemes in the document that needs it, = draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455. Forgot to add the pointer to the simple fix text: https://github.com/core-wg/coap-tcp-tls/pull/128/files Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 21 09:13:54 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F24129481 for ; Fri, 21 Apr 2017 09:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iBdFzR9d9FK for ; Fri, 21 Apr 2017 09:13:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5826129649 for ; Fri, 21 Apr 2017 09:13:51 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3LGDA8m018423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Apr 2017 09:13:10 -0700 (PDT) To: Toerless Eckert , Nico Williams Cc: Patrik F?ltstr?m , Phillip Hallam-Baker , "art@ietf.org" , Paul Eggert References: <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <7bc1a350-549c-c649-81c6-bcd19cff36d7@cisco.com> <9f719b6a-f3c0-ef98-1636-86e84106e366@cisco.com> <16db07fe-acc5-d178-b56c-755c3cf70680@cs.ucla.edu> <20170418222004.GB2856@localhost> <20170418232126.GD5937@faui40p.informatik.uni-erlangen.de> From: Joe Touch Message-ID: <8bd5b064-a516-a067-9d85-cf44e057135d@isi.edu> Date: Fri, 21 Apr 2017 09:13:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170418232126.GD5937@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:13:53 -0000 Continuing this in ART, as advised by the IESG: On 4/18/2017 4:21 PM, Toerless Eckert wrote: > Nice! > > Why not start to tackle the problem pragmatically before asking for standards > when its clearly a political issue. > > a) RFC describing the problems developers and system deployments can face > because of leap seconds. That's what draft-touch-time attempts to do. > b) And best current practices to get around those issues. Eg: Expect clock > smear on Jan 1 == reduced accuracy of ~1. Unless OS or other trusted > info source gives explicit indication: NO leap, no smear. BCP is to use UTC and track leap seconds if you can, or be clear when that's not possible and your clock (basically) approximates TAI (i.e., UTC without leap seconds, such as when not connected to a network). Nobody should "expect" clock smear - clock smear is just deliberately inaccurate time. > c) And finally a description of the worst open issues when b) is applied. > Anything worse than labels on products "reduced functionality on Jan 1 > after a leap second" ? The IETF doesn't have standards compliance so we can't dictate labels, so I'm not sure why this is useful to consider. Joe > > Cheers > Toerless > > On Tue, Apr 18, 2017 at 05:20:06PM -0500, Nico Williams wrote: >> On Tue, Jan 03, 2017 at 05:34:11PM -0500, Phillip Hallam-Baker wrote: >>> As I said, I want 30-100 years lead time so I can bake the schedule into >>> devices and remove a trust dependency. >> 30 years' lead time for leap seconds? Can't be done. >> >> Leap seconds depend on events such as earthquakes. >> >> You can estimate their frequency, but you can't estimate when they'll be >> inserted. >> >> Nico >> -- From nobody Fri Apr 21 09:19:59 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0612955B for ; Fri, 21 Apr 2017 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cDESh4oev39 for ; Fri, 21 Apr 2017 09:19:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229B2129AA6 for ; Fri, 21 Apr 2017 09:19:51 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3LGIZYD019906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Apr 2017 09:18:37 -0700 (PDT) To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Toerless Eckert Cc: Phillip Hallam-Baker , "art@ietf.org" , Paul Eggert References: <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <7bc1a350-549c-c649-81c6-bcd19cff36d7@cisco.com> <9f719b6a-f3c0-ef98-1636-86e84106e366@cisco.com> <16db07fe-acc5-d178-b56c-755c3cf70680@cs.ucla.edu> <20170418222004.GB2856@localhost> <20170418232126.GD5937@faui40p.informatik.uni-erlangen.de> From: Joe Touch Message-ID: <6a5cdc2b-f6f8-6937-ac32-c0f1a68db32d@isi.edu> Date: Fri, 21 Apr 2017 09:18:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:19:55 -0000 Again, response moved to ART... On 4/18/2017 10:18 PM, Patrik Fältström wrote: > ... > I want as potential fixes which I think are doable: > > - an updated POSIX definition... I'd be glad to hear how that works out, but it's out of scope here AFAICT. > - a slot in the NTP protocol not used today include the number of leap seconds so people get to know that. That seems productive... > That said, I am not against a BCP explaining the issues due to for example the broken POSIX specification (which makes it hard to "do the right thing" in software). Again, that seems out of scope for the IETF. AFAICT, though, it is important to understand what information we need protocols to report, which goes to point #2 above. Joe From nobody Fri Apr 21 10:57:21 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FEA129B22 for ; Fri, 21 Apr 2017 10:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqyY8lmJtUJJ for ; Fri, 21 Apr 2017 10:57:18 -0700 (PDT) Received: from smtp.ucolick.org (hunan.ucolick.org [128.114.23.233]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C14128854 for ; Fri, 21 Apr 2017 10:57:18 -0700 (PDT) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id F3BF3275A; Fri, 21 Apr 2017 10:57:17 -0700 (PDT) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) by smtp.ucolick.org (Postfix) with ESMTP id E22F520FC; Fri, 21 Apr 2017 10:57:17 -0700 (PDT) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (Postfix) with ESMTP id C77A959E; Fri, 21 Apr 2017 10:57:17 -0700 (PDT) Received: (from sla@localhost) by geneva.ucolick.org (8.14.7/8.14.7/Submit) id v3LHvHkO017009; Fri, 21 Apr 2017 10:57:17 -0700 Date: Fri, 21 Apr 2017 10:57:17 -0700 From: Steve Allen To: Applications and Real-Time Area Discussion Message-ID: <20170421175717.GA15237@ucolick.org> References: <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:57:20 -0000 On Mon 2017-04-17T14:32:57 -0700, Joe Touch hath writ: > A new version of I-D, draft-touch-time-02.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. UT0 is not "rarely used", but UT0 belongs in this document for the sake of history. UT0 was the only form of date/time which was available from any source up to around 1950. Thus UT0 was the basis of official/legal times until then. Various radio broadcast sources of time differed from others by 0.1 second or more until after 1960. UT0 had become unavailable from any source before the late 1980s. A reference document for UT0 (and the other forms of UT) is Sadler (1978): http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1978QJRAS..19..290S UT2 is not "rarely used", but UT2 belongs in this document for the sake of history. UT2 became available starting around 1956. In 1959 UT2 became the recommended goal for radio broadcast time signals, and thus UT2 underlay the basis of official/legal times for just over a decade. No technical body was fully comfortable with the concept of UT2, and the folks doing radio broadcast time signals did not claim to be providing UT2. No sources were providing UT2 nor anything based on UT2 starting with the inception of leap seconds in 1972. Reference documents for the use of UT2 are CCIR Recommendation 319 (1959) and CCIR Recommendation 374 (1963,1966). UT1R does not belong in this document. UT1R is never used as a time scale. It serves little purpose other than to guide the eye toward seeing the rapid changes in earth rotation that result from large atmospheric storm systems and the slower trends of UT1 resulting from oceanic and core/mantle interactions. UT1 is more than "widely used as the basis of calendar days". UT1 is the conventional measure of mean solar time descended from GMT. Twenty six nations agreed to use mean solar time as the basis of the Universal Day (the calendar day for diplomacy, commerce, etc.) in the text of Resolution 5 at the International Meridian Conference in 1884, and GMT remains the legal basis of time in many countries. Ephemeris Time does not precede Universal Time. ET did not exist until the 1950s. UT had existed since the 1884 International Meridian Conference, and the name Universal Time was agreed at IAU in 1928. https://www.iau.org/static/resolutions/IAU1928_French.pdf The reference for "Newcomb's tables" in the section on ET is "Tables of the Four Inner Planets" 2nd edition (1898) https://ia801005.us.archive.org/11/items/06AstronomicalPapersPreparedForTheUse/06-Astronomical_Papers_Prepared_for_the_Use_text.pdf The list of major satellite navigation system times woefully ignores India: https://en.wikipedia.org/wiki/Indian_Regional_Navigation_Satellite_System -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From nobody Fri Apr 21 11:23:37 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B741129B36 for ; Fri, 21 Apr 2017 11:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM-Vi3LhI1aO for ; Fri, 21 Apr 2017 11:23:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DE8128DE7 for ; Fri, 21 Apr 2017 11:23:34 -0700 (PDT) Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3LIMcDn011727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Apr 2017 11:22:39 -0700 (PDT) To: Steve Allen , Applications and Real-Time Area Discussion References: <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> <8942ad3f-c151-26a1-1619-b0f36d78b5f0@isi.edu> <20170421175717.GA15237@ucolick.org> From: Joe Touch Message-ID: <36d64760-168f-ef94-25d3-32d16b10f999@isi.edu> Date: Fri, 21 Apr 2017 11:22:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170421175717.GA15237@ucolick.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 18:23:36 -0000 Hi, Steve, Thanks for the updates - I'll roll them in. My apologies in particular for not tracking India's system and including it. Joe On 4/21/2017 10:57 AM, Steve Allen wrote: > On Mon 2017-04-17T14:32:57 -0700, Joe Touch hath writ: >> A new version of I-D, draft-touch-time-02.txt >> has been successfully submitted by Joe Touch and posted to the >> IETF repository. > UT0 is not "rarely used", but UT0 belongs in this document for the > sake of history. UT0 was the only form of date/time which was > available from any source up to around 1950. Thus UT0 was the basis > of official/legal times until then. Various radio broadcast sources > of time differed from others by 0.1 second or more until after 1960. > UT0 had become unavailable from any source before the late 1980s. > A reference document for UT0 (and the other forms of UT) is Sadler (1978): > http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1978QJRAS..19..290S > > UT2 is not "rarely used", but UT2 belongs in this document for the > sake of history. UT2 became available starting around 1956. In 1959 > UT2 became the recommended goal for radio broadcast time signals, and > thus UT2 underlay the basis of official/legal times for just over a > decade. No technical body was fully comfortable with the concept of > UT2, and the folks doing radio broadcast time signals did not claim to > be providing UT2. No sources were providing UT2 nor anything based on > UT2 starting with the inception of leap seconds in 1972. > Reference documents for the use of UT2 are CCIR Recommendation 319 > (1959) and CCIR Recommendation 374 (1963,1966). > > UT1R does not belong in this document. UT1R is never used as a time > scale. It serves little purpose other than to guide the eye toward > seeing the rapid changes in earth rotation that result from large > atmospheric storm systems and the slower trends of UT1 resulting from > oceanic and core/mantle interactions. > > UT1 is more than "widely used as the basis of calendar days". > UT1 is the conventional measure of mean solar time descended from GMT. > Twenty six nations agreed to use mean solar time as the basis of the > Universal Day (the calendar day for diplomacy, commerce, etc.) in the > text of Resolution 5 at the International Meridian Conference in 1884, > and GMT remains the legal basis of time in many countries. > > Ephemeris Time does not precede Universal Time. ET did not exist > until the 1950s. UT had existed since the 1884 International Meridian > Conference, and the name Universal Time was agreed at IAU in 1928. > https://www.iau.org/static/resolutions/IAU1928_French.pdf > The reference for "Newcomb's tables" in the section on ET is > "Tables of the Four Inner Planets" 2nd edition (1898) > https://ia801005.us.archive.org/11/items/06AstronomicalPapersPreparedForTheUse/06-Astronomical_Papers_Prepared_for_the_Use_text.pdf > > The list of major satellite navigation system times woefully ignores India: > https://en.wikipedia.org/wiki/Indian_Regional_Navigation_Satellite_System > > -- > Steve Allen WGS-84 (GPS) > UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 > 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 > Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Mon Apr 24 03:06:22 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B899B12EC13; Mon, 24 Apr 2017 03:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dho2VUhYH-8b; Mon, 24 Apr 2017 03:06:07 -0700 (PDT) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2863612EBCF; Mon, 24 Apr 2017 02:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mGRZQ2Pk6IP6/9wtfPWMjnHXt+PJWC1dFb1mTGStjFk=; b=Ra+sR9NwwL+hjijG0dKrBk683O tNqK1vd/2imcrl0ojS7kbmSqjNjVMK1k3RIdDvFw7o76V1/MMAqLII9SrUP5UxLV9Ny5R9NhYzN+q Gi2+3nXRbPhARqNkVCBB9Rb80bri1CrGm2xVzN6VWFo4MMvjv1syfckrldjPPZt1VQd0r0M4Tfmci caQ7AKpBkS+SrKg+Mn1fEni2WFdtCMA9raNB+shgtzMLdJ77L4lrj6saBjG+TlY8gVO6qICW4HISv pWOoPFK8OImqdF6Mm6RjSK8n6cV1iG35XrKtZDqpAmJmP8gNIZ9d1BXNmQA737Vf/uykUJP7UJOJt 08k3+wRg==; Received: from 201.116.77.83.dynamic.wline.res.cust.swisscom.ch ([83.77.116.201]:55969 helo=dretbook.home) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d2amA-0000GX-9t; Mon, 24 Apr 2017 05:59:22 -0400 To: Herbert Van de Sompel , Carsten Bormann References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> Cc: ietf@ietf.org, art@ietf.org, draft-ietf-core-links-json.all@ietf.org, Mark Nottingham , "core@ietf.org WG" From: Erik Wilde Message-ID: Date: Mon, 24 Apr 2017 10:49:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 10:06:09 -0000 hello. just adding my voice here and since i am collaborating with herbert on this, my position is relatively clear. On 2017-04-18 14:47, Herbert Van de Sompel wrote: > 2. Regarding Mark's comment "This means that any constraints upon > RFC6690 documents are also > mirrored into these formats": Mark mentions IRIs as a concern. I am also > concerned about the rules for interpretation of (the Context IRI of) > links as described in Section 2.1 of 6690 > (https://tools.ietf.org/html/rfc6690#section-2.1). It seems to me that > these also introduce constraints that go beyond 5988. I may be mistaken > with that regard because I have never fully understood that section of > 6690 (i.e. the use of "base URI", "origin", "Context URI"). But, when > compared to 5988, the section comes across as imposing constraints that > are intended to allow the straightforward use of relative URIs in > constrained environments as a means to decrease the payload. If my > interpretation is correct, then I would very much favor spec-ing the > json link format in terms of 5988 rather than 6690. very much agreed, it would be great to have a generic way of serializing links as standalone resources (ideally in a way that is able to preserve their context, so that relative URIs are well-defined). my concern is that RFC 6690 was not intended to do this (it adds constraints to RFC 5988), and thus draft-ietf-core-links-json has the same limitations. to be fair, the draft does not intend to define a general-purpose web link serialization, it is simply intended as a serialization of the specialized model defined in RFC 6690. i am not sure what the best way forward is. the representations defined in this draft are tantalizingly close to general-purpose serializations of RFC 5988. but the draft is clearly intended to be (one more) building block in the "CoRE-only" universe. two suggestions: - add language that makes it clear that because of the limitations of RFC 6690, the media types in this draft should not be considered as general-purpose serializations of web links. - consider adding a serialization of web links to RFC 5988bis. this would address the problem of how to serialize web links outside of the HTTP link header field. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Apr 24 04:53:17 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF612EBC7; Mon, 24 Apr 2017 04:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-_A0SSi7VOd; Mon, 24 Apr 2017 04:53:08 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D70E127B73; Mon, 24 Apr 2017 04:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3OBqHMr003090; Mon, 24 Apr 2017 13:52:17 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wBPpS6GrhzDHJ4; Mon, 24 Apr 2017 13:52:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 24 Apr 2017 13:52:15 +0200 Cc: Herbert Van de Sompel , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514727535.684329-be5ad1644b45dde245ba178c864264fa Content-Transfer-Encoding: quoted-printable Message-Id: <027F2C41-E498-4801-86E2-047771E10545@tzi.org> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> To: Erik Wilde X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 11:53:10 -0000 On Apr 24, 2017, at 10:49, Erik Wilde wrote: >=20 > - consider adding a serialization of web links to RFC 5988bis. this = would address the problem of how to serialize web links outside of the = HTTP link header field. Sounds good to me. What needs to be done to make sure links-json is a proper subset of = this? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 24 05:48:38 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891BA13150F; Mon, 24 Apr 2017 05:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-LpXFH2X_aM; Mon, 24 Apr 2017 05:48:28 -0700 (PDT) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C1D131504; Mon, 24 Apr 2017 05:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=UC9sWWxKH1eqF2oU21h1VeiNoG4Wqp4yaF7IlyCwuds=; b=ammD7eky36yaO3MZBCm/PYIoXe OXvTk/bIAizfuJX+U9fje4wwZ44IkbN6T4GLktDoq+XQLCk056oBlpMWzM44h1CXp0UANOkcx8D+f 5Drcwi9xvJTaPEdkZNR47vsyJUi7YUw3LtdcqNYeXlRuJqQJnQKnmW32RWhomkrK1NTNYJGlNdwnO aC/iWAlYpxUJTTWAmtJoh8wT88NJofaaoFgQ0KtdKeos2JDJmaGfoBKagUCXzvfAuGHJeD2LF7gSr tTCD8okTDxQtLaHGzAqctuwh3MpI8v1menCmadCB7qXXaB0ag8wd2MqnOEj9D9cz2G92H/NjawinG 0Fm4Np4w==; Received: from 201.116.77.83.dynamic.wline.res.cust.swisscom.ch ([83.77.116.201]:55922 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d2dPn-0003r7-Np; Mon, 24 Apr 2017 08:48:27 -0400 To: Carsten Bormann References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> Cc: Herbert Van de Sompel , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org From: Erik Wilde Message-ID: <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> Date: Mon, 24 Apr 2017 14:48:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <027F2C41-E498-4801-86E2-047771E10545@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 12:48:30 -0000 On 2017-04-24 13:52, Carsten Bormann wrote: > On Apr 24, 2017, at 10:49, Erik Wilde wrote: >> - consider adding a serialization of web links to RFC 5988bis. this would address the problem of how to serialize web links outside of the HTTP link header field. > Sounds good to me. > What needs to be done to make sure links-json is a proper subset of this? hard to tell as "this" is just speculation at this point. generally speaking, i don't think it's such a great idea to piggyback on standards and then reduce their expressiveness. imho that's one of the well-known anti-patterns of interop: (extended) subsets. but if you're shooting for a subset i think that's where you are right now. it would be better to make sure that serializations of web links actually can represent web links and not just some of the information that they convey. that train may have left the station with RFC 6690, but maybe for the JSON and CBOR serializations that can be changed. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Apr 24 05:57:06 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF137128959; Mon, 24 Apr 2017 05:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vQKb_6jzFps; Mon, 24 Apr 2017 05:56:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B40E131448; Mon, 24 Apr 2017 05:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3OCtv8U024072; Mon, 24 Apr 2017 14:55:57 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wBRCx27SHzDHKw; Mon, 24 Apr 2017 14:55:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> Date: Mon, 24 Apr 2017 14:55:56 +0200 Cc: Herbert Van de Sompel , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514731356.639242-36f7ee4bca0d5a83208bda5fa5f40929 Content-Transfer-Encoding: quoted-printable Message-Id: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> To: Erik Wilde X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 12:56:51 -0000 On Apr 24, 2017, at 14:48, Erik Wilde wrote: >=20 > On 2017-04-24 13:52, Carsten Bormann wrote: >> On Apr 24, 2017, at 10:49, Erik Wilde wrote: >>> - consider adding a serialization of web links to RFC 5988bis. this = would address the problem of how to serialize web links outside of the = HTTP link header field. >> Sounds good to me. >> What needs to be done to make sure links-json is a proper subset of = this? >=20 > hard to tell as "this" is just speculation at this point. generally = speaking, i don't think it's such a great idea to piggyback on standards = and then reduce their expressiveness. imho that's one of the well-known = anti-patterns of interop: (extended) subsets. >=20 > but if you're shooting for a subset i think that's where you are right = now. >=20 > it would be better to make sure that serializations of web links = actually can represent web links and not just some of the information = that they convey. that train may have left the station with RFC 6690, = but maybe for the JSON and CBOR serializations that can be changed. Right. Can you be more specific what you would want to see here? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 25 05:36:17 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72C12EC88; Tue, 25 Apr 2017 05:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-qJLzjJYjvS; Tue, 25 Apr 2017 05:35:57 -0700 (PDT) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4780A12EC85; Tue, 25 Apr 2017 05:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zSyfr+bpXj8QAvL2HVJqpDCw/VifG4EMu3P5i8hEDMo=; b=xQlkMleb/tu1ALgiOrSEnFpOsr 9Dtqigqv7Z4hn6MlPZgbCikNn6T/6ZvSUaDhRCo3EC3jYdSdtog0l8BIp37M/0BpaN8wfXqqDRQ2u LdM1jk5pAadGPP8W5423qvHoEYRbj4fTBPbvRnrdljnK2GQpfPJQVP2M/B/s4pEBt4vMbfrNYmWGh bZB3WxJyejzEbTvVyKktj6lCcrSrquFyHfeE7hnTZkLMsnRCkvkfGUAXklQ4S5WsvpK71VePBtnfw rOxQgQwpMo8jLzJfJ4qRlncsfD1S6QFt20R56ivXUHPA84rnucKiYZpFFUOdpuajF8+2+ajTOt6zu n2Cu8wRw==; Received: from [141.202.54.2] (port=64523 helo=dretpro.local) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d2zhD-0007F1-Pv; Tue, 25 Apr 2017 08:35:55 -0400 To: Carsten Bormann References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> Cc: Herbert Van de Sompel , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org From: Erik Wilde Message-ID: Date: Tue, 25 Apr 2017 14:35:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 12:35:58 -0000 hello carsten. On 2017-04-24 14:55, Carsten Bormann wrote: >> it would be better to make sure that serializations of web links actually can represent web links and not just some of the information that they convey. that train may have left the station with RFC 6690, but maybe for the JSON and CBOR serializations that can be changed. > Right. Can you be more specific what you would want to see here? two possibilities: - to do things well it would be better to have web link serializations that cover *all* of RFC 5988 (bis). that's a hard thing to do and will take a while. - for the RFC 6690-based variants under consideration right now, it would be helpful to very explicitly point out that they are *not* general-purpose serializations of web links, but instead inherit the limitations of the underlying spec. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Tue Apr 25 05:50:27 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3944112EC9D; Tue, 25 Apr 2017 05:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KroGHSiWTdXU; Tue, 25 Apr 2017 05:50:16 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F78712ECA4; Tue, 25 Apr 2017 05:50:16 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id h123so57648861qke.0; Tue, 25 Apr 2017 05:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5qvgovgsEj6145CjlgdjBcvQgNAGxSCzrRrXNZNl+yg=; b=en4ZqxTx6HwDtZVJrXKaZqAZL4rgwCF0hZBzFNG+TWy/Q5H7/tJJk6gdbzXQtgF+0k ZPSH/pbfpN0OP7BZIiaH25NIo6foeaacz/iTmF27FydcDWcbyqvcPX/+was8rLiz9oGc HfEVMsyAojmV97Y+nBI6POpk/vZdZhDBOcoNnMtr/tYpdp1oonBowGGGyLzXqGFAaXbm +YWvLjXyy/hPTUzEeU6FbUyTMLfoKjF5GxP5JNFf4cCWAQfAgRwALHqVjDjqrJFu+4k3 Ph0oD0rwr5J1hoatEVsl/jPg/yFYqZzmO0iAen8Q0tD+tyt8IOyKtI+LAhOiUNh+FUxs GKGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5qvgovgsEj6145CjlgdjBcvQgNAGxSCzrRrXNZNl+yg=; b=jrjg3YbimVAV3YV7dGyRY9AABPfyTBoTngHW2s3Euz44iuA+HFEmGUV6lyv5QyePld si7S7Wo1IwLg8SYaQG2yTDM0vTmKo1roZLRaX0uXoXsRhierG5UlKgmgDbLFHlexBpXZ 8gGYXViREtKT34S3AxUE9WBsZ+kBPN1QTX8uxon++sDjo0zhzUPeOn45WjuQ2qMGYnAY 1aMRnIG8zpbZJJ5vBO9vIq6IPhqsJPrz7OBIZUuP503urM2jfEqfkwVDo2gAezKogJ7G itjJAR3rMgMYWe5miKcLtE7i8w8fmdQjMJ9h0zyrFIeWD+WfWDAe2SgP1XbayxnUEQLp oGIA== X-Gm-Message-State: AN3rC/6uA1gBQZSGOuTwFLeXuTywCV78IrBSdmqMC7wi4gSIdnx/zszS JO9/CpXP/YXeldEnm8alZkBqjRse/Q== X-Received: by 10.55.41.74 with SMTP id p71mr11448557qkh.110.1493124615856; Tue, 25 Apr 2017 05:50:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.45.162 with HTTP; Tue, 25 Apr 2017 05:50:15 -0700 (PDT) In-Reply-To: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> From: Herbert Van de Sompel Date: Tue, 25 Apr 2017 14:50:15 +0200 Message-ID: To: Erik Wilde Cc: Carsten Bormann , art@ietf.org, Mark Nottingham , ietf@ietf.org, "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org, Herbert Van de Sompel Content-Type: multipart/alternative; boundary=001a1147acdc557ada054dfd2adc Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 12:50:18 -0000 --001a1147acdc557ada054dfd2adc Content-Type: text/plain; charset=UTF-8 On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde wrote: > hello carsten. > > On 2017-04-24 14:55, Carsten Bormann wrote: > >> it would be better to make sure that serializations of web links actually >>> can represent web links and not just some of the information that they >>> convey. that train may have left the station with RFC 6690, but maybe for >>> the JSON and CBOR serializations that can be changed. >>> >> Right. Can you be more specific what you would want to see here? >> > > two possibilities: > > - to do things well it would be better to have web link serializations > that cover *all* of RFC 5988 (bis). that's a hard thing to do and will take > a while. > > As Erik previously indicated, it would be great if this could be done as part of RFC5988bis. > - for the RFC 6690-based variants under consideration right now, it would > be helpful to very explicitly point out that they are *not* general-purpose > serializations of web links, but instead inherit the limitations of the > underlying spec. > > That would, indeed, be good. But, in case RFC5988bis would spec a (JSON) serialization, it seems to me that it would be rather helpful for the CORE community if the RFC 6690 JSON serialization would be based on it. Cheers herbert > > cheers, > > dret. > > -- > erik wilde | mailto:erik.wilde@dret.net | > | http://dret.net/netdret | > | http://twitter.com/dret | > -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ http://orcid.org/0000-0002-0715-6126 == --001a1147acdc557ada054dfd2adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 25, 2017 at 2:35 PM, Erik Wilde <erik.wilde@dret.net> wrote:
hello carst= en.

On 2017-04-24 14:55, Carsten Bormann wrote:
it would be better to make sure that serializations of web links actually c= an represent web links and not just some of the information that they conve= y. that train may have left the station with RFC 6690, but maybe for the JS= ON and CBOR serializations that can be changed.
Right.=C2=A0 Can you be more specific what you would want to see here?

 two possibilities:

- to do things well it would be better to have web link serializations that= cover *all* of RFC 5988 (bis). that's a hard thing to do and will take= a while.


As Erik previously indicated, it would= be great if this could be done as part of RFC5988bis.
=C2=A0
- for the RFC 6690-based variants under consideration right now, it would b= e helpful to very explicitly point out that they are *not* general-purpose = serializations of web links, but instead inherit the limitations of the und= erlying spec.

=

That would, indeed, be good. But, in= case RFC5988bis would spec a (JSON) serialization, it seems to me that it = would be rather helpful for the CORE community if the RFC 6690 JSON seriali= zation would be based on it.=C2=A0

Cheers

herbert

=C2=A0

cheers,

dret.

--
erik wilde | mailto:erik.wilde@dret.net |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret=C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://twitter.com/dret=C2=A0 = =C2=A0 |



--
=
Herbert Van de Sompel
Digital Library Res= earch & Prototyping
Los Alamos National Laboratory, Research Library=
http://p= ublic.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126

=3D= =3D
--001a1147acdc557ada054dfd2adc-- From nobody Tue Apr 25 06:07:58 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342441200FC; Tue, 25 Apr 2017 06:07:51 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjSJrpLvIKPH; Tue, 25 Apr 2017 06:07:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89573127B57; Tue, 25 Apr 2017 06:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3PD6pKS026446; Tue, 25 Apr 2017 15:06:51 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wC3Q304RBzDHsc; Tue, 25 Apr 2017 15:06:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 25 Apr 2017 15:06:48 +0200 Cc: Erik Wilde , art@ietf.org, Mark Nottingham , IETF , "core@ietf.org WG" , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514818407.59117-b4ffb0b6498cf5f580cda089da02173a Content-Transfer-Encoding: quoted-printable Message-Id: <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> To: Herbert Van de Sompel X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:07:51 -0000 > On Apr 25, 2017, at 14:50, Herbert Van de Sompel = wrote: >=20 > On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde = wrote: > hello carsten. >=20 > On 2017-04-24 14:55, Carsten Bormann wrote: > it would be better to make sure that serializations of web links = actually can represent web links and not just some of the information = that they convey. that train may have left the station with RFC 6690, = but maybe for the JSON and CBOR serializations that can be changed. > Right. Can you be more specific what you would want to see here? >=20 > two possibilities: >=20 > - to do things well it would be better to have web link serializations = that cover *all* of RFC 5988 (bis). that's a hard thing to do and will = take a while. >=20 >=20 > As Erik previously indicated, it would be great if this could be done = as part of RFC5988bis. Yes. But covering all of RFC 5988 is mainly hard because of the vagaries of = HTTP header field encoding. We don=E2=80=99t have that problem in RFC 6690, so it is easy to have = RFC 6690 and links-json as a proper subset if we want to. > - for the RFC 6690-based variants under consideration right now, it = would be helpful to very explicitly point out that they are *not* = general-purpose serializations of web links, but instead inherit the = limitations of the underlying spec. >=20 >=20 > That would, indeed, be good. But, in case RFC5988bis would spec a = (JSON) serialization, it seems to me that it would be rather helpful for = the CORE community if the RFC 6690 JSON serialization would be based on = it.=20 I would hope so, but remember that links-json is already out there. The RFC 6690 JSON serialization is pretty much a no-brainer, and there = are no obvious ways to do things very different (well, you could choose = a different name for =E2=80=9Chref=E2=80=9D, but that would not be very = bright). CBOR adds a few bike sheds, but these can be painted in the = same color with little effort. If a superset RFC 5988 JSON serialization deviates from this (i.e., is = not a proper superset), I think this would require some willful effort. (I=E2=80=99m happy to be proven wrong; that=E2=80=99s why I was asking = if any specifics are known here already.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 25 09:47:43 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8F212EB44; Tue, 25 Apr 2017 09:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iioN6VG7Bwdt; Tue, 25 Apr 2017 09:47:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05CB129A91; Tue, 25 Apr 2017 09:47:24 -0700 (PDT) Received: from [192.168.178.20] ([93.217.111.164]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LyVcA-1bxQWf3moo-015uEj; Tue, 25 Apr 2017 18:46:24 +0200 To: Carsten Bormann , Herbert Van de Sompel References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> Cc: IETF , art@ietf.org, "core@ietf.org WG" , Erik Wilde , draft-ietf-core-links-json.all@ietf.org From: Julian Reschke Message-ID: Date: Tue, 25 Apr 2017 18:46:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hc2flPMI2xoEM8PXdvVJ6YpBzL4x35h2N/07C+H5n+WlR2ldIsT kOmSrI+bsgT4Zr2SReDzoV6h0XGPB9KeIlENoBW+ruN5PecCWuDh5AC/MWyKv6BWZK/5G4q YSYp5WVzWm32NumtRWf4xkZheeHL3o+l4MKDqimlN0OqV0XZFabIqvVKOaooXtlSbeayoSx FpUUqbFcgrg6X2jkGjX9w== X-UI-Out-Filterresults: notjunk:1;V01:K0:rOnBY3m5eYo=:Dn2omTrw4EVngdaeIS8U4O FsUn5q/gNf/bFeuoqsHDzWabMr0gCTYHq1TUzCON45WN/EXz1/WaUs0/9Vr79WasGWT6SKLa3 v5st6ds73Ko/tQWgOlBOj23l9xg3f5DVWy9RrqcIBbni+JHuEKCNUWzFZTl/Ba4jB9PQT0vEU MvZu+MVm2FJx3wh3QsT+NZO81uJa1znx6/+YAP4z/mrUZTkz7LFVxaRz0lCS2UZn0eaZ+4nhP E6xJdEvf5RSTNf1ULyaxc+H9WkqWvOgFqN5hbIqdJVJhuVlOJ8vdd9ODneTVtytdM9oGV4/fD +UaIVBv84JUO1Qw3SGDWsYdpEqy7lGrY8GmRJgVWzyOCDHP+90oZUVXcsTLGFLnfvQ2VJ22Ck UWMusunICnLgl06n3MDxRfl1Jd7kpy5EUfVCDq3ngeKVPeBc/Zdan36iVHj7HNxuuGHlDhNhE g1Oy4wzX0qb6nkP4OIXTz5GxurHvU4pI+QG/pCcW4JFC2vk43JQ2Ye/KzGUQBgxEaOkpgfNBZ luiTFhiX4rpnx7EslAUclVX5rleBDIQ9yuoJyTGC0OqGvML4vvqvkq9IFc3fjIh7tPe60hLHv lUVgvjhnAkU/X36omK1pPng8krm4AP3L5usBwfenj8wRDvgVWwj4TOEGoALhp6y0oE5cC4Ecj vhVjrrTvD4wlEWSJT7sQF0t95dzh3JFxNTIkZnnJgjRf9J8xPze302RTZCF0WdJOsuj32HI+y p2T7G9iY9LhAzKrd3N3dq3VZDHIShZ22VJH02iiecsiuyiNOMc/n7OUcPdADQWYMer66wAFVB iVj+FER Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 16:47:27 -0000 On 2017-04-25 15:06, Carsten Bormann wrote: > >> On Apr 25, 2017, at 14:50, Herbert Van de Sompel wrote: >> >> On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde wrote: >> hello carsten. >> >> On 2017-04-24 14:55, Carsten Bormann wrote: >> it would be better to make sure that serializations of web links actually can represent web links and not just some of the information that they convey. that train may have left the station with RFC 6690, but maybe for the JSON and CBOR serializations that can be changed. >> Right. Can you be more specific what you would want to see here? >> >> two possibilities: >> >> - to do things well it would be better to have web link serializations that cover *all* of RFC 5988 (bis). that's a hard thing to do and will take a while. >> >> >> As Erik previously indicated, it would be great if this could be done as part of RFC5988bis. > > Yes. > > But covering all of RFC 5988 is mainly hard because of the vagaries of HTTP header field encoding. > ... Do you have a specific problem in mind? Best regards, Julian From nobody Tue Apr 25 10:26:50 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FE31316D6; Tue, 25 Apr 2017 10:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_GVWp4Riwbm; Tue, 25 Apr 2017 10:26:43 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0095.outbound.protection.outlook.com [104.47.2.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A993C129AB2; Tue, 25 Apr 2017 10:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xrSNF8YSOouXuL+jyq4t1k3/OeIaRENSfwVWiYhZrA8=; b=YymU6rOlnl9lJ0zUTOo2j80qbrlZBpPsCle9IVwznqqgS+iiBeGu0GU0hha4HkxUTQL8uPNsAmTX0F4XGqy6z8EY2rRLN5314X13kiucfynCnmPxhE81Fx0/W74M5faXbglZhZ4lLQvaAT+NH2mCsiXb1sfQJG/a9wv2Wfemy9I= Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) by DB6PR0701MB2455.eurprd07.prod.outlook.com (10.168.75.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 17:26:40 +0000 Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) by DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) with mapi id 15.01.1061.011; Tue, 25 Apr 2017 17:26:40 +0000 From: "Randriamasy, Sabine (Nokia - FR/Nozay)" To: Martin Thomson , "art@ietf.org" CC: "alto@ietf.org" , "ietf@ietf.org" , "draft-ietf-alto-multi-cost.all@ietf.org" Thread-Topic: Artart telechat review of draft-ietf-alto-multi-cost-08 Thread-Index: AQHSrnqQeK8CFgpYuE64kjZYAubM4qHWYMDg Date: Tue, 25 Apr 2017 17:26:40 +0000 Message-ID: References: <149144445494.22036.11923880719369865745@ietfa.amsl.com> In-Reply-To: <149144445494.22036.11923880719369865745@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.212.18] x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2455; 7:1cBM0Up4I8Aer73/BhkQIv3yAD6n2ASwTylLjQluWHeaRDPNfcrHzusxbJXQFKmPrzrJrFCxArvodk3oemsp4BgwdqwFvqV+sK623Vx0vbMXMb24fmdi+g/wfCGdMckVAJEkNT4Iux0xPvULB9vOu2GW9rilBvERAbqAKx8efZDGhsBFn0ZdWrKFaA4L1JRLh50ZD6OtEW7yc8c3Nny0IsUhe9GN9CzBFpZ1OEgZ3AUyUpUcLp8so0q3f+gHhFypypTmYCjwdVtaPBbAKxT63jeBrQORxlebtcSSJrmPPsz6nBN+k0F2d3jAGpXg0FMi73D524iU2DMfMnO8qk9kSA== x-ms-office365-filtering-correlation-id: 93ceb0cc-8dc0-4a4d-f14a-08d48c003c26 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB6PR0701MB2455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148); SRVR:DB6PR0701MB2455; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2455; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(13464003)(51444003)(377424004)(2900100001)(6246003)(2501003)(38730400002)(6306002)(6436002)(54906002)(9686003)(189998001)(6506006)(106356001)(53936002)(230783001)(6116002)(3846002)(102836003)(66066001)(99286003)(55016002)(7696004)(3660700001)(122556002)(39060400002)(2950100002)(7736002)(50986999)(76176999)(54356999)(3280700002)(81166006)(2906002)(8936002)(25786009)(8676002)(4326008)(77096006)(74316002)(33656002)(305945005)(345774005)(5660300001)(229853002)(86362001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2455; H:DB6PR0701MB2454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 17:26:40.0604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2455 Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-alto-multi-cost-08 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:26:46 -0000 SGVsbG8gTWFydGluLCANCg0KRmlyc3Qgb2YgYWxsIHRoYW5rIHlvdSBmb3IgeW91ciB0aG9yb3Vn aCByZXZpZXcgYW5kIGNvbW1lbnRzLiANCkEgbmV3IHZlcnNpb24gaGFzIGJlZW4gdXBsb2FkZWQg dG8gYWRkcmVzcyB0aGVtIGFuZCBpcyBhdmFpbGFibGUgYXQgDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYWx0by1tdWx0aS1jb3N0LTA5IA0KSSBob3Bl IHRoZSB1cGRhdGVzIGFkZHJlc3MgeW91ciBxdWVzdGlvbnMuIFBsZWFzZSwgbGV0IG1lIGtub3cg b3RoZXJ3aXNlLg0KDQpQbGVhc2Ugc2VlIGFsc28gaW5saW5lIGZvciBteSBhbnN3ZXJzLA0KDQpC ZXN0IHJlZ2FyZHMsDQpTYWJpbmUNCg0KDQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXQ0K Pj5TZW50OiAwNiBBcHJpbCAyMDE3IDA0OjA4DQo+PlRvOiBhcnRAaWV0Zi5vcmcNCj4+Q2M6IGFs dG9AaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYWx0by1tdWx0aS1jb3N0LmFs bEBpZXRmLm9yZw0KPj5TdWJqZWN0OiBBcnRhcnQgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWll dGYtYWx0by1tdWx0aS1jb3N0LTA4DQo+Pg0KPj5SZXZpZXdlcjogTWFydGluIFRob21zb24NCj4+ UmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXMNCj4+DQo+PkRvY3VtZW50OiBkcmFmdC1p ZXRmLWFsdG8tbXVsdGktY29zdC0wOA0KPj5EYXRlOiAyMDE3LTA0LTA2DQo+PlJldmlld2VyOiBN YXJ0aW4gVGhvbXNvbg0KPj4NCj4+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IEFMVE8gY2Fu IGJlIHVzZWQgdG8gYWNxdWlyZSBjb3N0IG1hcHMgd2l0aA0KPj5tdWx0aXBsZSBjb3N0IG1ldHJp YyBpbnN0ZWFkIG9mIGEgc2luZ2xlIG1ldHJpYy4NCj4+DQo+PlRoZSBkb2N1bWVudCB2ZXJ5IGNh cmVmdWxseSBkZWFscyB3aXRoIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3RpbmcN Cj4+QUxUTyBzZXJ2ZXJzIGFuZCBjbGllbnRzLiAgSSBkb24ndCBhbnRpY2lwYXRlIG1hbnkgaXNz dWVzIGFyaXNpbmcgZnJvbSB0aGUNCj4+ZGVwbG95bWVudCBvZiB0aGlzIHByb3RvY29sLg0KPj4N Cj4+SSBzdGFydGVkIHJlYWRpbmcgLTA3LCBidXQgZmluaXNoZWQgd2l0aCAtMDguICBJIGNoZWNr ZWQgdGhhdCB0aGUgaXNzdWVzIEkgcmFpc2UNCj4+c3RpbGwgZXhpc3QsIGJ1dCBJJ20gbm90IGlu ZmFsbGlibGUuICBBcG9sb2dpZXMgaWYgSSBnZXQgc29tZXRoaW5nIHdyb25nLg0KPj4NCj4+TWlu b3IgaXNzdWVzOiBJJ3ZlIGlkZW50aWZpZWQgYSBmZXcgaXNzdWVzIHRoYXQgYXJlIG1vcmUgdGhh biBuaXRzLCB0aGVzZSBhcmUNCj4+bWFya2VkICJJTVBPUlRBTlQiIGJlbG93Lg0KPj4NCj4+DQo+ PlRoZSBhYnN0cmFjdCBpbmNsdWRlcyBjb25zaWRlcmFibGUganVzdGlmaWNpYXRpb24uICBBbiBh YnN0cmFjdCBvbmx5IG5lZWRzIHRvDQo+PmRlc2NyaWJlIHRoZSAqd2hhdCosIG5vdCB0aGUgKndo eSouICBUaHVzLCB3aGF0IGlzIHRoZXJlIGNvdWxkIGJlIHNpbXBsaWZpZWQNCj4+Y29uc2lkZXJh Ymx5LCBlLmcuLA0KPj4NCj4+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IG1ldGhvZCBm b3IgcmV0cmlldmluZyBtdWx0aXBsZSBjb3N0IG1ldHJpY3MgaW4NCj4+YQ0KPj4gICBzaW5nbGUg cmVxdWVzdCBmb3IgYW4gQUxUTyBmaWx0ZXJlZCBjb3N0IG1hcC4gIEl0IGFsc28gZGVmaW5lcyBp bXByb3ZlbWVudHMNCj4+ICAgdG8gdGhlIGNvbnN0cmFpbnRzIHRoYXQgY2FuIGJlIHVzZWQgZm9y IGZpbHRlcmVkIGNvc3QgbWFwcy4NCg0KW1NSICAgICBdICBPSy4gQWJzdHJhY3Qgc2hvcnRlbmVk IGluIHRoYXQgZGlyZWN0aW9uDQo+Pg0KPj5TZWN0aW9uIDENCj4+DQo+PlRoZSBpbnRyb2R1Y3Rp b24gdXNlcyBhIGJ1bmNoIG9mIG9kZCB0ZXJtcy4gIFNvbWUgb2YgdGhlc2UgYXJlIHJlY29nbml6 YWJsZQ0KPj5mcm9tIHRoZSBBTFRPIHNwZWNpZmljYXRpb24sIGJ1dCBzb21lIG9mIHRoZSBqYXJn b24gc2VlbXMgdW5uZWNlc3NhcnkuICBJbg0KPj5wYXJ0aWN1bGFyLCAiSW50ZXJuZXQgVmlldyIs ICJQcm92aWRlciBOZXR3b3JrIHJlZ2lvbiIgYW5kICJWZWN0b3IgY29zdHMiLg0KPj5BbGwgb2Yg d2hpY2ggSSB0aGluayB0aGF0IEkgdW5kZXJzdGFuZCwgYnV0IHRoZXkgbWFrZSB0aGUgZG9jIGhh cmQgdG8gZm9sbG93Lg0KPj4NCj4+R2VuZXJhbGx5LCBJIGZvdW5kIHRoZSBpbnRyb2R1Y3Rpb24g cXVpdGUgaGFyZCB0byBmb2xsb3csIGJvdGggZm9yIHRoYXQgcmVhc29uDQo+PmFuZCBzdHJ1Y3R1 cmFsbHkuICBUaGUgaW50cm9kdWN0aW9uIGNvdWxkIGJlIGEgbG90IHNob3J0ZXIgYW5kIG1vcmUN Cj4+Y29uY2lzZToNCj4+DQo+PjEuIEFMVE8gZGVmaW5lcyBtdWx0aXBsZSBjb3N0IHR5cGVzIChh bmQgbW9yZSBhcmUgYmVpbmcgZGVmaW5lZCkuDQo+PjIuIENsaWVudHMgc29tZXRpbWVzIGNvbnN1 bWUgbXVsdGlwbGUgY29zdCB0eXBlcy4NCj4+My4gUmVxdWVzdGluZyBtdWx0aXBsZSBjb3N0IHR5 cGVzIGF0IHRoZSBzYW1lIHRpbWUgaXMgbW9yZSBlZmZpY2llbnQgKGZvcg0KPj4gICBzZXZlcmFs IHJlYXNvbnMpLg0KPj40LiBUaGlzIGRvY3VtZW50IGRlZmluZXMgaG93IHRvIGRvIHRoYXQuDQo+ PjUuIFNlcGFyYXRlbHksIHdoZW4gbXVsdGlwbGUgY29zdCB0eXBlcyBhcmUgcHJlc2VudCwgbW9y ZSBzb3BoaXN0aWNhdGVkDQo+PiAgIGZpbHRlcmluZyBjYW4gaW1wcm92ZSBlZmZpY2llbmN5IGZ1 cnRoZXIuDQo+PjYuIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBob3cgdG8gZG8gdGhhdCB0b28uDQo+ Pg0KW1NSICAgICBdIE9LLCBzZWN0aW9uIHJldmlzZWQgaW4gdGhhdCBkaXJlY3Rpb24NCg0KPj5T ZWN0aW9uIDINCj4+DQo+PlRoZXJlIGFyZSBzZXZlcmFsIGl0ZW1zIGluIHRoZSBsaXN0IGhlcmUg dGhhdCBhcmUgbm90IHVzZWQ6DQo+PkFwcGxpY2F0aW9uIENsaWVudCwNCj4+TmV0d29yayBTZXJ2 aWNlIFByb3ZpZGVyLCBtYXliZSBtb3JlLiAgUGxlYXNlIGNoZWNrIGFuZCByZW1vdmUgdGhvc2UN Cj4+dGhhdCBkb24ndCBhcHBseS4NCj4+DQpbU1IgICAgIF0gT0s6IHJlbW92ZWQgMyBkZWZpbml0 aW9ucw0KDQo+PlRoZSBSRkMgNzI4NSBzZWN0aW9uIHJlZmVyZW5jZSB0aGluZyBpcyB1bm5lY2Vz c2FyeS4NCj4+DQpbU1IgICAgIF0gT0s6IG1vdmVkIHRvIGVuZCBvZiBzZWN0aW9uIDIsIHRvIGF2 b2lkIHJlcGVhdGluZyAib2YgW1JGQzcyODVdIiB0b28gb2Z0ZW4uDQoNCj4+VGhpcyBkb2N1bWVu dCBkb2Vzbid0IGNpdGUgUkZDIDIxMTksIGJ1dCBpdCB1c2VzIHRoZSBrZXl3b3Jkcy4NCltTUiAg ICAgXSBSRkMgMjExOSBpcyBjaXRlZCBvbiBwYWdlIDEsIHNlY3Rpb24gIiBSZXF1aXJlbWVudHMg TGFuZ3VhZ2UiIGFuZCBzZWN0aW9uICI5LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyIuIFNob3Vs ZCBpdCBiZSByZWZlcmVuY2VkIGVsc2V3aGVyZT8gDQoNCj4+U2VjdGlvbiAzLjENCj4+DQo+PlRo ZSBleGFtcGxlIHNob3dzIGFuIGVtcHR5IGNvc3QtdHlwZSwgYnV0IHRoZSBzY2hlbWEgeW91IGRl ZmluZSBhbGxvd3MgaXQNCj4+dG8gYmUgYWJzZW50LiAgWW91IFJFQUxMWSBuZWVkIHRvIHBpY2sg b25lLiAgSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhpcyBpcyBhDQo+PmNvbXBhdGliaWxpdHkgaXNz dWU6IG9uY2UgeW91IGhhdmUgZGV0ZXJtaW5lZCB0aGF0IGEgY2xpZW50IHN1cHBvcnRzIG11bHRp LQ0KPj5jb3N0LCB0aGVuIHlvdSBjYW4gZG8gYW55dGhpbmcgeW91IGxpa2UsIGp1c3QgYmUgY2xl YXIgYWJvdXQgaXQuDQpbU1IgICAgIF0gT0ssIGFkZGVkIGV4cGxhbmF0aW9ucyBiZWZvcmUgYW5k IGFmdGVyIHRoZSBleGFtcGxlIA0KPj4NCj4+U2VjdGlvbiAzLjINCj4+DQo+PkkgZm91bmQgdGhl IGFyZ3VtZW50IGFib3V0IHRoZSBlYXNlIG9mIHdyaXRpbmcgYSBwYXJzZXIgdG8gYmUgcXVpdGUN Cj4+dW5jb252aW5jaW5nLiAgSG93ZXZlciwgYSBuZXcgbWVkaWEgdHlwZSB0aGF0IGlzIGxhcmdl bHkgdGhlIHNhbWUgYXMgdGhlDQo+PmV4aXN0aW5nIG1lZGlhIHR5cGUgd29uJ3QgbmVjZXNzYXJp bHkgcmVzdWx0IGluIGNvZGUgZHVwbGljYXRpb24uDQo+Pg0KPj5KdXN0IHNheSB3aGF0IGl0IGlz IHlvdSBleHBlY3QgdG8gaGFwcGVuIGFuZCBkb24ndCB0cnkgdG8gYmUgYXBvbG9nZXRpYyBhYm91 dA0KPj5pdC4gIFdoYXQgeW91IGhhdmUgYXBwZWFycyB0byBiZSBhIHdvcmthYmxlIGRlc2lnbi4N CltTUiAgICAgXSBPSywgcmVtb3ZlZCAxc3QgcGFyYWdyYXBoLg0KPj4NCj4+U2VjdGlvbiAzLjUN Cj4+DQo+PlRoaXMgc2VjdGlvbiBpcyBjb25mdXNpbmcuICBZb3Ugb25seSBuZWVkIHRvIHNheSB0 aGF0IHlvdSBhcmUgbm90IGFsdGVyaW5nIGZ1bGwNCj4+Y29zdCBtYXAgcmVzb3VyY2VzIGluIGFu eSB3YXkgYW5kIHRoYXQgY2xpZW50cyBuZWVkIHRvIHVzZSBmaWx0ZXJlZCBjb3N0IG1hcHMNCj4+ aWYgdGhleSB3YW50IG11bHRpcGxlIGNvc3RzIGF0IHRoZSBzYW1lIHRpbWUuICAoT2J2aW91c2x5 IHlvdSBjb3VsZCBoYXZlLCBidXQNCj4+Y3JlYXRpbmcgbXVsdGlwbGUgcmVzb3VyY2VzIHdpdGgg dGhlIGZ1bGwgY29tYmluYXRvcmlhbCBtZXNzIGNhdXNlZCBieQ0KPj5jb21iaW5pbmcgbWFueSBj b3N0IHR5cGVzIGlzIHVud2llbGR5LikgIEF0IGEgbWluaW11bSwgdGhlIHNlY29uZA0KPj5wYXJh Z3JhcGggaGVyZSBjYW4gYmUgcmVtb3ZlZC4NCltTUiAgICAgXSBPSyBzaG9ydGVuZWQgMm5kIHBh cmFncmFwaA0KPj4NCj4+U2VjdGlvbiAzLjYuMg0KPj4NCj4+SU1QT1JUQU5UOiBZb3UgZG9uJ3Qg ZGVmaW5lIHdoYXQgaGFwcGVucyB3aGVuIGEgY2xpZW50IHByb3ZpZGVzICJvci0NCj4+Y29uc3Ry YWludHMiDQo+PmFuZCAiY29uc3RyYWludHMiIGF0IHRoZSBzYW1lIHRpbWUuICBUaGVyZSBhcmUg c2V2ZXJhbCB2YWxpZCBvcHRpb25zLCBidXQgeW91DQo+Pm5lZWQgdG8gY2hvb3NlLg0KW1NSICAg ICBdIE9LIGFkZGVkIHRleHQgYXQgdGhlIGVuZCBvbiB3aHkgYSBjbGllbnQgY2Fubm90IHByb3Zp ZGUgYm90aA0KPj4NCj4+U2VjdGlvbiAzLjYuMw0KPj4NCj4+SXQgaXMgcHJvYmFibHkgd29ydGgg ZXhwbGljaXRseSBub3RpbmcgdGhhdCBpZiAidGVzdGFibGUtY29zdC10eXBlcyINCj4+ZG9lcyBu b3QNCj4+aW5jbHVkZSB2YWx1ZXMgZnJvbSAibXVsdGktY29zdC10eXBlcyIsIHRoZW4gdGhvc2Ug dHlwZXMgY2FuJ3QgYmUgaW5jbHVkZWQgaW4NCj4+ImNvbnN0cmFpbnRzIi8ib3ItY29uc3RyYWlu dHMiLg0KW1NSICAgICBdIE9LIGFkZGVkIHRoaXMgYWZ0ZXIgMXN0IHBhcmFncmFwaA0KPj4NCj4+ UGxlYXNlIGV4cGxhaW4gdGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRoZSBpbmRleCBmb3IgdGhlICJj b25zdHJhaW50cyIvIm9yLQ0KPj5jb25zdHJhaW50cyIgZXhwcmVzcyBpbiB0aGlzIHNlY3Rpb24g aW4gYWRkaXRpb24gdG8gd2hlcmUgaXQgaXMgaGlkZGVuIGluIGEgbm90ZQ0KPj5sYXRlciBpbiB0 aGUgZG9jdW1lbnQuDQpbU1IgICAgIF0gT0ssIG1vdmVkIHRleHQgdG8gZXhhbXBsZSBpbiBzZWN0 aW9uIDUuNA0KPj4NCj4+U2VjdGlvbiAzLjYuNQ0KPj4NCj4+VXBwZXJjYXNlIGZvciAibXVzdCBu b3QiIGluIHRoZSBzZWNvbmQgcGFyYWdyYXBoLiAgKFRoZSAibWF5IiBsYXRlciBpbiB0aGUNCj4+ cGFyYWdyYXBoIG1pZ2h0IGJlIGJldHRlciBhcyAiY2FuIi4pDQpbU1IgICAgIF0gT0ssIGRvbmUu IEFsc28gYWRkZWQgYW4gc2VudGVuY2UgaW4gMXN0IHBhcmFncmFwaCB0byBjbGFyaWZ5IGl0LiAN Cj4+DQo+PkluIHRoZSBleGFtcGxlLCB0aGUgcmVzb3VyY2UgbmFtZWQgImZpbHRlcmVkLW11bHRp Y29zdC1tYXAiIGlzIHByb3ZpZGVkIGZvcg0KPj5sZWdhY3kgcmVhc29ucyBvbmx5LiAgV2h5IGJv dGhlciBpbmNsdWRpbmcgIm1heC1jb3N0LXR5cGVzIiBhbmQgImNvc3QtdHlwZS0NCj4+bmFtZXMi IGF0IGFsbCB3aGVuICJmaWx0ZXJlZC1jb3N0LW1hcC1leHRlbmRlZCIgaW5jbHVkZXMgYWxsIHRo YXQgYW5kIG1vcmU/DQpbU1IgICAgIF0gT0ssIGJlZm9yZSBleGFtcGxlLCBhZGRlZCB0ZXh0IGV4 cGxhaW5pbmcgd2hlbiBpdCBpcyB1c2VmdWwgdG8gc3BlY2lmeSBib3RoLiANCkFjdHVhbGx5LCAi Y29zdC10eXBlLW5hbWVzIiBpcyBhbHdheXMgcHJlc2VudCBpbiBmaWx0ZXJlZCBjb3N0IG1hcCBj YXBhYmlsaXRpZXMuDQo+Pg0KPj5TZWN0aW9uIDQuMS4xDQo+Pg0KPj5UaGUgZGVmaW5pdGlvbiBv ZiB0aGUgc2NoZW1hIGhlcmUgKGFuZCBsYXRlcikgYWN0dWFsbHkgcmVkZWZpbmVzIHRoZSBvYmpl Y3QNCj4+Y29tcGxldGVseS4gIEkgZm91bmQgdGhhdCBjb25mdXNpbmcgaW5pdGlhbGx5LiAgSXQg d291bGQgYmUgZ29vZCB0byBpZGVudGlmeSB0aGUNCj4+KmNoYW5nZXMqIGZyb20gdGhlIGJhc2Ug c3BlY2lmaWNhdGlvbiBzb21laG93Lg0KW1NSICAgICBdIGluZGVlZC4gSW4gUkZDNzI4NSB7MTEu My4yLjR9LCBtZW1iZXIgImNvc3QtY29uc3RyYWludHMiIGlzIG5vdCBvcHRpb25hbCBpbiBvYmpl Y3Qgc3BlY2lmaWNhdGlvbiBidXQgaXMgb3B0aW9uYWwgaW4gdGhlIG1lbWJlciBkZXNjcmlwdGlv bi4gQWRkZWQgYSBzZW50ZW5jZSBhdCB0aGUgZW5kIG9mIDFzdCBwYXJhZ3JhcGggc3RyZXNzaW5n IHRoZSBwcmVzZW5jZSBvZiB0aGUgMiBuZXcgbWVtYmVyIGxpc3RlZCBpbiB0aGUgYmVnaW5uaW5n IG9mIHRoaXMgcGFyYWdyYXBoLiANCkFsc28gYWRkZWQgc29tZSB0ZXh0IGluIGludHJvZHVjdGlv biBvZiBzZWN0aW9uIDQsIG9uIHRoZSBub3RhdGlvbnMsIGluIHBhcnRpY3VsYXIgIjxtLi5uPiIu IA0KPj4NCj4+Q2FuIHRlc3RhYmxlLWNvc3QtdHlwZS1uYW1lcyBiZSBwcmVzZW50IGFuZCBlbXB0 eSBpZiBjb3N0LWNvbnN0cmFpbnRzIGlzDQo+PmZhbHNlPw0KPj5UaGUgZmlyc3QgcGFydCBvZiB0 aGUgZGVmaW5pdGlvbiBwZXJtaXRzIHRoYXQsIHRoZSBzZWNvbmQgZm9yYmlkcyBpdC4NCltTUiAg ICAgXSBUaGUgZmlyc3QgcGFydCBzcGVjaWZpZXMgbWVtYmVyICJ0ZXN0YWJsZS1jb3N0LXR5cGUt bmFtZXMiIGFzIGhhdmluZyAiPDEuLio+IiBlbGVtZW50cywgaWYgcHJlc2VudC4gIA0KQWRkZWQg aXRlbSB0byBkZXNjcmliZSAiY29zdC1jb25zdHJhaW50cyIgYW5kIG1vdmVkIHRleHQgZnJvbSAi dGVzdGFibGUtY29zdC10eXBlLW5hbWVzIiB0aGVyZS4gDQo+Pg0KPj5TZWN0aW9uIDQuMS4yDQo+ Pg0KPj5UaGUgcmVkZWZpbml0aW9uIG9mIFBJREZpbHRlciBpcyB1bm5lY2Vzc2FyeS4NCltTUiAg ICAgXSBPSywgZGVsZXRlZA0KPj4NCj4+SU1QT1JUQU5UOiBwaWRzIGlzIG9wdGlvbmFsIGluIFJG QyA3Mjg1LiAgV2h5IHRoZSBjaGFuZ2U/DQpbU1IgICAgIF0gT0ssIGNvcnJlY3RlZCB0aGlzLCBw aWRzIG9wdGlvbmFsIGFnYWluLiBUaGFua3MgZm9yIGNhdGNoaW5nIHRoaXMuDQo+Pg0KPj5JIGZp bmQgdGhlIHJlZGVmaW5pdGlvbiBvZiB0aGUgb3B0aW9uYWxpdHkgb2YgY29zdC10eXBlIHRvIGJl IHdvcnRoeSBvZiBzcGVjaWFsDQo+Pm5vdGUuDQpbU1IgICAgIF0gT0ssIGFkZGVkIHNlbnRlbmNl IGluIGRlZmluaXRpb24gb2YgImNvc3QtdHlwZSIgbWVtYmVyDQo+Pg0KPj5JbiB0aGUgZGVmaW5p dGlvbiBvZiAib3ItY29uc3RyYWludHMiLCB5b3UgdXNlIGEgImRhdGFiYXNlIHF1ZXJ5Ig0KPj53 aGVyZSB3b3Jkcw0KPj53b3VsZCBzdWZmaWNlLg0KW1NSICAgICBdIE9LLCByZXBsYWNlZCAiZGF0 YWJhc2UgcXVlcnkiIHdpdGggIndvcmRzIg0KPj4NCj4+U2VjdGlvbiA0LjEuMw0KPj4NCj4+SSBm aW5kIHRoZSBjaG9pY2Ugb2YgdmFsdWUgZm9yICJjb3N0LXR5cGUiIHRvIGJlIHByb2JsZW1hdGlj LiAgSXQgaXMgYSBzdHJpbmcgaW4gdGhlDQo+PmJhc2UgcHJvdG9jb2wsIHNvIGNoYW5naW5nIHRv IGFuIGVtcHR5IG9iamVjdCBpcyBsaWtlbHkgdG8gY2F1c2UgbW9yZSBpc3N1ZXMNCj4+dGhhbiBz aW1wbHkgb21pdHRpbmcgaXQuDQpbU1IgICAgIF0gQWN0dWFsbHksICJjb3N0LXR5cGUiIGlzIGRl ZmluZWQgaW4gezEwLjd9IGFzIGFuIG9iamVjdCB1bmxpa2UgImNvc3QtdHlwZS1uYW1lcyIgd2hp Y2ggaXMgYXJyYXkgb2YgSlNPTlN0cmluZy4NCj4+DQo+PlNlY3Rpb24gNC4yIGNvbnRhaW5zIG1p c21hdGNoZWQgYnJhY2VzL3BhcmVucyBmb3Igc2VjdGlvbiByZWZlcmVuY2VzLg0KW1NSICAgICBd IE9LLCBjb3JyZWN0ZWQNCj4+DQo+PlNlY3Rpb24gNC4yLjINCj4+DQo+PklNUE9SVEFOVDogVGhp cyBwcm92aWRlcyBhIGRlZmluaXRpb24gZm9yIFJlcUZpbHRlcmVkQ29zdE1hcCB0aGF0IGlzIHZl cnkNCj4+ZGlmZmVyZW50IHRvIHRoYXQgaW4gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbi4gIEkgdGhp bmsgdGhhdCB0aGlzIHNob3VsZCBoYXZlIGJlZW4NCj4+UmVxRW5kcG9pbnRDb3N0TWFwLg0KW1NS ICAgICBdIE9LLCBjb3JyZWN0ZWQgdGhpcyBhbmQgcmVwbGFjZWQgIiBSZXFGaWx0ZXJlZENvc3RN YXAgIiB3aXRoICJSZXFFbmRwb2ludENvc3RNYXAiLCB0aGFua3MgZm9yIGNhdGNoaW5nIHRoaXMu DQo+Pg0KPj5BcyBiZWZvcmUsIHJlcGVhdGluZyB0aGUgZGVmaW5pdGlvbiBvZiBFbmRwb2ludEZp bHRlciBpcyB1bm5lY2Vzc2FyeS4NCltTUiAgICAgXSBPSyBkZWxldGVkDQo+Pg0KPj5TZWN0aW9u IDQuMi4zIC0gc2VlIGNvbW1lbnQgb24gNC4xLjMNCltTUiAgICAgXSBPSywgcGxlYXNlIHNlZSBt eSBhbnN3ZXIuDQo+Pg0KPj5TZWN0aW9uIDUNCj4+DQo+Pkkgd291bGQgYmUgbW9yZSBjb21mb3J0 YWJsZSBpZiB0aGUgZXhhbXBsZXMgdXNlZCBvYnZpb3VzbHktc3B1cmlvdXMNCj4+bWV0cmljcyAo ZS5nLiwgImNhdHRsZS1oZWFkLWNvdW50IiwgInNtZWxsIiwgInNob2Utc2l6ZSIsIGV0Yy4uLikg dGhhbiB0aGVzZQ0KPj5tZXRyaWNzIHRoYXQgYXJlIHByZXR0eSBwbGF1c2libGUuICBNb3JlIHNv IHdoZW4geW91IGNsYWltIHRoYXQgdGhleSBhcmUNCj4+d2lkZWx5IHZhbHVlZCwgd2hpY2ggaW1w bGllcyBzb21lIHNvcnQgb2YgdmFsaWRpdHkuDQpbU1IgICAgIF0gT0ssIHJlcGxhY2VkICJob3Bj b3VudCIgd2l0aCAic2hvZXNpemUiIGFuZCAiYmFuZHdpZHRoc2NvcmUiIHdpdGggInNjZW5lcnly YXRlIiBhbmQgYWRhcHRlZCBzZWN0aW9uIGludHJvZHVjdGlvbiBhY2NvcmRpbmdseS4gDQo+Pg0K Pj5JdCBzaG91bGQgYmUgcmVsYXRpdmVseSBlYXN5IHRvIHBvcHVsYXRlIENvbnRlbnQtTGVuZ3Ro IG5vdyB0aGF0IHRoZQ0KPj5leGFtcGxlcyBhcmUgImZpbmFsIi4NCltTUiAgICAgXSBPSywgZG9u ZQ0KPj4NCj4+U2VjdGlvbiA1LjENCj4+DQo+PllvdSBoYXZlIHVubWF0Y2hlZCBicmFjZXMgaW4g Im1ldGEiIGR1ZSB0byB0aGUgY29tbWVudC4NCltTUiAgICAgXSBPSywgY29ycmVjdGVkIHRoaXMu IEFsc28gcmVtb3ZlZCB0aGUgY29tbWVudHMgaW4gdGhlIElSRA0KPj4NCj4+U2VjdGlvbiA1LjIN Cj4+DQo+PkRvIHlvdSB3YW50IHRvIHNob3cgb25lIG9mIHRoZSBleGFtcGxlcyBhcyBoYXZpbmcg bm8gY29zdCB2YWx1ZXMgYXQgYWxsDQo+PmFjcm9zcyBhbGwgdGhlIGNvc3QgdHlwZXM/DQpbU1Ig ICAgIF0gT0ssIHVwZGF0ZWQgdGV4dCB0byBzYXkgdGhpcyBvbmx5IGhvbGRzIGJldHdlZW4gUElE MiBhbmQgUElEMw0KPj4NCg0K From nobody Tue Apr 25 12:01:28 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C700913178B; Tue, 25 Apr 2017 12:01:20 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2qMWII5vINR; Tue, 25 Apr 2017 12:01:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3EB13178D; Tue, 25 Apr 2017 12:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3PJ014b017046; Tue, 25 Apr 2017 21:00:01 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCCFX5KBpzDJ5m; Tue, 25 Apr 2017 21:00:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 25 Apr 2017 20:59:59 +0200 Cc: Herbert Van de Sompel , art@ietf.org, draft-ietf-core-links-json.all@ietf.org, IETF , "core@ietf.org WG" , Erik Wilde X-Mao-Original-Outgoing-Id: 514839599.587282-cfed82419b35f701b30329893f680c6a Content-Transfer-Encoding: quoted-printable Message-Id: <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> To: Julian Reschke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:01:21 -0000 On Apr 25, 2017, at 18:46, Julian Reschke wrote: >=20 > Do you have a specific problem in mind? This work was done half a decade ago (May 18, 2012, that is), so I = don=E2=80=99t remember all the details. RFC 6690 says: In order to convert an HTTP Link Header field to this link format, first the "Link:" HTTP header is removed, any linear whitespace (LWS) is removed, the header value is converted to UTF-8, and any percent- encodings are decoded. So we get rid of all that fun before it becomes RFC 6690 (and CoAP of = course is all UTF-8 in any case). So far, we have run into one real case where that approach is a = limitation, and that is in URIs: The link coap://example.com?stupid%3Dkey=3D4711 is not distinguishable from coap://example.com?stupid=3Dkey=3D4711 (The typical reaction of an implementer is =E2=80=9Cthen don=E2=80=99t = do that!=E2=80=9D [1,2].) We know that because the CoAP protocol itself also completely runs in = the UTF-8 domain (there is no percent encoding on the wire); I=E2=80=99m = not sure that simplification actually hurt in RFC 6690 use cases yet. (Note that it is rather likely to see user-visible strings in DNS-SD = instance names, which turn into =E2=80=9Cins=E2=80=9D link attributes, = so this is not only a URI/IRI/WVUS [3] issue.) We don=E2=80=99t have a lot of experience with lingering legacy charsets = in HTTP headers in the constrained space, so I=E2=80=99m sure there are = other side effects. Gr=C3=BC=C3=9Fe, Carsten [1]: = http://www.condenaststore.com/-sp/Then-don-t-do-that-New-Yorker-Cartoon-Pr= ints_i14788077_.htm [2]: http://www.catb.org/~esr/jargon/html/D/Don-t-do-that-then-.html [3]: https://url.spec.whatwg.org/#valid-url-string (WHATWG Valid URL = String, or WVUS for short) From nobody Tue Apr 25 13:09:44 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31651294BD; Tue, 25 Apr 2017 13:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO3d1RO-ttsv; Tue, 25 Apr 2017 13:09:41 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822F2128CD5; Tue, 25 Apr 2017 13:09:41 -0700 (PDT) Received: from homiemail-a42.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTP id E59779018A3E; Tue, 25 Apr 2017 13:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=768msT/pCVcCIOXkVMHTvPXcNI8=; b=HKj2hRl35LJd8eNI/Hrp1nCP1VC9 LA29bFPPLMxkvx2idjdYgDl1FscwyCbzj6ZyJ98EuSGm9va3KYzrUeT0r47PUZll Zh8l3Hi600mLG6qa4rHfcx8ezTsK3heIvhmXm8KFD+tTPKSAM27Z2FeUCKP5ycJ6 McWkBzelJXKWWPQ= Received: from [192.168.1.8] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTPSA id ADC1C9018A3C; Tue, 25 Apr 2017 13:09:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> Date: Tue, 25 Apr 2017 13:09:40 -0700 Cc: Julian Reschke , IETF , art@ietf.org, draft-ietf-core-links-json.all@ietf.org, "core@ietf.org WG" , Erik Wilde , Herbert Van de Sompel Content-Transfer-Encoding: quoted-printable Message-Id: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 20:09:43 -0000 > On Apr 25, 2017, at 11:59 AM, Carsten Bormann wrote: >=20 > On Apr 25, 2017, at 18:46, Julian Reschke = wrote: >>=20 >> Do you have a specific problem in mind? >=20 > This work was done half a decade ago (May 18, 2012, that is), so I = don=E2=80=99t remember all the details. > RFC 6690 says: >=20 > In > order to convert an HTTP Link Header field to this link format, = first > the "Link:" HTTP header is removed, any linear whitespace (LWS) is > removed, the header value is converted to UTF-8, and any percent- > encodings are decoded. Well, that's broken. > So we get rid of all that fun before it becomes RFC 6690 (and CoAP of = course is all UTF-8 in any case). >=20 > So far, we have run into one real case where that approach is a = limitation, and that is in URIs: >=20 > The link >=20 > coap://example.com?stupid%3Dkey=3D4711 >=20 > is not distinguishable from >=20 > coap://example.com?stupid=3Dkey=3D4711 >=20 > (The typical reaction of an implementer is =E2=80=9Cthen don=E2=80=99t = do that!=E2=80=9D [1,2].) That isn't a "limitation". It's a bug to decode pct-encoded octets in a URI before decomposing the reference into its parts. ASCII is already in UTF-8. Decoding a pct-encoding doesn't make it "more UTF-8"; it just means the string is no longer a URI reference. That's broken. So = utterly broken that it obviously wasn't reviewed by the right people. > We know that because the CoAP protocol itself also completely runs in = the UTF-8 domain (there is no percent encoding on the wire); I=E2=80=99m = not sure that simplification actually hurt in RFC 6690 use cases yet. *sigh* ....Roy From nobody Tue Apr 25 14:26:58 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1670D129436; Tue, 25 Apr 2017 14:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTWt0hOQbt53; Tue, 25 Apr 2017 14:26:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446DA126B6E; Tue, 25 Apr 2017 14:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3PLPnO8005255; Tue, 25 Apr 2017 23:25:49 +0200 (CEST) Received: from client-0139.vpn.uni-bremen.de (client-0139.vpn.uni-bremen.de [134.102.107.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCGTn2MXhzDJ7X; Tue, 25 Apr 2017 23:25:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 25 Apr 2017 23:25:48 +0200 Cc: IETF , Julian Reschke , art@ietf.org, Herbert Van de Sompel , "core@ietf.org WG" , Erik Wilde , draft-ietf-core-links-json.all@ietf.org X-Mao-Original-Outgoing-Id: 514848348.452778-61494f675340a082fab68f2a595dd329 Content-Transfer-Encoding: quoted-printable Message-Id: <26C26E7B-24E1-4982-B3D8-9991AA1CC6DF@tzi.org> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> To: "Roy T. Fielding" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:26:51 -0000 >> RFC 6690 says: >>=20 >> In >> order to convert an HTTP Link Header field to this link format, = first >> the "Link:" HTTP header is removed, any linear whitespace (LWS) is >> removed, the header value is converted to UTF-8, and any percent- >> encodings are decoded. >=20 > Well, that's broken. OK, let me start typing that errata report then. >> coap://example.com?stupid%3Dkey=3D4711 >>=20 >> is not distinguishable from >>=20 >> coap://example.com?stupid=3Dkey=3D4711 >>=20 >> (The typical reaction of an implementer is =E2=80=9Cthen don=E2=80=99t = do that!=E2=80=9D [1,2].) >=20 > That isn't a "limitation=E2=80=9D. =20 For RFC6690 users, it pretty much is, because certain URIs don=E2=80=99t = work. They tend to design their URIs in such a way that they do, probably more = so because these designs are natural for them than because they are = fully aware of that limitation. > It's a bug to decode pct-encoded octets in > a URI before decomposing the reference into its parts. =20 Well, percent-encoding is playing two roles in RFC 3986: hiding = characters within syntactic elements from their delimiter roles, and = encoding non-ASCII (and C0 etc.) characters. The passage I cited from RFC 6690 got nicely rid of the latter, and = broke the former(*). > ASCII is already > in UTF-8. Decoding a pct-encoding doesn't make it "more UTF-8"; it = just > means the string is no longer a URI reference. That's broken. So = utterly > broken that it obviously wasn't reviewed by the right people. So what should I write into the errata report? Or more generally speaking, how should we fix RFC 6690, without creating = a need for constrained nodes to do full URI processing? Maybe it is sufficient to document the limitation in the errata, for = now? And, more to the point of the subject line, how should we handle this on = the JSON/CBOR level? There definitely will be a round-tripping problem with RFC 6690 if the = URIs collide with the above limitation of RFC 6690. But that=E2=80=99s = OK because that defines the subset. To be more general, not doing any percent-decoding of URIs when creating = JSON/CBOR from scratch is probably the easy way, but it means that when = we want to phase out RFC 6690 on the constrained level by replacing it = with JSON/CBOR, there is additional complexity. Horribile dictu, but = maybe IRIs are the right thing to do here. Gr=C3=BC=C3=9Fe, Carsten (*) It may be worth pointing out that the amount of breakage here is = much larger than for CoAP itself, which does the percent-decoding only = after decomposing a URI into what CoAP considers to be its components, = so the URI parsing works properly =E2=80=94 coap://example.com/foo%2fbar = has one path segment, =E2=80=9Cfoo/bar=E2=80=9D. But the application semantics of hiding application delimiters, which my = example above is breaking, is not supported in CoAP either. Some people think that URIs should be carried around in that decomposed = form throughout the constrained space, and I can=E2=80=99t blame them. I don=E2=80=99t have data how many URI libraries in active use in the = non-constrained space get this particular detail right, either. From nobody Tue Apr 25 23:39:34 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C9B13186C; Tue, 25 Apr 2017 23:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3JY-jIw2wGo; Tue, 25 Apr 2017 23:39:24 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E808013186A; Tue, 25 Apr 2017 23:39:09 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id t144so102422483lff.1; Tue, 25 Apr 2017 23:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/D9VKNVJ8QYkQ89Mo4kvOhkroqt7wfnupPkMcBMphpM=; b=Jz8mQqFcl34Ll+z5XLE7rbIftbfdbZS6fBfLRzu5jjHYLIz/jqGfVi4B//sJBiwDDW 8Uha1ZH2bb3uCra5OI0zDVjjcRf7PI19rjC87MGOtvacgDzMsTe5bipWBXMmqXPKFPH/ QTW3EiTTFu4O48Bs9eZFeGNKCZ71IKieCdqNHfb3njAtT3ylWhC/DFF3VkyLF3zXlOBu YPuTBwVkW43H7aFyck6h1SPhzcXCaE3xU+TRZhZSP+IjQSPFncU1WWo0n7J8YEI5ANQO PAb+ks0UsCY2j0gNtqJRE7Fc5f1wg6pd/r3FJIJgMDGZ779p0kto0/tgeF4whyUbSkJe NWuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/D9VKNVJ8QYkQ89Mo4kvOhkroqt7wfnupPkMcBMphpM=; b=SdOWT44ImTPLWeWIAW1DrxPhJQn5gXH9Wc60ZaUaFjae8tHrR3FyUZ159MPCGr96sI WQZMC95ifedjE4jbdei+2YNyQ2OHpUD48aZ4mayiPMjj9ltp05qr/P48Sa3mXU8s+ti0 3EhIpxGHQHlMOqQ4fYfzZlb6g2hzPkj3j9p1dZagxqAN5y/lwl7KhNfxL58ujnyEdpR7 OSae5wqvIatNBeMI4aE1Jtp13WuXD6ZiY1tXa8XQL+jnnN+nhUq8zVi8QN5Zz/auisbe Jh7Aoxr7a4+XvbauxP3bN1Y+ADm55ALVdEZtR8ymZAIH9Wdez+s+SxmsNYfFdT7qV2iG /Jwg== X-Gm-Message-State: AN3rC/5Vk8PibYXVTQZhO5HGoLAS/e86plMu1OHlHPRLIJfgZiOE/rtv L0hwZV2rXyGutELMWxZSz6cGBrycmw== X-Received: by 10.46.21.2 with SMTP id s2mr2644800ljd.50.1493188748139; Tue, 25 Apr 2017 23:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 25 Apr 2017 23:39:07 -0700 (PDT) In-Reply-To: References: <149144445494.22036.11923880719369865745@ietfa.amsl.com> From: Martin Thomson Date: Wed, 26 Apr 2017 16:39:07 +1000 Message-ID: To: "Randriamasy, Sabine (Nokia - FR/Nozay)" Cc: "art@ietf.org" , "alto@ietf.org" , "ietf@ietf.org" , "draft-ietf-alto-multi-cost.all@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-alto-multi-cost-08 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 06:39:26 -0000 On 26 April 2017 at 03:26, Randriamasy, Sabine (Nokia - FR/Nozay) wrote: >>>This document doesn't cite RFC 2119, but it uses the keywords. > [SR ] RFC 2119 is cited on page 1, section " Requirements Language" and section "9.1. Normative References". Should it be referenced elsewhere? The convention is to put those in the body, I missed it in the boilerplate. I skimmed the other changes, and they look fine. From nobody Wed Apr 26 00:38:26 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A44131C14; Wed, 26 Apr 2017 00:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydjtCvy3xHff; Wed, 26 Apr 2017 00:38:22 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40125.outbound.protection.outlook.com [40.107.4.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C91A131C13; Wed, 26 Apr 2017 00:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YWcG7kBnAZ52eR+8yImeRnsbwaN4vcuIn+Rp8Sy8ydg=; b=Lw9frEDq4sb/gfbUVjd1dyDgYvaNf+ZK6FpRHLMeFHZfMSOMUrtvgEmVLJWMaCaq5DAdtIa2rdyfnoghDL+SPd8RsRQw5xJYe3sg3wkbGtL+JW07kAmpX5wu76RviYxpUIt0AjZmz2AkS/MzhdopvSgNsPOddqIGQ6Kp84IwEf4= Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) by DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Wed, 26 Apr 2017 07:38:20 +0000 Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) by DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) with mapi id 15.01.1061.011; Wed, 26 Apr 2017 07:38:20 +0000 From: "Randriamasy, Sabine (Nokia - FR/Nozay)" To: Martin Thomson CC: "art@ietf.org" , "alto@ietf.org" , "ietf@ietf.org" , "draft-ietf-alto-multi-cost.all@ietf.org" Thread-Topic: Artart telechat review of draft-ietf-alto-multi-cost-08 Thread-Index: AQHSrnqQeK8CFgpYuE64kjZYAubM4qHWYMDggADx5oCAABAUYA== Date: Wed, 26 Apr 2017 07:38:19 +0000 Message-ID: References: <149144445494.22036.11923880719369865745@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [86.242.114.166] x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2454; 7:KwlDfJIPf1h3NQKPXcDX90PdAateKyw4hKoNjPM52eewKxmGTrOqGzZ8JhmcUWizbLR2i1rL7irxIjsnrs/60GUklqPP6O0JwPwwb2S/SgR9OWpe72a+UwE71s7OSBXsV6zS0As0/rf5LOh2AagNRD8QSTXvZRS+toNaGs1Sr7BTxSnSLUeX5e/R1V28k9P35kwZzl0nBLEcS34F8xh59oJWCPSwxR4vqvURw8MbhAC/Hg7mqyI7nMyE6EYDppAhu0V1Lk/I1Fmur13UbJVq4Ns64WlZLXmOM2xlR3AeujtR+5e9kZn/qVnHVU1kQlMZfvrbsqXJdEls3CWW6VCC8w== x-ms-office365-filtering-correlation-id: d644fa95-8177-4d45-40ea-08d48c773609 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB6PR0701MB2454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148); SRVR:DB6PR0701MB2454; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2454; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39400400002)(39410400002)(39850400002)(39840400002)(13464003)(24454002)(8936002)(5660300001)(55016002)(54906002)(99286003)(2906002)(8676002)(77096006)(68736007)(81166006)(3280700002)(38730400002)(6506006)(74316002)(305945005)(9686003)(39060400002)(7736002)(81156014)(3660700001)(6436002)(4326008)(33656002)(53936002)(122556002)(2950100002)(6916009)(3846002)(6116002)(102836003)(25786009)(230783001)(2900100001)(50986999)(229853002)(76176999)(54356999)(7696004)(6246003)(66066001)(189998001)(110136004)(86362001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2454; H:DB6PR0701MB2454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 07:38:19.9984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2454 Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-alto-multi-cost-08 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 07:38:24 -0000 SGVsbG8gTWFydGluLA0KDQpUaGFua3MsIEknbGwgdXBkYXRlIHdpdGggUkZDIDIxMTkgY2l0ZWQg YXQgYXBwcm9wcmlhdGUgcGxhY2VzIA0KU2FiaW5lDQoNCg0KPj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj5Gcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbV0NCj4+U2VudDogMjYgQXByaWwgMjAxNyAwODozOQ0KPj5UbzogUmFuZHJpYW1hc3ks IFNhYmluZSAoTm9raWEgLSBGUi9Ob3pheSkgPHNhYmluZS5yYW5kcmlhbWFzeUBub2tpYS0NCj4+ YmVsbC1sYWJzLmNvbT4NCj4+Q2M6IGFydEBpZXRmLm9yZzsgYWx0b0BpZXRmLm9yZzsgaWV0ZkBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1hbHRvLW11bHRpLQ0KPj5jb3N0LmFsbEBpZXRmLm9yZw0KPj5T dWJqZWN0OiBSZTogQXJ0YXJ0IHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLWFsdG8tbXVs dGktY29zdC0wOA0KPj4NCj4+T24gMjYgQXByaWwgMjAxNyBhdCAwMzoyNiwgUmFuZHJpYW1hc3ks IFNhYmluZSAoTm9raWEgLSBGUi9Ob3pheSkNCj4+PHNhYmluZS5yYW5kcmlhbWFzeUBub2tpYS1i ZWxsLWxhYnMuY29tPiB3cm90ZToNCj4+Pj4+VGhpcyBkb2N1bWVudCBkb2Vzbid0IGNpdGUgUkZD IDIxMTksIGJ1dCBpdCB1c2VzIHRoZSBrZXl3b3Jkcy4NCj4+PiBbU1IgICAgIF0gUkZDIDIxMTkg aXMgY2l0ZWQgb24gcGFnZSAxLCBzZWN0aW9uICIgUmVxdWlyZW1lbnRzIExhbmd1YWdlIiBhbmQN Cj4+c2VjdGlvbiAiOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMiLiBTaG91bGQgaXQgYmUgcmVm ZXJlbmNlZCBlbHNld2hlcmU/DQo+Pg0KPj5UaGUgY29udmVudGlvbiBpcyB0byBwdXQgdGhvc2Ug aW4gdGhlIGJvZHksIEkgbWlzc2VkIGl0IGluIHRoZSBib2lsZXJwbGF0ZS4NCj4+DQo+Pkkgc2tp bW1lZCB0aGUgb3RoZXIgY2hhbmdlcywgYW5kIHRoZXkgbG9vayBmaW5lLg0K From nobody Wed Apr 26 08:52:52 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00FE131476; Wed, 26 Apr 2017 08:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHfLtRPALlI5; Wed, 26 Apr 2017 08:52:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BED131460; Wed, 26 Apr 2017 08:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3QFpku5028088; Wed, 26 Apr 2017 17:51:46 +0200 (CEST) Received: from client-0227.vpn.uni-bremen.de (client-0227.vpn.uni-bremen.de [134.102.107.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wCl1s6lR2zDH15; Wed, 26 Apr 2017 17:51:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <26C26E7B-24E1-4982-B3D8-9991AA1CC6DF@tzi.org> Date: Wed, 26 Apr 2017 17:51:45 +0200 Cc: IETF , Julian Reschke , art@ietf.org, draft-ietf-core-links-json.all@ietf.org, "core@ietf.org WG" , Erik Wilde , Herbert Van de Sompel X-Mao-Original-Outgoing-Id: 514914705.088075-62d7dcc2c4f9f617e52eb3a25c091a6c Content-Transfer-Encoding: quoted-printable Message-Id: References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> <26C26E7B-24E1-4982-B3D8-9991AA1CC6DF@tzi.org> To: "Roy T. Fielding" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:52:51 -0000 On Apr 25, 2017, at 23:25, Carsten Bormann wrote: >=20 > OK, let me start typing that errata report then. Below is a draft errata report. Is this information correct? Is it sufficient? Obviously, this errata report doesn=E2=80=99t by itself answer the = important questions raised about links-json, but it might be a useful = outcome of this discussion anyway. Gr=C3=BC=C3=9Fe, Carsten Report Errata for RFC6690 Date: 2017-04-26 Name: Carsten Bormann Email: cabo@tzi.org Type: Editorial Section: 2 Original Text: [...] In order to convert an HTTP Link Header field to this link format, first the "Link:" HTTP header is removed, any linear whitespace (LWS) is removed, the header value is converted to UTF-8, and any percent- encodings are decoded. Corrected Text: (add after unchanged original text:) Note that this percent-decoding damages URIs that percent-encode reserved characters (i.e., characters out of ":/?#[]@!$&'()*+,;=3D", not including the double quotes). Such URIs therefore generally cannot be successfully used with RFC 6690 link-format. Notes: Fully percent-decoding URIs before placing them into the link-format reduces complexity in processing link-format, but creates a limitation on the set of URIs that link-format faithfully can represent. This may not be as widely known as is desirable, creating a pitfall for unwitting users of RFC 6990. From nobody Wed Apr 26 14:37:52 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49A1292CE; Wed, 26 Apr 2017 14:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXoZCa_LWWsv; Wed, 26 Apr 2017 14:37:42 -0700 (PDT) Received: from homiemail-a121.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B37912709D; Wed, 26 Apr 2017 14:37:42 -0700 (PDT) Received: from homiemail-a121.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a121.g.dreamhost.com (Postfix) with ESMTP id CB86F60001A09; Wed, 26 Apr 2017 14:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=kTIV2paK+Y/7/+g0K87Ygnu4MQU=; b=BqwGNUhv3uZYNaYSBiQb63Bk6WRC NXP3WFn5IB2klpPiHQ8MQtHOugvE/9zovU3en5vfRPgEZuYx3YiDAosgh0vjO9aZ fiL0/EcM2sL520MlTYQCWTbhpfgHfyalY2lxmDtrxUYHHtLM9NkrFjpb2gEeTr3o L4Pp/6U5bd3EhHo= Received: from [192.168.1.8] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a121.g.dreamhost.com (Postfix) with ESMTPSA id 103D360001104; Wed, 26 Apr 2017 14:37:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: Date: Wed, 26 Apr 2017 14:37:40 -0700 Cc: IETF , Julian Reschke , art@ietf.org, Herbert Van de Sompel , "core@ietf.org WG" , Erik Wilde , draft-ietf-core-links-json.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8E2E3319-0540-441C-A2D3-2325FBE199D9@gbiv.com> References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org> <26C26E7B-24E1-4982-B3D8-9991AA1CC6DF@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:37:44 -0000 > On Apr 26, 2017, at 8:51 AM, Carsten Bormann wrote: >=20 > On Apr 25, 2017, at 23:25, Carsten Bormann wrote: >>=20 >> OK, let me start typing that errata report then. >=20 > Below is a draft errata report. >=20 > Is this information correct? No. An RFC that isn't interoperable (in this case, because it contradicts its own normative references) is a design error. I don't agree with the entire contents of RFC6690. The abstract alone = is enough for me to drop it in the nearest recycling bin; the design has nothing to do with REST (an architectural style, not an architecture). Nevertheless, the error (a non-interoperable design error) in RFC6690 is = in section 4.1. It is either a bad URI template (if the examples are = correct) or a bad description of how to process that template. /.well-known/core{?search*} RFC6570 requires that the above template's values be pct-encoded during expansion, so the examples given in 4.1: The following are examples of valid query URIs: o ?href=3D/foo matches a link-value that is anchored at /foo o ?href=3D/foo* matches a link-value that is anchored at a URI that starts with /foo o ?foo=3Dbar matches a link-value that has a target attribute named foo with the exact value bar o ?foo=3Dbar* matches a link-value that has a target attribute named foo, the value of which starts with bar, e.g., bar or barley o ?foo=3D* matches a link-value that has a target attribute named foo are almost all wrong. They would have to be The following are examples of valid query URIs: o ?href=3D%2Ffoo matches a link-value that is anchored at /foo o ?href=3D%2Ffoo%2A matches a link-value that is anchored at a URI = that starts with /foo o ?foo=3Dbar matches a link-value that has a target attribute named foo with the exact value bar o ?foo=3Dbar%2A matches a link-value that has a target attribute = named foo, the value of which starts with bar, e.g., bar or barley o ?foo=3D%2A matches a link-value that has a target attribute named = foo Alternatively, if the examples are correct, the specification needs to = replace the above URI template with a more accurate list of such templates to = match the examples: /.well-known/core /.well-known/core?href=3D{+reference} /.well-known/core?anchor=3D{+anchor} /.well-known/core?type=3D{+mt} /.well-known/core{?rel} /.well-known/core{?rev} /.well-known/core{?hreflang} /.well-known/core{?media} /.well-known/core{?title} /.well-known/core{?rt} /.well-known/core{?if} /.well-known/core{?sz} /.well-known/core{?link-extension*} /.well-known/core?href=3D{+reference}* /.well-known/core?anchor=3D{+anchor}* /.well-known/core?type=3D{+mt}* /.well-known/core{?rel}* /.well-known/core{?rev}* /.well-known/core{?hreflang}* /.well-known/core{?media}* /.well-known/core{?title}* /.well-known/core{?rt}* /.well-known/core{?if}* /.well-known/core{?sz}* /.well-known/core{?link-extension*}* ... [note that this still has an ambiguity problem for href string values that happen to end in "*"] and then the text in 4.1 should be fixed as well: Original Text: Value Strings are percent-decoded ([RFC3986], Section 2.1) before matching; similarly, Corrected Text: Value Strings for the href, anchor, and type attributes (reserved = templates) are not percent-decoded ([RFC3986], Section 2.1) before matching; for all other templates, Value Strings are percent-decoded only once before matching; note that a value which originally contained a percent-encoded triplet of "%20" would be encoded as "%2520" by a non-reserved template expansion and restored here as "%20". = Similarly, The above would make RFC6690 consistent with its normative references. A more sensible design would separate the response format (which is fine as a media type) from the query syntax (which doesn't need to be limited to link attributes anyway). ....Roy From nobody Thu Apr 27 04:57:43 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFE31293F5; Thu, 27 Apr 2017 04:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLQnJM0TLsoO; Thu, 27 Apr 2017 04:57:26 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10130.outbound.protection.outlook.com [40.107.1.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8D8120724; Thu, 27 Apr 2017 04:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O76leYrZmQuaQ8966PcOihX9I+7vjTPVi8SpcRI1H10=; b=MK8vmr22KAH2g613KMrJ3mscdzBR4BexPu9P8giES5xtcx+hU/JXfLaG4oCIC7/0TMBL9c+FtR5vflMWRgS0HxIsdiwud04LDXLz0Xz6UFZsioH4wKK2OO/8Y1isqJYEGsk/TZa+EQKvmt/r14DuNETjax51nr8stoicRbXqcJI= Received: from HE1PR0701MB2459.eurprd07.prod.outlook.com (10.168.128.141) by HE1PR0701MB2459.eurprd07.prod.outlook.com (10.168.128.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Thu, 27 Apr 2017 11:57:22 +0000 Received: from HE1PR0701MB2459.eurprd07.prod.outlook.com ([10.168.128.141]) by HE1PR0701MB2459.eurprd07.prod.outlook.com ([10.168.128.141]) with mapi id 15.01.1061.013; Thu, 27 Apr 2017 11:57:22 +0000 From: "Randriamasy, Sabine (Nokia - FR/Nozay)" To: Martin Thomson CC: "art@ietf.org" , "alto@ietf.org" , "ietf@ietf.org" , "draft-ietf-alto-multi-cost.all@ietf.org" Thread-Topic: Artart telechat review of draft-ietf-alto-multi-cost-08 Thread-Index: AQHSrnqQeK8CFgpYuE64kjZYAubM4qHWYMDggADx5oCAAeoBoA== Date: Thu, 27 Apr 2017 11:57:22 +0000 Message-ID: References: <149144445494.22036.11923880719369865745@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.212.18] x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2459; 7:yy2XgWH2l6d2Oe8cFawc5PdzNrntO4PqbpmhY/9ytE19vWvC/EkEhtlafQ/9nUStgUq7lBkZTuXOo559+aW8Z3xxAHJAC9K9rz3jlvJHSmgJdUr7X85l7fPdlAjRmRXK5Olx1QarrAeC2rsiPN0rQ4ToP5V7PDFGfbQfntAlynvQaFsaXlowJfAcg9xQ1zIWb2Rdo3uxcnEiZFzn4xbulrYPcJcECnaSutvHz9B42ewSqbA4bFzd8McnMgW6bg/nc5HvlzGHIdH3KpIzScLvV5TuzuJA7G1hJ4ptuJUDf0QSurtnmewHnUb/FkSOnuo5NlxtT/gUefzwMCjjBEKauw== x-ms-office365-filtering-correlation-id: 732930a5-f84f-48b6-6b5e-08d48d649096 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:HE1PR0701MB2459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:HE1PR0701MB2459; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2459; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39860400002)(39410400002)(39840400002)(39400400002)(24454002)(13464003)(6246003)(74316002)(305945005)(77096006)(38730400002)(110136004)(229853002)(230783001)(6116002)(3846002)(102836003)(6436002)(7696004)(6506006)(7736002)(8936002)(2906002)(81166006)(8676002)(33656002)(4326008)(25786009)(5660300001)(3660700001)(3280700002)(39060400002)(2950100002)(6916009)(9686003)(6306002)(189998001)(122556002)(2900100001)(53936002)(54906002)(99286003)(55016002)(66066001)(54356999)(106356001)(76176999)(50986999)(86362001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2459; H:HE1PR0701MB2459.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 11:57:22.6644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2459 Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-alto-multi-cost-08 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 11:57:29 -0000 SGVsbG8gTWFydGluLA0KDQpJIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZSB3aGVyZSB0aGUgIiBSZXF1 aXJlbWVudHMgTGFuZ3VhZ2UiIHRleHQgaGFzIGJlZW4gbW92ZWQgaW4gYSBzZWN0aW9uIDEuMS4N CkFzIEkgc2F3IGl0IG9uIGEgbnVtYmVyIG9mIG90aGVyIGlldGYgZHJhZnRzLCBJIGFsc28gYWRk ZWQgdGhlIHNlbnRlbmNlIA0KIldoZW4gdGhlIHdvcmRzIGFwcGVhciBpbiBsb3dlciBjYXNlLCB0 aGVpciBuYXR1cmFsIGxhbmd1YWdlIG1lYW5pbmcgaXMgdXNlZC4iDQoNClRoZSB1cGRhdGUgYW5k IHN0YXR1cyBhcmUgYXZhaWxhYmxlIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtYWx0by1tdWx0aS1jb3N0Lw0KDQpUaGFua3MsDQpTYWJpbmUNCg0KDQo+Pi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86 bWFydGluLnRob21zb25AZ21haWwuY29tXQ0KPj5TZW50OiAyNiBBcHJpbCAyMDE3IDA4OjM5DQo+ PlRvOiBSYW5kcmlhbWFzeSwgU2FiaW5lIChOb2tpYSAtIEZSL05vemF5KSA8c2FiaW5lLnJhbmRy aWFtYXN5QG5va2lhLQ0KPj5iZWxsLWxhYnMuY29tPg0KPj5DYzogYXJ0QGlldGYub3JnOyBhbHRv QGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLWFsdG8tbXVsdGktDQo+PmNvc3Qu YWxsQGlldGYub3JnDQo+PlN1YmplY3Q6IFJlOiBBcnRhcnQgdGVsZWNoYXQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtYWx0by1tdWx0aS1jb3N0LTA4DQo+Pg0KPj5PbiAyNiBBcHJpbCAyMDE3IGF0IDAz OjI2LCBSYW5kcmlhbWFzeSwgU2FiaW5lIChOb2tpYSAtIEZSL05vemF5KQ0KPj48c2FiaW5lLnJh bmRyaWFtYXN5QG5va2lhLWJlbGwtbGFicy5jb20+IHdyb3RlOg0KPj4+Pj5UaGlzIGRvY3VtZW50 IGRvZXNuJ3QgY2l0ZSBSRkMgMjExOSwgYnV0IGl0IHVzZXMgdGhlIGtleXdvcmRzLg0KPj4+IFtT UiAgICAgXSBSRkMgMjExOSBpcyBjaXRlZCBvbiBwYWdlIDEsIHNlY3Rpb24gIiBSZXF1aXJlbWVu dHMgTGFuZ3VhZ2UiIGFuZA0KPj5zZWN0aW9uICI5LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyIu IFNob3VsZCBpdCBiZSByZWZlcmVuY2VkIGVsc2V3aGVyZT8NCj4+DQo+PlRoZSBjb252ZW50aW9u IGlzIHRvIHB1dCB0aG9zZSBpbiB0aGUgYm9keSwgSSBtaXNzZWQgaXQgaW4gdGhlIGJvaWxlcnBs YXRlLg0KPj4NCj4+SSBza2ltbWVkIHRoZSBvdGhlciBjaGFuZ2VzLCBhbmQgdGhleSBsb29rIGZp bmUuDQo=