From nobody Thu Aug 3 02:03:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBE8132325 for ; Thu, 3 Aug 2017 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EiRkFNN3nNiu for ; Thu, 3 Aug 2017 02:03:16 -0700 (PDT) Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 8A4A813217A for ; Thu, 3 Aug 2017 02:03:16 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:203]) by smtp-cloud8.xs4all.net with ESMTPA id dC2EdhZ5cDnvndC2EddhJy; Thu, 03 Aug 2017 11:03:14 +0200 Received: from 2001:983:a264:1:f466:d75:d6b5:f041 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 03 Aug 2017 11:03:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 Aug 2017 11:03:13 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfJ5zb2UnHfF+FD7upfzBfOR4/yLSsPv0YoQm2wRahtZ0TEO/1/d81pW11rkeZiCfExHZAui7eRcdIQF9WvprempG1gneZN0svZi/k3/6QbQilqOL4cm8 RUzQRd2m0I/rSoflBsnYCllH1CS7VwFpIQZgf3vVkmKm6t6FuNtNDi3y8Vsaq6zQJqKqK91AjnjUXVgyfT4EzEKtOjq9NnNog70= Archived-At: Subject: [core] relation between EDHOC and OSCOAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 09:03:19 -0000 Hi all, Possibly there has been already a discussion on the relation between the drafts selander-ace-cose-edhce (EDHOC) and ietf-core-object-security (OSCOAP). In that case my apologies. If I understand correctly, EDHOC together with OSCOAP provide security at the application layer, using COSE, the same way as DTLS and TLS do at the transport layer by creating a common secret and using that for the communication. OSCOAP draft describes that an alternative to EDHOC can be provided by using the proposed oauth-authz protocol. That alternative to EDHOC, in my understanding, motivates the separation of the two drafts: EDHOC and OSCOAP. However, I assume that a browser that supports coaps by using OSCOAP instead of DTLS, will also use EDHOC. For 6tisch the EALS protocol, described in selander-ace-eals, also uses both protocols EDHOC and OSCOAP. In OSCOAP the importance of EDHOC to OSCOAP is described, but the EDHOC draft summarily refers to OSCOAP and then uses it for the implementation. Unless my understanding is completely wrong, may I suggest that both drafts provide normative references to each other and explain this tight coupling. A logic consequence is then that both drafts form a package to be brought to RFC together. Looking forward to being corrected, Peter -- Peter van der Stok From nobody Fri Aug 4 07:56:33 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956D132398 for ; Fri, 4 Aug 2017 07:56:30 -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 KS3phtYtWhQm for ; Fri, 4 Aug 2017 07:56:29 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 A586713217D for ; Fri, 4 Aug 2017 07:56:28 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id t128so8095370lff.2 for ; Fri, 04 Aug 2017 07:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2Fk5jBv7Mp4Xm7U73cdiP5KH8bkKQeujrss5w4cxHHo=; b=f2pzJu46kvx10gTyU4olMdLu6qL0S+qeimzsVM3DYbiNNICfu5227q5vxtiQCy67O3 yAdtqXdoPNPtKU2twxzy7Ob7boybnhzWxIY6lskuIKGXylIhaLKlcbJf1QvUvAnoA8Rf onzM8Xty5umWYvPOQdl9ttUEVPwvNfqWsDUO73dB3BOfCw1boU3Wlck05tKp0zE267VH 9ANOqOOTSVA9APV25j9L6ES3ShYzA3ThS3QxuNhsU9ETLh5yOo0qqN00C23m55gEgcDI k8nqT07JHpFYRIdifOm8ooiDsiCS8SakqRx1I/oWNs0ITzv9BP7OZ+N0oiR9nuruSrSi VBPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2Fk5jBv7Mp4Xm7U73cdiP5KH8bkKQeujrss5w4cxHHo=; b=NV2I0fDeugFAVKEcbbilPDPuGlclbYejdKpXcAsy883wfwqKQBVgVgSgOgVyPCfJdr iTomJf2qkyhhsHwlxFTqxkCi2GRT8Mzwbh3jHXLex35v4wnEcQihvLScg/58QTKW5Thw zDyZIReafVI762j/wbTz6d3K34qlll6Qkse/VKc9nN+KoO26WJb0ug8Rvml9f2Sq516O paoTH7Am1a/pL0l/X2YijjIgWA5YgeET5cjb2wYNm5puP8XengAOxVZBAzOjffdicVdB BMFa94LRcU1KOWsQn4zDn+5N74leiA8/SHervbZfLvlLGC6TWIxOj48UgB98nE1r6EYm qyHA== X-Gm-Message-State: AHYfb5hKArw2J5Ijlh/lI8UJ41x6xylHTv1DQ1a9m/L/gWRDUmIyEDZ6 ewpaIxJL54ZckKjZx1r3AX8zYhltMATU X-Received: by 10.25.38.148 with SMTP id m142mr940785lfm.137.1501858586751; Fri, 04 Aug 2017 07:56:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.218 with HTTP; Fri, 4 Aug 2017 07:56:25 -0700 (PDT) From: Riccardo Bernardini Date: Fri, 4 Aug 2017 16:56:25 +0200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="001a1141029090f8340555eeb3a8" Archived-At: Subject: [core] Official (de facto/de jure) API for CoAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 14:56:31 -0000 --001a1141029090f8340555eeb3a8 Content-Type: text/plain; charset="UTF-8" Dear all, I am planning to write a CoAP library in Ada/SPARK [1] (why? Partly because it is fun, partly as a tough exercise in SPARK, partly for a future project of mine). My question is: does it exist an official API (or a preferred one) for CoAP? So far (1) I went to the "Implementation" page ( http://coap.technology/impls.html) where I saw several implementations, but no reference to a common API. I could take inspiration from an implementation, but which one? (2) I searched the mail archive for "API" ( https://mailarchive.ietf.org/arch/search/?email_list=core&gbt=1&q=API ), but browsing the "Subject" of the resulting 139 messages, I did not see anything promising (with the exception of "Common request/response API," but as I understand it is related to defining a set of exceptions) Thank you in advance for your help Riccardo [1] https://en.wikipedia.org/wiki/SPARK_(programming_language) --001a1141029090f8340555eeb3a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
I am plan= ning to write a CoAP library in Ada/SPARK [1] (why? Partly because it is fu= n, partly as a tough exercise in SPARK, partly for a future project of mine= ).=C2=A0

My question is: does it exist=C2=A0 an official API (or a = preferred one) for CoAP?

So far

=C2=A0 (1)=C2=A0=C2= =A0=C2=A0 I went to the "Implementation" page (http://coap.technology/impls.html) where I = saw several implementations, but no reference to a common API.=C2=A0 I coul= d take inspiration from an implementation, but which one?

=C2= =A0 (2)=C2=A0=C2=A0=C2=A0 I searched the mail archive for "API" (= https://mailarchive.ietf.org/arch/search/?email_list= =3Dcore&gbt=3D1&q=3DAPI ), but browsing the "Subject"= of the resulting 139 messages, I did not see anything promising (with the = exception of "Common request/response API," but as I understand i= t is related to defining a set of exceptions)


Thank = you in advance for your help

Riccardo
--001a1141029090f8340555eeb3a8-- From nobody Fri Aug 4 08:21:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872A413233E for ; Fri, 4 Aug 2017 08:21:49 -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 f5ZZecwbJuUj for ; Fri, 4 Aug 2017 08:21:47 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 586B81321B2 for ; Fri, 4 Aug 2017 08:21:47 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for core@ietf.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ddeQ5-002mgS-7M>; Fri, 04 Aug 2017 17:21:45 +0200 Received: from prag.imp.fu-berlin.de ([160.45.114.37]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for core@ietf.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id <1ddeQ5-001Mfq-1M>; Fri, 04 Aug 2017 17:21:45 +0200 To: core@ietf.org From: Hauke Petersen Message-ID: <2819adb0-8a17-64d2-32cf-9cfd3770c4c1@fu-berlin.de> Date: Fri, 4 Aug 2017 17:21:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 160.45.114.37 Archived-At: Subject: [core] Feedback on draft-ietf-core-resource-directory-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 15:21:50 -0000 Dear all, Pekka Nikander and I implemented (parts of) draft-ietf-core-resource-directory-11 during a hackathon in Dagstuhl [1] last week. We implemented both an RD server for node.js [2], including an integration to Node RED [3], as well as an RD client integrated into RIOT [4,5]. While doing this, we came across some points in the draft that were not quite clear to us and which could potentially be clarified. Sorry if these are duplicates, but I could not find anything on the mailing list archive about these points. Simple registration (Sections 5.3.1/5.3.2): ------------------------------------------- 1. How should a node (RD client) update its entries when using the simple registration sequence, as described in 5.3.2? We assumed that the node simply repeats the sequence, as described in that section, but the draft could be more precise on that matter. 2. Is it correct that a node using the simple registration is not able to delete its RD entries actively? So, is the only choice to simply not update its entries and wait for expiration of the defined lifetime? Or is the idea that the node registers with lt=60 (the minimum) and then waits for 60 seconds? 3. How should the RD respond, if the payload of the initial POST request is not empty? Apparently there was in an earlier draft also the possibility that the POST request could contain the resources, but that was removed. However, the current draft does not define how the RD should respond in the case there is any content. 4. Examples in Section 5.3.2: both `Req:` line comments seem wrong: shouldn't be the initial POST coap://rd.example.com/.well-known/core?lt=6000;ep=node1 be marked as like `from EP to [ff02::1] (RD server)` and the second GET coap://[ff02::1]/.well-known/core request be something like `from RD server to EP (unicast)`? Registration Update (Section 5.4.1): ------------------------------------ 5. Should the registration update PUT instead of POST? That is, upon normal registration the RD responds with a new link to the initial POST with 2.01 Created and a Location (Section 5.3). Then the update updates the data at the location. Should that be a PUT instead of POST, as it does not create a new URL? If it indeed shall be a POST, then the draft should have some rationale for why. For some discussion on similar matters, see e.g. [6]. Best, Hauke [1]https://www.dagstuhl.de/en/program/calendar/evhp/?semnr=17303 [2]https://github.com/Ell-i/coap-rd [3]https://github.com/Ell-i/node-red-contrib-coap-rd [4]https://github.com/RIOT-OS/RIOT/pull/7406 [5]https://github.com/RIOT-OS/RIOT/pull/7428 [6]https://stackoverflow.com/questions/630453/put-vs-post-in-rest From nobody Fri Aug 4 08:32:33 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85030132355 for ; Fri, 4 Aug 2017 08:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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=augustcellars.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 LPAfE7yVatQC for ; Fri, 4 Aug 2017 08:32:29 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689F8132470 for ; Fri, 4 Aug 2017 08:32:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0366_01D30CFC.326729F0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501860725; h=from:subject:to:date:message-id; bh=bnxPBN9odOl8rp8JUo/1vj/Ft+KcCj215P7rN253EvA=; b=c7gMnRfDuKaAhCdaxoMPR5NWh2+XP0DE2jsFGZCy5I2mV/tT+nAWqdxHuzRK5PH1HkohD/f+kXr ymez2EKerYoHbHr8E3TaCSRBOk41YhIAZzBhbjpjIPt5slpPz891EtLjjaZtpLoFfDrmVw13vDdiD EFdV5KnuTT4Tf6cg+CILoGdPAd7zFFjdq4shlfMQLYQz77p+a+SZQ/BB5pDNCP6qpOexTlwwXYvLv pTzLNXbtce+xHhPDLOEEwb+OjUbfn8v5+x2z3QRnC+xppV3ptJIXnZSyOgUXbzvLUqqa5c2yE7OKe r4pw0VaJTjI9bZALXgwyMkdcUXkd9hM3ooTA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 4 Aug 2017 08:32:05 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 4 Aug 2017 08:32:01 -0700 From: Jim Schaad To: 'Riccardo Bernardini' , References: In-Reply-To: Date: Fri, 4 Aug 2017 08:32:21 -0700 Message-ID: <036501d30d36$dec58cc0$9c50a640$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHtlgBwsrSlFlpu/7pZCcoKk/dcMKI/QX3Q X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Official (de facto/de jure) API for CoAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 15:32:32 -0000 ------=_NextPart_000_0366_01D30CFC.326729F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The IETF does not generally decide what APIs look like. I am not aware = of any standardized API although the one from Californium may be the = closest you might get for a flavor. =20 Jim =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Riccardo = Bernardini Sent: Friday, August 4, 2017 7:56 AM To: core@ietf.org Subject: [core] Official (de facto/de jure) API for CoAP? =20 Dear all, I am planning to write a CoAP library in Ada/SPARK [1] (why? Partly = because it is fun, partly as a tough exercise in SPARK, partly for a = future project of mine). =20 My question is: does it exist an official API (or a preferred one) for = CoAP?=20 So far=20 (1) I went to the "Implementation" page = (http://coap.technology/impls.html) where I saw several implementations, = but no reference to a common API. I could take inspiration from an = implementation, but which one? (2) I searched the mail archive for "API" ( = https://mailarchive.ietf.org/arch/search/?email_list=3Dcore = &gbt=3D1&q=3DAPI ), but browsing the "Subject" of the resulting 139 = messages, I did not see anything promising (with the exception of = "Common request/response API," but as I understand it is related to = defining a set of exceptions) =20 Thank you in advance for your help Riccardo [1] https://en.wikipedia.org/wiki/SPARK_(programming_language) =20 ------=_NextPart_000_0366_01D30CFC.326729F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The IETF = does not generally decide what APIs look like.=C2=A0 I am not aware of = any standardized API although the one from Californium may be the = closest you might get for a flavor.

 

Jim

 

 

From: core = [mailto:core-bounces@ietf.org] On Behalf Of Riccardo = Bernardini
Sent: Friday, August 4, 2017 7:56 AM
To: = core@ietf.org
Subject: [core] Official (de facto/de jure) API = for CoAP?

 

Dear all,

I am planning to write a CoAP library in = Ada/SPARK [1] (why? Partly because it is fun, partly as a tough exercise = in SPARK, partly for a future project of mine). 

My = question is: does it exist  an official API (or a preferred one) = for CoAP?

So far

  (1)    I went to = the "Implementation" page (http://coap.technology/impls.h= tml) where I saw several implementations, but no reference to a = common API.  I could take inspiration from an implementation, but = which one?

  = (2)    I searched the mail archive for "API" ( = https://mailarchive.ietf.org/arch/search/?email_list=3D= core&gbt=3D1&q=3DAPI ), but browsing the "Subject" = of the resulting 139 messages, I did not see anything promising (with = the exception of "Common request/response API," but as I = understand it is related to defining a set of = exceptions)

 

Thank you in advance = for your help

Riccardo

------=_NextPart_000_0366_01D30CFC.326729F0-- From nobody Fri Aug 4 09:10:41 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C2113238C for ; Fri, 4 Aug 2017 09:10:40 -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 hhOug3ncKxlN for ; Fri, 4 Aug 2017 09:10:38 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 5D6401321F0 for ; Fri, 4 Aug 2017 09:10:38 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id m86so8889079lfi.4 for ; Fri, 04 Aug 2017 09:10:38 -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; bh=bpFhhn/n962L3xvdfm/Z2hacClwoZsp+j5uNvHN6R0E=; b=QD+t6AGuclSYI3BS/9fNemF7X639Q2+qQJquIWMrfGnOA7zvOCxuf4NfkeuuXmV0dL 9dDLnD11VdtZx8WpiIMMfdUJLKCHYJaO4iBArjiEQoefE0OccmfGF4pTZLkRfVvjtMmK fk9eUXUjQsdELX4gOiNA1LQ5JvHhNhlt6xU9ZQC1ZKikiOivFQSpWJUhCsJS5x12yajt y56m+/+a5pMkRCMs9K8sDANY7jG2y2Y044eWq8ntjbh+Wuov/99pxs7WigqLxov3GTAr 8PwhN9KHknjQQIYOvVnsJvyfEKSO9SrhDh4l5XclFreP6gkgZ3iyrQWbCpUIQsV+DoeA AVAg== 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; bh=bpFhhn/n962L3xvdfm/Z2hacClwoZsp+j5uNvHN6R0E=; b=d5q9N3n0XslK/pd421qLUCeWaPuwNZnZuqCfDwYtP24vpiQ6M6fM941bgVuoj3Jf11 dDfPgxEENgbF7a3cEIEkykE8TZ4/J85i4UMMzOpJfW8JcN8PUtR8hjCmtq+SgQWSrkOw KXFBqFELfILTGe0iw6KnydexytgTtnA+eKoe8VCxMnGBRq8sshudFzx1Fw8MFvK7agD3 24vxBJo5f6wmUrY/5vjF9Tgp6e06ueHoxMjPLm/IKjSEioXmNYtzQq+efxnXpvwqxRJQ DpbMPNrMUpi0ORSgBSJxAiAbgv8aFzACMaqwfC+qAbbltUBVGmDPvle0QBMN5FBUCqf2 /i9w== X-Gm-Message-State: AIVw111ZKlxUydWJHr8nzmxUS09ghKWGC+LYRhuMDNfShh6kVqhI19VI vExuz6E0HEh9O1RPxGb7t5xeMh+5iQ== X-Received: by 10.46.78.17 with SMTP id c17mr1069909ljb.106.1501863036004; Fri, 04 Aug 2017 09:10:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.218 with HTTP; Fri, 4 Aug 2017 09:10:34 -0700 (PDT) In-Reply-To: <036501d30d36$dec58cc0$9c50a640$@augustcellars.com> References: <036501d30d36$dec58cc0$9c50a640$@augustcellars.com> From: Riccardo Bernardini Date: Fri, 4 Aug 2017 18:10:34 +0200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="f403045ecf06c32ecf0555efbca8" Archived-At: Subject: Re: [core] Official (de facto/de jure) API for CoAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 16:10:41 -0000 --f403045ecf06c32ecf0555efbca8 Content-Type: text/plain; charset="UTF-8" Thank you Jim. On Fri, Aug 4, 2017 at 5:32 PM, Jim Schaad wrote: > The IETF does not generally decide what APIs look like. > Yes, I know, and I also know that every now and then there is some discussion if it should (but I do not want to re-ignite this discussion here). However, sometimes "de facto" standard APIs emerge (e.g., BSD socket), although CoAP is maybe too young for that. > I am not aware of any standardized API although the one from Californium > may be the closest you might get for a flavor. > I'll check. Thank you again. Riccardo > > > Jim > > > > > > *From:* core [mailto:core-bounces@ietf.org] *On Behalf Of *Riccardo > Bernardini > *Sent:* Friday, August 4, 2017 7:56 AM > *To:* core@ietf.org > *Subject:* [core] Official (de facto/de jure) API for CoAP? > > > > Dear all, > > I am planning to write a CoAP library in Ada/SPARK [1] (why? Partly > because it is fun, partly as a tough exercise in SPARK, partly for a future > project of mine). > > My question is: does it exist an official API (or a preferred one) for > CoAP? > > So far > > (1) I went to the "Implementation" page ( > http://coap.technology/impls.html) where I saw several implementations, > but no reference to a common API. I could take inspiration from an > implementation, but which one? > > (2) I searched the mail archive for "API" ( > https://mailarchive.ietf.org/arch/search/?email_list=core&gbt=1&q=API ), > but browsing the "Subject" of the resulting 139 messages, I did not see > anything promising (with the exception of "Common request/response API," > but as I understand it is related to defining a set of exceptions) > > > > Thank you in advance for your help > > Riccardo > > > [1] https://en.wikipedia.org/wiki/SPARK_(programming_language) > > > --f403045ecf06c32ecf0555efbca8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Jim.

On Fri, Aug 4, 2017 at 5:32 PM, Jim Schaad <ie= tf@augustcellars.com> wrote:

The IETF does not general= ly decide what APIs look like.=C2=A0


=
Yes, I know, and I also know that every now and then there is so= me discussion if it should (but I do not want to re-ignite this discussion = here).=C2=A0 However, sometimes "de facto" standard APIs emerge (= e.g., BSD socket), although CoAP is maybe too young for that.
=C2=A0

I am not aware of any standardized API although the one fr= om Californium may be the closest you might get for a flavor.=


I'll check.=C2=A0 Than= k you again.

Riccardo

=C2=A0

Jim

<= p class=3D"MsoNormal">=C2=A0

=C2=A0

From: = core [mailto:cor= e-bounces@ietf.org] On Behalf Of Riccardo Bernardini
Sent:= Friday, August 4, 2017 7:56 AM
To: core@ietf.org
Subject: [core] Offic= ial (de facto/de jure) API for CoAP?

=C2=A0

Dear all,

I am planning to wr= ite a CoAP library in Ada/SPARK [1] (why? Partly because it is fun, partly = as a tough exercise in SPARK, partly for a future project of mine).=C2=A0 <= br>
My question is: does it exist=C2=A0 an official API (or a preferred = one) for CoAP?

So far

=C2=A0 (1)=C2=A0=C2=A0=C2=A0 I went to the= "Implementation" page (http://coap.technology/impls.html) where I = saw several implementations, but no reference to a common API.=C2=A0 I coul= d take inspiration from an implementation, but which one?

=

=C2=A0 (2)=C2=A0=C2=A0=C2=A0 I searched the ma= il archive for "API" ( htt= ps://mailarchive.ietf.org/arch/search/?email_list=3Dcore&gbt= =3D1&q=3DAPI ), but browsing the "Subject" of the resulti= ng 139 messages, I did not see anything promising (with the exception of &q= uot;Common request/response API," but as I understand it is related to= defining a set of exceptions)

=C2=A0

Thank you in advance for your hel= p

Riccardo

<= div>=

--f403045ecf06c32ecf0555efbca8-- From nobody Fri Aug 4 11:14:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AED4132359 for ; Fri, 4 Aug 2017 11:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 RBWHlwG3cTCD for ; Fri, 4 Aug 2017 11:14:50 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 87A4B13233E for ; Fri, 4 Aug 2017 11:14:41 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id t86so10753658pfe.2 for ; Fri, 04 Aug 2017 11:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Had6jAKus2VxFOq5Kz26MsxTXPcWKzT1l1PwfHreciE=; b=uu0ATw/jvpzadaHNAPP0zmiRvjKy4zNO961m4Qgh+pi7VAuryD4eiZczA/1mCmLmae V+uoDmY7PsZSarDflICZi1BaXhaJ4zbL/Z7B/F4OPfLiLadKzfzeGohtD2CXAav7YsFx fXpanpxbwZB2/c0wsbXUfaTY4WxnOGiSBwa8W0DUxH3c1o1/kz1VYgettzWiA/yhTWbq YS/R06MI03ljM1ixiGR2DsOUbPqfYAAJQ9oPC8Hox4JTw415+pLi6nEPRhA2C+/lsv6X UHK7/wYo4/a2BJu6z9jiooKbNAILs/fBUjjIopd1fHfKtQ5tJLf7btO4cLbQtWZDps4m SkLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Had6jAKus2VxFOq5Kz26MsxTXPcWKzT1l1PwfHreciE=; b=Kq8GNgZZ0XoQk+nm/VGd+bAs4Aa/kdQT4B09XIejszv0GhValAl1kJckqYIxIE7WLA 6xKECRrDpFtcunpEHqGoILpl1Sr7D4qq/icT06o8vUw17wqaauevcsacmRl33UnOjb1f YB91MU9Mta59AzhaFzJ1TiznIpGvH0BhgP+Gt6xpcEGv+QmgRPOcPe1rdr67Z6t0RLu+ iISJcUZ5MgjUuawW6gcelmNBjkXH05v8upVEGNv/DXu6gGuFWLN1xNWOuGL0DRMvmd5P Cr+RnZ58OdbcU5WXpTXBBM3YInxqMMaYfSrfC+E+sxLmPfnC022QmH0EMp9GIFhBuAso ln8g== X-Gm-Message-State: AIVw113+giJkNgPjsni2POvgMBbytxxTZ+1hMevprZt4hMohJLLj0T03 ptm2ns3jKWGLbQH1puI= X-Received: by 10.99.151.17 with SMTP id n17mr3121564pge.157.1501870480958; Fri, 04 Aug 2017 11:14:40 -0700 (PDT) Received: from [10.0.0.6] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id x81sm4375555pfi.20.2017.08.04.11.14.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 11:14:40 -0700 (PDT) From: Michael Koster Message-Id: <964FB20F-FB48-4D75-9FEF-9D2659316119@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_061A12FA-B536-418F-B63F-63439A6871FD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 4 Aug 2017 11:14:38 -0700 In-Reply-To: <2819adb0-8a17-64d2-32cf-9cfd3770c4c1@fu-berlin.de> Cc: core@ietf.org To: Hauke Petersen References: <2819adb0-8a17-64d2-32cf-9cfd3770c4c1@fu-berlin.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Feedback on draft-ietf-core-resource-directory-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 18:14:53 -0000 --Apple-Mail=_061A12FA-B536-418F-B63F-63439A6871FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Hauke, Thank you for the comments, particularly on simple registration. I agree = that we need to clarify some points. More comments are in-line: > On Aug 4, 2017, at 8:21 AM, Hauke Petersen = wrote: >=20 > Dear all, >=20 > Pekka Nikander and I implemented (parts of) = draft-ietf-core-resource-directory-11 during a hackathon in Dagstuhl [1] = last week. We implemented both an RD server for node.js [2], including = an integration to Node RED [3], as well as an RD client integrated into = RIOT [4,5]. While doing this, we came across some points in the draft = that were not quite clear to us and which could potentially be = clarified. Sorry if these are duplicates, but I could not find anything = on the mailing list archive about these points. >=20 > Simple registration (Sections 5.3.1/5.3.2): > ------------------------------------------- >=20 > 1. How should a node (RD client) update its entries when using the = simple registration sequence, as described in 5.3.2? We assumed that = the node simply repeats the sequence, as described in that section, but = the draft could be more precise on that matter. >=20 Yes, that is the expected behavior. We imply that in the phrase = "occasionally sends", but agree we should be more specific. > 2. Is it correct that a node using the simple registration is not able = to delete its RD entries actively? So, is the only choice to simply not = update its entries and wait for expiration of the defined lifetime? Or = is the idea that the node registers with lt=3D60 (the minimum) and then = waits for 60 seconds? >=20 Yes, we should be explicit about how simple registration entries expire. > 3. How should the RD respond, if the payload of the initial POST = request is not empty? Apparently there was in an earlier draft also the = possibility that the POST request could contain the resources, but that = was removed. However, the current draft does not define how the RD = should respond in the case there is any content. >=20 We removed that option because we already have a way to upload links in = the registration payload, per section 5.3 and didn't want to require = another, though it would make sense from a REST API point of view. = Should payloads be ignored or should an error be signalled? We don't = require an RD to expose any registered links in its .well-known/core. I = would tend toward signalling some kind of exception. Probably would be worthwhile to point out that an RD would still create = an endpoint registration resource when using simple registration, but = there is no defined way for the device using simple registration to = obtain the location information. > 4. Examples in Section 5.3.2: both `Req:` line comments seem wrong: = shouldn't be the initial >=20 > POST coap://rd.example.com/.well-known/core?lt=3D6000;ep=3Dnode1 >=20 > be marked as like `from EP to [ff02::1] (RD server)` and the second >=20 The POST is from the device at [ff02::1] using simple registration to = register an EP to the RD server > GET coap://[ff02::1]/.well-known/core >=20 > request be something like `from RD server to EP (unicast)`? Yes, the GET is from the RD server to the device at [ff02::1] to obtain = its links to register We can clarify that the registering device is at [ff02::1] in this = example. >=20 > Registration Update (Section 5.4.1): > ------------------------------------ >=20 > 5. Should the registration update PUT instead of POST? That is, upon = normal registration the RD responds with a new link to the initial POST = with 2.01 Created and a Location (Section 5.3). Then the update updates = the data at the location. Should that be a PUT instead of POST, as it = does not create a new URL? If it indeed shall be a POST, then the draft = should have some rationale for why. >=20 The reason for using POST is to provide the option of sending an empty = payload, in order to update the registration lifetime (refresh) without = re-sending the links. Some early implementations used PUT for the refresh and deleted all of = the links on refresh operations. The definition of PUT is to replace the = contents of the resource, and the REST libraries would enforce that = behavior. If this is an empty payload, than the result is an empty = resource. Thus, we changed to POST.=20 The definition of POST does not seem to exclude updates as well as = create as the actual result is determined by the server (see RFC2616, = section 9.5 https://tools.ietf.org/html/rfc2616 = ), and we signal the correct = interpretation in the response. The response to an initial registration = is 2.01 Created, and the response to a refresh or update, also using = POST, is 2.04 Changed. It depends on how you interpret the requirement = for a "subordinate resource". We believe that his conforms best to the intent and practice of REST API = design. I will review the stackoverflow reference and comment further if = it seems useful. I will also look into your implementation as I am also considering a = nodejs implementation of RD. Node-RED is another interesting system to = integrate. Thanks again! Best regards, Michael > For some discussion on similar matters, see e.g. [6]. >=20 > Best, > Hauke >=20 > [1]https://www.dagstuhl.de/en/program/calendar/evhp/?semnr=3D17303 > [2]https://github.com/Ell-i/coap-rd > [3]https://github.com/Ell-i/node-red-contrib-coap-rd > [4]https://github.com/RIOT-OS/RIOT/pull/7406 > [5]https://github.com/RIOT-OS/RIOT/pull/7428 > [6]https://stackoverflow.com/questions/630453/put-vs-post-in-rest >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_061A12FA-B536-418F-B63F-63439A6871FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Hauke,

Thank you for the comments, particularly on simple = registration. I agree that we need to clarify some points.

More comments are = in-line:

On = Aug 4, 2017, at 8:21 AM, Hauke Petersen <hauke.petersen@fu-berlin.de> wrote:

Dear = all,

Pekka Nikander and I implemented = (parts of) draft-ietf-core-resource-directory-11 during a hackathon in = Dagstuhl [1] last week.  We implemented both an RD server for = node.js [2], including an integration to Node RED [3], as well as an RD = client integrated into RIOT [4,5]. While doing this, we came across some = points in the draft that were not quite clear to us and which could = potentially be clarified.  Sorry if these are duplicates, but I = could not find anything on the mailing list archive about these = points.

Simple registration (Sections = 5.3.1/5.3.2):
-------------------------------------------
1. How should a node (RD client) update its = entries when using the simple registration sequence, as described in = 5.3.2?  We assumed that the node simply repeats the sequence, as = described in that section, but the draft could be more precise on that = matter.

Yes, that = is the expected behavior. We imply that in the phrase "occasionally = sends", but agree we should be more specific.

2. Is it correct that a node using the simple registration is = not able to delete its RD entries actively? So, is the only choice to = simply not update its entries and wait for expiration of the defined = lifetime?  Or is the idea that the node registers with lt=3D60 (the = minimum) and then waits for 60 seconds?

Yes, we should be explicit about how = simple registration entries expire.

3. How should = the RD respond, if the payload of the initial POST request is not empty? =  Apparently there was in an earlier draft also the possibility that = the POST request could contain the resources, but that was removed. =  However, the current draft does not define how the RD should = respond in the case there is any content.

We removed that option because we = already have a way to upload links in the registration payload, per = section 5.3 and didn't want to require another, though it would make = sense from a REST API point of view. Should payloads be ignored or = should an error be signalled? We don't require an RD to expose any = registered links in its .well-known/core. I would tend toward signalling = some kind of exception.

Probably = would be worthwhile to point out that an RD would still create an = endpoint registration resource when using simple registration, but there = is no defined way for the device using simple registration to obtain the = location information.

4. Examples in Section 5.3.2: = both `Req:` line comments seem wrong: shouldn't be the initial

     POST coap://rd.example.com/.well-known/core?lt=3D6000;ep=3Dnode1=

  be marked as like `from EP to = [ff02::1] (RD server)` and the second

The POST is from the device at = [ff02::1] using simple registration to register an EP to the RD = server

     GET coap://[ff02::1]/.well-known/core

  request be something like `from RD server to EP = (unicast)`?

Yes, = the GET is from the RD server to the device at [ff02::1] to obtain its = links to register

We can clarify = that the registering device is at [ff02::1] in this example.

Registration Update (Section 5.4.1):
------------------------------------

5. Should the registration update PUT instead of POST? =  That is, upon normal registration the RD responds with a new link = to the initial POST with 2.01 Created and a Location (Section 5.3). =  Then the update updates the data at the location.  Should = that be a PUT instead of POST, as it does not create a new URL?  If = it indeed shall be a POST, then the draft should have some rationale for = why.

The reason = for using POST is to provide the option of sending an empty payload, in = order to update the registration lifetime (refresh) without re-sending = the links.

Some early = implementations used PUT for the refresh and deleted all of the links on = refresh operations. The definition of PUT is to replace the contents of = the resource, and the REST libraries would enforce that behavior. If = this is an empty payload, than the result is an empty resource. Thus, we = changed to POST. 

The = definition of POST does not seem to exclude updates as well as create as = the actual result is determined by the server (see RFC2616, section = 9.5 https://tools.ietf.org/html/rfc2616 ), and we signal = the correct interpretation in the response. The response to an initial = registration is 2.01 Created, and the response to a refresh or update, = also using POST, is 2.04 Changed. It depends on how you interpret the = requirement for a "subordinate resource".

We believe that his conforms best to the intent = and practice of REST API design. I will review the stackoverflow = reference and comment further if it seems useful.

I will also look into your implementation as I am = also considering a nodejs implementation of RD. Node-RED is another = interesting system to integrate.

Thanks again!

Best regards,

Michael

= --Apple-Mail=_061A12FA-B536-418F-B63F-63439A6871FD-- From nobody Fri Aug 4 14:52:25 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9C9127058 for ; Fri, 4 Aug 2017 14:52:23 -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 Tttym4w0CuVK for ; Fri, 4 Aug 2017 14:52:21 -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 44F0C12708C for ; Fri, 4 Aug 2017 14:52:20 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 4 Aug 2017 23:52:09 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0361.001; Fri, 4 Aug 2017 23:52:18 +0200 From: "Kovatsch Matthias" To: core WG CC: Carsten Bormann , "'Klaus Hartke (hartke@tzi.org)'" Thread-Topic: draft-ietf-core-etch: Response Code for FETCH Thread-Index: AdMNa3ofcgeYYfMkT5eYqCcDYbQQFQ== Date: Fri, 4 Aug 2017 21:52:17 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] draft-ietf-core-etch: Response Code for FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:52:23 -0000 Hi all I am currently adding etch support to Copper and read the following: " FETCH cannot be assumed to be a complete representation of the resource identified by the effective request URI, i.e., it cannot be used by a cache as a payload to be returned by a GET request." Too bad that: "Unlike HTTP, the cacheability of CoAP responses does not depend on the request method, but it depends on the Response Code. " [RFC 7252] Thus, we need a proper Response Code for FETCH. However, which one? "Change= d" is a bit ill-suited for a safe method... Currently text on this is completely missing. Examples will have to be fixe= d. Ciao Matthias From nobody Fri Aug 4 15:01:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CA6127B73 for ; Fri, 4 Aug 2017 15:00:54 -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 btFQ8O7yGmG4 for ; Fri, 4 Aug 2017 15:00: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 03CF6126CB6 for ; Fri, 4 Aug 2017 15:00:51 -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 v74M0miV017040; Sat, 5 Aug 2017 00:00:48 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xPLTX583mzDLkP; Sat, 5 Aug 2017 00:00:48 +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: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> Date: Sat, 5 Aug 2017 00:00:47 +0200 Cc: core WG , "Klaus Hartke (hartke@tzi.org)" X-Mao-Original-Outgoing-Id: 523576847.204049-fc1bc9dc1d13845efbe6f477598412ae Content-Transfer-Encoding: quoted-printable Message-Id: <1F7F6477-95E1-4E83-99B5-5A3DEE040066@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-etch: Response Code for FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 22:00:54 -0000 The FETCH payload is part of the cache key. (Penultimate paragraph of intro to Section 2.) Shouldn=E2=80=99t that solve your problem? Gr=C3=BC=C3=9Fe, Carsten > On Aug 4, 2017, at 23:52, Kovatsch Matthias = wrote: >=20 > Hi all >=20 > I am currently adding etch support to Copper and read the following: >=20 > " FETCH cannot be assumed to be a complete representation > of the resource identified by the effective request URI, i.e., it > cannot be used by a cache as a payload to be returned by a GET > request." >=20 > Too bad that: >=20 > "Unlike HTTP, the cacheability of CoAP responses does not depend on > the request method, but it depends on the Response Code. " [RFC = 7252] >=20 > Thus, we need a proper Response Code for FETCH. However, which one? = "Changed" is a bit ill-suited for a safe method... > Currently text on this is completely missing. Examples will have to be = fixed. >=20 > Ciao > Matthias >=20 >=20 >=20 From nobody Fri Aug 4 15:15:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3933128961 for ; Fri, 4 Aug 2017 15:15: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 z-bNLoTtMyRR for ; Fri, 4 Aug 2017 15:14:58 -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 9B2F41288B8 for ; Fri, 4 Aug 2017 15:14:58 -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.361.1; Sat, 5 Aug 2017 00:14:48 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0361.001; Sat, 5 Aug 2017 00:14:56 +0200 From: "Kovatsch Matthias" To: Carsten Bormann CC: core WG , "Klaus Hartke (hartke@tzi.org)" Thread-Topic: draft-ietf-core-etch: Response Code for FETCH Thread-Index: AdMNa3ofcgeYYfMkT5eYqCcDYbQQFf//4cWA///c67A= Date: Fri, 4 Aug 2017 22:14:56 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B55BA7DE5A@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> <1F7F6477-95E1-4E83-99B5-5A3DEE040066@tzi.org> In-Reply-To: <1F7F6477-95E1-4E83-99B5-5A3DEE040066@tzi.org> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-etch: Response Code for FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 22:15:01 -0000 PiBUaGUgRkVUQ0ggcGF5bG9hZCBpcyBwYXJ0IG9mIHRoZSBjYWNoZSBrZXkuDQo+IChQZW51bHRp bWF0ZSBwYXJhZ3JhcGggb2YgaW50cm8gdG8gU2VjdGlvbiAyLikgU2hvdWxkbuKAmXQgdGhhdCBz b2x2ZSB5b3VyDQo+IHByb2JsZW0/DQoNCldlcmUgcGF5bG9hZHMgY29uc2lkZXJlZCBmb3IgdGhl IGNhY2hlIGtleSBiZWZvcmU/IEkgZ3Vlc3MsIGl0IHdvdWxkIG5lZWQgc29tZSBwcm9wZXIgd3Jp dGUtdXAgYW5kIGVkdWNhdGlvbiBmb3IgdGhhdCAoaW5jbHVkaW5nIHRoZSB1cGRhdGUgb2YgcG90 ZW50aWFsbHkgaW5zdGFsbGVkIGNhY2hlcykuDQoNCldvdWxkIHRoYXQgbWVhbiBhbGwgcmVxdWVz dCBwYXlsb2Fkcz8gVGhpcyB3b3VsZCBtYWtlIDIuMDUgcmVzcG9uc2VzIHRvIFBPU1QgYWxzbyBj YWNoZWFibGUsIHdoaWNoIG1pZ2h0IGJlIGEgZmVhdHVyZSBhbmQgbWF5YmUgZml4IENvQVAgc2Vy dmVycyB0aGF0IHVzZSAyLjA1IGluIHJlc3BvbnNlIHRvIGEgUE9TVCB1bmtub3dpbmdseS4uLg0K DQpCZXN0IHdpc2hlcywNCk1hdHRoaWFzDQo= From nobody Fri Aug 4 15:21:09 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2361204DA for ; Fri, 4 Aug 2017 15:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[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 HJ76jIJrxbIE for ; Fri, 4 Aug 2017 15:20:59 -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 74218127978 for ; Fri, 4 Aug 2017 15:20: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 v74MKuFL002499; Sat, 5 Aug 2017 00:20:56 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xPLwl5xQ9zDLkV; Sat, 5 Aug 2017 00:20:55 +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: <55877B3AFB359744BA0F2140E36F52B55BA7DE5A@MBX110.d.ethz.ch> Date: Sat, 5 Aug 2017 00:20:55 +0200 Cc: core WG , "Klaus Hartke (hartke@tzi.org)" X-Mao-Original-Outgoing-Id: 523578055.202053-6f3208f450832fc43073a4579a941012 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> <1F7F6477-95E1-4E83-99B5-5A3DEE040066@tzi.org> <55877B3AFB359744BA0F2140E36F52B55BA7DE5A@MBX110.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-etch: Response Code for FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 22:21:01 -0000 > On Aug 5, 2017, at 00:14, Kovatsch Matthias = wrote: >=20 >> The FETCH payload is part of the cache key. >> (Penultimate paragraph of intro to Section 2.) Shouldn=E2=80=99t that = solve your >> problem? >=20 > Were payloads considered for the cache key before? I guess, it would = need some proper write-up and education for that (including the update = of potentially installed caches). I don=E2=80=99t think so. E.g., a POST payload often is large, making = it less useful as a cache key. (More importantly, POST isn=E2=80=99t idempotent; this would have needed = an iPOST or some such.) > Would that mean all request payloads? This would make 2.05 responses = to POST also cacheable, which might be a feature and maybe fix CoAP = servers that use 2.05 in response to a POST unknowingly=E2=80=A6 Let me cite that penultimate paragraph from RFC 8132: Depending on the response code as defined by [RFC7252], the response to a FETCH request is cacheable; the request body is part of the cache key. Specifically, 2.05 (Content) response codes (the responses for which are cacheable) are a typical way to respond to a FETCH request. =20 So this is FETCH only. And it (tries to) say that 2.05 should work very = well with that. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 4 15:45:10 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8422D12714F for ; Fri, 4 Aug 2017 15:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 S2DCc7rSQSeH for ; Fri, 4 Aug 2017 15:45:06 -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 E97221204DA for ; Fri, 4 Aug 2017 15:45:05 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 5 Aug 2017 00:44:53 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0361.001; Sat, 5 Aug 2017 00:45:03 +0200 From: "Kovatsch Matthias" To: Carsten Bormann CC: core WG , "Klaus Hartke (hartke@tzi.org)" Thread-Topic: draft-ietf-core-etch: Response Code for FETCH Thread-Index: AdMNa3ofcgeYYfMkT5eYqCcDYbQQFf//4cWA///c67CAACi1gP//3dbw Date: Fri, 4 Aug 2017 22:45:02 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B55BA7DECD@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> <1F7F6477-95E1-4E83-99B5-5A3DEE040066@tzi.org> <55877B3AFB359744BA0F2140E36F52B55BA7DE5A@MBX110.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: [129.132.130.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-etch: Response Code for FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 22:45:08 -0000 PiA+IFdlcmUgcGF5bG9hZHMgY29uc2lkZXJlZCBmb3IgdGhlIGNhY2hlIGtleSBiZWZvcmU/IEkg Z3Vlc3MsIGl0IHdvdWxkIG5lZWQNCj4gc29tZSBwcm9wZXIgd3JpdGUtdXAgYW5kIGVkdWNhdGlv biBmb3IgdGhhdCAoaW5jbHVkaW5nIHRoZSB1cGRhdGUgb2YNCj4gcG90ZW50aWFsbHkgaW5zdGFs bGVkIGNhY2hlcykuDQo+IA0KPiBJIGRvbuKAmXQgdGhpbmsgc28uICBFLmcuLCBhIFBPU1QgcGF5 bG9hZCBvZnRlbiBpcyBsYXJnZSwgbWFraW5nIGl0IGxlc3MgdXNlZnVsIGFzIGENCj4gY2FjaGUg a2V5LiANCj4gKE1vcmUgaW1wb3J0YW50bHksIFBPU1QgaXNu4oCZdCBpZGVtcG90ZW50OyB0aGlz IHdvdWxkIGhhdmUgbmVlZGVkIGFuIGlQT1NUIG9yDQo+IHNvbWUgc3VjaC4pDQoNCldlbGwsIEkg Z3Vlc3MgaXQgaXMgaGFyZCB0byBjYXRlZ29yaXplIHRoaXMgZ2xvYmFsbHkuLi4gVGhlcmUgbWln aHQgYmUgc2VydmljZSByZXNvdXJjZXMgdGhhdCBjb252ZXJ0IHZhbHVlcyBmcm9tIG9uZSB1bml0 IHRvIGFub3RoZXIgYW5kIHByb2JhYmx5IG1hbnkgbW9yZSB1c2UgY2FzZXMgZm9yIHNtYWxsIFBP U1QgcGF5bG9hZHMgYW5kIGEgY2FjaGVhYmUgcmVzcG9uc2UuDQoNCk15IGlkZWEgd2FzIHRoYXQg YSBwcm9wZXIgd3JpdGUtdXAgY291bGQgdGVsbCBzZXJ2ZXIgaW1wbGVtZW50ZXJzIHRoYXQgdGhl eSBzaG91bGQgcmVzcG9uZCB3aXRoIDIuMDUgd2hlbiB0aGVpciBQT1NUIHJlc291cmNlIGhhbmRs ZXIgaXMgaW5kZWVkIGlkZW1wb3RlbnQvY2FjaGVhYmxlIGFuZCAyLjA0IG90aGVyd2lzZS4gVGhp cyB3YXMgZm9yIG1lIHRoZSBiZW5lZml0IG9mIGxpbmtpbmcgY2FjaGVhYmlsaXR5IHRvIHRoZSBy ZXNwb25zZSBjb2RlIGluIHRoZSBmaXJzdCBwbGFjZS4uLiBXaGF0IHdhcyB0aGUgIG1haW4gcmVh c29uIGZvciB0aGlzPw0KDQo+IExldCBtZSBjaXRlIHRoYXQgcGVudWx0aW1hdGUgcGFyYWdyYXBo IGZyb20gUkZDIDgxMzI6DQo+IA0KPiAgICBEZXBlbmRpbmcgb24gdGhlIHJlc3BvbnNlIGNvZGUg YXMgZGVmaW5lZCBieSBbUkZDNzI1Ml0sIHRoZSByZXNwb25zZQ0KPiAgICB0byBhIEZFVENIIHJl cXVlc3QgaXMgY2FjaGVhYmxlOyB0aGUgcmVxdWVzdCBib2R5IGlzIHBhcnQgb2YgdGhlDQo+ICAg IGNhY2hlIGtleS4gIFNwZWNpZmljYWxseSwgMi4wNSAoQ29udGVudCkgcmVzcG9uc2UgY29kZXMg KHRoZQ0KPiAgICByZXNwb25zZXMgZm9yIHdoaWNoIGFyZSBjYWNoZWFibGUpIGFyZSBhIHR5cGlj YWwgd2F5IHRvIHJlc3BvbmQgdG8gYQ0KPiAgICBGRVRDSCByZXF1ZXN0Lg0KPiANCj4gU28gdGhp cyBpcyBGRVRDSCBvbmx5LiAgQW5kIGl0ICh0cmllcyB0bykgc2F5IHRoYXQgMi4wNSBzaG91bGQg d29yayB2ZXJ5IHdlbGwgd2l0aA0KPiB0aGF0Lg0KDQpUaGUgcHJvYmxlbSBJIHNlZSBpcyB0aGF0 IHNvIGZhciwgdGhlIG1lc3NhZ2Ugd2FzOiB3aGVuIHlvdSBpbXBsZW1lbnQgYSBjYWNoZSBvbmx5 IGxvb2sgYXQgdGhlIHJlc3BvbnNlIGNvZGUgYW5kIHVzZSB0aGUgcmVxdWVzdCBvcHRpb25zIGZv ciB0aGUgY2FjaGUga2V5LiBOb3cgd2UgaGF2ZSBhbiBleHRlbnNpb24gZHJhZnQgdGhhdCBhbHNv IHJlcXVpcmVzIGNhY2hlIGltcGxlbWVudGVycyB0byBsb29rIGF0IHRoZSByZXF1ZXN0IG1ldGhv ZC4uLg0KDQo= From nobody Fri Aug 4 17:13:13 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9965D129B26 for ; Fri, 4 Aug 2017 17:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=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 bMV8hF_wTRoa for ; Fri, 4 Aug 2017 17:13: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 4EE94129AEB for ; Fri, 4 Aug 2017 17:13:10 -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 v750D6Jq028680 for ; Sat, 5 Aug 2017 02:13:07 +0200 (CEST) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xPPQB4x5zzDLl2 for ; Sat, 5 Aug 2017 02:13:06 +0200 (CEST) Received: by mail-io0-f171.google.com with SMTP id c74so11033514iod.4 for ; Fri, 04 Aug 2017 17:13:06 -0700 (PDT) X-Gm-Message-State: AHYfb5hP7Q6wXpYlk9pFuLd14ED0AItdczcpcNgwXnrCOaVoTQFia9uC k+arFqezuFwJ+ChgY1cUUdBDNrQbWA== X-Received: by 10.107.173.150 with SMTP id m22mr4372745ioo.264.1501891984940; Fri, 04 Aug 2017 17:13:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.38.14 with HTTP; Fri, 4 Aug 2017 17:12:24 -0700 (PDT) In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> <1F7F6477-95E1-4E83-99B5-5A3DEE040066@tzi.org> <55877B3AFB359744BA0F2140E36F52B55BA7DE5A@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B55BA7DECD@MBX110.d.ethz.ch> From: Klaus Hartke Date: Sat, 5 Aug 2017 02:12:24 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Kovatsch Matthias Cc: Carsten Bormann , core WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] draft-ietf-core-etch: Response Code for FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 00:13:11 -0000 Klaus Hartke wrote: > the only viable way > right now is to always include the request method, all applicable > request options, and the request payload in the cache key. Unless we update RFC 7252 with something like this: +---------------------------------+-----------+---+---+---+ | Response Code | Cacheable | M | O | P | +---------------------------------+-----------+---+---+---+ | 2.01 Created | no* | | | | | 2.02 Deleted | no* | | | | | 2.03 Valid | no* | | | | | 2.04 Changed | no* | | | | | 2.05 Content | yes | x | x | x | | 4.00 Bad Request | yes | x | x | x | | 4.01 Unauthorized | yes | x | x | | | 4.02 Bad Option | yes | x | x | | | 4.03 Forbidden | yes | | x | | | 4.04 Not Found | yes | | x | | | 4.05 Method Not Allowed | yes | x | | | | 4.06 Not Acceptable | yes | x | x | | | 4.12 Precondition Failed | yes | x | x | | | 4.13 Request Entity Too Large | yes | x | x | x | | 4.15 Unsupported Content-Format | yes | x | x | | | 5.00 Internal Server Error | yes | x | x | x | | 5.01 Not Implemented | yes | x | x | x | | 5.02 Bad Gateway | yes | x | x | x | | 5.03 Service Unavailable | yes | | | | | 5.04 Gateway Timeout | yes | | | | | 5.05 Proxying Not Supported | yes | x | x | | +---------------------------------+-----------+---+---+---+ * = not cacheable, but has some effect on cache entries; M = request method is part of the cache key; O = applicable request options are part of the cache key; P = request payload is part of the cache key. Klaus From nobody Fri Aug 4 19:40:07 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9551412EAF0 for ; Fri, 4 Aug 2017 19:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=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 dKi6agxVq66B for ; Fri, 4 Aug 2017 19:40:03 -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 18D64124B18 for ; Fri, 4 Aug 2017 19:40:02 -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 v752e0oa020006 for ; Sat, 5 Aug 2017 04:40:00 +0200 (CEST) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xPSgg5tSQzDLmg for ; Sat, 5 Aug 2017 04:39:59 +0200 (CEST) Received: by mail-it0-f53.google.com with SMTP id 77so15309196itj.1 for ; Fri, 04 Aug 2017 19:39:59 -0700 (PDT) X-Gm-Message-State: AIVw112lDe5ndJG8WNfgR9Ks923TNlyeOYU8DHjU66GN7JTRoer65GN6 u6dW8Op3mmNgkYTcueTZAc7roCNCjg== X-Received: by 10.36.86.199 with SMTP id o190mr3764451itb.139.1501890158422; Fri, 04 Aug 2017 16:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.38.14 with HTTP; Fri, 4 Aug 2017 16:41:57 -0700 (PDT) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B55BA7DECD@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> <1F7F6477-95E1-4E83-99B5-5A3DEE040066@tzi.org> <55877B3AFB359744BA0F2140E36F52B55BA7DE5A@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B55BA7DECD@MBX110.d.ethz.ch> From: Klaus Hartke Date: Sat, 5 Aug 2017 01:41:57 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Kovatsch Matthias Cc: Carsten Bormann , core WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] draft-ietf-core-etch: Response Code for FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 02:40:05 -0000 Matthias Kovatsch wrote: > The problem I see is that so far, the message was: when you implement a c= ache only look at the response code and use the request options for the cac= he key. Now we have an extension draft that also requires cache implementer= s to look at the request method... >From [1]: For a presented request, a CoAP endpoint MUST NOT use a stored response, unless: o the presented request method and that used to obtain the stored response match, [...] So the request method is already always part of the cache key. [1] always confuses me a bit though, because it only considers applicable options to form the cache key, and requires the request method to match in addition to that. It would have been simpler to define the cache key to include everything that must match. [1] does not include the request payload in the cache key, but that turned out to be likely a bug: If the response depends on the request payload, then the request payload should really be part of the cache key. On the other hand, if the response does not depend on the request payload (e.g., a 4.04 Not Found response), then the request payload should not be part of the cache key (and, in the case of a 4.04, the cache key should probably not even include the request method). However, RFC 7252 does not define any mechanism that tells a cache what parts of a request a response depends on, so the only viable way right now is to always include the request method, all applicable request options, and the request payload in the cache key. Klaus [1] https://tools.ietf.org/html/rfc7252#section-5.6 From nobody Sat Aug 5 10:37:42 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50814131DA1 for ; Sat, 5 Aug 2017 10:37:41 -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 ujEa_51EVd3Z for ; Sat, 5 Aug 2017 10:37:39 -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 31033127058 for ; Sat, 5 Aug 2017 10:37:38 -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.361.1; Sat, 5 Aug 2017 19:37:24 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0361.001; Sat, 5 Aug 2017 19:37:36 +0200 From: "Kovatsch Matthias" To: Klaus Hartke CC: Carsten Bormann , core WG Thread-Topic: draft-ietf-core-etch: Response Code for FETCH Thread-Index: AdMNa3ofcgeYYfMkT5eYqCcDYbQQFf//4cWA///c67CAACi1gP//3dbwgAA4zoD//rPCUA== Date: Sat, 5 Aug 2017 17:37:35 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B55BA7F2C6@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B55BA7DE20@MBX110.d.ethz.ch> <1F7F6477-95E1-4E83-99B5-5A3DEE040066@tzi.org> <55877B3AFB359744BA0F2140E36F52B55BA7DE5A@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B55BA7DECD@MBX110.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-etch: Response Code for FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 17:37:41 -0000 PiBGcm9tIFsxXToNCj4gDQo+ICAgIEZvciBhIHByZXNlbnRlZCByZXF1ZXN0LCBhIENvQVAgZW5k cG9pbnQgTVVTVCBOT1QgdXNlIGEgc3RvcmVkDQo+ICAgIHJlc3BvbnNlLCB1bmxlc3M6DQo+IA0K PiAgICBvICB0aGUgcHJlc2VudGVkIHJlcXVlc3QgbWV0aG9kIGFuZCB0aGF0IHVzZWQgdG8gb2J0 YWluIHRoZSBzdG9yZWQNCj4gICAgICAgcmVzcG9uc2UgbWF0Y2gsDQo+IA0KPiAgICBbLi4uXQ0K PiANCj4gU28gdGhlIHJlcXVlc3QgbWV0aG9kIGlzIGFscmVhZHkgYWx3YXlzIHBhcnQgb2YgdGhl IGNhY2hlIGtleS4NCg0KT2theSwgSSBndWVzcyB0aGUgd2hvbGUgYmVhdXR5IEkgZXhwZWN0ZWQg YmVoaW5kIHRoaXMgIlVubGlrZSBIVFRQIiBwaGlsb3NvcGh5IGlzIGFjdHVhbGx5IG5vdCB0aGVy ZS4gQSBGRVRDSCB3aXRob3V0IHBheWxvYWQgY2Fubm90IGJlIGFuc3dlcmVkIHdpdGggYSBwZXJm ZWN0bHkgbmljZSAyLjA1IGluIHRoZSBjYWNoZSwgYSBHRVQgY2Fubm90IGJlIGFuc3dlcmVkIHdp dGggYSAyLjA1IGZyb20gYSByZXNwb25zZSB0byBQT1NULCBldGMuDQoNCkNhY2hpbmcgYXBwZWFy cyB0byBiZSBhIGJpdCB0b28gY29tcGxleCB0byBmbG9yaXNoIHdpdGhvdXQgYSBuZXcgZG9jdW1l bnQuLi4gUHVoLCBpZiBvbmx5IHRoZXJlIHdhcyB0aW1lLg0K From nobody Sun Aug 6 16:19:56 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2415129AE7 for ; Sun, 6 Aug 2017 16:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 ZgiHB6rZkp-W for ; Sun, 6 Aug 2017 16:19:52 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EAB12009C for ; Sun, 6 Aug 2017 16:19:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1502061564; h=from:subject:to:date:message-id; bh=Pf6l8NlYWZYbNNfdWFlcbzZqerUNwswqeXd7TyaA0Rk=; b=NiHQ47Cml0DtOtcEEX4FsqCH4toEgeDgEf1MJtR7d/1GzAVzGhZcE09Ofd5UjcqYo6nCLewHh4M yslpPrM/7jB839A+P+A6rQZaH7pYvswKoEYqZTwix4Ho2wsDCkYwebPAzEb8eqsfRDAY9srFDxLv3 gjEA/dm8gQ1raH9RS1oLg5IVp4rTVM7GCxz/tfvvaA4jabLPNWgBX9opawwAfO5w8WhtcSa6rKj8b wm7DM+x7QQcn9R4V78fqX9vpJi39LtyK+JoDeFzfWd+yp/tVDUe6Ep2krWVGyPe9L4EehjnImqn1T 4K+2bZoTH0DFiEh7xv/gXUriXEwgwJgYQ4Uw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 6 Aug 2017 16:19:19 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 6 Aug 2017 16:19:16 -0700 From: Jim Schaad To: Date: Sun, 6 Aug 2017 16:19:33 -0700 Message-ID: <000201d30f0a$7a9597b0$6fc0c710$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMPCeX84gHvpwn5RzSmnJhkOgp7SQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Is ct an occur once attribute X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 23:19:54 -0000 I was expecting to see "ct" as being defined to only occur once, however looking at section 7.2.1 of RFC 7252 there is no such statement. Is this something that was intended or is it a missing statement in the document. It does say that it allows or space separated values, and other attributes such as "rt" do make the only occur once statement. Jim From nobody Sun Aug 6 23:46:01 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70754128BC8 for ; Sun, 6 Aug 2017 23:46:00 -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 Rd8E9vE5MY2O for ; Sun, 6 Aug 2017 23:45:58 -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 64E40120227 for ; Sun, 6 Aug 2017 23:45:58 -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 v776jKA1011085; Mon, 7 Aug 2017 08:45:20 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xQp1r1QrHzDMKs; Mon, 7 Aug 2017 08:45:20 +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: <000201d30f0a$7a9597b0$6fc0c710$@augustcellars.com> Date: Mon, 7 Aug 2017 08:45:19 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 523781118.714921-d45eb09b40881fa79567bb33435582bc Content-Transfer-Encoding: quoted-printable Message-Id: <7123FA3B-1170-40D5-BAD6-04AE64101CB6@tzi.org> References: <000201d30f0a$7a9597b0$6fc0c710$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Is ct an occur once attribute X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 06:46:01 -0000 Hi Jim, On Aug 7, 2017, at 01:19, Jim Schaad wrote: >=20 > I was expecting to see "ct" as being defined to only occur once, = however > looking at section 7.2.1 of RFC 7252 there is no such statement. >=20 > Is this something that was intended or is it a missing statement in = the > document. It does say that it allows or space separated values, and = other > attributes such as "rt" do make the only occur once statement. Good catch. I believe the lack of this statement is an oversight; ct is = intended to be an occur-once link target attribute. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 7 11:10:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2C13261B for ; Mon, 7 Aug 2017 11:05:31 -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, 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 fCWD1f1OggIU for ; Mon, 7 Aug 2017 11:05:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E491325F8 for ; Mon, 7 Aug 2017 11:05:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 16CE7B80D92; Mon, 7 Aug 2017 11:05:19 -0700 (PDT) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, cabo@tzi.org, jaime@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@augustcellars.com, core@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170807180519.16CE7B80D92@rfc-editor.org> Date: Mon, 7 Aug 2017 11:05:19 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 07 Aug 2017 11:10:01 -0700 Subject: [core] [Technical Errata Reported] RFC7252 (5078) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:05:31 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5078 -------------------------------------- Type: Technical Reported by: Jim Schaad Section: 7.2.1 Original Text ------------- The Content-Format code attribute MAY include a space-separated sequence of Content-Format codes, indicating that multiple content-formats are available. The syntax of the attribute value is summarized in the production "ct- value" in Figure 12, where "cardinal", "SP", and "DQUOTE" are defined as in [RFC6690]. Corrected Text -------------- The Content-Format code attribute MAY include a space-separated sequence of Content-Format codes, indicating that multiple content-formats are available. The Content-Format code attribute MUST NOT appear more than once in a link. The syntax of the attribute value is summarized in the production "ct-value" in Figure 12, where "cardinal", "SP", and "DQUOTE" are defined as in [RFC6690]. Notes ----- Insert a sentence that says that the code MUST NOT appear more than once. This appears to be what was intended, but not stated, by the authors since it supports the space separated values to appear in a single attribute value. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Mon Aug 7 21:20:41 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BF7126E3A; Mon, 7 Aug 2017 21:20:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150216603910.12471.18374874372296069327@ietfa.amsl.com> Date: Mon, 07 Aug 2017 21:20:39 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 04:20:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Alexander Pelov Abhinav Somaraju Randy Turner Ana Minaburo Filename : draft-ietf-core-yang-cbor-05.txt Pages : 32 Date : 2017-08-07 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 10 10:57:30 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153631323BC; Thu, 10 Aug 2017 10:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 i0-qt10Bd5wu; Thu, 10 Aug 2017 10:57:25 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C0D131D1A; Thu, 10 Aug 2017 10:57:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1502387818; h=from:subject:to:date:message-id; bh=6Qd06VIi2BaUnu+jv6chfuKbnREUZQFKf4vfTSPdRFo=; b=IAKCfav7NhlHVB1CZ0m5n3K/L4yRumEomw4MAoEugfpTBfGuogrtKOg+GZXu3aA9JwUZqmQ6N3E e4ymY6rnqpCtTPpt/hh8GGXPlH5HqRM7hyK+RohLjRBc+wS7U2d2BX6OO6zdnPQEsqfBAEaKqikXE k5fruAKqzLBRWXRTHkWJYGycQV6NCaWFuYfALA9uSmd71bpuuvCARs2P8nQEbOVaLhF/NVa6b+BkM xXYdC8axBRDISfNFVb60ZwPjPdswDPUlmFM8R5PbVMbFk3lQj7MrldZaiwt4yl/zeAT30sXEA2Z3o 9ocoga2Mrn1LIB3XVV8/0uSbHYuGMFkvyqRA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 10 Aug 2017 10:56:56 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 10 Aug 2017 10:56:32 -0700 From: Jim Schaad To: CC: Date: Thu, 10 Aug 2017 10:56:54 -0700 Message-ID: <008e01d31202$0eea5870$2cbf0950$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMRci0Luk2lCuSlSeikhZNrR/U7SQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Comments on draft-ietf-core-resource-directory-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 17:57:29 -0000 1. In section 5.2 para 2 - Not sure if this is wrong or not. However I would think that rt=core.rd-group is used to discover the URI path for RD group operations not rt=core.gp. I note that core.gp is not listed in the set of valid rt values in the template. 2. I am unclear of the proper interactions of the following items: * The anchor attribute - does it override the context query parameter * What happens if a full URI is given as the target? How does this interact w/ the context query parameter? 3. For simple registration. If the client has needed to find the RD so it knows where to do the post, why is the post not done to the RD rather than to the /.well-know/core point? 4. It is not clear to me what if the patch payload of {data} should be accepted. Looking at the document as JSON, there is always an array wrapper around it so that this template never matches the resulting document. It seems as if this should always be [{data}] instead. Is there an implicit add of the array if absent? If you have a pattern of {data} and you match multiple items, is that an error? 5. Is there an implication that if the resources associated with an endpoint expire, that the endpoint expires from all of its groups as well? Is there a different way that endpoints are registered with the RD? 6. Can an endpoint register zero items with an RD? 7. should there be some text on interactions between ETag and page/count query parameters? What happens if there is a an update of the registry in the middle of doing a sequence of queries about the links using these options? Jim Typo s/ecample.com/example.com/ From nobody Fri Aug 11 09:34:24 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7B113242C; Fri, 11 Aug 2017 09:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 jdsjHnNQ7bc4; Fri, 11 Aug 2017 09:34:20 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EE61321BE; Fri, 11 Aug 2017 09:34:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1502469225; h=from:subject:to:date:message-id; bh=vZiutWYWwDIqMf81+4d6GU+bPzniGwKbxV4yNdIe3U4=; b=ZOL2k7vSZsi8GI2z3K8cZmPMSjsYt2DXGxNsTcXwFWhDGPEKPOKcfxNdume8PoZ3MvQ19IYD7dE dg8hTDZNFoKw07L6o73MO58Qy2gfCgYDEHvin63b1JqIQiEOMbtPUNPK8bgjKRRnQma4AAjXdLDux MzlP4kA+8TTpXe+EIUgCFYeRzUbT54qEhX136Y91XwLUcWjcKSrmImvXIEMC0JVtOezeLqzswGz6X isiRF8MJ7vF3q+xRq956C9aKql7q+NCd9MzcebL2Cad5BbQV832uggKknv4rwswMeTZwATk15ic2h Xt4rWI5GeLGaykGFDFGbsq6UYRe6DGYY96KQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 11 Aug 2017 09:33:45 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 11 Aug 2017 09:33:44 -0700 From: Jim Schaad To: CC: Date: Fri, 11 Aug 2017 09:34:03 -0700 Message-ID: <00eb01d312bf$a8548040$f8fd80c0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMSv2Tn2SgBy9/XQxK1bC5PpHKmUw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] draft-ietf-core-resource-directory is update atomic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 16:34:22 -0000 I am going through and figuring out how to implement this specification and I came up with a questions on how things work. 1. The document says that PATCH is supported. What about iPATCH? 2. Are PATCH and POST update operations atomic? Is a partial update permitted or is that not allowed? Jim From nobody Mon Aug 14 00:56:33 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD90131D19; Mon, 14 Aug 2017 00:56:31 -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_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 j2b-6eTkniYZ; Mon, 14 Aug 2017 00:56:29 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (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 9259E13203D; Mon, 14 Aug 2017 00:56:27 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud7.xs4all.net with ESMTPA id hAEZdBzI2Ar7rhAEZd10va; Mon, 14 Aug 2017 09:56:26 +0200 Received: from ip565c6c1e.direct-adsl.nl ([86.92.108.30]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 14 Aug 2017 09:56:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 Aug 2017 09:56:23 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <00eb01d312bf$a8548040$f8fd80c0$@augustcellars.com> References: <00eb01d312bf$a8548040$f8fd80c0$@augustcellars.com> Message-ID: <0205144dc49c2c291e42e035c95765c5@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfPvwvdajfTXruSfvqYc1C4tRaWfFlOd8oSz9dyNb7Dfjuu89qkxxWVpRS0jRdtul0pFCuynZ67FyDayxLU/RphAriGEpa1xhrgJHwL8Ypi0V4gSKvmgj jg6cUp+74Ni23ASeOqvdKdLaqva2xUg5VrhT4fqeSW7Fpui97c855sxmVxtoge+FWzgFPrU6ddftKVX9PcnenANiapUsv8uPkfSBcksKxMGCEeTAzDbtwyi7 sazPHlYrNBHclV1KPLRqXA== Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory is update atomic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 07:56:31 -0000 Thanks Jim, I try to answer below. I hope I understand the meaning correctly. Jim Schaad schreef op 2017-08-11 18:34: > I am going through and figuring out how to implement this specification > and > I came up with a questions on how things work. > > 1. The document says that PATCH is supported. What about iPATCH? Good remark. The document should probably state that both are allowed but iPATCH is preferred. > > 2. Are PATCH and POST update operations atomic? The spec says that registrations need to be idempotent, that is not repeated for the other operations (but implied?). The update changes the lt; you might argue that this is not an idempotent operation as the effects at a given time changes after a second invocation of the same update. Nevertheless, I would call it idempotent. Idempotency => atomic? (as meaning: all or nothing) > Is a partial update > permitted or is that not allowed? Partial updates are permitted for PATCH and also for POST under the conditions specified in section 5.4.1 Or is your argument that POST should not be used for partial updates. > > Jim Hope this helps. peter > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Aug 14 07:42:07 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB5413226B; Mon, 14 Aug 2017 07:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 2PDkPqJ95STi; Mon, 14 Aug 2017 07:42:04 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5B7132250; Mon, 14 Aug 2017 07:42:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1502721695; h=from:subject:to:date:message-id; bh=Y3IAEFqTDHFFPkO4uowQ7tndmfAUhh5gOQUyx3uRLLI=; b=ZySbZWG73jhqJ7etqdqnLLrzuHkjsSUu0f8FOWNw4fS+S0g+FNdmtlzVRLtXu45ivuwh+NpRE6n FZm+y4Uc2XQjqJY9U0QbV5wnS8FzIC1y0F+U8gj77Wv8nCegNeU8LoygnED59U64OF1iHzNXiE8// Ks/urgt2GorhCxgVZcmhNmheOVTf/x+G62cN1Dq8qIMn8Sso4ZTtapRCuY77WEJxpSN+JBnC1NlZa +QuhAIA0ZdxN/yBatW/q9oHM0IpfMf7+nHsdxnW7LA6opqvv0eSsxxD+u/nytaGc21FwCK7Bcr6fl hqp3VM/JvlQIT+TKvBS4KCEUWBSVk1G7TYdQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 14 Aug 2017 07:41:34 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 14 Aug 2017 07:41:30 -0700 From: Jim Schaad To: CC: , References: <00eb01d312bf$a8548040$f8fd80c0$@augustcellars.com> <0205144dc49c2c291e42e035c95765c5@xs4all.nl> In-Reply-To: <0205144dc49c2c291e42e035c95765c5@xs4all.nl> Date: Mon, 14 Aug 2017 07:41:54 -0700 Message-ID: <000801d3150b$7b0efe00$712cfa00$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFc8HOCAImCnYNACzSvb2T79v3NVQIFAO9ao2ANxZA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory is update atomic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 14:42:06 -0000 What I was looking at with atomic is along the lines of. Half way through the update I find that an error will result. Do I throw away all the of the updates that I have done so far? Jim > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Monday, August 14, 2017 12:56 AM > To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org > Subject: Re: [core] draft-ietf-core-resource-directory is update atomic > > Thanks Jim, > > I try to answer below. I hope I understand the meaning correctly. > > Jim Schaad schreef op 2017-08-11 18:34: > > I am going through and figuring out how to implement this > > specification and I came up with a questions on how things work. > > > > 1. The document says that PATCH is supported. What about iPATCH? > Good remark. The document should probably state that both are allowed but > iPATCH is preferred. > > > > 2. Are PATCH and POST update operations atomic? > The spec says that registrations need to be idempotent, that is not repeated > for the other operations (but implied?). > The update changes the lt; you might argue that this is not an idempotent > operation as the effects at a given time changes after a second invocation of > the same update. Nevertheless, I would call it idempotent. > Idempotency => atomic? (as meaning: all or nothing) > > Is a partial update > > permitted or is that not allowed? > Partial updates are permitted for PATCH and also for POST under the > conditions specified in section 5.4.1 Or is your argument that POST should not > be used for partial updates. > > > > Jim > > Hope this helps. > > peter > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 16 00:19:58 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C9B13263E; Wed, 16 Aug 2017 00:19:57 -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_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 AUPLnApS7-AL; Wed, 16 Aug 2017 00:19:54 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 8CFC8132645; Wed, 16 Aug 2017 00:19:50 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud7.xs4all.net with ESMTPA id hscFdTZcTAr7rhscFd8W5T; Wed, 16 Aug 2017 09:19:48 +0200 Received: from ip565c6c1e.direct-adsl.nl ([86.92.108.30]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 16 Aug 2017 09:19:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 16 Aug 2017 09:19:47 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <008e01d31202$0eea5870$2cbf0950$@augustcellars.com> References: <008e01d31202$0eea5870$2cbf0950$@augustcellars.com> Message-ID: <83dfdae55629cc8c18dba0a8fc517fff@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfExg5yU09dza9HrZhDXJjJUjYVIYyxL6MV4H7xzmKG/vZAaCZD1aVFru34Qp/G5cYREE7gPBBfklb9cudq56iEHQNqw/cOK9tOXoybm8ytJfpFgzgYW8 BHnDTf54bs8mKayekNdlHTurWmJwuVeM0984V3s673p1iGLYrFeIzUlfD1NrL1YaSFXMMs/3MV6KeW+gGfixAWmg/L2xjv1NWrAZfRVLG5FVLe/gG89fA+aA vf/c758jq7mFjDFRHXrHiQ== Archived-At: Subject: Re: [core] Comments on draft-ietf-core-resource-directory-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 07:19:57 -0000 Hi Jim, thanks for these remarks, they do help in getting the text better. Jim Schaad schreef op 2017-08-10 19:56: > 1. In section 5.2 para 2 - Not sure if this is wrong or not. However > I > would think that rt=core.rd-group is used to discover the URI path for > RD > group operations not rt=core.gp. I note that core.gp is not listed in > the > set of valid rt values in the template. absolutely, spot on. archaeological remains to be removed. > > 2. I am unclear of the proper interactions of the following items: > * The anchor attribute - does it override the context query parameter > * What happens if a full URI is given as the target? How does this > interact w/ the context query parameter? @Michael or @Christian, can you react; my web vocabulary does not always suffice. > > 3. For simple registration. If the client has needed to find the RD > so it > knows where to do the post, why is the post not done to the RD rather > than > to the /.well-know/core point? section 5.3.1 refers to 5.3.2 where the client posts to the RD; and the RD reacts. Do you want more explicit text in 5.3.1? OR 5.3.1 and 5.3.2 integrated? > > 4. It is not clear to me what if the patch payload of {data} should > be > accepted. Looking at the document as JSON, there is always an array > wrapper > around it so that this template never matches the resulting document. > It > seems as if this should always be [{data}] instead. Is there an > implicit > add of the array if absent? If you have a pattern of {data} and you > match > multiple items, is that an error? I'm sorry, not to understand this remark. we refer to section 5.4.4? The template specifies nothing about the payload apart from the format application/merge-patch+json which is defined in RFC 7396. RFC7396 allows arrays and simple objects in curly brackets in the payload Is the example incorrect? Do you want to remove the array brackets because it is a single object? > > 5. Is there an implication that if the resources associated with an > endpoint expire, that the endpoint expires from all of its groups as > well? > Is there a different way that endpoints are registered with the RD? Will put in additional text that removal of endpoint implies removal from groups as well. > > 6. Can an endpoint register zero items with an RD? I expect so. Text can be added that registration of an endpoint with zero links does not create the endpoint. > > 7. should there be some text on interactions between ETag and > page/count > query parameters? What happens if there is a an update of the registry > in > the middle of doing a sequence of queries about the links using these > options? Correct remark. In the CoMI draft I added warning text about interleaving with the block option. Do you consider that a warning note in the text is sufficient? Getting interleavings handled correctly may lead to massive amounts of code (and specification text); so to me a warning seems sufficient. > > > Jim > > > Typo > s/ecample.com/example.com/ Noted > > many thanks, hope this meets your questions (partially) Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 16 20:03:49 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166A413217D; Wed, 16 Aug 2017 20:03:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 u7opcR0pIHCm; Wed, 16 Aug 2017 20:03:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2496132638; Wed, 16 Aug 2017 20:03:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BAA02201AC; Wed, 16 Aug 2017 23:06:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1D77780B17; Wed, 16 Aug 2017 23:03:36 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org, core@ietf.org reply-to: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 03:03:41 -0000 --=-=-= Content-Type: text/plain Hi. I was trying to generate some code to implement a YANG model in CBOR using: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 which quite clearly says that I'm to use a CBOR map type (5). Except that my understanding of SIDs is that they are deltas for the key part. (My other problem is that I don't have a SID until the SID document progresses, but I can use the experimental range for now) In many languages for which there are easy to use CBOR bindings, ruby, python, perl, js, java, the CBOR map translates to a hash or directionary. So I wondered how I could do deltas on keys in such an unordered structure... My reading of: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 about type 5, and then I read: https://tools.ietf.org/html/rfc7049#section-3.7 which says: The CBOR data model for maps does not allow ascribing semantics to the order of the key/value pairs in the map representation. so, it seems that the SID concept as described in ietf-core-yang-cbor can not work using the map type!!! At first I thought it was just a language binding issue; that I needed ordered sets of some kind, but no... It violates the above property. Solutions that I can imagine: 1) use an array of 2-element arrays (requires an extra byte for each inner array!) 2) use an array 2x the size, and let the application reconstruct things as a hash after taking in account the SID delta. 3) use one of the discussed point/multi-dimensional-array/etc. structures that I believe were presented at IETF99... I think draft-jroatch-cbor-tags was the document. I think that I favour (2), as being the most expedient and easiest to implement. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmVB4cACgkQgItw+93Q 3WWl8ggAnqlA8iHXjQiYSuIQ2t+9go5uw1bpM4XIAlbcThozf2ow1OZgC6hQ7JXo Hq7qbL67/SrbOBXh0TGGvmPxxuH9pLuhivWNO+xQ7QtPP2b8gOt1CSwMtDE3E4Kq xl+kZi9p/19HIGUEUiWXX/1V2X7vxaVXGGvLfF0k4iD9I57je9bJnHXyA9LH92Zi KSC6CXgFMYTgYe2Ha8Kv1qRxlq78fPHbZtHuBbAglU4d1+qTz9yjDt3OBRcec5tf a/TOB9QtYte0V4c6W7lRMrDvg5pPOt252gnrOBoXp8EL8t7zA4MV2vLbphFhxzeN iclfi0sYRZQgvI9olc7z0IjLFEdG8g== =/I+1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 16 22:48:35 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1046124E15; Wed, 16 Aug 2017 22:48:28 -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 z0hjTWoi84vJ; Wed, 16 Aug 2017 22:48:26 -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 DB3281323B2; Wed, 16 Aug 2017 22:48:25 -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 v7H5mLbV019929; Thu, 17 Aug 2017 07:48:21 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xXwHT0m9RzDLbQ; Thu, 17 Aug 2017 07:48:21 +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: <13753.1502939016@obiwan.sandelman.ca> Date: Thu, 17 Aug 2017 07:48:20 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 524641700.331557-e714c0e8394a04a63bb401ec92b1aabd Content-Transfer-Encoding: quoted-printable Message-Id: <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> References: <13753.1502939016@obiwan.sandelman.ca> To: core WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:48:29 -0000 Hi Michael, SID deltas in maps are parent-referenced (and not sibling-referenced) = for this reason. Do you see anything that makes you think they are sibling-referenced? That would indeed not work in maps. (We discussed using one or more of your solutions for introducing = =E2=80=9Cordered maps=E2=80=9D, but then it seemed parent-referenced was = good enough.) Gr=C3=BC=C3=9Fe, Carsten > On Aug 17, 2017, at 05:03, Michael Richardson = wrote: >=20 >=20 > Hi. I was trying to generate some code to implement a YANG model in > CBOR using: > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 >=20 > which quite clearly says that I'm to use a CBOR map type (5). Except = that > my understanding of SIDs is that they are deltas for the key part. > (My other problem is that I don't have a SID until the SID document > progresses, but I can use the experimental range for now) >=20 > In many languages for which there are easy to use CBOR bindings, ruby, > python, perl, js, java, the CBOR map translates to a hash or = directionary. > So I wondered how I could do deltas on keys in such an unordered = structure... >=20 > My reading of: > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 > about type 5, and then I read: > https://tools.ietf.org/html/rfc7049#section-3.7 >=20 > which says: > The CBOR data model for maps does not allow ascribing semantics to > the order of the key/value pairs in the map representation. >=20 > so, it seems that the SID concept as described in ietf-core-yang-cbor = can not > work using the map type!!! > At first I thought it was just a language binding issue; that I needed > ordered sets of some kind, but no... It violates the above property. >=20 > Solutions that I can imagine: > 1) use an array of 2-element arrays (requires an extra byte for each = inner > array!) > 2) use an array 2x the size, and let the application reconstruct = things as a > hash after taking in account the SID delta. > 3) use one of the discussed point/multi-dimensional-array/etc. = structures > that I believe were presented at IETF99... I think = draft-jroatch-cbor-tags > was the document. >=20 > I think that I favour (2), as being the most expedient and easiest to = implement. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Aug 16 23:54:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E77126B7E; Wed, 16 Aug 2017 23:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dWxJ2T-GL_Bm; Wed, 16 Aug 2017 23:54:33 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F459124BAC; Wed, 16 Aug 2017 23:54:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 58BFF6AA; Thu, 17 Aug 2017 08:54:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id GP2eaB5w8V7s; Thu, 17 Aug 2017 08:54:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Aug 2017 08:54:32 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36BEF200C5; Thu, 17 Aug 2017 08:54:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5g2w2uE5MPh8; Thu, 17 Aug 2017 08:54:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 963DE200C3; Thu, 17 Aug 2017 08:54:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 317F3404117B; Thu, 17 Aug 2017 08:54:30 +0200 (CEST) Date: Thu, 17 Aug 2017 08:54:30 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: core WG , cbor@ietf.org Message-ID: <20170817065430.wp3gqiui37f26ki6@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , core WG , cbor@ietf.org References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 06:54:36 -0000 Carsten, if I search for 'delta' or 'reference SID', I do not find text that says what the reference SID is. Where do I have to look at to understand that delta SIDs are parent-referenced? /js PS: Why do we have this, I mean, why is there a $ for some of these? pattern 'Module|Submodule|feature|' + 'identity$|node$|notification$|rpc$|action$'; Why is this not an enum in the first place? And why are the first two capitalized? PS: Why do you not import yang-identifier from ietf-yang-types? On Thu, Aug 17, 2017 at 07:48:20AM +0200, Carsten Bormann wrote: > Hi Michael, > > SID deltas in maps are parent-referenced (and not sibling-referenced) for this reason. > Do you see anything that makes you think they are sibling-referenced? > That would indeed not work in maps. > > (We discussed using one or more of your solutions for introducing “ordered maps”, but then it seemed parent-referenced was good enough.) > > Grüße, Carsten > > > > On Aug 17, 2017, at 05:03, Michael Richardson wrote: > > > > > > Hi. I was trying to generate some code to implement a YANG model in > > CBOR using: > > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 > > > > which quite clearly says that I'm to use a CBOR map type (5). Except that > > my understanding of SIDs is that they are deltas for the key part. > > (My other problem is that I don't have a SID until the SID document > > progresses, but I can use the experimental range for now) > > > > In many languages for which there are easy to use CBOR bindings, ruby, > > python, perl, js, java, the CBOR map translates to a hash or directionary. > > So I wondered how I could do deltas on keys in such an unordered structure... > > > > My reading of: > > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2 > > about type 5, and then I read: > > https://tools.ietf.org/html/rfc7049#section-3.7 > > > > which says: > > The CBOR data model for maps does not allow ascribing semantics to > > the order of the key/value pairs in the map representation. > > > > so, it seems that the SID concept as described in ietf-core-yang-cbor can not > > work using the map type!!! > > At first I thought it was just a language binding issue; that I needed > > ordered sets of some kind, but no... It violates the above property. > > > > Solutions that I can imagine: > > 1) use an array of 2-element arrays (requires an extra byte for each inner > > array!) > > 2) use an array 2x the size, and let the application reconstruct things as a > > hash after taking in account the SID delta. > > 3) use one of the discussed point/multi-dimensional-array/etc. structures > > that I believe were presented at IETF99... I think draft-jroatch-cbor-tags > > was the document. > > > > I think that I favour (2), as being the most expedient and easiest to implement. > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 17 00:04:14 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48A13217D; Thu, 17 Aug 2017 00:04:13 -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 4kh5eI1tQF0C; Thu, 17 Aug 2017 00:04:12 -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 B34E61326F6; Thu, 17 Aug 2017 00:04:11 -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 v7H747wm024055; Thu, 17 Aug 2017 09:04:08 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xXxyv5QLyzDLcR; Thu, 17 Aug 2017 09:04:07 +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: <20170817065430.wp3gqiui37f26ki6@elstar.local> Date: Thu, 17 Aug 2017 09:04:07 +0200 Cc: core WG , cbor@ietf.org X-Mao-Original-Outgoing-Id: 524646247.003675-9304050efac4903fa3d2a088a0851070 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> <20170817065430.wp3gqiui37f26ki6@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:04:13 -0000 On Aug 17, 2017, at 08:54, Juergen Schoenwaelder = wrote: >=20 > Carsten, >=20 > if I search for 'delta' or 'reference SID', I do not find text that > says what the reference SID is. Where do I have to look at to > understand that delta SIDs are parent-referenced? 4.2.1 (of yang-cbor) says: o The delta value is equal to the SID of the current schema node minus the SID of the parent schema node. When no parent exists in But maybe there is indeed potential for editorial improvement here. Clearly phrasing this always in terms of the reference SID, and then = saying where that reference SID comes from (e.g., zero at the root of = the tree), might help. This probably also should be buttressed some more by examples. > /js >=20 > PS: Why do we have this, I mean, why is there a $ for some of these? >=20 > pattern 'Module|Submodule|feature|' + > 'identity$|node$|notification$|rpc$|action$'; >=20 > Why is this not an enum in the first place? And why are the > first two capitalized? (Now you are in core-sid, I think.) Good questions; I=E2=80=99d defer to the YANG specialists here. > PS: Why do you not import yang-identifier from ietf-yang-types? Ditto. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 17 00:29:10 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190A51327EC; Thu, 17 Aug 2017 00:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 S9GgEMCPwgii; Thu, 17 Aug 2017 00:29:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24552132436; Thu, 17 Aug 2017 00:29:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E9914EF9; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id UjP5eNr_HqSw; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8D2F200C5; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4jCkAb8urc2C; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CA36200C3; Thu, 17 Aug 2017 09:29:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C82D0404125E; Thu, 17 Aug 2017 09:29:03 +0200 (CEST) Date: Thu, 17 Aug 2017 09:29:03 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: core WG , cbor@ietf.org Message-ID: <20170817072903.sce5vxgckv3q3njt@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , core WG , cbor@ietf.org References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> <20170817065430.wp3gqiui37f26ki6@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:29:08 -0000 Carsten, I looked into core-sid to understand how sids work, I did not expect that the definition how delta sids work is in core-cbor... /js On Thu, Aug 17, 2017 at 09:04:07AM +0200, Carsten Bormann wrote: > On Aug 17, 2017, at 08:54, Juergen Schoenwaelder wrote: > > > > Carsten, > > > > if I search for 'delta' or 'reference SID', I do not find text that > > says what the reference SID is. Where do I have to look at to > > understand that delta SIDs are parent-referenced? > > 4.2.1 (of yang-cbor) says: > > o The delta value is equal to the SID of the current schema node > minus the SID of the parent schema node. When no parent exists in > > But maybe there is indeed potential for editorial improvement here. > Clearly phrasing this always in terms of the reference SID, and then saying where that reference SID comes from (e.g., zero at the root of the tree), might help. > This probably also should be buttressed some more by examples. > > > /js > > > > PS: Why do we have this, I mean, why is there a $ for some of these? > > > > pattern 'Module|Submodule|feature|' + > > 'identity$|node$|notification$|rpc$|action$'; > > > > Why is this not an enum in the first place? And why are the > > first two capitalized? > > (Now you are in core-sid, I think.) > Good questions; I’d defer to the YANG specialists here. > > > PS: Why do you not import yang-identifier from ietf-yang-types? > > Ditto. > > Grüße, Carsten > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 17 00:33:56 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F51327FE; Thu, 17 Aug 2017 00:33:54 -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 H1x8DjEefHMc; Thu, 17 Aug 2017 00:33:51 -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 692211327EC; Thu, 17 Aug 2017 00:33:51 -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 v7H7XmF7019034; Thu, 17 Aug 2017 09:33:48 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xXyd81VJszDLdK; Thu, 17 Aug 2017 09:33:48 +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: <20170817072903.sce5vxgckv3q3njt@elstar.local> Date: Thu, 17 Aug 2017 09:33:47 +0200 Cc: cbor@ietf.org, core WG X-Mao-Original-Outgoing-Id: 524648027.541033-8d9006c7919cd41c44fdc3168b152d27 Content-Transfer-Encoding: quoted-printable Message-Id: <9449DAD7-723C-46DE-96BE-6D46DE6E7BBE@tzi.org> References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> <20170817065430.wp3gqiui37f26ki6@elstar.local> <20170817072903.sce5vxgckv3q3njt@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Cbor] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:33:54 -0000 > On Aug 17, 2017, at 09:29, Juergen Schoenwaelder = wrote: >=20 > Carsten, >=20 > I looked into core-sid to understand how sids work, That document tells you how to get SIDs. > I did not expect > that the definition how delta sids work is in core-cbor=E2=80=A6 That document tells you how to encode the SIDs you have into deltas in = the CBOR serialization of YANG models. I think that is a quite reasonable division of work, but maybe again = there is potential for explaining this better editorially. One problem in the past has been that people have been referring to the = deltas as SIDs =E2=80=94 they aren=E2=80=99t, and we need to root any = remnant of that usage out of the documents. Gr=C3=BC=C3=9Fe, Carsten >=20 > /js >=20 > On Thu, Aug 17, 2017 at 09:04:07AM +0200, Carsten Bormann wrote: >> On Aug 17, 2017, at 08:54, Juergen Schoenwaelder = wrote: >>>=20 >>> Carsten, >>>=20 >>> if I search for 'delta' or 'reference SID', I do not find text that >>> says what the reference SID is. Where do I have to look at to >>> understand that delta SIDs are parent-referenced? >>=20 >> 4.2.1 (of yang-cbor) says: >>=20 >> o The delta value is equal to the SID of the current schema node >> minus the SID of the parent schema node. When no parent exists = in >>=20 >> But maybe there is indeed potential for editorial improvement here. >> Clearly phrasing this always in terms of the reference SID, and then = saying where that reference SID comes from (e.g., zero at the root of = the tree), might help. >> This probably also should be buttressed some more by examples. >>=20 >>> /js >>>=20 >>> PS: Why do we have this, I mean, why is there a $ for some of these? >>>=20 >>> pattern 'Module|Submodule|feature|' + >>> 'identity$|node$|notification$|rpc$|action$'; >>>=20 >>> Why is this not an enum in the first place? And why are the >>> first two capitalized? >>=20 >> (Now you are in core-sid, I think.) >> Good questions; I=E2=80=99d defer to the YANG specialists here. >>=20 >>> PS: Why do you not import yang-identifier from ietf-yang-types? >>=20 >> Ditto. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 From nobody Thu Aug 17 01:41:51 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D00132418; Thu, 17 Aug 2017 01:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bIVq05NQ1ZYs; Thu, 17 Aug 2017 01:41:48 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC8F132386; Thu, 17 Aug 2017 01:41:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8BC80EC1; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id LKlMrE2uwim0; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C263200C5; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mNFfvRYnEcVa; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19D5A200C3; Thu, 17 Aug 2017 10:41:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D4C4C404147F; Thu, 17 Aug 2017 10:41:45 +0200 (CEST) Date: Thu, 17 Aug 2017 10:41:45 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: cbor@ietf.org, core WG Message-ID: <20170817084145.crttu7egrha6oxoq@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , cbor@ietf.org, core WG References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> <20170817065430.wp3gqiui37f26ki6@elstar.local> <20170817072903.sce5vxgckv3q3njt@elstar.local> <9449DAD7-723C-46DE-96BE-6D46DE6E7BBE@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <9449DAD7-723C-46DE-96BE-6D46DE6E7BBE@tzi.org> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [core] [Cbor] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 08:41:50 -0000 On Thu, Aug 17, 2017 at 09:33:47AM +0200, Carsten Bormann wrote: > > > On Aug 17, 2017, at 09:29, Juergen Schoenwaelder wrote: > > > > Carsten, > > > > I looked into core-sid to understand how sids work, > > That document tells you how to get SIDs. > > > I did not expect > > that the definition how delta sids work is in core-cbor… > > That document tells you how to encode the SIDs you have into deltas in the CBOR serialization of YANG models. > Ehem, you referred to core-cbor in order to explain how deltas work, i.e. what the reference SID actually are that core-sid introduces. It is not just encoding as far as I can tell. > I think that is a quite reasonable division of work, but maybe again there is potential for explaining this better editorially. > > One problem in the past has been that people have been referring to the deltas as SIDs — they aren’t, and we need to root any remnant of that usage out of the documents. > I would appreciate if delta SIDs are defined in core-sid and core-cbor would only talk about how that delta number is encoded but not how that delta number is determined. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 17 07:03:06 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8A126BFD; Thu, 17 Aug 2017 07:02:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 eBp0Y0F-250I; Thu, 17 Aug 2017 07:02:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A585213242C; Thu, 17 Aug 2017 07:02:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A22452009E; Thu, 17 Aug 2017 10:05:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 82C0F806D2; Thu, 17 Aug 2017 10:02:51 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: core WG , cbor@ietf.org In-Reply-To: <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> References: <13753.1502939016@obiwan.sandelman.ca> <7689DC42-6C05-462F-8466-C067B34232A9@tzi.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Cbor] map (5), ordering vs YANG SID in ietf-core-yang-cbor X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:02:59 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: cb> SID deltas in maps are parent-referenced (and not sibling-referenced) cb> for this reason. Okay. I don't think I understand the resulting structure then. cb> Do you see anything that makes you think they are sibling-referenced? draft> When no parent exists in draft> the context of use of this container, the delta is set to the SID draft> of the current schema node (i.e., a parent with SID equal to zero draft> is assumed). This was the text that made me think the the "parent" was the previous entry in the dictionary. If we want to encode: 20: fruit 24: bats 28: snow that we would do this with: 20: fruit +4: bats +4: snow I re-read the example and it's clearer now, but I was reading the rules. My appologies for the confusion. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmVogsACgkQgItw+93Q 3WX5Mgf/WEN3cdG/FyxmeAXQkTDJgN2AUtDJ5mb6xrHfEJ/S6MRgOu6nJM4ef93A EhxGmLaNbbltLJGNpZe8JS80/OzQgxYbSW/UB1ybIeRSt0Sh1zdf1SCkqJ+Eaz7K bhREGSfMIKJ70EfnFBIaHBjOLloEDaqmUP2V/BvWmUUpPC6Qy+aWIDF8+FE1z0IJ cMjQCy7jMIOkwYSc4k7J2eEj2cbIy7Xk8q53NmYvXlKezS8L3DLRIK6QUIaW8joz k9rqtaFoOy3fAIlgCDP4PlV7QeHmXR6wJHa9R4X7+6e3z0ObMAbkW/PwQDhk7ZXD oYLHCLhdCeAHjWB55TDvqZ+6q25BJA== =Wy1B -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 18 02:06:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813AA132932; Fri, 18 Aug 2017 02:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 xFQX2m4ASNhb; Fri, 18 Aug 2017 02:05:59 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 D2561132518; Fri, 18 Aug 2017 02:05:55 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id d124so30324798vkf.2; Fri, 18 Aug 2017 02:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GERBG/eM/yasj4k+eJolpwzBm2VkJMJl9Es7PbD/YF4=; b=ClaY6h3e9i/gJ2rcuxRMouBIxe0/dVIxOHfU9kJYilLiOTjrv1grEGXdUn8r3pU+6a xsF7cUcT9apQ5AKGBInPBQMyBDwFo6SR3B+DeqLSrzQzkVm7eE6ai7RyU7ZX7SxcT7jb K5KnOPOCqJo9irQKk/wUqDvH0zj4Ci7jN7wPbR6JdWZDQSukbbNQnSyLOZ8k9t4FBkTn 99jxKXEUPo2dJBvGluDBV2TsLgwm2aBCUga/RJfYtsrUlxHZSPxAEaPVdHVogj4izWZO VTpQd2RVqMs1JdA2bXBUZl/lmJYSrHBueZtuNXJFHNFYo1Ngt8234KNVJAzZf4CtGKst DoAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GERBG/eM/yasj4k+eJolpwzBm2VkJMJl9Es7PbD/YF4=; b=dkGP4WIpKjYo2h9G3CWWtWr6Zrxf9Sq4ruzIa7aHEVrMsfkpc5tILRGCLFfvsIb4fO lqq4nNKeSV80jaeaktd6haDgvBc09Qhr5SuyeUQXFW6D0mDm7SGtkv/9X1HMGeSjuUzB E2vJIryDvofK0iU8ehBfL5NXUUQWuhpbTqPllO2mLFuI5fpBh00z0LTwD9MjChU04Szk 16lLeN+xnUlr+B5XNXJ28wBJXQyJ7G3W4VIJgilVG8IvJ7J6oQp2XfYgwQeX2w8f0AGV T5/8HeRgiF5bQBtRAEmhaIO1489YbiI72QgWi+JsX7gpqLUYgsP72xDt5cbyEgCesLNv 72SQ== X-Gm-Message-State: AHYfb5jupAXrP3CflgRpFshb3z56R8VdFaYIaKP9iTFX0FVtqgqkfNit llvJ7weQ2qfDn8T8ww5W8r0PfgEB0EkJ X-Received: by 10.31.232.7 with SMTP id f7mr5110527vkh.32.1503047154801; Fri, 18 Aug 2017 02:05:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.161 with HTTP; Fri, 18 Aug 2017 02:05:54 -0700 (PDT) From: Zhen Cao Date: Fri, 18 Aug 2017 17:05:54 +0800 Message-ID: To: draft-ietf-lwig-coap@ietf.org, lwip@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [core] Issues of CoAP with DTLS X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 09:06:00 -0000 Hi Authors of draft-lwig-coap, Thank you for the draft. I have a question related to CoAP-over-DTLS. Section 5.4 of the draft (https://tools.ietf.org/html/draft-ietf-lwig-coap-04#section-5.4) has some discussion over the problem, it however does not help with the case below. Say, the client and server is talking over a CoAP-DTLS session with a NAT between. Then the NAT session expires because of an idle period when no traffic re-enforce the NAT state. Assume afterwards the client would like to send a new CoAP-CON message towards the server. With the NAT outgoing
pair changed, the server will not be able to resume the previous DTLS session and will discard this message. Sad though, it is not that serious because NAT problems is everywhere. What's worse is however, under such scenario, the client is unclear if it needs to retransmit the CoAP-over-DTLS message or re-negotiate a new DTLS (isn't it? because it does not know whether it is a network issue or DTLS failure). If it takes it as a network issue, it will keep trying to retransmit the CoAP-CON, until it reaches the retry limit (4 defined in RFC7252). This is very costly because of the exponential backoff may sum to more than 10s. In this case, it will be more efficient in this case to have the client re-negotiates the DTLS with server immediately. a) So my first question will be : Is this an issue with the current implementation and shall we make some recommendations? b) With regards to a better solution, draft-fossati-tls-iot-optimizations-00 will be a direct solution by including a connection ID in the DTLS record layer, but I do not know why this draft expires. @Hannes, could you help me with some background. Many thanks for discussion. BR, Zhen From nobody Fri Aug 18 02:37:46 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74162132937; Fri, 18 Aug 2017 02:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1qinQQwK-q5S; Fri, 18 Aug 2017 02:37:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 296B91323AD; Fri, 18 Aug 2017 02:37:41 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.73]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPppG-1ddfud1i9y-0052ut; Fri, 18 Aug 2017 11:37:38 +0200 To: Zhen Cao , draft-ietf-lwig-coap@ietf.org, lwip@ietf.org, "core@ietf.org WG" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Fri, 18 Aug 2017 11:37:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:x97znv5xVIMQ7Zgw3rN8iyD45MNHkj4uG1t5gxY5WIp6hyxzWHp AuxB5/0w+VXfNFoa5iaPMjiXV/wNEh3fyfp4r9xWPFIlfjV4vxvZ89j1hTcancj9ir54Rhi qgGFiNJn2lB+tV7GQS6N2+GgQuDdzQDUXXzYjm0fe0Uv1kfZ4N56R7B7oB9x8w5D6v9YhTF GhRG9KYBK+4djmar+THWQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:aRtLNAtT6Io=:/BusZgLvTJHvEdQbEIiKxh XIEZE5GNRdY5SN1JjaHYQ57ftlREOR5OnOIqX1BBWVLv1sAvASzW6/O3wwK+Epa1MzMDaOW+B P98MEtrR6vYsiKCrvtMV7XhP9UOVRdOe9tgzFN4QQNw4WyXmSOT6+ntscNi7OEWnKznAvcNWD N4bzccd2ZLXSANTwPJO8ufdX6Zoegg/cCEUqLLeHHsgIZNu05bK6oYlIV2D1p/VJtHZlVXyiu gKFdpmRwblbl85DNFeEve6bm3GBtZXTnHj1jJhBchHQa1Ya9OvW7Xz0AOh3FMQONe/dZKC35f mSCKYyHMn439FG3I3ew/3O8wpUwcXAbSQG+rBo8seuhIfFh2CMX7qzEjs3eTfKtaqmIbYmdfa LJeuTz3QmCcjSp0LEDSqxzSGg+wyunOswL7tTFCJ3E+vhg096imqUS3SwqXkvTSiI+eFBJPl0 3yEq2aPzaUlBtI+iDegxxg27G3tVLhCGZPMGt8DZyZBlK7jAAFsUSGJweTPUejVB2f0cg5t+s cKcDRC27qIioCKjciaGyMsM9CKWBEbqHrOJVd/I/NKmeyA2NLxhVKRCMkSMJXfJ4oLOErXT6b /ak7ZONbqLxzxsuFFdCdvi1xD+8lsc4/Rb3J6RMX2fOy3q7loG4C0HTWaTUCQfdrqCI7FjR9o MaW0c1shIP25Fwz8A1yegAbLbPSCZTV3gtUsy8TTQXGvNUexUElkQrL6nnuoiU/VZUi3sSeSR y4M1CpYvG72LaeL5nYELX3A1UcIAok3Hp3bp9KVgj6xwxdv0NA+k4Z5rBB4rjbfu3RdVHJe80 eAsKu2G1/XM+YuhEOKlMM+sFmwh8s+9TuNRsaeqgoiUM8xVz70= Archived-At: Subject: Re: [core] [Lwip] Issues of CoAP with DTLS X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 09:37:44 -0000 Hi Zhen, a few people have pointed out this problem and hence a solution will be worked on (as agreed at the last TLS WG meeting). Ciao Hannes On 08/18/2017 11:05 AM, Zhen Cao wrote: > Hi Authors of draft-lwig-coap, > > Thank you for the draft. I have a question related to CoAP-over-DTLS. > Section 5.4 of the draft > (https://tools.ietf.org/html/draft-ietf-lwig-coap-04#section-5.4) has > some discussion over the problem, it however does not help with the > case below. > > Say, the client and server is talking over a CoAP-DTLS session with a > NAT between. Then the NAT session expires because of an idle period > when no traffic re-enforce the NAT state. Assume afterwards the > client would like to send a new CoAP-CON message towards the server. > With the NAT outgoing
pair changed, the server will not > be able to resume the previous DTLS session and will discard this > message. Sad though, it is not that serious because NAT problems is > everywhere. > > What's worse is however, under such scenario, the client is unclear if > it needs to retransmit the CoAP-over-DTLS message or re-negotiate a > new DTLS (isn't it? because it does not know whether it is a network > issue or DTLS failure). If it takes it as a network issue, it will > keep trying to retransmit the CoAP-CON, until it reaches the retry > limit (4 defined in RFC7252). This is very costly because of the > exponential backoff may sum to more than 10s. In this case, it will > be more efficient in this case to have the client re-negotiates the > DTLS with server immediately. > > a) So my first question will be : > Is this an issue with the current implementation and shall we make > some recommendations? > > b) With regards to a better solution, > draft-fossati-tls-iot-optimizations-00 will be a direct solution by > including a connection ID in the DTLS record layer, but I do not know > why this draft expires. @Hannes, could you help me with some > background. > > Many thanks for discussion. > > BR, > Zhen > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > From nobody Fri Aug 18 03:06:08 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D0F1323AD; Fri, 18 Aug 2017 03:06:00 -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_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 QtFo140hE0Du; Fri, 18 Aug 2017 03:05:57 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0121.outbound.protection.outlook.com [104.47.1.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E6B13235C; Fri, 18 Aug 2017 03:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n8rclxqNMsmXHvHUb0wrmTv0LBluzUURHH0aXPM+LMM=; b=PUPnecSjVJ4NoFGcDhftWL3RIFvdWER6X36SAAbAnNqczdXsVmwn6eRS4kCm8q4J1yLw7nOvNrxzVX8lbJ9Yu9rtY+G3ff1kad3d5duhxLDe4ZaPXuG5VbU8SNfGAWMzpTqGrNsJ/zJGTLzbUNWZs3ecLJ3fO6TEQE6RndzZpjU= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1392.eurprd07.prod.outlook.com (10.164.92.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Fri, 18 Aug 2017 10:05:54 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::b4cd:e432:f911:52f8]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::b4cd:e432:f911:52f8%14]) with mapi id 15.01.1362.018; Fri, 18 Aug 2017 10:05:54 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Hannes Tschofenig , Zhen Cao , "draft-ietf-lwig-coap@ietf.org" , "lwip@ietf.org" , "core@ietf.org WG" Thread-Topic: [core] [Lwip] Issues of CoAP with DTLS Thread-Index: AQHTGAWqSU2+Kmk6wEi2m1nJAN58WKKJ896A Date: Fri, 18 Aug 2017 10:05:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [92.23.92.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1392; 6:WEVz/Tull3bQ+u2ADUeo6vPNYpsaWxCociTyizCXjFQxh92ZOtZN2tTP9CpvJnjwRn45+183Xvl34YvhqUxIir1IoX1cylYwLnPXoy7lzhe4sCkXOqgbBhD0FC28dR+RwuHZVfb/byf42xgn8RvzfKcqe+ct7gJyowEqwDTF5SkFoYZswAdzRjVA7tHzCKZr72KBCkTRy4sm4MageoAvs3XdZv7MJbhJBtPZf/L7iHL5rVXN6JaRBXSAVa1nIwrR1pF/UhcpRCQp8q2ryztrzdBJ5rnjwFliWdjubXQxaNOtknvuH5qAjQkTzvG5kq8LN6LrYQlJvR9ktPTM9hwilQ==; 5:4ZZ/CLkaJXGovcB3mUWAMXG6kjRcoQ/e90C9r0F7UqJDUgxPc443XDMqM4wtatoS4bwZGEmNJzpChY9qd1LbJmOaEeymkF/qqgj0aPM7f3N/VymvXMTRl6Ow9i/wHyDs0waBnVHqdlLL6awWgfCjyA==; 24:3vchl4w7YPxaNQUQZrawn1HGCqsKT0dvT08uhQimgXgozVJkUMgcZoFZNR+ly+cfzje9kEcNLggs55JLFk3O3ijuOFth/4aPObdgZRkSEKc=; 7:wuqA1FfGjiEJJTaw2Bmsje7sGm10hTxUbdlu5nmVObZekOHXDlHsRQt3yerF0bxi3IBhIALmLpxUAJyO6u2ISxYgU5oAtHC08DnMxtUKwTkb/cX6TUpNHYQUnUdrKhrB56kQ6fB7rb7JLzrlkpzW+g4EYPoLqQRwRvBHNrhtQ0caMsxL+homIvahNGpvI/1L4f++8YQ3fIet7sMO/DU9IVwqTA3is6n5wcqF/4V59Oc= x-ms-office365-filtering-correlation-id: 2859a4d9-170e-4b54-272f-08d4e620b6d3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR07MB1392; x-ms-traffictypediagnostic: VI1PR07MB1392: x-exchange-antispam-report-test: UriScan:(268559375225159)(158342451672863)(248736688235697); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1392; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1392; x-forefront-prvs: 040359335D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(66654002)(377454003)(199003)(189002)(24454002)(50986999)(54356999)(3846002)(76176999)(101416001)(81166006)(6116002)(81156014)(8676002)(53936002)(106356001)(102836003)(8936002)(345774005)(6246003)(107886003)(105586002)(3660700001)(99286003)(2906002)(3280700002)(39060400002)(68736007)(66066001)(6306002)(6512007)(36756003)(2900100001)(229853002)(2950100002)(6506006)(82746002)(33656002)(97736004)(189998001)(2501003)(305945005)(25786009)(14454004)(83716003)(5250100002)(478600001)(83506001)(4326008)(7736002)(2201001)(5660300001)(4001350100001)(6436002)(6486002)(53546010)(86362001)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1392; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4966B46515BCC74EB120740B693B0623@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2017 10:05:54.5153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1392 Archived-At: Subject: Re: [core] [Lwip] Issues of CoAP with DTLS X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 10:06:00 -0000 SGkgWmhlbiwNCg0KSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIHRoZSBmMmYgZGlzY3Vzc2lvbiB0 aGF0IEhhbm5lcyBtZW50aW9uZWQsIHNlZSBbMV0uDQoNCkNoZWVycywgdA0KDQpbMV0gaHR0cHM6 Ly95b3V0dS5iZS9tcy0wUGxZMVItOD90PTI1MzQNCg0KDQpPbiAxOC8wOC8yMDE3LCAxMDozNywg ImNvcmUgb24gYmVoYWxmIG9mIEhhbm5lcyBUc2Nob2ZlbmlnIiA8Y29yZS1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCg0KSGkg WmhlbiwNCg0KYSBmZXcgcGVvcGxlIGhhdmUgcG9pbnRlZCBvdXQgdGhpcyBwcm9ibGVtIGFuZCBo ZW5jZSBhIHNvbHV0aW9uIHdpbGwgYmUNCndvcmtlZCBvbiAoYXMgYWdyZWVkIGF0IHRoZSBsYXN0 IFRMUyBXRyBtZWV0aW5nKS4NCg0KQ2lhbw0KSGFubmVzDQoNCk9uIDA4LzE4LzIwMTcgMTE6MDUg QU0sIFpoZW4gQ2FvIHdyb3RlOg0KPiBIaSBBdXRob3JzIG9mIGRyYWZ0LWx3aWctY29hcCwNCj4g DQo+IFRoYW5rIHlvdSBmb3IgdGhlIGRyYWZ0LiAgSSBoYXZlIGEgcXVlc3Rpb24gcmVsYXRlZCB0 byBDb0FQLW92ZXItRFRMUy4NCj4gU2VjdGlvbiA1LjQgb2YgdGhlIGRyYWZ0DQo+IChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sd2lnLWNvYXAtMDQjc2VjdGlvbi01LjQp IGhhcw0KPiBzb21lIGRpc2N1c3Npb24gb3ZlciB0aGUgcHJvYmxlbSwgaXQgaG93ZXZlciBkb2Vz IG5vdCBoZWxwIHdpdGggdGhlDQo+IGNhc2UgYmVsb3cuDQo+IA0KPiBTYXksIHRoZSBjbGllbnQg YW5kIHNlcnZlciBpcyB0YWxraW5nIG92ZXIgYSBDb0FQLURUTFMgc2Vzc2lvbiB3aXRoIGENCj4g TkFUIGJldHdlZW4uICAgVGhlbiB0aGUgTkFUIHNlc3Npb24gZXhwaXJlcyBiZWNhdXNlIG9mIGFu IGlkbGUgcGVyaW9kDQo+IHdoZW4gbm8gdHJhZmZpYyByZS1lbmZvcmNlIHRoZSBOQVQgc3RhdGUu ICBBc3N1bWUgYWZ0ZXJ3YXJkcyB0aGUNCj4gY2xpZW50IHdvdWxkIGxpa2UgdG8gc2VuZCBhIG5l dyBDb0FQLUNPTiBtZXNzYWdlIHRvd2FyZHMgdGhlIHNlcnZlci4NCj4gV2l0aCB0aGUgTkFUIG91 dGdvaW5nIDxhZGRyZXNzIHBvcnQ+IHBhaXIgY2hhbmdlZCwgdGhlIHNlcnZlciB3aWxsIG5vdA0K PiBiZSBhYmxlIHRvIHJlc3VtZSB0aGUgcHJldmlvdXMgRFRMUyBzZXNzaW9uIGFuZCB3aWxsIGRp c2NhcmQgdGhpcw0KPiBtZXNzYWdlLiAgU2FkIHRob3VnaCwgaXQgaXMgbm90IHRoYXQgc2VyaW91 cyBiZWNhdXNlIE5BVCBwcm9ibGVtcyBpcw0KPiBldmVyeXdoZXJlLg0KPiANCj4gV2hhdCdzIHdv cnNlIGlzIGhvd2V2ZXIsIHVuZGVyIHN1Y2ggc2NlbmFyaW8sIHRoZSBjbGllbnQgaXMgdW5jbGVh ciBpZg0KPiBpdCBuZWVkcyB0byByZXRyYW5zbWl0IHRoZSBDb0FQLW92ZXItRFRMUyBtZXNzYWdl IG9yIHJlLW5lZ290aWF0ZSBhDQo+IG5ldyBEVExTIChpc24ndCBpdD8gYmVjYXVzZSBpdCBkb2Vz IG5vdCBrbm93IHdoZXRoZXIgaXQgaXMgYSBuZXR3b3JrDQo+IGlzc3VlIG9yIERUTFMgZmFpbHVy ZSkuICAgSWYgaXQgdGFrZXMgaXQgYXMgYSBuZXR3b3JrIGlzc3VlLCBpdCB3aWxsDQo+IGtlZXAg dHJ5aW5nIHRvIHJldHJhbnNtaXQgdGhlIENvQVAtQ09OLCB1bnRpbCBpdCByZWFjaGVzIHRoZSBy ZXRyeQ0KPiBsaW1pdCAoNCBkZWZpbmVkIGluIFJGQzcyNTIpLiBUaGlzIGlzIHZlcnkgY29zdGx5 IGJlY2F1c2Ugb2YgdGhlDQo+IGV4cG9uZW50aWFsIGJhY2tvZmYgbWF5IHN1bSB0byBtb3JlIHRo YW4gMTBzLiAgSW4gdGhpcyBjYXNlLCBpdCB3aWxsDQo+IGJlIG1vcmUgZWZmaWNpZW50IGluIHRo aXMgY2FzZSB0byBoYXZlIHRoZSBjbGllbnQgcmUtbmVnb3RpYXRlcyB0aGUNCj4gRFRMUyB3aXRo IHNlcnZlciBpbW1lZGlhdGVseS4NCj4gDQo+IGEpIFNvIG15IGZpcnN0IHF1ZXN0aW9uIHdpbGwg YmUgOg0KPiBJcyB0aGlzIGFuIGlzc3VlIHdpdGggdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24g YW5kIHNoYWxsIHdlIG1ha2UNCj4gc29tZSByZWNvbW1lbmRhdGlvbnM/DQo+IA0KPiBiKSBXaXRo IHJlZ2FyZHMgdG8gYSBiZXR0ZXIgc29sdXRpb24sDQo+IGRyYWZ0LWZvc3NhdGktdGxzLWlvdC1v cHRpbWl6YXRpb25zLTAwIHdpbGwgYmUgYSBkaXJlY3Qgc29sdXRpb24gYnkNCj4gaW5jbHVkaW5n IGEgY29ubmVjdGlvbiBJRCBpbiB0aGUgRFRMUyByZWNvcmQgbGF5ZXIsICBidXQgSSBkbyBub3Qg a25vdw0KPiB3aHkgdGhpcyBkcmFmdCBleHBpcmVzLiAgIEBIYW5uZXMsIGNvdWxkIHlvdSBoZWxw IG1lIHdpdGggc29tZQ0KPiBiYWNrZ3JvdW5kLg0KPiANCj4gTWFueSB0aGFua3MgZm9yIGRpc2N1 c3Npb24uDQo+IA0KPiBCUiwNCj4gWmhlbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gTHdpcCBtYWlsaW5nIGxpc3QNCj4gTHdpcEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x3aXANCj4gDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1h aWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlDQoNCg0K From nobody Sat Aug 26 15:06:25 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DB4132396; Sat, 26 Aug 2017 15:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 DtuuQXOa0QPe; Sat, 26 Aug 2017 15:06:22 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206531320C9; Sat, 26 Aug 2017 15:06:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1503785145; h=from:subject:to:date:message-id; bh=uPVFPmucZvn3tVeDwrXnmBwU+nkadGvM5B6eUy99t1s=; b=blzkKYjJQFlJ1O4JNoz+UuhxdctcgVnfRv9gadTE9x7deiONTY/4tXHzq7OvE6XDkxIgiixEiVY zoDma1kZzKyb4oMe5EBsufS8gF5p04UkpV/bEMSiVOVn/3ZtJvpohbAxn+MfGqddB1jOXGLgQBhkl 45lRpbQSakIM6EowoSS34+4XBX7QsOLxWEnlSVkTWsgVZljWpVR30P/9ovDtnl7+ozSiQ303UbCf8 p+Uk7wtiO9goz9teQeV0Oq+qookESKYUlTxeOF33IRd2UKQH7a0OIe4+dciXlk5mJWO0aAAM6ge+r EQhtL3siWLmAIhrwyS4QVxDq1cKe8Z4nUC/w== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 26 Aug 2017 15:05:45 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 26 Aug 2017 15:05:43 -0700 From: Jim Schaad To: CC: Date: Sat, 26 Aug 2017 15:06:13 -0700 Message-ID: <019d01d31eb7$89791a60$9c6b4f20$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMetICzn45cVH3zTPirIUYpctyfZw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] More questions on resource directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 22:06:24 -0000 With the normal directory queries, if the external representation is ;if="sensor", ;if="sensor" Then a query of ?href="/sensors" would return all of the items. On the other hand if the external representation is ;if="sensor";anchor="/sensors", < /light>;if="sensor";anchor="/sensors" The same query would return nothing. This behavior is leading me to some questions on how the context field should be processed or ignored when doing filtering as part of the RD code. Suppose you publish Context="coap://example.org/sensors" ;if="sensor", < /light>;if="sensor" ** Should a get with ?href="/sensors" against the path returned from the post return any of the entries or should it find zero entries? (Section 5.4.3 Read Endpoint links) ** Does the answer change if I do the query against the full resource directory rather than a single subset of the RD? (Section 7) Given that a response to a section 7 query would return < coap://example.org/sensors/temp>;if="sensor", < coap://example.org/sensors /light>;if="sensor" ** Should a query with ?href="/temp" return a response with one element - or is the full context string needed for this type of query? (i.e. ?href="coap://example.org/sensors*") ** I have already asked one question about anchors in the prior message, but normalization for a response seems to be a problem here. Jim From nobody Sat Aug 26 15:31:13 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448F31321A5 for ; Sat, 26 Aug 2017 15:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 kdNQcfOxGP5X for ; Sat, 26 Aug 2017 15:31:11 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141AF1204DA for ; Sat, 26 Aug 2017 15:31:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1503786635; h=from:subject:to:date:message-id; bh=RVJshjGeCDzGlECUo8ncViT/vgJJp0W5a0Ab4HBh7U8=; b=SDZsLzOVA0B24hP9KW/Zkwa5vyj958vv2KMLZ9dZmPJchitysIF9TayPZHz8/wBTkySOWex/cTc XeelHzLv6xWu19Zwy86EfVi+2EV7I/Vv3uQXatWbxoC/K5pgTNN6H0STyXzU3+pFyrMqI0Ng1QJQh gd0BScIi09yqonu1g/394tHwnPd8tojo1sbP12UT2N33ynfExbRYPcovqYSpT17j+gIG8tyIRl8lq Lv+IK5qHhMZNr3AvzeHWmnwHrYSQ1r4LEOgwBG0q7T029WuieFBbclA2m0e0JmOswOS9QLPaRidFJ 9xkPL+yvYVsf7kKPeU/OpHiA3sXBoNLHqGCw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 26 Aug 2017 15:30:33 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 26 Aug 2017 15:30:32 -0700 From: Jim Schaad To: Date: Sat, 26 Aug 2017 15:31:01 -0700 Message-ID: <019e01d31ebb$00ccdd60$02669820$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMeuFRLxWr5anlVSNWoKTgjzJ0VVw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Observe on non-GET request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 22:31:12 -0000 I have now be part of two different situations where the question has arisen of what happens if one attempts to do an observe on a message which is not a GET request. RFC 7641 only talks about what happens if this option is part of a GET or a response, it does not have any indications about what should happen if this option occurs on a PUT request operation. Both of the situations that I have looked at involve security operations where the response would never be cached by a proxy, so all of the text dealing with freshness and caching behavior are moot for me. I would, for example, always put a Max-Age=0 option in the responses so that caching would not occur. I was not involved in the CORE group at the time that observe was being formulated and discussed, but my assumption is that all of the discussions were dealing with the cases of wanting to cache responses to gets so that network traffic could be reduced and they did not ever look at the types of cases that I am currently playing with. I can do a single get operation to setup the observe relationship for one of the cases which will basically return an empty response but setup the observe relationship on all of the servers and proxies. No association of queries and responses can be done for these as all observes would be using the same token value. In the other case, since the observe could be assumed to be on a get it would not hide the fact that this is a get relation and that responses are tied to this specific request (based on the token). So I guess the questions are: 1. What should happen to an observe on a PUT? 2. Should we re-visit this question and see if we want to change the behavior? Jim From nobody Sat Aug 26 15:44:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6401323C0 for ; Sat, 26 Aug 2017 15:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=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 u2IXQ9Nzn_ch for ; Sat, 26 Aug 2017 15:44:51 -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 294311321A5 for ; Sat, 26 Aug 2017 15:44:51 -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 v7QMilpF023155 for ; Sun, 27 Aug 2017 00:44:47 +0200 (CEST) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xftQ726PszDL5S for ; Sun, 27 Aug 2017 00:44:47 +0200 (CEST) Received: by mail-it0-f54.google.com with SMTP id 77so12080096itj.0 for ; Sat, 26 Aug 2017 15:44:47 -0700 (PDT) X-Gm-Message-State: AHYfb5gMA2D7aUYJ+ZC2YsRkpJWwKH7NItm1FQ34B/1z6LSf28m1yayS qzEeyvnkmEHonSE91MuhSSgVSPoRnw== X-Received: by 10.36.200.86 with SMTP id w83mr1974393itf.36.1503787485847; Sat, 26 Aug 2017 15:44:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.15.211 with HTTP; Sat, 26 Aug 2017 15:44:05 -0700 (PDT) In-Reply-To: <019e01d31ebb$00ccdd60$02669820$@augustcellars.com> References: <019e01d31ebb$00ccdd60$02669820$@augustcellars.com> From: Klaus Hartke Date: Sun, 27 Aug 2017 00:44:05 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] Observe on non-GET request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 22:44:53 -0000 Jim Schaad wrote: > 1. What should happen to an observe on a PUT? The Observe option is not defined for PUT and is therefore treated as an unrecognized option [1]. > 2. Should we re-visit this question and see if we want to change the > behavior? What would an Observe option in a PUT request mean? For example, an Observe option in a GET request gives you a continuously updated representation of a resource. Would an Observe option in a PUT request give you a continuously updated action result? The same effect of an Observe option in a GET request can be achieved by repeatedly making normal GET requests ("polling"). How could the same effect of an Observe option in a PUT request be achieved with normal PUT requests? Klaus [1] https://tools.ietf.org/html/rfc7252#section-5.4.1 From nobody Sat Aug 26 18:13:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AE51321BF for ; Sat, 26 Aug 2017 18:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 l0t1Vfp4isLs for ; Sat, 26 Aug 2017 18:12:59 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D860132193 for ; Sat, 26 Aug 2017 18:12:59 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1503796335; h=from:subject:to:date:message-id; bh=VYpOVlqxodfH5ns53LKJay+pWu2OOFNBKlM7Ag9+FXw=; b=fsyj9h38Y+vu0EwpE73Mk7AB9IPDmzLPgUhL6+BkKxtawlhrUcMN/84WutJqYJccyKBVBWlCvx8 Q4oASlnCXydHA4+ujzui3ZyB9q+/R2EwlRX/1sNkI32r7bnutYKDK3j6M37VOhPDI9NjUmcZpzk56 MYVjmLqi3D6IYqZYWKA5mNvR+gRVT4mCH2a4/lOl7u9HGIOrev/qvgz2G2PSqD2fgqaZr5D1I+ahD misQLC+z2qKKgfrolKySW0TAZyQ1gaKOhP4JTUwqOHSpRyGZscb4fOJ350BITcz8ts3fdJIpj1l5z SIpeH+389FWszjwvoTEEHuQATmZkkHS12G6g== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 26 Aug 2017 18:12:13 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 26 Aug 2017 18:12:13 -0700 From: Jim Schaad To: 'Klaus Hartke' CC: References: <019e01d31ebb$00ccdd60$02669820$@augustcellars.com> In-Reply-To: Date: Sat, 26 Aug 2017 18:12:42 -0700 Message-ID: <01a101d31ed1$96e6c2a0$c4b447e0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG4WmHtunmJBhCRaGviCb5QdL63RAHXjl4aor4xczA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Observe on non-GET request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 01:13:01 -0000 > -----Original Message----- > From: Klaus Hartke [mailto:hartke@tzi.org] > Sent: Saturday, August 26, 2017 3:44 PM > To: Jim Schaad > Cc: core@ietf.org WG > Subject: Re: [core] Observe on non-GET request >=20 > Jim Schaad wrote: > > 1. What should happen to an observe on a PUT? >=20 > The Observe option is not defined for PUT and is therefore treated as = an > unrecognized option [1]. Would probably be nice to make that explicit in the Observe RFC if it = gets revised. >=20 > > 2. Should we re-visit this question and see if we want to change the > > behavior? >=20 > What would an Observe option in a PUT request mean? For example, an > Observe option in a GET request gives you a continuously updated > representation of a resource. Would an Observe option in a PUT request = give > you a continuously updated action result? >=20 > The same effect of an Observe option in a GET request can be achieved = by > repeatedly making normal GET requests ("polling"). How could the same = effect > of an Observe option in a PUT request be achieved with normal PUT = requests? I would want to define the behavior as the same as making a GET on the = request for all subsequent requests. This is basically an optimization = to avoid having to do the extra get operation. Jim >=20 > Klaus >=20 > [1] https://tools.ietf.org/html/rfc7252#section-5.4.1 From nobody Tue Aug 29 07:36:56 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0A0132D01 for ; Tue, 29 Aug 2017 07:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 UUJeHMNsKKuk for ; Tue, 29 Aug 2017 07:36:53 -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 1C5BF132A91 for ; Tue, 29 Aug 2017 07:36:52 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.73]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M3eDF-1dUtpj29qL-00rDcq for ; Tue, 29 Aug 2017 16:36:50 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 29 Aug 2017 16:36:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:i1cUu5Wq9u47aSBlbZJ9V2ycZk0zjowLLa7QfpTbvR7zyyohsQs pzysuYeyDzlB+Z80lspLtzTI//88PF6WvB82U9wk1KcInfnbwiLHVV2EiYBqD3TsVRAcV29 4XLDikaGMhDA5EIJR9Dn36fRhmq4e9Hx8iAKicpSi5OWi189n++gJIX18K0Ae8Y3Nlbv5SL YPHdDV8pvtJ92rcP1sVjA== X-UI-Out-Filterresults: notjunk:1;V01:K0:uT8vo54jbZo=:rMIcxNRjThk38mLMrB4Ubj w6L4+9T0Q2g45o+0aeG7ycZx8vLVsy4LF6fJVUZdOgLEx72uNduQfNpB+Nibb9XC56pLCD4UZ avhlAvd2y607hCTB3EHBWB4A0LukQkusY0zO55cm6ZDTTeJZSiLX7sUyG9Lfxlfaso7zdYXPT ORTn6RCnTw1r68mc1HCLtuYGtXAUhN5nSrm2DsVQNNfMnAimHmo2xwJskiAufQz/WGTizmJmX RHsBoqO1SiszT/PLwu6VJv6qRwGKhKHAJL296sOdVSCqTthfKW8MqepNldAwA1AwS3o8QO3Yf 2ajDoYpUQpSX9fpSRPDg2VORY3PD/WTddN5t0mtX5o2MlIVaqviL9tPSOvUW93EUuhgsN7kLE 9JQCqbPvxiGWNaFx1vASNfQyaC1zFXoiRvfxJ3K+gh2Xga/wsd80iQgw7QmjQvcvXY09MWN1b vmvOSkQ6Flpbe4GYWTRP2bUt4XGZ4+6mrFAsVgHHzAop7wIKfMIk9MsrboCXJ/Vnk3u/rN3RY kAG93Mbcr7hG0pKj01TjMZ93MrzjHnMBqxPpmyopL3qtA7YZekTy2QRnJj44XDn/07Kw/7Zr6 JmFyfAaCQl29MqYpQp0rTyJbrOpxRQ4Lj2DlWLmHblXYP2gYySbCtpdYwj6fPKJ8N5LjIjBiW KCr88rzEsHIDhwIyE1L5XjaVwWvnXrrSW+R2mvxQwgZhObnKS/9LYmq9Fk8pq4ZrsOGXmly6z hdvz+kxAcpbNSjfxW5h5yF4YO2KHvEE51WpH1Lbzbh/Wyul4lauAg0fgA+RyhPhkHLg6q1AYN 9gi9TJj4IS5IcV+iKGiUrQYUsoYiI2OR2MnE1/Mp9CAL056Rlg= Archived-At: Subject: [core] Milestone Update X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 14:36:55 -0000 I was wondering whether there is a plan to update the milestone dates since this was discussed at the Prague IETF meeting. Ciao Hannes From nobody Tue Aug 29 07:41:46 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D24124B18 for ; Tue, 29 Aug 2017 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 p1Kvcw4Yx2na for ; Tue, 29 Aug 2017 07:41:43 -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 6190C13292B for ; Tue, 29 Aug 2017 07:41:42 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.73]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MSdRI-1duIQS1utw-00RWQ6 for ; Tue, 29 Aug 2017 16:41:40 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <33503b56-68f7-a89f-04b3-5e96b335cbf6@gmx.net> Date: Tue, 29 Aug 2017 16:41:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9iIEmF6ObIAi436G/hulrfyOBYcaq130HvezH81TC5Wc9m+IeKf zbr4B4ByuqunTRgwW0ip2j3rJ3WKER++U40/WJi0x/6I3msAoxxx2z1Vpf6gXQNtZG9xQI4 GMEZaswh5wkdQrc8rCpHFwXBSjLVYKgQXNUVDrm2vsz8BblGCu6A/ab3yXg+8uH/FpR8yO1 XkBKC2zP1TYWHPNlx+bbQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:u4pdmKxBiU0=:Aun37zSxM6GPV9HBs2PBII APWwLe30niymebJQLKtjySGcFvJ/pr7db3TR9zk6PhibBxA1eC3b9H0JCmZxWAboNYXC1gk5X 5hxkqSzVBQ3CxaO+1R6Cmpl1Nezb6GNan+nenX4MQ39pbk6cQKoiNcSNq7T1VtBysAFNJZBzO +OFtO2WztYBYqvrNu/hZe478aQe9LraSQYT/Bkx7Ne7/PaqVS0oD+SSDAhbc3qwu1cDhCXIhr u23/KjpP+UukRpeYVh1Pw/rh1qbCoSfzPIN5Mr0jNOEsRzFsoGYczbj/jNuuRsqbRWmYA5uBX qmKD0qOjh5RcnbaNVh+Yv5Bc2/7/WtaJxZoXO4EFLUGJNwaX2HuV8y6SQpzbTvjWztcZC7nRR BCVw4KmP4qCE1vXDjDWdXaUglg5wplmtEaIS3nPUHG6bTiD8xcSZ5V8LnIioq4RgW3plMNkK/ IowPd+m1im4ZZ2o6+PAvtp6DSL+Rkcd4zMXg2a94nCKLa7pseK24MmpgMN+50JzY9gHdS5kXa hMteTdOSO7YrNQIR9HaOLDE2OblO1fNGtZMqJKHRLg5SG7G3Jsn94CjlwGFbhPRa27Q/W7B/h WI9nLDVryn2njfFjtgF1Rzw+BNoBelKW40oQQsRrda1kuA8bFsGUOFiDAoxuSWL1mryOS6pbo GjTi9agmw1jdyL4E5FWSYIShO9mgKbBhup6s8BggBXh/VvXuPo/9j1i/AWZ5lnniOPI/STXC0 6Mw2QpT87sEkFe65r7Yb5A2M/hdfLvjY+OEHyLyGJePYdg1vGMn6WHScwetIAl+da73HSXDMt tiW5f9FgVzm0TpwMDzwtOp8U5GZRJbJ+dpp/40UUggMuPmMKgg= Archived-At: Subject: [core] CoAP Usage X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 14:41:45 -0000 Hi all, in IPSO we are working on an IoT protocol comparison document and we were wondering whether someone of you has collected some data about the use of the following features in CoAP: * CoAP allows the use of IP multicast for discovery and also for data transmission. Is there data about IP multicast usage with CoAP? * CoAP supports reliable and unreliable data transmission. Is there some data about the use of unreliable data transmission? Ciao Hannes From nobody Wed Aug 30 18:59:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB84013219A; Wed, 30 Aug 2017 18:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 y2fzdVtBwYY4; Wed, 30 Aug 2017 18:59:52 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482D912008A; Wed, 30 Aug 2017 18:59:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504144758; h=from:subject:to:date:message-id; bh=SQjiBMHIUK+iyCZwV+o94aUKTo1oVeiYAlWR80/c1No=; b=jpZpSTMyD6Wa+vZTO6i7P7MTRdcTBQ4xctqBRzmKjdLs6cG+OScl7eIyTdqxAyUgxfLgv1z30MN 3Faga1qnRuhT9zzGXo/Qu3JgTYLR59fhKCM4OJfoZDoJQFv3FBASPjKGvRb4x3/B/Hiqc7rbWO68c pLN12K/07XPIYQ3gWd5axW7JT0FixEP8G5MCMbjHwVeFmVxezqN8v/KpZQHC3haplU5HWLE5RwoUW MHwlgXLYDJ+H+KfNk2BbI1El3eKlToYNmFzd8FihHPQwE2eLfsAAPnylt4iMZCv714FyHNYZlSpAe 9OehhqAgnwqDk3lpYtQ9+5wEDc3SQbWD+G5w== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 18:59:17 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 18:59:13 -0700 From: Jim Schaad To: CC: Date: Wed, 30 Aug 2017 18:59:44 -0700 Message-ID: <016801d321fc$d2820d50$778627f0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMh+lDNFE87jaZiTrSD4LE+r4oZvg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] draft-ietf-core-resource-directory = GET /rd X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:59:54 -0000 I am wondering if there should be a GET action defined against the resource directory object. Currently, if an entity does a registration for an endpoint it gets back a location for that registration. If a second entity modifies the endpoint and wants to update the registration, it currently has no method to get the location associated with the endpoint and cannot make a second new registration since the pair is required to be unique. Thus Interaction: EP -> RD Method: GET URI Template: {+rd}{?ep,d} Content-Format: application/link-format (or variants) ;ep=endpoint1,;ep=endpoint1;domain=beta, ... Jim From nobody Wed Aug 30 21:55:34 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C58126BFD; Wed, 30 Aug 2017 21:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 j7uhVGLsvzuH; Wed, 30 Aug 2017 21:55:30 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC539124207; Wed, 30 Aug 2017 21:55:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504155296; h=from:subject:to:date:message-id; bh=VpkL4xxNR2xQsvLJiauvwmxU2aE+uBfK6KWqvUdt2kM=; b=gKh6k6F5iIPJ8nJmNHxJ5SrCwS3K+hcOzSNh5R/68n9H4zJ9QQTqNGpmsqBRiFW+sKvatkYIaye KsDUfa2LRHAckQzQCoDe2WQdab1aZzFCg+ltCmZ+EaacQCQVioytVyRFPaod8SsxKpfu7sh+XBsMQ v6tczCardJTtTxANUXW0A09TCT3NJKCVNx+pkd9NTiSd21LoLjvVkGXvzuq8eqd+lI+kZ6eJMyKHz GchRboYpzkKqlCZ27/mw2SaT43h8UUE5pT7470qthL/pAr+i7ZN6oiyTOeltHq6oQy7+D2IRyo8ag mOFexLyMNdNjKLGmwMDX8PUoQQq7c4mYAfFw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 21:54:55 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 21:54:51 -0700 From: Jim Schaad To: CC: Date: Wed, 30 Aug 2017 21:55:22 -0700 Message-ID: <016d01d32215$5bb82a10$13287e30$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMiEFZkYl24GsijSFG69gJ737L63w== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] draft-ietf-core-resource-directory - More headaches w/ context X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 04:55:33 -0000 In reading through and working on implementing this draft, I have found what appears to me to be conflicting language on the context parameter. Section 5.3.4 indicates that context + target could have collisions and that this is likely to occur if there are multiple configuration tools. This text appears to me to indicate that the context can be different for each link in a registration resource. Each update could provide a different context. (I will note that the text probably needs to discuss dealing with both normalization of the context and building the full URI from the context and target when doing the comparison. The pairs and should probably compare as identical. Section 5.4.1 in the third paragraph talks about updating the lifetime and context in the same paragraph Since I know that the lifetime is a parameter of the registration resource, it is reasonable from the context to assume that the context would also be a parameter of the registration resource rather than of a link. In my opinion, these are conflicting concepts of what the meaning of context is. Would it be possible to figure out which is supposed to be correct and both let me know and update the document? Jim