From nobody Thu Nov 1 03:03:10 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D830412870E; Thu, 1 Nov 2018 03:03:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2ZlhNuSCv0I; Thu, 1 Nov 2018 03:03:05 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 48E1A1286E7; Thu, 1 Nov 2018 03:03:03 -0700 (PDT) Received: from mail-qt1-f182.google.com ([209.85.160.182]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gI9oa-0004o4-Kj; Thu, 01 Nov 2018 11:03:00 +0100 Received: by mail-qt1-f182.google.com with SMTP id q41-v6so20379806qtq.10; Thu, 01 Nov 2018 03:03:00 -0700 (PDT) X-Gm-Message-State: AGRZ1gJYycFpBU1tPMKnQfjC+Pny441wvCwBVYREKbCcxun++ejt+uYR sKn6nTf1zyTbgt6ddZTuxMiFII8XLTgE6d98d1I= X-Google-Smtp-Source: AJdET5d2wsMhJ0MRkmPlhhiW3KoxUqne5AQ1OH8AttJ6del07hEKxiZJvbmJT761UO4aXUZVF/PvAQOGYXimSZpPfYU= X-Received: by 2002:a0c:8003:: with SMTP id 3mr6138520qva.129.1541066579430; Thu, 01 Nov 2018 03:02:59 -0700 (PDT) MIME-Version: 1.0 References: <20181031164534.GA4995@hephaistos.amsuess.com> In-Reply-To: <20181031164534.GA4995@hephaistos.amsuess.com> From: Klaus Hartke Date: Thu, 1 Nov 2018 11:02:23 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: T2TRG@irtf.org, draft-hartke-t2trg-coral@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541066584; 475ae839; X-HE-SMSGID: 1gI9oa-0004o4-Kj Archived-At: Subject: Re: [core] [T2TRG] Review of CoRAL X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 10:03:08 -0000 Hej Christian, thanks a lot for this very detailed review! You're making a lot of good points. Since several points seem to me worth a discussion on their own, I will go through the list in the upcoming days one-by-one and comment on them individually. A question to the chairs of T2TRG and CoRE WG as this thread was started on both mailing lists: Where would you like to see the extended discussion to happen? Best regards, Klaus Christian Ams=C3=BCss wrote: > Hello CoRAL observers, > > I've read and partially implemented draft-hartke-t2trg-coral-05, and > would like to offer a review of it. > > My two largest individual issues with this are that I'm not convinced of > the necessity or suitability of the textual format, and that I don't see > yet how forms would be used in practice (that's out of scope for the > document, but limits the depth of my review). > > In general, the described format would be useful to me, both for new > applications and to fill in for link-format where RFC6690 is too > limited. > > The following is a rather unsorted list of things that struck me as > unclear or odd; none of them should stand in the way of a research or > working group adoption or be otherwise insurmountable; many are also > just editorial comments. > > * "The CoRAL data and interaction model is a superset of the Web Linking > model" / "can describe simple resource metadata in a way similar to > the Resource Description Framework (RDF)": > > From the examples in 2.1 (in particular, because the rel becomes a > full URI), it appears the othr way round: That the data model is a > superset of the RDF model, and that the document describes an > equivalence of a subset of RDF statements to typed links (as used in > link headers, link format and HTML). > > * Browsing context: This growing history appears hard to do in a > constrained context. Can an agent still work with any given maximum > history length, in particular 1 or even 0? > > * Forms: I haven't followed all the W3C & surroundings discussions on > forms, so I can't say much there as I don't yet understand how they > were to actually work. Examples that go beyond "POST to create" and > "DELETE to delete" would be helpful when they'd go beyond the > intuitive. -- But I assume that as this matures, any formative github > discussions will evolve into referrable documents. > > * If the first use of the http://www.iana.org/assingments/relation/ > prefix for rel values pointed to RFC4287, it would be clearer to the > reader that this is already established practice. > > * Representations: I think it would be helpful to state something in the > area of the second paragraph along the lines of "The producer of the > CoRAL document claims that the embedded representation is fresh at > least for as long as the CoRAL document is fresh", if so intended. > > It's obvious that the "full, partial or inconsistent" part is > intentionally giving much leeway to the CoRAL producer. Could this > possibly be narrowed down for resources under the same authority? A > statement like "(under some condition), the presence of a > representation states that there exists a request to the target that > would result in a response with the given payload" could go into a > direction where an agent could populate its own cache with it and work > on from there. > > * Binary data format: When relations expressed as uint are first > mentioned (and possibly also with numeric form-field-name), a forward > reference to the topic of profiles would be helpful. > > * Textual format: I find this more confusing than helpful. The format is > too far from turtle to allow intuition to be taken from there > (especially as there are simple and qualified names, where turtle has > only qualified names but the qualifier may be empty), too far from the > binary representation to help understanding the binary format (eg. > someone only editing in text format would not see that naming a > resource linked as rel=3D"index" would be beneficial, but could > be misled to believe that application/octet-stream can be a compact > default or that representations can have more attributes -- plus > people were led to think that CoRAL is large on the wire). > > My impression is that CoRAL would not be written by humans, let alone > stored or transported as that. I think the document would be better > off if no textual format were defined, but full turtle (or a slim > superset thereof that's still within N3) were used to express the > semantics of a document (which would need an RDF serialization of > forms and representations, but that's more of a benefit than a > downside IMO). > > Concrete example from 2.1: > > @prefix : . > > <> :next <./chapter4>; > :icon ; > :license . > > or from 2.2: > > @prefix : . > @prefix coral: . > > <> :task [ =3D ; > :description "Pick up the kids" > ]; > :task [ =3D ; > :description "Return the books to the library"; > coral:delete [ form:method coap:DELETE; > form:iri > ] > ] > > * Why is used for attrs, but used > for the core form relations? They could at least share structural > similarity. > > * attrs: title and title* are described as target attributes in RFC8288 > and can thus easily occur in CoRAL documents. > > * ibd: Then, it can say something like "MUST NOT occur in a CoRAL > document as attributes, but are expressed as link relations, nested > links and link relations, respectively" to indicate that their > information is not lost in the transition. > > * Any test vectors or examples to get started on the binary format would > be helpful, and could be augmented by (CDDL automatically?) annotated > extended diagnostic notation, like (as in the above, assuming a > navigation profile where someone forgot that favicon is a typical rel) > > [[/link/ 2, /rel:next/ 4, > /<./chapter4>/ [6, "chapter4"]], > [/link/ 2, "http://www.iana.org/assignments/relation/icon", > // [5, 0, 6, "favicon.png"]], > [/link/ 2, /rel:license/ 10, > // [1, "http", 2: > "creativecommons.org", 6, "licenses", 6, "by", 6, "4.0", 6, ""]] > ] > > * FoaF example: Just for my understanding, would anything be wrong with > some application using > as the rel to foaf:Person here? (I figure that few RDF applications > treat rdf:type and iana:type as equivalent properties). > > Later that's clarified a bit in A.1 where it says "same purpose", but > is rel:type in actual use anywhere? Otherwise, I suggest to go for > rdf:type right away, as that is in use. (It's more verbose when > expressed in non-CoRAL link formats, though.) > > * Only occurred to me when writing the above > extended-diagnostic-notation example: Might it make sense to allow > profile defined URIs as well, like common licenses or (when looking a > the FoaF example) types? They'd need to be told apart from numeric > literals that could just as well show up in a link target, but the iri > rule could get an additional `?(profiled: 9, uint)` entry that could > only exist on its own and expands like a numeric rel. > > * What to do with language-tagged attributes (like title*)? The takeaway > from links-json is that they can be decoded easily but need to keep > their language information. That's easily expressed in RDF (turtle: > `<> :title "=C3=9Cberschrift"@de`). links-json went for > `{"title":{"de":"=C3=9Cberschrift"}}`, which seems a bit crude to me bu= t > could work just as well for CoRAL, as could a tagged CBOR array or a > plain array if we stared using arrays with discriminators that are not > part of the IRI discriminators as something different than IRIs (a la > `[/link/ 2, /attr:title/ 42, [/language-tagged/ -1, "de", > "=C3=9Cberschrift"]]`). > > * Appendix C: Do I understand correctly that there are some CBOR encoded > relative references that can not (even when knowing the rel in > append-relation) be expressed in a relative-ref? In particular, those > would be the append-* types. If so, it would be prudent to point out > right next to where it says that "CBOR-encoded IRI References are not > capable of expressing all IRI references". > > * Most of the URI resolution gets away without string comparisons. I'd > like to suggest making "../" an explicit URI option (say, a `*(parent: > 5.5)` that'd go between path.type and and path. References with > dot-segments inside them are probably safe to put in the "not capable > of expressing all" category. > > As I understand URI resolution, we don't need a "./" because that only > needs to be explicit when starting with something that has a colon in > it that's not the scheme's colon, otherwise "./x/y" is always > equivalent to "x/y". > > * Speaking of expressiveness of the encoded URIs: (Especially as urn: is > used in the document,) would it hurt to grow the encoded references > such that they can encode urns? It might be sufficient to allow scheme > without a host/port but a path. > > Apropos port: Why must this be present after a host name? This > complicates round-tripping to URIs (because the algorithm has to know > to fill in default ports of all protocols), limits applicability to > portless protocols and adds some bytes -- and in the embedded > implementation, adding a default port can be as easy as just setting > it at initialization time before parsing. > > * Appendix C: A state transition diagram like the ones on > http://json.org/ could be as expressive as the list in C.3 while being > easier to grasp. > > * How are compressed URIs expressed in CBOR? Flat [6, "foo", 6, "bar"] > or nested [[6, "foo"], [6, "bar"]]? My first reading (and current > implementation) resulted in "nested", supported by the `(option, > value) =3D href[0]` line in C4, but reading C.1 with the CDDL spec next > to it (and running the cddl tool) rather indicates "flat" to me. > > Either way, some examples would be great. > > * Nit: calling a sequence of options _absolute_ brings up the > association of the "absolute URI", which is not the same as "URI" > (which is by definition not a reference, but sometimes it helps to say > "full URI"). An Absolute URI would not have a fragment identifier (and > is defined to ease definign protocols where the fragment is never > sent), whereas the non-relative or full option sequence described here > can easily (and should be able to) contain a fragment identifier. > > * Is there a difference between a CoRAL registry and a CoRAL profile? > Both terms are used. > > Best regards > Christian From nobody Fri Nov 2 23:55:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE394129385; Fri, 2 Nov 2018 23:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 Y6alD0ixio8L; Fri, 2 Nov 2018 23:55:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4F67E127332; Fri, 2 Nov 2018 23:55:01 -0700 (PDT) Received: from [10.42.10.6] (ip-91-232-239-173.texas.us.northamericancoax.com [173.239.232.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA36snF6085299 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 3 Nov 2018 01:54:52 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-91-232-239-173.texas.us.northamericancoax.com [173.239.232.91] claimed to be [10.42.10.6] From: Ben Campbell Message-Id: <81D232DE-12AD-4A4E-B5BC-E8E3DA27455C@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_684B442B-2E77-4B66-8AA8-1996EBCD58BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sat, 3 Nov 2018 13:54:48 +0700 In-Reply-To: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-too-many-reqs@ietf.org" To: =?utf-8?Q?Ari_Ker=C3=A4nen?= References: <154033246253.31224.15896855788700700234.idtracker@ietfa.amsl.com> <54D94C5C-F815-496B-B069-0887DF236B9A@nostrum.com> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [core] Ben Campbell's No Objection on draft-ietf-core-too-many-reqs-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 06:55:04 -0000 --Apple-Mail=_684B442B-2E77-4B66-8AA8-1996EBCD58BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 1, 2018, at 7:50 AM, Ari Ker=C3=A4nen = wrote: >=20 > Hi Ben, >=20 > (Clipping out all except the remaining comment; see below) >=20 > On 24 Oct 2018, at 20.37, Ben Campbell wrote: >>> On Oct 24, 2018, at 1:48 AM, Ari Ker=C3=A4nen = wrote: >>> On 24 Oct 2018, at 1.08, Ben Campbell wrote: >>>=20 >>>> Ben Campbell has entered the following ballot position for >>>> draft-ietf-core-too-many-reqs-05: No Objection >>> [...] >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- > [...] >>>> =C2=A74: "A client MUST NOT rely on a server being able to send the = 4.29 >>>> Response Code in an overload situation because an overloaded server >>>> may not be able to reply at all to some requests." >>>>=20 >>>> Can you elaborate on the practical effect of that MUST NOT? >>>=20 >>> Client should not make assumptions, e.g., that it can safely keep = increasing the request rate until it receives 4.29, even if a server = supports that. >>=20 >> That seems kind of vague for a normative MUST NOT. How did clients = pace requests prior to this? Are we asking them to do something = different >=20 > Basic CoAP implementations using default values would have just a = single request on fly, but more advanced implementation could have more = e.g., based on RTT estimates. The key point here is that this error code = should not be used to probe a limit the server can handle. So it=E2=80=99s= not really any new behavior this draft is asking for, rather a hint = that this code should *not* be used for this (probing) kind of =E2=80=9Cne= w behavior=E2=80=9D. >=20 > What would you recommend instead of MUST NOT here? Would =E2=80=9Cshould= not=E2=80=9D be more appropriate? That would work for me. Thanks! Ben. --Apple-Mail=_684B442B-2E77-4B66-8AA8-1996EBCD58BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvdRjgACgkQgFZKbJXz 1A2nYRAAkuK3LTqXDxfnz3aOzaynzxUdfw6OizMPA3v3qq/r63Wx09DJ0aiuV17C yiVUrl6XO6ibnMXT3lGBd2sW1wYH1LV/CFTpmC2z8LM5uQxqW1s4KvEO+cDJl4zQ lU8tiE08jXbnJ7Au7dZAjv9IgWOGRaU6JHwSKzOM6vJU9ZDNCfGH+/1yBo08Q9p6 PlUunumNmfyJGDxBzE8aWMFsd68W46lu+LompNRVfLNDslvRmNqK3YhDf2m6KrTq SG3m5MRzznTNOL+NZtlLOAMaMuDrvZv9iuUA16/EaEFieveyB4H02WMuDA4aZFnv CeonGIB65SKUpYGYV1q3WQYT9QCyYyde3xxTwKdI68sy9q4kaMtsOBen5ENst1ms Z3ZatGriz1OnLWXSQHmSV8JOxcwKZc3s5mNRgkOPawYOKgDSUcnf3/hMsYs4TncE InvYfKnH0/Ej9x5I4Myd0DHMxBxjRrlYuiwyWE4TLKdUTKbamJ3EM+zk4lMxWEWz keMHKg3qG93Ff5CBMw6SkB+hUrWGXGT6XK1/UpitmaCZGEpRs4oPML0fvUB7CmUw QBzAPCY9a/L3b3rv/DigGgyQWgvISHLodlLp0JTHC73iwUFlWyVqosSmXSLuGo2s aRcxTMxQvnpqT5xebgECWZZhaAeKX0r5zX2ulvyE8TOP0jUHp80= =0ouS -----END PGP SIGNATURE----- --Apple-Mail=_684B442B-2E77-4B66-8AA8-1996EBCD58BB-- From nobody Sat Nov 3 04:12:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C8C1288BD for ; Sat, 3 Nov 2018 04:12:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 dy5e2g-t5aUm for ; Sat, 3 Nov 2018 04:12:19 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA5F124BAA for ; Sat, 3 Nov 2018 04:12:18 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 2D7081801FF39; Sat, 3 Nov 2018 11:12:17 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:2:4:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2068:2069:2198:2199:2525:2528:2553:2557:2559:2568:2570:2627:2682:2685:2693:2703:2741:2827:2859:2892:2897:2933:2937:2939:2942:2945:2947:2951:2954:3022:3148:3586:3622:3642:3743:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4050:4250:4321:4470:4860:5007:6117:6119:6261:6298:7875:7903:8603:9010:9025:9177:10004:10346:11658:12379:12740:13139:13149:13161:13229:13230:13237, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:27, LUA_SUMMARY:none X-HE-Tag: dime09_4e10fcda82004 X-Filterd-Recvd-Size: 15013 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf06.hostedemail.com (Postfix) with ESMTPA; Sat, 3 Nov 2018 11:12:16 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6341b0f6f79cb78af389984a5f44a423" Date: Sat, 03 Nov 2018 18:12:15 +0700 From: Peter van der Stok To: Andy Bierman Cc: Carsten Bormann , peter van der Stok , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <17342.1536697549@localhost> <622CDA79-7BE4-4A71-BFF7-0C80F63A1556@tzi.org> <50f58c78b6825ce1cdbc33ea852c3145@bbhmail.nl> <84F58F84-4637-4D65-8F86-8E86B346528F@tzi.org> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [31.133.146.97] Archived-At: Subject: Re: [core] [Anima] documenting SID usage in IETF specification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 11:12:22 -0000 --=_6341b0f6f79cb78af389984a5f44a423 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi all, Jut to conclude and come to a decision. SID files are included in the I-D and RFC. SID allocation is handled by comi.space as is; remains the maintenance question of comi.space. Once I-D goes to RFC, SIDs are administrated by IANA. It would be good if comi.space is made aware of that. Can these principles and the IANA registry become part of the ietf-core-sid draft? There are currently two registries proposed in core-sid: - a YANG range registry - a YANG module assignment The latter may actually contain the sid files that are used and IANA should check that no numbers are used twice. Any suggestions? Peter Andy Bierman schreef op 2018-09-12 23:32: > On Wed, Sep 12, 2018 at 9:14 AM, Carsten Bormann wrote: > >>> On Sep 12, 2018, at 17:15, Peter van der Stok wrote: >>> >>> Hi all, >>> >>> The numbering of the SIDs in our case should be as stable as possible after publication as RFC. >>> A permanent assignment of the numbers, like the content-format numbers, would be very much appreciated. >>> Using the same already allocated numbers for other RFCs would be quite disastrous. >> >> Yes, I think that part is clear. >> >> What Andy pointed out is that we also need to have an idea of how to evolve a draft in a way that minimizes damage from changing those numbers during the development of that draft. So we need to start allocating and managing SID numbers early in their lifetime, at least from the point of time when a draft is becoming an "implementation draft" (as opposed to just an idea that wants to be discussed). That is not something we have traditionally done with IANA registrations, which are traditionally considered a scarce resource and thus should only be assigned to finished (or near-finished, hence "early allocations") protocols. >> >> My proposal would be: >> >> -- have a more explicit way of designating drafts as Implementation Drafts. Basically, any SIDs allocated before that are without protection, but once we have an Implementation Draft, the SIDs used in that will not be re-used. (Intermediate versions between Implementation Drafts would again have any new SIDs in unprotected state until another Implementation Draft is declared.) >> >> -- have a way to include the SID file in the document (draft, RFC). This is not beautiful, but unless we invent another representation for that information, that is the interchangeable form. (If we do invent another representation, maybe we should always use that?) > > Thanks for summarizing the issue and also for a very practical solution. > The SID file needs to be included in the I-Ds and the RFC. > The Implementation Draft idea sounds like the old discussions about "working group snapshots" > but it very useful info to know the difference: > > - the module and SID assignments are not stable at all and MAY change at any time in the future > - the module and SID assignments are from an Implementation Draft and SHOULD remain the same in future revisions > > - the module and SID assignments are from an RFC and MUST remain the same in future revisions > >> Grüße, Carsten > > Andy > >>> >>> Maintenance of (part of) the comi.space by a organisation like IANA could be a possibility. >>> >>> Peter >>> Andy Bierman schreef op 2018-09-12 01:32: >>> >>>> >>>> >>>> On Tue, Sep 11, 2018 at 3:12 PM, Carsten Bormann wrote: >>>> On Sep 11, 2018, at 22:25, Michael Richardson wrote: >>>>> >>>>> SHOULD ietf-core-sid say something about this? >>>> >>>> Yes, we should have a common way of handling SID allocations in RFCs. >>>> >>>> draft-ietf-core-sid sounds like a natural way to place this, but what goes into what document is often a question of who has time to write something at a particular point in time. So let's discuss this with the authors. >>>> >>>> In any case, this probably should stay at the level of a suggestion more than prescribing a normative way of doing things -- the conventions we use for this may evolve faster than the rest of the technical content of draft-ietf-core-sid. >>>> >>>> >>>> You probably want to make a clear distinction between Internet Drafts with volatile SID assignments >>>> and RFCs with permanent SID assignments. >>>> >>>> Do you want early implementation (of modules using SID) to be as painful as possible or as seamless as possible? >>>> Renumbering SID assignments may be extremely disruptive to actual deployments. >>>> Correctness of a SID file within a source document is not the same thing as correctness of all SID files >>>> across an entire administrative domain. >>>> >>>> I agree the administration of SID assignments is out of scope for CORE WG but punting >>>> the problem to vendors or operators will not be good enough. >>>> >>>> >>>> >>>> Grüße, Carsten >>>> >>>> >>>> Andy >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core [1] >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima [2] Links: ------ [1] https://www.ietf.org/mailman/listinfo/core [2] https://www.ietf.org/mailman/listinfo/anima --=_6341b0f6f79cb78af389984a5f44a423 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi all,

Jut to conclude and come to a decision.
SID files a= re included in the I-D and RFC.
SID allocation is handled by comi.spac= e as is; remains the maintenance question of comi.space.
Once I-D goes= to RFC, SIDs are administrated by IANA. It would be good if comi.space is = made aware of that.

Can these principles and the IANA registry b= ecome part of the ietf-core-sid draft?
There are currently two registr= ies proposed in core-sid:
- a YANG range registry
- a YANG module= assignment

The latter may actually contain the sid files that a= re used and IANA should check that no numbers are used twice.

An= y suggestions?

Peter

Andy Bierman schreef op 2018-09-12 23:32:



On Wed, Sep 12, 2018 at 9:14 AM, Carsten Bormann= <cabo@tzi.org<= /a>> wrote:


> On Sep 12,= 2018, at 17:15, Peter van der Stok <stokcons@bbhmail.nl> wrote:
> > Hi all,
>
> The numbering of the SIDs in our ca= se should be as stable as possible after publication as RFC.
> A p= ermanent assignment of the numbers, like the content-format numbers, would = be very much appreciated.
> Using the same already allocated numbe= rs for other RFCs would be quite disastrous.

Yes, I think that = part is clear.

What Andy pointed out is that we also need to ha= ve an idea of how to evolve a draft in a way that minimizes damage from cha= nging those numbers during the development of that draft.  So we need = to start allocating and managing SID numbers early in their lifetime, at le= ast from the point of time when a draft is becoming an "implementation draf= t" (as opposed to just an idea that wants to be discussed).  That is n= ot something we have traditionally done with IANA registrations, which are = traditionally considered a scarce resource and thus should only be assigned= to finished (or near-finished, hence "early allocations") protocols.
=
My proposal would be:

— have a more explicit way o= f designating drafts as Implementation Drafts.   Basically, any S= IDs allocated before that are without protection,  but once we have an= Implementation Draft, the SIDs used in that will not be re-used.  (In= termediate versions between Implementation Drafts would again have any new = SIDs in unprotected state until another Implementation Draft is declared.)<= br />
— have a way to include the SID file in the document (dra= ft, RFC).  This is not beautiful, but unless we invent another represe= ntation for that information, that is the interchangeable form.  (If w= e do invent another representation, maybe we should always use that?)
=
 
Thanks for summarizing the issue and also for a very practical solutio= n.
The SID file needs to be included in the I-Ds and the RFC.
The Implementation Draft idea sounds like the old discussions about "w= orking group snapshots"
but it very useful info to know the difference:
 
   - the module and SID assignments are not stable at all an= d MAY change at any time in the future
   - the module and SID assignments are from an Implementati= on Draft and SHOULD remain the same in future revisions
   - the module and SID assignments are from an RFC and MUST= remain the same in future revisions
 
 
Grüße, Carsten
 
Andy
 

>
> Main= tenance of (part of) the comi.space by a organisation like IANA could be a = possibility.
>
> Peter
> Andy Bierman schreef o= p 2018-09-12 01:32:
>
>>
>>
>&= gt; On Tue, Sep 11, 2018 at 3:12 PM, Carsten Bormann <cabo@tzi.org> wrote:
>>= On Sep 11, 2018, at 22:25, Michael Richardson <mcr+ietf@sandelman.ca> wrote: >> >
>> > SHOULD ietf-core-sid say something a= bout this?
>>
>> Yes, we should have a common way = of handling SID allocations in RFCs.
>>
>> draft-i= etf-core-sid sounds like a natural way to place this, but what goes into wh= at document is often a question of who has time to write something at a par= ticular point in time.  So let's discuss this with the authors.
= >>
>> In any case, this probably should stay at the leve= l of a suggestion more than prescribing a normative way of doing things &md= ash; the conventions we use for this may evolve faster than the rest of the= technical content of draft-ietf-core-sid.
>>
>>&n= bsp;
>> You probably want to make a clear distinction between = Internet Drafts with volatile SID assignments
>> and RFCs with = permanent SID assignments.
>> 
>> Do you want= early implementation (of modules using SID)  to be as painful as poss= ible or as seamless as possible?
>> Renumbering SID assignments= may be extremely disruptive to actual deployments.
>> Correctn= ess of a SID file within a source document is not the same thing as correct= ness of all SID files
>> across an entire administrative domain= =2E
>> 
>> I agree the administration of SID = assignments is out of scope for CORE WG but punting
>> the prob= lem to vendors or operators will not be good enough.
>>  <= br /> >> 
>> 
>> Grüße= , Carsten
>> 
>> 
>> Andy >> 
>>
>> _______________________= ________________________
>> core mailing list
>= > core@ietf.org<= br /> >> https://www.ietf.org/mailman/listinf= o/core
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
&= gt;> https://www.ietf.org/mailman/listinfo/anim= a

--=_6341b0f6f79cb78af389984a5f44a423-- From nobody Sat Nov 3 06:32:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4AC128CF3 for ; Sat, 3 Nov 2018 06:32:46 -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 xkjQYWP0njmR for ; Sat, 3 Nov 2018 06:32:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA4F1277D2 for ; Sat, 3 Nov 2018 06:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA3DWaIp009931; Sat, 3 Nov 2018 14:32:41 +0100 (CET) Received: from [IPv6:2001:67c:1230:105:5c53:b8bb:f5a9:e4ef] (unknown [IPv6:2001:67c:1230:105:5c53:b8bb:f5a9:e4ef]) (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 42nKcf67Nyz1Bqf; Sat, 3 Nov 2018 14:32:34 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Sat, 3 Nov 2018 20:32:31 +0700 Cc: Andy Bierman , Core X-Mao-Original-Outgoing-Id: 562944748.969873-8acfae18cc4c830068d2c0241670737c Content-Transfer-Encoding: quoted-printable Message-Id: <82ECE4AE-5284-42A4-B85D-7B5B413FD858@tzi.org> References: <17342.1536697549@localhost> <622CDA79-7BE4-4A71-BFF7-0C80F63A1556@tzi.org> <50f58c78b6825ce1cdbc33ea852c3145@bbhmail.nl> <84F58F84-4637-4D65-8F86-8E86B346528F@tzi.org> To: peter van der Stok X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [Anima] documenting SID usage in IETF specification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 13:32:46 -0000 On Nov 3, 2018, at 18:12, Peter van der Stok = wrote: >=20 > The latter may actually contain the sid files that are used and IANA = should check that no numbers are used twice. While that is always a good thing: How could that happen? Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Nov 3 06:45:53 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A5E128CB7 for ; Sat, 3 Nov 2018 06:45:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 xrez7pj1sEuO for ; Sat, 3 Nov 2018 06:45:49 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2650127148 for ; Sat, 3 Nov 2018 06:45:49 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 6481B18021DB2; Sat, 3 Nov 2018 13:45:48 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1534:1541:1575:1588:1589:1592:1594:1711:1714:1730:1776:1792:2198:2199:2528:2553:2559:2562:2693:2827:3138:3139:3140:3141:3142:3350:3622:3865:3867:3868:3871:3874:4250:4321:5007:6117:6261:6298:6657:6659:6678:7875:7903:8603:9177:10004:10214:10400:10848:11232:11658:11783:11914:12043:12740:12895:13071:13139:13161:13229:14096:14180:14181:14721:21060:21080:21433:21451:21625:30034:30041:30054:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, LUA_SUMMARY:none X-HE-Tag: brush10_6cd5928a92b4f X-Filterd-Recvd-Size: 3537 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf19.hostedemail.com (Postfix) with ESMTPA; Sat, 3 Nov 2018 13:45:47 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_18e6b057c0ad55422f0c24c624b9c6f6" Date: Sat, 03 Nov 2018 20:45:47 +0700 From: Peter van der Stok To: Carsten Bormann Cc: peter van der Stok , Andy Bierman , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <82ECE4AE-5284-42A4-B85D-7B5B413FD858@tzi.org> References: <17342.1536697549@localhost> <622CDA79-7BE4-4A71-BFF7-0C80F63A1556@tzi.org> <50f58c78b6825ce1cdbc33ea852c3145@bbhmail.nl> <84F58F84-4637-4D65-8F86-8E86B346528F@tzi.org> <82ECE4AE-5284-42A4-B85D-7B5B413FD858@tzi.org> Message-ID: <1ee600960e00adc9926b87425a585d3d@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [31.133.146.97] Archived-At: Subject: Re: [core] [Anima] documenting SID usage in IETF specification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 13:45:52 -0000 --=_18e6b057c0ad55422f0c24c624b9c6f6 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Carsten, there are two sides to your question: - How do we convince IANA to take the responsibility - How will they check the SID files: Like they check the content-format numbers and others Was there a third side? Peter Carsten Bormann schreef op 2018-11-03 20:32: > On Nov 3, 2018, at 18:12, Peter van der Stok wrote: > >> The latter may actually contain the sid files that are used and IANA should check that no numbers are used twice. > > While that is always a good thing: How could that happen? > > Grüße, Carsten --=_18e6b057c0ad55422f0c24c624b9c6f6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Carsten,

there are two sides to your question:
- How do = we convince IANA to take the responsibility
- How will they check the = SID files: Like they check the content-format numbers and others

Was there a third side?

Peter

Carsten Bormann schreef op 2018-11-03 20:32:

= On Nov 3, 2018, at 18:12, Peter van der Stok <stokcons@bbhmail.nl> wrote:

The latter may actually contain the sid files t= hat are used and IANA should check that no numbers are used twice.
While that is always a good thing: How could that happen?

Grüße, Carsten

--=_18e6b057c0ad55422f0c24c624b9c6f6-- From nobody Sat Nov 3 07:34:19 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9D21277D2 for ; Sat, 3 Nov 2018 07:34:17 -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 U_nmXRQxQ4bH for ; Sat, 3 Nov 2018 07:34:16 -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 34789124408 for ; Sat, 3 Nov 2018 07:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA3EY7mL025766; Sat, 3 Nov 2018 15:34:12 +0100 (CET) Received: from [IPv6:2001:67c:1230:105:5c53:b8bb:f5a9:e4ef] (unknown [IPv6:2001:67c:1230:105:5c53:b8bb:f5a9:e4ef]) (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 42nLzf2BMjz1Bqf; Sat, 3 Nov 2018 15:34:05 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <1ee600960e00adc9926b87425a585d3d@bbhmail.nl> Date: Sat, 3 Nov 2018 21:34:01 +0700 Cc: Andy Bierman , Core X-Mao-Original-Outgoing-Id: 562948439.888887-cde5e596bf266414edd68a1df0278923 Content-Transfer-Encoding: quoted-printable Message-Id: <937F3F95-6B97-4773-BAC6-8BE6A3A903C3@tzi.org> References: <17342.1536697549@localhost> <622CDA79-7BE4-4A71-BFF7-0C80F63A1556@tzi.org> <50f58c78b6825ce1cdbc33ea852c3145@bbhmail.nl> <84F58F84-4637-4D65-8F86-8E86B346528F@tzi.org> <82ECE4AE-5284-42A4-B85D-7B5B413FD858@tzi.org> <1ee600960e00adc9926b87425a585d3d@bbhmail.nl> To: peter van der Stok X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [Anima] documenting SID usage in IETF specification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 14:34:18 -0000 On Nov 3, 2018, at 20:45, Peter van der Stok = wrote: >=20 > Hi Carsten, >=20 > there are two sides to your question: > - How do we convince IANA to take the responsibility That depends a lot on the scale. There will be hundreds of modules, = each potentially with hundreds of SIDs. So we are creating a problem on the scale of IANA=E2=80=99s biggest = registry (Private Enterprise numbers, PENs). I=E2=80=99m not sure that is realistic. > - How will they check the SID files: Like they check the = content-format numbers and others The allocation is based on mega-ranges. What people do within their = allocations should really be their business. Only for the IETF range we may want to go into more detail, and that = should be based on allocating ranges for the modules. The only thing that needs to be checked is that all SIDs of a module are = within the range allocated to the module, and that those allocations = don=E2=80=99t overlap. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Nov 4 04:04:42 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFFA130E09 for ; Sun, 4 Nov 2018 04:04:39 -0800 (PST) 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 WkUrJ-Cbe8L5 for ; Sun, 4 Nov 2018 04:04:38 -0800 (PST) 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 5D89912426A for ; Sun, 4 Nov 2018 04:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA4C4Unp026478 for ; Sun, 4 Nov 2018 13:04:35 +0100 (CET) Received: from [172.20.81.28] (110-170-235-6.static.asianet.co.th [110.170.235.6]) (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 42nvcY55WSz1Bqf; Sun, 4 Nov 2018 13:04:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <64EB078F-F701-4403-9855-29F5B33DB9CF@tzi.org> Date: Sun, 4 Nov 2018 19:04:25 +0700 X-Mao-Original-Outgoing-Id: 563025863.294789-861f681e6704abe8b53a0c99ebdb7aaa Content-Transfer-Encoding: quoted-printable Message-Id: References: <64EB078F-F701-4403-9855-29F5B33DB9CF@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-hartke-core-s?= =?utf-8?q?tateless?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 12:04:40 -0000 > This formal WG adoption call runs until the end of October 31st. We are now past this date. Together with the support in the interim meeting, we have reached = consensus for adoption. Klaus: Please submit as draft-ietf-core-stateless. As threatened, unless there is a reasoned objection, WGLC is next. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Nov 4 06:57:16 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0C1130DD9; Sun, 4 Nov 2018 06:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MefZTPs6SWGW; Sun, 4 Nov 2018 06:57:07 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 13E8B130E0E; Sun, 4 Nov 2018 06:57:07 -0800 (PST) Received: from mail-qk1-f172.google.com ([209.85.222.172]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJJpl-00083f-Or; Sun, 04 Nov 2018 15:57:01 +0100 Received: by mail-qk1-f172.google.com with SMTP id u68so10673699qkg.9; Sun, 04 Nov 2018 06:57:01 -0800 (PST) X-Gm-Message-State: AGRZ1gLePBOe+5MAZAd6RHdEERxKVajSAPN3U4Cej6yk/pXflX5DJ5OM yH8aE2TpyJ4gPY5qK6RAaobGQpHziy1uc3l06NY= X-Google-Smtp-Source: AJdET5d0mm2+vCHWWwJM26EpDdUPzTpmLsxGgKyN/TipXjL23ghGi5538EkYg+Rsu/W0fM9K+RJEsQgCWHjCw3T6vf0= X-Received: by 2002:aed:26a3:: with SMTP id q32mr5953642qtd.106.1541343420651; Sun, 04 Nov 2018 06:57:00 -0800 (PST) MIME-Version: 1.0 References: <20181031164534.GA4995@hephaistos.amsuess.com> In-Reply-To: <20181031164534.GA4995@hephaistos.amsuess.com> From: Klaus Hartke Date: Sun, 4 Nov 2018 15:56:28 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: T2TRG@irtf.org, draft-hartke-t2trg-coral@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541343427; 880428d0; X-HE-SMSGID: 1gJJpl-00083f-Or Archived-At: Subject: Re: [core] [T2TRG] Review of CoRAL X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 14:57:09 -0000 Hej Christian, again, thanks a lot for your feedback. I'll start with some low-hanging fruits and create separate threads for larger topics. As part of the IETF103 Hackathon this weekend, I've started doing some basic interop testing of our two CoRAL implementations. There was one blocking issue and a few minor issues, the blocking issue being this one from your review: > * How are compressed URIs expressed in CBOR? Flat [6, "foo", 6, "bar"] > or nested [[6, "foo"], [6, "bar"]]? My first reading (and current > implementation) resulted in "nested", supported by the `(option, > value) = href[0]` line in C4, but reading C.1 with the CDDL spec next > to it (and running the cddl tool) rather indicates "flat" to me. The representation of the list of options is indeed different in the draft for CBOR and Python. In Python, it feels natural to me to iterate over the list as a list of pairs, while in CBOR I don't see a need to wrap each pair in an extra array. So, in CBOR, the array should be flat: [6, "foo", 6, "bar"]. If it improves clarity, the Python code could be updated to operate on flat lists instead, e.g., using the grouper function from : - for option, _ in href: + for option, _ in grouper(href, 2): Minor interop issues: body.py: > if ':' in i.relation: > rel = i.relation > else: > rel = 'http://www.iana.org/assignments/relation/' + i.relation When a relation is provided as a string, the intention is that the string always contains the IRI. I don't think the current set of IANA-registered link relation types is relevant enough in the context of IoT that it should get special treatment. body.py: > elif isinstance(i, BaseDirective): > base = base / i.iri The draft currently specifies that a base IRI is resolved against the current context IRI, not the previous base IRI. Editorial issues: > * Is there a difference between a CoRAL registry and a CoRAL profile? > Both terms are used. The draft uses the "profile" media type parameter defined in to indicate the CoAL registry, which I think makes more sense to define a new "registry" parameter with essentially the same semantics. So "profile" should appear only as the parameter name. I've replaced all instances where "profile" appeared without this meaning with "registry". > * Why is used for attrs, but used > for the core form relations? They could at least share structural > similarity. In general, I think URNs would make more sense for identifiers than HTTP URIs, as the latter always look like they could be successfully dereferenced. But it seems that HTTP URIs are more popular in the Semantic Web... Right now, both and (which I've replaced with and in my working copy, respectively) are just visually distinct placeholders until IETF-controlled IRIs are assigned. > * If the first use of the http://www.iana.org/assingments/relation/ > prefix for rel values pointed to RFC4287, it would be clearer to the > reader that this is already established practice. The whole Examples section probably needs an overhaul, but I've moved the text about expressing registered link relations into its own section and added a note that the prefix is already established practice. > * Any test vectors or examples to get started on the binary format would > be helpful, and could be augmented by (CDDL automatically?) annotated > extended diagnostic notation, like (as in the above, assuming a > navigation profile where someone forgot that favicon is a typical rel) My idea was to maintain a collection of test vectors in a GitHub repository, so that the test vectors can be more numerous and more easily fixed than in an RFC. Now that we creating a bunch of examples for use cases like RD, it would actually be a good time to start that. Best regards, Klaus From nobody Sun Nov 4 07:07:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7E6130E13 for ; Sun, 4 Nov 2018 07:07:48 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DVKScMimPtE for ; Sun, 4 Nov 2018 07:07:47 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 B3783130E17 for ; Sun, 4 Nov 2018 07:07:47 -0800 (PST) Received: from mail-qk1-f182.google.com ([209.85.222.182]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJK0A-0002BV-7v; Sun, 04 Nov 2018 16:07:46 +0100 Received: by mail-qk1-f182.google.com with SMTP id y16so9521822qki.7 for ; Sun, 04 Nov 2018 07:07:46 -0800 (PST) X-Gm-Message-State: AGRZ1gJbPn4Gyjj837Iq1AQ62Nm7F/zkBinHO5pFeyyp3I5sjaOz4BbR EX0fzBW3uXzFndp/cvf6vilpPdV+ohcFIDpeyk4= X-Google-Smtp-Source: AJdET5fp5IdtEUwhjbJom60ECn8cepboPDq7us2dbvStP1mBjDBQg959IhZ5gKUy+Apy1wiG+3sG9eqOj04oOpc4iec= X-Received: by 2002:a37:a84b:: with SMTP id r72mr18054519qke.2.1541344065279; Sun, 04 Nov 2018 07:07:45 -0800 (PST) MIME-Version: 1.0 References: <20181031065938.GA6605@hephaistos.amsuess.com> <360fce5cf526718475f9d1fffa66ca4c@bbhmail.nl> In-Reply-To: <360fce5cf526718475f9d1fffa66ca4c@bbhmail.nl> From: Klaus Hartke Date: Sun, 4 Nov 2018 16:07:13 +0100 X-Gmail-Original-Message-ID: Message-ID: To: peter van der Stok Cc: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541344067; 60f96f39; X-HE-SMSGID: 1gJK0A-0002BV-7v Archived-At: Subject: Re: [core] Links, hosts, and resource directories X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 15:07:49 -0000 Peter van der Stok schrieb: > Christian Ams=C3=BCss schreef: >> Klaus Hartke wrote: >>> [A Resource Directory (RD)] hosts registrations of >>> resources held on other servers, allowing lookups >>> to be performed for those resources. >>> >>> Is this a lie? >> >> Without more context, yes it is, and we should ensure that the wording >> does not lead to the conclusion that resources (and not links) would be >> stored. > > Sorry to react to this, but > I cannot imagine how "registrations of resources" can be equated with "re= sources". > > But if it creates confusion it needs to be adapted. Don't get too hung up on this particular sentence. The issue is more the overall impression I got after skimming the current draft version combined with the interop spec, which felt inconsistent. Maybe the introduction is fine and just some legacy examples need fixing. I'll make suggestions when I can pinpoint exactly what trips me up. Let me ask a few more dumb questions first to make sure I get things right. Klaus From nobody Sun Nov 4 07:28:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739D9130E1B for ; Sun, 4 Nov 2018 07:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 CoN1Tq8wrbS3 for ; Sun, 4 Nov 2018 07:28:44 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 CA9E8130DCF for ; Sun, 4 Nov 2018 07:28:44 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id g10so5744005otl.12 for ; Sun, 04 Nov 2018 07:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d1YtVU7EA+lL8WSWk6xUBrGCFdrybe3+jm0Ia1/2Lag=; b=h2p4V4MLEhN28ZrMoVOffhM6reQZuR6WqBfnLxsXS5LEtqeIf3JVcSdII5nq7a8qWy NFO4CO+nBurImI8vYbv4LOB7RYcg3CCBv+E997JgkJI+SQ2Qr3ImzYSrNPqVATBDjCg1 yVoNAwU7FyGr2PGoZss6XA+K0xoVJxy67w1S8qc83/fkWu7X+G2HUzrYsF+4kk4GI+bB 99qOoL06hmOcFxWIYgWDFxO2XXqZ3po6gGB3ILfhYMSi31fs+QXalySfRe5IMMw+NDit x64h1Xu2RDfHhHcI1BhklwSTf67VqGM6paq7UlUk041e9jU8y0K6mK1bgC+GreLXzPNX sDjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d1YtVU7EA+lL8WSWk6xUBrGCFdrybe3+jm0Ia1/2Lag=; b=oUnMFGxr8zcNfZSsXiRPR8Pha6fwdL/cqq+a10KG1KnV2vMBEDj2hqvceQMnWz5R28 /v1YoI0wooDV48YzGAQSHTeQrJB9E39smQ12G6LS1WtpF4IkXTjBfRYkoc8t5oakeeUC 2gvZOTRkUKLgeo2z+U/iuTTd+gd4bQQjfWP/RfBVmTSAGy+9uWB6th63XL+OoFF2zJEX 1fxUCCbIg9ysr7mdsraMCuhUEKDhwO7epgBgjfTrPuxZCiua6CUXUWO5wSCya2PrOdSP f5rkTQ9mEgn1Lk+OpiVU91nype3/YY2o/FOV1qRYDiwixpwMEoRbqutcsNbIFOb1twPT Cjcg== X-Gm-Message-State: AGRZ1gKjhdaE8qhfvIL6x0VJEV8c1mV80V9JQ021jawDheC3mPQO2ZHe EK46bJwZ/wDRT3EHU9KFa4zGQpET X-Google-Smtp-Source: AJdET5e1E7I7KKDPtF1DcO5XafkPEpPei8HmQW9hkP8nuZnuEynHKBOD28E8zRPZq+t4rc0cbo43yg== X-Received: by 2002:a9d:28b0:: with SMTP id s45mr11938096ota.138.1541345324178; Sun, 04 Nov 2018 07:28:44 -0800 (PST) Received: from [10.0.0.3] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id y204-v6sm5996587oiy.40.2018.11.04.07.28.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 07:28:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: Date: Sun, 4 Nov 2018 07:28:37 -0800 Cc: peter van der Stok , =?utf-8?Q?=22Christian_M=2E_Ams=C3=BCss=22?= , "core@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <214E0D57-75FA-4631-B94C-3F0A1B167A01@gmail.com> References: <20181031065938.GA6605@hephaistos.amsuess.com> <360fce5cf526718475f9d1fffa66ca4c@bbhmail.nl> To: Klaus Hartke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Links, hosts, and resource directories X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 15:28:48 -0000 It is a common mis-perception that resource representations can be = obtained from a Resource Directory. Best regards, Michael > On Nov 4, 2018, at 7:07 AM, Klaus Hartke = wrote: >=20 > Peter van der Stok schrieb: >> Christian Ams=C3=BCss schreef: >>> Klaus Hartke wrote: >>>> [A Resource Directory (RD)] hosts registrations of >>>> resources held on other servers, allowing lookups >>>> to be performed for those resources. >>>>=20 >>>> Is this a lie? >>>=20 >>> Without more context, yes it is, and we should ensure that the = wording >>> does not lead to the conclusion that resources (and not links) would = be >>> stored. >>=20 >> Sorry to react to this, but >> I cannot imagine how "registrations of resources" can be equated with = "resources". >>=20 >> But if it creates confusion it needs to be adapted. >=20 > Don't get too hung up on this particular sentence. The issue is more > the overall impression I got after skimming the current draft version > combined with the interop spec, which felt inconsistent. Maybe the > introduction is fine and just some legacy examples need fixing. I'll > make suggestions when I can pinpoint exactly what trips me up. Let me > ask a few more dumb questions first to make sure I get things right. >=20 > Klaus >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Nov 4 07:35:41 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B580130E6A; Sun, 4 Nov 2018 07:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61GsEsmk0JXf; Sun, 4 Nov 2018 07:35:35 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 8E14C130E2E; Sun, 4 Nov 2018 07:35:32 -0800 (PST) Received: from mail-qk1-f169.google.com ([209.85.222.169]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJKR0-0001o7-RV; Sun, 04 Nov 2018 16:35:30 +0100 Received: by mail-qk1-f169.google.com with SMTP id r71so10771412qkr.10; Sun, 04 Nov 2018 07:35:30 -0800 (PST) X-Gm-Message-State: AGRZ1gJ4AKZxcOIcRJyImvwhctHn3/mu7eJm3A+KPq84kArFYHNGKkN2 wtwWZ1nLSE/eYEtRhmcNqfBP8a/gCbz/891chNg= X-Google-Smtp-Source: AJdET5fkKzGA351jsb5TUzWPSgDaqhDd2KxnQdNA9F2XTaB595I4g6mETC2f2QFfp+MWoWKKomlOqIwnVwNItKvAcxQ= X-Received: by 2002:a37:455:: with SMTP id 82mr17540520qke.60.1541345729839; Sun, 04 Nov 2018 07:35:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Klaus Hartke Date: Sun, 4 Nov 2018 16:34:58 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "core@ietf.org WG" , draft-ietf-core-hop-limit@ietf.org Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541345735; 9fe299d6; X-HE-SMSGID: 1gJKR0-0001o7-RV Archived-At: Subject: [core] draft-ietf-core-hop-limit-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 15:35:40 -0000 Hi authors of draft-ietf-core-hop-limit, the draft was discussed a couple of times in the recent virtual interims of CoRE, but I'm not sure if the conclusions ever made it the mailing list. We discussed the open questions from the August 29 virtual interim [1], with the following conclusions: > * Would it be useful to have a general-purpose content format for > providing details of an alternate server, or is the information too > DOTS-specific? In general, a general-purpose content format would be nice, but for now a DOTS-specific content format is fine. > * Should a more specific media type than "application/cbor" be used? Yes. (draft-ietf-dots-signal-channel now uses "application/dots+cbor".) > * Is {elective, safe to forward, not part of the cache key} the right choice? > * Is {elective, safe to forward, part of the cache key} the better choice? The option should be elective, safe-to-forward, and part of the cache key. If a cache understands the option, it should perform a greater-than-or-equals comparison instead of just checking for equality of the option value. > * Is there a better number than 5.06? (HTTP 506 is: Variant Also > Negotiates [RFC2295]) Allocating response code 5.06 for "Hop Limit Reached" is fine, since "Variant Also Negotiates" is unlikely to make it into CoAP. Best regards, Klaus [1] https://www.ietf.org/mail-archive/web/core/current/msg09830.html From nobody Sun Nov 4 11:52:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D266D126CB6 for ; Sun, 4 Nov 2018 11:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Xsl0xeMX; dkim=pass (1024-bit key) header.d=ericsson.com header.b=GnK8Ijus 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 2neq05BRhzTR for ; Sun, 4 Nov 2018 11:52:26 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA69123FFD for ; Sun, 4 Nov 2018 11:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541361144; x=1543953144; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nRMdPAttX5gxwHOA7CcRUztSYI76TzMIGYtoNDsQbOU=; b=Xsl0xeMXefDRuvpYM+sRq+UWqsygsLDA7+OwuJg/sCiprXIwjIzdhkKCbxLcxJ3w pYvzU6ldiUYuBvHp6q57c+n8FeU/jAy1s7rB3OmhVotPJJSB8z/YCXa6NZlxoQNk BKxHUAgSOpWjmRWYxm3fSs/LbnKZVu4ZbuSP63O1u/Y=; X-AuditID: c1b4fb30-1ebff70000007d19-cd-5bdf4df78cff Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0E.33.32025.7FD4FDB5; Sun, 4 Nov 2018 20:52:24 +0100 (CET) Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 4 Nov 2018 20:52:23 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 4 Nov 2018 20:52:23 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sun, 4 Nov 2018 20:52:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K4/lPIlnfP5X8ZKZps/04KoN/9Xi/bQShLNmLP8lOII=; b=GnK8IjustQcRrWv+Va1NN5eCFgHzXU3Oke7Nu6lDjXtivLNyi6lOglIGAv6a53j0DuSvTZqVGmR/FYX+XG2KqVWEMeJWuv3F7OoxM2DJ58bMddXg43SceTivFcDHOM2Z23DODWYSHngdNdcYtFYW03ka9YhLIB+Da/CpLMe0W5s= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB3356.eurprd07.prod.outlook.com (10.170.247.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.10; Sun, 4 Nov 2018 19:52:22 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95%3]) with mapi id 15.20.1294.032; Sun, 4 Nov 2018 19:52:22 +0000 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: =?iso-8859-1?Q?Christian_Ams=FCss?= , core Thread-Topic: Short review of SenML fetch/patch Thread-Index: AQHUVkB5+PFf3+Mfc0qMr/ag7hWmPw== Date: Sun, 4 Nov 2018 19:52:22 +0000 Message-ID: References: <20180927085947.GA5321@hephaistos.amsuess.com> <8F814ABD-10B3-4279-945B-D1B33E0BD1A8@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3356; 6:HUdkwyQXAlYqe7B0AAPthCboGCnfV8s/CSSD+upgfTIUitDII9m5Owh8ncXGhfDZzyszMsOFmsq2/ntQBaT3ZtdGWbgM6FYq9dHzDT2L+ZEHGnwgPGewmCy/l+anDJhgz2rnp+Qy0AHt/2CEL+dA9/QNK0Zrl5iT2AOxEioPjIqPVVzkk2ZK6IQBX+LiPtk/brp20fTDKT2ht4SR3opKklh9JkzqyCCEFmks0+Kwt0eiOpU8LPd6Tc5a3ZTvKFTrloSbOVUwUXgBAW0XuK22sTw4Nb2u0p96ZvZZ1ocTzPUTaKnxECMa3gylYuXFpxo8GCRyqmoDQ/OtYjD7jPAn0UL4k+y+bCiSilnxK/PT+fCF1TmTRBVOEYalt0WUExaf+N6qL+nVx1QTGqs+NPSGcUPSBcX7unisuU7FOp1THcnvdmWke35ucEKzvxE0dyn2XZEt/JaIpQP9zpVIWBaCpA==; 5:t8Ys0QotdGQ+tIR6Nkd+DIBYGMIw7DCs4K60g/sNjrXrwUECpi3lcCO+/HMlFrTQwDr8169imS0UREgTV+cWNDjVoDHCZUSzijPbJkFcXGDQFI1x+NWOSDGxoIBl87aVj5Sj2EXGN+EajDA5bLmsArdgV4u25L8b/+KM3XTs5jw=; 7:0NUo3HXAxtYs8jEwN16iqthGEfPj/lMcMMNQHAekoHpSBOiEESJ4vjHWyK8sj036xPsodlWX+TzTTpLQD58p8ImnMZczk8M95oHZMDD8vR8iIORH0OgyJ8TRj30351VizgSBuQ54TPxRcI82ryNo1A== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 11b53a08-297d-4ae1-8680-08d6428f0934 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3356; x-ms-traffictypediagnostic: HE1PR07MB3356: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3356; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3356; x-forefront-prvs: 084674B2CF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(366004)(376002)(346002)(199004)(43544003)(189003)(74316002)(256004)(71190400001)(305945005)(71200400001)(5660300001)(26005)(66066001)(14444005)(229853002)(345774005)(97736004)(81156014)(6246003)(81166006)(8676002)(105586002)(8936002)(25786009)(106356001)(86362001)(6436002)(6506007)(53936002)(76176011)(2906002)(316002)(68736007)(478600001)(7696005)(55016002)(2900100001)(99286004)(486006)(7736002)(446003)(476003)(66574009)(186003)(102836004)(6116002)(3846002)(33656002)(6306002)(9686003)(110136005)(14454004)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3356; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LnG3bD8TZ77DBefEcQ0Wl+vJWoUEMHuIxtj/rXGnLdzcHJQPkYL99DHTeCD7bFRQYx/k+2uUp7ayVMFcw4CA00oZ1AqKTTaqsf5R2+0myKat+w1owlGQIarlpo8vGnTt2zGMyFm30JVUtYu9ToPTCX1WM8tboFZhC6mhpRI+Lnpsc7qBgWJ+zIhkF3uMJ7CQmdmz/SaxohSudj7zlFGLD7I1KuqV8FvrcPyu10SamlxxoOrxHLKf5Hkl9kM/mPqi53SOXJC0tcQ6LEJZZDsc6K54V5+ojSmpwJ4DkXfsgdf97gHSeKKV/RtkiXpMhTYiy5+ZhmD+iaoySbXB8hd3ScLOgMGluPNrzlPDfjCxVQI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 11b53a08-297d-4ae1-8680-08d6428f0934 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2018 19:52:22.0536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3356 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec9lHoej4/LyoHRxCYmXuaTBIMmuaIhR2EVU0JUH71POMVH7 soqMJtryEirIrDa3xLB05T6EuCWoAxNHjRTBhpI3FBUyW6RtOwv69n9////zvM/z8lK4+AEZ QRWrqhhWpSyTCIRER9YQl7CbMZ8j205VDFuaCMXwej9+BkvTWN1kml7/C7uCZQuTC5iy4mqG TTydLyzq+zwtqJyR1zyz7GBqNBCnQYEU0CfhXfPjAA0SUmJ6FMFS8wbyGmL6B4JH7Xm84dE9 /Q6MN15i8MoY4zUIWovD9icj4lMtGJht7zH+4EKgW3P6SgR0CrT0bXlSFBVC34QnhjAvPkhL wd3xh+RxIjgnMr04xIN3J5dxryboaFi/v+zrIqJzwazt9A9RCQbHiMCrER0GP+19Po7T4TC7 qMP41WjQf5jCeR0KKwt7JJ/PgVX7RADPo2Byw+XPHwKHrsG3C9BOAbhNzYg3EmCzrc3fKAPe Dg0SfGgMgXtjh+SNWFgZ7PIXlEJrl47gdS7MGxb9NxyG3kaXn4/h4GxM0CJZ53+D81oKX9ta BbyOg57na3in7wGCYaJjkehGRC8K5RjuVnlhUpKUYYtvc1yFSqpiqgaQ52tYzb9lFrSydNaG aApJgkRXT83niEllNVdbbkNA4ZIQ0ccLHiQqUNbWMWxFHnunjOFsKJIiJOEixeXBbDFdqKxi ShmmkmH/uRgVGKFGhlR7+viIlNkfJbeS444ELWSVRKXJSc2llO6YSKMjfkr9XdWUybD1Dees X/LtsBesUArPv1DHD02a5pKPjt9zWb+V9LA1N7SCA5LoJPnsHLEercice31x6ql5uuFht2LG FFl37PjItqlcf23/ut7YLt+sv/vGkrKavizTNkoIrkh5IhZnOeVfBZ4MvxYDAAA= Archived-At: Subject: Re: [core] Short review of SenML fetch/patch X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 19:52:29 -0000 Hi Christian et al,=0A= =0A= Thank you once more for the thorough review Christian!=0A= =0A= After discussing the media type issue with various CoRE and OMA DM =0A= folks, using new media types for the SenML FETCH/PATCH seems to be a =0A= good approach. Hence I'm proposing we'll go that way in the next version = =0A= of the draft (see -00 draft [1] how that could look like in practice). =0A= This should address most of your remaining comments below.=0A= =0A= We still need to decide on how to indicate delete operation though. "v: =0A= null" and "vdel: true" seem to be our options. Some pros and cons are =0A= discussed in the original e-mail below. Input on this is very welcome.=0A= =0A= =0A= Cheers,=0A= Ari=0A= =0A= [1] https://tools.ietf.org/html/draft-keranen-core-senml-fetch-00#section-5= =0A= =0A= On 28/09/2018 1.07, Ari Ker=E4nen wrote:=0A= > Thank you for the review Christian!=0A= > =0A= > See inline.=0A= > =0A= >> On 27 Sep 2018, at 11.59, Christian Ams=FCss wro= te:=0A= >>=0A= >> Hello authors,=0A= >>=0A= >> as requested during yesterday's interim meeting, I've had a look at=0A= >> senml-fetch again:=0A= >>=0A= >> Fetch=0A= >> =3D=3D=3D=3D=3D=0A= >>=0A= >> Fetching by time=0A= >> ----------------=0A= >>=0A= >> Being able to pick aparticular timestamp is an oddly specific=0A= >> application; my impression of general SenML data sets is that it will be= =0A= >> hard to predict which point in time should have a datum if that record= =0A= >> is not already known. Unless there are good (and argued for) use cases,= =0A= >> I suggest that the topic of fetching time series points be explored=0A= >> comprehensively in a separate document, possibly hooking into=0A= >> draft-bormann-t2trg-stp.=0A= > =0A= > The time-stamp use case I had in mind was where the record is already kno= wn, so it's mainly useful for PATCHing, but didn't see issue having it for = FETCH too (say, you know time out of band). Otherwise we have no mechanism = to tell apart two records from the same source.=0A= > =0A= > =0A= >> Using SenML to fetch=0A= >> --------------------=0A= >>=0A= >> SenML requires to have a value (or sum) on every record, the payload of= =0A= >> the fetch request therefore can't use any of the defined SenML mime=0A= >> types but would need to specify their own. I'm unsure on whether adding= =0A= >> a field like "fetch_":1 to the first record (a mandatory-to-decode=0A= >> custom field) would be sufficient to work around that constraint.=0A= >>=0A= >> Otherwise, it might be an option to update RFC8428 to say that some of= =0A= >> those limitations (also the later "v":null) may be overridden in=0A= >> applications like this where it is made sure (eg. by never using those= =0A= >> freedoms in Content or PUT payloads) that no generic SenML processor=0A= >> ever gets its hands on the document.=0A= > =0A= > Good point. Maybe updating 8428 with the exception that restrictions on v= alue don't apply for FETCH/PATCH is appropriate.=0A= > =0A= >> The payload sent in as a FETCH payload is not actually sensor data, it's= =0A= >> a list of names (or, provided they're viewed as URIs, which I recommend)= =0A= >> links. We already have a way to transmit a list of links in CoRE=0A= >> (actually 3 with links-json). I don't object to introducing another=0A= >> (given the above, might be called application/links+senml+{cbor,json}?)= =0A= >> especially to reduce parsing complexity, but do suggest that FETCHing=0A= >> SenML data be done with a list of identifiers no matter how they are=0A= >> transported, and the recommended way can well be a SenML-names-only=0A= >> payload (but would not preclude others).=0A= > =0A= > The payload is a list of names without URI semantics (e.g., may not have = scheme at all, have different concatenation semantics, etc.) and timestamps= , so I think it's quite different from the other link formats.=0A= > =0A= >> Patch=0A= >> =3D=3D=3D=3D=3D=0A= >>=0A= >> "value field with value null": There has been some backpressure against= =0A= >> having variable-type fields in SenML back when its JSON/CBOR structure= =0A= >> was last changed; having a "v":null in there could be problematic (esp.= =0A= >> as its JSON type is fixed to Number in Table 2 of RFC8428). I suggest=0A= >> having a explicit "delete value" field, eg. "vdel":true.=0A= > =0A= > The "v":null approach made this nice and clean, but you do have a valid p= oint to consider here. Will have a closer look at this.=0A= > =0A= >> How would base values work with patch? I figure that it's always the=0A= >> resolved record that matter, but that should be explicit. In connection= =0A= >> with a "vdel" (or "v":null if it turns out it's OK for it to stay like= =0A= >> that), it might make sense to allow that too (where a "v":n would=0A= >> override "vdel" or "v":null from an offset of zero) to allow for=0A= >> efficient batch removal of values.=0A= > =0A= > Yes, resolved records are that matter (see end of section 3.1). I'm not q= uite sure what you suggest allowing though?=0A= > =0A= >> Security considerations=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= >>=0A= >> "potentially allow retrieving or changing many resources at once" makes= =0A= >> it sound like FETCH and PATCH could reach out to different resources.=0A= >> They don't (conceptually), they only manipulate what's inside the target= =0A= >> resource (which typically is an aggregation of other resources, as in a= =0A= >> core-interfaces batch). Suggested replacement:=0A= >>=0A= >> In FETCH and iPATCH requests, the client can pass arbitrary names to= =0A= >> the target resource for manipulation. The resource implementer must= =0A= >> take care to only allow access to names that are actually part of (or= =0A= >> accessible through) the target resource.=0A= >>=0A= >> If the client is not allowed to do a GET or PUT on the full target=0A= >> resource (and thus all the names accessible through it), access=0A= >> control rules must be evaluated for each record in the pack.=0A= >>=0A= >> (It's fine if someone goes ahead and defines a /senml resource on their= =0A= >> device that is a gate to "everything and anything that can be addressed= =0A= >> in SenML", but that shouldn't be the default assumption).=0A= > =0A= > Good point. The replacement looks good to me.=0A= > =0A= > =0A= > Thanks,=0A= > Ari=0A= > =0A= >> Best regards=0A= >> Christian=0A= >>=0A= >> -- =0A= >> You don't become great by trying to be great. You become great by=0A= >> wanting to do something, and then doing it so hard that you become great= =0A= >> in the process.=0A= >> -- Marie Curie (as quoted by Randall Munroe)=0A= > =0A= > =0A= From nobody Sun Nov 4 20:01:58 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAB3129C6B for ; Sun, 4 Nov 2018 20:01:56 -0800 (PST) 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 aXIRi2ICLcPO for ; Sun, 4 Nov 2018 20:01:54 -0800 (PST) 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 997D9128CF2 for ; Sun, 4 Nov 2018 20:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA541jYr027944 for ; Mon, 5 Nov 2018 05:01:50 +0100 (CET) Received: from [172.20.20.116] (110-170-235-6.static.asianet.co.th [110.170.235.6]) (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 42pJs45tvmz1Bqf; Mon, 5 Nov 2018 05:01:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 5 Nov 2018 11:01:41 +0700 X-Mao-Original-Outgoing-Id: 563083299.398182-01434a53cc24336088262824a1064a89 Content-Transfer-Encoding: quoted-printable Message-Id: <48447A2B-3BE7-4057-ABF5-F739971C039F@tzi.org> References: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] CoRE @ IETF103 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 04:01:57 -0000 I have uploaded an initial slide deck: = https://datatracker.ietf.org/meeting/103/materials/slides-103-core-consoli= dated-slides As you can see, we are missing quite a few slide sets; weekends, time = zones, medical emergencies, etc., seem to conspire. Please send in slides to fill any gaps=E2=80=A6 Where we don=E2=80=99t have slides at 13:00 ICT (UTC+0700), we=E2=80=99ll = skip the item on the agenda. Updated agenda will follow=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > On Oct 25, 2018, at 04:01, Carsten Bormann wrote: >=20 > The chairs have posted a preliminary agenda for the Bangkok IETF: >=20 > = https://datatracker.ietf.org/meeting/103/materials/agenda-103-core-00.html= >=20 > As you can see, the schedule is quite tight. >=20 > If you are on the agenda and want to stay there, please supply the = usual objectives. > Also, tell the chairs how much time you really need =E2=80=94 = reductions are welcome, but if you really need more time to make = progress, we need to know that, too. >=20 > If you are not on the agenda and want to get on there, the same = applies. >=20 > It would be good to have a first round of feedback (to = core-chairs@ietf.org) by COB Thursday. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Sun Nov 4 20:38:12 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9911298C5 for ; Sun, 4 Nov 2018 20:38:10 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ie36uSpp7eMx for ; Sun, 4 Nov 2018 20:38:08 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641CC128CF2 for ; Sun, 4 Nov 2018 20:38:08 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 1B95A3C48E; Mon, 5 Nov 2018 04:38:07 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2527:2528:2553:2559:2564:2682:2685:2693:2741:2827:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3622:3846:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4118:4250:4321:5007:6117:6119:6261:6298:6657:6659:6678:7860:7875:7903:8603:8985:9025:9177:10004:10400:10848:11232:11658:11783:11914:12043:12663:12740:12895:13071:13139:13149:13160:13161:13229:13230:13972:14093:14096:14180:14181:14347:14721:14819:21060:21063:21080:21433:21451:21625:21811:30029:30030:30034:30041:30054:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF X-HE-Tag: coat13_63eb750bb9845 X-Filterd-Recvd-Size: 7551 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf15.hostedemail.com (Postfix) with ESMTPA; Mon, 5 Nov 2018 04:38:06 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_0c1d29f98b43511672db49438f76d2df" Date: Mon, 05 Nov 2018 11:38:06 +0700 From: Peter van der Stok To: Carsten Bormann Cc: peter van der Stok , Andy Bierman , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <937F3F95-6B97-4773-BAC6-8BE6A3A903C3@tzi.org> References: <17342.1536697549@localhost> <622CDA79-7BE4-4A71-BFF7-0C80F63A1556@tzi.org> <50f58c78b6825ce1cdbc33ea852c3145@bbhmail.nl> <84F58F84-4637-4D65-8F86-8E86B346528F@tzi.org> <82ECE4AE-5284-42A4-B85D-7B5B413FD858@tzi.org> <1ee600960e00adc9926b87425a585d3d@bbhmail.nl> <937F3F95-6B97-4773-BAC6-8BE6A3A903C3@tzi.org> Message-ID: <67ddf8fa801586ca3452e331e93252c9@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [31.133.136.157] Archived-At: Subject: Re: [core] [Anima] documenting SID usage in IETF specification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 04:38:11 -0000 --=_0c1d29f98b43511672db49438f76d2df Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Carsten, My proposal for the handling of SIDs is the following: During the development of a YANG module described in an Internet draft, the allocation of SIDs is handled by the comi.space facility. A range is allocated to the module in the non-RFC range; during the development of the draft, the range can be changed and the allocation to individual YANG names can be changed. Once the draft is accepted to become RFC, the following actions should be taken: - The SID range for every module in the future RFC is allocated from the RFC range. (This means changing the SID values) - The contents of the SID files (one per module) are included in the RFC. - IANA registers the module names, RFC number, and the SID range allocations. - IANA registers the YANG name to SID map for every module in the RFC. we could ask IANA to provide an extension to YANG parameter registry https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml It contains presently a YANG module registry. (as specified in RFC6020, section 14.1) Suggestion to create next to yang module registry a sid module registry. Currently, IANA makes a version of the yang module available, so maintaining a sid file should be possible as well (IMO) Comments will be appreciated, Peter Carsten Bormann schreef op 2018-11-03 21:34: > On Nov 3, 2018, at 20:45, Peter van der Stok wrote: > >> Hi Carsten, >> >> there are two sides to your question: >> - How do we convince IANA to take the responsibility > > That depends a lot on the scale. There will be hundreds of modules, each potentially with hundreds of SIDs. > So we are creating a problem on the scale of IANA's biggest registry (Private Enterprise numbers, PENs). > I'm not sure that is realistic. > >> - How will they check the SID files: Like they check the content-format numbers and others > > The allocation is based on mega-ranges. What people do within their allocations should really be their business. > Only for the IETF range we may want to go into more detail, and that should be based on allocating ranges for the modules. > The only thing that needs to be checked is that all SIDs of a module are within the range allocated to the module, and that those allocations don't overlap. > > Grüße, Carsten --=_0c1d29f98b43511672db49438f76d2df Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Carsten,

My proposal for the handling of SIDs is the follo= wing:

During the development of a YANG module described in an In= ternet draft, the allocation of SIDs is handled by the comi.space facility= =2E
A range is allocated to the module in the non-RFC range; during t= he development of the draft, the range can be changed and the allocation to= individual YANG names can be changed.

Once the draft is accep= ted to become RFC, the following actions should be taken:
- The SID r= ange for every module in the future RFC is allocated from the RFC range. (T= his means changing the SID values)
- The contents of the SID files (o= ne per module) are included in the RFC.
- IANA registers the module n= ames, RFC number, and the SID range allocations.
- IANA registers the= YANG name to SID map for every module in the RFC.

we could ask= IANA to provide an extension to YANG parameter registry
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
It contains presently a YANG module registry. (as spe= cified in RFC6020, section 14.1)
Suggestion to create next to yang mo= dule registry a sid module registry.
Currently, IANA makes a version o= f the yang module available, so maintaining a sid file should be possible a= s well (IMO)

Comments will be appreciated,

Peter

Carsten Bormann schreef op 2018-11-03 21:34:

= On Nov 3, 2018, at 20:45, Peter van der Stok <stokcons@bbhmail.nl> wrote:

Hi Carsten,

there are two sides to = your question:
- How do we convince IANA to take the responsibility
That depends a lot on the scale.  There will be hundreds of mod= ules, each potentially with hundreds of SIDs.
So we are creating a pr= oblem on the scale of IANA's biggest registry (Private Enterprise numbers, = PENs).
I'm not sure that is realistic.

- How will they check the SID files: Like they check t= he content-format numbers and others

The allocation is based on mega-ranges.  What people do within = their allocations should really be their business.
Only for the IETF = range we may want to go into more detail, and that should be based on alloc= ating ranges for the modules.
The only thing that needs to be checked= is that all SIDs of a module are within the range allocated to the module,= and that those allocations don't overlap.

Grüße, Ca= rsten

--=_0c1d29f98b43511672db49438f76d2df-- From nobody Sun Nov 4 22:24:26 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5296D12F1A6 for ; Sun, 4 Nov 2018 22:24:24 -0800 (PST) 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 8aJ7Er3b25zD for ; Sun, 4 Nov 2018 22:24:21 -0800 (PST) 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 3790712EB11 for ; Sun, 4 Nov 2018 22:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA56OBsY015332; Mon, 5 Nov 2018 07:24:16 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:4059:1844:7999:a8a8] (unknown [IPv6:2001:67c:1232:144:4059:1844:7999:a8a8]) (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 42pN1M5tVnz1Bqf; Mon, 5 Nov 2018 07:24:07 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20181030174246.GA6420@nokia.com> Date: Mon, 5 Nov 2018 13:24:03 +0700 Cc: "hartke@projectcool.de" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 563091832.224184-f84eed4829b8d8a4a2b306d45a3385f2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181030174246.GA6420@nokia.com> To: "Fossati, Thomas (Nokia - GB/Cambridge)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 06:24:24 -0000 Here are my two cents=E2=80=A6 > On Oct 31, 2018, at 00:42, Fossati, Thomas (Nokia - GB/Cambridge) = wrote: >=20 > Hi Klaus, >=20 >> 1. " This memo defines application/multipart-core, an >> application-independent media-type" -- General purpose media-type? >> (Why does it have "core" in the name if it's general-purpose?) >=20 > It's got "core" because it specifies the use of CoAP content formats = for > constructing the aggregate, but that doesn't invalidate the general > purpose-ness, I think. Indeed. >> 1. "that can be used to combine representations of several different >> media types" -- Does it have to be several media types or is 2 media >> types enough? 1? 0? >=20 > s/several/two or more/ ? =E2=80=9CSeveral=E2=80=9D was not intended to exclude 2, 1, or 0. I see that the dictionary does this. (It can be 0 or 1 in the case introduced by draft-bormann-core-maybe.) >> 1. "into a single CoAP message-body with minimal framing overhead, >> each along with a CoAP Content-Format identifier." -- Can it only be >> used in a CoAP message-body? >=20 > s/CoAP message-body/message/ ? Well, this is a body, which might even be transmitted in block-wise = fashion, so it is not tied to messages. Maybe =E2=80=9CCoAP request or response body=E2=80=9D is the best way to = fit this. (There is no implication that it can=E2=80=99t also be used to brush = your teeth.) >> 1. "Applications using the application/multipart-core Content-Format >> define the internal structure of the application/multipart-core >> representation." -- Isn't the internal structure of the format = defined >> by figure 1? Or is this about assigning further meaning to positions >> in the array? >=20 > Yes, it's the fact that the exact position of a type inside the array = is > part of the structural definition - in fact, the position is the = unique > name of the field inside the aggregate type. I think Klaus wants us to point out that the application needs to stay = in the CDDL. >> 1. "For example, one way to structure the sub-types specific to an >> application/multipart-core container is to always include them at the >> same fixed position." -- Ah, I see. Join this paragraph with the >> previous one. >=20 > Makes sense. >=20 >> 1. "This specification allows to indicate that an optional part is = not >> present by substituting a null value for the representation of the >> part." -- Do we need this? >=20 > How do you suggest we deal with optional values? You could leave them out entirely, but then the application cannot = simply use a positional structure. >> 1. "Optionally, an application might use the general format defined >> here, but also register a new media type and an associated >> Content-Format identifier -- typically one in the range 10000-64999 = -- >> instead of using application/multipart-core." -- What's an example >> where an application would do this? I can't imagine any where I'd >> recommend this. >=20 > I don't see how that could harm (besides, if someone wants to do it, = we > cannot prevent it); that said I'm not opposed to removing text that is > not strictly necessary. It was meant as an encouragement to define application-specific media = types in a way that conforms with the structure of multipart-ct where = that makes sense. >=20 >> 1. "typically one in the range 10000-64999" -- Better not to state = the >> range explicitly as that locks the Content-Formats registry into >> providing this range for this purpose forever. >=20 > If we remove the above, this will go together with that. Right. We could explicitly say =E2=80=9CFirst Come First Served=E2=80=9D = instead. >> 2. -- There should be a sub-section or paragraph specifying what a >> recipient of a application/multipart-core representation should do if >> it encounters something that doesn't match the grammar. Does the = whole >> array become unusable when there is an unexpected element, or can a >> recipient use the array up to the unexpected element? Should a >> recipient try to do error recovery and skip to the next element? This >> has impact on how the format can be evolved in the future. >=20 > Isn=E2=80=99t that application specific? Please see draft-iab-protocol-maintenance >> 2. "(Future extensions might want to include additional alternative >> ways of specifying the media type of a representation in such a >> position.)" -- This side note feels a bit out of place and isn't >> really helpful. What should a reader of the document do with this >> information? >=20 > Yep, I agree this is out of scope and we should remove it. If we don=E2=80=99t want to do this, we should remove it. (I still believe we should do this, now.) >> 3. -- Is the "Observing Resources" example the prime usage example = for >> -multipart-ct? If not, shouldn't there be an example for the prime = use >> case? >=20 > I don't think there are prime use cases in a "hierarchical" sense. > Anything that fits is good to go :-) >=20 >> 3.1. -- I see that draft-ietf-core-coap-pubsub-05 is still proposing = a >> new response code (2.07) for this scenario. Will -pubsub switch to >> -multipart-ct as described in this section? If not, better remove the >> example. >=20 > This one is for Carsten, but I think the example in 3.1 is not > necessarily pubsub specific, though clearly it applies quite well to > pubsub. Let=E2=80=99s discuss this in the WG today. >> 3.2 "Implementation hints" -- This doesn't seem like a usage example. >> Promote it to a top-level section. >=20 > Agree >=20 >> 3.2 "In effect, the serialization for a single object is done by >> prefixing the object with information about its content-format (here: >> 0x82 0x00) and its length (here: 0x4b)." -- What about the array >> containing the two elements? >=20 > Sorry, I don=E2=80=99t understand this. Klaus points out that there is one more byte, something like 0x81. >> 4.1 "Fragment identifier considerations: N/A" -- Change to same as >> CBOR? Should we also copy the text: =E2=80=9C(At publication of this document, there is no fragment identification syntax defined for =E2=80=9Capplication/cbor=E2=80=9D.)" ? >>=20 >> 6.1 "[RFC7252]" -- Just to confirm: This is a normative reference >> because of the use of CoAP Content-Format numbers, right? >=20 > Yes >=20 >> 6.1 "[RFC7641]" -- This should be an informative reference, as = Observe >> seems to be referenced only in the usage examples section. >=20 > Agree >=20 > Thank you very much! Indeed! Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 5 00:03:46 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C205130E50; Mon, 5 Nov 2018 00:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yTdYo2xgrkS1; Mon, 5 Nov 2018 00:03:41 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5755130DD2; Mon, 5 Nov 2018 00:03:40 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 42pQDC0CnKz8tcV; Mon, 5 Nov 2018 09:03:39 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 42pQDB6Jf8z1xpN; Mon, 5 Nov 2018 09:03:38 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 09:03:38 +0100 From: To: Klaus Hartke , "core@ietf.org WG" , "draft-ietf-core-hop-limit@ietf.org" Thread-Topic: [core] draft-ietf-core-hop-limit-00 Thread-Index: AQHUdFQP5QIAzt/KB0qqQ5lsNmrhEqVA0DMA Date: Mon, 5 Nov 2018 08:03:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-hop-limit-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 08:03:45 -0000 Hi Klaus,=20 Thank you. FYI, we considered those comments when editing draft-ietf-core-h= op-limit-00. Early answers to these issues were made by Tiru at: https://mailarchive.iet= f.org/arch/msg/core/giPOExiFuWDJdNtRY52g3dMkXAM.=20 I do agree that (Allocating response code 5.06 for "Hop Limit Reached" is f= ine). We can suggest 5.06 when it comes to assigning TBA2 (during the IANA = review process).=20 Cheers, Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de Klaus Hartke > Envoy=E9=A0: dimanche 4 novembre 2018 16:35 > =C0=A0: core@ietf.org WG; draft-ietf-core-hop-limit@ietf.org > Objet=A0: [core] draft-ietf-core-hop-limit-00 >=20 > Hi authors of draft-ietf-core-hop-limit, >=20 > the draft was discussed a couple of times in the recent virtual > interims of CoRE, but I'm not sure if the conclusions ever made it the > mailing list. >=20 > We discussed the open questions from the August 29 virtual interim > [1], with the following conclusions: >=20 > > * Would it be useful to have a general-purpose content format for > > providing details of an alternate server, or is the information too > > DOTS-specific? >=20 > In general, a general-purpose content format would be nice, but for > now a DOTS-specific content format is fine. >=20 > > * Should a more specific media type than "application/cbor" be used? >=20 > Yes. (draft-ietf-dots-signal-channel now uses "application/dots+cbor".) >=20 > > * Is {elective, safe to forward, not part of the cache key} the right > choice? > > * Is {elective, safe to forward, part of the cache key} the better choi= ce? >=20 > The option should be elective, safe-to-forward, and part of the cache > key. If a cache understands the option, it should perform a > greater-than-or-equals comparison instead of just checking for > equality of the option value. >=20 > > * Is there a better number than 5.06? (HTTP 506 is: Variant Also > > Negotiates [RFC2295]) >=20 > Allocating response code 5.06 for "Hop Limit Reached" is fine, since > "Variant Also Negotiates" is unlikely to make it into CoAP. >=20 > Best regards, > Klaus >=20 > [1] https://www.ietf.org/mail-archive/web/core/current/msg09830.html >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Nov 5 02:00:18 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57F51277BB for ; Mon, 5 Nov 2018 02:00:16 -0800 (PST) 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] 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 qpPAmpn1LvU8 for ; Mon, 5 Nov 2018 02:00:14 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082EE130F0E for ; Mon, 5 Nov 2018 02:00:13 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id E0B9A41E9D for ; Mon, 5 Nov 2018 11:00:11 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 065AD10A for ; Mon, 5 Nov 2018 11:00:11 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::f08]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id ADE705B for ; Mon, 5 Nov 2018 11:00:10 +0100 (CET) Received: (nullmailer pid 25773 invoked by uid 1000); Mon, 05 Nov 2018 10:00:10 -0000 Date: Mon, 5 Nov 2018 11:00:10 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: <20181105100010.GA19849@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] Resource Directory: Usage of pre -17 groups and advanced 6690 features X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 10:00:17 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE group, I'd like to repeat the questions to the group from today's meeting to the list for confirmation of the planned course of the Resource Directory document: * Is there any active or deployed work that relies on groups as they described before -17, ie. that needs the RD to store which endpoints (actually: endpoint registrations) are members of the group? * Are there active users of RFC6690 features that go beyond what is described in the examples? In particular, do you use any of * References are relative but do not start with a slash? * Relative references in the target, and full URIs in the anchor? * Links where the precise link context ("the anchor") is relevant even though the anchor attribute is not given? If so, please let me know during this week. The room gave two "no"s, based on which RD should be able to progress to a WGLC document swiftly. Thanks Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvgFKYACgkQOY0REtOk veGxGRAAgLwDahB7HkSZ9ziGGcNF0aylbWrpmXNND11q/O/uKjAhPuV2eTY0XGMF EQC6B7MToSe1djRGp81KHsDGpRfOHfhKgt348eYrMlT8Ey1glIrmYeuKOBQyNoNe KKWEbFhngsgDkjJbWWt9guLsqGZPNP5AjutsMclTz1JkRyzQTU0GbJZSaW7/Ppex xP9GV6jNqV89IBnPnGcGCbQsRZewPvtKzTSSoVAV3xrNesVlt555M3q3y3qeIkr6 8JjkUlIuFSWRyR9AS1DST3rxY3fY/Ttd7BxKzNc6sDl6PkgCFPDYjDSkUuTqL/6p z4XYpjvqRmz2LlA/GpKUe6eX+/LzuFKQhZXxbfRX/U/EDrx3C5OBXr9YWQZ1ox8G 6osnFR8jX1MWNhIe5dMOaSc+s6zvyduIC+5RnUGd+sQA52Rnlybe5YQwNLc9GQac KOr+93cjfvq/E1GubRNThelnm843zucoB1oszvxA9Nr4zOM4RVOHejPjIZK/IXPb ISyqocU3QWw/tDVvGjmQWA/YwivVH1c3qMWUH+Dy0JAC95NZzyJ+JgHCOMm34zP1 h1V5q/TlHNoCzP/wfo7Vu6Byvh6UlOBcmCE0kIZ59xxhl4JwqnjLpG6Z9pWfxO8z 4sGneIj1Yy0Yl+7gkD5Rxn7zikHgvXoWcPMM06DmB01kmRUdiZM= =rVmG -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From nobody Mon Nov 5 03:26:58 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26742128DFD for ; Mon, 5 Nov 2018 03:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=TxXU8DF7; dkim=pass (1024-bit key) header.d=ericsson.com header.b=MKTaHYe3 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 7r4GhYbIDy4A for ; Mon, 5 Nov 2018 03:26:55 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 E7134127133 for ; Mon, 5 Nov 2018 03:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541417212; x=1544009212; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gyq2bsEpFRpGJUBBWWkrGJ0Oajs7S4DdCUgQCXyAudI=; b=TxXU8DF7u0RAleBUkpjmKjM7h5sHquHVHKFG8Kh1nJfb7iCIN6V/QTD3DN7qNSYL SJyEXyStfGVQoooMS05ZRkXA8cpf5Hf/ce5u4Fg352SyPEDMIZ4cxxWVkxicXc4i 59pSKYOc8D4/qy0GH7wjRZ5pwKlskqR4dqYEkci2SAk=; X-AuditID: c1b4fb3a-9dbff700000063b1-e0-5be028fcc7bd Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.8B.25521.CF820EB5; Mon, 5 Nov 2018 12:26:52 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 5 Nov 2018 12:26:52 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 5 Nov 2018 12:26:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gyq2bsEpFRpGJUBBWWkrGJ0Oajs7S4DdCUgQCXyAudI=; b=MKTaHYe3Xm8d/ZPs7iQzyrhwTZWOE1u/0sXqcrRkdRJim8g0HV/he+K0vRCLPJJQIbFBYt18ScJ4YkkW/aEkQn5z9948goziCJjFX72DlKdkS95U/L9fZ7N4mTBb9WR/33AQvxd7DND6E6dZ17BvXO9D1R4SLLbkSMSi3QEjZ0I= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB3340.eurprd07.prod.outlook.com (10.170.247.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.12; Mon, 5 Nov 2018 11:26:51 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95%3]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 11:26:51 +0000 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: Final fixes to draft-ietf-core-too-many-reqs Thread-Index: AQHUdPpy7YlmgZ9fy0yzWXjAVfyDMw== Date: Mon, 5 Nov 2018 11:26:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3340; 6:8YYSqIwG2fZONPxm2lHuSRTQbOEbaEEmoe+etCFgHHaQ2SbjN99yh1Pp2yh8PmLN7a49lJsnF/bS0U9+wuSrLUyNCJgc4bOKLg7l9Ey1U97dlZv59hl2+ZA5/MNnMfQeZAvQodQgi0tKWN1kOhn6yi4TpGktKixtQJ2P96B9PFr1z2bH2f6hRXlvTFS+cpAzYvYVgJzkrI/23jEZg/yRyM0eQhDOw7RyKO12hYQ8D0T06NpUwbnPvM0/EkPEqrmOLL6xk+WTVe2aT7Xj0UbUc1c+iwAZecItk/pQoKni4jmnHWHkU4cdztIjwViahjl3jYUMMkQBV5VXI78i1ciui+IqPthLSMUK7F6XWa9y4KNsWiYhEiS0D0vNDXa3FLVaHvlImmRMkCJWWKuua3snPVusLCyQYqVPP9MxWxzdOxpNd9WlIOB4kx9qWZJd3DP1eEILlYv/V6ptPDfOpHHK0g==; 5:GkQHBr4hd/rHSMGo4ov1L9hsnh3mcG+DkwbykyKnaZjTkQxDHb3TgYg96Ny1WD5w0k2XKFPhfJNfQsQMkXZF998/jkyPQDx+Hi6aMtUFNVmmIRHluxlCsIA9Iengsro0qcmv9j/Hax3/np8vKhG8z8+/WWmRqeoFib6cZ4Q1xq4=; 7:xuOHR6X5sVhk48p8QO3rCOLNcWMnbabXl1Z2s5UJO9v/qPDIH3egDsrwknU4t0xf8LEQvO3lUoCx+lr72PyJwAGlxuqaCa6bW/LF+v/iV0miRGwqE94bN6JP1Jbk4oCeCE3zBpL0E0HKntefo+SCjA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f3176bc5-dcd5-4302-ce30-08d643119532 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3340; x-ms-traffictypediagnostic: HE1PR07MB3340: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3340; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3340; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(366004)(346002)(396003)(376002)(189003)(199004)(53754006)(966005)(7736002)(305945005)(86362001)(106356001)(105586002)(478600001)(71200400001)(2906002)(256004)(3846002)(97736004)(6116002)(71190400001)(7696005)(99286004)(6436002)(9686003)(6306002)(53936002)(2900100001)(55016002)(5660300001)(14454004)(6916009)(74316002)(8936002)(8676002)(81166006)(81156014)(33656002)(486006)(68736007)(66066001)(6506007)(476003)(26005)(25786009)(186003)(102836004)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3340; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: QVFvudEjCuUdLZ9++0ZpPqI4NlT/iL6MYGEVHIzRDjV5XQWAxC6BqxPvNoIFnGjLKol/B5/l6ZvMr7jOB96l+Z/D/AxyHHtACmgbqsqhkt2oVwyLaJiGNBk55X2WBz+QaBggC64P32LMREpca7/sJnCDtPJJVAlFIcYSRaLoH2HJ/OrSPFGcRtmpFZNKQb4lSiM6KQaNW0E3oP5jWoyZtpE0jvWFKV3jagsKQjTCpKdbZY/zXHyqdiAiCQbaiXhk6VgQK0lLaxyDzzHzDpJ3F6P6FTXkKrlM6cf2gqAq9izwOIhfxTdukhiLaRtuGB4Uu5Vve6I83CudAd40B3VY2VWqNpORywiOyALlGn3V75Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f3176bc5-dcd5-4302-ce30-08d643119532 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 11:26:51.4912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3340 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUyM2J7ue4fjQfRBlt2GVvse7ue2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGSd+OhXsYa2Y0NvO2MC4j6WLkZNDQsBE4tWqGaxdjFwcQgJH GCU+vf8C5XxllFh5ZyMzhLOYSWLK/CtMIA6LwARmiffTFrFAZCYzSdz83sQOMkxI4CGjxL9+ cRCbTcBeYvKaj4wgtoiAhETn1/1gNcICphIHd+1hgYhbSdxecxdoHweQrSfRd0UDJMwioCKx anI3E4jNKxAjcevkc1YQm1FATOL7qTVgcWYBcYlbT+YzQfwgILFkz3lmCFtU4uXjf6wQtqLE 2XcPoWpkJS7N72YEuVlC4BqbxK0zx6CKdCU+TJ0K1ewrcXD5LmaIouOMEneXH4fq1pK4s/of O8QV0RKvTp1kh4hnS0yasBaqxkdiy/bbUEPlJFb1PmSBGsQssfnYdWhwy0jseL4ayp7OKvF0 vtoERr1ZSD6CsPUkbkydwgZha0ssW/iaeRY4NAQlTs58wrKAkWUVo2hxanFxbrqRkV5qUWZy cXF+nl5easkmRmCSOLjlt9UOxoPPHQ8xCnAwKvHwags/iBZiTSwrrsw9xCjBwawkwqvEBhTi TUmsrEotyo8vKs1JLT7EKM3BoiTO65RmESUkkJ5YkpqdmlqQWgSTZeLglGpgXJzxZydvwMPY bduy3kYn9is6BMZ90lrnsTDXQCpHYt9V+QLGHa/1l9nIJtj5M7M/FTK4bWA16+a9SXz5ruLL Uu4HuMg/Xe7ULXNX69zhoEeHbzLN/rmu5SnbgTmXPs+fuuroho3V7m7zkp/ulN3V+E1PaatM N+vEc4u2mb5d/z619+bUwMdFmkosxRmJhlrMRcWJANkIsUQOAwAA Archived-At: Subject: [core] Final fixes to draft-ietf-core-too-many-reqs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 11:26:57 -0000 Hi all,=0A= =0A= As discussed in the CoRE WG meeting today, here's a PR for the final =0A= changes before finishing IESG review:=0A= https://github.com/core-wg/too-many-reqs/pull/6/files=0A= =0A= In summary:=0A= * Adding this document as additional IANA reference for Max-Age=0A= * Changed rate-limiting from "e.g., once per RTT" to "usual load =0A= shedding policy"=0A= * Changed to non-normative recommendation for not relying on server =0A= sending this code=0A= =0A= Comments & reviews on the text are very welcome!=0A= =0A= This PR will be applied in addition to the PR 5 to make a new version =0A= and the plan is to submit that tomorrow.=0A= =0A= =0A= Cheers,=0A= Ari=0A= From nobody Mon Nov 5 03:58:02 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A429F1277CC; Mon, 5 Nov 2018 03:57:52 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SxDTN8MOiGP; Mon, 5 Nov 2018 03:57:50 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 864E5128CFD; Mon, 5 Nov 2018 03:57:50 -0800 (PST) Received: from mail-qk1-f178.google.com ([209.85.222.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJdVs-0000gJ-5n; Mon, 05 Nov 2018 12:57:48 +0100 Received: by mail-qk1-f178.google.com with SMTP id a132so14154007qkg.1; Mon, 05 Nov 2018 03:57:48 -0800 (PST) X-Gm-Message-State: AGRZ1gKUOOb54Hxe58dmEJT7yaVjiHpKuMtGvF6OVWSdL0baMNc8kG7Z OMCc0ng9b9HRaTrhZ7bnad07ELdVqSgUJOOgoxI= X-Google-Smtp-Source: AJdET5emxf9kl9+Yd6KiF/OkM9UeMrdxKfRM6rIhT/mJF4EE09ZVQdyoeUoWCUYXv50FTvV2yn14msgV90CSh9s7/ZI= X-Received: by 2002:a37:324a:: with SMTP id y71mr6570038qky.291.1541419067000; Mon, 05 Nov 2018 03:57:47 -0800 (PST) MIME-Version: 1.0 From: Klaus Hartke Date: Mon, 5 Nov 2018 12:57:10 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: T2TRG@irtf.org, draft-hartke-t2trg-coral@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541419070; 7e5886f4; X-HE-SMSGID: 1gJdVs-0000gJ-5n Archived-At: Subject: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 11:57:53 -0000 On Wed, 31 Oct 2018 at 17:45, Christian Ams=C3=BCss = wrote: > * attrs: title and title* are described as target attributes in RFC8288 > and can thus easily occur in CoRAL documents. Good catch! For some reason I was convinced that "title" and "title*" would describe the link itself, not the link target. I've changed the text in my working copy accordingly. > * ibd: Then, it can say something like "MUST NOT occur in a CoRAL > document as attributes, but are expressed as link relations, nested > links and link relations, respectively" to indicate that their > information is not lost in the transition. This is true for "rel" and "anchor", but not for potential new attributes defined in the future. I don't think CoRAL should try to accommodate those, so I'd just forbid all of them (without giving a mapping to CoRAL) as it is now. > * What to do with language-tagged attributes (like title*)? The takeaway > from links-json is that they can be decoded easily but need to keep > their language information. That's easily expressed in RDF (turtle: > `<> :title "=C3=9Cberschrift"@de`). links-json went for > `{"title":{"de":"=C3=9Cberschrift"}}`, which seems a bit crude to me bu= t > could work just as well for CoRAL, as could a tagged CBOR array or a > plain array if we stared using arrays with discriminators that are not > part of the IRI discriminators as something different than IRIs (a la > `[/link/ 2, /attr:title/ 42, [/language-tagged/ -1, "de", > "=C3=9Cberschrift"]]`). Since in CoRAL it's possible to make statements about link targets (here: the literal "=C3=9Cberschrift"), something like this would look natural to me: #using iana =3D #using attr =3D iana:terms-of-service { attr:title "Nutzungsbedingungen" { attr:hreflang "de" } attr:title "Terms of use" { attr:hreflang "en" } } <=3D> ; rel=3Dterms-of-service; title*=3DUTF-8'de'Nutzungsbedingungen; title*=3DUTF-8'en'Terms%20of%20use Another, related question is how to express link target attributes containing multiple, white-space separated values. Currently, the mapping of link target attributes to CoRAL links is pretty unsophisticated: All attribute values simply become a text string. So, multiple, white-space separated values are still white-space separated, and numeric values (as for the content-format, "ct", or representation size, "sz") are expressed as decimal string representations. The reason for this is that it enables "round-tripping" for potential new attributes defined in the future. If there's a guarantee that there won't be any new link target attributes in the future (for RFC 6690 link serializations), then we could skip the whole mapping topic and just define a new, more natural set of link relation types: #using rdf =3D #using iana =3D #using meta =3D iana:hosts { meta:content-format 110 rdf:type rdf:type meta:size 1234 } <=3D> #using iana =3D #using attr =3D iana:hosts { attr:ct "110" attr:rt "example.temperature-sensor example.sensor" attr:sz "1234" } Speaking of the IANA-registered "type" link relation and the RDF "a" predic= ate: > * FoaF example: Just for my understanding, would anything be wrong with > some application using > as the rel to foaf:Person here? (I figure that few RDF applications > treat rdf:type and iana:type as equivalent properties). > > Later that's clarified a bit in A.1 where it says "same purpose", but > is rel:type in actual use anywhere? Otherwise, I suggest to go for > rdf:type right away, as that is in use. (It's more verbose when > expressed in non-CoRAL link formats, though.) Good point. My assumption was that translators to RDF would convert every iana:type to an rdf:type, but using rdf:type directly makes a lot of sense. I've changed the text in my working copy accordingly. Klaus From nobody Mon Nov 5 04:01:20 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED00128CFD for ; Mon, 5 Nov 2018 04:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwsqD92neEAj for ; Mon, 5 Nov 2018 04:01:17 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEEA1277CC for ; Mon, 5 Nov 2018 04:01:16 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B000A41E9D; Mon, 5 Nov 2018 13:01:14 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1A80410A; Mon, 5 Nov 2018 13:01:11 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A357B5B; Mon, 5 Nov 2018 13:01:10 +0100 (CET) Received: (nullmailer pid 9079 invoked by uid 1000); Mon, 05 Nov 2018 12:01:10 -0000 Date: Mon, 5 Nov 2018 13:01:10 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Klaus Hartke Cc: "core@ietf.org WG" Message-ID: <20181105120109.GC12165@hephaistos.amsuess.com> References: <20181031164534.GA4995@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sHrvAb52M6C8blB9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] [T2TRG] Review of CoRAL X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 12:01:19 -0000 --sHrvAb52M6C8blB9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Klaus, (recipients reduced as CoRE indicated interest in adoption) On Sun, Nov 04, 2018 at 03:56:28PM +0100, Klaus Hartke wrote: > > * How are compressed URIs expressed in CBOR? Flat [6, "foo", 6, "bar"] > > or nested [[6, "foo"], [6, "bar"]]? >=20 > should be flat: [6, "foo", 6, "bar"]. Very well (saves ~10% message size in the 6690 example), now fixed in micrurus. > If it improves clarity, the Python code could be updated to operate > on flat lists instead. The grouper version is probably more concise than the note that "the Python code expects base and href not to be input in the trivial deserialization of a CBOR array, but as a list of (option number, option value) pairs" that should otherwise be there. > body.py: > > if ':' in i.relation: > > rel =3D i.relation > > else: > > rel =3D 'http://www.iana.org/assignments/relation/' = + i.relation >=20 > When a relation is provided as a string, the intention is that the > string always contains the IRI. I don't think the current set of > IANA-registered link relation types is relevant enough in the context > of IoT that it should get special treatment. Indeed. I don't know where the mistake came from -- my mental model after my current reading of the document was yours, just my the code and example from March did not match it. > body.py: > > elif isinstance(i, BaseDirective): > > base =3D base / i.iri >=20 > The draft currently specifies that a base IRI is resolved against the > current context IRI, not the previous base IRI. Thanks; likewise, I missed updating the current relation number. Both being fixed. > > * Is there a difference between a CoRAL registry and a CoRAL profile? > > Both terms are used. >=20 > The draft uses the "profile" media type parameter defined in > to indicate the CoAL registry, > which I think makes more sense to define a new "registry" parameter > with essentially the same semantics. So "profile" should appear only > as the parameter name. I've replaced all instances where "profile" > appeared without this meaning with "registry". Having read up on them, a "profile" has a no-changes-to-interpretation condition: A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation Given that a client without knowledge of the profile can't process a representation, the parameter should probably be called something else. > In general, I think URNs would make more sense for identifiers than > HTTP URIs, as the latter always look like they could be successfully > dereferenced. But it seems that HTTP URIs are more popular in the > Semantic Web... It's a matter of style; my take: Devices that dereference URIs on a whim will cause trouble in some form anyway, better let that show on expected input and not only when under attack. And as a developer, I'd rather have a link to follow than know where to look up values in subregistries. Thanks Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --sHrvAb52M6C8blB9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvgMQEACgkQOY0REtOk veHmthAAxF28SOJqHg/0ehomI6kwROz8fso1zSgnmQeQ/gq4tHVJXckPsLjzxugm Z9QvEjzjFqzxHN8iyGbsnFXODNl8MFpE4njwFqXGSxAlDWAdOsWsvm34XowYg59x azxrNfHCGwm40P7KlJfdvth8G7YCcZaWIX/pNMoeVkKXhgLXZmBGLCxJewEyBTX4 XpY5EDbuuSWvZDiDXFL9HDW0K4B13VeBZalywtT4zrTgAcCODbtyh2ZB7mYPGrww Ksuu6oYLDRPRWcNX36gyVbUUn5MlimPhXNznoIk7SllATCgad5hcgUiC4XkaHZBO o4YSTZSTYR8M58vn6N9FlTFURrNMgKXES5d6Uu3vIBpc2DiQwnrk9jDEEJUTjkTi +QVnhCQWjEgathxURJXciG85SKnT4uGIjHy4tEhq63HozDAz+BGhIrqXPmG5b0Tk TBVa6yrz1Zkm1BZRPk+dUPS7gaN5W2yTmbNx0RazK1jwHfVtiIXzirSdP4Ye652/ DG4ISyFaRdoM6FQFrxI78E1jk9Nc0HhsLHVx/WMaA/tI1PmSsfoh+BXQxlaH90Aj G+5vrLJSqDfMy6kZ096fvJrgi6vT2EldFxwO92w2MvQvOwp+GLO5GGxdLSt+wnkQ gzOl3H73FWwkyqWVIPWDhoCEyKrtPTuHlahmAgcfCFLz03Il8og= =Wik+ -----END PGP SIGNATURE----- --sHrvAb52M6C8blB9-- From nobody Mon Nov 5 04:36:13 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31C5128CFD for ; Mon, 5 Nov 2018 04:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_EujvcvKjCj for ; Mon, 5 Nov 2018 04:36:09 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D191298C5 for ; Mon, 5 Nov 2018 04:36:08 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0A50241E9D; Mon, 5 Nov 2018 13:36:07 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7A2C810A; Mon, 5 Nov 2018 13:36:05 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2E21B5B; Mon, 5 Nov 2018 13:36:05 +0100 (CET) Received: (nullmailer pid 13712 invoked by uid 1000); Mon, 05 Nov 2018 12:36:04 -0000 Date: Mon, 5 Nov 2018 13:36:04 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Klaus Hartke Cc: "core@ietf.org WG" Message-ID: <20181105123604.GA9680@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 12:36:12 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Nov 05, 2018 at 12:57:10PM +0100, Klaus Hartke wrote: > > * ibd: Then, it can say something like "MUST NOT occur in a CoRAL > > document as attributes, but are expressed as link relations, nested > > links and link relations, respectively" to indicate that their > > information is not lost in the transition. >=20 > This is true for "rel" and "anchor", but not for potential new > attributes defined in the future. I don't think CoRAL should try to > accommodate those, so I'd just forbid all of them (without giving a > mapping to CoRAL) as it is now. Non-target link attributes are something I'd discourage in general; would you, when someone does define new non-target attributes, encourage them to specify how they'd be expressed in CoRAL? (RDF would typically do some form of reificiation there, or provide an intermediate anonymous node). > Since in CoRAL it's possible to make statements about link targets > (here: the literal "=DCberschrift"), something like this would look > natural to me: >=20 > #using iana =3D > #using attr =3D >=20 > iana:terms-of-service { > attr:title "Nutzungsbedingungen" { attr:hreflang "de" } > attr:title "Terms of use" { attr:hreflang "en" } > } >=20 > <=3D> >=20 > ; rel=3Dterms-of-service; > title*=3DUTF-8'de'Nutzungsbedingungen; > title*=3DUTF-8'en'Terms%20of%20use That's kind of neat and kind of scary. The scary comes from the implications of hosts { attr:title "Gift" { attr:hreflang "en" } attr:title "Geschenk" { attr:hreflang "de" } } hosts { attr:title "Poison" { attr:hreflang "en" } attr:title "Gift" { attr:hreflang "de" } } which may be read to imply that there is a string "Gift" that is both English and German and describes both resources. I think it can still work b/c none of that would survive a na=EFve round-trip to RDF, and a converter would need to make attr:title "Gift"@en, "Geschenk"@de . attr:title "Poison"@en, "Gift"@de . out of it because RDF statements can't have literals in their subject, but that issue would need to be well-understood, and literals would need to be described along the lines of "Two literals are only interchangable if they have the same literal value *and* all their properties are identical", where it is not possible to give a literal properties outside of where it is defined (for that would create a different literal). > Another, related question is how to express link target attributes > containing multiple, white-space separated values. Yes; I have a similar proposal for that in micrurus[1], but it does not go as far as converting to URIs or numerics yet. [1]: https://gitlab.com/chrysn/micrurus/blob/master/README.rst#special-prov= isions-for-link-format-conversions > If there's a guarantee that there won't be any new link target > attributes in the future (for RFC 6690 link serializations), then we > could skip the whole mapping topic and just define a new, more natural > set of link relation types: I don't think we need a guarantee for that. We can, as they pop up, for some funny-string-valued attributes define equivalent more semantic attributes, each with their own mapping. So a general CoRAL processor you could encounter both `attr: rt=3D"x y"` or `split-attr:rt rt:x, split-attr rt:y` and needs to know of the equivalence. A profile like links-CoRAL could then say that types need to be expressed using the split attributes. I would, in general, discourage defining new white-space-separated attributes, and in particular I already do so in RD, for the RD would need to know that an attribute is such a one for usable lookup. As for the prefix, attr:rt, attr:if and attr:ct have registries, so we could treat non-URI bare values in analogy to link relation types. (Those produce currently uncompressible URIs, leading to profile-defined URIs in what will be another thread). Best regards Chrisian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvgOTEACgkQOY0REtOk veE7DA/+JTOLL87S1EC0n+p3cF5Slaetd/qjZKTkcRmxyJ6qToUPfGvMzW7gYP7Q dIOpAnYr9FrAW12sx76krGO59Fu5vCHljFFEQEXlrTqNut4P33lPlsvXh03OD9dO rPAn51+mBVYLZwlrW0vVdH6+XqMiXEI5NQjB4OFKaccRicwBCBMLP3qda9wZGlgq sMNEVlFTGfNKLCR31jWzeXE0QeIwvsssIp0WTOxGDHGjDW4pIAjNHcumkAxYAxMz YJ+EGk/nPR3No4qduZtqu7mbrPWp4HeEhgWsfLtZpqUUTL01XqXnRU5TebbjJq6K IPbwgVw4BCRlGe32wbBi0yfZN0r4qauoracOEVHOLXmYMjGUfZ7kijGJR0CCIZUU /o2FyLxN+xE8UHPUNIa8Ce+5n/66jY8tqnBDSOcwb59bOAFYRuTwaG8uPgWXQUoM uFCgx4sr/iDa4LZw2GcxxwBM8fsrkvD/jRlZBh9ct5so7PQzCIri9GGlS8Bxngfd ZqGujCTxuY7WCWDZxov8TuSk5Kq+M2XqyFoRlteB2Rj62dWWLswyMBBO+Kv78D8s GynErcBga+uujV1u9wnZUglaz3QslvpGqkG8HmuIuK3DW3eKmJH1df4skhbJIjLY xkxMb6tlvIqAqAUIp5SvGKAd9mXr4GXKMXtXK1bCQyfxjNywp94= =3fuz -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From nobody Mon Nov 5 06:03:49 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D83128CFD for ; Mon, 5 Nov 2018 06:03:47 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhlMzpaP8EKm for ; Mon, 5 Nov 2018 06:03:45 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 5173212426A for ; Mon, 5 Nov 2018 06:03:45 -0800 (PST) Received: from mail-qk1-f172.google.com ([209.85.222.172]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJfTh-00054V-VC; Mon, 05 Nov 2018 15:03:42 +0100 Received: by mail-qk1-f172.google.com with SMTP id q1so14708515qkf.13 for ; Mon, 05 Nov 2018 06:03:41 -0800 (PST) X-Gm-Message-State: AGRZ1gJYqNV70NF08yML1x0gcOqM/0Grs7UDLXkRHMX6Ref0y5Ca+zl/ jlrMHqCp8rff7KBYUq4T9oDda2gRdP6PMvy73xo= X-Google-Smtp-Source: AJdET5fvsqxysF5DWuHlZttQ/3l0cdf/MOuob9ld/+a5YYjcLRvujwEEamO50TvFcwMOuTFFjkWU8xL3E4QRYedulcM= X-Received: by 2002:a0c:8003:: with SMTP id 3mr21917257qva.129.1541426620994; Mon, 05 Nov 2018 06:03:40 -0800 (PST) MIME-Version: 1.0 References: <20181031065938.GA6605@hephaistos.amsuess.com> In-Reply-To: <20181031065938.GA6605@hephaistos.amsuess.com> From: Klaus Hartke Date: Mon, 5 Nov 2018 15:03:09 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541426625; fade1371; X-HE-SMSGID: 1gJfTh-00054V-VC Archived-At: Subject: Re: [core] Links, hosts, and resource directories X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 14:03:48 -0000 Christian Ams=C3=BCss wrote: > > ;rt=3Da,;rt=3Db,;rt=3Da > > > > This means, there are three links [6]: > > > > hosts > > which has type "a" . > > Actually it is ` hosts ...` due to the wording of > RFC6690 Section 2.1 b). Good point! For some reason, I was convinced that only the "hosts" relation type would do weird things to the link context. I missed that RFC 6690 defines the anchor for *all* links without an anchor attribute to be the root resource of the origin. So, for example, the links in this Link Format representation of ... ;rel=3Dhosts,;rel=3Dicon ...are resolved to... hosts . icon . ...which, to me, have the following meaning: (coap, example.org, 5683) has a resource . The shortcut icon for - but not immediately any other resource hosted by (coap, example.org, 5683) - is . RFC 6690 is really interesting. > I'm not sure that this interpretation of 'hosts' necessarily follows > from the definition ("hosted by the server indicated by the link > context"). Isn't that exactly what "hosted by the server indicated by the link context" means? See also the text in : Thus, the links in this example tell that the Origin server from which /.well-known/core was requested (the context) hosts the resources /sensors/temp and /sensors/light (each a target). It's probably not worth discussing the exact semantics, though, as those have little relevance in practice. Klaus From nobody Mon Nov 5 06:09:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3241298C5 for ; Mon, 5 Nov 2018 06:09:29 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X05NfT2Wzkio for ; Mon, 5 Nov 2018 06:09:27 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 C694B12426A for ; Mon, 5 Nov 2018 06:09:27 -0800 (PST) Received: from mail-qk1-f175.google.com ([209.85.222.175]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJfZG-00016J-8v; Mon, 05 Nov 2018 15:09:26 +0100 Received: by mail-qk1-f175.google.com with SMTP id o89so14875177qko.0 for ; Mon, 05 Nov 2018 06:09:26 -0800 (PST) X-Gm-Message-State: AGRZ1gI1qD/194QU4MDtdc06Wk3tbIhiKprh3BHjdIcUM8AKJOkGJWSD XCMvqxKp5IgSz1joVsQrqIgMKCuc3+X84PVPIrs= X-Google-Smtp-Source: AJdET5funBANBgK0tE8LHE54lbXHDDishDcHd9d4NczBQY51DRlVGfE3IheqdwTfkKmt8/SE+YkVlsNIfR3rPlzAs6I= X-Received: by 2002:aed:26a3:: with SMTP id q32mr9411482qtd.106.1541426965320; Mon, 05 Nov 2018 06:09:25 -0800 (PST) MIME-Version: 1.0 References: <20181031065938.GA6605@hephaistos.amsuess.com> <360fce5cf526718475f9d1fffa66ca4c@bbhmail.nl> <214E0D57-75FA-4631-B94C-3F0A1B167A01@gmail.com> In-Reply-To: <214E0D57-75FA-4631-B94C-3F0A1B167A01@gmail.com> From: Klaus Hartke Date: Mon, 5 Nov 2018 15:08:53 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Michael Koster Cc: peter van der Stok , =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541426967; 3eefd6f5; X-HE-SMSGID: 1gJfZG-00016J-8v Archived-At: Subject: Re: [core] Links, hosts, and resource directories X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 14:09:29 -0000 Michael Koster wrote: > It is a common mis-perception that resource representations > can be obtained from a Resource Directory. Feel free to point people who want to obtain resource representations from a Resource Directory to Data Hubs [1] :-) But, yes, maybe a disclaimer could be added to the introduction of the RD draft, saying that an RD doesn't store resource representations. Klaus [1] https://tools.ietf.org/html/draft-hartke-t2trg-data-hub-02 From nobody Mon Nov 5 07:54:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D168130DE5 for ; Mon, 5 Nov 2018 07:54:12 -0800 (PST) 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 OpnYRxYAUMA3 for ; Mon, 5 Nov 2018 07:54:09 -0800 (PST) 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 939C6130DF2 for ; Mon, 5 Nov 2018 07:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA5Fs0Ak000192; Mon, 5 Nov 2018 16:54:05 +0100 (CET) Received: from [172.20.20.116] (110-170-235-6.static.asianet.co.th [110.170.235.6]) (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 42pcft5vKzz1Bqk; Mon, 5 Nov 2018 16:53:58 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 5 Nov 2018 22:53:55 +0700 Cc: Michael Koster , =?utf-8?Q?Christian_Ams=C3=BCss?= , "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 563126034.316807-cf9d588ded7111c071c84fdb81942113 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181031065938.GA6605@hephaistos.amsuess.com> <360fce5cf526718475f9d1fffa66ca4c@bbhmail.nl> <214E0D57-75FA-4631-B94C-3F0A1B167A01@gmail.com> To: Klaus Hartke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Links, hosts, and resource directories X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 15:54:12 -0000 On Nov 5, 2018, at 21:08, Klaus Hartke wrote: >=20 > But, yes, maybe a disclaimer could be added to the introduction of the > RD draft, saying that an RD doesn't store resource representations. +1 (And +1 on the data hub, too.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 5 19:21:01 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EF31276D0 for ; Mon, 5 Nov 2018 19:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (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 1BmfFIj3v4Ny for ; Mon, 5 Nov 2018 19:20:57 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10101.outbound.protection.outlook.com [40.107.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FC4127148 for ; Mon, 5 Nov 2018 19:20:56 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=acFfy8QU8Ced8HBTTgjp24WWI1LO/wcy9+T24RSY4UI=; b=mZuSqfPNfwiZEgL2ZaCaq48yTeWfP8kK7E6JwkRnmNBbkq1nB/QxGqXBDdNqhFAlnAugXsHp6/SRS/TlsQnW7C5uwKaNH5CSo7JUp9iQBR38GmHGX7w1H5Zhg3isggND++qF08ksrXBqjqY8NMeg0yYxORjc028bdKnC+aviKXQ= Received: from AM6PR07MB4930.eurprd07.prod.outlook.com (20.177.119.75) by AM6PR07MB5397.eurprd07.prod.outlook.com (20.178.88.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.30; Tue, 6 Nov 2018 03:20:53 +0000 Received: from AM6PR07MB4930.eurprd07.prod.outlook.com ([fe80::f95b:cf9a:b466:21d3]) by AM6PR07MB4930.eurprd07.prod.outlook.com ([fe80::f95b:cf9a:b466:21d3%3]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 03:20:53 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Carsten Bormann CC: "hartke@projectcool.de" , "core@ietf.org" Thread-Topic: [core] Review of draft-ietf-core-multipart-ct-02 Thread-Index: AQHUcHf46zhgh8nfgU+ep4XF1bdRj6VAv1qAgAFeRu0= Date: Tue, 6 Nov 2018 03:20:53 +0000 Message-ID: References: <20181030174246.GA6420@nokia.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [2001:67c:370:128:3203:16ce:64f4:5b37] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB5397; 6:/aGb/UYERJ0/u8ClJPoAodfL2aQe5K/QG3O1XCwqochBA1xk9ndmf+COb5VwR1T7spOM4OMwUcuJ3tlShOrX1dwQcubcqlWBwQJPJ/U1cQhXL5vA7nWdisYOGkRfxJJ5vLCdiZ7OHkIAqmpMRwpgcOPM7KFRFRErAP4vzAArAuZvCwFUFaei6jRsrTcsUl2L+wr6Ka8x+d6zfsRdGSePYlwU2MbaOo8EpQPc1XFuG3+VJY35d6avgWSSvyrkLt89dSi2ZO+7mKRr0DareIaS8WLuUo6aboDyb0KeGVtjkOi+9I/a8FKRl59i999esvkXhtDa1ayhtN2YyoF5/lbWNJ6Pf9E5FclujQ1GcIm6dSVym1jg2Bxy7CuLHD6hefbXSQ1jHbjH4T1TSFjQUdfh/TWwzRTm3jgPHauPCJDmHUQnD5XNobQlAedykWBQtOva7BjBQ5rbF4VghspxcWRO4g==; 5:JvFMnWYHVANk3OdQyrK0Xl9PenNpaELhMIS4geGEzkJpBV43H9PQQd5VXZvDHzswddw39Y8Kvf6dXyd3zTJbQ2QaUQ4VtrIGEBOBCiLcS4rwkyCC3XSbDJ5rPmD2iAZGqgA0iKl42VUSJfIb75npITNTgFLkfVgYzyV4jkOja1A=; 7:ipvv+2CQDbNGfxB0fFffA2GycQfP4Rap6FgYpR5wIr/y422eepF+ENIHK2X6G3P4ZkB7B5OivuTBdmt/PXiWQn3PuvAa0HMCRgs81IKYB6tW3iBRb0YMKVSjbukQLwFraBC5b0QMYGVxIuC5fzckcQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1aef0f22-ca66-4f5e-3d04-08d64396dbec x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5397; x-ms-traffictypediagnostic: AM6PR07MB5397: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(17755550239193)(131327999870524)(190756311086443)(82608151540597)(195916259791689)(109105607167333); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231382)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB5397; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB5397; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(396003)(136003)(39860400002)(199004)(189003)(97736004)(478600001)(316002)(99286004)(55016002)(6916009)(446003)(229853002)(25786009)(7696005)(14454004)(9686003)(6436002)(68736007)(476003)(486006)(76176011)(2900100001)(54906003)(86362001)(11346002)(81156014)(53936002)(2906002)(5660300001)(81166006)(8676002)(4326008)(6116002)(186003)(8936002)(74316002)(46003)(4744004)(6506007)(6246003)(33656002)(71200400001)(53546011)(106356001)(71190400001)(305945005)(7736002)(105586002)(102836004)(256004)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5397; H:AM6PR07MB4930.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 7YFGPQGelLufcTnLtmRLuYM0JswksCAWhNW7sR1vl58alJItbM71xiTa2Hcf47bVeQQHcdSmDi6P+eCXiNBhesVjkJOA+m3y/+XccXovrT8Fr5EHgEz7fDniU7x8q0r52eIDD0Hz97VppBsME59gAi/kHP8dySmPd5MFaXa/PX0vc+h7tUqa5DUy1kimpcfGZdGp02T/YVZHznv1MmqKAk2iJdzuGBXxyQrs86ZcPPpYjnWCWdVDuhmSNsZk3tGCWhWAwGPpfOzCBbZvALmoWMR7r3xdMNZHipjKqg0NisxUpocmNM0PFVe4EGy1lnVNVVcSXI0NNSSxerWRsU73IoonF7nzOjFUontlGn7QJUw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1aef0f22-ca66-4f5e-3d04-08d64396dbec X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 03:20:53.2726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5397 Archived-At: Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 03:21:00 -0000 Hi Carsten, > Here are my two cents=85 > >> 1. "that can be used to combine representations of several different > >> media types" -- Does it have to be several media types or is 2 media > >> types enough? 1? 0? > > > > s/several/two or more/ ? > > =93Several=94 was not intended to exclude 2, 1, or 0. > I see that the dictionary does this. > (It can be 0 or 1 in the case introduced by draft-bormann-core-maybe.) It's "[...] used to combine zero or more media types" then? > >> 1. "into a single CoAP message-body with minimal framing overhead, > >> each along with a CoAP Content-Format identifier." -- Can it only be > >> used in a CoAP message-body? > > > > s/CoAP message-body/message/ ? > > Well, this is a body, which might even be transmitted in block-wise > fashion, so it is not tied to messages. Maybe =93CoAP request or > response body=94 is the best way to fit this. Works for me. > (There is no implication that it can=92t also be used to brush your > teeth.) :-) > >> 1. "Applications using the application/multipart-core > >> Content-Format define the internal structure of the > >> application/multipart-core representation." -- Isn't the internal > >> structure of the format defined by figure 1? Or is this about > >> assigning further meaning to positions in the array? > > > > Yes, it's the fact that the exact position of a type inside the > > array is part of the structural definition - in fact, the position > > is the unique name of the field inside the aggregate type. > > I think Klaus wants us to point out that the application needs to stay > in the CDDL. The CDDL describes the syntactic constraints but the applications still need to define the shape and semantics of their multipart blobs. Using a programming metaphor, the CDDL says "it's a struct", while the applications define the fields and associated types inside the struct. > >> 1. "For example, one way to structure the sub-types specific to an > >> application/multipart-core container is to always include them at > >> the same fixed position." -- Ah, I see. Join this paragraph with > >> the previous one. > > > > Makes sense. > > > >> 1. "This specification allows to indicate that an optional part is > >> not present by substituting a null value for the representation of > >> the part." -- Do we need this? > > > > How do you suggest we deal with optional values? > > You could leave them out entirely, but then the application cannot > simply use a positional structure. Optionality by omission doesn't work in all cases (e.g., two adjacent optional fields of the same type) and I'd rather recommend using the positional approach which works in all cases and is trivial to implement. But yes, we probably shouldn't preclude the ability of the application designer to optimise for its case. > >> 1. "Optionally, an application might use the general format defined > >> here, but also register a new media type and an associated > >> Content-Format identifier -- typically one in the range 10000-64999 > >> -- instead of using application/multipart-core." -- What's an > >> example where an application would do this? I can't imagine any > >> where I'd recommend this. > > > > I don't see how that could harm (besides, if someone wants to do it, > > we cannot prevent it); that said I'm not opposed to removing text > > that is not strictly necessary. > > It was meant as an encouragement to define application-specific media > types in a way that conforms with the structure of multipart-ct where > that makes sense. Either way I'm OK: I think is a good suggestion but it's not needed for interop so we could also leave it out. > >> 1. "typically one in the range 10000-64999" -- Better not to state > >> the range explicitly as that locks the Content-Formats registry > >> into providing this range for this purpose forever. > > > > If we remove the above, this will go together with that. > > Right. We could explicitly say =93First Come First Served=94 instead. Works for me. > >> 2. -- There should be a sub-section or paragraph specifying what a > >> recipient of a application/multipart-core representation should do > >> if it encounters something that doesn't match the grammar. Does the > >> whole array become unusable when there is an unexpected element, or > >> can a recipient use the array up to the unexpected element? Should > >> a recipient try to do error recovery and skip to the next element? > >> This has impact on how the format can be evolved in the future. > > > > Isn=92t that application specific? > > Please see draft-iab-protocol-maintenance Going back to Klaus' comment, which grammar are we talking about? The overarching CDDL or the application defined position-type-value? If the former I'm more than OK to say "fail hard and early" in this document. If the latter, I wouldn't know how to deal with these kinds of inconsistencies in a generally applicable way. These things should be left to the applications. > >> 2. "(Future extensions might want to include additional alternative > >> ways of specifying the media type of a representation in such a > >> position.)" -- This side note feels a bit out of place and isn't > >> really helpful. What should a reader of the document do with this > >> information? > > > > Yep, I agree this is out of scope and we should remove it. > > If we don=92t want to do this, we should remove it. (I still believe we > should do this, now.) I think it's safer if we leave any alternative future format to a separate multipart-ct-2. > >> 3. -- Is the "Observing Resources" example the prime usage example > >> for -multipart-ct? If not, shouldn't there be an example for the > >> prime use case? > > > > I don't think there are prime use cases in a "hierarchical" sense. > > Anything that fits is good to go :-) > > > >> 3.1. -- I see that draft-ietf-core-coap-pubsub-05 is still > >> proposing a new response code (2.07) for this scenario. Will > >> -pubsub switch to -multipart-ct as described in this section? If > >> not, better remove the example. > > > > This one is for Carsten, but I think the example in 3.1 is not > > necessarily pubsub specific, though clearly it applies quite well to > > pubsub. > > Let=92s discuss this in the WG today. Apologies I couldn't be there, I had a conflict with TLS :-( I'll read the minutes. > >> 3.2 "Implementation hints" -- This doesn't seem like a usage > >> example. Promote it to a top-level section. > > > > Agree > > > >> 3.2 "In effect, the serialization for a single object is done by > >> prefixing the object with information about its content-format > >> (here: 0x82 0x00) and its length (here: 0x4b)." -- What about the > >> array containing the two elements? > > > > Sorry, I don=92t understand this. > > Klaus points out that there is one more byte, something like 0x81. OK > >> 4.1 "Fragment identifier considerations: N/A" -- Change to same as > >> CBOR? > > Should we also copy the text: =93(At publication of this document, there > is no fragment identification syntax defined for =93application/cbor=94.)= " > ? > > >> > >> 6.1 "[RFC7252]" -- Just to confirm: This is a normative reference > >> because of the use of CoAP Content-Format numbers, right? > > > > Yes > > > >> 6.1 "[RFC7641]" -- This should be an informative reference, as > >> Observe seems to be referenced only in the usage examples section. > > > > Agree > > > > Thank you very much! > > Indeed! and thank you, cheers, t ________________________________________ From: Carsten Bormann Sent: 05 November 2018 07:24:03 To: Fossati, Thomas (Nokia - GB/Cambridge) Cc: hartke@projectcool.de; core@ietf.org Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02 Here are my two cents=85 > On Oct 31, 2018, at 00:42, Fossati, Thomas (Nokia - GB/Cambridge) wrote: > > Hi Klaus, > >> 1. " This memo defines application/multipart-core, an >> application-independent media-type" -- General purpose media-type? >> (Why does it have "core" in the name if it's general-purpose?) > > It's got "core" because it specifies the use of CoAP content formats for > constructing the aggregate, but that doesn't invalidate the general > purpose-ness, I think. Indeed. >> 1. "that can be used to combine representations of several different >> media types" -- Does it have to be several media types or is 2 media >> types enough? 1? 0? > > s/several/two or more/ ? =93Several=94 was not intended to exclude 2, 1, or 0. I see that the dictionary does this. (It can be 0 or 1 in the case introduced by draft-bormann-core-maybe.) >> 1. "into a single CoAP message-body with minimal framing overhead, >> each along with a CoAP Content-Format identifier." -- Can it only be >> used in a CoAP message-body? > > s/CoAP message-body/message/ ? Well, this is a body, which might even be transmitted in block-wise fashion= , so it is not tied to messages. Maybe =93CoAP request or response body=94 is the best way to fit this. (There is no implication that it can=92t also be used to brush your teeth.) >> 1. "Applications using the application/multipart-core Content-Format >> define the internal structure of the application/multipart-core >> representation." -- Isn't the internal structure of the format defined >> by figure 1? Or is this about assigning further meaning to positions >> in the array? > > Yes, it's the fact that the exact position of a type inside the array is > part of the structural definition - in fact, the position is the unique > name of the field inside the aggregate type. I think Klaus wants us to point out that the application needs to stay in t= he CDDL. >> 1. "For example, one way to structure the sub-types specific to an >> application/multipart-core container is to always include them at the >> same fixed position." -- Ah, I see. Join this paragraph with the >> previous one. > > Makes sense. > >> 1. "This specification allows to indicate that an optional part is not >> present by substituting a null value for the representation of the >> part." -- Do we need this? > > How do you suggest we deal with optional values? You could leave them out entirely, but then the application cannot simply u= se a positional structure. >> 1. "Optionally, an application might use the general format defined >> here, but also register a new media type and an associated >> Content-Format identifier -- typically one in the range 10000-64999 -- >> instead of using application/multipart-core." -- What's an example >> where an application would do this? I can't imagine any where I'd >> recommend this. > > I don't see how that could harm (besides, if someone wants to do it, we > cannot prevent it); that said I'm not opposed to removing text that is > not strictly necessary. It was meant as an encouragement to define application-specific media types= in a way that conforms with the structure of multipart-ct where that makes= sense. > >> 1. "typically one in the range 10000-64999" -- Better not to state the >> range explicitly as that locks the Content-Formats registry into >> providing this range for this purpose forever. > > If we remove the above, this will go together with that. Right. We could explicitly say =93First Come First Served=94 instead. >> 2. -- There should be a sub-section or paragraph specifying what a >> recipient of a application/multipart-core representation should do if >> it encounters something that doesn't match the grammar. Does the whole >> array become unusable when there is an unexpected element, or can a >> recipient use the array up to the unexpected element? Should a >> recipient try to do error recovery and skip to the next element? This >> has impact on how the format can be evolved in the future. > > Isn=92t that application specific? Please see draft-iab-protocol-maintenance >> 2. "(Future extensions might want to include additional alternative >> ways of specifying the media type of a representation in such a >> position.)" -- This side note feels a bit out of place and isn't >> really helpful. What should a reader of the document do with this >> information? > > Yep, I agree this is out of scope and we should remove it. If we don=92t want to do this, we should remove it. (I still believe we should do this, now.) >> 3. -- Is the "Observing Resources" example the prime usage example for >> -multipart-ct? If not, shouldn't there be an example for the prime use >> case? > > I don't think there are prime use cases in a "hierarchical" sense. > Anything that fits is good to go :-) > >> 3.1. -- I see that draft-ietf-core-coap-pubsub-05 is still proposing a >> new response code (2.07) for this scenario. Will -pubsub switch to >> -multipart-ct as described in this section? If not, better remove the >> example. > > This one is for Carsten, but I think the example in 3.1 is not > necessarily pubsub specific, though clearly it applies quite well to > pubsub. Let=92s discuss this in the WG today. >> 3.2 "Implementation hints" -- This doesn't seem like a usage example. >> Promote it to a top-level section. > > Agree > >> 3.2 "In effect, the serialization for a single object is done by >> prefixing the object with information about its content-format (here: >> 0x82 0x00) and its length (here: 0x4b)." -- What about the array >> containing the two elements? > > Sorry, I don=92t understand this. Klaus points out that there is one more byte, something like 0x81. >> 4.1 "Fragment identifier considerations: N/A" -- Change to same as >> CBOR? Should we also copy the text: =93(At publication of this document, there is no fragment identification syntax defined for =93application/cbor=94.)" ? >> >> 6.1 "[RFC7252]" -- Just to confirm: This is a normative reference >> because of the use of CoAP Content-Format numbers, right? > > Yes > >> 6.1 "[RFC7641]" -- This should be an informative reference, as Observe >> seems to be referenced only in the usage examples section. > > Agree > > Thank you very much! Indeed! Gr=FC=DFe, Carsten From nobody Mon Nov 5 23:03:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1987D1277C8 for ; Mon, 5 Nov 2018 23:03:46 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51BEbKwZPfZ1 for ; Mon, 5 Nov 2018 23:03:44 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 579F712777C for ; Mon, 5 Nov 2018 23:03:44 -0800 (PST) Received: from mail-qt1-f170.google.com ([209.85.160.170]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJvOn-0008PP-Rf; Tue, 06 Nov 2018 08:03:41 +0100 Received: by mail-qt1-f170.google.com with SMTP id p35so1496711qtc.4 for ; Mon, 05 Nov 2018 23:03:41 -0800 (PST) X-Gm-Message-State: AGRZ1gIM+HnOBqfwuCzsA1VOEdvV4+/tXHnLLROsP1ypIdEhO1qARwQI +1gj3QWOyJsdtq7nJ9kST2IqimJpa5PO4QEWccY= X-Google-Smtp-Source: AJdET5fplV+samOa6YuPslAa9+tj4apqiJBKBLXzAJjAFnyDXDe26droenZ9HVDFwmZOLuhT6CzvEK5ftPbrK89yOgw= X-Received: by 2002:aed:26a3:: with SMTP id q32mr12511654qtd.106.1541487820754; Mon, 05 Nov 2018 23:03:40 -0800 (PST) MIME-Version: 1.0 References: <20181031164534.GA4995@hephaistos.amsuess.com> <20181105120109.GC12165@hephaistos.amsuess.com> In-Reply-To: <20181105120109.GC12165@hephaistos.amsuess.com> From: Klaus Hartke Date: Tue, 6 Nov 2018 08:03:04 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541487824; e618af48; X-HE-SMSGID: 1gJvOn-0008PP-Rf Archived-At: Subject: Re: [core] [T2TRG] Review of CoRAL X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 07:03:46 -0000 Christian Ams=C3=BCss wrote: > The grouper version is probably more concise than the note that "the > Python code expects base and href not to be input in the trivial > deserialization of a CBOR array, but as a list of (option number, option > value) pairs" that should otherwise be there. Right, but it also makes the code slightly less self explanatory. I'll think about it. Thanks! > Having read up on them, a "profile" has a no-changes-to-interpretation > condition: > > A profile MUST NOT change the semantics of the resource representation > when processed without profile knowledge, so that clients both with > and without knowledge of a profiled resource can safely use the same > representation > > Given that a client without knowledge of the profile can't process a > representation, the parameter should probably be called something else. Good catch! I've changed the parameter name to "registry" in my working cop= y. Klaus From nobody Tue Nov 6 00:06:07 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA60D12D4E9 for ; Tue, 6 Nov 2018 00:06:04 -0800 (PST) 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, 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=smartthings.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 fn51THPaHPcg for ; Tue, 6 Nov 2018 00:06:01 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 B25E3128A5C for ; Tue, 6 Nov 2018 00:06:01 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id f24so10614103otl.5 for ; Tue, 06 Nov 2018 00:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TjJ9SU2lds+wu9h99kPzHKmDXTuyzbmYP9KFlPip9ps=; b=cZn9tw7ejNevTwq1ndEZEqg1S3ZGBrqQSoKvmVGxuWOUxIb0j/tD0yL5HaMLUcPN9c mR2LbzdxsBK4jbGKWL1ykGVmF3qJlDeYLidBYAPen52pgKMGqMDNisbb7UHOulAvnjEN fhclH8H4i4VKFPDTswmwHdK+FwvvAyrhJp/LVa2OSURVzODAk7pqONNAnPREM2GEQ0TY MMtoi6mQD+OefgXJQE+7+FYc9dSddoG55yT6Zvp/BDlQtpoAzvH6e0iECPsvxDJGvo8s Pi2P8gtgUevSya6kKp+lBjWP3juBJUae/mnG0L7MIz7FSIz+PW8CiEZDxRGhym+72dhh /hRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TjJ9SU2lds+wu9h99kPzHKmDXTuyzbmYP9KFlPip9ps=; b=L/jUEckb3gToD2Sb2us1ATosxLk0kg/MlsoLpebiBkUUcrKr5pxErdE8+XDXsi6NSC uMcgr3jTyrZYgBVHCEKY6Gw0rnLHtn9lz+GXXCZOjKQeuc7G10/QDQ5FsGEr3W8GtIgI u7u3iBl+Nke1rmvWIWJRT/psqxO5VSOgAVG9xnw/mr5M6dUM4RdxCtygJ5YFmUpvowlM pSpAhscquEyssoJASJEnfozeBrhwVVQlcZtkDoLFJiYtd194S1h/bk9CJZsKCjLwUPYH W0tbA+I2BSOgX9gsBrq2hmgVi+l9ps8FTIS0A6qfrztiuj5rDpPnUwUafmum/8RI6xnB UQHQ== X-Gm-Message-State: AGRZ1gIpHY7QhOQQ7UsFlyzXVCCUSPYSMQcDVTyPUJ6Wdf0QPahAWva6 ZHzmMv4IdkIVLvKCHrgnmFbyQg== X-Google-Smtp-Source: AJdET5f2j3YNq0HZ59KU79rtU/GTuuEcC9UgZUNi4EuDHWrJtQoxPWz+uVYVjZ4Eid8PXlZ1rjOLxQ== X-Received: by 2002:a9d:3d0:: with SMTP id f74mr14805183otf.52.1541491560816; Tue, 06 Nov 2018 00:06:00 -0800 (PST) Received: from [10.0.0.3] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id t132-v6sm141775oih.37.2018.11.06.00.05.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 00:06:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: <20180926163552.GA18946@hephaistos.amsuess.com> Date: Tue, 6 Nov 2018 00:05:57 -0800 Cc: core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180926163552.GA18946@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= , Bill Silverajan , "jintao.zhu@huawei.com" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Dynlink observation attributes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 08:06:05 -0000 Hi Christian, I have finally read through these notes again and thought through the = questions, and I have some comments as well as some general re-think. I am convinced that we need to support observe attributes as query = parameters to an observe request, and include them in the request = caching. This makes sense as an application pattern and as a sub-pattern = for dynlinks (below). The modified URI may be thought of as a newly defined resource that = exposes a coarser grained dynamic representation of the same variable = indicated by the other URI parameters. I haven't fully thought through = the caching issue with etags and lifetimes, but it seems like there will = be ony one set of parameters feeding any given cached resource. The = notifications should be cacheable. I am also convinced that the idea of storing parameters on PUT and = returning them on GET is hard to work out, and I agree we need to = rethink that part. I believe we were trying to find a way to make the = parameters themselves readable but there are other ways to support this, = like in a dynlink. On that, I believe that the use of target attributes in a dynlink is = quite reasonable if we consider that the target of the link is always = the source of the transfer when rel=3Dboundto, and that we always use = the observe mechanism as an architectural model =3D> they are always = observe attributes, and they apply to the target of the link which is = hte source of the transfer. The "native" case is simply an optimization and not an architecture = permutation. A practical implementation may re-use the observe mechanism = for local transers.=20 Note that using a dynlink makes the observe parameters visible and gives = the observe relationship an affordance. Note also that the "bind" attribute is not strictly needed if we apply = these other constraints, as you point out. We may always assume observe = as an architectural model. This can be generalized to allow the link to = be stored anywhere that a client function can be implemented, especially = useful if we don't want to modify existing servers.=20 Not sure if we need polling but if we do, it's probably not the same = relation as "boundto". The transfer would likely be from source to = target like rel=3Dpolls, as in "target polls context". Only one = attribute of poll interval could be supported, and of course the others = could be modeled on observers of the target resource after the polling, = using the algorithm.=20 Many of your text comments can be resolved if we make these = simplifications.=20 We do not need to include the dysfunctional LWM2M "empty put with query" = method at all, or maybe as an appendix and negative example. In the draft we can describe the observe attribute first, then describe = the use in dynlinks, then describe a link table example implementation. = I think a lot of the confusion can be alleviated this way, and we can = focus on preferred patterns. Does this make sense? I could write up a rough strawman draft with the = changes. This also tracks my implementation approach. I have a third method of = storing the parameters as static variables for the resource, but that's = mostly a refactoring optimization of the binding table where there is = only one destination e.g. LPWAN link to a device. Does this all make sense? Michael > On Sep 26, 2018, at 9:35 AM, Christian Ams=C3=BCss = wrote: >=20 > Hello Michael, >=20 > as suggested in today's interim meeting, I'd like to get the = discussion > on observation attributes going again. >=20 > To me, the takewaway point of today was that there can be various ways > of expressing the observation attributes; that we're happy with what = the > attributes can do and their semantics, but that the current way of > persistently PUT parameters on a link is not ideal for the general use > case. >=20 > I've left the bulk of my original mail below because I still think it > gets across the message (though some may be preaching to the choir = given > the above), and stripped unrelated points into a separate thread: >=20 >> Observation attributes >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> I'd like to refer back to one of my earlierst mails on this mailing >> list at [CA2013]. The answer to "why not just observe >> as it was in earlier drafts" about = caching >> was not really satisfying, given that this scheme breaks caching just = as >> the original but just worse (previously, a cache would just not have = a >> response ready; now, it sees an observation and thinks the value is >> current where it's actually from an observation to a client that's = not >> interested in details). >>=20 >> The way of PUTting empty values onto query-parameter identified >> resources is incompatible with multiple observations. >>=20 >> Moreover, its use is unclear to me from reading it. The sentence = "These >> query parameters MUST be treated as resources that are read using GET >> and updated using PUT" seems to indicate that they are used like = this: >>=20 >> | GET /temp?pmin >> | 2.05 Content >> | Payload: "0" >>=20 >> (or however undefined is expressed there) >>=20 >> | PUT /temp?pmin >> | Payload: "10" >> | 2.04 Changed >>=20 >> But "Multiple parameters MAY be updated at the same time by including >> the values in the query string of a PUT" makes it sound like it = should >> be >>=20 >> | PUT /temp?pmin=3D10&pmax=3D20 >> | empty payload >> | 2.04 Changed >>=20 >> -- are both permissible? And if only the latter: How is this accessed >> with GET? Examples might help, but explicit words would be good too. >>=20 >> Another open question is how to turn those limits off again. Would I >> just DELETE the resources?=20 >>=20 >> This was all a whole lot clearer when one could observer >>=20 >> | GET /temp?pmin=3D10&pmax=3D20 >>=20 >> and have those limits per observation without any new state = introduced >> to the server -- a behavior I would still prefer to see there. >>=20 >> [CA2013]: http://ietf.org/mail-archive/web/core/current/msg04270.html >>=20 >> Observation attributes in bindings >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> There are two components in this document I percieve as relatively >> separate -- the link bindings, and the limiting attributes. >>=20 >> Link bindings work well on their own. >>=20 >> With in-query observation attributes, there would not be any need to >> define the attributes additionally as link attributes (where, judging >> from RD discussions, it can be confusing to have both). >>=20 >> Especially troublesome about the attributes is that they are not = target >> attributes, but link attributes. (All other common attributes in >> link-format documents are target attributes, with the exception of >> anchor=3D and rel=3D/rev=3D which are core to the web linking model). = That >> means that using other web link formats (eg. CoRAL, RDF; don't know >> about HSML) will have a hard time expressing those. I think that >> non-target link attributes should be limited to data that is = meaningful >> on the web linking level and not for arbitrary attributes. >=20 > One closing throught: In implementations, we're often thinking of > everything that has the same path as the same resource, and query > parameters just giving details on it. CoAP's REST model does not know > this distinction -- /temp is something different than /temp?pmin=3D10, = and > only because we said ;if=3D"core.s" we can conclude that it's > related to the /temp?pmin=3D10 resource. >=20 > Let us stick with this, and call /temp?pmin=3D10 a view on /temp, like > through a lens that blurs an image. >=20 > Best regards > Christian >=20 > --=20 > This may seem a bit weird, but that's okay, because it is weird. > -- perldata(1) about perl variables > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Nov 6 00:06:54 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9A12D7EA for ; Tue, 6 Nov 2018 00:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf0wxC01I3P9 for ; Tue, 6 Nov 2018 00:06:50 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 64C9E128A5C for ; Tue, 6 Nov 2018 00:06:50 -0800 (PST) Received: from mail-qt1-f169.google.com ([209.85.160.169]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJwNs-00085h-4M; Tue, 06 Nov 2018 09:06:48 +0100 Received: by mail-qt1-f169.google.com with SMTP id b22-v6so1621435qtr.11 for ; Tue, 06 Nov 2018 00:06:48 -0800 (PST) X-Gm-Message-State: AGRZ1gJnIY2nrxdLjJ57gDuZ117/Ew8ovehFvKrENzWnTyH3MQJWkTq7 2EmyHlNO5v7uSSDzUK2w7drl59j2+OAMtxL93d0= X-Google-Smtp-Source: AJdET5cr3Gw8Y/AYkHoGs93/wkTV1yNvYtqlPCE2V1+OeQf85HvYu0xNx28KsAklMT/lS2EJzdLDkQnc3aDjvnZomC4= X-Received: by 2002:ac8:2ea5:: with SMTP id h34-v6mr24236567qta.18.1541491607139; Tue, 06 Nov 2018 00:06:47 -0800 (PST) MIME-Version: 1.0 References: <20181105123604.GA9680@hephaistos.amsuess.com> In-Reply-To: <20181105123604.GA9680@hephaistos.amsuess.com> From: Klaus Hartke Date: Tue, 6 Nov 2018 09:06:11 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541491610; 8f2a4ec6; X-HE-SMSGID: 1gJwNs-00085h-4M Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 08:06:53 -0000 Christian Ams=C3=BCss wrote: > Non-target link attributes are something I'd discourage in general; > would you, when someone does define new non-target attributes, encourage > them to specify how they'd be expressed in CoRAL? I think I don't care enough about Link Format that I'd encourage maintaining any kind of mapping. The draft currently describes a generic mapping that works for any target attribute but makes no attempt to work for any non-target attribute. If I could get rid of the mapping, I would do it. > > Since in CoRAL it's possible to make statements about link targets > > (here: the literal "=C3=9Cberschrift"), something like this would look > > natural to me: > > > > #using iana =3D > > #using attr =3D > > > > iana:terms-of-service { > > attr:title "Nutzungsbedingungen" { attr:hreflang "de" } > > attr:title "Terms of use" { attr:hreflang "en" } > > } > > > > <=3D> > > > > ; rel=3Dterms-of-service; > > title*=3DUTF-8'de'Nutzungsbedingungen; > > title*=3DUTF-8'en'Terms%20of%20use > > That's kind of neat and kind of scary. Good point. I'm open to other ideas. But I think I don't want make processing much more complex to accommodate language-tagged strings, since it's unlikely that a constrained device will serve links annotated with titles in 20 languages. > > If there's a guarantee that there won't be any new link target > > attributes in the future (for RFC 6690 link serializations), then we > > could skip the whole mapping topic and just define a new, more natural > > set of link relation types: > > I don't think we need a guarantee for that. We can, as they pop up, for > some funny-string-valued attributes define equivalent more semantic > attributes, each with their own mapping. So a general CoRAL processor > you could encounter both `attr: rt=3D"x y"` or `split-attr:rt rt:x, > split-attr rt:y` and needs to know of the equivalence. This is exactly what I'd like to avoid. IMO we should decide on either a generic mapping that can round-trip any attributes or a new set of relations, but not both: Implementations could never rely on that the other kind doesn't appear and therefore would have to support both, which doesn't help with keeping developers happy and implementation sizes small. Klaus From nobody Tue Nov 6 00:22:20 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9B1128A6E for ; Tue, 6 Nov 2018 00:22:16 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WneRJFiA8FMm for ; Tue, 6 Nov 2018 00:22:15 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 22658128A5C for ; Tue, 6 Nov 2018 00:22:15 -0800 (PST) Received: from mail-qt1-f178.google.com ([209.85.160.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJwcn-0006Ic-Ig; Tue, 06 Nov 2018 09:22:13 +0100 Received: by mail-qt1-f178.google.com with SMTP id v11so1648909qtc.2 for ; Tue, 06 Nov 2018 00:22:13 -0800 (PST) X-Gm-Message-State: AGRZ1gJIwdFuKF34RMfpl9somWuWFgguKMYRZxOBh6GaW9hTOuFmzGXx r/ha5s+4T7FJddPNNWgvkJK0T4oU52cfHDyjzj8= X-Google-Smtp-Source: AJdET5c8K3osixvTXRcV3EisFRZLZIgusYvpdT90dXAJuZ8kgodepQkiYF3Ai0StVOI9mMTLWj8H7tq5gZOaOW0xyqU= X-Received: by 2002:a0c:ae30:: with SMTP id y45mr24201639qvc.145.1541492532625; Tue, 06 Nov 2018 00:22:12 -0800 (PST) MIME-Version: 1.0 References: <20181105123604.GA9680@hephaistos.amsuess.com> In-Reply-To: From: Klaus Hartke Date: Tue, 6 Nov 2018 09:21:36 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541492535; 81477c85; X-HE-SMSGID: 1gJwcn-0006Ic-Ig Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 08:22:17 -0000 Klaus Hartke wrote: > Christian Ams=C3=BCss wrote: > > I don't think we need a guarantee for that. We can, as they pop up, for > > some funny-string-valued attributes define equivalent more semantic > > attributes, each with their own mapping. So a general CoRAL processor > > you could encounter both `attr: rt=3D"x y"` or `split-attr:rt rt:x, > > split-attr rt:y` and needs to know of the equivalence. > > This is exactly what I'd like to avoid. Of course, we could for new link target attributes, as they pop up, define an equivalent more semantic link relation type. In Link Format you would use the link target attribute; in CoRAL, the link relation type. If a converter encounters a new, unknown attribute, it would fail. Klaus From nobody Tue Nov 6 00:22:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70274130F86 for ; Tue, 6 Nov 2018 00:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAfJ_FfU59rP for ; Tue, 6 Nov 2018 00:22:44 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C350130F59 for ; Tue, 6 Nov 2018 00:22:44 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6B11041EAF; Tue, 6 Nov 2018 09:22:42 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 877F16E; Tue, 6 Nov 2018 09:22:41 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3C91337; Tue, 6 Nov 2018 09:22:41 +0100 (CET) Received: (nullmailer pid 18536 invoked by uid 1000); Tue, 06 Nov 2018 08:22:40 -0000 Date: Tue, 6 Nov 2018 09:22:40 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Klaus Hartke Cc: "core@ietf.org WG" Message-ID: <20181106082240.GB4293@hephaistos.amsuess.com> References: <20181105123604.GA9680@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 08:22:47 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > > attr:title "Nutzungsbedingungen" { attr:hreflang "de" } > > That's kind of neat and kind of scary. >=20 > Good point. I'm open to other ideas. But I think I don't want make > processing much more complex to accommodate language-tagged [...] I'm more and more confident that the scheme you proposed can work, and the only thing that does need to be done is to be very clear about how the RDF mapping works, and to say that only particular relations SHOULD be used with literals. (And I can work out with RDF people what the particular attribute for language tagging should be if you like). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvhT00ACgkQOY0REtOk veGgwg/8DvmqaJ75eRGzF8D1h5SGMJVGUx6vnFZmm885d0v5C2rReHc5OOjZ3L2I 3rz51dZr3cdJ55wg4MVPCLhFprNFFh/gizVs7B/U6Zs6310xeHjTlA2F+SUiL0B3 KY9CEtIgOnslGgHm3OsuF1lqom2jzT8FVRZsXnMubAIuJ9RoSzoDGhVH8De8aF/P nDEKJet2XGKsn7FdYi/vV17D/tSvuWmUVx/ajyb5/O8mjSCq1BpR21GR0bjaQefn NBTzQ3BaRRZcc672PoDLXT3LO4hk3eVays+q6/1EO+lQCRNCKqhoxE8mbibFbRqe /DIGTuhMfMyHnBpX0ostR21o2cQxxHGi0ksgs9zhl8TdKw91D3DPqmG05O+bKZYO PFz89fY8sn4JWrq+sRAoZz/5wXomeZcCUVqvhyOY4p0Vk3rP+ZP3+wK9UIUP82pd cnUdEjSs8iuuTWvXQV2qm7CqaZh1fHlftxbZTnyE8qfH+rTpd3LL0l26vkjU5aAX wL3/QVLzSGXA87Pb76sU31PnENY0setIiVUNhI5f5djmg9XojPCWSfvHvzHCvN5S WpMtHneN6IOKbqFBcIeTaPCW7r5swlojqh69m1Vzy7QReWpgfZpy+rqB506CwWJh in4C/g9ddMHWKwKK5yzkcoiB8EZNjtkHvA7mNIr/KGQOxWRN7C0= =BeYo -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From nobody Tue Nov 6 00:41:41 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EA1128A6E for ; Tue, 6 Nov 2018 00:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moRTQTtLMrN2 for ; Tue, 6 Nov 2018 00:41:38 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B701277C8 for ; Tue, 6 Nov 2018 00:41:37 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D5A3C41EAF; Tue, 6 Nov 2018 09:41:35 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DC3086E; Tue, 6 Nov 2018 09:41:34 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9859837; Tue, 6 Nov 2018 09:41:34 +0100 (CET) Received: (nullmailer pid 20468 invoked by uid 1000); Tue, 06 Nov 2018 08:41:34 -0000 Date: Tue, 6 Nov 2018 09:41:34 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Klaus Hartke Cc: "core@ietf.org WG" Message-ID: <20181106084134.GC4293@hephaistos.amsuess.com> References: <20181105123604.GA9680@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 08:41:40 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 06, 2018 at 09:21:36AM +0100, Klaus Hartke wrote: > Christian Ams=FCss wrote: > > I don't think we need a guarantee for that. We can, as they pop up, for > > some funny-string-valued attributes define equivalent more semantic > > attributes, each with their own mapping. So a general CoRAL processor > > you could encounter both `attr: rt=3D"x y"` or `split-attr:rt rt:x, > > split-attr rt:y` and needs to know of the equivalence. > > This is exactly what I'd like to avoid. > > [later] >=20 > Of course, we could for new link target attributes, as they pop up, > define an equivalent more semantic link relation type. In Link Format > you would use the link target attribute; in CoRAL, the link relation > type. If a converter encounters a new, unknown attribute, it would fail. Only defining the mapping for known target attributes would neatly get us rid of the issue of link attributes. Implementations could still be as simple as possible (ie. not even have an enumeration of known attributes) if they accept producing odd output on unspecified input, and follow the most common rule (map to attr:${key} "${value}") on all but the known whitespacers. My expectation though is that processors that convert link-format to CoRAL would be less constrained devices (C2 or larger), and that smaller devices that still want to serve both would have something equivalent to hard-copies of both representation in ROM instead -- is that a reasonable one? Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvhU7sACgkQOY0REtOk veFPhRAAq/qcVrfll4oFzTBGncnwKHdUXeUfQXFghfMVWQ2ivjE4wVF5pQhUlmHh CcmE7p1kl3cH+C9jywTy1A73j8A6ouTMY8Iie6QzE7p0C/i3PhQjK80zc7fp7OGI JpRAvn/6Zh6GeMB8s3sQw0TeACKGHeYkg1X6Ec2ni1GEEXl9MWNjVCVk69D+M19a ghTT1yan8SfkkdomHbu9/pIZ7fk5jHW9rRufUqRRX0Ht4xUwy+WgMVxyztTRbKpI SAnnAUFRaO2Pum6Qc0TJw1sW1rSxkxmjGsf03N33sp0MOERDa52bLJBXmeAGdj5R AbiPfZPxUmRUr1Z6auf+veKt4BTC+bDpE5l54dnersF5EoGpLH2bo8fU4COr2GPZ b446RUXsJALsE632oI9s/U70UZ2v+ts8MERB57yCAjvc8/3pPLAaWpDIKUqDgl7C jZp0INq43IL1wqszJCXVzbwTCsExGLk8ezgwjv66xjj2188X2lvJLQXSUnOLhDN3 8+6QdhfQunmHH4x5OR/mYMfPkCLPI+2hPm94+4jbEXdmaqjbVppODwjv/Jxm9ulW 9Z6tKT7U3BSdrvWoI+WABN9D4tgqrdPHZNaMOF2zv5MqIMAn+fppDsfCPW8042wH dOAHScI3vBjp8sOryaonKrAqUwDaL943PFxG9pS10vv0GY3VWsY= =P7f5 -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From nobody Tue Nov 6 04:15:59 2018 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 0528312958B; Tue, 6 Nov 2018 04:15:52 -0800 (PST) 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.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <154150655193.30848.13925648205243412362@ietfa.amsl.com> Date: Tue, 06 Nov 2018 04:15:52 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-hop-limit-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 12:15:52 -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 : Constrained Application Protocol (CoAP) Hop Limit Option Authors : Mohamed Boucadair Tirumaleswar Reddy Jon Shallow Filename : draft-ietf-core-hop-limit-01.txt Pages : 6 Date : 2018-11-06 Abstract: The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-hop-limit/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-hop-limit-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-hop-limit-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-hop-limit-01 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 Tue Nov 6 10:23:09 2018 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 E2B64124408; Tue, 6 Nov 2018 10:23:07 -0800 (PST) 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.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <154152858785.30885.9037127702139471129@ietfa.amsl.com> Date: Tue, 06 Nov 2018 10:23:07 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-too-many-reqs-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 18:23:08 -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 : Too Many Requests Response Code for the Constrained Application Protocol Author : Ari Keranen Filename : draft-ietf-core-too-many-reqs-06.txt Pages : 6 Date : 2018-11-06 Abstract: A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP Response Code for a server to indicate that a client should reduce the rate of requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-06 https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-too-many-reqs-06 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 Tue Nov 6 18:33:02 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3C7128CE4 for ; Tue, 6 Nov 2018 18:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=QiTrm5km; dkim=pass (1024-bit key) header.d=ericsson.com header.b=WHMzlxD3 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 z8kB6LnQIGCH for ; Tue, 6 Nov 2018 18:33:00 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 AECF012785F for ; Tue, 6 Nov 2018 18:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541557977; x=1544149977; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EsOG02v/ZagjU/sMvvByr3sIIHu522bz+zRDhSPC45o=; b=QiTrm5kmI2aH7OZLU8jdkY1OJsXC2mKDU2rl7OABVo/R4iePgiDMEVDXrnODkXh5 kb3m9790TNrUa3zvBqR1QxZR+G9mSz33wWmX9BSgxiye2+TU60Vet0CcmZ1SZsY6 RZYKXt4+Al5futyA7hkZ2RjLKMo1IvQiD8HQOWL0klA=; X-AuditID: c1b4fb2d-f61ff70000007af1-5d-5be24ed98215 Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.84.31473.9DE42EB5; Wed, 7 Nov 2018 03:32:57 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 7 Nov 2018 03:32:56 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 7 Nov 2018 03:32:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=awN6kluDcepVbMVitrLYvkYAfgI1ylqjirI2DSoMYQE=; b=WHMzlxD365HD2ayYM72cAFXl3aOpiX2BV0OtXmqIzcV5FCSaxHKOqjnUXHGwU+L0NQCezBwRSUkV5UmAFe/cnRRaeHWR8HxTsrsVEfxm6EbTu5RjMQ04vpKjf1NlFR7UbaNfmeazYBnSbWhjvVZl19CFCvDZBHHBpPkvwOLx2dI= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.10; Wed, 7 Nov 2018 02:32:55 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95%3]) with mapi id 15.20.1294.032; Wed, 7 Nov 2018 02:32:55 +0000 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-too-many-reqs-06.txt Thread-Index: AQHUdf3SgJ1h0kBTk0mIQxxJW2kUCA== Date: Wed, 7 Nov 2018 02:32:55 +0000 Message-ID: References: <154152858785.30885.9037127702139471129@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4236; 6:M0delIbGVStOGXKDEtoBbz0gsGE9LaddBjSgxcXSx8FnA4scruNTycfrE13ywEM9ILpS3mS44hSxBdgugl4MDvu1zV3rolYd8ESxFEhh/1zAPDElMKottxIe6Y2e2afhnRGpnBaCh6wEUERgTRfJYs40pgnP0y2BrJ3ckBE0sAYng8SQxiVioFvmdJgO1equ0R28B6c15FWimKPfZjgTIWcWpgdeDsuTD9Lw+yk6sNPwwP+r0O/DRKjfKf2pnpylFlA5P+MPFSlP0Al5pgPyuN9nfw74gCO5Mm7EDLJHLmdZQ7EK3jOt0zmRv34QlHVpkWW2wQkrhdbELoIdFiL/IaBNc9NYy+8W8xNNiB4Axf74cZ0i+R5o2Rnfg9DZr6wTpE/p/6qZL1bSSyfyQmwsZUYi8EMT5ItwSTX504jj6Y26faeEQLEbOsLXCFOTVOOTyj5UhhB+8ugh76rtwQb5Aw==; 5:jjsMYX77Jycs7hu2PEbvJNR3gZR9HIeXa84xWr1dhIpFJMXAhfH85s1tUrc9W0HUNNITnOI4hHPzlRs5ggb0uL+BJb/1A9Dcct0dASYjgavijr+2cCZKpCxNb3qfUrsz99dT2tsjr5QWfgUogrA1LJGsq/wJbarysjghbYgZw84=; 7:wepkSEh51CKLQksZ1AEkXdwQGdsxxm8v95FKF51bOJJh4RqHC+mrkiFB2yDP3jdV1d5N4Coory6UtZEU4+QNlKn5AAYrvUuUuV+on3vRzN7MRkd5b/ielAdr3QUzR8rmOr/bWZBJ3TqN1VIaw4Vl7g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: eae60f06-74f4-42f5-640b-08d644595330 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4236; x-ms-traffictypediagnostic: HE1PR07MB4236: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB4236; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB4236; x-forefront-prvs: 08497C3D99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(376002)(346002)(366004)(189003)(199004)(81156014)(14454004)(7696005)(76176011)(6506007)(256004)(966005)(2906002)(446003)(476003)(14444005)(102836004)(478600001)(486006)(74316002)(229853002)(5660300001)(97736004)(71200400001)(71190400001)(25786009)(186003)(99286004)(8936002)(6916009)(26005)(316002)(2351001)(5640700003)(105586002)(106356001)(53936002)(6436002)(2501003)(3846002)(6116002)(6246003)(9686003)(86362001)(1730700003)(6306002)(68736007)(66066001)(7736002)(305945005)(2900100001)(55016002)(8676002)(81166006)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4236; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2AKjd0sLH5uFUHzG1wj+sx9ZxztX8GaHF40KMg84p+wzqgqkHWVwbMigQheQ832Uy9r4VexvS4K1e5V02TDKceDXEDvKmF857N/xuChRJO//CYuaZrTzFlfMkc33Jmh3tsKFLgRXTT3G9lLTVah0dHHFCRIZjl8e8OdFv0bpfDnTWV/kWJ9Sz6w6Xf7LcFScnrEMfSkXshXgPCOn78tPjMnYJYLaq1H+PgzgMkM84y6j9ePGPLzSf+TwafGiMGJkonwkZrChZV26PrtKqHl5oBkJIin2wuIawwgV8OPVLwSy7eNXHcbxsN6QdM6fyda0JsmfRL49OvRzWwwYccmu7fxh2Vd1YEstDoqVYd3XrZE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eae60f06-74f4-42f5-640b-08d644595330 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 02:32:55.6731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4236 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHfc85246j1evUfPBSNCvEcJYJFYQmFfUhu30pXGKHPKioU86Z ln6IhWipWYtU0C86FRlTKrWY5so2DHNpSVh0gXAqak5tlpdWWLmdE/Tt9zz//3N7eWlSuUaF 0llaHctpmRyVVE7VnbfoYj6cHNfsbpoN3P90/j55CB1vafEQp1GK/GA6m5NVyHKxCRflme22 t1S+EV+52Tsi1aNyRQXypwHHQ3PVMlGB5LQS9yMYK70jEYJlBGsdfyghaCbgkccm8wYUNpBg ti2JSjUBX3tHxBonAuNyB/J2luJEuNu+6OMgHAldQy4fB+Ij4B7tlgn5o/Ds+jVSYDV45mt9 TOHtsPSiWuJlBb4Ao7dt69Po9QGH4Z7Fl0Z4M6w62gkvkzgEPk42EMJBGFqsr0mBg+HLxG/R r4FZx6BMyG+D4QWn6I+ANw2VyLs/4HdSqKt3SAQhBtw1NWKjZDCV9IimAQQ9ZWZRiIbu2VeU wNngLtVLBT4BeptL9GwBc5WTEotJGB5YEU3hYBi5JTOg2Pr/rhBYDe9rqqUC74JWo4us9z1G AAzWTVKNiDKjYJ7l+dyMuL1qlsu6xPN5WrWW1XWi9U9he/grphu1uZLsCNNItUHRmjSuUUqY Qr4o146AJlVBipdtTo1Skc4UFbNcXhpXkMPydhRGU6oQhdpsTVHiDEbHZrNsPsv9UwnaP1SP yMjagScBfXq7O+EUH/9pyU2rmwo7KiI+//yxGmjZWRXbFZe8L+D7SnHqjbkFh7npsbXzgYUa OnPAb2P6dCU5U5aKjk37JUaVJE1cXcwzlRegzB3Wc5aFYcaUxs73TY31zZ2lw59vSlyLCtv6 TRY0dbm/V7NomGmccvd7So2siuIzmT3RJMczfwHmwYxrEAMAAA== Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 02:33:01 -0000 This update addresses the final IESG review comments and issues as =0A= presented during the CoRE session on Monday.=0A= =0A= =0A= Cheers,=0A= Ari=0A= =0A= On 07/11/2018 1.23, internet-drafts@ietf.org wrote:=0A= > =0A= > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.=0A= > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF.=0A= > =0A= > Title : Too Many Requests Response Code for the Constr= ained Application Protocol=0A= > Author : Ari Keranen=0A= > Filename : draft-ietf-core-too-many-reqs-06.txt=0A= > Pages : 6=0A= > Date : 2018-11-06=0A= > =0A= > Abstract:=0A= > A Constrained Application Protocol (CoAP) server can experience=0A= > temporary overload because one or more clients are sending requests= =0A= > to the server at a higher rate than the server is capable or willing= =0A= > to handle. This document defines a new CoAP Response Code for a=0A= > server to indicate that a client should reduce the rate of requests.= =0A= > =0A= > =0A= > The IETF datatracker status page for this draft is:=0A= > https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/=0A= > =0A= > There are also htmlized versions available at:=0A= > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-06=0A= > https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-06=0A= > =0A= > A diff from the previous version is available at:=0A= > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-06=0A= > =0A= > =0A= > Please note that it may take a couple of minutes from the time of submiss= ion=0A= > until the htmlized version and diff are available at tools.ietf.org.=0A= > =0A= > Internet-Drafts are also available by anonymous FTP at:=0A= > ftp://ftp.ietf.org/internet-drafts/=0A= > =0A= > _______________________________________________=0A= > core mailing list=0A= > core@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/core=0A= > =0A= From nobody Wed Nov 7 04:27:03 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBD612D4E9 for ; Wed, 7 Nov 2018 04:27:01 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zrl1jYaZVKBX for ; Wed, 7 Nov 2018 04:27:00 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 D0E81128CF2 for ; Wed, 7 Nov 2018 04:26:59 -0800 (PST) Received: from mail-qt1-f170.google.com ([209.85.160.170]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gKMvB-0005EG-85; Wed, 07 Nov 2018 13:26:57 +0100 Received: by mail-qt1-f170.google.com with SMTP id u34-v6so6321390qth.3 for ; Wed, 07 Nov 2018 04:26:57 -0800 (PST) X-Gm-Message-State: AGRZ1gLyY/MbzWITOWqyGUaCe84aaVcHXtEpolCyNSOdyuVeTZXIcO+U penj9MuBsXDkXFal+sImyaX6U1qocBooZxwh+PQ= X-Google-Smtp-Source: AJdET5fUkoOHwbKEeIUTvl7ssMd9EQdDGeDM+H6Hh+cskWGR2XcuLgDX0k0gOJOC4pqlHvQZS1R1PwCAwCgNAqGNCIA= X-Received: by 2002:a0c:8003:: with SMTP id 3mr1446927qva.129.1541593616208; Wed, 07 Nov 2018 04:26:56 -0800 (PST) MIME-Version: 1.0 References: <20181030174246.GA6420@nokia.com> In-Reply-To: From: Klaus Hartke Date: Wed, 7 Nov 2018 13:26:19 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge)" Cc: Carsten Bormann , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541593619; 686b0161; X-HE-SMSGID: 1gKMvB-0005EG-85 Archived-At: Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 12:27:01 -0000 I think the draft needs to be much clearer on whether a multipart collection is an unordered multiset of representations (which I had assumed so far) or an ordered sequence where applications attach additional out-of-band meaning to the positions. Speaking of additional out-of-band meaning, I wonder if there should be identifiers in the collection explicitly describing the semantics in the interest of self-description. There are also considerations related to evolving the out-of-band information, such as when an application wants to change the meaning of a position but continue using the "application/multipart-core" content format ID. Klaus From nobody Wed Nov 7 09:38:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7F312D4EF for ; Wed, 7 Nov 2018 09:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.19 X-Spam-Level: X-Spam-Status: No, score=-0.19 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_EMBEDS=1.799, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 dQ5We-OnXVst for ; Wed, 7 Nov 2018 09:38:07 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 E97AD12DD85 for ; Wed, 7 Nov 2018 09:38:06 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id u130-v6so14515255oie.7 for ; Wed, 07 Nov 2018 09:38:06 -0800 (PST) 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=U2kwwCf+dDqRD4T3vk1BxhSaDKHJ29a5HVpHn4clbVI=; b=REjpB+ezfJKKpggGbCuPJLhEk6Yw+21Tb5hYw4Z1aLEeVMMy6F4vAVsP40PvwSXfXS O2pYoE1rUr/WbQOG+6VyXPTU0R91FeY4SSLl68WuGbJP+GO8R/GmI8/HDX0qDaRAKWlo Vq4EO12tnPr86xIYrWWo+QFT9P8vc1fBPvaUpYNgBdcpMOTfh+ZOBxZnsFvaq6ul7eL2 jzZ4T4N6VQYgQqUvnFZd/IESmpssVdmuWhXB+NL0nmtkQob+JD/KR8SZlUWL/IyOTy1y 0280FnCTGz00OngFPT2SfdMhJcYgfLUDG8REr71HnSlMNjEsrpaaWNTlgev+qkOnTf0k 8QlA== 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=U2kwwCf+dDqRD4T3vk1BxhSaDKHJ29a5HVpHn4clbVI=; b=gMb+/wGokgbU1fD+ugmA93cFIYS9MnAGfigfH7F9y3uF8x0EK9OEI01Wdtn+Uh3mz3 9bEU0ZtsXxQEX6uBE3oXoZUxjGaB6J5Nv21xgeqsMey6jZvuaF9ZTEL6fVWUemj+u8yL FNGWNVzLwmMTXBFeL7GGiwgxmltUaT93/YgYeK33kq/jCw8oot658skcCEfI8HlmGz/5 Mm5mmYylU0UDY3O96qsbDaAz9592hwiZgJp1bKXYmzI/gdSw5uUiKBOohghipInqcDcC c6cWbxFFK3Kr+ZtORU6symJH3vB/KqpGyxuaZD8r0FGcyy7BiAgJ561RLlLvSD9bPMTH J+pA== X-Gm-Message-State: AGRZ1gKWlwfctAkDPSpWD+4y4jRt2mMsiE5Wi/L6IC5gXqlzNk9AGWDS Fd4EFHgcBA2COn+6C5x3Qy8= X-Google-Smtp-Source: AJdET5fmph+N1BUpGw+S9V2A2mGWzMm14fQphTs6sHTT72HCLVRf1BZAGXETtnkFPvulLJFT7aqaeg== X-Received: by 2002:aca:5204:: with SMTP id g4-v6mr671422oib.149.1541612286196; Wed, 07 Nov 2018 09:38:06 -0800 (PST) Received: from [10.0.0.3] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id f3sm436467otb.12.2018.11.07.09.38.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 09:38:03 -0800 (PST) From: Michael Koster Message-Id: <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_381CF3B9-99B3-4E07-973A-12B86CCC9DC6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 7 Nov 2018 09:38:01 -0800 In-Reply-To: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> Cc: "core@ietf.org" , "fluffy@cisco.com" To: Shantanoo Desai References: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [SenML] Multiple values in a measurement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 17:38:09 -0000 --Apple-Mail=_381CF3B9-99B3-4E07-973A-12B86CCC9DC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here is one possibility: [ { "bn": "inertialmeasurement", "bu": "rad/s", "n": "xvalue", "v": 0.34, }, { "n": "yvalue", "v": 1.43, }, { "n": "zvalue", "v": 0.23, } ] Or as an IPSO Smart Object representationfor the accelerometer object = type (3313): [ { "bn": "3313/0/", "n": "5701", "vs": "rad/s", }, { "n": "5702", "v": 0.34 }, { "n": "5703", "v": 0.34 }, { "n": "5704", "v": 0.34 } ] On Oct 18, 2018, at 1:35 AM, Shantanoo Desai = wrote: >=20 > Hello all, > =20 > In a practical scenario there are sensors that provide more than one = values, for e.g., an Inertial Measurement Unit (IMU) will provide Euler = Angles as Yaw, Pitch, Roll indicating orientation of the sensor node or = an Accelerometer which measures linear acceleration in X, Y, Z = directions. > =20 > Is there any schematic in SenML that would support multiple values? > =20 > =46rom my understanding there is none and most values are indicated by = the field =E2=80=9Cv=E2=80=9D as a single key:value pair in JSON. > =20 > > =20 > Even if I split the reading into three, there might not be clear = distinction since =E2=80=9Cn=E2=80=9D always remains the same (the = sensor name is always =E2=80=9Cinertialmeasurement=E2=80=9D) > =20 > > =20 > =20 > Is there a way to inculcate such features into senML or is there a way = around this that I have overlooked? > =20 > =20 > =20 > Mit freundlichen Gr=C3=BC=C3=9Fen > =20 >=20 > i. A. M.Sc. Shantanoo Desai > Wissenschaftlicher Mitarbeiter > =20 > BIBA - Bremer Institut f=C3=BCr Produktion und Logistik GmbH > =20 > Informations- und kommunikationstechnische Anwendungen in der = Produktion > Prof. Dr.-Ing. Klaus-Dieter Thoben > =20 > Raum 1390 > Tel: +49 (0)421 218-50138 > Handy: +49 162 6536 107 > des@biba.uni-bremen.de > =20 > = = = = =20 > =20 > BIBA =E2=80=93 Bremer Institut f=C3=BCr Produktion und Logistik GmbH > Postanschrift: Postfach P.O.B. 33 05 60 =C2=B7 D-28335 Bremen / = Germany > Gesch=C3=A4ftssitz: Hochschulring 20 =C2=B7 D-28359 Bremen / Germany > USt-ID: DE814890109 Amtsgericht Bremen HRB 24505 HB > Tel: +49 (0)421/218-02 Fax: +49 (0)421/218-50031 > E-Mail: info@biba.uni-bremen.de =C2=B7 = Internet: www.biba.uni-bremen.de > Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr.-Ing. K.-D. Thoben, O. Simon > =20 > =20 > = _______________________________________________= > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_381CF3B9-99B3-4E07-973A-12B86CCC9DC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Here is one possibility:

[
  {
    "bn": "inertialmeasurement",
    "bu": = "rad/s",
    "n": "xvalue",
    "v": = 0.34,
 = },
  = {
  =   "n": "yvalue",
    "v": = 1.43,
 = },
  = {
  =   "n": "zvalue",
    "v": = 0.23,
 = }
]

Or as an IPSO Smart Object representationfor the = accelerometer object type (3313):

[
  {
    "bn": "3313/0/",
    "n": = "5701",
    "vs": "rad/s",
  },
  {
    "n": "5702",
    "v": = 0.34
 },
  {
    "n": "5703",
    "v": = 0.34
 },
  {
    "n": "5704",
    "v": = 0.34
 }
]


On Oct 18, 2018, at 1:35 = AM, Shantanoo Desai <des@biba.uni-bremen.de> = wrote:

Hello all,
 
In a practical scenario there are = sensors that provide more than one values, for e.g., an Inertial = Measurement Unit (IMU) will provide Euler Angles as Yaw, Pitch, Roll = indicating orientation of the sensor node or an Accelerometer which = measures linear acceleration in X, Y, Z directions.
 
Is there = any schematic in SenML that would support multiple values?
 
=46rom my = understanding there is none and most values are indicated by the field = =E2=80=9Cv=E2=80=9D as a single key:value pair in JSON.
 
<image006.png>
 
Even if I = split the reading into three, there might not be clear distinction since = =E2=80=9Cn=E2=80=9D always remains the same (the sensor name is always = =E2=80=9Cinertialmeasurement=E2=80=9D)
 
<image007.png>
 
 
Is there = a way to inculcate such features into senML or is there a way around = this that I have overlooked?
 
 
 
Mit freundlichen = Gr=C3=BC=C3=9Fen
 

i. A. M.Sc. Shantanoo Desai

Wissenschaftlicher Mitarbeiter
 
BIBA - Bremer Institut f=C3=BCr = Produktion und Logistik GmbH
 
Informations- und = kommunikationstechnische Anwendungen in der Produktion
Prof. Dr.-Ing. Klaus-Dieter Thoben
 
Raum 1390
Tel: +49 (0)421 218-50138
Handy: +49 162 6536 107
des@biba.uni-bremen.de
 
 
BIBA =E2=80=93 = Bremer Institut f=C3=BCr Produktion und Logistik GmbH
Postanschrift: Postfach P.O.B. 33 = 05 60 =C2=B7 D-28335 Bremen / Germany
Gesch=C3=A4ftssi= tz: Hochschulring 20 =C2=B7 D-28359 Bremen / Germany
USt-ID: DE814890109 = Amtsgericht Bremen HRB 24505 HB
Tel: +49 = (0)421/218-02  Fax: +49 (0)421/218-50031
E-Mail: info@biba.uni-bremen.de =C2=B7 Internet: www.biba.uni-bremen.de
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr.-Ing. K.-D. Thoben, O. = Simon
 
 
<image001.png><oledata.mso>_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_381CF3B9-99B3-4E07-973A-12B86CCC9DC6-- From nobody Wed Nov 7 10:57:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE1C130DC8 for ; Wed, 7 Nov 2018 10:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 YOYc66mraHA1 for ; Wed, 7 Nov 2018 10:57:11 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70130.outbound.protection.outlook.com [40.107.7.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62A4130934 for ; Wed, 7 Nov 2018 10:57:10 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=OI6vyIMpwbCnT2Kjc3HzeJMguxt+UysAzR0RzLBsmRQ=; b=b51rXRIBeLGDMYy2JJAknuiOHKhk8vys/BRf88153MDHSEksGg+sFH42QuUqHrHQhz08GHVCa53UHtqNdfaIqTp2wjhXR0JvUWtxPbRWGQsn76aUvq5FqsMOyty1Wx2Q8mg9b76b4x86foDNGP6+nse9/eIzinmNojuhlPiabnU= Received: from DB7PR07MB4933.eurprd07.prod.outlook.com (20.177.192.210) by DB7PR07MB4854.eurprd07.prod.outlook.com (20.177.123.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.28; Wed, 7 Nov 2018 18:57:07 +0000 Received: from DB7PR07MB4933.eurprd07.prod.outlook.com ([fe80::48b2:dd97:dce2:ca20]) by DB7PR07MB4933.eurprd07.prod.outlook.com ([fe80::48b2:dd97:dce2:ca20%3]) with mapi id 15.20.1294.034; Wed, 7 Nov 2018 18:57:07 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Klaus Hartke CC: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] Review of draft-ietf-core-multipart-ct-02 Thread-Index: AQHUcHf46zhgh8nfgU+ep4XF1bdRj6VAv1qAgAFeRu2AAiubgIAAbN2d Date: Wed, 7 Nov 2018 18:57:07 +0000 Message-ID: References: <20181030174246.GA6420@nokia.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [43.249.105.152] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB4854; 6:oDPk+fPDyIZqSKBpByQ72yjoS30YH3JCmSjOvP/V3PvBjvvyqyh3uzPj9cl0TAr/CTgK6uLuUugHMskLB3W8SRizLtaHnEAdU8vRUJnaNfrUigLqKQrRZeMKIva7qUY/AzU02ZPOsfOBMjqpTiZhA0h0Q3oANXzfj3fmzzq8eGvlc2h22igmz1HqhHoWdI2ftxKVweAGh0DIPzhmnE6KLWS4VLDjr2bWuT+1Y0/TH9MrZW0SXTQLU74C7l1YajunS3Xmkuowf42iAuTqwFdAlhSJsrDnz+BAsPsbVSpQO3kM+5Qmg4Zvj+DN/ow3c2iAvqui/u/pP/M6IkPZmN40d0VAz9zNUvhsdy68p17tB8LikZnUeBYLZ2s9QIi5iyuq8rAu2mtcS4KOxCJMAhEKJ4AOuEFetk25uDlwBR0wb7NyWUSisZ9tlyU5vd8hmeryifMq8zUmve2/yvAIWhU9Gw==; 5:nO1drRR6UrpvOoce2u3H9v1hXXm8hm+npLyUhR18/nd+1sBQIkTcVYeFztIgtukm2qHkChi43evlTQ2kkAOQhOEWLPVN1JJ5sQAUJHZWeo4ZB9aY5caEgXJWW42fbTS7QupocbDinDVPmyjB9IoN9tIJr1BwXw+vHLhPINhTymw=; 7:f2DoBx1qUfTlYNDznG33Tfcq6RAuIvINPNser5+nCaQziCEGtEvwh3wbFH2qzGrVQ25sg6dlYka3b9O3EYmsLvCwjTsMTKr2hqnVaHgfw1k5ychokkxUN0EoTnBjzozOJWV68axdigrafGJCthuw/Q== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2bda23c1-5fee-4411-cca9-08d644e2d0df x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7167020)(7193020); SRVR:DB7PR07MB4854; x-ms-traffictypediagnostic: DB7PR07MB4854: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(131327999870524); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4854; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4854; x-forefront-prvs: 08497C3D99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(346002)(39860400002)(136003)(54094003)(199004)(189003)(53936002)(14454004)(97736004)(478600001)(106356001)(105586002)(74316002)(6436002)(7736002)(6916009)(25786009)(305945005)(55016002)(8676002)(71200400001)(8936002)(81166006)(81156014)(71190400001)(2900100001)(9686003)(2906002)(476003)(446003)(186003)(6346003)(26005)(11346002)(486006)(4326008)(6116002)(33656002)(93886005)(54906003)(66066001)(316002)(256004)(5024004)(5660300001)(7696005)(86362001)(76176011)(6246003)(99286004)(3846002)(6506007)(55236004)(229853002)(68736007)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4854; H:DB7PR07MB4933.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-message-info: K5eBP7G9z+WKt3sQpzszypR8gu2IDWvIdjZcOR45YN4cy3s8qdqxWKzxqh7FLkRS6fpi1mAC9Q75H2ftcnPAHOFn/kvgF9mOGWrH1XSna42xbh6FUkkyHVenD1IUbTGmAmol0Pgflpd8bj9VT5pZ3WlfqUjWFmcqnRI11812ujugWE64nLz4BulZgd9o7JOkXkLsEdB7XucTJ2qbIWUItG/uOZX9GrXIYeX7RyKUhYxx8GuNoTGpbKR/AL6DzFfEoIYZG8eXTyGChz9Zgq5/+187MvmK4gedG3frpsoUynNDgi7LpMw2TlDtzpZsOeUHG7GYLnTEKeIx6EntmTcgkQrrWpv9TFg8dyY/oMVl6U4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2bda23c1-5fee-4411-cca9-08d644e2d0df X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 18:57:07.5568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4854 Archived-At: Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 18:57:13 -0000 Hi Klaus, > I think the draft needs to be much clearer on whether a multipart > collection is an unordered multiset of representations (which I had > assumed so far) or an ordered sequence where applications attach > additional out-of-band meaning to the positions. The word multiset got me confused. In my mind a multiset is a set of (repeatable) elements of the same type. What do you mean by "unordered multiset" exactly? The way I intend multipart-ct, and I think this is also how it's described in the current draft, is the latter -- i.e. a sequence of=20 fields each with its own type. > Speaking of additional out-of-band meaning, I wonder if there should > be identifiers in the collection explicitly describing the semantics > in the interest of self-description. (see below) > There are also considerations related to evolving the out-of-band > information, such as when an application wants to change the meaning > of a position but continue using the "application/multipart-core" > content format ID. Maybe this an example of where the suggestion about freezing a given multipart-ct into its own content-format comes in handy. If you want to change the semantics, you just give it a different c-f. At this time I wouldn't go down the road of defining a full blown=20 container format with all the bells and whistles. I'd like to see what we can achieve with this minimalist framework in the first place and if experience teaches us it's not fit for purpose, we can always make it=20 better in a future iteration. Cheers!= From nobody Wed Nov 7 23:18:16 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EB5130DC2 for ; Wed, 7 Nov 2018 23:18:14 -0800 (PST) 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] 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 NJha7aYJbPBP for ; Wed, 7 Nov 2018 23:18:12 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892601294D7 for ; Wed, 7 Nov 2018 23:18:12 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id E889C41F27; Thu, 8 Nov 2018 08:18:06 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4F5696B; Thu, 8 Nov 2018 08:18:05 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id EF7372E; Thu, 8 Nov 2018 08:18:04 +0100 (CET) Received: (nullmailer pid 4708 invoked by uid 1000); Thu, 08 Nov 2018 07:18:04 -0000 Date: Thu, 8 Nov 2018 08:18:04 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Cc: Shantanoo Desai , "fluffy@cisco.com" , "core@ietf.org" Message-ID: <20181108071803.GA4264@hephaistos.amsuess.com> References: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] [SenML] Multiple values in a measurement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 07:18:15 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 07, 2018 at 09:38:01AM -0800, Michael Koster wrote: > Or as an IPSO Smart Object representationfor the accelerometer object typ= e (3313): >=20 > [ > { > "bn": "3313/0/", > "n": "5701", > "vs": "rad/s", > }, careful here: bn+n needs to be globally unique and can't rely on its retrieval URI to disambiguate. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvj4yUACgkQOY0REtOk veFksRAAugTSz+zrTv2rap3Tpl1EHsL98Rp7YHYz+j5aPxQm5t0/wZNZdX/uH3W1 jgJbLcuvImDHk4tL1cmHprpekQsPSkDqRMIZRK9M0Rpe8WA3VEdLYwCrjty+7dia ngL6ULj1IP2f3hsDFrVcLe90CsKjW+a2oLgslWdugZpm51UigEmgaLUvoYw9V83f 38Dxba33x36ykWvG6FXn6Y3xavhXOTgR0e9MWga0z+KXkvOxl/RmYnbwT45VpwMj RI3ciG2jlarNV8HSSAwIFIMMVkTXB8SVTMmskGQpW9boGeiaQC3hPrSeyT38SjiD bhkkym2l0qxDelwW84ikCkznAG9D9aH8fj2cY6SHE1PwYF1B2+B2dwXPAk2Y/23X WBy3q+JArjTVz4Q61fCIJZ40bRlJDBXQ3NRnWsEMN5T4hHf+cFpmgngdNpCyTHwC cGtAns51cD2MRMfeiE7vbLxC31inKC6g09x0bTM1E8qfIkVvweZ1MsbC+1X1c8QS 1dYijE734nncAfUXdc8R8q1oUESnSjQVU+RiA6+iwk0xoflrJOc6NJInm0St12Lo TnhXpCIZojMHUVV5Qs1jI0OWN30whq/HEiloDHOeQ1pN7QUS096Q46DL7IYwgZcm f9tNgMSLX1C1pJ1Q8a1XJLqhC8d+lUpiTZuR7ilOaHEr+4CnWEM= =4zxF -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From nobody Thu Nov 8 00:31:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245E1130E90 for ; Thu, 8 Nov 2018 00:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=J8MGzuLe; dkim=pass (1024-bit key) header.d=ericsson.com header.b=K6I3JfXo 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 05UDNS5Xcf1x for ; Thu, 8 Nov 2018 00:31:05 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 25EFC130E6E for ; Thu, 8 Nov 2018 00:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541665863; x=1544257863; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MJ9CNFmvKBE9mYmZLIHmsGB/6PxpwGIaH4ELJ+DklIw=; b=J8MGzuLeDgDgBLfu3YE+fh/ATa1Mb/0jM9X3P1mRmBiRGAdXtl+ETgMGo6UkrjWL rUPv09XiuWJzKMqJV8N1KMZ9ehdTO0XucMG7hhoZJ/oDeCf8LF3co5zhFlOvTG7g y4nL+f8QWiuHo3qgfaUIGsb+vE9MQSVYxiTbtsZOxV4=; X-AuditID: c1b4fb2d-f61ff70000007af1-bc-5be3f44751a3 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 04.1D.31473.744F3EB5; Thu, 8 Nov 2018 09:31:03 +0100 (CET) Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 8 Nov 2018 09:31:02 +0100 Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 8 Nov 2018 09:31:02 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 8 Nov 2018 09:31:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0rwM/y314pXkP8JLG68ihatR4B3YGAoU/crwgJ5ZDDY=; b=K6I3JfXoUMaxqvArg/QfsVG3ZZkRXVcBq/ObzrHqVxKcx0XAb6kpTkl7Kwp71yud1qgRdGsZ79ZGsDAo7vjkDM/K1RmCj5MR0CMQtWHLt6H22aLwS+1vqb0knf6yuPLz5N/J0AjNc+PXGaPUFWAdEHxIC54PNP7PXxYucFCH+2U= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB3499.eurprd07.prod.outlook.com (10.170.247.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Thu, 8 Nov 2018 08:31:01 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95%3]) with mapi id 15.20.1294.034; Thu, 8 Nov 2018 08:31:01 +0000 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: Shantanoo Desai CC: Michael Koster , "fluffy@cisco.com" , "core@ietf.org" Thread-Topic: [core] [SenML] Multiple values in a measurement Thread-Index: AdRmu1O0gVkxiXhNQCmF42kugckttw== Date: Thu, 8 Nov 2018 08:31:00 +0000 Message-ID: References: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3499; 6:Ax4rnlaUTTeon/nlh3Q29pKWcY2Dt65HxxAAqVv9z6GNS0+aekdj95/PhY8PigVKC5JLVQ9pZ2o1QAkFxkwZFW0nyBMKU60t9xKVNljV+olBEchqcvQZr3zOe/RrNf8Z10DTOG43+gQrmdG3ZeQEkJ3u+zQg5bk349eaEJc+iRn4tZfOQi7w05mctgyM/W+vP/Cqnkg+UnkciQGN0NVDj9YZL2Wpe8DiGEl1MyjJ4P/7EEQ2l8mfy4xHux+zawvCOoO8VxE7qKWCIK/omkNqyFUjm5WFRyZf/57qi083Y+nqNxd20AAwranJ1gqEuxwIEWYsQzky8rIcM/aFp9Lt6pyKhI1fTPLmyfugSlg7CMGmnCZcCaFQ3nBxXF2ypYfOhNeN8tbxw+iAsPP5eOqEefhssTRgOJRKM4GQ+GPtl3VBTee4gObWQbAZtaceIyHVzuJbusHZqZT2MyptU9DJeQ==; 5:xaGNu4HoH34SCD8Tajxsoas97hpj0FUuW+b3K28zAS6xw2DXXMBvjgnjpvO0YMDR2gPbZ/hzMlawXQDcyiNfgSeZxscxSoOW1B4fC+MoGXDDXC0MqcJGCt2dOBBusZKtOxGaWZtZXujiHZ5tXIRWFRiJsHdGvZKp9vYxmZBEmK4=; 7:1uVMG2tYYUHOoZMrlkHyk5fpRolj2X/+OwwNNRkl1I7Wh0KHZFkEJqRPKw0D5I7H72R0JG3Bv0IrPrHDPDHph2nfQiqChFQzDbCXmzMA+DLAemhPuxS8U+6NW/pCpkhXnrVXYwu+FnLYcp6S42YTaw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 011d9a27-1071-4324-c1ca-08d6455483cf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3499; x-ms-traffictypediagnostic: HE1PR07MB3499: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(128460861657000)(81160342030619)(38017032943787)(86561027422486)(64217206974132)(91638250987450)(254730959083279); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231382)(944501410)(52105095)(10201501046)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3499; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3499; x-forefront-prvs: 0850800A29 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(376002)(396003)(366004)(53754006)(189003)(199004)(55016002)(6306002)(7696005)(8676002)(305945005)(8936002)(81156014)(81166006)(6246003)(966005)(7736002)(53936002)(14454004)(6436002)(99286004)(74316002)(33656002)(86362001)(478600001)(186003)(486006)(9686003)(476003)(446003)(6506007)(53546011)(71200400001)(71190400001)(39060400002)(76176011)(66574009)(26005)(229853002)(4326008)(68736007)(25786009)(97736004)(102836004)(6916009)(6116002)(2900100001)(3846002)(66066001)(316002)(105586002)(54906003)(106356001)(5660300001)(14444005)(256004)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3499; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: czlAWMbwIpSsLNIYF5OFR4GlatgOjCr73YdorAmdTrlwJzYsXaVIBPgOk/xQqDoaanxxRKTLwVQngHfNQ91D28E2DmmpU+oBpsjCI/5NQl0RHRs1rAIQ5J6FQoKapjei6N/2doU56jCMrSfHWSKSnyqLvky0R7aggXpUq2+/+3ioXuCCWfmI1YHBvSyGn6/6dtIMbKdRgAvesyOkdjxmMU1YVSSSBtl3kp51PkBaK+zsx0B23A6Dq74cyu+1a7jgNGUReIVVF8Jxag9P9niuI4nwNioQIl/EuOMnxHMigWCwDIl/mKY9GOMQFzIcOtDfi1mXfg6POPuQwvK3vgKxxRaEa9CFkOI76Vv4zQgWmhM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 011d9a27-1071-4324-c1ca-08d6455483cf X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2018 08:31:00.8502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3499 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGO7t3d9fR4miab1qCy4KsmZbQKDNHUPujSKSgNNClFxV12r0m KhGjMHMq+LElE3OWw0rNUFeztA+HJRpqWqkMRIdiH7ZSTPoQNLc7of9+7/M85znvgUMTXgah H52qzmZYtSpdSolJwzlLruzEz+m40NVSSv7C8YiQX58dFMhvVlLyW4VDoihSWWJ2UErdcqtQ +bR6QqQ0mf4IoslYcUQSk56aw7D7IhPEKZrht1SWOSC3ufeBSIP0W7WIpgGHQ3VDtBaJaS/c g6B79aWIH5YQ6BfqhVrkwQ+fXit4o14A92daXCkSlxEwZp5CvKMTQEVhnYAf7AgqTe2U8zyF FdBvf+jq8sZ7wVxQgpyXEzgfarXHnPJmHAHmzgrCKXvjI1C+wPLpECh4YxA4mcRBoJ91EE6W 4AvwfqDWvaoGQUF7iyuE8Bb41d/sYgL7gm3G6GLAGExdQwTPPvBlekXI5+Pga3+fiNcDYeC7 3Z3fDiPGYtfDAI9SoBm2CnlDBvN6vbvoFIyOFZF8qBfBq9tN7tPBcG+y2N2aBkMfVwk+VINg omO9KQAaS+1kGQqr/m9bnkPhx6CR4HkPNNyZc7EEe0KfYYasQ2Qj8uEYjstI3n8ghGFTEzku Ux2iZrLb0NqH6TYvyzpQ05zCijCNpBsl2DEd5yVU5XB5GVYENCH1llTNr0mSJFVePsNmxrOX 0xnOivxpUuorCWnsivXCyapsJo1hshh23RXQHn4ahNpitB6jsjMHbU+epa+c97PUJimqEh7b o8ZKl2vCExXK9vIU8BQuTi5uqLWEv7McNV7ddnjH6eK7rUu6IntgpLRr9vN4xZWdJ3Nu9Ei1 i9+mLdcOxQf753R6/t6VFaMbed4cVLbJNG47vjuxfe6vtvLSWbWPzvRhOb7SNnWRYo1SkktR hQUTLKf6BzOmLwcsAwAA Archived-At: Subject: Re: [core] [SenML] Multiple values in a measurement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 08:31:10 -0000 Also probably worth noting that if you have more thank one set of =0A= triples in a single SenML Pack, you can link them together using the =0A= time field.=0A= =0A= =0A= Cheers,=0A= Ari=0A= =0A= On 08/11/2018 0.38, Michael Koster wrote:=0A= > Here is one possibility:=0A= > =0A= > [=0A= > =A0 {=0A= > =A0 =A0 "bn": "inertialmeasurement",=0A= > =A0 =A0 "bu": "rad/s",=0A= > =A0 =A0 "n": "xvalue",=0A= > =A0 =A0 "v": 0.34,=0A= > =A0 },=0A= > =A0 {=0A= > =A0 =A0 "n": "yvalue",=0A= > =A0 =A0 "v": 1.43,=0A= > =A0 },=0A= > =A0 {=0A= > =A0 =A0 "n": "zvalue",=0A= > =A0 =A0 "v": 0.23,=0A= > =A0 }=0A= > ]=0A= > =0A= > Or as an IPSO Smart Object representationfor the accelerometer object =0A= > type (3313):=0A= > =0A= > [=0A= > =A0 {=0A= > =A0 =A0 "bn": "3313/0/",=0A= > =A0 =A0 "n": "5701",=0A= > =A0 =A0 "vs": "rad/s",=0A= > =A0 },=0A= > =A0 {=0A= > =A0 =A0 "n": "5702",=0A= > =A0 =A0 "v": 0.34=0A= > =A0},=0A= > =A0 {=0A= > =A0 =A0 "n": "5703",=0A= > =A0 =A0 "v": 0.34=0A= > =A0},=0A= > =A0 {=0A= > =A0 =A0 "n": "5704",=0A= > =A0 =A0 "v": 0.34=0A= > =A0}=0A= > ]=0A= > =0A= > =0A= > On Oct 18, 2018, at 1:35 AM, Shantanoo Desai > wrote:=0A= >>=0A= >> Hello all,=0A= >> In a practical scenario there are sensors that provide more than one =0A= >> values, for e.g., an Inertial Measurement Unit (IMU) will provide =0A= >> Euler Angles as Yaw, Pitch, Roll indicating orientation of the sensor = =0A= >> node or an Accelerometer which measures linear acceleration in X, Y, Z = =0A= >> directions.=0A= >> Is there any schematic in SenML that would support multiple values?=0A= >> From my understanding there is none and most values are indicated by =0A= >> the field =93v=94 as a single key:value pair in JSON.=0A= >> =0A= >> Even if I split the reading into three, there might not be clear =0A= >> distinction since =93n=94 always remains the same (the sensor name is = =0A= >> always =93inertialmeasurement=94)=0A= >> =0A= >> Is there a way to inculcate such features into senML or is there a way = =0A= >> around this that I have overlooked?=0A= >> Mit freundlichen Gr=FC=DFen=0A= >>=0A= >> __=0A= >>=0A= >> *i.=A0A. M.Sc. Shantanoo Desai***=0A= >>=0A= >> Wissenschaftlicher Mitarbeiter=0A= >> *BIBA**- Bremer Institut f=FCr Produktion und Logistik GmbH*=0A= >> Informations- und kommunikationstechnische Anwendungen in der Produktion= =0A= >> Prof. Dr.-Ing. Klaus-Dieter Thoben=0A= >> Raum 1390=0A= >> Tel: +49 (0)421 218-50138=0A= >> Handy: +49 162 6536 107=0A= >> des@biba.uni-bremen.de =0A= >> =0A= >> =0A= >> =0A= >> =0A= >> =0A= >> BIBA =96 Bremer Institut f=FCr Produktion und Logistik GmbH=0A= >> Postanschrift: Postfach P.O.B. 33 05 60 =B7=A0D-28335 Bremen / Germany= =0A= >> Gesch=E4ftssitz: Hochschulring 20 =B7 D-28359 Bremen / Germany=0A= >> USt-ID:=A0DE814890109 Amtsgericht Bremen HRB 24505 HB=0A= >> Tel: +49 (0)421/218-02 =A0Fax: +49 (0)421/218-50031=0A= >> E-Mail:info@biba.uni-bremen.de =0A= >> =B7=A0Internet:www.biba.uni-bremen.de = =0A= >> =0A= >> Gesch=E4ftsf=FChrer: Prof. Dr.-Ing. K.-D. Thoben, O. Simon=0A= >>=0A= >> _____________________________________________= __=0A= >> core mailing list=0A= >> core@ietf.org =0A= >> https://www.ietf.org/mailman/listinfo/core=0A= > =0A= From nobody Thu Nov 8 03:31:09 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16609126BED for ; Thu, 8 Nov 2018 03:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkcUyPhGNzkc for ; Thu, 8 Nov 2018 03:31:07 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F180123FFD for ; Thu, 8 Nov 2018 03:31:07 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 34D4F41F32; Thu, 8 Nov 2018 12:31:05 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 50FD56B; Thu, 8 Nov 2018 12:31:04 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id EE7E52E; Thu, 8 Nov 2018 12:31:03 +0100 (CET) Received: (nullmailer pid 30229 invoked by uid 1000); Thu, 08 Nov 2018 11:31:03 -0000 Date: Thu, 8 Nov 2018 12:31:03 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Klaus Hartke Cc: "core@ietf.org WG" Message-ID: <20181108113103.GB13498@hephaistos.amsuess.com> References: <20181105123604.GA9680@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:31:09 -0000 --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 06, 2018 at 09:21:36AM +0100, Klaus Hartke wrote: > Of course, we could for new link target attributes, as they pop up, > define an equivalent more semantic link relation type. In Link Format > you would use the link target attribute; in CoRAL, the link relation > type. If a converter encounters a new, unknown attribute, it would fail. It just occurred to me that there is another point to be made for per-relation rules: There are target attributes that are URI-valued. That's something I'd recommend to avoid in the first place, but still does happen (eg. ol=3D in protocol-negotiation, or even base=3D in RD which I can't really rip up now). It's a trade-off, though: While making the resulting data semantically more palatable, it makes link filtering odder (a `GET /.well-known/core?ol=3Dcoap://x/` CoRAL response one'd need to think `GET /.w-k/c?anchor=3Dcoap://x/&rel=3Dattr:ol`). I still think it's worth it (speaking as someone who'll have to implement the lookups). Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvkHnQACgkQOY0REtOk veHiRA/9FouoSHnD/u1gD2oLxBctpm8719n4WfJe58EnvphsYOckl70MTe9vWwYb 0yMWJzoVscXW7Uhzj41OUVXP4nggXErEqvPyQb+vkA7ZHe3FN6oG8J4Fl0l74ZJz 0hSx1hHH+QQsE2jzTHgjXkC7RZJ36+kIHwESKXnCbEE8p2VErf3EoEmD4ps83FV1 EYnbeIYTzJ0X3Fhk2p17P1lnE96TjJG1qsKe3bqQeDpWH/bzpiZRYSwSLfa0w1FP rBnmG/XefS/3WfYbr/vg5Lj8UN+Hs82dheyJtcun1wmFLKhunPaclCGOeWO0S8iq dJoEQM4Klz6yEGwl+oX9lgRxJoYoYiGz2lKEYdd/oSunp51pXV1+0l/v0QyYHsiH AmxcetL/JaF/bx2pGOMd8Ljc5+P6Kcll0M5DBjt+iH6/fMf8y7HM3MVyw8DyZowP Kmm80QxuJi1XSYSMUVV8v5Pw8S4J5sqxLcgSHOjDVCUf9g69CYyCrl3I6Zd8ZfYz 83PNMAFE/MhcDa3FKxEXYBfWagfwqcG3IVKxqO+q6q1X2wEtYhIdme6M/lV7gQcA i+MIlL31qeGJlAAv7eUJbK7mlKXrO97egLjiJTDPlkc+agS6Uef2bO7DRERkc6Zd AZjpK68/aGApqcp1QSMSaUXpduzoZcIVZ+esxBG3VfovzZ2w5l4= =AyEv -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V-- From nobody Thu Nov 8 06:29:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BA8128CF2 for ; Thu, 8 Nov 2018 06:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_Qs2YPeg8UK for ; Thu, 8 Nov 2018 06:29:29 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 9F2EF126CB6 for ; Thu, 8 Nov 2018 06:29:29 -0800 (PST) Received: from mail-qk1-f179.google.com ([209.85.222.179]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gKlJH-0004uE-1Q; Thu, 08 Nov 2018 15:29:27 +0100 Received: by mail-qk1-f179.google.com with SMTP id m5so3024003qka.9 for ; Thu, 08 Nov 2018 06:29:26 -0800 (PST) X-Gm-Message-State: AGRZ1gJyJw2RR1eg1FEvjLyuAAk4Jf1/ryTVdFiz9ic0boSeWR82wW8A 1T2EWjrKj7n5uYUrYcaSvGg3ryd/rym9+nS/wMg= X-Google-Smtp-Source: AJdET5cQYdYNl4JsFSOjVic8ctvHn2/H1xlEFrkcl7BCqF5kOn39/N2ve5BdI8fq7AG6kEHynCpCmNAhvf0O9jMKEQg= X-Received: by 2002:ac8:16d8:: with SMTP id y24mr4594107qtk.253.1541687365910; Thu, 08 Nov 2018 06:29:25 -0800 (PST) MIME-Version: 1.0 References: <20181105123604.GA9680@hephaistos.amsuess.com> <20181108113103.GB13498@hephaistos.amsuess.com> In-Reply-To: <20181108113103.GB13498@hephaistos.amsuess.com> From: Klaus Hartke Date: Thu, 8 Nov 2018 15:28:48 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541687369; fa14b81d; X-HE-SMSGID: 1gKlJH-0004uE-1Q Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 14:29:31 -0000 Christian Ams=C3=BCss wrote: > It's a trade-off, though: While making the resulting data semantically > more palatable, it makes link filtering odder (a `GET > /.well-known/core?ol=3Dcoap://x/` CoRAL response one'd need to > think `GET /.w-k/c?anchor=3Dcoap://x/&rel=3Dattr:ol`). I still think it's > worth it (speaking as someone who'll have to implement the lookups). The lookup interface is indeed an interesting topic. I would assume that ?anchor=3Dcoap://x/&rel=3Dattr:foobar selects all links with the link context and link relation type (using attr =3D ). But I think you want to select all links where there is a nested link with the link relation type and link target . My idea would be to use CoRAL to express this: FETCH /.well-known/core Content-Format: text/coral #using iana =3D #using attr =3D iana:hosts _ { attr:foobar } Klaus From nobody Thu Nov 8 06:45:57 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7B112872C; Thu, 8 Nov 2018 06:45:54 -0800 (PST) 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] 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 cLC42rOq4JT4; Thu, 8 Nov 2018 06:45:52 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4B3126CB6; Thu, 8 Nov 2018 06:45:51 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DCDBB41F32; Thu, 8 Nov 2018 15:45:49 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C54A86B; Thu, 8 Nov 2018 15:45:48 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6F6572E; Thu, 8 Nov 2018 15:45:48 +0100 (CET) Received: (nullmailer pid 20479 invoked by uid 1000); Thu, 08 Nov 2018 14:45:48 -0000 Date: Thu, 8 Nov 2018 15:45:48 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-hartke-t2trg-coral@ietf.org Cc: core@ietf.org Message-ID: <20181108144547.GA26534@hephaistos.amsuess.com> References: <20181031164534.GA4995@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20181031164534.GA4995@hephaistos.amsuess.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Review of CoRAL X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 14:45:55 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Klaus, some more points came up pushing forward my implementation: * On "Why are there bare-words as relation strings": During refactoring[1], I found why I had that -- the append-rel path type seemed to indicate that the rel should be something usable here. Now the code in the draft is a bit vague here (`format(relation, "x")`), and there's no text on it yet. Any ideas yet on how I'd come from a URI to an appendable string (like uri_to_rel(x) =3D rightmost substring of x where x in [a-zA-Z.0-9-])? Will it be sufficent on a constrained device that has hardcoded knowledge of what the URIs mean to only store uri_to_rel(rel_number_to_uri(n)) for all n in the supported profiles? * current base IRI: Current base IRI keeps being updated to current context IRIs. That is a good idea in terms of compact representations, but means that local references can not be expressed "deep in there". Say I want to say that " is described by , where has author , change log at <...> *and is also available at *" (like a local cached version). By the time I talk about the thing at example.com, my context and current base URI is http://example.com/..., and I can't say any more meaning a local resource. (Note that this is a bit of a similar situation as with RFC6690, but sans all the confusion.) In this very example, one could work around by saying that "is also available at" is symmetric, so one could instead say "Furthermore, is also available at ", which would be another toplevel link, but it means that a *generic* link-format document can not necessarily be expressed easily. I have no concrete proposal of how this could be done better. One idea is to allow expressing "rev" and not only "rel", but have not thought through whether this solves the issue completely at all. Best regards, and sorry for the somewhat chaotic way in which my observations and questions arrive Christian [1] which has led to micrurus to be what I believe to be correct again, not only w/rt flat CIRIs, but also with base URI changes and delta-compressed relation numbers --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvkTBgACgkQOY0REtOk veHtGw//dqHSzUvvtVftRjQvZN5sC3D5Uz8i9hj05MVB6sGKXaH3uZNV3ZvUclvu E5Sv5i4DSLJsnaw6RTDSnIAMQUYIiwJ3CzOCd/8zsxGz8UaRqJCfIRgAp/8ZwYbr kW/h07QjnxJ1zeKN0OF4Pn9NRCvqhXHIIYEiIdWiBLvZ7G6mh1J90iYOytkttdUs 4Y0Sx+BNZnAPWirDQEH4/q0/JOLlkGxh7DSoFfR3gn6Z0koMoz2Y8rXq/F8d21w2 /u3ChtdgzRj4Elk3FEVpBHyVHjaFustJgjbLyNkg2wI/+nQhZvFh46TzBXzMch7I LlwPIbwuYQywDrOMZ6OmIIjQw/j0Vxds74/WrdYYofHLL72p8UZH8kmUPOzwp5ix 23HMiZLWeZ7TBnNQYVbu/tXG9A6pY1AdVV++d/3gHy0DR1kY7558nT+v9Xucas4L xKE0hpjHjKtVwvWcWZuzvtZ956HjEwLqP9c+6+g25qy1IkmtOjmEW22tny2SY8Qs Wj6z457M/Qpbw+8DYU4A+hhE75bVNfkQGbMPBK3LjbHKbNa2BCo2TfP5M9kwMUCp lLQ/ha6Os0ohSyAcuVOV20cg0gzt8cAOhCDlIdjmf6zvvAqRmBb8GvSDFHHEAS1U 04hiHirBYz9ixKZp2PLHn1A6UGjPJAlyVLKbNGCJ3YdstxR2rTM= =7XI4 -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From nobody Thu Nov 8 06:55:26 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC93128BCC for ; Thu, 8 Nov 2018 06:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYg6d7nRZ9AN for ; Thu, 8 Nov 2018 06:55:22 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE82F12872C for ; Thu, 8 Nov 2018 06:55:22 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id BB00D41F32; Thu, 8 Nov 2018 15:55:20 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 028C26B; Thu, 8 Nov 2018 15:55:20 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AFE682E; Thu, 8 Nov 2018 15:55:19 +0100 (CET) Received: (nullmailer pid 21192 invoked by uid 1000); Thu, 08 Nov 2018 14:55:19 -0000 Date: Thu, 8 Nov 2018 15:55:19 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Klaus Hartke Cc: "core@ietf.org WG" Message-ID: <20181108145518.GC13498@hephaistos.amsuess.com> References: <20181105123604.GA9680@hephaistos.amsuess.com> <20181108113103.GB13498@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 14:55:25 -0000 --mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 08, 2018 at 03:28:48PM +0100, Klaus Hartke wrote: > I would assume that ?anchor=3Dcoap://x/&rel=3Dattr:foobar selects all > links with the link context and link relation type > (using attr =3D ). Yes, that's what it means. It's just that once we consider expressing URI-string-valued target attributes as CoRAL IRIs, as in hosts { attr:sz "1024", attr:ol } then the line between attributes and relations gets blurred (Is it a link? Is it an attribute? Why was it not expressed as a link in the first place?) to the point that it affects query filtering[1]. Two reason why this still does not make me say "nah, let's have them as string literals then" is that a) I'm an RDF afficionado, and b) whoever does filtering already needs to know the semantics of the field, or would fail to make ?rt=3Dx match ;rt=3D"x y". > My idea would be to use CoRAL to express this: >=20 > FETCH /.well-known/core A CoRAL fetch format ... and I was afraid suggesting this would be way over the top :-). I'm looking forward to this (hopefully in a shorter time frame than SenML-adoption-to-SenmL-fetch), but right now it's probably too early for it. Christian [1] I'm speaking of .well-known/core query filtering and not of RD lookup filtering because the latter is an extension of the former. --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvkTlYACgkQOY0REtOk veHqnBAAqMvoWE5arivRWAr61cvzXRwZiEgtR/TzXyvY5tsI4HT+EZvMY9pOOxzt LELOjmQWAUY3NRC0zZH+UtGqMIG9s1yQqfo+z/dcpS8w/f5LxNtlt1ntKfcWTu+s U8ATROIwhzVrHXqjw9Gpq7tW62D0+B1x3yDMTsWKTcVgqEPoNDZdKAc7W22R4clu O6q3yri4Hij6pPQvXol+onJ81wom0b7DR9taTw8zw0tg7WAhpYz2Gfmnrqb5zi6R eJSa5VfxJW7vz8TD3johj4a2LP+n27A35aNcZeQY9L6aBIWgCbjVd/ydm44iz1PT L7dFUH1KJGPwfRj8FDBD7mLZEOg7AiyGOvZD4GPVGTrFjEzm4pRnrg5iFhUfqEUT 1Kh9u/B2043lnvh/hRzaOpYQVPK+ZLs5Wgj9brEqZriZj96dh3f1gs73C+ioQa+w 1jScpnuGWS0i8EaQcIQ1jgYJlLuYan8VP+YZvKNlKOOqXzxAazd+A3aymMnAgggy EpBinB0GZ05LuDnwYIusAagBqI2imzCphYiZyE2nxrOEGeXYiwxjVjqT9+/xb5wS FwFQ79DupwRcxvTmSFGWXrcTmfKwAQSgwhfV7TiYOOwAa118vLKIL+G1GsLvCo30 fvAsBZL1IXAOkQIvBb7wpikrvwuw+DEs8oqyj4gHoDNl7pPcGuU= =xY// -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x-- From nobody Thu Nov 8 10:17:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39512426A for ; Thu, 8 Nov 2018 10:17:47 -0800 (PST) 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 clloIA3Zl2Ev for ; Thu, 8 Nov 2018 10:17:45 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 E3BCB123FFD for ; Thu, 8 Nov 2018 10:17:44 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id k9so19011749otl.10 for ; Thu, 08 Nov 2018 10:17:44 -0800 (PST) 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=y00mvl4a9YqKMJUKlMTUvia57EKZkyrYmxoH2PXImKY=; b=OtPIysOxw88tQODvSlg7NL411nuI/2FydwYfuDzsJUyTgL8bZKYbV7VdegkpC/24v0 WTxuuUWRljywS62CoqAHBJUwXda2UrggTRTbgrj4nbMPv4T/C8TiE83wkHhShV3QmIbB caJnR/ioL+ONfpLyInI0OtyY0pXIb5Tgj+Z/WdGbVeOyvc8JdSSjONi7YDQH7fyHihyC JWn5dnHIP7/wW66rk+LuHs6cG/LRn/6tiXpEaHupMI6N0ty4N5OHPxsu5qbDgQZR/9+p 1QdnrrPaoEdVIH7IMfv2PGAjDh5jkeI02VdJ6dB4Jyjujdx5lVb7SY4pVIWyxQEUB2xb XZSw== 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=y00mvl4a9YqKMJUKlMTUvia57EKZkyrYmxoH2PXImKY=; b=ZxS38E9IktdaMeRqeQFMtYyBsHNfFj/m7o1tpv6T98/mMF7z/+r/O5zx3L4QHCGptb uynZv5WtSGH+iY+OZb5u7pDOXvVIqrX3lhC0M3wRzepZ1kWI7x6yj2KlZW5BWyEcmzli HLzEiTIdOEyz3gjf1Y8XlXQc3YvcqUIO1MYBIz+TRaY6MbUDY+szoTz+nzUw3EhPx7p6 XlmSMlkmzFBv4MQ9Nc2kZ4LJczf7UN6KPlZUkzDBe0xgSR14OhK5hxmqhC+AuIU9HFed K9/SW5wGKE3ap59oLzMqOSIQO0QufU1XDkFVoZisIKIK3XI3I/OplSpx8pkx7bWUiuRs 9eUQ== X-Gm-Message-State: AGRZ1gI0tVH/FO2Ub0fJbdkabc6hh6zf4TrnR0bo+HzGhHhNkKDIYaOY aMRD9a0mxVb/Tk/gSsFaLj4= X-Google-Smtp-Source: AJdET5fP6gBrF/ahpm1TB8KTcxgCKmPjkCLfOUKnmX4kZpQJFGLr/nrZLgJ9C/TCrC0sLpf4kCBbTQ== X-Received: by 2002:a9d:5249:: with SMTP id q9mr3290222otg.160.1541701064257; Thu, 08 Nov 2018 10:17:44 -0800 (PST) Received: from [10.0.0.3] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id y31sm2052007oty.78.2018.11.08.10.17.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 10:17:43 -0800 (PST) From: Michael Koster Message-Id: <993797F0-02BB-46C0-94C2-FD62C311635D@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_37B48A03-ACD0-46E3-8FAC-CAA6FF043461" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 8 Nov 2018 10:17:41 -0800 In-Reply-To: <20181108071803.GA4264@hephaistos.amsuess.com> Cc: Shantanoo Desai , "fluffy@cisco.com" , "core@ietf.org" To: =?utf-8?Q?Christian_Ams=C3=BCss?= References: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> <20181108071803.GA4264@hephaistos.amsuess.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [SenML] Multiple values in a measurement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 18:17:47 -0000 --Apple-Mail=_37B48A03-ACD0-46E3-8FAC-CAA6FF043461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christian, I don't believe RFC8428 places any normative constraints on the scope of = the identifiers that result from bn+n, either in section 4.5.1 names or = 4.6 resolved records.=20 It recommends URI or URN, which aren't required to resolve to exclusive = identifiers in any particular scope.=20 It seems like the word global is carefully avoided, and there is an = example that uses a local and possibly short-lived identifier scheme: [ {"bn":"2001:db8::2/","bt":1.320078429e+09, "n":"temperature","u":"Cel","v":25.2}, {"n":"humidity","u":"%RH","v":30}, {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3}, {"n":"humidity","u":"%RH","v":67} ] I other words, I think the concept of uniqueness needs to be allowed to = be defined in the context of use cases that may be outside the scope of = RFC8428 to limit. Specifically, I don't imagine there being a senML validator that would = check for the uniqueness of bn+n resolved names. I don't even know how = right offhand. What do the authors say? Best regards, Michael > On Nov 7, 2018, at 11:18 PM, Christian Ams=C3=BCss = wrote: >=20 > On Wed, Nov 07, 2018 at 09:38:01AM -0800, Michael Koster wrote: >> Or as an IPSO Smart Object representationfor the accelerometer object = type (3313): >>=20 >> [ >> { >> "bn": "3313/0/", >> "n": "5701", >> "vs": "rad/s", >> }, >=20 > careful here: bn+n needs to be globally unique and can't rely on its > retrieval URI to disambiguate. >=20 > Best regards > Christian >=20 > --=20 > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom --Apple-Mail=_37B48A03-ACD0-46E3-8FAC-CAA6FF043461 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Christian,

I don't believe RFC8428 places any normative constraints on = the scope of the identifiers that result from bn+n, either in section = 4.5.1 names or 4.6 resolved records. 

It recommends URI or URN, which aren't = required to resolve to exclusive identifiers in any particular = scope. 

It = seems like the word global is carefully avoided, and there is an example = that uses a local and possibly short-lived identifier scheme:

   [
     {"bn":"2001:db8::2/","bt":1.320078429e+09,
      "n":"temperature","u":"Cel","v":25.2},
     {"n":"humidity","u":"%RH","v":30},
     {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3},
     {"n":"humidity","u":"%RH","v":67}
   ]

I = other words, I think the concept of uniqueness needs to be allowed to be = defined in the context of use cases that may be outside the scope of = RFC8428 to limit.

Specifically, I don't imagine there being a senML validator = that would check for the uniqueness of bn+n resolved names. I don't even = know how right offhand.

What do the authors say?

Best regards,

Michael


On = Nov 7, 2018, at 11:18 PM, Christian Ams=C3=BCss <christian@amsuess.com> wrote:

On = Wed, Nov 07, 2018 at 09:38:01AM -0800, Michael Koster wrote:
Or as an IPSO Smart = Object representationfor the accelerometer object type (3313):

[
 {
=    "bn": "3313/0/",
   "n": = "5701",
   "vs": "rad/s",
=  },

careful here: bn+n = needs to be globally unique and can't rely on its
retrieval = URI to disambiguate.

Best regards
Christian

--
To = use raw power is to make yourself infinitely vulnerable to greater = powers.
 -- Bene Gesserit axiom

= --Apple-Mail=_37B48A03-ACD0-46E3-8FAC-CAA6FF043461-- From nobody Thu Nov 8 10:37:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0420512426A for ; Thu, 8 Nov 2018 10:37:22 -0800 (PST) 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] 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 nDQmRK-nUg9k for ; Thu, 8 Nov 2018 10:37:19 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4C313106B for ; Thu, 8 Nov 2018 10:37:19 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 71AB941F4B; Thu, 8 Nov 2018 19:37:17 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A27746B; Thu, 8 Nov 2018 19:37:16 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 75A802E; Thu, 8 Nov 2018 19:37:16 +0100 (CET) Received: (nullmailer pid 10078 invoked by uid 1000); Thu, 08 Nov 2018 18:37:16 -0000 Date: Thu, 8 Nov 2018 19:37:16 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Cc: Shantanoo Desai , "fluffy@cisco.com" , "core@ietf.org" Message-ID: <20181108183715.GB26534@hephaistos.amsuess.com> References: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> <20181108071803.GA4264@hephaistos.amsuess.com> <993797F0-02BB-46C0-94C2-FD62C311635D@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <993797F0-02BB-46C0-94C2-FD62C311635D@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] [SenML] Multiple values in a measurement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 18:37:22 -0000 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Michael, On Thu, Nov 08, 2018 at 10:17:41AM -0800, Michael Koster wrote: > I don't believe RFC8428 places any normative constraints on the scope > of the identifiers that result from bn+n, either in section 4.5.1 > names or 4.6 resolved records.=20 Quote: | Name: Name of the sensor or parameter. When appended to the Base | Name field, this must result in a globally unique identifier for | the resource. I'm not particularly fond of of that, but remember very clear reasoning =66rom the authors that having unique IDs in there is a stronger requirement than playing nice with URI references. > Specifically, I don't imagine there being a senML validator that would > check for the uniqueness of bn+n resolved names. I don't even know how > right offhand. I figure "We funnel data from all our devices into our Enterprise server whose database behaves like a concatenation of all SenML files" was one application. That'd get confused quite fast if different devices all reported their first accelerometer as "3313/0/". > What do the authors say? I'd be very happy to be told I'm wrong on this (it would allow more elegant core-interfaces), and look forward to a response from them. Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvkglgACgkQOY0REtOk veEkMxAAw4ZIAMBGvcYvycw0wMPsrXfxh7nk/sZ6eaT2vWe2zqdkPMsQL7fTD4Ix u5UZnXx1bxg5mL6fE29VqTTDKFgBynB5QefubOm5+boUqhnjFRv5f515keJCw7E2 PBF+YX2gvM61QRzapTZWQGa+4W2y8OsWAjHB1OuPgBEzr+XSAiUvXd+1pmdZlOwG qaGlfnVHXd0Pdkuk4yf1nxN9jOCPRd55Fnw1IxcFX/Ry5isCKpjrdc5oTYr24XF0 3gcv4vKi46Gn//ChiRkxf4a+a6pwHFDQkZlRF1nvWug20hD54SAdNr+QmndKcIXf 35DWyQzQbaYa8u8k2cu5poaI0kGcwFxZ9NwF5xq9iwhrgzeb+z9lC9o/WyiG7wQx wN5bay+YXiL9w5spysEuKVBaBr8FLLnaN09j17GbDlYpLFj5HQuWZRqvmJg+D4Q0 yG0dBYLvo1bgaBAAuLGN6sAu01gRPxm6MZRUhMBQg/1evsheI79ZBIFQW/qRVDqk HNfVfWCTXsKqMYrgT8szTIn3gYxO8irwQIwuQqQ5AXBbx9rCWz2TM1Spzn8rSXz/ b+k8hbR5+CvlS+5WL17AMwOt2yf2/Ggt8cr8Zxdp5BKOrolRNjo2rvkVNa++6Pc3 dqJfk/F51AagC9jfC/iK6EtRYp/r8ftxZQjPGcTY5e1aBv4ow2k= =BGIY -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- From nobody Fri Nov 9 03:58:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F517130DEB for ; Fri, 9 Nov 2018 03:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=PcTSc702; dkim=pass (1024-bit key) header.d=ericsson.com header.b=LM4wpRV4 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 VDjTr8OUPvQc for ; Fri, 9 Nov 2018 03:58:30 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 7254E130DE9 for ; Fri, 9 Nov 2018 03:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541764708; x=1544356708; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+O57/5dI540SIeqCl3ki8un0CZHCJ2bz6EnP2+f4v2g=; b=PcTSc702aActEgADGAtd/Cos0jpURgTwqZeNiSWaWSeWZlDlVNqAIrGRGgDnJHdD Bt6FHUQKjzWc0J8bOM2eIHtHfC1MYMjQ7qkSKKPKSVW62ywLDY6/44J6xh/+LBCp 3SekIo85JBHn8Ia9+uO+t3Fcju3Tx57VoVFvD+hOgWY=; X-AuditID: c1b4fb3a-45fff70000002747-b3-5be57664d194 Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.42.10055.46675EB5; Fri, 9 Nov 2018 12:58:28 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 9 Nov 2018 12:58:28 +0100 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 9 Nov 2018 12:58:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nv9odwa9nX6ql3ORYuSCi+kxTW+PCniW/Fav7rryqJk=; b=LM4wpRV4jRNlXSk7v8PlHMvD4nGSPjP/agY8NEK7zy3P2ZrCqBNppc6YmppSIZ6KD/R4dIiTl1CxKlEk8Xn1dBmDRMvbdSpZdVh8PtbagLGEjlXR9xPA08AZS+EzSWNG6McR97Wyq+kjTUKvUluVQqdtyqH5vr7rc9EsBp8Pegk= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB1241.eurprd07.prod.outlook.com (10.164.51.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Fri, 9 Nov 2018 11:58:27 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::b074:afe2:469c:dd95%3]) with mapi id 15.20.1294.034; Fri, 9 Nov 2018 11:58:27 +0000 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "Michael Koster" CC: "fluffy@cisco.com" , Shantanoo Desai , "core@ietf.org" Thread-Topic: [core] [SenML] Multiple values in a measurement Thread-Index: AdRmu1O0gVkxiXhNQCmF42kugckttw== Date: Fri, 9 Nov 2018 11:58:26 +0000 Message-ID: References: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> <20181108071803.GA4264@hephaistos.amsuess.com> <993797F0-02BB-46C0-94C2-FD62C311635D@gmail.com> <20181108183715.GB26534@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1241; 6:omMvey+7sC1L8UXljlhIEtCRGAqJNM13CjUU5RdwcqLjvBcbIw6IkGJT3X8toJ7SMwoVBwuUiMBxisHizWR2P2uskU3fNW9GrmC2ElOwsASahTpGA9+DutODKPc1yy+ppFqXfI87EyQkPI2KZi1a+jzwU8ItWiJObrIz1ctmXz09kkpW6A9zPcHbtZQX1Ob8X1KrAk6+QBBW3qwhmj5bYMI8gvt7Iytn48haGEqlOMqHMjW1VjQgBJvPvwtdt80/X9ZpctY98pldcb9uymX7jO1fykP+0BLCzVaHnonNyK8X5aYqeIcDKn2bgs5XJH91p4zK331xegbUyM4yvJBz/iow9p7QblNZ6cdmkTi3P54m5i+bdU5yLCTaqNMFo6s99tV43tQkTmWjkYgLT7cVUlmmp4awrWc1xIcBU5R2bW9DuOE4ma3sBJGJ2VOTu/vL24r7rD5GQnZG/xeMIn5sTQ==; 5:Tg8y27BCHDja7Hu+41sqkhg59cip4Gnem6ksqIU4tvONE7Yv3hjPH/q+0J2NL3S3XIsF8uQQVA2+MoeawKp3YiLyCKjbAz5mQTm1Ewd3RqsztG/eYeX+nsinwoNntdhg5kzv5jGc8rB5ejRmbejms9q6MZ2e7T/sVNK/LexLdw0=; 7:rH092udrSqqknEH7YPsiWvkIo4xLfZz+vsltsctkEDKT7i+dhJjnxeguMK2HFx+thWOk37A9XP/zBwDqtqlIhDy5+i2L2e51I+32T6RvIH1bOKa2nwQ8BzAyh/K2akOEiNZ+Y3JU84QVnI0QP2+RKQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 845c9be9-3e0e-4067-05ec-08d6463aa897 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB1241; x-ms-traffictypediagnostic: HE1PR07MB1241: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB1241; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1241; x-forefront-prvs: 08512C5403 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(39860400002)(136003)(396003)(189003)(199004)(6436002)(7696005)(9686003)(53936002)(6506007)(93886005)(105586002)(68736007)(76176011)(39060400002)(6246003)(106356001)(99286004)(55016002)(2906002)(110136005)(54906003)(6116002)(97736004)(229853002)(14454004)(3846002)(2900100001)(5660300001)(478600001)(8676002)(71190400001)(71200400001)(66066001)(486006)(4326008)(316002)(8936002)(81156014)(81166006)(33656002)(446003)(476003)(256004)(25786009)(26005)(74316002)(86362001)(305945005)(7736002)(102836004)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1241; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: eHAC2J81KpJiiLgqjwruyxMPUhPlq5Kdk/MpED+bjZAhi6Rn6Udf30PwOZ/TZvghRilLjL3QMf2Ked/eBjLIpvr6r9ai1RpK4yuDdyDU9KKooFeHSXq2p132bI4XqkCZKeIEGCncUU8IV/lBgk4iQ/fGzvKwgEMcUxE6gZgOHKQuX/J81IqAH/60UpeCXOKfGPsVxxUAPZ77WIaGsEjYVBYNIic9+6V1BlN0hfKACtRRXkDUejluUYlDmkJHmcjNCoxIeby6o5emOXUBYaxUltrLUNUCwBU/jxVF/XHsRmmo6ihtt907YNl58CRNlBKVaWrOzCFE2SsGT5uT2/kOsQ9CIKD911sapPRstyH7qNk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 845c9be9-3e0e-4067-05ec-08d6463aa897 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2018 11:58:26.8069 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1241 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUyM2J7iW5K2dNog/X7FS327ehjsdj3dj2z RfOzc0wWHZPZLKa1n2d3YPXoOviL1aNny1s2jym/N7J67Jx1l91jyZKfTAGsUVw2Kak5mWWp Rfp2CVwZm+aeZSuYwFux79lu9gbGvVxdjJwcEgImEjNvTWPpYuTiEBI4wijxfMd2RgjnK6PE mfevmSGcxUwSJ+ctB3NYBCYwSzRdX8sEkZnMJLFvzlRWCOcho8SGz/cZQSazCdhLTF7zEcwW ESiU2PTpNROIzSxQJrH9SCcLiC0sYCOxZfckoLEcQDW2EhM/FkGU60m0HpsJVs4ioCKx8PJl NhCbVyBG4uust+wQu6YxSRx4958VJMEoICbx/dQaqPniEreezGeC+E5AYsme88wQtqjEy8f/ oOqjJV6dOskOEVeUOPvuIVS9rMSl+d3gAJAQuMYm0XlvFytEQlfiw9SpYIdKCPhKXNgYA1Fz nFFi7eqXLBA1WhIre5+zQtRkS8z6GwERtpZY+eoD1Bg5iVW9D1mgepklJn1ZwTSB0WAWkrsh bD2JG1OnsEHY2hLLFr5mngUOAEGJkzOfsCxgZFnFKFqcWlycm25kpJdalJlcXJyfp5eXWrKJ EZh0Dm75bbWD8eBzx0OMAhyMSjy8DDlPo4VYE8uKK3MPMUpwMCuJ8PoWAYV4UxIrq1KL8uOL SnNSiw8xSnOwKInzOqVZRAkJpCeWpGanphakFsFkmTg4pRoY9XhuPnTxP7dwsZHD7uNzErfy Wi8Syog45R7Svt5VeFXZ4+fbVvW63XVT567TqWCKtNRev7ZX+eC63WVLyxZ5JFurqb2+6t+4 0LYi8P+mO1mzuTM+pbhO2nZ8QoXsc4tzdgsvJM64YpP0fM6xE/W3Vu404p5i4m54scduyc3/ QZsVnMRzXz/PUWIpzkg01GIuKk4EAA2srNo2AwAA Archived-At: Subject: Re: [core] [SenML] Multiple values in a measurement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 11:58:33 -0000 On 09/11/2018 1.37, Christian Ams=FCss wrote:=0A= > Hi Michael,=0A= > =0A= > On Thu, Nov 08, 2018 at 10:17:41AM -0800, Michael Koster wrote:=0A= >> I don't believe RFC8428 places any normative constraints on the scope=0A= >> of the identifiers that result from bn+n, either in section 4.5.1=0A= >> names or 4.6 resolved records.=0A= > =0A= > Quote:=0A= > =0A= > | Name: Name of the sensor or parameter. When appended to the Base=0A= > | Name field, this must result in a globally unique identifier for= =0A= > | the resource.=0A= > =0A= > I'm not particularly fond of of that, but remember very clear reasoning= =0A= > from the authors that having unique IDs in there is a stronger=0A= > requirement than playing nice with URI references.=0A= > =0A= >> Specifically, I don't imagine there being a senML validator that would= =0A= >> check for the uniqueness of bn+n resolved names. I don't even know how= =0A= >> right offhand.=0A= > =0A= > I figure "We funnel data from all our devices into our Enterprise=0A= > server whose database behaves like a concatenation of all SenML files"=0A= > was one application. That'd get confused quite fast if different devices= =0A= > all reported their first accelerometer as "3313/0/".=0A= > =0A= >> What do the authors say?=0A= > =0A= > I'd be very happy to be told I'm wrong on this (it would allow more=0A= > elegant core-interfaces), and look forward to a response from them.=0A= =0A= Yes, one of the design principles was that SenML names need to be =0A= globally unique so that they can be used e.g., as data base keys without = =0A= conflicts.=0A= =0A= =0A= Cheers,=0A= Ari=0A= From nobody Fri Nov 9 04:18:09 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAF3130DE9; Fri, 9 Nov 2018 04:18:06 -0800 (PST) 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] 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 BaBwvYKn3Nvn; Fri, 9 Nov 2018 04:18:04 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D3B130DD8; Fri, 9 Nov 2018 04:18:03 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id C259341F6B; Fri, 9 Nov 2018 13:18:01 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1656639; Fri, 9 Nov 2018 13:18:00 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 500D12E; Fri, 9 Nov 2018 13:17:59 +0100 (CET) Received: (nullmailer pid 12457 invoked by uid 1000); Fri, 09 Nov 2018 12:17:58 -0000 Date: Fri, 9 Nov 2018 13:17:58 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-hartke-t2trg-coral@ietf.org Cc: core@ietf.org Message-ID: <20181109121757.GA17755@hephaistos.amsuess.com> References: <20181031164534.GA4995@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20181031164534.GA4995@hephaistos.amsuess.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] Possible and impossible CIRIs (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 12:18:07 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Running larger tests of CoRAL conversion from RDF (because that's what I have large quantities of) I ran into issues converting IRIs, which I think makes sense to discuss (and maybe write down in a section in what I only just noticed now to be the standalone CIRI document) -- "Which IRIs can we express and which not". Topics there are: * userinfo (ftp://user:password@example.com/): Can not be expressed; that way of transporting credentials is deprecated anyway. * Some syntax-based denormalization in IRIs is implicitly normalized (following RFC 3986 section 6.2.2) when converted to CoRAL. In particular, this removes * The difference of having a trailing slash after the netloc when the path is empty (http://example.com vs. http://example.com/), and * any denormalization in percent encoding. * Denormalization in the capitalization of scheme and host name may be persisted. * Any differences in IP literal representation: Can not be expressed. (I'm not sure whether that falls in the syntax-based normalization category; at any rate, there's no guarantees that a CoRAL system actually outputs the normalized version.) * "Using the scheme's default port" can not be expressed. As this precludes to-CoRAL conversion (and normalized from-CoRAL) on schemes the processor has no explicit knowledge of, I already suggested that this be allowed. (It's also a form of normalization, but not syntax-based.) * URIs that do not use a netloc are not supported. Anticipating interaction with the dev-urn draft, I think that the netloc parts in the CIRI should just be optional; micrurus can run the recompose code with just one more bit of state (has_netloc) and round-trip URNs with that as well [1]. I did not check whether relative resolution works correctly there, but don't see why it shouldn't if it's defined at all. (I ran into this converting the various mailto: and xmpp: addresses in my RDF files, but urn:dev: is probably a more suitable example.) I'm currently expanding my test section that decomposes RFC3986 example URIs and tests recomposition, but so far, I'm confident that CIRIs can be used for all I'd ever intend them :-) Christian [1]: https://gitlab.com/chrysn/micrurus/commit/b734de8fdf6cfb701ca0f662c705= 62574048f621 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvlevEACgkQOY0REtOk veFwHxAAjatcCWptUJiL1eKwr97uYvtcEtoip/e3lXcvwysUQ+/DFPXZqTOMkFk4 lKVGeqTBfGAf3FZzL9rg6CoLrw912COpGLwE5vxjQ4eupKYOQ+xPCFMt9iIcIZHz bAwPLnsFX9N29qnix7lBkWDy61DU6poMk5oPID5h56JkFZxlPbQoCyEmcjRR4WEl EhcgaOKXIJdiceyAr0ojoOiXJ2mV3UkPTeXN4v1aTwFzSC9LCzSTT7VD9s3Yaf37 sWo1mzBb4iaCARMbZJ4lWwHUuyoai0ItxIRhFUdBKvoHIiuXc7JIECjFPyn+/ejr BigofTgX0n5X/2aJGDwK9J5+p+iPM3RHmXiQuHzgtI9ptmk2Bf+4NZkDinJnkNZ0 trjdUmKwyawAjqGEHYVB7lj9UmlvWCF9Y8x8VQue3n81eFHuGV52KlvxRmWNqcUH 1lWaBsCcCmsBtuN96FMmhC3ELnMbFDLnR8H4x8aL/lLbOPKaJOIaj/piHastVhdu 2ViVhnS61y6VFLbLNXocRrYb7b+NLVDIF9l/iFCPDasl/Ok2VHOyBeAY7FS2r1yW A6u+riPfqLdWii3sSciXmKk2296zHXbCC54nlpqfJOTdTTsm4SuTiDf/2nZN4Tjd za7ehYrl9UwiFQyxWD1Zd8se+gH3YMZCeWiIhW7Mslq5ok/LyVc= =Ca1d -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From nobody Fri Nov 9 06:46:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA9912870E for ; Fri, 9 Nov 2018 06:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNmyfcw1IJB6 for ; Fri, 9 Nov 2018 06:46:27 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 282E1130DC6 for ; Fri, 9 Nov 2018 06:46:27 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id w25so1052330otm.13 for ; Fri, 09 Nov 2018 06:46:27 -0800 (PST) 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=9sNIbcLqHqm0I7PcZBV9awPTFgndZFv97ZUl2ec98KI=; b=h9J3zpSuOTpdkW+0gJ6484IPn7zC8wPd9nUwMddulMbecZ6i4equxrLrY+An1YQWUr Gag4xvi45eDqcyyuqKkMwgGShP9pNeYWnwsfEhW2EC5nEc9Axffy3PqmqsfDdr89dHFQ H4+bWny10QQHZbG2fGpN4CXnSo7WuaUExJdKvIeE0+Tz5L+KBPJ3zMqZMCUwf8ZVbNSs behRDA8awRuVim9GXG/Vsu6ISQKMMdPYxWG09B1UCbKY/Z7kpB5omZbPSeYCAntiJydx njKC74lkkCK7BgldWBV/bmrB4RQAjA1s0kUuuYsfCJDN8wpq96dbz9CXebFUTP7aBjrj 6IRA== 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=9sNIbcLqHqm0I7PcZBV9awPTFgndZFv97ZUl2ec98KI=; b=uZqug8n6y0eOZhNsDBvL/Soeq7sPBrdu7L92hx1EG6pD++d8MY10f4QzUFaNfkD5jL PWpBS5GV9eG7GUYTHL2roUIGpPy+SWs3UJTKKebnLqxdk8/5N1FTeNoPCsaT0/2bViS3 FfJ7JNqPAAXjf8kCcpB15TpxIhs8hxVDr3U9ADdO5dEgeKkUHuOxw3HOuK7EsMlg6ZGA ab1vd5Ev8dmS5QgjGCBYY/DQaKu6sQpuEpvPsce8RmvGzUgiNfkvBrZEb1QfOU6bejzg CNDjl5fhXH31+veEa9Llevwq2qNEj3aiyQkaZ60m4Ip55OSR0LyV0iSCmH8wMG2zkwqd gX8Q== X-Gm-Message-State: AGRZ1gJ2C1el+fKDb0aXU7YupsAa/JAjKwhKCHGAVb0kuMuBCJuUOstZ IN+Vcw6tfzxDR7MFXZSAqy4= X-Google-Smtp-Source: AJdET5fm4K80Tg0+1vy0sFZDPdqtq2Rq1kufCtNwN4xo70qzLBZioHaS6IQtgXb8JfOHi8jqmui34Q== X-Received: by 2002:a9d:3f34:: with SMTP id m49mr5196135otc.23.1541774786478; Fri, 09 Nov 2018 06:46:26 -0800 (PST) Received: from [10.0.0.3] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id h53sm2862419otd.41.2018.11.09.06.46.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 06:46:24 -0800 (PST) From: Michael Koster Message-Id: <6DAEE31A-A9D1-4F58-A9AE-DE9005809E36@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_99710D5F-F37F-4370-8685-BA6D074558E5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 9 Nov 2018 06:46:22 -0800 In-Reply-To: Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= , "fluffy@cisco.com" , Shantanoo Desai , "core@ietf.org" To: =?utf-8?Q?Ari_Ker=C3=A4nen?= References: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> <20181108071803.GA4264@hephaistos.amsuess.com> <993797F0-02BB-46C0-94C2-FD62C311635D@gmail.com> <20181108183715.GB26534@hephaistos.amsuess.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [SenML] Multiple values in a measurement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 14:46:29 -0000 --Apple-Mail=_99710D5F-F37F-4370-8685-BA6D074558E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oh, OK.=20 I see the statement in 4.2 Name: Name of the sensor or parameter. When appended to the Base Name field, this must result in a globally unique identifier for the resource. I'm a little confused by what is a resource and what is a senml pack. I = guess each senl pack needs to be bound to some globally unique resource? How would I validate that? Also, Is the example in the RFC wrong? This doesn't resolve to a = globally unique identifier=20 [ {"bn":"2001:db8::2/","bt":1.320078429e+09, "n":"temperature","u":"Cel","v":25.2}, {"n":"humidity","u":"%RH","v":30}, {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3}, {"n":"humidity","u":"%RH","v":67} ] To summarize, it seems overly restrictive to the general use of senml to = require that each senml pack be identified with a globally unique = resource. (please correct me if I mis-stated this) Best regards, MIchael > On Nov 9, 2018, at 3:58 AM, Ari Ker=C3=A4nen = wrote: >=20 > Yes, one of the design principles was that SenML names need to be=20 > globally unique so that they can be used e.g., as data base keys = without=20 > conflicts. >=20 >=20 > Cheers, > Ari --Apple-Mail=_99710D5F-F37F-4370-8685-BA6D074558E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Oh, OK. 

I see the statement in 4.2
   Name:  Name of the sensor or parameter.  =
When appended to the Base
      Name field, this must result in a globally unique identifier for
      the resource.
I'm a little confused by what = is a resource and what is a senml pack. I guess each senl pack needs to = be bound to some globally unique resource?

How would I validate that?

Also, Is the example in = the RFC wrong? This doesn't resolve to a globally unique = identifier 

   [
     {"bn":"2001:db8::2/","bt":1.320078429e+09,
      "n":"temperature","u":"Cel","v":25.2},
     {"n":"humidity","u":"%RH","v":30},
     {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3},
     {"n":"humidity","u":"%RH","v":67}
   ]

To = summarize, it seems overly restrictive to the general use of senml to = require that each senml pack be identified with a globally unique = resource. (please correct me if I mis-stated this)

Best regards,

MIchael

On Nov 9, 2018, at 3:58 AM, Ari Ker=C3=A4nen = <ari.keranen@ericsson.com> wrote:

Yes, one of the design = principles was that SenML names need to be 
globally unique so that they can be used e.g., = as data base keys without 
conflicts.

Cheers,
Ari

= --Apple-Mail=_99710D5F-F37F-4370-8685-BA6D074558E5-- From nobody Fri Nov 9 15:00:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B86E12D4F2 for ; Fri, 9 Nov 2018 15:00:45 -0800 (PST) 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 Okkeg9Rrz-7d for ; Fri, 9 Nov 2018 15:00:44 -0800 (PST) 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 95FC712D4E7 for ; Fri, 9 Nov 2018 15:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA9N0RaL019573; Sat, 10 Nov 2018 00:00:32 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:4ca7:1ca5:121e:cc52] (unknown [IPv6:2001:67c:1232:144:4ca7:1ca5:121e:cc52]) (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 42sFx45Ny3z1Bqk; Sat, 10 Nov 2018 00:00:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <6DAEE31A-A9D1-4F58-A9AE-DE9005809E36@gmail.com> Date: Sat, 10 Nov 2018 06:00:20 +0700 Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , =?utf-8?Q?Christian_Ams=C3=BCss?= , "fluffy@cisco.com" , Shantanoo Desai , "core@ietf.org" X-Mao-Original-Outgoing-Id: 563497218.604251-649c48453ad560c49bd7ef69804476b4 Content-Transfer-Encoding: quoted-printable Message-Id: <7B224439-4DFD-4774-9FDA-E92112A31A11@tzi.org> References: <3643AE5F1967B74C86F1D72E6EB108926367EB@EXCH1.biba.uni-bremen.de> <9315AE8F-0893-4587-8FF3-8EA43BF48D64@gmail.com> <20181108071803.GA4264@hephaistos.amsuess.com> <993797F0-02BB-46C0-94C2-FD62C311635D@gmail.com> <20181108183715.GB26534@hephaistos.amsuess.com> <6DAEE31A-A9D1-4F58-A9AE-DE9005809E36@gmail.com> To: Michael Koster X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] [SenML] Multiple values in a measurement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 23:00:45 -0000 On Nov 9, 2018, at 21:46, Michael Koster = wrote: >=20 > Also, Is the example in the RFC wrong? This doesn't resolve to a = globally unique identifier=20 >=20 > [ > {"bn":"2001:db8::2/","bt":1.320078429e+09, > "n":"temperature","u":"Cel","v":25.2}, > {"n":"humidity","u":"%RH","v":30}, > {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3}, > {"n":"humidity","u":"%RH","v":67} > ] In RFCs, 2001:db8::x is code for =E2=80=9Can IP address". That is = =E2=80=9Cglobally unique=E2=80=9D (unless RFC 1918, which we don=E2=80=99t= have in IPv6). Obviously its ownership can change over time. But that = is then disambiguated by bt/t. > To summarize, it seems overly restrictive to the general use of senml = to require that each senml pack be identified with a globally unique = resource. (please correct me if I mis-stated this) This is a choice that we did debate a lot. The RFC documents the = outcome of that debate. The other choice would have been valid as well. (My personal view is that an RFC 6919 =E2=80=9CMUST (BUT WE KNOW YOU = WON=E2=80=99T)=E2=80=9D would have been closer to what we=E2=80=99ll = find in real world use of SenML. But at least we gave an incentive to = other SDOs to look for ways to obtain unique identifiers.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Nov 10 01:01:42 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448D7130E13 for ; Sat, 10 Nov 2018 01:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Onm4JTVEy8Z1 for ; Sat, 10 Nov 2018 01:01:38 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 CEBD0130DED for ; Sat, 10 Nov 2018 01:01:37 -0800 (PST) Received: from mail-qk1-f180.google.com ([209.85.222.180]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gLP93-0000xT-E1; Sat, 10 Nov 2018 10:01:34 +0100 Received: by mail-qk1-f180.google.com with SMTP id m5so5829845qka.9 for ; Sat, 10 Nov 2018 01:01:33 -0800 (PST) X-Gm-Message-State: AGRZ1gL3bZk88uOY28u9Wp/ANwUgAXYhRBWLSkMzOLamrJh1PTG+iLHH dPKW8PABKVWg+p3xaBCLZ2IcT04socxheU3hrQI= X-Google-Smtp-Source: AJdET5eS+lGOudqDaXihu6mVE9Q5b7qU76MhJH4v/t6OS8NzE//scl/SG0LYFlQSdJ4uRorgu8I7/8iE6m7qXIfqWZc= X-Received: by 2002:aed:26a3:: with SMTP id q32mr11955086qtd.106.1541840492423; Sat, 10 Nov 2018 01:01:32 -0800 (PST) MIME-Version: 1.0 References: <20181105123604.GA9680@hephaistos.amsuess.com> In-Reply-To: <20181105123604.GA9680@hephaistos.amsuess.com> From: Klaus Hartke Date: Sat, 10 Nov 2018 10:00:59 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541840497; 9b17b6ec; X-HE-SMSGID: 1gLP93-0000xT-E1 Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 09:01:40 -0000 Christian Ams=C3=BCss wrote: > > #using iana =3D > > #using attr =3D > > > > iana:terms-of-service { > > attr:title "Nutzungsbedingungen" { attr:hreflang "de" } > > attr:title "Terms of use" { attr:hreflang "en" } > > } > > That's kind of neat and kind of scary. The scary comes from the > implications of > > hosts { > attr:title "Gift" { attr:hreflang "en" } > attr:title "Geschenk" { attr:hreflang "de" } > } > hosts { > attr:title "Poison" { attr:hreflang "en" } > attr:title "Gift" { attr:hreflang "de" } > } > > which may be read to imply that there is a string "Gift" that is both > English and German and describes both resources. Literals as link targets indeed seem to need some fine-tuning. Besides language tags, I can also imagine other kinds of information attached to a literal, such as a unit: hosts { example:value 21 { example:unit } } hosts { example:value 21 { example:unit } } This may be read to imply that there is a resource identified by the integer 21, which has the unit degree Celsius and contradictorily also the unit kilogram... Klaus From nobody Sat Nov 10 01:04:46 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19E130DED for ; Sat, 10 Nov 2018 01:04:44 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtHKVXH47x2R for ; Sat, 10 Nov 2018 01:04:42 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 169D9130E13 for ; Sat, 10 Nov 2018 01:04:42 -0800 (PST) Received: from mail-qk1-f171.google.com ([209.85.222.171]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gLPC3-0004Ag-Kp; Sat, 10 Nov 2018 10:04:39 +0100 Received: by mail-qk1-f171.google.com with SMTP id y16so5827368qki.7 for ; Sat, 10 Nov 2018 01:04:39 -0800 (PST) X-Gm-Message-State: AGRZ1gKjC/YCNxALyvu1tnZxLCVZzbu1oCqGPPIr0+lMyAwhBKiceDHs K1LQj6+KrQbMiPekM7cC4Mv8xhdLA6r+GoadyvU= X-Google-Smtp-Source: AJdET5dCqi0TH8BtqepQ2m2BD4IfPqTAtLNx2ccc7iv2wfZUToHlA+oZgJURX97voQtDmkQr9svbsWPz9tSudSER7Rw= X-Received: by 2002:ac8:16d8:: with SMTP id y24mr11993304qtk.253.1541840678717; Sat, 10 Nov 2018 01:04:38 -0800 (PST) MIME-Version: 1.0 References: <20181105123604.GA9680@hephaistos.amsuess.com> <20181106084134.GC4293@hephaistos.amsuess.com> In-Reply-To: <20181106084134.GC4293@hephaistos.amsuess.com> From: Klaus Hartke Date: Sat, 10 Nov 2018 10:04:05 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541840682; bf532413; X-HE-SMSGID: 1gLPC3-0004Ag-Kp Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 09:04:44 -0000 Christian Ams=C3=BCss wrote: > Only defining the mapping for known target attributes would neatly get > us rid of the issue of link attributes. Implementations could still be > as simple as possible (ie. not even have an enumeration of known > attributes) if they accept producing odd output on unspecified input, > and follow the most common rule (map to attr:${key} "${value}") on all > but the known whitespacers. =F0=9F=91=8D > My expectation though is that processors that convert link-format to > CoRAL would be less constrained devices (C2 or larger), and that smaller > devices that still want to serve both would have something equivalent to > hard-copies of both representation in ROM instead -- is that a > reasonable one? As long as a constrained device understands all attributes in its , I see not problem with a constrained device generating a CoRAL representation from a Link Format representation on the fly (or vice versa) (or both from a more efficient in-memory representation). If that's not the case, then storing hard-copies of both representations in ROM sounds reasonable to me. Klaus From nobody Sat Nov 10 01:09:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11ED130E43 for ; Sat, 10 Nov 2018 01:09:31 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rmc9qKcwJ78 for ; Sat, 10 Nov 2018 01:09:30 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 91F8B130E13 for ; Sat, 10 Nov 2018 01:09:30 -0800 (PST) Received: from mail-qk1-f174.google.com ([209.85.222.174]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gLPGj-0007eZ-1z; Sat, 10 Nov 2018 10:09:29 +0100 Received: by mail-qk1-f174.google.com with SMTP id o89so5842985qko.0 for ; Sat, 10 Nov 2018 01:09:29 -0800 (PST) X-Gm-Message-State: AGRZ1gKQoqbb3dWw4i33YwpUymAMqIGHR+7v5zAijG6iLY22JiTbG7qb PBkymcloXjEKmp8ilaQR6reSHx5W8/KPw5DBSAg= X-Google-Smtp-Source: AJdET5dui2B/ts3Xb3JcJnQL8L+dfenGh1QGXIvO/Apm96cK2grQx7gslz0XIIbgsa+eprJYknDyiqLG/tihV8jQkrY= X-Received: by 2002:ac8:3986:: with SMTP id v6mr11606369qte.1.1541840968022; Sat, 10 Nov 2018 01:09:28 -0800 (PST) MIME-Version: 1.0 References: <20181031164534.GA4995@hephaistos.amsuess.com> <20181105120109.GC12165@hephaistos.amsuess.com> In-Reply-To: <20181105120109.GC12165@hephaistos.amsuess.com> From: Klaus Hartke Date: Sat, 10 Nov 2018 10:08:55 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541840970; ff673390; X-HE-SMSGID: 1gLPGj-0007eZ-1z Archived-At: Subject: Re: [core] [T2TRG] Review of CoRAL X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 09:09:32 -0000 Christian Ams=C3=BCss wrote: > > The draft currently specifies that a base IRI is resolved against the > > current context IRI, not the previous base IRI. > > Thanks; likewise, I missed updating the current relation number. Both > being fixed. I just checked how Turtle does it, and it seems that in Turtle a base IRI is resolved against the previous base IRI. The difference is as follows: Document without base IRIs: item item item item Document with base IRIs relative to context IRI: #base item item #base item item Advantage: Since link targets are more likely to be relative to the context than to the previous link targets, this should generate slightly more compact CBOR representations. Document with base IRIs relative to previous base IRI: #base item item #base <../bar/> item item Advantages: Since the context IRI is not used after the first base IRI directive, a processor can reuse the memory for the context IRI to store the base IRI instead of having to allocate memory for both. It would match the intuition of people who are familiar with Turtle. Would it make sense to switch? Klaus From nobody Sat Nov 10 01:16:18 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B0130E11 for ; Sat, 10 Nov 2018 01:16:17 -0800 (PST) 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] 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 mPDwnkLX6viw for ; Sat, 10 Nov 2018 01:16:14 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A055C130DE4 for ; Sat, 10 Nov 2018 01:16:14 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id EEF1E41F8C; Sat, 10 Nov 2018 10:16:10 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7706139; Sat, 10 Nov 2018 10:16:09 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 286332E; Sat, 10 Nov 2018 10:16:09 +0100 (CET) Received: (nullmailer pid 15787 invoked by uid 1000); Sat, 10 Nov 2018 09:16:08 -0000 Date: Sat, 10 Nov 2018 10:16:08 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Klaus Hartke Cc: "core@ietf.org WG" Message-ID: <20181110091607.GA5913@hephaistos.amsuess.com> References: <20181105123604.GA9680@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 09:16:17 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 10, 2018 at 10:00:59AM +0100, Klaus Hartke wrote: > Literals as link targets indeed seem to need some fine-tuning. Besides > language tags, I can also imagine other kinds of information attached > to a literal, such as a unit: RDF has data types, of which many AFAICT could be mapped to non-string literals (making their normalization issues go away like CIRIs do away with IRI normalization issues). Units I'd prefer to keep per-resource, but we can probably come up with a way to make them into data types for RDF conversion too if we want. > This may be read to imply that there is a resource identified by the > integer 21, which has the unit degree Celsius and contradictorily also > the unit kilogram... The mind set to lead us out of this is to treat literals more like blank nodes with a value -- two blank nodes are only identical if they are the same null thing in the syntax tree, and literal nodes don't become identical just by virtue of having the same literal value. (RDF might treat them as identical if their value *and* all their attributes like language tag and data type are). CIRI references are not identical either if they have the same array representation, but are identical if they resolve to the same full CIRI (and as with RDF, some applications might introduce additional equivalencies, eg. from protocol-negotiation). But yes, this does need thinking over, and probably some text explains why it's justified. Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvmodQACgkQOY0REtOk veEo3w//erinPMWyaf+MKnDGkDCfzYyIn2GJgWmObiGAkL8nV2u8gXYjyAxUywXX amPYc0dXLRWexDZt3T+js/omSCC4dxpjy/Y1bq5C5smgXblTIWoAWsGeuIQSDEnu U/nce0x6U5JN4j0clHvI1nouMc54SrAuuaG/dDH8gh6Dpg6rwvKEIk6nhwp34CK0 PBEV1Dgk5pNl6VlLdH0iAp0fY5NnZ+Hh3JtTAUoxY3ayj55BsLlkfaJwxMUJHg92 BkbfwDgCyI1rD+nm9gtVgLKydSlhlBfzCL8HZ1CSFX2vcXJ6HewxW0miBhs+eMbt //dEkMs0OmVxfCX6QFrsK0P/DeM1yBNp53FL7CxoFKm8QE23JYrEeIMlcNadbsBr QuhGgHNi3Nk69YeUQa30KgPi/7W6KjO5TvSkNOOsudfFc1kX44aNwIwgGKAEEb0a W+YwIA0gFOajEWlY57RYR3DiY5ao6EwiFzIJIbykfDh60kHZm9rIN5k3LfygYOWB hm4eBzyLsLu+xjVFaRPK6HmjJHzF0rp1n4mxNnh0pzmM9lLN//cyv4FPhyIR2jNV B8YObjJx2vdgRNt3IJc3UBRUFYsxMXJkp53acA0U2eipSlt7bRQItSjN2wQChjYU E2X4Prva3b+flRLZIXEJD/wGPwbxQ1Qqb0YK348krZmixo35kGw= =VdRV -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From nobody Sat Nov 10 01:54:44 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EAF130E13 for ; Sat, 10 Nov 2018 01:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjkNZLTmWklU for ; Sat, 10 Nov 2018 01:54:40 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21AB7130DE4 for ; Sat, 10 Nov 2018 01:54:39 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 19CF341F8C; Sat, 10 Nov 2018 10:54:38 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0266039; Sat, 10 Nov 2018 10:54:37 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8115D2E; Sat, 10 Nov 2018 10:54:36 +0100 (CET) Received: (nullmailer pid 19399 invoked by uid 1000); Sat, 10 Nov 2018 09:54:35 -0000 Date: Sat, 10 Nov 2018 10:54:35 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Klaus Hartke Cc: "core@ietf.org WG" Message-ID: <20181110095435.GC5888@hephaistos.amsuess.com> References: <20181031164534.GA4995@hephaistos.amsuess.com> <20181105120109.GC12165@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] [T2TRG] Review of CoRAL X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 09:54:43 -0000 --V0207lvV8h4k8FAm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 10, 2018 at 10:08:55AM +0100, Klaus Hartke wrote: > Christian Ams=FCss wrote: > > > The draft currently specifies that a base IRI is resolved against the > > > current context IRI, not the previous base IRI. > > > > Thanks; likewise, I missed updating the current relation number. Both > > being fixed. Oh: I did not fix all of it. What my original code did was change the context IRI as well (which I had fixed), but I kept working off the same base IRI. > I just checked how Turtle does it, and it seems that in Turtle a base > IRI is resolved against the previous base IRI. I checked HTML, but they only allow a single base href. XML's (and thus Atom's) xml:base URIs can't be relative references anyway. In JSON-LD, the @base must be in the @context if I understand the text right, so there can only be one like in HTML. > #base > #base > > Advantage: Since link targets are more likely to be relative to the > context than to the previous link targets, this should generate > slightly more compact CBOR representations. I'd think that situations of deep links will be rather unlikely anyway (if / says something about /foo/bar/, it probably says something about /foo/ too, and /foo/bar/ will be linked to from /foo/ and not / in the likely cases.) > Document with base IRIs relative to previous base IRI: >=20 > #base > #base <../bar/> >=20 > Advantages: Since the context IRI is not used after the first base IRI > directive, a processor can reuse the memory for the context IRI to > store the base IRI instead of having to allocate memory for both. It > would match the intuition of people who are familiar with Turtle. I'd rather think of it as "updated in-place" than "freed and reused", but yes, it might be more RAM efficient (esp. interesting with non-zero nesting limits). Transfering intuition from related formats is a bonus too, so... > Would it make sense to switch? yes. Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --V0207lvV8h4k8FAm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvmqtYACgkQOY0REtOk veFPJA/+LxTggQdbwElKY9JuX73RFF0XZU6Q068UM+bBM22DFDmYeJraEAzqKTWD 7OSsnOHMKYmKIDalT+wIXmyaMJkxQc0AFbnysGKky6yPVKNMQlbcB9Tz1ZT/o0cj aWr0Q/d8NCsXUjxRc2/cZhkzIl6uW6IS6bvYOm3QBRfF6LZ/QmVMGCgDGaJrLJYP jKo/DTRqal5cN258iVx8CwszWLfgJcl+jYoN2V23znMnC6Chqytsec7JiZOcDg8T ineXdFpiLfkQ6loqj4oCPzTAmuS7tI/qy6MJndh27/OmoDsZczSrJQv7bSrVdVCK QXuPtnGVamh2DEqngl/m85n/pXKAIPwywX3VFdHQ+mR0xMwqkaZFco6GQ5gWUYY+ Z9arTxzCXRLgw2wBKXCQAtvQxNsz2nOkO+JHkxL/IrL6xLhSOzaPUfGoc3CMjkbm GQNKmY1pJ754VPlJggPxCDvZQAaYwkSu7mGXEEgb4xX1W+zXt2sdST1YwJHNeQ+i V6bYI29+U+6IIVbaIfHynWLfZSA5bp8FRyE1Bs8PREYukE3CXzksQkKBHLfsYJl5 zPMAMht6rZvuXE0KSnnQVeD8p25qbqbD/Z4hzsHYAR+OGNWB0wHm3fGNUcIbosi3 iy7+Qhc2cwmL5KYoo8kmKBXxsSP0YTxFVCuMOIL2f3c+Ir0+coM= =Ngu1 -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- From nobody Mon Nov 12 18:59:00 2018 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 7163E124408; Mon, 12 Nov 2018 18:58:58 -0800 (PST) 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.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <154207793840.4202.1238228595871118910@ietfa.amsl.com> Date: Mon, 12 Nov 2018 18:58:58 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-comi-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 02:58:58 -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 : CoAP Management Interface Authors : Michel Veillette Peter van der Stok Alexander Pelov Andy Bierman Filename : draft-ietf-core-comi-04.txt Pages : 56 Date : 2018-11-12 Abstract: This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CoMI). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CoMI uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CoMI extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-comi/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-comi-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-comi-04 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 Mon Nov 12 21:04:46 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3264A129C6B for ; Mon, 12 Nov 2018 21:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rBKb6BajhQNt for ; Mon, 12 Nov 2018 21:04:42 -0800 (PST) Received: from mail2.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 177C3126F72 for ; Mon, 12 Nov 2018 21:04:42 -0800 (PST) Received: from Jude (210.160.37.27) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 12 Nov 2018 20:59:46 -0800 From: Jim Schaad To: 'Klaus Hartke' , "'Fossati, Thomas (Nokia - GB/Cambridge)'" CC: References: <20181030174246.GA6420@nokia.com> In-Reply-To: Date: Tue, 13 Nov 2018 14:04:32 +0900 Message-ID: <000201d47b0e$608c6800$21a53800$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHcHUzYtNBi+9l+u3E0IFYmK/CERQF4w+LNAhRtpRkBN6c5CqUXuvHg Content-Language: en-us X-Originating-IP: [210.160.37.27] Archived-At: Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 13 Nov 2018 05:04:44 -0000 Klaus, I think that I would prefer that the choice between ordered or unordered be a property of the application that is using the multipart collection rather than hard coding it in. I can think of use cases where both are things to be desired and thus would not like to rule out either one. Jim > -----Original Message----- > From: core On Behalf Of Klaus Hartke > Sent: Wednesday, November 7, 2018 9:26 PM > To: Fossati, Thomas (Nokia - GB/Cambridge) > Cc: core@ietf.org WG > Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02 > > I think the draft needs to be much clearer on whether a multipart collection > is an unordered multiset of representations (which I had assumed so far) or > an ordered sequence where applications attach additional out-of-band > meaning to the positions. > > Speaking of additional out-of-band meaning, I wonder if there should be > identifiers in the collection explicitly describing the semantics in the interest > of self-description. There are also considerations related to evolving the out- > of-band information, such as when an application wants to change the > meaning of a position but continue using the "application/multipart-core" > content format ID. > > Klaus > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Nov 12 21:09:36 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C094129C6B for ; Mon, 12 Nov 2018 21:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 UhVZssAYP_Ru for ; Mon, 12 Nov 2018 21:09:32 -0800 (PST) Received: from mail2.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 35D97126F72 for ; Mon, 12 Nov 2018 21:09:32 -0800 (PST) Received: from Jude (210.160.37.27) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 12 Nov 2018 21:04:16 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_M._Ams=FCss'?= , 'Klaus Hartke' CC: References: <20181105123604.GA9680@hephaistos.amsuess.com> <20181108113103.GB13498@hephaistos.amsuess.com> In-Reply-To: <20181108113103.GB13498@hephaistos.amsuess.com> Date: Tue, 13 Nov 2018 14:09:02 +0900 Message-ID: <000501d47b0f$007301d0$01590570$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHTTO+CYtfYJXecibqIijavORWENwMCsChUAnhNUzECkIVB7AJKIuPDpPzWjgA= Content-Language: en-us X-Originating-IP: [210.160.37.27] Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 13 Nov 2018 05:09:34 -0000 > -----Original Message----- > From: core On Behalf Of Christian M. Ams=FCss > Sent: Thursday, November 8, 2018 8:31 PM > To: Klaus Hartke > Cc: core@ietf.org WG > Subject: Re: [core] Link target attributes in CoRAL (was: Review of = CoRAL) >=20 > On Tue, Nov 06, 2018 at 09:21:36AM +0100, Klaus Hartke wrote: > > Of course, we could for new link target attributes, as they pop up, > > define an equivalent more semantic link relation type. In Link = Format > > you would use the link target attribute; in CoRAL, the link relation > > type. If a converter encounters a new, unknown attribute, it would = fail. >=20 > It just occurred to me that there is another point to be made for per-relation > rules: There are target attributes that are URI-valued. > That's something I'd recommend to avoid in the first place, but still = does > happen (eg. ol=3D in protocol-negotiation, or even base=3D in RD which = I can't > really rip up now). >=20 > It's a trade-off, though: While making the resulting data semantically more > palatable, it makes link filtering odder (a `GET /.well- > known/core?ol=3Dcoap://x/` CoRAL response one'd need to think `GET = /.w- > k/c?anchor=3Dcoap://x/&rel=3Dattr:ol`). I still think it's worth it = (speaking as > someone who'll have to implement the lookups). Would a more interesting version of this end up being GET /.well-known/core?ol=3Dcoap+tls://x/ Although I am completely unsure if that means the same thing as what you suggested. Jim >=20 > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Tue Nov 13 00:36:36 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2673012D4E6 for ; Tue, 13 Nov 2018 00:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-W-UuHl6XT7 for ; Tue, 13 Nov 2018 00:36:33 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C24130DDA for ; Tue, 13 Nov 2018 00:36:31 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id EE6DA415D3; Tue, 13 Nov 2018 09:36:28 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0C7EE39; Tue, 13 Nov 2018 09:36:28 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AA9E319; Tue, 13 Nov 2018 09:36:27 +0100 (CET) Received: (nullmailer pid 20963 invoked by uid 1000); Tue, 13 Nov 2018 08:36:26 -0000 Date: Tue, 13 Nov 2018 09:36:26 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Jim Schaad Cc: 'Klaus Hartke' , core@ietf.org Message-ID: <20181113083625.GA19660@hephaistos.amsuess.com> References: <20181105123604.GA9680@hephaistos.amsuess.com> <20181108113103.GB13498@hephaistos.amsuess.com> <000501d47b0f$007301d0$01590570$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <000501d47b0f$007301d0$01590570$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 13 Nov 2018 08:36:35 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2018 at 02:09:02PM +0900, Jim Schaad wrote: > > It's a trade-off, though: While making the resulting data > > semantically > more palatable, it makes link filtering odder (a `GET > > /.well- known/core?ol=3Dcoap://x/` CoRAL response one'd need to think > > `GET /.w- k/c?anchor=3Dcoap://x/&rel=3Dattr:ol`). I still think it's > > worth it (speaking > as someone who'll have to implement the > > lookups). >=20 > Would a more interesting version of this end up being >=20 > GET /.well-known/core?ol=3Dcoap+tls://x/ >=20 > Although I am completely unsure if that means the same thing as what you > suggested. Yes, that's the kind of lookups I'm thinking about. The rel=3Dattr:ol lookup above is not something I expect we'd ever send over the wire, but should express the differeneces in models we are facing: The CoRAL/RDF data model knows no attributes to look up aganist, and could (especially with link-valued attributes) not even know from the data alone whether something is a link or an attribute. When implementing query filtering, one will first see ?ol=3Dcoap+tls://x/ then will recognize that ol is a link-valued target attribute, so the=20 query is internally semantically equivalent to SELECT ?target WHERE { ?target attr:ol } (which is a form of lookup one'd also have if a query were for ?anchor=3Dcoap+tls://x/&rel=3Dsomething), and then look into the data again to convert back. I guess what I'm eventually saying here is that the way query filtering is expressed is tightly bound to the web links (annotated targets) information model, and running them against the CoRAL model (only links, but also to literals; which I personally think is way more elegant) does not come trivially. It is possible, and well-defined once a mapping between the information models, and can probably even be implemented efficiently, but not immediately obvious when thinking in CoRAL and seeing a filter query. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlvqjQUACgkQOY0REtOk veH11g//RdpRS7A50gss7lnUhag+yErhZPyPUrmY3+ocY6lzfVArfVAcsgmNSaeV 3ZGdc+K37GuW5+UZU7EQeDVBHejvmT5sBuT5jklrG01ZPq5xxDj8qWa5KY3LOC38 vScUzMhMkk0abyr27NKOdfiVwnZ1Npxotxv46jeVPSK0neA/ZdwvA/yYSigBpvAD qP/+Geem0wWa5SL7ndZ99l21YkMzfhVG2yJ0BOSmD58n3D944nR0Q1bf9n8ElmhY CA89xeYS79fsT4nIuCd8ByLUOTRg/L7pNLR7deJ3lb6L+92V3EnsMnxJc61jCWZu erVVwZ5DyA5AmvZT1tXniG2ggtF48spxP1j3yKGaSrUpRMd9QKm3plHRLtgfoi8w VRu1K/vK5DryEwIqMfP59wz5NeiKcm6h1s6R/+Nl8mSqYIEYOKref8ZRwkSxwqsP 6UnixWqifE4UgYlqFvlJqKS2jBt9ZCckAa30avLuOV1KgEbdJLlU4J8pk9fRmTtw jQDjV5bJF15adTb8xflf/GjT45ti1bVD4j9eaa2ynPH5NPeKjZ2QfiPhcVrV9sKp 3to/LHNLmUSLpX8ZdExwlVD4cFzvbHZ9zpFPmU/GBBSpq3gZ4v50zSGK6QjVTpm4 PTdr289He1rNiVHJQ9EdQwYDCbzlLSvCxkcNgzLRVPQ9ug+heow= =YWCb -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From nobody Mon Nov 19 08:29:04 2018 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 34923130DDF; Mon, 19 Nov 2018 08:28:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , core-chairs@ietf.org, Carsten Bormann , draft-ietf-core-too-many-reqs@ietf.org, core@ietf.org, alexey.melnikov@isode.com, cabo@tzi.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154264493520.5285.17291712157636008658.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 08:28:55 -0800 Archived-At: Subject: [core] Protocol Action: 'Too Many Requests Response Code for the Constrained Application Protocol' to Proposed Standard (draft-ietf-core-too-many-reqs-06.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 16:28:55 -0000 The IESG has approved the following document: - 'Too Many Requests Response Code for the Constrained Application Protocol' (draft-ietf-core-too-many-reqs-06.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ Technical Summary: A CoAP server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP Response Code for a server to indicate that a client should reduce the rate of requests. Working Group Summary: While this seemed to be a simple housekeeping document (based on other SDOs' requests) at first, the WG process did unearth a few fine points that have been taken care of in the current document. WGLC was passed July 16, 2018 (right before the CoRE meeting in Montreal), there was no dissent on advancing this. Document Quality: While no formal review was sent to the list, both Jim Schaad and Klaus Hartke sent comments based on an in-depth review and later indicated that their comments had been resolved in -04. Implementers indicated intent to implement this. No formal languages in the document. Personnel: Shepherd: Carsten Bormann Responsible AD: Alexey Melnikov