From nobody Tue Aug 4 12:20:43 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3433A0DCD for ; Tue, 4 Aug 2020 12:20:41 -0700 (PDT) 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G47BpKgAYUZr for ; Tue, 4 Aug 2020 12:20:36 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB183A1066 for ; Tue, 4 Aug 2020 12:20:36 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BLl2j35nBzyh4; Tue, 4 Aug 2020 21:20:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 618261628.880242-34d7598ca7f0a989f092df17b91fe160 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 4 Aug 2020 21:20:28 +0200 Message-Id: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> To: asdf@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 19:20:42 -0000 As we now have > 50 subscribers assembled on the mailing list, I think = we can start doing work here. Thank you all again for helping making the BOF a success. We got a clear mission to complete and agree the charter proposal now. The proposal is at: https://github.com/one-data-model/ietf108 There is one pull request for the charter at: https://github.com/one-data-model/ietf108/pull/3 You can approve that PR if you like; if there are no objections, I would = like to merge this one at the end of the week. Please read the charter and submit issues/pull requests where we need = further improvement =E2=80=94 we were reasonably happy during the BOF = already and should make changes only where needed. As always, it is = worth discussing PRs in issues (or here) before submitting them (typos = excluded). .oOo. We cannot really start work as a Working Group until chartered: We = cannot make decisions without Working Group Chairs that call consensus = on issues. This does not have to stop us from doing work. The SDF draft is at: https://github.com/one-data-model/SDF One Data Model people have a number of feature requests that we should = have a look at now. It would be good to have an SDF 1.1 by October that = addresses some of these requests, and to keep up an approximately = bi-monthly rhythm of releases (modulo holiday times). =20 This should be driven by what we consider best practice in = creating/converting data models =E2=80=94 we have about 15 ecosystems = that we can pick and choose ideas from. We also need to check how these = features can be picked up by the tools; I expect that once the features = gel a bit, and before they are fully crystallized, we will see = implementations in the tools (https://github.com/one-data-model/tools as = well as ecosystem specific). Some github issues will now be opened by people who already have = experienced limitations of SDF 1.0 that should be addressed; of course, = other people can submit issues, too. We can have a discussion right in = the github issues, or, for more fundamental decisions to be taken, also = here in the mailing list. It will probably take a little until we have = pull requests based on these issues; we can discuss these then and, by = the time the discussion solidifies, we might have a WG. I=E2=80=99m looking forward to SDF 1.1, and the further work of the ASDF = WG-to-be! Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 4 13:08:45 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990493A1082 for ; Tue, 4 Aug 2020 13:08:43 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtUAzo6X9Z2r for ; Tue, 4 Aug 2020 13:08:41 -0700 (PDT) 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 53D523A107D for ; Tue, 4 Aug 2020 13:08:41 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Aug 2020 13:08:35 -0700 From: Jim Schaad To: 'Carsten Bormann' , References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> In-Reply-To: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> Date: Tue, 4 Aug 2020 13:08:33 -0700 Message-ID: <05aa01d66a9b$092ce2a0$1b86a7e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQDxdGu9PMHGlpfUPtGZ6qhxuiI4BKryTMvQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 20:08:44 -0000 How much leeway is there for modifications of the first round of the SDF = document? It seems possible that changes could "break" the current = collections of model descriptions. If this is not within the of = possibility it needs to be so stated. Jim -----Original Message----- From: Asdf On Behalf Of Carsten Bormann Sent: Tuesday, August 4, 2020 12:20 PM To: asdf@ietf.org Subject: [Asdf] Kicking off ASDF As we now have > 50 subscribers assembled on the mailing list, I think = we can start doing work here. Thank you all again for helping making the BOF a success. We got a clear mission to complete and agree the charter proposal now. The proposal is at: https://github.com/one-data-model/ietf108 There is one pull request for the charter at: https://github.com/one-data-model/ietf108/pull/3 You can approve that PR if you like; if there are no objections, I would = like to merge this one at the end of the week. Please read the charter and submit issues/pull requests where we need = further improvement =E2=80=94 we were reasonably happy during the BOF = already and should make changes only where needed. As always, it is = worth discussing PRs in issues (or here) before submitting them (typos = excluded). .oOo. We cannot really start work as a Working Group until chartered: We = cannot make decisions without Working Group Chairs that call consensus = on issues. This does not have to stop us from doing work. The SDF draft is at: https://github.com/one-data-model/SDF One Data Model people have a number of feature requests that we should = have a look at now. It would be good to have an SDF 1.1 by October that = addresses some of these requests, and to keep up an approximately = bi-monthly rhythm of releases (modulo holiday times). =20 This should be driven by what we consider best practice in = creating/converting data models =E2=80=94 we have about 15 ecosystems = that we can pick and choose ideas from. We also need to check how these = features can be picked up by the tools; I expect that once the features = gel a bit, and before they are fully crystallized, we will see = implementations in the tools (https://github.com/one-data-model/tools as = well as ecosystem specific). Some github issues will now be opened by people who already have = experienced limitations of SDF 1.0 that should be addressed; of course, = other people can submit issues, too. We can have a discussion right in = the github issues, or, for more fundamental decisions to be taken, also = here in the mailing list. It will probably take a little until we have = pull requests based on these issues; we can discuss these then and, by = the time the discussion solidifies, we might have a WG. I=E2=80=99m looking forward to SDF 1.1, and the further work of the ASDF = WG-to-be! Gr=C3=BC=C3=9Fe, Carsten --=20 Asdf mailing list Asdf@ietf.org https://www.ietf.org/mailman/listinfo/asdf From nobody Tue Aug 4 13:39:32 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0AB3A0B7E for ; Tue, 4 Aug 2020 13:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwUogpJ9xwj9 for ; Tue, 4 Aug 2020 13:39:29 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBEA03A0B85 for ; Tue, 4 Aug 2020 13:39:28 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BLmnn4G7yzyhN; Tue, 4 Aug 2020 22:39:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <05aa01d66a9b$092ce2a0$1b86a7e0$@augustcellars.com> Date: Tue, 4 Aug 2020 22:39:24 +0200 Cc: asdf@ietf.org X-Mao-Original-Outgoing-Id: 618266364.6697119-36afc0caec2083e55e704fa625e0cdda Content-Transfer-Encoding: quoted-printable Message-Id: <0E4A71FC-BEC7-43D0-A973-B925905B59A4@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <05aa01d66a9b$092ce2a0$1b86a7e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 20:39:31 -0000 Hi Jim, On 2020-08-04, at 22:08, Jim Schaad wrote: >=20 > How much leeway is there for modifications of the first round of the = SDF document? It seems possible that changes could "break" the current = collections of model descriptions. If this is not within the of = possibility it needs to be so stated. As I said in the BOF, most of these models are generated from ecosystem = sources by tools, so if there is a breaking change that doesn=E2=80=99t = reduce the domain, it should be possible to get the tools to adjust. Of = course other materials such as tutorials decay with these changes, and = touching the tools is work, so there should be a reason for the change. = But overall I think this specification is malleable to an extent rarely = seen. In the end, layering backpack on backpack will make the tools hard to = maintain and brittle, so we really care about getting the = simplifications and refactorings possible with each change. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 7 15:07:25 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB953A0C4D for ; Fri, 7 Aug 2020 15:07:23 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNKQCuUV7BgM for ; Fri, 7 Aug 2020 15:07:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5800C3A0C47 for ; Fri, 7 Aug 2020 15:07:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 469FE389CD; Fri, 7 Aug 2020 17:46:40 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qSmRmB4aK4wM; Fri, 7 Aug 2020 17:46:36 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68C12389CA; Fri, 7 Aug 2020 17:46:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 76A0D1D3; Fri, 7 Aug 2020 18:07:17 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , asdf@ietf.org In-Reply-To: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 22:07:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > https://github.com/one-data-model/SDF > One Data Model people have a number of feature requests that we should > have a look at now. It would be good to have an SDF 1.1 by October > that addresses some of these requests, and to keep up an approximately > bi-monthly rhythm of releases (modulo holiday times). 1) What would you call a "release" here? 2) Are there important ODM member deadlines, meetings or processes that we should consider in our milestone process? 3) Would SDF be a single document, or a base document plus extensions? Are there parts that we can rapidly gain consensus on and publish, with discussion about the other parts? Or does draft-onedm-t2trg-sdf-00 represent the consensus part already, a= nd there is some "freezer" of other things which were removed during the OneDM part of the effort? > Some github issues will now be opened by people who already have > experienced limitations of SDF 1.0 that should be addressed; of cours= e, > other people can submit issues, too. We can have a discussion right = in > the github issues, or, for more fundamental decisions to be taken, al= so > here in the mailing list. It will probably take a little until we ha= ve > pull requests based on these issues; we can discuss these then and, by > the time the discussion solidifies, we might have a WG. > I=E2=80=99m looking forward to SDF 1.1, and the further work of the A= SDF WG-to-be! Should publishing 1.0 ASAP be a goal, or should we just do 1.1? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8t0JUACgkQgItw+93Q 3WWvkggAldDImdEEJ/sIJa/wERbN+VaxOz1giGYcE3iYyEyv+OXy0bIkUypXk+5x T4j1hYnqn4O4Psrryz1Hc11w6cEklVRAjO1J7hwgA6IMAdJL9GVb7mF/CBw162SL CnYvimZF6D2ZbL7eQ0Rjtany3B1BjBirtIIqbOy//uRZcRPhzFqbaEn/kqYvGyKZ ccna/hGl5Djxisgas5/USKMHKWq7zvUEVkYetFVqS1FGsfctZLi3OxPBRzgi0kq5 giBgEkcZGNsHBnUYHYEyGssEIbAt2mwJv5BIUbBnAIDE8cuRSfK3m5eEMbGEE9cJ VXTkwepMU5CiFOPGyf78e9qTvkNozQ== =tV8a -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 7 15:12:50 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E933A0C77 for ; Fri, 7 Aug 2020 15:12:48 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb_Mb0Xvs8CX for ; Fri, 7 Aug 2020 15:12:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC57A3A0C71 for ; Fri, 7 Aug 2020 15:12:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 61A75389CD; Fri, 7 Aug 2020 17:52:02 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wVVZGa1_GJhH; Fri, 7 Aug 2020 17:51:58 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 653DF389CA; Fri, 7 Aug 2020 17:51:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6DE8A1D3; Fri, 7 Aug 2020 18:12:39 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , asdf@ietf.org In-Reply-To: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Asdf] Is JSONPATH in scope? X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 22:12:48 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: > We cannot really start work as a Working Group until chartered: We > cannot make decisions without Working Group Chairs that call consensus > on issues. This does not have to stop us from doing work. I have some questions about paragraph two of the core of the charter: https://github.com/one-data-model/ietf108/issues/5 } In the process, some smaller pieces may become usable independently from } SDF itself and its applications. JSON Path (similar to, but different in } scope from JSON Pointer documented in RFC6901) might be an example for } such a spin-off specification -- it is currently defined on a website } and would benefit from a more formal definition so it can be used in } discovery processes involving SDF models. The web site in question is, I think: https://jsonpath.com/ ? https://goessner.net/articles/JsonPath/ https://restfulapi.net/json-jsonpath/ <- seems most authoritative Is it a goal to do this work in ASDF? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8t0dcACgkQgItw+93Q 3WVQFQf/Z4MpwvZMn4JmXUfFTftdOtCNLabuo6Y2wVW01h7285lqsIIVmLIBfmBg Ub/do3atD7Nq4bN8X017hgxdtJmRN2une8uyOKQbuMN0yK3kqvZ2V1U9TEztyt2d Z9ctzF4ANSD6qEs5kV9KjAEP5kNWCb902aP1d8BHTFXQvm54dO4QrbbfgOqz+Wu5 FJxARtlL6eEI1xo+p9Kx7/uVsGS8qSPatJeD3gBa6PayT87RkGh0U8F0T3SD3q25 agtMBtWjatIvyaZuhkBp16RihRVDfLg5PapvqjQC/fzcpHmvylPqZQtPdTYaC9hp +l/NoFPNYyJ6o5m++HmDs4wo3GcIIw== =5npC -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 7 15:25:20 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E24A3A0CEE; Fri, 7 Aug 2020 15:25:19 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzaIXFi9foNu; Fri, 7 Aug 2020 15:25:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BB63A0BEA; Fri, 7 Aug 2020 15:25:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B0462389CD; Fri, 7 Aug 2020 18:04:35 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z4u0ESEkqyXl; Fri, 7 Aug 2020 18:04:34 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1FAB0389CA; Fri, 7 Aug 2020 18:04:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2D5BC15F; Fri, 7 Aug 2020 18:25:15 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , asdf@ietf.org, json@ietf.org In-Reply-To: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] Kicking off ASDF charter discussion X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 22:25:19 -0000 --=-=-= Content-Type: text/plain {didn't open issues for this} } The ASDF WG will work closely with the CBOR WG, home of the CDDL } specification. It will also engage the still active mailing list of the } dormant JSON WG. Recent proposals to form an IRTF formal description } techniques (FDT) Research Group may lead to another collaboration } partner. The Thing-to-Thing Research Group (T2TRG) and its WISHI program } can be instrumental in engaging researchers and other SDOs in this space, } or instance W3C WoT, which is working on Thing Description Templates and } related specifications. I can't really agree or disagree with any of this :-) Can we split this up a bit? 1> The ASDF WG will work closely with the CBOR WG, home of the CDDL 1> specification. While we are using CDDL to define the structure, I'm unclear what the back and forth that ASDF will have with CBOR here. Are there pieces in CDDL that are missing that this model will motivate adding to CDDL? 2> It will also engage the still active mailing list of the 2> dormant JSON WG. Is this about json-path, and/or json-schema? 3> Recent proposals to form an IRTF formal description 3> techniques (FDT) Research Group may lead to another collaboration 3> partner. Where are these proposals occuring, and at one point will they conclude, and is the timing of this important, critical, or optional to the process? 4> The Thing-to-Thing Research Group (T2TRG) and its WISHI program 4> can be instrumental in engaging researchers and other SDOs in this space, 4> or instance W3C WoT, which is working on Thing Description Templates and 4> related specifications. This part seems rather aspirational. All sorts of communications are important and beneficial, but is there some kind of implied liason activity, or some kind of cross-WG/RG last-call that is implied? I don't see any effect from just deleting this paragraph from the charter :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8t1MoACgkQgItw+93Q 3WWzhgf/T+MLTAQBh7OF8KhXDL2pKt7LXpzzhGgZi1Dak0MuOP3BPkWX+38f9nPi Ye9dxu8f1fvFx7CTIU7AGbS/RBctN4BMDvuu9YWAOONmbkEKhUbGxg1jlw3Oonlt 77UFJQyQf8HXhp0H2UHoxMMzWGUJHhFjxGHgiBluCDtl1DdGn51Cbcf+6PCIT9ir b0lb1Q34rtpnJhw7IxpCnyRhp7tg2Lsqd0miP++LeJCwZejmOWCzcp0kBFwUncm4 3HXI/YJ9QsLi75/8TQCWe9nzfMlMG8eFJ2a3irRELaklKg7W3fPnIizZgOZw5P3Q uQ1LqYjUEoJqNFoqhNDzClHpS4IY3g== =apT9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 8 00:19:04 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100EF3A0B2F; Sat, 8 Aug 2020 00:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnbB_ErrnQ_P; Sat, 8 Aug 2020 00:18:55 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9CC3A0AE3; Sat, 8 Aug 2020 00:18:53 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BNtrD0Yx6z100r; Sat, 8 Aug 2020 09:18:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <3271.1596839115@localhost> Date: Sat, 8 Aug 2020 09:18:51 +0200 Cc: asdf@ietf.org, json@ietf.org X-Mao-Original-Outgoing-Id: 618563931.597766-d8682c5d4ab2b95665a69af48000a86b Content-Transfer-Encoding: quoted-printable Message-Id: <014EFFF5-0E83-48BC-9FCF-13831A9A9A6C@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <3271.1596839115@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] [Json] Kicking off ASDF charter discussion X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 07:18:58 -0000 On 2020-08-08, at 00:25, Michael Richardson = wrote: >=20 > I don't see any effect from just deleting this paragraph from the = charter :-) I completely agree. However, relationship to other groups usually comes up in charter = discussion, and this paragraph was intended to provide a landscape. = These links may be obvious to us, but maybe not to others joining the = work. But I would expect the WG to act on this landscape independent of = whether it is exposed in the charter or not. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Aug 8 00:25:27 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A343A0B87; Sat, 8 Aug 2020 00:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO1Jh_LlZ9bV; Sat, 8 Aug 2020 00:25:19 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778D63A0B48; Sat, 8 Aug 2020 00:25:19 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BNtzd3RwBzys0; Sat, 8 Aug 2020 09:25:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <3271.1596839115@localhost> Date: Sat, 8 Aug 2020 09:25:15 +0200 Cc: asdf@ietf.org, json@ietf.org X-Mao-Original-Outgoing-Id: 618564315.874993-60803e3743c83c46bea5704634d6dace Content-Transfer-Encoding: quoted-printable Message-Id: <2A11875E-43EA-4227-A6E7-A7F5A09831EC@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <3271.1596839115@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] [Json] Kicking off ASDF charter discussion X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 07:25:23 -0000 On to the details: > On 2020-08-08, at 00:25, Michael Richardson = wrote: >=20 > 1> The ASDF WG will work closely with the CBOR WG, home of the CDDL > 1> specification. >=20 > While we are using CDDL to define the structure, I'm unclear what the = back > and forth that ASDF will have with CBOR here. Are there pieces in = CDDL that > are missing that this model will motivate adding to CDDL? That has already happened (the .feature feature). I could imagine the SDF work will continue to be a fertile ground for = further improving the usability of CDDL in specs of this kind. > 2> It will also engage the still active mailing list of the > 2> dormant JSON WG. >=20 > Is this about json-path, and/or json-schema? Probably more about json data definition (which includes the = json-schema.org proposals that have been inspiring the SDF data = definition components). > 3> Recent proposals to form an IRTF formal description > 3> techniques (FDT) Research Group may lead to another collaboration > 3> partner. >=20 > Where are these proposals occuring, fdt@ietf.org > and at one point will they conclude, Good question. > and > is the timing of this important, critical, or optional to the process? Entirely optional. > 4> The Thing-to-Thing Research Group (T2TRG) and its WISHI program > 4> can be instrumental in engaging researchers and other SDOs in this = space, > 4> or instance W3C WoT, which is working on Thing Description = Templates and > 4> related specifications. >=20 > This part seems rather aspirational. All sorts of communications are > important and beneficial, but is there some kind of implied liason = activity, > or some kind of cross-WG/RG last-call that is implied? T2TRG is not engaging in formal liaisons. It *is* working on getting = people to talk (e.g., last week the discussion we had on Azure DTDL). = For ASDF, getting information from the various ecosystems trying to get = their models expressed in SDF is vital =E2=80=94 preferably in the form = of people from these ecosystems taking part in the work, but ASDF people = taking part in the communications is a good second best. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Aug 8 00:40:36 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50343A0E87 for ; Sat, 8 Aug 2020 00:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_MUTUALBENEFIT=2, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 jkx3qvKXkIcq for ; Sat, 8 Aug 2020 00:40:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417453A0E82 for ; Sat, 8 Aug 2020 00:40:31 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BNvK63VZHz17rq; Sat, 8 Aug 2020 09:40:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <31064.1596838037@localhost> Date: Sat, 8 Aug 2020 09:40:26 +0200 Cc: asdf@ietf.org X-Mao-Original-Outgoing-Id: 618565226.075001-3546167db424aaf5636aeff8454be53c Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 07:40:36 -0000 On 2020-08-08, at 00:07, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Carsten Bormann wrote: >> https://github.com/one-data-model/SDF >=20 >> One Data Model people have a number of feature requests that we = should >> have a look at now. It would be good to have an SDF 1.1 by October >> that addresses some of these requests, and to keep up an = approximately >> bi-monthly rhythm of releases (modulo holiday times). >=20 > 1) What would you call a "release" here? An Internet-Draft that is specifically marked as such (often called = =E2=80=9Cimplementation draft=E2=80=9D in other groups). The intention would be to reach a periodic milestone where OneDM people = and ASDF agree that a specific I-D is useful as a basis for further = OneDM work, e.g., by using that I-D for validating models in the OneDM = playground and convergence processes, and by ecosystem tool builders = modifying their tools to target that I-D in their conversion processes = (which is what enables breaking changes). This could be done in a tick-tock style, with a feature I-D and then a = period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so on. > 2) Are there important ODM member deadlines, meetings or processes = that we > should consider in our milestone process? See above. I am not aware of any specific deadlines. OneDM meets = weekly at the moment, and I would expect us to have some personal = overlap that facilitates communication. I=E2=80=99m not sure we have = all the details of making OneDM=E2=80=99s convergence process work in = the presence of a periodic SDF spec release process; I would expect the = mutual benefit from making that work to motivate OneDM to work on these. > 3) Would SDF be a single document, or a base document plus extensions? More on the side of a single document. A spec language for protocol = bindings might be a conceivable extension. > Are there parts that we can rapidly gain consensus on and publish, = with > discussion about the other parts? The consensus we have on SDF 1.0 is based on existing input from = ecosystem SDOs; it is also based on understanding that the current = limitations will be addressed by further work. So I don=E2=80=99t think = we should be publishing anything quickly now. > Or does draft-onedm-t2trg-sdf-00 represent the consensus part = already, and > there is some "freezer" of other things which were removed during = the > OneDM part of the effort? See above. No freezer, but we did take out some elements that were = meant to support protocol bindings that might go into that other = document. >> Some github issues will now be opened by people who already have >> experienced limitations of SDF 1.0 that should be addressed; of = course, >> other people can submit issues, too. We can have a discussion right = in >> the github issues, or, for more fundamental decisions to be taken, = also >> here in the mailing list. It will probably take a little until we = have >> pull requests based on these issues; we can discuss these then and, = by >> the time the discussion solidifies, we might have a WG. >=20 >> I=E2=80=99m looking forward to SDF 1.1, and the further work of the = ASDF WG-to-be! >=20 > Should publishing 1.0 ASAP be a goal, or should we just do 1.1? 1.0 was =E2=80=9Cpublished=E2=80=9D as an Internet-Draft. I don=E2=80=99t= think we should aim for RFC status until we have at least a handful of = SDOs that have put the majority of their relevant models through the = process. 1.0 is intended to be quickly superseded by 1.1, and that = might happen a couple more times until returns start to diminish. This rapid iterative process may be a bit unusual for IETF. =20 I=E2=80=99d assume we can stabilize the SDF core at 1.3 or 1.4 enough to = go for RFC. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Aug 8 00:45:39 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F043A0E89; Sat, 8 Aug 2020 00:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-UtKKD9c4Tp; Sat, 8 Aug 2020 00:45:35 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CA43A0B82; Sat, 8 Aug 2020 00:45:35 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BNvR21K57zyrT; Sat, 8 Aug 2020 09:45:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <2A11875E-43EA-4227-A6E7-A7F5A09831EC@tzi.org> Date: Sat, 8 Aug 2020 09:45:33 +0200 Cc: asdf@ietf.org, json@ietf.org X-Mao-Original-Outgoing-Id: 618565533.799698-6171c62f7c86e4dd60c9558d09dbb211 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <3271.1596839115@localhost> <2A11875E-43EA-4227-A6E7-A7F5A09831EC@tzi.org> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] [Json] Kicking off ASDF charter discussion X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 07:45:38 -0000 On 2020-08-08, at 09:25, Carsten Bormann wrote: >=20 >> 2> It will also engage the still active mailing list of the >> 2> dormant JSON WG. >>=20 >> Is this about json-path, and/or json-schema? >=20 > Probably more about json data definition (which includes the = json-schema.org proposals that have been inspiring the SDF data = definition components). =E2=80=A6and it is probably worth pointing out that, while SDF itself is = notated in JSON (and thus benefits from CDDL), the data models that SDF = describes cannot be limited just to the expressive gamut of JSON data. = So a JSON data definition format such as those proposed at = json-schema.org can be an inspiration, but cannot on its own solve the = entire problem. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 10 05:51:29 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80BB3A1544 for ; Mon, 10 Aug 2020 05:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oPAYxtPb73X for ; Mon, 10 Aug 2020 05:51:16 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026953A1538 for ; Mon, 10 Aug 2020 05:51:15 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BQG6m3lLSzyYQ; Mon, 10 Aug 2020 14:51:12 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <479.1596838359@localhost> Date: Mon, 10 Aug 2020 14:51:12 +0200 Cc: asdf@ietf.org X-Mao-Original-Outgoing-Id: 618756671.9833339-520057d8b2c1b349218d2bff28fdf249 Content-Transfer-Encoding: quoted-printable Message-Id: <29A07045-CA09-425A-A241-5968C4CBF58B@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <479.1596838359@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Is JSONPATH in scope? X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 12:51:28 -0000 On 2020-08-08, at 00:12, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Carsten Bormann wrote: >> We cannot really start work as a Working Group until chartered: We >> cannot make decisions without Working Group Chairs that call = consensus >> on issues. This does not have to stop us from doing work. >=20 > I have some questions about paragraph two of the core of the charter: > https://github.com/one-data-model/ietf108/issues/5 >=20 > } In the process, some smaller pieces may become usable = independently from > } SDF itself and its applications. JSON Path (similar to, but = different in > } scope from JSON Pointer documented in RFC6901) might be an example = for > } such a spin-off specification -- it is currently defined on a = website > } and would benefit from a more formal definition so it can be used = in > } discovery processes involving SDF models. >=20 > The web site in question is, I think: https://jsonpath.com/ ? > https://goessner.net/articles/JsonPath/ > https://restfulapi.net/json-jsonpath/ <- seems most = authoritative >=20 > Is it a goal to do this work in ASDF? That was not the feedback from the DISPATCH WG on 2020-07-27: https://www.ietf.org/proceedings/108/minutes/minutes-108-secdispatch-04 (Scroll forward to ## JSONPath standardi\[sz]ation - Carsten Bormann ) We now have a mailing list, jsonpath@ietf.org, that needs a kick-off. The idea is to come up with a proposed charter there, and propose that = back to the dispatch mailing list for a final charter. If that process = is successful, there would be two independent WGs =E2=80=94 which makes = sense, as at least initially JSONPath will focus on JSON only. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 11 08:22:06 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931C43A1155 for ; Tue, 11 Aug 2020 08:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ECVveZzbhL71 for ; Tue, 11 Aug 2020 08:21:55 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 389833A1164 for ; Tue, 11 Aug 2020 08:21:53 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id z18so10368884otk.6 for ; Tue, 11 Aug 2020 08:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kGj21iFagQvNX3Julj9FPf6cGS/NdcaSuccjZ+Hbaio=; b=PgTjkDLDtI0oLrXpbjdbLQK3e0oBY9Db5qjSxGRKd5fs5Yw7MqdrPVPHOza5CgweDr RAFT6xgfegXFgX3V9b3tFqr1g/GHbYadIegv9WQJ1raasmkm22sMtmaeQMeGeWaXFxqc F8gV+Wy0mZxdjfVVmoru7eM3Pqbwskn8a3Hf0rJOe/MZjVyTUI48SFoSuAkVL4O24KU5 HdyMiflviNTP+GDnx6zCZpwKG4CXk9Xy2V/rR5u1OF0sXD5FHULkEQfme3R2bY0Ol293 ziN7YlaRHGQcBCPzisyTT0T72av84N44DqW9RFwiloYg95MouaWjaXj8CB8D36HtGCnc 8cSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kGj21iFagQvNX3Julj9FPf6cGS/NdcaSuccjZ+Hbaio=; b=IOnAkeOc5dmuR15U/RZ1NjOdp3Jy0U8ulvaPyyD2Vs405qX2pdKYflUxxjmRHswhva BCK0832IIQYW13vA2zGwv6mxS4BJAsNIaIDdxB+Px0eX/DhlRlQnO1wsZu30fTwCUxdr BGSd2Kvv5QRNryp1IYt9FwpxhvmCV29jZfO3fXI91RujtPYbQWahytsHuEQAExg4WwyA QGR8qnI11RK2Mvj16aTr1+P+dB3gNLTpfve7ifYzNlgESC2dPULIjCnZEj1S9sWFoo7S XljK94/hjLPC8a6/bg87fqq1ds9MgWh+gAQP0olq9roYQqBQ7jbTlqKnxRFp5yxsCvMX YsVQ== X-Gm-Message-State: AOAM533S1hp59aeSLwvw/ZpLrGFl9tlctsM90wKK8Z4LIgW2jUSPkUCx 5v1xszLTwaPFQbxEYbNtVpnJ3E0qO0nm/L+9vx1XNwE5CL4= X-Google-Smtp-Source: ABdhPJzDNN8SJPJcpygWMBzeBOy940oOJViyIs6M3jcTg8pIr9oAV3xwrg5wMpjDMGY3/7Zkfh8yoTlIEqnrOsikYdI= X-Received: by 2002:a9d:4799:: with SMTP id b25mr5609846otf.206.1597159312241; Tue, 11 Aug 2020 08:21:52 -0700 (PDT) MIME-Version: 1.0 From: David Kemp Date: Tue, 11 Aug 2020 11:21:40 -0400 Message-ID: To: asdf@ietf.org Content-Type: multipart/alternative; boundary="00000000000074b94905ac9ba1c5" Archived-At: Subject: [Asdf] Namespacing X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 15:22:04 -0000 --00000000000074b94905ac9ba1c5 Content-Type: text/plain; charset="UTF-8" The SDF description of namespacing seems a bit convoluted: The following example declares a set of namespaces and defines cap as the > default namespace. > > > "namespace": { > "cap": "https://example.com/capability/cap", > "zcl": "https://zcl.example.com/sdf" > }, > "defaultNamespace": "cap", > > > > If no defaultNamespace setting is given, the SDF definition file does not > contribute to a global namespace. As the defaultNamespace is set by giving > a namespace short name, its presence requires a namespace map that contains > a mapping for that namespace short name. > > > If no namespace map is given, no short names for namespace URIs are set > up, and no defaultNamespace can be given. > The namespacing goals of an SDF file are to: 1) contribute to a global namespace 2) reference definitions from the global namespace The last statement sounds like a self-licking ice cream cone: namespace maps have to be set up in order to give a default namespace. That's a true statement, but the reason for setting up a namespace map is to contribute to and reference the global namespace, not to enable someone to give a default namespace. JSON Schema uses the $id keyword to contribute, and the $ref keyword to reference. OpenC2 extends JSON Schema by adding the short name map (called "imports") to allow short references. Is it reasonable to align SDF with JSON Schema by presenting the same information in a clearer way? "id": "https://example.com/capability/cap", "namespace": { "zcl": "https://zcl.example.com/sdf" } --00000000000074b94905ac9ba1c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The SDF description of namespacing seems a bit convoluted:=

The following exampl= e declares a set of namespaces and defines=C2=A0cap=C2=A0as the default namespace.

"namespac=
e": {
  "cap": "htt=
ps://example.com/capability/cap",
  "zcl": "https://zc=
l.example.com/sdf"
},
"defaultNamespace": "cap",

I= f no defaultNamespace setting is given, the SDF definition file does not co= ntribute to a global namespace. As the defaultNamespace is set by giving a = namespace short name, its presence requires a namespace map that contains a= mapping for that namespace short name.

If no namespace = map is given, no short names for namespace URIs are set up, and no defaultN= amespace can be given.


The namespacing = goals of an SDF file are to:
1) contribute to a global namespace
2) r= eference definitions from the global namespace

The last statement so= unds like a self-licking ice cream cone: namespace maps have to be set up i= n order to give a default namespace. That's a true=C2=A0statement, but = the reason for setting up a namespace map is to contribute to and reference= the global namespace, not to enable someone to give a default namespace.
JSON Schema uses the $id keyword to contribute, and the $ref keyword = to reference.=C2=A0 OpenC2 extends JSON Schema by adding the short name map= (called "imports") to allow short references.

Is it reaso= nable to align SDF with JSON Schema by presenting the same information in a= clearer way?

"id": "https://example.com/capability/cap",
"namespace": {
  "zcl": "https://zc=
l.example.com/sdf"
}

<= br>

--00000000000074b94905ac9ba1c5-- From nobody Tue Aug 11 08:34:29 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21E3A1109 for ; Tue, 11 Aug 2020 08:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGY3WtJVVKnJ for ; Tue, 11 Aug 2020 08:34:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87873A1105 for ; Tue, 11 Aug 2020 08:34:24 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BQxhb2KxMzywK; Tue, 11 Aug 2020 17:34:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 11 Aug 2020 17:34:22 +0200 Cc: asdf@ietf.org X-Mao-Original-Outgoing-Id: 618852862.727808-a3582d131079226803a9afcc9a4551f1 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Kemp X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Namespacing X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 15:34:29 -0000 On 2020-08-11, at 17:21, David Kemp wrote: >=20 > Is it reasonable to align SDF with JSON Schema by presenting the same = information in a clearer way? Well, the json-schema.org proposals and SDF go into different spaces, so = I don=E2=80=99t think there is a strong reason to align. More recent versions of the json-schema.org proposals use $id for = modifying a =E2=80=9Cbase URI=E2=80=9D (which is otherwise inherited = from document context as defined in Section 5.1.4 of RFC 3986. We = certainly wouldn=E2=80=99t want a feature that makes the meaning of an = SDF spec depend on from where you are downloading it. I like the fact that the current structure gives the defaultNamespace a = short name as well (=E2=80=9Ccap=E2=80=9D in the example). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 11 09:19:59 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2A3A1182 for ; Tue, 11 Aug 2020 09:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 V-Vg87UPQ2gR for ; Tue, 11 Aug 2020 09:19:56 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 E08D13A1172 for ; Tue, 11 Aug 2020 09:19:55 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id 93so10582870otx.2 for ; Tue, 11 Aug 2020 09:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4zypSis37VlY2SVctHGePaOJUmvZZ6K/N+FrzeVfyiw=; b=H7tV6IeUuBGeY8QwwucFuARuzQohV2Chv/dkIq2uR3B9ZmW8JpDix4u3I+eUoAalMw +w+k9LrgMZi0K7xFXJZMIRED1obprduqQ6ERliARClm5w23ZTpmGNV3rkigoZNFZIdpr klvpw/PKStcfZFQJDaAfh5oCUgFjaLSwc7KHqPKAE8O99Gkj7YhqZokOLt4Fz6XdCfBB fnNi6wN+UazEqsL5exPjfZiiUosRGul4liAo0BuGFlytlb8QyC2s/g71Z0fxcdFiVTar 7g1HcFKrNIjDWPMdrqjKdQxoaZJU2+7NykdThDMBzr4wwZrPiKwfNDLSegPnuBlTKnJj KkUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4zypSis37VlY2SVctHGePaOJUmvZZ6K/N+FrzeVfyiw=; b=t8RNtWXTUFrI2AsL871adzdefQmzqnFiJ6WrYZ2/oAuH2Z1pSQo91VwtZHrYg1tbJW 8hn1I3UJ/VCGvxoQDcNVpyd2NttPfuPFvG3tUx88UrluEU+mGIhskmFxExeIL44XuZBP bC3kGjWlGdAlSBmrGXuQjPeQsDnNi5y8ZEnInrzlMcgRlkL8TbuRGp2/s+GHrWMfIYHV bJ6Lt8TiW/8IBMVyh3Eg69TxciKpJScmIbu8raaCOk0xclwfJOXE243KclwWDKJlX7o4 ofje92yeyWC8g/m9PxBD1B4mOsqdZaFd1yVToLJG8ykQeGJ3CJyg3xs+O7DE2j3oO7PP 7g9g== X-Gm-Message-State: AOAM5337M7SfnxZ3YtXSyLMsuIltfZUTCiNlzqw6gKNl4zqR0a6ZXupJ DiCOStd+ySz7rFRdu8RwulaQi+Rp5lv+YkzclX4MoZ14un4= X-Google-Smtp-Source: ABdhPJyD8ARUqvSc5nhe4bpwuR1f+MMegfH5qTiEGvkm++thDZLI5P2PI2UHnP+E2bYXjaXlcGXWRf7itBpHC5G99jw= X-Received: by 2002:a9d:4799:: with SMTP id b25mr5868927otf.206.1597162795205; Tue, 11 Aug 2020 09:19:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Kemp Date: Tue, 11 Aug 2020 12:19:42 -0400 Message-ID: To: Carsten Bormann Cc: asdf@ietf.org Content-Type: multipart/alternative; boundary="0000000000000e880e05ac9c711b" Archived-At: Subject: Re: [Asdf] Namespacing X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 16:19:58 -0000 --0000000000000e880e05ac9c711b Content-Type: text/plain; charset="UTF-8" An XML "prefix" (short name) is local to the file containing its assignment, and because it is short, it is not globally-unique. Attempting to bind a short name to a global name beyond the local scope will inevitably lead to collisions, or to registration of reserved short names, or to conventions that attempt to minimize collisions of short names. That's a can of worms that could be easily avoided by not defining non-local short names in the first place. The defaultNamespace *could *be given a short name, but it is never used in the local scope. So why bother, except to invite trouble? Regards, Dave --0000000000000e880e05ac9c711b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An XML "prefix" (short nam= e) is local to the file containing its assignment, and because it is short,= it is not globally-unique.

Attempting to bind a short name to a glo= bal name beyond the local scope will inevitably lead to collisions, or to r= egistration of reserved short names, or to conventions that attempt to mini= mize collisions of short names.=C2=A0 That's a can=C2=A0of worms that c= ould be easily avoided by not defining non-local short names in the first p= lace.

The defaultNamespace could be given a short name, but i= t is never used in the local scope.=C2=A0 So why bother, except to invite t= rouble?

Regards,
Dave
--0000000000000e880e05ac9c711b-- From nobody Fri Aug 14 07:40:17 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15C43A120A for ; Fri, 14 Aug 2020 07:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 UBRL26AFWndZ for ; Fri, 14 Aug 2020 07:40:11 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049693A1208 for ; Fri, 14 Aug 2020 07:40:10 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id k4so8327061oik.2 for ; Fri, 14 Aug 2020 07:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=H7OEWRgmQwNLR7qr1P7SoLozccQjhz8ltsD54kb0CCc=; b=uzIJQnVhhB+z6mlR54ARD4HZzOxubYj7VKDU6fhpi1syy2I/sPYEuU6SM0GyGbC31q hmx6tgDxJLYpbUYSWsQmqGtFR1C5l18F6rAmWxKPyfeze6C4Y3KqG/SMuMQqXwuDKjTm iOZkGXhwcdtFXY/UmDBjcMbrRPferXPUMPxX6UKHfFhrwWpAHDiTV+y6HtCIUSqw6nY5 YeFJhlq2utQleLrxyPnVDC8Yt8EMIBLExwgAPElmcUGdGy1FQQ8HqcFVvh05/i8BK0J6 43C/Y+Y4Yb5Hqqc7UdC2VLUtE1YDCaIFyEbkBOKA1DXHwjKUu2wuZXKWouQNJgz8cjgT sq0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=H7OEWRgmQwNLR7qr1P7SoLozccQjhz8ltsD54kb0CCc=; b=ThGFE7WjOwUesI+f93Uui/NuxM5nY6PxUSfvJv8T5vzvyrZuRZV2Qw5haUVNac5vSS LiD5fQMyrGZfHU1rC1nrs7q0AcNa/+/MN0UpcYYciLjwzitFfnB9fUHNUw3EHSZdFf6N vst/1FdsErOQG1Z5O1V8OAulx8pTgS+a1AekIbQyk9siGx4OniCQjlAMBOApsdTdab0c FY1mJxzMMYU101xqbRwjH2PS3RlsGou9L3kvawndrfu+DnyJkLXxZVXiiUKBHsBFCRCI cuRNKNqPblSZlTCG0IrT/z7HbVM1DX4XrwvCm28+8THIC4mKQvi0by1skK9nyS5iZy2s UNVA== X-Gm-Message-State: AOAM5331q6fs0F2nwd5pMx9EV0O9ifSjRnolOeq2QoeV5BCHfcdO8kEC cyj0kCzQvTqQtHpwIx+BdNahxAZhCLeVdihVZggjco73WT42lw== X-Google-Smtp-Source: ABdhPJw+jxdDwA1l19hGj4KoisOysMgnYkXjPzNQIJOrCCVWTcdUs/riQn/FbiBzASFE0OZ3e4ctSCt+/PN0lHuvV1s= X-Received: by 2002:aca:51c5:: with SMTP id f188mr1625281oib.114.1597416009845; Fri, 14 Aug 2020 07:40:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Kemp Date: Fri, 14 Aug 2020 10:39:58 -0400 Message-ID: To: asdf@ietf.org Content-Type: multipart/alternative; boundary="000000000000d34e5b05acd76506" Archived-At: Subject: Re: [Asdf] ASDF Digest, Vol 3, Issue 4 X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 14:40:16 -0000 --000000000000d34e5b05acd76506 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We certainly don't want a namespace URI to change depending on it's download location! The issue I see is calling something related to JSON a "default namespace". XML data has namespaces, JSON data does not. Namespacing applies only to schemas -- a namespace is a unique identifier from which to obtain type definitions. An SDF file can assert with confidence " https://example.com/capability/cap" is my namespace, my unique identifier. But what does it mean for an SDF file to say "cap is my defaultNamespace"? Default for what? Under what circumstances would an SDF namespace be missing for which a default would need to be supplied? The purpose of namespacing is to enable independent development of capabilities, and later, smooth integration of those capabilities. If two people from two different organizations develop IoT devices and both think it would be cool to give their SDF files a defaultNamespace of "cap", what happens when a third organization tries to use them together? "cap" might be better understood as an instantiation of "self" - a class doesn't know it's own identifier until it is instantiated, and different instantiations have different identifiers. At the time SDF file A is written A's author has no idea who will be using namespace A or what short name they will use to refer to it. So another way of representing the same information would be: "namespace": { "default": "https://example.com/capability/cap", "zcl": "https://zcl.example.com/sdf" } where "default" (or "self") is a reserved word meaning "this file's namespace". If SDF makes a file authoritative for its own short name, it will need to describe what happens when two organizations pick the same short name to refer to their respective namespaces. That can be done, it just seems unnecessary. Regards, Dave From: David Kemp > Is it reasonable to align SDF with JSON Schema by presenting the same > information in a clearer way? > > > > "id": "https://example.com/capability/cap", > "namespace": { > "zcl": "https://zcl.example.com/sdf" > } > > > > > From: Carsten Bormann > > Well, the json-schema.org proposals and SDF go into different spaces, so >> I don=E2=80=99t think there is a strong reason to align. > > > > More recent versions of the json-schema.org proposals use $id for >> modifying a =E2=80=9Cbase URI=E2=80=9D (which is otherwise inherited fro= m document context >> as defined in Section 5.1.4 of RFC 3986. We certainly wouldn=E2=80=99t = want a >> feature that makes the meaning of an SDF spec depend on from where you a= re >> downloading it. > > > > I like the fact that the current structure gives the defaultNamespace a >> short name as well (=E2=80=9Ccap=E2=80=9D in the example). > > > --000000000000d34e5b05acd76506 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We certainly don't want a namespace URI to change= depending on it's download location!

The issue I see is calling= something related to JSON a "default namespace".=C2=A0 XML data = has namespaces, JSON data does not.=C2=A0 Namespacing applies only to schem= as -- a namespace is a unique identifier from which to obtain type definiti= ons.=C2=A0 An SDF file can assert with confidence "https://example.com/capability/cap" is= my namespace, my unique identifier.

But what does it mean for an SD= F file to say "cap is my defaultNamespace"?=C2=A0 Default for wha= t?=C2=A0 Under what circumstances would an SDF namespace be missing for whi= ch a default would need to be supplied?

The pu= rpose of namespacing is to enable independent development of capabilities, = and later, smooth integration of those capabilities.=C2=A0 If two people fr= om two different organizations develop IoT devices and both think it would = be cool to give their SDF files a defaultNamespace of "cap", what= happens when a third organization tries to use them together?

"= ;cap" might be better=C2=A0understood=C2=A0as an instantiation of &quo= t;self" - a class doesn't know it's own identifier until it is= instantiated, and different instantiations have different identifiers.=C2= =A0 At the time SDF file A is written A's author has no idea who will b= e using namespace A or what short name they will use to refer to it.
So another way of representing the same information would be:

=C2= =A0 =C2=A0 "namespace": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &= quot;default": "ht= tps://example.com/capability/cap",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = "zcl": "https://zcl.example.com/sdf"
=C2=A0 =C2=A0 }

where= "default" (or "self") is a reserved word meaning "= ;this file's namespace".

If SDF makes a file authoritative = for its own short name, it will need to describe what happens when two orga= nizations pick the same short name to=C2=A0refer=C2=A0to their respective n= amespaces.=C2=A0 That can be done, it just seems unnecessary.

Regard= s,
Dave

=C2=A0

From:=C2=A0David Kemp <dk190a@gmail.com>
Is it reason= able to align SDF with JSON Schema by presenting the same information in a = clearer way?

&qu=
ot;id": "https://example.com/capability/cap",
"namespace": {
  "zcl": "https://zcl.example.com/sdf"
}


From:=C2=A0Carsten Bormann <cabo@tzi.org>

Well, the json-schema.org proposals and SDF go into different spaces, so I= don=E2=80=99t think there is a strong reason to align.=C2=A0
<= /blockquote>
=C2=A0
More recent versions of the json-schema.org proposals use $id for modifyin= g a =E2=80=9Cbase URI=E2=80=9D (which is otherwise inherited from document = context as defined in Section 5.1.4 of RFC 3986.=C2=A0 We certainly wouldn= =E2=80=99t want a feature that makes the meaning of an SDF spec depend on f= rom where you are downloading it.=C2=A0
=C2=A0
I like the fact that the current structure gives the defaultNamespace a sho= rt name as well (=E2=80=9Ccap=E2=80=9D in the example).

--000000000000d34e5b05acd76506-- From nobody Wed Aug 19 06:11:06 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792053A099C for ; Wed, 19 Aug 2020 06:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_MUTUALBENEFIT=2, SPF_HELO_NONE=0.001, SPF_PASS=-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 DwGXFdP4vG1p for ; Wed, 19 Aug 2020 06:11:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61ED83A096C for ; Wed, 19 Aug 2020 06:11:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B05B038A02; Wed, 19 Aug 2020 08:50:09 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VVb8b2TMRvix; Wed, 19 Aug 2020 08:50:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2761638A01; Wed, 19 Aug 2020 08:50:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C99B27B; Wed, 19 Aug 2020 09:10:59 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , asdf@ietf.org In-Reply-To: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 13:11:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-08-08, at 00:07, Michael Richardson w= rote: >> >> Signed PGP part >> >> Carsten Bormann wrote: >>> https://github.com/one-data-model/SDF >> >>> One Data Model people have a number of feature requests that we sho= uld >>> have a look at now. It would be good to have an SDF 1.1 by October >>> that addresses some of these requests, and to keep up an approximat= ely >>> bi-monthly rhythm of releases (modulo holiday times). >> >> 1) What would you call a "release" here? > An Internet-Draft that is specifically marked as such (often called > =E2=80=9Cimplementation draft=E2=80=9D in other groups). > The intention would be to reach a periodic milestone where OneDM peop= le > and ASDF agree that a specific I-D is useful as a basis for further > OneDM work, e.g., by using that I-D for validating models in the OneDM > playground and convergence processes, and by ecosystem tool builders > modifying their tools to target that I-D in their conversion processes > (which is what enables breaking changes). I'm not exactly thrilled about having an I-D hang around for a long time li= ke this. > This could be done in a tick-tock style, with a feature I-D and then a > period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so > on. I'm even less thrilled about assigning version numbers to "Work-in-progress" If we could iterate on RFCs faster, would that also work? It seems to me that maybe we should fork/multiprocess: (1) take current document, SDF 1.0, kick it off as Informational<*> and go out to get reviews and approvals immediately. (2) simultaenously, start on 1.1/1.2 as you suggest, pulling in the review comments into that document as we go, producing a -bis document late next year. <*> - this is the typical publish externally developed spec as Informationa= l, then revise it within the IETF, and publish as "standard". But, I think that the SDF document might always be Informational :-) I think that we could reserve a point prior to RFC publication of (1) at which we might decide not to publish 1.0. I big concern I have, thinking about publication, is that I think that the subject matter is sufficiently esoteric compared to, say, BGP extensions or IMAP extensions, that getting reviewers who aren't already involved with OneDM will be difficult. >> 2) Are there important ODM member deadlines, meetings or processes t= hat we >> should consider in our milestone process? > See above. I am not aware of any specific deadlines. OneDM meets > weekly at the moment, and I would expect us to have some personal > overlap that facilitates communication. I=E2=80=99m not sure we have= all the > details of making OneDM=E2=80=99s convergence process work in the pre= sence of a > periodic SDF spec release process; I would expect the mutual benefit > from making that work to motivate OneDM to work on these. okay, thank you. Basically, you are saying that we can self-impose/self-organize deadlines. >> 3) Would SDF be a single document, or a base document plus extension= s? > More on the side of a single document. A spec language for protocol = bindings might be a conceivable extension. >> Are there parts that we can rapidly gain consensus on and publish, w= ith >> discussion about the other parts? > The consensus we have on SDF 1.0 is based on existing input from > ecosystem SDOs; it is also based on understanding that the current > limitations will be addressed by further work. So I don=E2=80=99t th= ink we > should be publishing anything quickly now. >>> Some github issues will now be opened by people who already have >>> experienced limitations of SDF 1.0 that should be addressed; of cou= rse, >>> other people can submit issues, too. We can have a discussion righ= t in >>> the github issues, or, for more fundamental decisions to be taken, = also >>> here in the mailing list. It will probably take a little until we = have >>> pull requests based on these issues; we can discuss these then and,= by >>> the time the discussion solidifies, we might have a WG. >> >>> I=E2=80=99m looking forward to SDF 1.1, and the further work of the= ASDF WG-to-be! >> >> Should publishing 1.0 ASAP be a goal, or should we just do 1.1? > 1.0 was =E2=80=9Cpublished=E2=80=9D as an Internet-Draft. I don=E2= =80=99t think we should aim > for RFC status until we have at least a handful of SDOs that have put > the majority of their relevant models through the process. 1.0 is > intended to be quickly superseded by 1.1, and that might happen a > couple more times until returns start to diminish. > This rapid iterative process may be a bit unusual for IETF. > I=E2=80=99d assume we can stabilize the SDF core at 1.3 or 1.4 enough= to go for RFC. I understand your concern about "release.0" issue, and that you wish to validate things. I want to point out that this is precisely the difference between Proposed Standard (1.0) and Internet Standard (1.1). Personally, I have been pushing back loudly against continued grade deflati= on in the IETF process. So I would personally be loath to put this into a ch= arter. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl89JOMACgkQgItw+93Q 3WWTgQgAs3Ed5Dh/0Y5lRb2kPcR5H+Apurzf4d5tuKvqOL5iN6Gt/kGue1OCTm2W XHw8B9BYf3RRXpg7dGUZGd2a8JzGQm4SzmIX0vR5meZ7kURuS7QnOsvzL5F2MD6+ IireOO8Gv8f+BADv1bgN+gA2O+ELhPmPtGgQuxaHHVsmB2WaCi69LFO5y6oHqQuF pSpT9eqGgKu++UOHJ1efItonH7EuV7PBi/QgXMqZ4Rwnldf0zYS/qsvj0LyDsJU0 Azn9DmL10ueDYB983+5ahSmjTUDjmZwlSkFWMc/sVMdoTHTzCi8eGRsOxfkOJ9J/ oGVTWMDaXCg6uJHC9u/pC53pY5iLdA== =NYsi -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 19 06:18:17 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41293A09B3 for ; Wed, 19 Aug 2020 06:18:15 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcFiB8UX7_r5 for ; Wed, 19 Aug 2020 06:18:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289013A09AD for ; Wed, 19 Aug 2020 06:18:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C144D38A02; Wed, 19 Aug 2020 08:57:20 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qZwT3-iWR4o3; Wed, 19 Aug 2020 08:57:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9247B38A01; Wed, 19 Aug 2020 08:57:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4144E7B; Wed, 19 Aug 2020 09:18:11 -0400 (EDT) From: Michael Richardson To: asdf@ietf.org, Barry Leiba In-Reply-To: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Asdf] on ASDF cycling at internet-draft X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 13:18:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Barry, I'm uncomfortable with a plan to have more than implementation draft as a WIP. While it seems that this where the IETF has evolved to, I'm really not sure that planning it this way is in the right spirit. I would significantly prefer to iterate at PS, but the hurdles seem higher than ever. I'd love to be wrong! Maybe someone has some 3933 process experiment ideas that could be done. Carsten Bormann wrote: >> 1) What would you call a "release" here? > An Internet-Draft that is specifically marked as such (often called > =E2=80=9Cimplementation draft=E2=80=9D in other groups). > The intention would be to reach a periodic milestone where OneDM peop= le > and ASDF agree that a specific I-D is useful as a basis for further > OneDM work, e.g., by using that I-D for validating models in the OneDM > playground and convergence processes, and by ecosystem tool builders > modifying their tools to target that I-D in their conversion processes > (which is what enables breaking changes). > This could be done in a tick-tock style, with a feature I-D and then a > period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so > on. ... >> Should publishing 1.0 ASAP be a goal, or should we just do 1.1? > 1.0 was =E2=80=9Cpublished=E2=80=9D as an Internet-Draft. I don=E2= =80=99t think we should aim > for RFC status until we have at least a handful of SDOs that have put > the majority of their relevant models through the process. 1.0 is > intended to be quickly superseded by 1.1, and that might happen a > couple more times until returns start to diminish. > This rapid iterative process may be a bit unusual for IETF. > I=E2=80=99d assume we can stabilize the SDF core at 1.3 or 1.4 enough= to go for RFC. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl89JpIACgkQgItw+93Q 3WXkvAgAt62+fUv6Lr77q1UL++F+73nui+BoFk/XtLZ1a/feLDD2v79d3XreIsyV H9TCLXvyVksQdl7eV5WxJLl5dkkw2moPBhkTkpEfIznCniR96jlRkoiN1OG8GyDV RFNILPqmgZPv4AKfhb12TE63J5xI5x1injaMLg0AXminvtL4/dOI6y5YZNxfukBI KV0b+PYGY4lWDjPM0siKjHy3tneieVlODxtoFxZP/RGhpWVVX+DvHXmYcD+raJVt QIZmEVLw2MtL7T1BLOLdocT8zMuMGQKJT7XdmlV3ch/Zuz4F+FdcpVXfR19+T3Hs ieQ151vfcptxBRNqlbecglQSb86L+A== =fYdw -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 19 06:20:26 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4374D3A09BE for ; Wed, 19 Aug 2020 06:20:25 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXL7HkA6ng7h for ; Wed, 19 Aug 2020 06:20:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE993A09BC for ; Wed, 19 Aug 2020 06:20:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B064C38A02; Wed, 19 Aug 2020 08:59:29 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DDUOfWyrHL96; Wed, 19 Aug 2020 08:59:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CD68A38A01; Wed, 19 Aug 2020 08:59:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 57CBA7B; Wed, 19 Aug 2020 09:20:20 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , asdf@ietf.org In-Reply-To: <29A07045-CA09-425A-A241-5968C4CBF58B@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <479.1596838359@localhost> <29A07045-CA09-425A-A241-5968C4CBF58B@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] Is JSONPATH in scope? X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 13:20:25 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: >> The web site in question is, I think: https://jsonpath.com/ ? >> https://goessner.net/articles/JsonPath/ >> https://restfulapi.net/json-jsonpath/ <- seems most authoritative >> >> Is it a goal to do this work in ASDF? > That was not the feedback from the DISPATCH WG on 2020-07-27: > https://www.ietf.org/proceedings/108/minutes/minutes-108-secdispatch-04 > (Scroll forward to > ## JSONPath standardi\[sz]ation - Carsten Bormann > ) Ah, I was unaware that this had happened. As I understand, you previously said that we would not need to normatively depend upon the results: we'd include just enough text to get by. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl89JxQACgkQgItw+93Q 3WWRLQf9Htjj9c94a7oR8oLScGI+/v0yugRbTGgq7OvHAv4IyMD1k6NFZdPpJaWF FfN9rY28qDZk/3XIl37uuXuffKzoAHIL0KJJ4D8ZtBETctTE+lTRZNZrq3n6PbM7 4zIzpy59/c6fmGNgGu8YhNIjIGNN9j0J8HrEzk17lj5Qj2WJ5K4nLgbPAmwF61o+ I52g+juNUfaTl1Wcfab4q1CRccv2F2jOfdNlwBpl4MiUiyg8kT20gv1ImLFo/W1T 36UaSK/95n9rxNP45OMcJBHkC5QpnXA+UIL8yotUUYTPnhMbCdPtrKm9NqEnlDIX edWoi8B5EcbXixgIFPmGB3OG9NatrA== =K6zM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 19 08:06:48 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD643A0B05 for ; Wed, 19 Aug 2020 08:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_MUTUALBENEFIT=2, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 k-RLxA0cY-Gt for ; Wed, 19 Aug 2020 08:06:43 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775373A0ABB for ; Wed, 19 Aug 2020 08:06:42 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BWrhv3KlxzyXm; Wed, 19 Aug 2020 17:06:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <9820.1597842659@localhost> Date: Wed, 19 Aug 2020 17:06:39 +0200 Cc: asdf@ietf.org X-Mao-Original-Outgoing-Id: 619542399.052518-7605aee08774c96b1b1bfce0476fa902 Content-Transfer-Encoding: quoted-printable Message-Id: <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 15:06:46 -0000 Hi Michael, > I'm not exactly thrilled about having an I-D hang around for a long = time like this. Maybe you should tell the HTTP/2, QUIC, =E2=80=A6 groups. This works well when there is a closely knit community that actually has = made a commitment to follow through on the updates. (I remember = draft-martini vs. draft-kompella etc. for counter-examples, where drafts = escaped into products=E2=80=A6) >> This could be done in a tick-tock style, with a feature I-D and then = a >> period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so >> on. >=20 > I'm even less thrilled about assigning version numbers to = "Work-in-progress" > If we could iterate on RFCs faster, would that also work? Maybe, but this is not our ocean to boil... > It seems to me that maybe we should fork/multiprocess: > (1) take current document, SDF 1.0, kick it off as Informational<*> > and go out to get reviews and approvals immediately. That is exactly *not* the point. This would make it look like = specifiers get to choose between all the RFCs that we drop. = Internet-Drafts are =E2=80=9Cobsoleted=E2=80=9D (expired) much more = solidly than RFCs ever are. > (2) simultaenously, start on 1.1/1.2 as you suggest, pulling in the > review comments into that document as we go, producing a -bis > document late next year. We want to be faster than that! > <*> - this is the typical publish externally developed spec as = Informational, > then revise it within the IETF, and publish as "standard". Yes, and, again, that is *not* the model here. People will not stick to SDF 1.0 when there is a better SDF 1.1, and the = historical interest in document what SDF 1.0 was is rather limited. > But, I think that the SDF document might always be Informational = :-) That is not the intention either. We do want to converge to something = that is stable. (Which still will have extensions.) > I think that we could reserve a point prior to RFC publication of (1) = at > which we might decide not to publish 1.0. We do not want to =E2=80=9Cpublish=E2=80=9D (as an RFC) 1.0. > I big concern I have, thinking about publication, is that I think that = the > subject matter is sufficiently esoteric compared to, say, BGP = extensions or > IMAP extensions, that getting reviewers who aren't already involved = with > OneDM will be difficult. I=E2=80=99m seeing that danger, but I=E2=80=99m also seeing good = cross-area review in other places. We will have to seek out for that. >=20 >>> 2) Are there important ODM member deadlines, meetings or processes = that we >>> should consider in our milestone process? >=20 >> See above. I am not aware of any specific deadlines. OneDM meets >> weekly at the moment, and I would expect us to have some personal >> overlap that facilitates communication. I=E2=80=99m not sure we have = all the >> details of making OneDM=E2=80=99s convergence process work in the = presence of a >> periodic SDF spec release process; I would expect the mutual benefit >> from making that work to motivate OneDM to work on these. >=20 > okay, thank you. > Basically, you are saying that we can self-impose/self-organize = deadlines. Given the personnel overlap, I think we=E2=80=99ll get communication = about important outside milestones. (I still remember vividly a CES = deadline we blew as the CoRE WG.) >=20 >>> 3) Would SDF be a single document, or a base document plus = extensions? >=20 >> More on the side of a single document. A spec language for protocol = bindings might be a conceivable extension. >=20 >>> Are there parts that we can rapidly gain consensus on and publish, = with >>> discussion about the other parts? >=20 >> The consensus we have on SDF 1.0 is based on existing input from >> ecosystem SDOs; it is also based on understanding that the current >> limitations will be addressed by further work. So I don=E2=80=99t = think we >> should be publishing anything quickly now. >=20 >>>> Some github issues will now be opened by people who already have >>>> experienced limitations of SDF 1.0 that should be addressed; of = course, >>>> other people can submit issues, too. We can have a discussion = right in >>>> the github issues, or, for more fundamental decisions to be taken, = also >>>> here in the mailing list. It will probably take a little until we = have >>>> pull requests based on these issues; we can discuss these then and, = by >>>> the time the discussion solidifies, we might have a WG. >>>=20 >>>> I=E2=80=99m looking forward to SDF 1.1, and the further work of the = ASDF WG-to-be! >>>=20 >>> Should publishing 1.0 ASAP be a goal, or should we just do 1.1? >=20 >> 1.0 was =E2=80=9Cpublished=E2=80=9D as an Internet-Draft. I don=E2=80=99= t think we should a >> for RFC status until we have at least a handful of SDOs that have put >> the majority of their relevant models through the process. 1.0 is >> intended to be quickly superseded by 1.1, and that might happen a >> couple more times until returns start to diminish. >=20 >> This rapid iterative process may be a bit unusual for IETF. >> I=E2=80=99d assume we can stabilize the SDF core at 1.3 or 1.4 enough = to go for RFC. >=20 > I understand your concern about "release.0" issue, and that you wish = to > validate things. I want to point out that this is precisely the = difference > between Proposed Standard (1.0) and Internet Standard (1.1). 1.4 might be an Internet Standard, if 1.3 becomes a Proposed Standard = (or the numbers could be 1.12 and 1.8; let=E2=80=99s see). > Personally, I have been pushing back loudly against continued grade = deflation > in the IETF process. So I would personally be loath to put this into = a charter. I understand the sentiment. I still think this is a good way to run this, for *this* specific = effort. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 19 08:15:32 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388513A0861 for ; Wed, 19 Aug 2020 08:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhGkeGrl5c20 for ; Wed, 19 Aug 2020 08:15:27 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADA73A08C0 for ; Wed, 19 Aug 2020 08:15:26 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BWrv01xBNzyXh; Wed, 19 Aug 2020 17:15:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> Date: Wed, 19 Aug 2020 17:15:23 +0200 Cc: asdf@ietf.org X-Mao-Original-Outgoing-Id: 619542923.869056-644c18f3e45a80563b9b16552e54398e Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 15:15:30 -0000 Picking out this one: On 2020-08-19, at 17:06, Carsten Bormann wrote: >=20 >> So I would personally be loath to put this into a charter. Do we have to? I think the WG can define (and modify, as needed) its = mode of operation and its rhythm; that does not need to be part of the = charter. I=E2=80=99m asking because I believe we should send off the charter to = our AD soon, so we need to find out whether there is anything left that = needs to be added. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 19 13:23:43 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939CB3A0DEF for ; Wed, 19 Aug 2020 13:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 FjdknPEcXzXg for ; Wed, 19 Aug 2020 13:23:40 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50040.outbound.protection.outlook.com [40.107.5.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9456B3A0B99 for ; Wed, 19 Aug 2020 13:23:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L02PAqW+c4D354B+IP/NkgKuhr+hJYzXylhaxw3rWw2PgK3bOL0cOdVy+kJ3TdH3BzZLORgynId/6bP1Ldl3FUZcuh7FEqG/iVPZzeSLt68r8iDk9iT82DF75W9K98dGlHrkCJy6+9Ht4DKpsH9b7l9Kc5Jh0YGtb/jtRcJ+44B2Xap/YUmbKSow3v10CRTKQXezQ8Fq+znIFxK/j5+DPbnLJSEi997JqkBzhdENOYiXRpUXz+9NMLBFHcIBduJa4aLbdvINlxXODfxF5PyeXfmPY6hargb8RQ/5B3qYj9yqLFP9d+/AIHsXK0RCxSXPiWOYXBKVJXfdGle06Uoddw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q/wCeRSMc/oQeh5PUHM8OE7zHNOTrvpC4mqUTmkUvGQ=; b=jWt0kp15/6rNp6HIsYOWImxUqTL+vq0Uk5xH/dA3XODW3P8GSz5fLw4NBnsFKPDYVvTMZCSmKZF16ZAlinwavSXBWv50faLoGpW3zRMewWrxwxZGHl4k6U/QeGndqoagzUlQ3hkLPDMPgYZyodMor9bRxaVWagoeDPMhKejSbUFqs0fBz+a5AdEWNpl1YRlNanlqt6EVFn9WdDzwE68VkVH5DFTZ2eGpXix9BqmQ7BXBNJTDF7vgfLJ5kMFchMlesBoZMBuA0j87LGyPgvNeZrjUmfs9a3fm908ZMMdfJr1si7gVwlE5zN0IR4d3Iay+kZx3q4isPFTNv1Cw57HH8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=Q/wCeRSMc/oQeh5PUHM8OE7zHNOTrvpC4mqUTmkUvGQ=; b=SzrIQf48SMLAj4uwswSfV6JcOW2RaOVUgXMJr993Cdj2OXhbxnSTQbHRDBFaqcCnoubxvDjC2HJoJUy37CbQoVEvGpDBeO/zanLVDZ3Y/fBeTmCNIoaqL1LCtpw+RYFRMHnNpBmGV9/WIhlUj4uxSZpDGS+87UZkaMqrS+mVjNQ= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB3147.eurprd07.prod.outlook.com (2603:10a6:7:39::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.20; Wed, 19 Aug 2020 20:23:33 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::9b1:f546:660f:f8ed]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::9b1:f546:660f:f8ed%7]) with mapi id 15.20.3305.019; Wed, 19 Aug 2020 20:23:33 +0000 From: Niklas Widell To: Carsten Bormann , Michael Richardson CC: "asdf@ietf.org" Thread-Topic: [Asdf] Kicking off ASDF Thread-Index: AQHWapRe7HPOiNhEpEmmmY1bH7JUJqktORCAgACgIwCAEaYAgIAAIFGAgAACcYCAAHehgA== Date: Wed, 19 Aug 2020 20:23:33 +0000 Message-ID: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [37.123.165.254] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2aeeee69-3727-4181-84a6-08d8447dbef9 x-ms-traffictypediagnostic: HE1PR07MB3147: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VaJCn65CxwW/vTFvoUlkGi9bdAz/V1DCo1IVltRo8PT2pksd9RvttUru+StoFzg/QijLbOTOXPo3Uz9Xy/pUuc5sOrB/8vaEYvjY5wM49fkdYWD7xqrR6YCz3VSngijcZEHM5sUdn0+opk9/Mk+MMJRcmd9VKm3kHuzGMbkmadWfqo62ntZDV6dVUKlz9xqBxQGsQX2KqpW4ppoAO+WWY4mNXBklVoU2MWqu9K5hHsSfbWvS4mJELyoY/vQpdEryy1QJAj9JSbzXdNDqphZKzReYPvJMm0wABfrJmJVzpH/Vt+SsvgC9yp7c4/0yDze8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(396003)(39860400002)(376002)(91956017)(4326008)(76116006)(2906002)(6486002)(66946007)(316002)(110136005)(66476007)(2616005)(66446008)(64756008)(66556008)(186003)(478600001)(83380400001)(33656002)(71200400001)(53546011)(8936002)(5660300002)(86362001)(6506007)(6512007)(8676002)(36756003)(44832011)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Ah0Y+RklRHDO0SMxZ7A9jaP4xxMkDjBV4ow67SX9vanPXD3rQpIPrrcUMt+Kco/wRsMluJANjMcOSLvujOEk6u8WejcqY6kfeoHDsiYyJATtNjlFV4SfTCa9/XHuKp4AONbFUkvQZAnG9dex+9r30POsEWw9MEL28kSZ91cAYkg6QLAroQ5sHi6QnCJFZtqsDmnHBJK6m3U6EDcCquNEUaqn0aw60JE9L7PLmitjUcj+D75XKjNQeZl9ehWS/CLWEDr0lsgkFlwLD9UsmifsxHe4i3lb7x/6rB/WMbO0WJWS67M0+sjEwnsOEYdIT8DvfYUfwTe8MMdRB7MxxUJn1NY2HvceYb91qxTn9rysQT93krsHwj0Md1Dhj2kgK9iTggmGYx1IE5X4aHdmyDwjVIyAnAzjCDP9kgqR6D8E75t00z4yK7Gjub9JOXg+onKVK3E4U3ayScb4ubpharn6Oq3V3Cj11kECHq99OnJDZcAjaWQHZO97j/gg2bcvRr8cdKPlgTOe94d6AAcBEcRMMpptgY32e6z7BRI8O0+47NO74bexcaAm7o4Zc4KdZDADYX+xVRjq0xeXxdZ51YYZI/7OKPb35ShVWz4TSxXuO7mAxZqy58ERaeKB418JaiAZVGsly8uKHm0sIOQPDR+dXw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8B05186A8FC07E45A31117317F9236F7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2aeeee69-3727-4181-84a6-08d8447dbef9 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 20:23:33.6930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mneUilZuGJzsovzhVZUGJ3rVP969DCdtO4T5BQrZHc/9K36B7C3ai1IIcTLm/iDRHTPm/56JMcjHiGmV0a7yEsC6U7dK6ku+bun+eJd5zNI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3147 Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 20:23:42 -0000 DQrvu79PbiAyMDIwLTA4LTE5LCAxNzoxNSwgIkFTREYgb24gYmVoYWxmIG9mIENhcnN0ZW4gQm9y bWFubiIgPGFzZGYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2Fib0B0emkub3JnPiB3 cm90ZToNCg0KICAgIFBpY2tpbmcgb3V0IHRoaXMgb25lOg0KDQogICAgT24gMjAyMC0wOC0xOSwg YXQgMTc6MDYsIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiB3cm90ZToNCiAgICA+IA0K ICAgID4+IFNvIEkgd291bGQgcGVyc29uYWxseSBiZSBsb2F0aCB0byBwdXQgdGhpcyBpbnRvIGEg Y2hhcnRlci4NCg0KICAgIERvIHdlIGhhdmUgdG8/ICBJIHRoaW5rIHRoZSBXRyBjYW4gZGVmaW5l IChhbmQgbW9kaWZ5LCBhcyBuZWVkZWQpIGl0cyBtb2RlIG9mIG9wZXJhdGlvbiBhbmQgaXRzIHJo eXRobTsgdGhhdCBkb2VzIG5vdCBuZWVkIHRvIGJlIHBhcnQgb2YgdGhlIGNoYXJ0ZXIuDQoNCiAg ICBJ4oCZbSBhc2tpbmcgYmVjYXVzZSBJIGJlbGlldmUgd2Ugc2hvdWxkIHNlbmQgb2ZmIHRoZSBj aGFydGVyIHRvIG91ciBBRCBzb29uLCBzbyB3ZSBuZWVkIHRvIGZpbmQgb3V0IHdoZXRoZXIgdGhl cmUgaXMgYW55dGhpbmcgbGVmdCB0aGF0IG5lZWRzIHRvIGJlIGFkZGVkLg0KDQpJZiBpdCBpcyBu b3QgbmVlZGVkLCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBkZXNjcmliZSBpbiBkZXRhaWwgaW4g dGhlIGNoYXJ0ZXIgdGhlIGZ1dHVyZSBldm9sdXRpb24gc3RlcHMgb2YgU0RGIGJleW9uZCB3aGF0 IHdlIGNhbiBzZWUgbm93IChpLmUuLCBhIElFVEYtZWQgIHZlcnNpb24gb2YgU0RGIDEuMCAgd2l0 aCBwb3RlbnRpYWxseSBzb21lIG9mIHRoZSBleGlzdGluZyBPbmVETSBmZWF0dXJlIHJlcXVlc3Rz IGZvbGRlZCBpbiBhcyB3ZWxsIGFzIGNoYW5nZXMgYmFzZWQgb24gcmVxdWlyZW1lbnRzIGZyb20g Im5ldyIgZWNvc3lzdGVtcykuIFRoYXQgU0RGIHdpbGwgdGhlbiBjb250aW51ZSB0byBncm93IGV4 cHJlc3NpdmVuZXNzIGlzIG1vc3QgbGlrZWx5LCBidXQgaG93IHRoYXQgaXMgYmVzdCBkb25lICh2 aWEgbmV3IG1haW4gc3BlYyB2ZXJzaW9ucyBvciB2aWEgZXh0ZW5zaW9uL2NvbXBhbmlvbiBzcGVj cykgc2hvdWxkIGJlIGxlZnQgZm9yIGZ1dHVyZSBkZWNpc2lvbi4gDQoNClRoYXQgc2FpZCwgSU1I TyB0aGUgY2hhcnRlciBjb3ZlcnMgdGhlIGN1cnJlbnRseSBlbnZpc2lvbmVkIHdvcmsgKGFzc3Vt aW5nIHJlbW92YWwgb2YgSlNPTiBwYXRoIHBhcmFncmFwaCAoZXhjZXB0IGZpcnN0IHNlbnRlbmNl KSBhcyBwZXIgaXNzdWUgIzUpIHNvIEknZCBhbHNvIGxpa2UgaXQgaGF2ZSBzdWJtaXR0ZWQgdG8g QUQgYXMgc29vbiBhcyBwb3NzaWJsZS4gDQoNCkNoZWVycywgDQpOaWtsYXMNCg0KDQoNCg0K From nobody Wed Aug 19 14:31:53 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A433A0E52 for ; Wed, 19 Aug 2020 14:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv0d5NbcK6Vl for ; Wed, 19 Aug 2020 14:31:49 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 117903A0E51 for ; Wed, 19 Aug 2020 14:31:49 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id a5so197457ioa.13 for ; Wed, 19 Aug 2020 14:31:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F+KOhBhtC4LOfWRy2gMjFKRSXQoiDgIWlJWCVB1g6rQ=; b=MiMo5d8VokZrg4hGv11xFAj3JDi2s8BUMC2oRSuTxj01ZCjBnd5d6qwii7d/7B9HPl O0p2xxr8DH9QunwNMj5XVC8yhAFQQFIScJzGtVdSWxV+kcVNExHho+pDV0H/Nt5kEpHi /f9Q9CVEh/MTD4+CVp92m/IPB4NDODjdlAlcwrh+XPFhhisxgi4cdtnJlxHHrGLBEtqm VcgdebCEbDfgv8h6GFXG2gxiWjjXKrXof5rquWmJzMiz42B4pLuSzniQLcH5NxAPiqF5 uW8hSslHk7FYCRXVJiHRBDb8NFx4cYwdOUULG+qL01dbFBERUhXF1AUehYz5hldBgvIO Lnbw== X-Gm-Message-State: AOAM530t07VZ7dDzL/mtScTcQAjAZTFR5qAmexw0kLXJWxfBmqzKbVGX j3SuiC3t/FIysjg2lGw0Cs/DeN8Kca6sCqBD7/T4HP08myI= X-Google-Smtp-Source: ABdhPJzek6+JUJwxzRZuIx6GQk8yYC8EdwlNKsiXazXvejlnS7UPuXlOZz6148CL1HgulyB92Jg+R8RV0HBUG0oTmT0= X-Received: by 2002:a5e:dd02:: with SMTP id t2mr20832176iop.90.1597872708145; Wed, 19 Aug 2020 14:31:48 -0700 (PDT) MIME-Version: 1.0 References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <11386.1597843091@localhost> In-Reply-To: <11386.1597843091@localhost> From: Barry Leiba Date: Wed, 19 Aug 2020 17:31:37 -0400 Message-ID: To: Michael Richardson Cc: asdf@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a5da605ad41bb41" Archived-At: Subject: Re: [Asdf] on ASDF cycling at internet-draft X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 21:31:51 -0000 --0000000000002a5da605ad41bb41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael, have a chat with Mark Nottingham: this is what httpbis did and quic is doing, and it worked very effectively for them. There are benefits to having a version in a PS RFC, then making the next version a new PS RFC that Obsoletes the first, and so on. There are also benefits to hashing things out during document development of the first PS RFC. The working group will have to weigh those, and see which side comes up heavier. Mark will have good input for that decision, I think. Barry On Wed, Aug 19, 2020 at 9:18 AM Michael Richardson wrote: > > > Barry, I'm uncomfortable with a plan to have more than implementation dra= ft > > as a WIP. While it seems that this where the IETF has evolved to, I'm > > really not sure that planning it this way is in the right spirit. > > > > I would significantly prefer to iterate at PS, but the hurdles seem highe= r > > than ever. I'd love to be wrong! > > Maybe someone has some 3933 process experiment ideas that could be done. > > > > Carsten Bormann wrote: > > >> 1) What would you call a "release" here? > > > > > An Internet-Draft that is specifically marked as such (often called > > > =E2=80=9Cimplementation draft=E2=80=9D in other groups). > > > > > The intention would be to reach a periodic milestone where OneDM > people > > > and ASDF agree that a specific I-D is useful as a basis for further > > > OneDM work, e.g., by using that I-D for validating models in the > OneDM > > > playground and convergence processes, and by ecosystem tool builder= s > > > modifying their tools to target that I-D in their conversion > processes > > > (which is what enables breaking changes). > > > > > This could be done in a tick-tock style, with a feature I-D and the= n > a > > > period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and s= o > > > on. > > > > ... > > >> Should publishing 1.0 ASAP be a goal, or should we just do 1.1? > > > > > 1.0 was =E2=80=9Cpublished=E2=80=9D as an Internet-Draft. I don=E2= =80=99t think we should > aim > > > for RFC status until we have at least a handful of SDOs that have p= ut > > > the majority of their relevant models through the process. 1.0 is > > > intended to be quickly superseded by 1.1, and that might happen a > > > couple more times until returns start to diminish. > > > > > This rapid iterative process may be a bit unusual for IETF. > > > I=E2=80=99d assume we can stabilize the SDF core at 1.3 or 1.4 enou= gh to go > for RFC. > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > > > > > > > --0000000000002a5da605ad41bb41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael, have a chat with Mark Nottingham: this is w= hat httpbis did and quic is doing, and it worked very effectively for them.= =C2=A0 There are benefits to having a version in a PS RFC, then making the = next version a new PS RFC that Obsoletes the first, and so on.=C2=A0 There = are also benefits to hashing things out during document development of the = first PS RFC.=C2=A0 The working group will have to weigh those, and see whi= ch side comes up heavier.=C2=A0 Mark will have good input for that decision= , I think.

Barry

On Wed, Aug 19, 2020 at 9:18 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Barry, I'm uncomfortable with a pla= n to have more than implementation draft

as a WIP.=C2=A0 =C2=A0While= it seems that this where the IETF has evolved to, I'm

really no= t sure that planning it this way is in the right spirit.



I w= ould significantly prefer to iterate at PS, but the hurdles seem higher
=
than ever.=C2=A0 I'd love to be wrong!

Maybe someone has som= e 3933 process experiment ideas that could be done.



Carsten = Bormann <cabo@tzi.org<= /a>> wrote:

=C2=A0 =C2=A0 >> 1) What would you call a "= ;release" here?



=C2=A0 =C2=A0 > An Internet-Draft th= at is specifically marked as such (often called

=C2=A0 =C2=A0 > = =E2=80=9Cimplementation draft=E2=80=9D in other groups).



=C2= =A0 =C2=A0 > The intention would be to reach a periodic milestone where = OneDM people

=C2=A0 =C2=A0 > and ASDF agree that a specific I-D i= s useful as a basis for further

=C2=A0 =C2=A0 > OneDM work, e.g.,= by using that I-D for validating models in the OneDM

=C2=A0 =C2=A0 = > playground and convergence processes, and by ecosystem tool builders
=C2=A0 =C2=A0 > modifying their tools to target that I-D in their = conversion processes

=C2=A0 =C2=A0 > (which is what enables break= ing changes).



=C2=A0 =C2=A0 > This could be done in a tic= k-tock style, with a feature I-D and then a

=C2=A0 =C2=A0 > perio= d of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so

=C2= =A0 =C2=A0 > on.



...

=C2=A0 =C2=A0 >> Should= publishing 1.0 ASAP be a goal, or should we just do 1.1?



= =C2=A0 =C2=A0 > 1.0 was =E2=80=9Cpublished=E2=80=9D as an Internet-Draft= .=C2=A0 I don=E2=80=99t think we should aim

=C2=A0 =C2=A0 > for R= FC status until we have at least a handful of SDOs that have put

=C2= =A0 =C2=A0 > the majority of their relevant models through the process.= =C2=A0 1.0 is

=C2=A0 =C2=A0 > intended to be quickly superseded b= y 1.1, and that might happen a

=C2=A0 =C2=A0 > couple more times = until returns start to diminish.



=C2=A0 =C2=A0 > This rap= id iterative process may be a bit unusual for IETF.

=C2=A0 =C2=A0 &g= t; I=E2=80=99d assume we can stabilize the SDF core at 1.3 or 1.4 enough to= go for RFC.





--

Michael Richardson <mcr+IETF@sandelman.c= a>, Sandelman Software Works

=C2=A0-=3D IPv6 IoT consulting = =3D-







--0000000000002a5da605ad41bb41-- From nobody Wed Aug 19 18:24:03 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED09C3A0FFD for ; Wed, 19 Aug 2020 18:24:01 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVgv9IJ-iJ-5 for ; Wed, 19 Aug 2020 18:24:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA363A0FFB for ; Wed, 19 Aug 2020 18:24:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0A39F38A0D; Wed, 19 Aug 2020 21:03:07 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id c2wkJwBZJjvh; Wed, 19 Aug 2020 21:03:06 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 54C99389F5; Wed, 19 Aug 2020 21:03:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6E40B91C; Wed, 19 Aug 2020 21:23:57 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , asdf@ietf.org In-Reply-To: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 01:24:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-08-19, at 17:06, Carsten Bormann wrote: >> >>> So I would personally be loath to put this into a charter. > Do we have to? I think the WG can define (and modify, as needed) its > mode of operation and its rhythm; that does not need to be part of the > charter. > I=E2=80=99m asking because I believe we should send off the charter t= o our AD > soon, so we need to find out whether there is anything left that needs > to be added. yes, I also feel the urge for some speed here. But, I think it's just you and I for the last two weeks though. Will it pick up again September 1, or is everyone just dead from ietf@ietf.= org? (I'm not reading that thread) I guess I thought this pandemic August would be different than other August= lulls. I wonder if there a useful place for an Experimental status document? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl890K0ACgkQgItw+93Q 3WUcDQgAuYttZmFKbhD7UtwxVcYFfue7NLa6viZ+67ePCe19xhln//HgxKt5eNyj CEZj37yIAqOB16svm+voCMadYsAPRQodJ+gmbZ+W8iZQRaXCTFIFnbXhmXjp95tR dYdjxh/HxB3Zy/DcXXBNKhOVu5vVvltCYquH9eyEWm878r0LVdi1a0kPWMStt11J 2I/SUNiRh7TFPxstIzfk3zTkIWYk4n1uVmolHOTkWK0xzwUQHmskBWiIOJPVKwqg t3Fktfn3f8v+QTUb4dnRahrVfd4hLK1YXZAoddZpvZapRYwJBUZSBr4qnt1dYncK UMBda8vX6gq1nDD8P1/kXjeuCGjC0Q== =F1wk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 19 22:00:34 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994753A0B8F for ; Wed, 19 Aug 2020 22:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2d2waATF4XR for ; Wed, 19 Aug 2020 22:00:31 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77353A0B80 for ; Wed, 19 Aug 2020 22:00:30 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BXCC02BSbzybM; Thu, 20 Aug 2020 07:00:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <18914.1597886637@localhost> Date: Thu, 20 Aug 2020 07:00:27 +0200 Cc: asdf@ietf.org X-Mao-Original-Outgoing-Id: 619592427.8873529-ae34e423ddf99f6b02804a31f8a2b6a4 Content-Transfer-Encoding: quoted-printable Message-Id: <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 05:00:34 -0000 > On 2020-08-20, at 03:23, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >> On 2020-08-19, at 17:06, Carsten Bormann wrote: >>>=20 >>>> So I would personally be loath to put this into a charter. >=20 >> Do we have to? I think the WG can define (and modify, as needed) its >> mode of operation and its rhythm; that does not need to be part of = the >> charter. >=20 >> I=E2=80=99m asking because I believe we should send off the charter = to our AD >> soon, so we need to find out whether there is anything left that = needs >> to be added. >=20 > yes, I also feel the urge for some speed here. > But, I think it's just you and I for the last two weeks though. Maybe charter smithing is just not everyone=E2=80=99s favorite pastime. (And maybe the charter is pretty much done?) > Will it pick up again September 1, or is everyone just dead from = ietf@ietf.org? > (I'm not reading that thread) > I guess I thought this pandemic August would be different than other = August lulls. It certainly is, with all the time on the balcony :-) (It also is ten degrees warmer.) > I wonder if there a useful place for an Experimental status document? I think we are way beyond =E2=80=9CExperimental=E2=80=9D. When do you create an =E2=80=9CExperimental=E2=80=9D protocol in the = IETF? (1) If you want to conduct an experiment (Research!) and need a common = specification for that. (1a) If you want to document an experiment, or are in the IRTF :-) (2) If you want to put out something as a proposal, and expect that will = be replaced by the real thing after some thinking later (RFC 2414 and = RFC 3390, RFC 3940 and RFC 5740, =E2=80=A6). (2a) If your protocol development fizzled out, but you still want to = document it (RFC 8548). (3) If you are not sure about the harm you are creating (damaging the = Internet) and want to get by the IESG anyway. SDF 1.0 might have been =E2=80=9Cexperimental=E2=80=9D. But we do not = plan to publish anything but the real thing. By the time we do this, we = expect to have most of the data models of a dozen or so ecosystems = represented in SDF and being used for organizing the convergence in = OneDM. That is no longer an experiment. .oOo. Back to the charter work: I created = https://github.com/one-data-model/ietf108/pull/6 to actually address = https://github.com/one-data-model/ietf108/issues/5 Please check whether that correctly reflects the change needed. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 20 00:37:53 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917E53A0992 for ; Thu, 20 Aug 2020 00:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 w_IpCH3waMQ3 for ; Thu, 20 Aug 2020 00:37:50 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150081.outbound.protection.outlook.com [40.107.15.81]) (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 A918C3A097D for ; Thu, 20 Aug 2020 00:37:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OuUx/Zj+lgWiauFu1SeKFjY9Ie6Y+ANFJy52Iynp8tejnn5zoOMpITXxbHlF78LDq7ma2vMLiICKDhmW4ncSW5hqL/WXkzsbfGUNmG96lvbJElyoN/EpvasJi4VPA9o8pgnVExxYhjJXP17r39QBajxp9wbWong9B0Mg0ii4QbpdYOJIuYB8XxSkVTuGQLMtxtgYjBHdKPLL0qh4ct8yJFLSz/TIkeIA+AGBCEHlMj2aqicbxEv/oX7YA8qM8J5nc+c+33tCD/Zr/azFIjo26j4lFbn065b/UA8/rrMF22INH2zMSqRqLszEk+hCQPjK+Oo0n9leRdMNrI+ngJCdRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1uYC301AhodGxkaku/wi5pFFzsHcpDn9jG5ViCqkD/0=; b=npVRFe0enri6AbpLrp20ls3zHZ9QNtS9/+42p9OYkuu5GawlQzjXgjg4V8YXcdsmT5a+D631cUOJvA7Xl4nfNxHm0LtjCrKtJX4kwLnH5nKL/9LXzG6vLc/RdV7ZqlCV+yKoaONn7rjYV/dRC3o/JGX204qmkT8t6Ipm82ZeBc1gxCpf7mMIIjokgT3YuQMlniezMIrPdf8errGYqITLd8Us3lm2oDmn/kJbYrGp/cDEBO22H4PKpQyhBrgzpI56aRSpzyxX5OKkULaNKtc8zmfafvUXHoWLJEbwnUCcRTXn7SubEJ7Pt0spcAEKKsCfr2rip66NUcWNWvhPjrDhGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=1uYC301AhodGxkaku/wi5pFFzsHcpDn9jG5ViCqkD/0=; b=U84Q0HKBP7s/98/kgT5HOG1V13H69wWnGn4nTm+5aUwyRS6w5JvbBlgYYLN6E6qXbS6Nl7j15a/j5qqciyFekVJQsvg2HH4xYy1Fc78FjFP/1ErJTCg9U9ZE1l1TSPUtbZWkitveDGkJFrnMBXwD8g/johBDAltj7JRwLPE6O+Q= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2251.eurprd07.prod.outlook.com (2603:10a6:3:1d::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.13; Thu, 20 Aug 2020 07:37:45 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::9b1:f546:660f:f8ed]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::9b1:f546:660f:f8ed%7]) with mapi id 15.20.3305.019; Thu, 20 Aug 2020 07:37:45 +0000 From: Niklas Widell To: Carsten Bormann , Michael Richardson CC: "asdf@ietf.org" Thread-Topic: [Asdf] Kicking off ASDF Thread-Index: AQHWapRe7HPOiNhEpEmmmY1bH7JUJqktORCAgACgIwCAEaYAgIAAIFGAgAACcYCAAKoIgIAAPH2AgABNeQA= Date: Thu, 20 Aug 2020 07:37:45 +0000 Message-ID: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> In-Reply-To: <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [37.123.165.254] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6330f750-082f-4ee3-7205-08d844dbedf9 x-ms-traffictypediagnostic: HE1PR0701MB2251: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mA90kJ8ubMXVYmqs/YRj4Gqs+GFOdo6xncy1pLDDApksuo4i0j72Wi7EOhF/b5FC3nCwv7pJL2PnRnDbgVnRDF9raEyyQqLrwVWTQhvZt0cE0fLSrtgPesbqD7LzcDIyCIIoB/DpU4dD2pFRUtF45ygoWokC3dy7R42WQxzhVqZthDLFQ5wtbkbsQ5IQA54bg/lbmgcxuvNXTqcSRMJbEtESAKg1R90F2QkVk3yhFvieLbyTPZlqvdbKGjc2XhF1xeu7ANf2M3qNDZPTQcpXQud/JIIwuQ0orLUeHGIVt2Ns9rY/uIPMgjdQBoS0AEPbRjWv0caGrQBh47qN+nHiqOKd/ivZj8fna/lfBBGY0JKy94pjmIJi5oNHoDWDj7F6TbWwAQ2cSVbPCO+GTEOqKQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(6506007)(36756003)(6512007)(6486002)(2616005)(5660300002)(53546011)(26005)(8676002)(44832011)(8936002)(2906002)(316002)(86362001)(110136005)(71200400001)(478600001)(33656002)(4326008)(66446008)(64756008)(66946007)(91956017)(76116006)(966005)(66556008)(66476007)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AtrcuNOJIzNUUtAemKwb2SOTTr28bTCQw8XnMVmVy+aWtO5BdCorg+FajdvV7okmNHhLMaPpJhP9uf11aAQY6m+qwwr00SKGPxhZxCmFAAdfww+dhqrpwURpNdgE56mU5ohJ5nVBmOc3TvHZ2tZ++zNM92kANSrrE+/Aknm3OaJrkjkyAuHiDBZNpfUK07hhuLRhL11OUcwmqovCvxSxyGlIuQM/ri+b0hyFKTDeUNT3/OirqrYLUmQMwocqBF22Eo0tbECVwdqGlcJYKy0lko3byRzgJ5/EW2Noakuw86/r8JsYkceP1Gt7TukNmLWaXd/3iWcAghUosQ9I0RWpHEkJDhUOnCwDqZEun//YTA4/v7A/30acMH5juwoBnn4XK27Xju9crQz+zBNjBRyAnmyKfRQ8O30oBR0HdlmhG+AmG91TiRVQpiv18E+1beGntLrBlYJf4PnexAmyeAOuRZV3jUOf0h1THgidfKUonYC5hvlDxjVFWXYn9t8irs8ck5vHYkhq7G7a1mrcex3bssK0SNHtzngWNvhN4I4wXvk9oalWrDp92Px+Z2MP24CHFMJtzyz0Q6tH4ALQxIy05HcLOm5cIni1emuiHfuXzT0zgTT8lPqHx7YJGlSBKh44gpYvmT8elTvs84LJ92Tuig== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <39AD77BB389D3A4D9BA6864BAD38EC75@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6330f750-082f-4ee3-7205-08d844dbedf9 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 07:37:45.2530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9U3y6Gs9sAt7/mF0+sdJpw2BsZzL6/vGgu0mGlGHy0l7nvumTnBvRxz3EXa2oKFXyVivCR2z/3fn0dr4eV6x517E1u6mo3bbfLTuke7XYgY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2251 Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 07:37:52 -0000 DQoNCu+7v09uIDIwMjAtMDgtMjAsIDA3OjAxLCAiQVNERiBvbiBiZWhhbGYgb2YgQ2Fyc3RlbiBC b3JtYW5uIiA8YXNkZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KDQogICAgPiBPbiAyMDIwLTA4LTIwLCBhdCAwMzoyMywgTWljaGFlbCBSaWNoYXJk c29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KICAgID4gDQogICAgPj4gSeKAmW0g YXNraW5nIGJlY2F1c2UgSSBiZWxpZXZlIHdlIHNob3VsZCBzZW5kIG9mZiB0aGUgY2hhcnRlciB0 byBvdXIgQUQNCiAgICA+PiBzb29uLCBzbyB3ZSBuZWVkIHRvIGZpbmQgb3V0IHdoZXRoZXIgdGhl cmUgaXMgYW55dGhpbmcgbGVmdCB0aGF0IG5lZWRzDQogICAgPj4gdG8gYmUgYWRkZWQuDQogICAg PiANCiAgICA+IHllcywgSSBhbHNvIGZlZWwgdGhlIHVyZ2UgZm9yIHNvbWUgc3BlZWQgaGVyZS4N CiAgICA+IEJ1dCwgSSB0aGluayBpdCdzIGp1c3QgeW91IGFuZCBJIGZvciB0aGUgbGFzdCB0d28g d2Vla3MgdGhvdWdoLg0KDQogICAgTWF5YmUgY2hhcnRlciBzbWl0aGluZyBpcyBqdXN0IG5vdCBl dmVyeW9uZeKAmXMgZmF2b3JpdGUgcGFzdGltZS4NCiAgICAoQW5kIG1heWJlIHRoZSBjaGFydGVy IGlzIHByZXR0eSBtdWNoIGRvbmU/KQ0KDQpOVz4gQWxzbywgdGhlcmUgd2FzIHByZXR0eSBtdWNo IHNvbGlkIHN1cHBvcnQgYXQgdGhlIEJvRiBhbmQgcGVvcGxlIHNlZW1lZCB0byBiZSBwcmV0dHkg aGFwcHkgd2l0aCB0aGUgY2hhcnRlciBub24tcmV2aWV3LCBzbyB3aGlsZSBuZWVkIHRvIGdldCB0 aGUgZm9ybWFsaXRpZXMgcmlnaHQgSSdtIG5vdCBzdXJlIHRoZXJlIGlzIG11Y2ggb3Bwb3NpdGlv biB0byBleHBlY3QuIA0KDQouLi4NCg0KICAgIFNERiAxLjAgbWlnaHQgaGF2ZSBiZWVuIOKAnGV4 cGVyaW1lbnRhbOKAnS4gIEJ1dCB3ZSBkbyBub3QgcGxhbiB0byBwdWJsaXNoIGFueXRoaW5nIGJ1 dCB0aGUgcmVhbCB0aGluZy4gIEJ5IHRoZSB0aW1lIHdlIGRvIHRoaXMsIHdlIGV4cGVjdCB0byBo YXZlIG1vc3Qgb2YgdGhlIGRhdGEgbW9kZWxzIG9mIGEgZG96ZW4gb3Igc28gZWNvc3lzdGVtcyBy ZXByZXNlbnRlZCBpbiBTREYgYW5kIGJlaW5nIHVzZWQgZm9yIG9yZ2FuaXppbmcgdGhlIGNvbnZl cmdlbmNlIGluIE9uZURNLiAgVGhhdCBpcyBubyBsb25nZXIgYW4gZXhwZXJpbWVudC4NCg0KTlc+ ICsxLiBQZW9wbGUgaW50ZW5kIHRvIHVzZSBTREYgaW4gcHJvZHVjdGlvbiAgDQoNCiAgICBCYWNr IHRvIHRoZSBjaGFydGVyIHdvcms6IEkgY3JlYXRlZCBodHRwczovL3Byb3RlY3QyLmZpcmVleWUu Y29tL3YxL3VybD9rPTIzODkzMjJmLTdkMjk5Y2UyLTIzODk3MmI0LTg2NjEzMmZlNDQ1ZS1kNDg3 MTQzMDZiOGI3YjFlJnE9MSZlPThkNGMyOWM1LTA4ZTItNDg3NS05Y2MzLTEwNWIxOGFlY2M4MyZ1 PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm9uZS1kYXRhLW1vZGVsJTJGaWV0ZjEwOCUyRnB1 bGwlMkY2IHRvIGFjdHVhbGx5IGFkZHJlc3MgaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92 MS91cmw/az0wYjIxMzhiNS01NTgxOTY3OC0wYjIxNzgyZS04NjYxMzJmZTQ0NWUtZjA3NGFmYzNh Mzk0NDhiZCZxPTEmZT04ZDRjMjljNS0wOGUyLTQ4NzUtOWNjMy0xMDViMThhZWNjODMmdT1odHRw cyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZvbmUtZGF0YS1tb2RlbCUyRmlldGYxMDglMkZpc3N1ZXMl MkY1DQogICAgUGxlYXNlIGNoZWNrIHdoZXRoZXIgdGhhdCBjb3JyZWN0bHkgcmVmbGVjdHMgdGhl IGNoYW5nZSBuZWVkZWQuDQoNCk5XPiBXaGlsZSB0aGUgSlNPTnBhdGggcGFydCBjb3VsZCBiZSBy ZW1vdmVkLCBJIHRob3VnaHQgdGhlIGZpcnN0IHNlbnRlbmNlICgiSW4gdGhlIHByb2Nlc3MsIHNv bWUgc21hbGxlciBwaWVjZXMgbWF5IGJlY29tZSB1c2FibGUgaW5kZXBlbmRlbnRseSBmcm9tIFNE RiBpdHNlbGYgYW5kIGl0cyBhcHBsaWNhdGlvbnMuIikgc3RpbGwgbWFkZSBzZW5zZQ0KDQoNCiAg ICBHcsO8w59lLCBDYXJzdGVuDQoNCkNoZWVycywgDQpOaWtsYXMNCg0KDQo= From nobody Thu Aug 20 00:57:33 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB8B3A0954 for ; Thu, 20 Aug 2020 00:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyxhAsQyLC_D for ; Thu, 20 Aug 2020 00:57:28 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AC03A09B1 for ; Thu, 20 Aug 2020 00:57:28 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BXH785t33zyS3; Thu, 20 Aug 2020 09:57:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 20 Aug 2020 09:57:24 +0200 Cc: Michael Richardson , "asdf@ietf.org" X-Mao-Original-Outgoing-Id: 619603044.309448-cae7eef7e33e902ae27ba2e3f552c499 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> To: Niklas Widell X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 07:57:32 -0000 On 2020-08-20, at 09:37, Niklas Widell = wrote: >=20 > NW> While the JSONpath part could be removed, I thought the first = sentence ("In the process, some smaller pieces may become usable = independently from SDF itself and its applications.") still made sense It sure made sense, but I=E2=80=99d expect it to be considered too = open-ended to survive a charter discussion. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 20 02:21:11 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9CA3A0A69 for ; Thu, 20 Aug 2020 02:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Z4qx2yZk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=d1Vul3H3 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 ArDuVftYYn0z for ; Thu, 20 Aug 2020 02:21:08 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F6E3A0A64 for ; Thu, 20 Aug 2020 02:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1258; q=dns/txt; s=iport; t=1597915268; x=1599124868; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zPyU0DHycXc52dIqFQzCrhoRK3zbXx4MckASXk41DyI=; b=Z4qx2yZkaObTsFDRBYI1jKMBTzvWBObJWhy8NEGIPmTiGTbyfo7FTcVn tPtLUtX/6WQipTyoFGZErRl9wpFuQlIvU/kxQSzRCexuUIO4O08erw0hU QTlmgMP5pyIkHwqTusi2S3096J2DvVQIbf+dm273pyNJrMNOkqWIOQpEz M=; IronPort-PHdr: =?us-ascii?q?9a23=3Aahz4qBNfI74ddKDfiOIl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw13kPbXMPc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoLVpUXsHkaA6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClBQBXPz5f/5tdJa1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUlEHcFgvLAqELYNGA41gmG2BQoERA1ULAQEBDAEBGAs?= =?us-ascii?q?KAgQBAYRMAheCKAIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEEAQEQERE?= =?us-ascii?q?MAQEsCwELBAIBBgIOAwQBAQECAiYCAgIlCxUICAIEAQ0FCBqDBYJLAy4BDpU?= =?us-ascii?q?kkGgCgTmIYXaBMoMBAQEFhVIYgg4DBoEOKoJxg2KGTBuCAIERQ4JNPoJcAQG?= =?us-ascii?q?BRRyDFTOCLZMGozUKgmKPcIpToCiSP59EAgQCBAUCDgEBBYFrI4FXcBU7gml?= =?us-ascii?q?QFwINjh+DcYUUhUJ0NwIGAQkBAQMJfI9YAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,332,1592870400"; d="scan'208";a="528842149" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Aug 2020 09:21:07 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07K9L70W030546 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2020 09:21:07 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 20 Aug 2020 04:21:07 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 20 Aug 2020 04:21:06 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 20 Aug 2020 04:21:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l8G150SFsDQFgv208geMzIaHPKfT+t2n6cMH4RIKfamlWfwSoY2P5PIPIw87qTCkVKKwc5wcXkcqnlIiSrL1wcNLQTxrrpJjd5S05ThEk0g9heYb/HIsC83Y9C4HB0wwuha7fYMU37sUQfRhxw3dMVnpSYn91Ff6uol05Hbv+ihqA0PKfSzWmFCvcG1DHVa5KLEtL0UxMjtBibfFNjeVFAUnMK9P491Yc8GnDflv/4Xm0EVY7F19b58BC9rJtVU6wY2wnr2vVI9GyZRi0ywzV5EVBaxy9QtZiXQXGYeJXkkzI7o3vHHgf3IcbKqiyKL4Lsn5zcqq5OVGZfUAmc0KRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zPyU0DHycXc52dIqFQzCrhoRK3zbXx4MckASXk41DyI=; b=kmby7tf5ZPL3FOn2QCZopKe3OAcxxDxSOWvv0E+6TsbDQZJlDyhzE3cPysXV5fQlnB0RRkJFdGIghIZtly/SD2jQ/nkZtGCRZQ7gb1uKiV4VkS5nhLq7qfW8cxSFkemt/xENOtmFzCChrxfCBYJcXlzGtJXQgsTiBoqqHK1n53aRKVciYk8tz8mJi+0nRcwPYfaDZEkWF3cLsx3sN4A3YvMHM1Y8KPFJCXEVRfcn1qdHSArGPIsNXm0r2QfBaU4yPnY3zqjTD6cyaSP0PynIwsOaAtrgi+r9HtM2HZh/g/NgvCOQ5ZnFOr4SwEVNzt7kfCF6deDUwVpsopYAdjDflw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zPyU0DHycXc52dIqFQzCrhoRK3zbXx4MckASXk41DyI=; b=d1Vul3H3XFz0ROXktt9e4BSPKwpJ8ltGl7XSHqNMQTzsEaz3KPn69pQ4S3tw+mBULGnsKryDqbY+JRgoUYdYGYzVgIqKTAj7jXuXdKEBOVp94/fd9Tj2zOJSye0AWo3lrkK5cNOmcMGcFUsb1IZDRr6lI0MTAuHpHkQPRVQPtAk= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (2603:10b6:300:10c::11) by MWHPR11MB0029.namprd11.prod.outlook.com (2603:10b6:301:67::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.23; Thu, 20 Aug 2020 09:21:04 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::34c5:6550:a098:209f]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::34c5:6550:a098:209f%12]) with mapi id 15.20.3305.024; Thu, 20 Aug 2020 09:21:04 +0000 From: "Wouter van der Beek (wovander)" To: Carsten Bormann , Niklas Widell , Michael Richardson CC: "asdf@ietf.org" Thread-Topic: [Asdf] Kicking off ASDF Thread-Index: AQHWapRgbLuiC7t7UUiwBjFhXPI4gaktORCAgACgIwCAEaYAgIAAIFGAgAACcYCAAKoIgIAAPH2AgAAr84CAAAV+AIAAFxMw Date: Thu, 20 Aug 2020 09:21:04 +0000 Message-ID: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35616d58-5aec-494d-4228-08d844ea5d19 x-ms-traffictypediagnostic: MWHPR11MB0029: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2582; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w/j51bEbt0oQkFRNS/1Z0X963uASPTqD1hWwt/a6CFcwGA3Wm1AbHm4XgCLf0fprCEfmNZDWF7ulWcyt/h0O5ifPxUSXN9d2qhv11jvVz+4h5srVUiKV/0VPVOWdE/cw+ebic2US8cpcSFkfyeszA2GrAm+y2ajdQOifEn/NuZVOu0l/4z8UYRJoQ1LBoc/lHpv+kAXKZDJYGM3d0Xi4fFEvzxena+6KO6A9v4RsweGdpi5GgmEL9B30jWlcJftgRAPHrQhGt3O3uQgwvZeTD2hxnLjCk8NpDl4ljMGCqkkqy/SzJUOJH457bNzFnr9j/DOKbpSAcre2mx3j0VDhyQSLwbhpHl7SaXSu4MIqFxhZ9+aeJJ/l7JYZs7s4dspnQ5uLuN3XGMcZw35IEQLJ4w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1838.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(136003)(366004)(396003)(53546011)(9686003)(26005)(110136005)(966005)(8936002)(55016002)(5660300002)(76116006)(4326008)(8676002)(2906002)(52536014)(33656002)(6506007)(83380400001)(66446008)(64756008)(7696005)(186003)(316002)(71200400001)(66556008)(4744005)(66476007)(86362001)(478600001)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: POOZ64D5drjjufsbRiJpnkQrriIY4bTRVaXqHVogKMlqvBCexkqugSMuYm+1rgrYbCs0UVXoHnmfqUpAxSSAJHSZZVh+3K5KpaXhh4r/XrwaSOWUq9SPGF45BhR5L6LwWtlnkwadlmElwhMyJ+i+bvAIfXgl9S9pr1u3fD2zuLY1Pl9t9E6SjfZi8shvGv6NO+u+D5t9v3228VYCRW+BdDRzI+oaUcXzxqRtzGfdTu2kFX+hOC/hbc0C4GqA50TGCz8/1c7d9rzolYv2CVXxKmrtsKPIBf5IxWqIyDT4DJAoEeqbPQ/C+L1GgkfVi7AooybOZ0YzTq6nieYYqomQkD7iTU5ENe382nEQ5GGNUt7IUfBz91FSmaJz4nPQrsiZ9Wmhr/kDEutKLjmfyIp7OSr3vY6M45xbnaoQqbugjmg/YRA61xIRuEpmYI0CqYZNQCjWSYfSTy5XG0U3aUp8ZjkoIiUWaDInJTOzktDOOnwK29LedDOtmRRy7OVIKbNiKao+Vzpe02Z+IcNkV6NLVUN2w6AC5ZcPXvPceY4NnXIdhL8B8ObjfFRk4ZOc2WPzsXAmuMMr0MiX1O6jOrQa/WxbKL4HwoYnGoGDGe24VDA+igtcD/IhGwvETWI/703WfjwX29vS3exF4EXUdqxtFw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1838.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35616d58-5aec-494d-4228-08d844ea5d19 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 09:21:04.6088 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /EPfCpc9W5tfndSqFpLIrCGD/pyvNMhgVx4gMKF2FcIisgwH04rkmG4RCjpGfSgUoFLo50/NKEmOQeyPR5nsMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB0029 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 09:21:11 -0000 SGkgQ2Fyc3RlbiwgTWljaGFlbCwNCg0KSXMgZXZlcnl0aGluZyBub3cgc29ydGVkIHRvIHN1Ym1p dCB0aGUgY2hhcnRlcj8NCmUuZy4gd2hvIGlzIHRha2luZyB0aGF0IGFjdGlvbj8NCg0KS2luZCBS ZWdhcmRzLA0KV291dGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBU0RG IDxhc2RmLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NClNl bnQ6IFRodXJzZGF5LCBBdWd1c3QgMjAsIDIwMjAgODo1NyBBTQ0KVG86IE5pa2xhcyBXaWRlbGwg PG5pa2xhcy53aWRlbGxAZXJpY3Nzb24uY29tPg0KQ2M6IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNy K2lldGZAc2FuZGVsbWFuLmNhPjsgYXNkZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBc2RmXSBL aWNraW5nIG9mZiBBU0RGDQoNCk9uIDIwMjAtMDgtMjAsIGF0IDA5OjM3LCBOaWtsYXMgV2lkZWxs IDxuaWtsYXMud2lkZWxsQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBOVz4gV2hpbGUgdGhl IEpTT05wYXRoIHBhcnQgY291bGQgYmUgcmVtb3ZlZCwgSSB0aG91Z2h0IHRoZSBmaXJzdCBzZW50 ZW5jZSAoIkluIHRoZSBwcm9jZXNzLCBzb21lIHNtYWxsZXIgcGllY2VzIG1heSBiZWNvbWUgdXNh YmxlIGluZGVwZW5kZW50bHkgZnJvbSBTREYgaXRzZWxmIGFuZCBpdHMgYXBwbGljYXRpb25zLiIp IHN0aWxsIG1hZGUgc2Vuc2UNCg0KSXQgc3VyZSBtYWRlIHNlbnNlLCBidXQgSeKAmWQgZXhwZWN0 IGl0IHRvIGJlIGNvbnNpZGVyZWQgdG9vIG9wZW4tZW5kZWQgdG8gc3Vydml2ZSBhIGNoYXJ0ZXIg ZGlzY3Vzc2lvbi4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQotLSANCkFTREYgbWFpbGluZyBsaXN0 DQpBU0RGQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fz ZGYNCg== From nobody Fri Aug 21 10:34:48 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056E83A0EF6 for ; Fri, 21 Aug 2020 10:34:47 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8VqZEIy-shi for ; Fri, 21 Aug 2020 10:34:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDF53A0EF8 for ; Fri, 21 Aug 2020 10:34:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F2E338A1F; Fri, 21 Aug 2020 13:13:50 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mqg8SDzVTsml; Fri, 21 Aug 2020 13:13:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6495238A1D; Fri, 21 Aug 2020 13:13:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F19E31AA; Fri, 21 Aug 2020 13:34:42 -0400 (EDT) From: Michael Richardson To: "Wouter van der Beek \(wovander\)" , "asdf\@ietf.org" In-Reply-To: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 17:34:47 -0000 --=-=-= Content-Type: text/plain Wouter van der Beek (wovander) wrote: > Is everything now sorted to submit the charter? > e.g. who is taking that action? Hi, Niklas and I are taking responsibility. At this point, we can't tell "silence == no objections" from "silence == everyone on vacation" I think that we need some additional text around the proposed idea to call Implementation Drafts. I would like some additional feedback on other ways of organizing the work, but I've heard Carsten's preference loudly. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9ABbIACgkQgItw+93Q 3WW6bgf8CNsWqwTeabG74rwhWOAIgd9g9n110VV/1hJhQSiS0tOklcvN96oFez3v KTE8zoKxW62lAdbbES3n0rgrIAtdW91zPbmYNsWFO19AR6FJ00wPL+6+rkBfe0KO qw38FLZ8M9mmLbnsApswlK8Q/fjVL+Ts7lDhr55RyNd3NawMcAZ5KLyMWKDLdnhN vQGumtFqPTrwMq1JQk3IbmomnxXHrx4OHQeW2Pc2KKoWGvqzusfkcHtrIVo+V+3+ TUu6cUS91iY/54e4J7rKJgE78ieStrGYHyEA4RFzBswafj49Jtmv++FsFuyDC5RE cUCa0omghV2+eMlYe6zIHEvNpuNxbw== =B7Iz -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 21 10:44:40 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919BF3A0EE7 for ; Fri, 21 Aug 2020 10:44:38 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKjNkffqKrxZ for ; Fri, 21 Aug 2020 10:44:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35153A0E9D for ; Fri, 21 Aug 2020 10:44:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 727B038A1F; Fri, 21 Aug 2020 13:23:41 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MFdlnmAUHiZp; Fri, 21 Aug 2020 13:23:40 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7ED7438A1D; Fri, 21 Aug 2020 13:23:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1C5DB1AA; Fri, 21 Aug 2020 13:44:34 -0400 (EDT) From: Michael Richardson To: Barry Leiba , asdf@ietf.org In-Reply-To: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <11386.1597843091@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] on ASDF cycling at internet-draft X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 17:44:39 -0000 --=-=-= Content-Type: text/plain Barry Leiba wrote: > Michael, have a chat with Mark Nottingham: this is what httpbis did and > quic is doing, and it worked very effectively for them. Yes, I know that they did this. I believe it works because the parties involved are a) funded to implement Internet-Drafts (not just discuss) b) actively deploy/test, with the understanding that it may break c) includes implementers that have both significant client and server properties My impression is that this mostly applies to ASDF as well, although (c) is irrelevant. > There are benefits to having a version in a PS RFC, then making the > next version a new PS RFC that Obsoletes the first, and so on. This is was how RFC1310/RFC1602/RFC2026/etc. intended, and it seems that it has again gotten unstuck, pushing WGs like httpbis and quic AND ASDF to take this approach. It seems that every 15 years, the process becomes ossified. As Carsten says, it's not our WG's purpose to try to fix the IESG, I guess we just have to work around things. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9ACAEACgkQgItw+93Q 3WUWlAgArNYysNY3OEnB1Y53daMDdbL2yf1qBILfzWou4k44CeTiqSxGCGHNW0Sl krgPZixhq2AwQzNm827fGXNhy4BHkiEc4zjmEUfJgxpdCZyLKkcsRt+vuz/kpk12 0Uhhgr3l5XZRYEwBKhiwuTcLWfVscP2BzfUmDsSNHQxrnY34oWjJXiSV8VRrlLcR D5wJdKiLSNo5d/2i2P/DebHSdrKWNan2CSePV6F2Uj+R2g60lkC8D6R3GoxpV2ZU bSY6yGI39gcbB0xIbmy5YOeD5PsgcvVpHSso54oev2RH+XE82e7wOLfzYLa1aEjD L5VwRj/JfENvVjOv3nQB9OvOyM9FMg== =t/Ef -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 21 10:56:31 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C03A3A0F97 for ; Fri, 21 Aug 2020 10:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERo22JuhirFj for ; Fri, 21 Aug 2020 10:56:26 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1703A3A0F95 for ; Fri, 21 Aug 2020 10:56:25 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BY8Mr46M5zyg2; Fri, 21 Aug 2020 19:56:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <26400.1598031282@localhost> Date: Fri, 21 Aug 2020 19:56:24 +0200 Cc: "asdf@ietf.org" X-Mao-Original-Outgoing-Id: 619725384.055841-6f2573874bb832d21772ebafc47885fd Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> <26400.1598031282@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 17:56:30 -0000 On 2020-08-21, at 19:34, Michael Richardson = wrote: >=20 > I think that we need some additional text around the proposed idea to = call > Implementation Drafts. In the charter? Being the lazy Bremen citizen I am [1], I now tried to steal from the = HTTPBIS and QUIC charters here. Nothing about that in the charter. = Could that be a mode of operation that the WG decides, without formal = IESG agreement? Gr=C3=BC=C3=9Fe, Carsten [1] https://de.wikipedia.org/wiki/Sieben_Faulen From nobody Fri Aug 21 13:12:25 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7553A11DE for ; Fri, 21 Aug 2020 13:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjQe47dUoBe0 for ; Fri, 21 Aug 2020 13:12:20 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 B47B03A11E0 for ; Fri, 21 Aug 2020 13:12:20 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id m23so2348343iol.8 for ; Fri, 21 Aug 2020 13:12:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KtAZnQNFTwyR6owTKNeUS0yHoeKVQHAWtMQNJrkF0Gs=; b=o6pXgl9vCm002XOaxKNFOyOwDzOnGq2kbxpXqLWSQH1kdVNyLXoAQAT0oPrWNx36A2 cs/kJp55iWAvpeZqTg8SbfrIoSXoYM38vFySTmqH+U9O7NNdHz0DK14KRbubXP1KWana dv+gYmNw9nwEEBnK+W8ZEgl56nmBLwhxTod3z3N0/lySZFM8x/S3HCfseEWqov34/NCu SA8q4QGBk02FvSzWloT2e7ijoy0JOIK4SkUW/cZhJlubDURnkhA6hb/HlXnfEuelaFeC hPzClxd71+YaX7f1L0mB+g9S6NsT1oDwVq71XUZUdlZjevQF4x5x1dEBisdzpM+0rEWi wIsg== X-Gm-Message-State: AOAM5310ASzRl1YURlJozqDhk/CRhfyCXXQAJwt/Q8cJ4OQruuNeY/pu +B9ZFFPRT/jAQA/0714t1eQUbyH8GhR2CPd/cwulwnh+5u3x/A== X-Google-Smtp-Source: ABdhPJxiymVgJ4Usut94x15H7FDvIbHgVgZSWY3XIVY7nt13NrmdSasp+4W+zfbCeeog5YRrZ/9MnZ/QzV6vWmGxiGc= X-Received: by 2002:a6b:8d8f:: with SMTP id p137mr266798iod.195.1598040739775; Fri, 21 Aug 2020 13:12:19 -0700 (PDT) MIME-Version: 1.0 References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <11386.1597843091@localhost> <28674.1598031874@localhost> In-Reply-To: <28674.1598031874@localhost> From: Barry Leiba Date: Fri, 21 Aug 2020 16:12:08 -0400 Message-ID: To: Michael Richardson Cc: asdf@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Asdf] on ASDF cycling at internet-draft X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 20:12:22 -0000 > As Carsten says, it's not our WG's purpose to try to fix the IESG, I guess we > just have to work around things. Well, it's not for the working group to fix the IESG or the IETF in general, but it *is* for the working group to decide how the working group should operate. If the working group, by rough consensus, thinks that publishing a PS spec with the intention of replacing it after more "running code" experience, then that's what the working group should do. If it's the rough consensus that going through implementation experience during the development of the first PS spec is the better way, then that's what should happen. It's up to the working group, and I'm behind either approach. Barry On Fri, Aug 21, 2020 at 1:44 PM Michael Richardson wrote: > > > Barry Leiba wrote: > > Michael, have a chat with Mark Nottingham: this is what httpbis did and > > quic is doing, and it worked very effectively for them. > > Yes, I know that they did this. > I believe it works because the parties involved are > a) funded to implement Internet-Drafts (not just discuss) > b) actively deploy/test, with the understanding that it may break > c) includes implementers that have both significant client and server properties > > My impression is that this mostly applies to ASDF as well, although (c) is irrelevant. > > > There are benefits to having a version in a PS RFC, then making the > > next version a new PS RFC that Obsoletes the first, and so on. > > This is was how RFC1310/RFC1602/RFC2026/etc. intended, and it seems that it > has again gotten unstuck, pushing WGs like httpbis and quic AND ASDF to take > this approach. It seems that every 15 years, the process becomes ossified. > > As Carsten says, it's not our WG's purpose to try to fix the IESG, I guess we > just have to work around things. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Fri Aug 21 15:55:08 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE86D3A1406 for ; Fri, 21 Aug 2020 15:55:06 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbPCr5-rtNJE for ; Fri, 21 Aug 2020 15:55:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7398F3A1405 for ; Fri, 21 Aug 2020 15:55:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 723EB38A20; Fri, 21 Aug 2020 18:34:10 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ndCvn0O1_h_e; Fri, 21 Aug 2020 18:34:09 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 84C0438A1F; Fri, 21 Aug 2020 18:34:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 57BEB1AA; Fri, 21 Aug 2020 18:55:03 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , "asdf\@ietf.org" In-Reply-To: References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> <26400.1598031282@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 22:55:07 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: > On 2020-08-21, at 19:34, Michael Richardson wrote: >> >> I think that we need some additional text around the proposed idea to call >> Implementation Drafts. > In the charter? > Being the lazy Bremen citizen I am [1], I now tried to steal from the > HTTPBIS and QUIC charters here. Nothing about that in the charter. > Could that be a mode of operation that the WG decides, without formal > IESG agreement? I'm thinking that it fits into the initial milestones. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9AUMcACgkQgItw+93Q 3WUFjwf+JOaTsPoMSuSrdGS4jI8fPZCIFrtbbu3eQNdRenFeEdWj+RvwYnOgOs2b 6QxExnFgcK2twJxCM7kL6pOaXKnNThbuTYYcjVfE7xlKWodwms1InI3mvx5tKwV/ gs2QnN96ItJw34WMxBpNFa0vDEjeGPp/80AKqgfuXJ1h0i5q09NyLeF+bCmK/3wy k7hNTSRDANr1zlI/ioBZ+dIaKVXvM7bx4YgPvX+l8GMoD8pSkgy/5nC42vBeRrIu +r1YbRLeDwYh2JkxdzdNf36dv4YvhSY5ERataRN8+sgj5+crDN9DIRNjrPq2234m Xg32O0ePyLXvBScMCMeTny6hdwRKPg== =wHWu -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 21 22:47:11 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C983A0DAE for ; Fri, 21 Aug 2020 22:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Qz9T4GdSdq9 for ; Fri, 21 Aug 2020 22:47:07 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6233A0DAA for ; Fri, 21 Aug 2020 22:47:05 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BYS7r1NR8zySN; Sat, 22 Aug 2020 07:47:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <2195.1598050503@localhost> Date: Sat, 22 Aug 2020 07:47:03 +0200 Cc: "asdf@ietf.org" X-Mao-Original-Outgoing-Id: 619768023.635646-a9682af8fa4ee910c79892571b0b729f Content-Transfer-Encoding: quoted-printable Message-Id: <88E71F97-7B67-424C-A721-D023F137B279@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> <26400.1598031282@localhost> <2195.1598050503@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 05:47:10 -0000 On 2020-08-22, at 00:55, Michael Richardson = wrote: >=20 > I'm thinking that it fits into the initial milestones. Sounds good. Like this? ## Initial Milestones There is only one deliverable, the SDF specification. It is not currently foreseen that this will be split into multiple documents, but that is also not excluded. The plan is to evolve the specification in a regular rhythm, with a new Implementation Draft available about bi-monthly. * SDF specification ("SDF 1.0"), WG document adopted, September 2020 * SDF specification ("SDF 1.1"), Implementation Draft, November 2020 * SDF specification ("SDF 1.2"), Implementation Draft, February 2020 * (continuing in the rhythm...) * SDF specification ("SDF 1.n"), PS to IESG, September 2021 Now https://github.com/one-data-model/ietf108/pull/7 Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Aug 23 14:22:30 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6C13A0E6F for ; Sun, 23 Aug 2020 14:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DovcXBYG2lI for ; Sun, 23 Aug 2020 14:22:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3EA3A0E6D for ; Sun, 23 Aug 2020 14:22:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 18D38389D4; Sun, 23 Aug 2020 17:01:30 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZVZdvh733i8n; Sun, 23 Aug 2020 17:01:23 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8D37F389D2; Sun, 23 Aug 2020 17:01:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1C2465ED; Sun, 23 Aug 2020 17:22:18 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: "asdf@ietf.org" In-Reply-To: <88E71F97-7B67-424C-A721-D023F137B279@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> <26400.1598031282@localhost> <2195.1598050503@localhost> <88E71F97-7B67-424C-A721-D023F137B279@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Sun, 23 Aug 2020 17:22:18 -0400 Message-ID: <10564.1598217738@localhost> Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 21:22:29 -0000 Carsten Bormann wrote: CB> Sounds good. CB> Like this? CB> ## Initial Milestones CB> There is only one deliverable, the SDF specification. CB> It is not currently foreseen that this will be split into multiple CB> documents, but that is also not excluded. CB> The plan is to evolve the specification in a regular rhythm, with a CB> new Implementation Draft available about bi-monthly. CB> * SDF specification ("SDF 1.0"), WG document adopted, September 2020 CB> * SDF specification ("SDF 1.1"), Implementation Draft, November 2020 CB> * SDF specification ("SDF 1.2"), Implementation Draft, February 2020 CB> * (continuing in the rhythm...) CB> * SDF specification ("SDF 1.n"), PS to IESG, September 2021 So, in that rhythm (~3 months), it would be: 1.3 May 2021 1.4 Sept 2021, PS to IESG ?? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sun Aug 23 22:26:46 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C913A0A36 for ; Sun, 23 Aug 2020 22:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovXl47jHUhqM for ; Sun, 23 Aug 2020 22:26:43 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A993A0A2D for ; Sun, 23 Aug 2020 22:26:42 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BZgbN3ddVzyTd; Mon, 24 Aug 2020 07:26:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <10564.1598217738@localhost> Date: Mon, 24 Aug 2020 07:26:40 +0200 Cc: "asdf@ietf.org" X-Mao-Original-Outgoing-Id: 619939600.083158-54c913ca76921f3c1c3b50a79fc2078d Content-Transfer-Encoding: quoted-printable Message-Id: <0809D764-4ECE-4EFF-AD3B-2C71E7F42D05@tzi.org> References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <9820.1597842659@localhost> <7E929A80-66E0-456E-89D4-922181686C3C@tzi.org> <18914.1597886637@localhost> <9B5FDA18-E7C0-4E16-B9DD-7BC00B087EDC@tzi.org> <26400.1598031282@localhost> <2195.1598050503@localhost> <88E71F97-7B67-424C-A721-D023F137B279@tzi.org> <10564.1598217738@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] Kicking off ASDF X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 05:26:45 -0000 > CB> The plan is to evolve the specification in a regular rhythm, = with a > CB> new Implementation Draft available about bi-monthly. >=20 > CB> * SDF specification ("SDF 1.0"), WG document adopted, September = 2020 > CB> * SDF specification ("SDF 1.1"), Implementation Draft, November = 2020 > CB> * SDF specification ("SDF 1.2"), Implementation Draft, February = 2020 > CB> * (continuing in the rhythm...) > CB> * SDF specification ("SDF 1.n"), PS to IESG, September 2021 >=20 > So, in that rhythm (~3 months), it would be: > 1.3 May 2021 > 1.4 Sept 2021, PS to IESG > ?? Well, bi-monthly is not tri-monthly. I tried to refrain from = prognosticating the exact version number we=E2=80=99ll go to IESG with, = but if we manage to keep up the rhythm, it would be 1.6. (I actually = think it is more likely that we=E2=80=99ll slow down at the end when = getting asymptotic.) .oOo. Michael has approved the pull request, any other takers? I think this is the last thing we need to do before submitting the = proposed charter. Approve (or comment) at: https://github.com/one-data-model/ietf108/pull/7 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Aug 25 10:54:56 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192A63A0B57 for ; Tue, 25 Aug 2020 10:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.845 X-Spam-Level: * X-Spam-Status: No, score=1.845 tagged_above=-999 required=5 tests=[LONGWORDS=1.844, SPF_HELO_NONE=0.001, SPF_PASS=-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 bba3UQL007LQ for ; Tue, 25 Aug 2020 10:54:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0174D3A0B55 for ; Tue, 25 Aug 2020 10:54:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A598238993; Tue, 25 Aug 2020 13:33:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ld-3claOoJ52; Tue, 25 Aug 2020 13:33:50 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 40FBF38991; Tue, 25 Aug 2020 13:33:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7FE62D0F; Tue, 25 Aug 2020 13:54:47 -0400 (EDT) From: Michael Richardson To: Barry Leiba , asdf@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Asdf] the ASDF charter seems.... done? X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 17:54:54 -0000 --=-=-= Content-Type: text/plain It has been worked at: https://github.com/one-data-model/ietf108 It seems to be done. Would you agree? But, maybe some people are still on vacation and haven't had change to object. ---- # Charter proposal for an ASDF WG - Name: A Semantic Definition Format for Data and Interactions of Things (ASDF) - Revision: 0.1.0 ## Background Data and interaction models of IoT devices today exhibit unneeded diversity between different industry ecosystem standards development organizations (SDOs), hindering interoperability across these ecosystems with little discernible benefit from the diversity. Early 2019, [One Data Model (OneDM)][2] was started to bring several IoT SDOs and IoT device and platform vendors together under a broad, multi-party liaison agreement, with a goal of arriving at a common set of data and interaction models that describe IoT devices. Ideally, for every class of IoT device, there is just a single model selected/created by the participating organizations, which everyone can adopt. As a common language for writing down these models, the Semantic Definition Format (SDF) was created, which can represent IoT Things, their composition from reusable Objects, their Interaction Affordances (Properties, Actions, Events), and the data models relevant to describe these Affordances. SDF is representing these models in JSON, enabling re-use of specification formats such as CDDL (RFC8610) and the formats proposed at json-schema.org and their tooling, for describing both the SDF format itself and the structure of the data to be modelled in SDF. Some 200 models in SDF format have been contributed by participating ecosystems; new models are being submitted continually. Version 1.0 of the SDF specification was published on the OneDM github repository and as an [Internet-Draft][1]. OneDM is now focusing on [consolidating the body of submitted models][3] and developing processes for arriving at harmonized models that span different industry ecosystems in a common way; they look towards the IETF for developing SDF 1.0 further into a high-quality specification. ## ASDF The objective of the ASDF WG is to develop SDF to an IETF-quality specification for Thing Interaction and Data Modelling, working with experts from OneDM and its contributing organizations. On the way to that specification, further functionality requirements will be addressed that emerge in the usage of SDF for model harmonization. The ASDF WG will work closely with the CBOR WG, home of the CDDL specification. It will also engage the still active mailing list of the dormant JSON WG. Recent proposals to form an IRTF formal description techniques (FDT) Research Group may lead to another collaboration partner. The Thing-to-Thing Research Group (T2TRG) and its WISHI program can be instrumental in engaging researchers and other SDOs in this space, for instance W3C WoT, which is working on Thing Description Templates and related specifications. [1]: https://www.ietf.org/id/draft-onedm-t2trg-sdf-00.html [2]: https://onedm.org [3]: https://onedm.org/faq ## Initial Milestones There is only one deliverable, the SDF specification. It is not currently foreseen that this will be split into multiple documents, but that is also not excluded. The plan is to evolve the specification in a regular rhythm, with a new Implementation Draft available about bi-monthly. * SDF specification ("SDF 1.0"), WG document adopted, September 2020 * SDF specification ("SDF 1.1"), Implementation Draft, November 2020 * SDF specification ("SDF 1.2"), Implementation Draft, February 2020 * (continuing in the rhythm...) * SDF specification ("SDF 1.n"), PS to IESG, September 2021 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9FUGcACgkQgItw+93Q 3WUhpQf/X8wSsJzkptM1UfpaLDGDqN5UkWRcs+xY6n4QPV8usNgvosoZPzV8nNFB z6wMR8pAlmL0BqXV2i0SGTb9mBByVs223d/ml/UagyO9Vyt37KbEgR0/KEVLQyHa Yix+yB0QYlzE+UQ5F9LVwM98tPMxoppnwD7tgIOeDqVMKjRdHQKRzLqzytB1WGFX X9Dm+9h84UQmuzsOuQGxduXOfpbrTsjQat9mb7w5tbN5jRUuCXWXSlVeco+r2Su5 PIMCEDnNB/ScC36q9AKOpyjo9dUmcRVWR0n3OuEhI/wK1PgZxP+OTm3fgmgSrVmy NoY3wxtLJBhZewW+JAWeEPNnsTZqjQ== =Qma3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 27 12:31:47 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDBA3A124A for ; Thu, 27 Aug 2020 12:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Xpbcvf6RABd2 for ; Thu, 27 Aug 2020 12:31:44 -0700 (PDT) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) (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 B37E93A124D for ; Thu, 27 Aug 2020 12:31:44 -0700 (PDT) Received: by mail-il1-f174.google.com with SMTP id t13so5859117ile.9 for ; Thu, 27 Aug 2020 12:31:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kKUvTL9gmtGcMiErbkpuc9jGSe3RXeu7FGoRyXWEjZ8=; b=jwZAlCmYMnLC2E2YqDl+qBPigcyQQ4AvRZ4GgJ9v8pwhM+CObMBrFVm52FoR/oex8H XWq3dJ0VRI3N/8L4bJjD85xGTicfahb8MZdAJ3YoLGCK6QFy6Y/vGBvil5Q/jlTx+ZPN nDdTVwUw5m1WwrdNSuwXbFwmR0SuhUQXMQfaiz66Z6WW3KvQEr+MSyhC07JtQ0Wsmms3 RWwstHEz7nqiDFWo6siBRxTm6cnHmpYtdR5A7K39DTNIRpYmXeu13bBdGfiERo0FBINE uYiwG1iv+nFB2ZXB5nWu1bwJvRK2BGpdIeo7MRSP/MTFsCjNHOQ2fMEW8Hj8MMR6Q/zg 0iCQ== X-Gm-Message-State: AOAM532d7XmZulTk31diwE9EuTdzrNTB/BhSjeF6cZaVk/E9lGkR6uWr Auh7Nht6eqRXwcO3og+wn7oP5+dN9rMtW97T/so= X-Google-Smtp-Source: ABdhPJyeILVjN8sZqGVB0r7sWcir3zUXNWBvuAbikx/kdiusFUZUdhQFxIWUhrDufI9Kp7A5eqO2fZvv9neNyyrnxOk= X-Received: by 2002:a05:6e02:140f:: with SMTP id n15mr15143220ilo.277.1598556703698; Thu, 27 Aug 2020 12:31:43 -0700 (PDT) MIME-Version: 1.0 References: <7342.1598378087@localhost> In-Reply-To: <7342.1598378087@localhost> From: Barry Leiba Date: Thu, 27 Aug 2020 15:31:32 -0400 Message-ID: To: Michael Richardson Cc: asdf@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Asdf] the ASDF charter seems.... done? X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 19:31:46 -0000 > It has been worked at: > https://github.com/one-data-model/ietf108 > > It seems to be done. Would you agree? I agree, and I've put it into the datatracker, with some minor editing. From here on, I'll update the proposed charter in the datatracker: https://datatracker.ietf.org/doc/charter-ietf-asdf/ > But, maybe some people are still on vacation and haven't had a chance to object. There's still time to make adjustments. Here's an expected timeline: - I'll leave it in the current "draft" state for a couple of weeks to be sure it's stable; please keep me informed about any issues. - I'll put it into IESG evaluation after that, to be on the 24 September telechat. - It will go out for "external review", at which point it will be announced on the main IETF list and on the new-work list. - It will come back to the IESG for final approval on 8 October. If you would like me to shorten that timeline by two weeks, I can cut the "draft charter" period to one week and get the initial IESG evaluation onto the 10 September telechat, with final approval expected on 24 September. Let me know if y'all think it's sufficiently ready for that. Barry From nobody Thu Aug 27 18:58:34 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EA73A14CB for ; Thu, 27 Aug 2020 18:58:33 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E3SRxqfL3VG for ; Thu, 27 Aug 2020 18:58:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC793A0BF6 for ; Thu, 27 Aug 2020 18:58:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7D109389CF; Thu, 27 Aug 2020 21:37:29 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rQnrR6lhQrln; Thu, 27 Aug 2020 21:37:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CC37D389C9; Thu, 27 Aug 2020 21:37:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 25A9A4D7; Thu, 27 Aug 2020 21:58:24 -0400 (EDT) From: Michael Richardson To: Barry Leiba cc: asdf@ietf.org In-Reply-To: References: <7342.1598378087@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] the ASDF charter seems.... done? X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 01:58:34 -0000 --=-=-= Content-Type: text/plain Barry Leiba wrote: > I agree, and I've put it into the datatracker, with some minor > editing. From here on, I'll update the proposed charter in the > datatracker: > https://datatracker.ietf.org/doc/charter-ietf-asdf/ Thank you. I suppose I could have done that. > If you would like me to shorten that timeline by two weeks, I can cut > the "draft charter" period to one week and get the initial IESG > evaluation onto the 10 September telechat, with final approval > expected on 24 September. Let me know if y'all think it's > sufficiently ready for that. I think that the extra two weeks will not help. Or rather, we'll know by the end of next week if we need more time. I don't think we will. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEyBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9IZL8ACgkQgItw+93Q 3WU6dgf4/mgqhTaA4CyDsP9KYkT3yamWN/5G6xaLHoWz3UFZaEvMR5V6GW4tpYZv XlOF5louMikj4tN3XCVBcDw9yDVusBTemZyAXyXwbdQxMgpY4+5iQuQTDGlipfqJ 39VJZ71Qjg3HGemSEqKl11rkACNuNpXSpAtS82QgTqYGFuK5NZgo0IiODsPjc45t 3liFXJjLlvai7MF2AHIOpWxUAj0wdRNHn73ABRj5SGyveLr6gNviApBZWme2vJDf 8l3NENxT4eP0YFobbfCdLXWE/u/EI0I2RmphfgVZURVgMsE9e0i+6kemAoq9GSrq ELL3da8nGaeBy4Y9kc10fXZ6BnFM =57lp -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 01:55:04 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23AD3A0E57 for ; Fri, 28 Aug 2020 01:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Bpgz0Y3OaW2g for ; Fri, 28 Aug 2020 01:55:00 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10060.outbound.protection.outlook.com [40.107.1.60]) (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 5B77C3A0E55 for ; Fri, 28 Aug 2020 01:55:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VamFjyjKXS8Q4+E2p38SAOj21w6lQg9P1GLyL6UQgK2lpkN681GJ6yNF2AfzKwLMZ/kvN7VFKi8dMKr/2fUYMG736+swtemBKrRJAIGe3s2B8mRuyehNuRZnpaB3TNVjpaTJcNV0SX7NqA53IfrVJYB8IIdnV66+kzl+lk0GdZN64yWZB3vd6lK8ni+lOrwiH7LAyoTWXQLJ2VfwT4/y3B/uw4epbbmNSk2byNu3ZnDa56irqaE3pbD6iIztAL9x4MQG+w8CbPEe6PTMtlVggwi7C8xX8HYGmHx+qLRJ213T3fEvOATdfdwgxp88yF5Zyeg0OJQ9vxOO+alY6dX+hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RKD945ehaN28oYpP6CiQlXDnFLycqxexxiiA9Vcu4hY=; b=iEULsB2PzsJ/2VhMmTtyPW0TStZRpn1N1KxIhX68KVrqBzaAiM8PK//SF1sw8hyT4SNeRwWQyzEwuGTFKMwPxsBHEzLQHvLztWklQlwWviQnH7dPZzIXUCD3apw/qWPDPedKdWkXbG/2FK1bxU96CeIL3FQrmQOfrkoK5QvpOiaGfAfFU9K99GI94VeW5k6nH4EH7ZQhvazT99+Ltnaqvk3lth4rQgdorI1j1p70/NUlRysL9xavtg63PannEvrEU6C9VglC7GCuilchxAauXQTBnyp7B3LeWdRH615YFv6KS5F3bIBmzw79LdNeiFNrCqYRV2CdXfTUS/ErT3ROtA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=RKD945ehaN28oYpP6CiQlXDnFLycqxexxiiA9Vcu4hY=; b=uu6fX+/YtwsUYZwtMJ/WUYrpOlfbVQdfWxMAvllzxZZmBvNJJT+LNJ/8n+AQrtRKov5dH9A6sBS+6G1NWcF3p05suPoBEt5IzXBJ9RcO8PcXYTQBhZKgNkWs8fvj+dMknPWTjhVnflkHQhmXschmZqA7JRuC1dIqY7TfXr1v/wU= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3820.eurprd07.prod.outlook.com (2603:10a6:7:81::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Fri, 28 Aug 2020 08:54:51 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::9b1:f546:660f:f8ed]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::9b1:f546:660f:f8ed%7]) with mapi id 15.20.3326.023; Fri, 28 Aug 2020 08:54:51 +0000 From: Niklas Widell To: Michael Richardson , Barry Leiba CC: "asdf@ietf.org" Thread-Topic: [Asdf] the ASDF charter seems.... done? Thread-Index: AQHWewjchfkZ3JBtvkmtWlZJ8qR5SqlMW0QAgABsFwCAAJXgAA== Date: Fri, 28 Aug 2020 08:54:51 +0000 Message-ID: References: <7342.1598378087@localhost> <16269.1598579904@localhost> In-Reply-To: <16269.1598579904@localhost> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [37.123.165.254] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f3d06c0-83c8-48c0-c979-08d84b3006cf x-ms-traffictypediagnostic: HE1PR0702MB3820: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JK+VulKpHS38WQYMBC488qgN/MoeC68Ydh2jwL49MMKy9YoxGELknOir/yJ14KKYiYtqFqGzIwZk/7WZ7x98nRGExEvZxKFeOAkhi2fkvpbXXwkv2eouhe3Pv2FffV1VUvdHYBxOUDWTuAqfIpidLshhGmAs9FjuQ2qIwT/tcTu8GQgqHv+WztD1c7DbfX8j7oTKc7eNyouBUurPpTbiSOWsBrWvrtuI1V2fKL4RoTrrREPAU4A0kzvZDHa3G/WKAmzwOX1oVgzwqq97ZtBN8wAS72u3Lbq3llPOH/KqcOpogHhPbh7CmB/YKf7XOWrdfiGwTTiwa7W7SuUNXaZi+OWQVI49NDFhyYom3gOCsuUhoO0qE1eatoRUQQ8Jx2/W2H1/x/OY9rJh0zNtlERs+Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(396003)(366004)(136003)(376002)(6486002)(8676002)(91956017)(66476007)(8936002)(4326008)(66556008)(64756008)(5660300002)(66446008)(6512007)(76116006)(66946007)(316002)(110136005)(6506007)(44832011)(966005)(36756003)(86362001)(186003)(26005)(33656002)(2906002)(478600001)(2616005)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: oVszKu3+EkDDWYA8e1X6I+HQcd93/I3OFsp5HrTvASC/K65bfAbfrTfam5ZAdC2bt1bneluVZnaCl9f0A0xRarrTTLp+qvIILAJVov0T4Ain2RRVtGkEUd8MO7qR79EM5QCcWJLxge1iuelEiqQV4gOPpRktKkonVsDMKtTn4/JaZ2Pl8n5YjTizNo0vejP1cNQY4BKzZnEjsKQULU+eUN0hq0Vh+xQT/0RP7HhRsGTQb6wVHwYuB8DBPH4eyGt01wwZVuG7WDkVsHUgz5J+wpWxfdaqGnkceg6bm93+NuqNMqWgcsme+68TB9fizJZYlT3pU3ceqb6fsBNm/Li9lKYtmAELKQlLY36OJ1P/2KZJmio24gJHDefIKA39LPwbtHGHzWj8upYcGYaK0VUvOOSrgL7uJPmr7lQuxPhLGesc1N5w8UWY+lTDRIZt9fU7FUoPa9z8QGxzw0bQMHdRVj1NyZ3w2Uql/F97R61KUJFovDA1eEN35v249hGjKh5HBEWExCJkRvyMK4FEhfP5A5DVPlV+Wc/eL5/i8XwT/zagGz5r07k3jloQnrI3eo5Qf0oeerw6hYHgRjj7Kd17oVq1lhJcezy0U6nmhbhvj46VWyETiXlf/2TWjcz+vSFPzkhjxdMaEU6gqqjFrp4soQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <525F1578EE1CA146B279C1BFB6907A21@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f3d06c0-83c8-48c0-c979-08d84b3006cf X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 08:54:51.6849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hA6D/BzQ4GKJS3wtRudRI/c3LQQQi+j3NaDBZ+NWiWOrjX30RbPIHLdwTe92l0iF60SOMioZjy1ItZvDBLgY/ObeWp4LrWZ60toaJsei2Pw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3820 Archived-At: Subject: Re: [Asdf] the ASDF charter seems.... done? X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 08:55:02 -0000 DQoNCu+7v09uIDIwMjAtMDgtMjgsIDAzOjU4LCAiQVNERiBvbiBiZWhhbGYgb2YgTWljaGFlbCBS aWNoYXJkc29uIiA8YXNkZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtY3IraWV0ZkBz YW5kZWxtYW4uY2E+IHdyb3RlOg0KDQogICAgQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0 ZXIub3JnPiB3cm90ZToNCg0KICAgICAgICA+IElmIHlvdSB3b3VsZCBsaWtlIG1lIHRvIHNob3J0 ZW4gdGhhdCB0aW1lbGluZSBieSB0d28gd2Vla3MsIEkgY2FuIGN1dA0KICAgICAgICA+IHRoZSAi ZHJhZnQgY2hhcnRlciIgcGVyaW9kIHRvIG9uZSB3ZWVrIGFuZCBnZXQgdGhlIGluaXRpYWwgSUVT Rw0KICAgICAgICA+IGV2YWx1YXRpb24gb250byB0aGUgMTAgU2VwdGVtYmVyIHRlbGVjaGF0LCB3 aXRoIGZpbmFsIGFwcHJvdmFsDQogICAgICAgID4gZXhwZWN0ZWQgb24gMjQgU2VwdGVtYmVyLiAg TGV0IG1lIGtub3cgaWYgeSdhbGwgdGhpbmsgaXQncw0KICAgICAgICA+IHN1ZmZpY2llbnRseSBy ZWFkeSBmb3IgdGhhdC4NCg0KICAgIEkgdGhpbmsgdGhhdCB0aGUgZXh0cmEgdHdvIHdlZWtzIHdp bGwgbm90IGhlbHAuDQogICAgT3IgcmF0aGVyLCB3ZSdsbCBrbm93IGJ5IHRoZSBlbmQgb2YgbmV4 dCB3ZWVrIGlmIHdlIG5lZWQgbW9yZSB0aW1lLg0KICAgIEkgZG9uJ3QgdGhpbmsgd2Ugd2lsbC4N Cg0KSSB0aGluayB0aGUgY2hhcnRlciBpcyBpbiBnb29kIHNoYXBlIHdpdGggbmVpdGhlciBsb29z ZSB0aHJlYWRzIG5vciBvdXRzdGFuZGluZyBpc3N1ZXMsIHNvIEknZCBiZSBpbiBmYXZvciBvZiBz aG9ydGVuaW5nIHRoZSB0aW1lbGluZSB0byB0aGUgU2VwdGVtYmVyIDEwLzI0IG9uZS4gVGhpcyBz dGlsbCBnaXZlcyBwZW9wbGUgYSByZWFzb25hYmxlIGNoYW5jZSB0byBzdGlsbCByYWlzZSBpc3N1 ZXMsIG5vdCB0aGF0IEkgZXhwZWN0IGFueSBlaXRoZXIuIA0KDQpGb3IgZm9sa3Mgb24gdGhlIGFz ZGYtbGlzdCwgX25vd18gd291bGQgYmUgYSBncmVhdCBvcHBvcnR1bml0eSB0byByYWlzZSBpc3N1 ZXMgb24gdGhlIGNoYXJ0ZXIsIGxhdGVzdCB2ZXJzaW9uIGhlcmU6IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1hc2RmLw0KDQoNCiAgICAtLQ0KICAgIE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzDQogICAgIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg0KQ2hlZXJzLCANCk5pa2xh cw0KDQoNCg0K From nobody Mon Aug 31 01:35:12 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560B23A10B9 for ; Mon, 31 Aug 2020 01:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Z+RpNpdL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pzIQwDcP 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 44fdlwJIiTXa for ; Mon, 31 Aug 2020 01:35:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6033A0FB4 for ; Mon, 31 Aug 2020 01:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2398; q=dns/txt; s=iport; t=1598862903; x=1600072503; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2WblV45ZoJQS7kuEraNfcI4kLCrVqtOS2peBJqXZzus=; b=Z+RpNpdLHIrqCpGpwRkntMUX3NH9ctqGa+Is4atuwQGY4U3PJeZeHduX YKQVBZKSI/6Nc2Cj9646xu+OJL/McYMOeo/sDV9KsZE52QndcTcq8eWVf YqBMUQI5QhhYN6E4J//r8slzV4jnUs4RTOLQW9n/Uuaarn/95N8oTDygn Y=; X-IronPort-AV: E=Sophos;i="5.76,375,1592870400"; d="scan'208";a="821027851" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Aug 2020 08:34:37 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 07V8Yb9J010185 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2020 08:34:37 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 03:34:37 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 03:34:36 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 31 Aug 2020 03:34:36 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LbzdH1u5l2CnGznIg8zwHeSuXWsj27rlKya5mT+g17tFabgW8ETFmfenBwHb1W4hJ1f9Bpc0qBV8BCqRMLTUa09KBP8WQ1wFucvOdFMpgwQ8TypU81SRISqGniRoamnK73R6+MgzxbGG/KVwDmux1z/Cj16Jq90r7cO1n4QzGU0ZjqTveLFEiCeLEXwNTmNjsQjyEvPSR9H9VsiVyQE5b4yPvRF6F7AIp8r39bolMKSeEWJc497tNF++tTL6+qN6bn2xBXcnol/3ykxQ9ArF2ks/hqE7rsGqer6El54irOoAKqcI/+ew6fUXzGZluBIm5SDCLbB1H0w4D2EyujBWgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2WblV45ZoJQS7kuEraNfcI4kLCrVqtOS2peBJqXZzus=; b=BtYXule0/H5eaI5jQvq4GwSdSGdu+BKfg5N0v15/5gWFnBa4Wtw2VpRIUz0qXTOipOqUfksnn4JWGs+E5+W2CN+iGULwlhnS4LrwpnmzTqQEo4v/d90nxHDI6DivDN5DzkkXhXvHiHAqdgoK6Ut+XXwngA8IaGrbWWZXiMapAOqDeODXtNPCibYY0zlqC5tjFgW6XcEINQMxw7OvWS83olB/2PeqS3RuOx1UbrmM0yoFAkjpMVWIvrsIu1HJfTLSI9rqHuWmvFUyOzVMyBOdJDRhaf3Ieo4wP+5qHlem4pDejNuOKlfVnHkPC2YQi69y2HtUZONiici4KWY6H2g1KQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2WblV45ZoJQS7kuEraNfcI4kLCrVqtOS2peBJqXZzus=; b=pzIQwDcPnPZwgjLw6iDGHG01JMV9vH+JA2t70mQ4/ib4fGz15T3h/a0iU0K4hf7csojh43CVnx8YbvFjQX0TKYu/UwzyQMKzBfO2RfIdDykbKP77H5Zm+6pMJIuEIvNrgWo+0g8GqoQRBQIcE5mh6xg5bZOEGzSS9npnLn54cj8= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (2603:10b6:300:10c::11) by MWHPR11MB1552.namprd11.prod.outlook.com (2603:10b6:301:e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.21; Mon, 31 Aug 2020 08:34:34 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::34c5:6550:a098:209f]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::34c5:6550:a098:209f%12]) with mapi id 15.20.3326.025; Mon, 31 Aug 2020 08:34:34 +0000 From: "Wouter van der Beek (wovander)" To: Niklas Widell , "Michael Richardson" , Barry Leiba CC: "asdf@ietf.org" Thread-Topic: [Asdf] the ASDF charter seems.... done? Thread-Index: AQHWewjlPJzwCBt6wUqTzfVMje3j3qlMW0QAgABsFwCAAHRagIAEsQ+g Date: Mon, 31 Aug 2020 08:34:34 +0000 Message-ID: References: <7342.1598378087@localhost> <16269.1598579904@localhost> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 190bde3a-bf96-4218-770d-08d84d88b056 x-ms-traffictypediagnostic: MWHPR11MB1552: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m4C9jqMYe1SJ79pOLbxFKqIBJSQSVALl5TiHqYhpa7OuwV8qO2hKLfCTAI2pL0uPGSA9YTIAGuc/sVZt8At9V4aBTS2YhEUb5IxoUMsbsZmwzS0VVSpp1IaGhh/husy4qjnvBGdYZw7IiCftLzZCkGi6Qvg8sRv6BkcpVe7xxqKmeliJQmb5dxrnOmnPRm/Tp9QJ4vl9m/FBH8BE3yGKwqAjRZdBikABgsU1M0dSJOvVHHwWIvBD2r/VXjLYN5Qh/jVNw4vb9qptEfZE9vZ2h48qqYF6zQ4a2d5sOj4gdPJsP6FhnmKaHsnN90RKsABzAbbcjX6o4VyzTf7MKc3N39YmnCcucr621SXnss2H/iwcJzK0wet/M3u3Dhflu1BGq3Dp3kX4piX5zSVEKla3qA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1838.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(39860400002)(346002)(366004)(9686003)(66476007)(316002)(8676002)(186003)(66556008)(71200400001)(5660300002)(66446008)(7696005)(2906002)(64756008)(4326008)(52536014)(55016002)(83380400001)(26005)(8936002)(110136005)(86362001)(66946007)(33656002)(6506007)(76116006)(966005)(478600001)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: evS4vQVSAWOwEVUMOOjhE+6X9aoyykKYnGXAhxJjuOhDfRLljo7P514gWXWB3x0E1268cql16gwjKFDzmB592287i1ctum5X6wi5BxTRHLVkotWZuFXLy276BKSrDcHI/igQ9g3aDWWDMmbTXFlG+H6IfyI7D7ecWauUH3KbRtw2BMzNmqfPkoUNA3IzvGrHgKzI5Kfy5eVqZCq1FkJS2v0WWLcBrRYRiI9P+pmvd/+xitONC5Gr0cIidOFXenY9kdTR2iNuNCn7YuG6iOrrVWehfhYrhbavh9y4YU4lFGUg8MOERdYMzK67qTW5RfDMsMYpNXMA+fMBhjzHcNXQ5t4ERW6UONb9/7RuniePlCsFOKtMlXPEebnBIZV/BTetS2f/z+trOfG5IyGeJGrn+zrI9oiTDrRlPtwwXng/5Wyt18Sa947H14KgoWhMgb6N69eYgJ1U0Pvsewa762AvS8V68BxrNGfBKWqPZJkNgRkQJc03d2i0ILBfScV9Oqni1uY/i+IeE2LrzkDMD/GIJh92x8wUijKtRQEI9nrWxHukWOKwBJz8nnBsfss5i52QTvcyStpQAxMpSOiogITgrfdz4Yrh8i4Ts1ilRlnhBqMTq6YcSO1BpX+lH4Uo2u0yvbENaOwNWdCMDgMcryns7g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1838.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 190bde3a-bf96-4218-770d-08d84d88b056 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 08:34:34.1173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /KiKuc5+Y9la/LpnXfaVKm6vvug93eA3LFJZUP4LLujrjsh6p2MpLts4CU7HLp+jOpXkxvZN8yi264re17XTSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1552 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Asdf] the ASDF charter seems.... done? X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 08:35:11 -0000 SGkgQWxsLA0KDQpUaGUgZGlzY3Vzc2lvbiBvbiB0aGUgY2hhcnRlciBoYXMgYmVlbiBtaW5pbWFs IA0Kd2h5IHdhaXQgYW5vdGhlciAyIHdlZWtzLg0KDQpLaW5kIFJlZ2FyZHMsDQpXb3V0ZXINCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFTREYgPGFzZGYtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIE5pa2xhcyBXaWRlbGwNClNlbnQ6IEZyaWRheSwgQXVndXN0IDI4 LCAyMDIwIDk6NTUgQU0NClRvOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1h bi5jYT47IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4NCkNjOiBhc2RmQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW0FzZGZdIHRoZSBBU0RGIGNoYXJ0ZXIgc2VlbXMuLi4uIGRv bmU/DQoNCg0KDQrvu79PbiAyMDIwLTA4LTI4LCAwMzo1OCwgIkFTREYgb24gYmVoYWxmIG9mIE1p Y2hhZWwgUmljaGFyZHNvbiIgPGFzZGYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWNy K2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCg0KICAgIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJh QGNvbXB1dGVyLm9yZz4gd3JvdGU6DQoNCiAgICAgICAgPiBJZiB5b3Ugd291bGQgbGlrZSBtZSB0 byBzaG9ydGVuIHRoYXQgdGltZWxpbmUgYnkgdHdvIHdlZWtzLCBJIGNhbiBjdXQNCiAgICAgICAg PiB0aGUgImRyYWZ0IGNoYXJ0ZXIiIHBlcmlvZCB0byBvbmUgd2VlayBhbmQgZ2V0IHRoZSBpbml0 aWFsIElFU0cNCiAgICAgICAgPiBldmFsdWF0aW9uIG9udG8gdGhlIDEwIFNlcHRlbWJlciB0ZWxl Y2hhdCwgd2l0aCBmaW5hbCBhcHByb3ZhbA0KICAgICAgICA+IGV4cGVjdGVkIG9uIDI0IFNlcHRl bWJlci4gIExldCBtZSBrbm93IGlmIHknYWxsIHRoaW5rIGl0J3MNCiAgICAgICAgPiBzdWZmaWNp ZW50bHkgcmVhZHkgZm9yIHRoYXQuDQoNCiAgICBJIHRoaW5rIHRoYXQgdGhlIGV4dHJhIHR3byB3 ZWVrcyB3aWxsIG5vdCBoZWxwLg0KICAgIE9yIHJhdGhlciwgd2UnbGwga25vdyBieSB0aGUgZW5k IG9mIG5leHQgd2VlayBpZiB3ZSBuZWVkIG1vcmUgdGltZS4NCiAgICBJIGRvbid0IHRoaW5rIHdl IHdpbGwuDQoNCkkgdGhpbmsgdGhlIGNoYXJ0ZXIgaXMgaW4gZ29vZCBzaGFwZSB3aXRoIG5laXRo ZXIgbG9vc2UgdGhyZWFkcyBub3Igb3V0c3RhbmRpbmcgaXNzdWVzLCBzbyBJJ2QgYmUgaW4gZmF2 b3Igb2Ygc2hvcnRlbmluZyB0aGUgdGltZWxpbmUgdG8gdGhlIFNlcHRlbWJlciAxMC8yNCBvbmUu IFRoaXMgc3RpbGwgZ2l2ZXMgcGVvcGxlIGEgcmVhc29uYWJsZSBjaGFuY2UgdG8gc3RpbGwgcmFp c2UgaXNzdWVzLCBub3QgdGhhdCBJIGV4cGVjdCBhbnkgZWl0aGVyLiANCg0KRm9yIGZvbGtzIG9u IHRoZSBhc2RmLWxpc3QsIF9ub3dfIHdvdWxkIGJlIGEgZ3JlYXQgb3Bwb3J0dW5pdHkgdG8gcmFp c2UgaXNzdWVzIG9uIHRoZSBjaGFydGVyLCBsYXRlc3QgdmVyc2lvbiBoZXJlOiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtYXNkZi8NCg0KDQogICAgLS0NCiAg ICBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBT b2Z0d2FyZSBXb3Jrcw0KICAgICAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQoNCkNoZWVycywg DQpOaWtsYXMNCg0KDQoNCi0tIA0KQVNERiBtYWlsaW5nIGxpc3QNCkFTREZAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXNkZg0K From nobody Mon Aug 31 07:25:57 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D62C3A13E7 for ; Mon, 31 Aug 2020 07:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGDeF3ZnLZ-5 for ; Mon, 31 Aug 2020 07:25:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298D73A13E6 for ; Mon, 31 Aug 2020 07:25:53 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BgCDH00BvzyWD; Mon, 31 Aug 2020 16:25:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann Date: Mon, 31 Aug 2020 16:25:50 +0200 Cc: t2trg@irtf.org, One Data Model Group X-Mao-Original-Outgoing-Id: 620576750.3947901-9b09c7ba8d2efee091c02d379fbdddd2 Content-Transfer-Encoding: quoted-printable Message-Id: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> To: asdf@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [Asdf] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 14:25:55 -0000 In today=E2=80=99s OneDM call, Bruce Nordman brought up the issue that, = in the end, we=E2=80=99ll need concrete representations to talk to = devices and use their data. So if we have one ecosystem that uses 0..100 for describing the = brightness setting for a lamp, another one that uses 0..254 (where 255 = means something complete different), and a third with 0..65535, what do = we do? (And these might also differ whether they describe a emitted = light power level or a perceptive luminous flux level.) The underlying problem is that we are abusing data model level = description techniques (in part borrowed from json-schema.org) to = describe information models. That works reasonably well until we start taking these data model level = descriptions at face value. The fact that some converged model uses a = scale based on the L component of Lu=E2=80=99v=E2=80=99 does not mean = that everybody has to represent their ecosystem model the same way. The obvious second problem is that we haven=E2=80=99t tackled a = framework for describing protocol bindings (which, initially, will = mostly be ecosystem bindings). That would be the place where we say how = the L component needs to mapped to the ecosystem specific concrete = representation. Since that mapping, in principle, can have arbitrary = complexity, completely covering all cases requires Turing-equivalent = functionality in a description language. Or we could go for an 80 % = solution and then, for the 20 %, register mapping components that are = more complex in an IANA registry. Let=E2=80=99s discuss this based on some real-world examples =E2=80=94 = it is easy to construct artificial ones that have more complexity than = we actually need. CCing T2TRG as well because quite a few people there are familiar with = the problem; maybe we want to have the bulk of the discussion on = asdf@ietf.org though. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 31 07:50:45 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000B23A0C33 for ; Mon, 31 Aug 2020 07:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CH/ruZMY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Wh+8XqSf 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 5Oe0vV1EMai7 for ; Mon, 31 Aug 2020 07:50:42 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251673A0C2B for ; Mon, 31 Aug 2020 07:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4816; q=dns/txt; s=iport; t=1598885442; x=1600095042; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/IJVQkHk1Q1TJasronKFOsPm66T9yKmbvlQ5zsa7huc=; b=CH/ruZMYb/VM56qmEuMzyRuWCy/1j/gH7AF8utHN8FY33Yi0MiiAHh7Y drvTz1Wp56hMJsNg7s/2+w9wuJg1RES5oNVxINyBg3nZW2Q8aCpRFbL2O 8LCCqCr7i4CWyE/2sB5YlLqn87Tsfytjy9biQRDOpDd8Nhj4njRF8vee0 0=; IronPort-PHdr: =?us-ascii?q?9a23=3A8EzPBhTmOt9/MLqh6AmUDevvlNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN2J9+BFze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXidVyUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxCQA7DU1f/5NdJa1fgQmDHFEHcFg?= =?us-ascii?q?vLAqDbkCDRgONdphxglMDVQsBAQEMAQEYCwoCBAEBhEwCF4IzAiQ4EwIDAQE?= =?us-ascii?q?LAQEFAQEBAgEGBG2FLwYnDIVyAQEBBAEBCgYREQwBASwLAQsEAgEGAg4DBAE?= =?us-ascii?q?BAwImAgICJQsVCAgCBAENBQgTB4MFgksDLgEOlRCQaAKBOYhhdoEygwEBAQW?= =?us-ascii?q?FQxiCEAMGgQ4qgnGDZYZPG4IAgRFDgh8uPoJcAQGBQSAVgwAzgi2QBSiCbqN?= =?us-ascii?q?TCoJlj3iKW6BWklGfVwIEAgQFAg4BAQWBayOBV3AVO4JpUBcCDYZOi0KFFIV?= =?us-ascii?q?CdDcCBgEJAQEDCXyPFQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,376,1592870400"; d="scan'208";a="534789717" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Aug 2020 14:50:41 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07VEoeiA000836 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2020 14:50:41 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 09:50:40 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 09:50:40 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 31 Aug 2020 10:50:39 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eVzMoV6Bpim38xJ4l703MAGssm0/vlnedhf2YrCZMJHbcAQd2O8rzNbR6oPbBIMvNWn+Sry4SdI3p4GerRQL7nKJcnbRDnf+qkrU/zSrV6z3MfiaKPRyA7YxJUR0xKFE2IALncPueOSjKm0PgfKgLYxky+2zb7IcCh7qCMX+qh4G8+rlPpfUuMqgWtbkaPpgKRRV4NihIr4ZhW7al6yhhB5TOeK0UOCq+xTybfiqagzLR93UO1stpKVfERIKyNUFTyV0zUKnYj5pKz4RW1SARSDkHjNEMcA85VdMBygnzQ93L6V0rtaXM3cHzz1Z62BMmFiXh8dfzOArZESOelvUNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/IJVQkHk1Q1TJasronKFOsPm66T9yKmbvlQ5zsa7huc=; b=MwQao/WfmpFeUfcmDI5u14NRBe1C4e7Ye1m3wd2DFP+E9bz58B9WQitm2mqluMsx/kYwlp1DRA6QbCyMP3qCSuRgGnW4HZhOhxzgocUqOdYPcDnYlMBPMKawjjAP53hhGJapw52AuCUq9eSXk1xm8CGvzxqkgVP5uik9bVWSss/0oKgYfmRyNz7JGZk/B9znx7+NMuPHb3VVfiMfTjtPRXWy1XzGNBoI1ssaWjdyMt7loWc3zxuRepZ700yWCAdeeohoahsTimGgB5NghhgR9VNFNwQRF/OfFgZvieZIIW3DnnySOoD3fr8yt92UtK63wA5yDaeQxZ3lwRdTZVg6nA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/IJVQkHk1Q1TJasronKFOsPm66T9yKmbvlQ5zsa7huc=; b=Wh+8XqSfI+BmH/HuYru6JGc6g/l3CCSe6o5+WHwf8Fp51WNAn9dqeHspltppWoYoPUmslpHfv1j4JF2y6pRiaGRed6MLC91FO9OeLi1BbHWicJdRo7IZ7VcATMcs2GNIS6Kaad/2BD8KJ1Kckt26jwAF9EPwqRo4FcXjdtE4abg= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (2603:10b6:300:10c::11) by MWHPR11MB1614.namprd11.prod.outlook.com (2603:10b6:301:11::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.23; Mon, 31 Aug 2020 14:50:38 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::34c5:6550:a098:209f]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::34c5:6550:a098:209f%12]) with mapi id 15.20.3326.025; Mon, 31 Aug 2020 14:50:38 +0000 From: "Wouter van der Beek (wovander)" To: Carsten Bormann , "asdf@ietf.org" CC: One Data Model Group , "t2trg@irtf.org" Thread-Topic: [Asdf] Representation issues and protocol bindings Thread-Index: AQHWf6Ks9vEN6ZlkEUeOqyooH12kt6lSSQVw Date: Mon, 31 Aug 2020 14:50:38 +0000 Message-ID: References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> In-Reply-To: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 425b9a14-d112-419a-c5b5-08d84dbd399b x-ms-traffictypediagnostic: MWHPR11MB1614: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bJ3+iBufaRp02v5hmvcU56fQNfydMgEStMi2LorDlQKddZe44OuedOmlRiQMpvYzaTMdnxfjupQe6Q9jIfCE5wexo59mMqc7bICeEYAY0SU+WxutTZJwoX9OjkXAiHu51uQFWcpo7/br+0W6kKij9CEqQPE5ltI65EqpBVsS+m3hATub4CZM6ghles9L1Tnc1ONZs1RO1YBBt9C4+RL7kS1X4H9Kneuod+tdg5v0py6ETPhNhVCyeL+YaQlWncPaBfLOObIm38Bbtc8zxc2izrK9WNhJ0wqXbY6pWb1i/ZrxDkfKxvtzl9Lg2UjHHqFD8+5c+lMl7UnVx47oTkoKnfQNhMxiKrvIcWJR9VmiLqtxoYaf7rq90ZZ71ffokizgIMX0m7ASwvsTSGHptuCgyQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1838.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(366004)(346002)(376002)(136003)(4326008)(26005)(2906002)(55016002)(186003)(53546011)(9686003)(7696005)(8936002)(6506007)(33656002)(71200400001)(76116006)(66446008)(966005)(83380400001)(66476007)(54906003)(66556008)(110136005)(86362001)(64756008)(66946007)(8676002)(478600001)(5660300002)(52536014)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bYTqD75pyo9sPBlYLMu8VHYmstfg2U9JtRC9jB9LJs+fpyBnVG4QHe8IntoS1ND2Kxv3chQWVRJZASnpF/47anElerANIkE500KCFbJxDKqWVxzQBYE+Ey84llOIJNjyvnQLCYuz94MZKlPVedgObjQcEeRAsOv5Fiu9mf1GQ46Uul0Rx6ypzP6T3XlB8jftLFzSad7KLpywkZle/2TPfKs+owNYaI67AiQRo7ZDRb6ymdD3KGKp5jt59zt68G8dfKYVQdHWjzwO/fu02fheEJj6VRJ2htka9wmA2zumIKshU6ovr2liSiq3LpoxpxeI8VqJLX+sG859kkshyjMctIY0ekG8EG9FjT0sCTrbjVotdskgWeJ9sq7z4r9wecUzZcF3hNi5/2lvtZu5KzVnUIk2uh6HEtZqY55Ga/p4w5DwbufG0dliU+/OVy5Reo568JCymguxGotu5IlyKURIq+8MuzTknGtvRUiaC2zjf4feOU5vw/yIodqI//dL5g/k6PgL0kth8jpJx/svrMljp+C/+xPgtRqffs5FBdCIgXNE6nWZW8dmmCnY9JJV3oflNG+m7I8QLNCz9i6UpQX28xbCdoxHuB7sijMf4tG9JjgUXA7Kq1JL20jFNwODYy4N8bOcoVrS7b4p8hKVp5ZLBg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1838.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 425b9a14-d112-419a-c5b5-08d84dbd399b X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 14:50:38.1383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZPyEx/6DdcMpamiPInyF5gwOq3hu+6EmZdynNo/OaN4o6Q5jRcJ92FnCNFz2TirfrMECrjnMoqWY/Zs9Tq7Cyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1614 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Asdf] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 14:50:44 -0000 SGkgQ2Fyc3RlbiwNCg0KSSB0aGluayB1c2luZyBKU09OIGFzIGEgbm90YXRpb24gYWN0dWFsbHkg aGVscHMsDQpJdCBhdm9pZHMgdXNpbmcgdGhlIG1vcmUgcHJlY2lzZSB0aHVzIG1vcmUgcHJlc2Ny aXB0aXZlICBpbnQzMi82NC8uLi4gZGF0YSB0eXBlcy4NCmUuZy4ganVzdCBCb29sZWFuLCBudW1i ZXIgYW5kIGludGVnZXIgYXMgYmFzZS4NCg0KRW51bSB2YWx1ZXMgSSBob3BlIGV2ZXJ5b25lIHdp bGwgc3RhcnQgdXNpbmcgc3RyaW5nIHZhbHVlIGFzIGVudW0gdmFsdWUsIHdoZXJlIHRoZSBzdHJp bmcgY2FuIGhhdmUgYW4gYWN0dWFsIG1lYW5pbmcsIGUuZy4gDQpTdGF0ZSA9IFsic3RvcHBlZCwg InJ1bm5pbmciLCAiYnJva2VuIl0gaW5zdGVhZCBvZiBbMSwyLDNdIC4uLg0KDQpBcyBleGFtcGxl IEkgdGhpbmsgYnJpZ2h0bmVzcyBzaG91bGQgYmUgZXhwcmVzc2VkIGFzICUgaW4gbnVtYmVyIHNv IHRoYXQgb25lIGNhbiBjaG9vc2UgaXRzIHByZWNpc2lvbiBvbiB0aGUgd2lyZS4NCkFsbCBleGFt cGxlcyBvZiAwLTI1NCwgMC0xMDAsIDAuLjY1NTM1IEFyZSBvayB3aXRoIG1lIHdpdGggYSBzcGVj aWZpYyBtYXBwaW5nLg0KU28gaWYgb25lIGVuY291bnRlcnMgdGhlIGJyaWdodG5lc3Mgb24gc3lz dGVtIEEgb25lIHNob3VsZCBrbm93IHRoZSBhY3R1YWwgZGF0YSBvbiB0aGUgd2lyZSBzbyB0aGF0 IG9uZSBjYW4gbWFwIGl0IHRvIHRoZSBvbmVETSBtb2RlbCBpbiBTREYuIElmIG9uZSBuZWVkcyB0 byB1c2UgaXQgb24gc3lzdGVtIEIsIG9uZSBuZWVkcyB0byBrbm93IGhvdyB0byB3cml0ZSB0aGUg ZGF0YSBvbiB0aGUgd2lyZSBmb3IgU3lzdGVtIEIuDQoobm90ZSB0aGF0IHRoaXMgb25seSB3b3Jr cyB3aGVuIGV2ZXJ5dGhpbmcgY2FuIGJlIG1hcHBlZCBsaW5lYXIsIHNvIGV2ZW4gdGhpcyBzaW1w bGUgZXhhbXBsZSBpcyBub3QgdGhhdCBzaW1wbGUpLg0KDQpBbmQgaWYgdGhlcmUgaXMgYSBuZWVk IChlLmcuIG9yaWdpbiBmcm9tIGFuIGNvbnRyaWJ1dGluZyBvcmcpIHdlIGNhbiBhZGQgdGhlIG1v cmUgcHJlY2lzZSBpbnQzMiBhcyBzdWIgdHlwZS4NCkJ1dCBJIHRoaW5rIHdlIGFsbCBleHBlcmll bmNlZCB0aGF0IG92ZXIgdGltZSByZXNvbHV0aW9ucyBnbyB1cCwgZ29vZCBleGFtcGxlIG9mIHRo aXMgaXMgUkdCLCAgMC0yNTUtIDggYml0cywgdGhlbiAxNiBiaXRzLCAyNCBiaXRzIC4uLg0KDQpT byBJIHJhdGhlciB3b3VsZCBnbyBmb3IgdGhlIDgwJSBzb2x1dGlvbiwgd2hpY2ggaXMgYWxyZWFk eSA4MCUgbW9yZSB0aGFuIHdoYXQgaXMgdGhlcmUgdG9kYXkuDQoNCktpbmQgUmVnYXJkcywNCldv dXRlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQVNERiA8YXNkZi1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQpTZW50OiBNb25kYXks IEF1Z3VzdCAzMSwgMjAyMCAzOjI2IFBNDQpUbzogYXNkZkBpZXRmLm9yZw0KQ2M6IE9uZSBEYXRh IE1vZGVsIEdyb3VwIDxvbmVkbUBpb3RsaWFpc29uLm9yZz47IHQydHJnQGlydGYub3JnDQpTdWJq ZWN0OiBbQXNkZl0gUmVwcmVzZW50YXRpb24gaXNzdWVzIGFuZCBwcm90b2NvbCBiaW5kaW5ncw0K DQpJbiB0b2RheeKAmXMgT25lRE0gY2FsbCwgQnJ1Y2UgTm9yZG1hbiBicm91Z2h0IHVwIHRoZSBp c3N1ZSB0aGF0LCBpbiB0aGUgZW5kLCB3ZeKAmWxsIG5lZWQgY29uY3JldGUgcmVwcmVzZW50YXRp b25zIHRvIHRhbGsgdG8gZGV2aWNlcyBhbmQgdXNlIHRoZWlyIGRhdGEuDQoNClNvIGlmIHdlIGhh dmUgb25lIGVjb3N5c3RlbSB0aGF0IHVzZXMgMC4uMTAwIGZvciBkZXNjcmliaW5nIHRoZSBicmln aHRuZXNzIHNldHRpbmcgZm9yIGEgbGFtcCwgYW5vdGhlciBvbmUgdGhhdCB1c2VzIDAuLjI1NCAo d2hlcmUgMjU1IG1lYW5zIHNvbWV0aGluZyBjb21wbGV0ZSBkaWZmZXJlbnQpLCBhbmQgYSB0aGly ZCB3aXRoIDAuLjY1NTM1LCB3aGF0IGRvIHdlIGRvPyAgKEFuZCB0aGVzZSBtaWdodCBhbHNvIGRp ZmZlciB3aGV0aGVyIHRoZXkgZGVzY3JpYmUgYSBlbWl0dGVkIGxpZ2h0IHBvd2VyIGxldmVsIG9y IGEgcGVyY2VwdGl2ZSBsdW1pbm91cyBmbHV4IGxldmVsLikNCg0KVGhlIHVuZGVybHlpbmcgcHJv YmxlbSBpcyB0aGF0IHdlIGFyZSBhYnVzaW5nIGRhdGEgbW9kZWwgbGV2ZWwgZGVzY3JpcHRpb24g dGVjaG5pcXVlcyAoaW4gcGFydCBib3Jyb3dlZCBmcm9tIGpzb24tc2NoZW1hLm9yZykgdG8gZGVz Y3JpYmUgaW5mb3JtYXRpb24gbW9kZWxzLg0KVGhhdCB3b3JrcyByZWFzb25hYmx5IHdlbGwgdW50 aWwgd2Ugc3RhcnQgdGFraW5nIHRoZXNlIGRhdGEgbW9kZWwgbGV2ZWwgZGVzY3JpcHRpb25zIGF0 IGZhY2UgdmFsdWUuICBUaGUgZmFjdCB0aGF0IHNvbWUgY29udmVyZ2VkIG1vZGVsIHVzZXMgYSBz Y2FsZSBiYXNlZCBvbiB0aGUgTCBjb21wb25lbnQgb2YgTHXigJl24oCZIGRvZXMgbm90IG1lYW4g dGhhdCBldmVyeWJvZHkgaGFzIHRvIHJlcHJlc2VudCB0aGVpciBlY29zeXN0ZW0gbW9kZWwgdGhl IHNhbWUgd2F5Lg0KDQpUaGUgb2J2aW91cyBzZWNvbmQgcHJvYmxlbSBpcyB0aGF0IHdlIGhhdmVu 4oCZdCB0YWNrbGVkIGEgZnJhbWV3b3JrIGZvciBkZXNjcmliaW5nIHByb3RvY29sIGJpbmRpbmdz ICh3aGljaCwgaW5pdGlhbGx5LCB3aWxsIG1vc3RseSBiZSBlY29zeXN0ZW0gYmluZGluZ3MpLiAg VGhhdCB3b3VsZCBiZSB0aGUgcGxhY2Ugd2hlcmUgd2Ugc2F5IGhvdyB0aGUgTCBjb21wb25lbnQg bmVlZHMgdG8gbWFwcGVkIHRvIHRoZSBlY29zeXN0ZW0gc3BlY2lmaWMgY29uY3JldGUgcmVwcmVz ZW50YXRpb24uICBTaW5jZSB0aGF0IG1hcHBpbmcsIGluIHByaW5jaXBsZSwgY2FuIGhhdmUgYXJi aXRyYXJ5IGNvbXBsZXhpdHksIGNvbXBsZXRlbHkgY292ZXJpbmcgYWxsIGNhc2VzIHJlcXVpcmVz IFR1cmluZy1lcXVpdmFsZW50IGZ1bmN0aW9uYWxpdHkgaW4gYSBkZXNjcmlwdGlvbiBsYW5ndWFn ZS4gIE9yIHdlIGNvdWxkIGdvIGZvciBhbiA4MCAlIHNvbHV0aW9uIGFuZCB0aGVuLCBmb3IgdGhl IDIwICUsIHJlZ2lzdGVyIG1hcHBpbmcgY29tcG9uZW50cyB0aGF0IGFyZSBtb3JlIGNvbXBsZXgg aW4gYW4gSUFOQSByZWdpc3RyeS4NCg0KTGV04oCZcyBkaXNjdXNzIHRoaXMgYmFzZWQgb24gc29t ZSByZWFsLXdvcmxkIGV4YW1wbGVzIOKAlCBpdCBpcyBlYXN5IHRvIGNvbnN0cnVjdCBhcnRpZmlj aWFsIG9uZXMgdGhhdCBoYXZlIG1vcmUgY29tcGxleGl0eSB0aGFuIHdlIGFjdHVhbGx5IG5lZWQu DQoNCkNDaW5nIFQyVFJHIGFzIHdlbGwgYmVjYXVzZSBxdWl0ZSBhIGZldyBwZW9wbGUgdGhlcmUg YXJlIGZhbWlsaWFyIHdpdGggdGhlIHByb2JsZW07IG1heWJlIHdlIHdhbnQgdG8gaGF2ZSB0aGUg YnVsayBvZiB0aGUgZGlzY3Vzc2lvbiBvbiBhc2RmQGlldGYub3JnIHRob3VnaC4NCg0KR3LDvMOf ZSwgQ2Fyc3Rlbg0KDQotLSANCkFTREYgbWFpbGluZyBsaXN0DQpBU0RGQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FzZGYNCg== From nobody Mon Aug 31 07:58:56 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E112D3A1451 for ; Mon, 31 Aug 2020 07:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 K-bLssKwua-t for ; Mon, 31 Aug 2020 07:58:48 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 BCECE3A141A for ; Mon, 31 Aug 2020 07:58:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2E/BgBqD01f/xoHYZlZBh4BAQsSDEC?= =?us-ascii?q?GFwqDbkCRGSWcHAsBAQEBAQEBAQEGAQEtAgQBAYRMAoJMASQ4EwIQAQEGAQE?= =?us-ascii?q?BAQEGBAIChlGGTAEFDBcPAQVBEAkCDgoCAiYCAkcQBgEMAQUCAQEXgwuCfAW?= =?us-ascii?q?VEZt6gTKFU4NbgUKBDiqGVoZPD4FNP4ERJwwDgiwuPoQfDoMngmAEkCmCbqM?= =?us-ascii?q?pKgeBXYELgQsEC5kMBQoekX0GjlOSUZ9XAgQCCQIVgWuBe00kgzhQFwINnGh?= =?us-ascii?q?yNwIGAQkBAQMJfI8VAYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2E/BgBqD01f/xoHYZlZBh4BAQsSDECGFwqDbkCRGSWcH?= =?us-ascii?q?AsBAQEBAQEBAQEGAQEtAgQBAYRMAoJMASQ4EwIQAQEGAQEBAQEGBAIChlGGT?= =?us-ascii?q?AEFDBcPAQVBEAkCDgoCAiYCAkcQBgEMAQUCAQEXgwuCfAWVEZt6gTKFU4Nbg?= =?us-ascii?q?UKBDiqGVoZPD4FNP4ERJwwDgiwuPoQfDoMngmAEkCmCbqMpKgeBXYELgQsEC?= =?us-ascii?q?5kMBQoekX0GjlOSUZ9XAgQCCQIVgWuBe00kgzhQFwINnGhyNwIGAQkBAQMJf?= =?us-ascii?q?I8VAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,376,1592863200"; d="scan'208";a="23997615" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2020 16:58:43 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2BQA4D01f/1lIDI1ZBhwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFKgipzVDAsCoNuQJEZJZwcCwEDAQEBAQEGAQEtAgQBAYR?= =?us-ascii?q?MAoJKAiQ4EwIQAQEFAQEBAgEGBG2FaIVzAQUMFw8BBUEQCQIOCgICJgICRxA?= =?us-ascii?q?GAQwBBQIBAReDC4MBlRybeoEyhVODW4FCgQ4qhlaGTw+BTT+BEScMA4IsLj6?= =?us-ascii?q?EHw6DJ4JgBJApgm6jKSoHgV2BC4ELBAuZDAUKHpF9Bo5TklGfVwIEAgkCFYF?= =?us-ascii?q?rI4FXTSSDOFAXAg2caEExNwIGAQkBAQMJfI8VAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,376,1592863200"; d="scan'208";a="120681152" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2020 16:58:40 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 07VEweDW015261 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 31 Aug 2020 16:58:40 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 31 Aug 2020 16:58:35 +0200 To: Carsten Bormann , CC: One Data Model Group , References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> From: Henk Birkholz Message-ID: <8eefcef1-2d60-5349-792f-da228968807c@sit.fraunhofer.de> Date: Mon, 31 Aug 2020 16:58:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Asdf] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 14:58:51 -0000 Heya, in the scope of semantic interoperability it is not unusual to structure named types in taxonomies (a fancy word for basically categories of categories, etc). Maybe taxonomical tagging (associating with category) of various similar (e.g., "temperature"'esque) data model items renders the model close enough to an information model - and therefore remediates this... creative use? But maybe the complexity of types and units is too big for such a simplistic approach? Viele Grüße, Henk On 31.08.20 16:25, Carsten Bormann wrote: > In today’s OneDM call, Bruce Nordman brought up the issue that, in the end, we’ll need concrete representations to talk to devices and use their data. > > So if we have one ecosystem that uses 0..100 for describing the brightness setting for a lamp, another one that uses 0..254 (where 255 means something complete different), and a third with 0..65535, what do we do? (And these might also differ whether they describe a emitted light power level or a perceptive luminous flux level.) > > The underlying problem is that we are abusing data model level description techniques (in part borrowed from json-schema.org) to describe information models. > That works reasonably well until we start taking these data model level descriptions at face value. The fact that some converged model uses a scale based on the L component of Lu’v’ does not mean that everybody has to represent their ecosystem model the same way. > > The obvious second problem is that we haven’t tackled a framework for describing protocol bindings (which, initially, will mostly be ecosystem bindings). That would be the place where we say how the L component needs to mapped to the ecosystem specific concrete representation. Since that mapping, in principle, can have arbitrary complexity, completely covering all cases requires Turing-equivalent functionality in a description language. Or we could go for an 80 % solution and then, for the 20 %, register mapping components that are more complex in an IANA registry. > > Let’s discuss this based on some real-world examples — it is easy to construct artificial ones that have more complexity than we actually need. > > CCing T2TRG as well because quite a few people there are familiar with the problem; maybe we want to have the bulk of the discussion on asdf@ietf.org though. > > Grüße, Carsten > From nobody Mon Aug 31 08:22:41 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AEA3A1516 for ; Mon, 31 Aug 2020 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotsense.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 uaKB8KkCnKYs for ; Mon, 31 Aug 2020 08:22:38 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770123.outbound.protection.outlook.com [40.107.77.123]) (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 35A5B3A13E4 for ; Mon, 31 Aug 2020 08:22:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UWKbMbsEjT9BMCPG+0gcBQveScV2KEGWXufOOiJc4VPKF6pEXmIK11VPfe8MuTC7M5nwMzlnXnzdvq6BKV8jYqAcqAvWVNB6Lkid44vK47a2ljhA6OCNWMHCwoYd+HtKQNZQLu8duKIWzvHA7ZlgNB1Eg1wy+DiQDAZKTNUZpxf/LNwffjlx/54debo8JtioBp6oSZ9Jntqk/3PrPnyTkIitJuJhwYOWbl/t8oNa2DYchEvKP4VhqyBNCM3jpo4cEKUMFAlUcCRFRrDozfwL7PxbiOZZkfv3DmdojAr6Z3F/FKebOh94HYpYL+GJPEh5eM50k7S6b8AFIAc28qz6cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zoIIDiDXk+q76kWGXAaMZarSpNEWZTzFvoXKMz2yNoI=; b=RnjT2JZxMnrbRBRF5Jk/KywMmZTfCu1N4U7pWj8gjV68t6Zf4NFhatzwptfgeUO7+6sEh/lBIPNV2SS2mllIImHdnMouA5NqcG+GE2vhHNRKQf+KnYI4G6ITl/vtTydXWROXe6fkFvIzA04ozoMO2IwsWFv4dnToBQM1VR3o3J3ibIN5KizAq0IJbpy0VPbPypJ3AC4Vg25bDWFPW8Qs3rUr6RSYMufDZ2VkJYAqHTVeFfLPtI+o/aVZ8aThbftk2WJ3amO8hbbx9P41U7aIoxa1nQMVQ5K7thbvHOaIMApJ4IC8hWGC8Lh8Dg5NR1URkwPUvq6JfmCaRLAqVPWjNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotsense.com; dmarc=pass action=none header.from=iotsense.com; dkim=pass header.d=iotsense.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotsense.onmicrosoft.com; s=selector2-iotsense-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zoIIDiDXk+q76kWGXAaMZarSpNEWZTzFvoXKMz2yNoI=; b=btIomrUciEu2OY9Cm9r18wlr2RBo/K8ueBeCrOJksTkcjDs9Qbprjq4+lfP1cXsYi5ByURl6GPI2l1om8FqK5yuXQJXYb0cR7Xgy23REOlJXVnRM/eHTR4/UUCkminPL48Aqgtu4mLNjEjS4eqz2V2PHYaKMcAc4cmH6gyrCpSM= Received: from BYAPR18MB2536.namprd18.prod.outlook.com (2603:10b6:a03:136::32) by BYAPR18MB2903.namprd18.prod.outlook.com (2603:10b6:a03:10d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Mon, 31 Aug 2020 15:22:35 +0000 Received: from BYAPR18MB2536.namprd18.prod.outlook.com ([fe80::7592:6a3e:a40:589d]) by BYAPR18MB2536.namprd18.prod.outlook.com ([fe80::7592:6a3e:a40:589d%4]) with mapi id 15.20.3326.025; Mon, 31 Aug 2020 15:22:35 +0000 From: Milan Milenkovic To: "Wouter van der Beek (wovander)" , Carsten Bormann , "asdf@ietf.org" CC: One Data Model Group , "t2trg@irtf.org" Thread-Topic: [One Data Model Group] [Asdf] Representation issues and protocol bindings Thread-Index: AQHWf6YhJFJ1diSpEk6fXKfeXFPwy6lSUhPg Date: Mon, 31 Aug 2020 15:22:35 +0000 Message-ID: References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=iotsense.com; x-originating-ip: [70.32.6.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 872c0e5d-55de-4f13-9c0b-08d84dc1b075 x-ms-traffictypediagnostic: BYAPR18MB2903: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aqIqogYGpQJgob7uJQ0dk0Vw5gvyh7JC4QD0OKEOEuq9AbmWftn3x76QR0J1ilb3Dj+MuRx+0Jtb1xF7Ci3Lz+/KyRhTRI6hQMSRocef3sS7EsylbrPw/DaprylPfhx5/TJ0yI4MnAYZW2Uvl/j9ouTPolPNF/3dJRYAGbbHZi1Ee+isYaQk86wpTHKWgXtFj1f8rAc9l/gxGi9H5xMfFhHgjRcH50tvoA5H3PHcgJ7/klYauvpuLaAvq3LuTrM3eb+f77QkyK+lwbi2ZKYL+5GLRB14BiZzWzWfF3JfdJTm4DSfdJsjP1ST/qw5O074DS6zyIgSs45T1sb6+rvPewLJdk5F1xfpaUVjNzqcbgVZznzxKljnWZanJ3Tcjq7ZPOd4GOq5kvvuMv+81DzP5Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2536.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39830400003)(396003)(366004)(376002)(346002)(71200400001)(15974865002)(316002)(6506007)(53546011)(8936002)(52536014)(9686003)(966005)(86362001)(4326008)(7696005)(110136005)(55016002)(478600001)(2906002)(26005)(66446008)(8676002)(54906003)(5660300002)(186003)(66556008)(66476007)(76116006)(64756008)(66946007)(33656002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Uu654iPG4GA7iqqvYQpTHYCBJqI6ZG9ywwbuWQ6OJIsDJeNDuvLnY4VAii39gJ99WqefrJ7u94AnRSlQ75zrJgbMUq8+GeaLstuOJQzXAkexRF5AO62YhOLeX0KVNuUOh3SUgV2E0c6l7ZB0A3ZVUQQVaM8MdfTaN9KOn0spI8IMb+7IwAQVwJuXWKRy+eaXa0meVbJyygeJcfE8m601LUAw12QUIY9sSqgHlLctXFsHVdjVlT044r6PIn5wbh6rE74XsWHugRAxaNasQF817fcFaV+Ct6QWl6ikjBpNTlXTazx30pgezfFeMGTdRueSuk0JdaL9hoHkewGIYiH3BDQrzDw+ET6fIqCzyBGfPCrJdLQjDqsJ2SOCNg/EcEDVIjllUrIMJFuDHdGHWeK/jxkyiqScrRGdRNb157wNEeIskq9zfIhJDl57EoZplT/cYU/4HDTJh0mJJKWeqYlNJD43WZYgQeHB8sezjS5SO7Gc6HMVmr6ldRvk1ksYVcJJ/Q0o/MI4ytuSo9V6d8ElDLUhEfni6irHS8XwbLzdVm1eXY0aQjZkqv0uoPjjEnPBAhg/uybsDaWEaa2cTPKua35/gahwQX+dKBxBAU37ggrqCZhnegCHR8gWRDx2UUZgHSdX2Qw026tJy7vLhNDNcQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotsense.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2536.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 872c0e5d-55de-4f13-9c0b-08d84dc1b075 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 15:22:35.6250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b545f0f5-d78c-40e8-8d33-8972480ced5e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RkV71gFV8TeW7NDjlzuEwqY9OKeSxTctZ3tRgdgkqp06VptBhmARqA6ssOzTPHSgUmGDh4SQ8rDoZyyZ8UOchg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2903 Archived-At: Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 15:22:40 -0000 SGkgS2Fyc3RlbiwgV291dGVyIGV0IGFsLg0KDQpGb3IgeW91ciBleGFtcGxlLCBJIHdhcyBnb2lu ZyB0byBzdWdnZXN0IHRoZSByYW5nZSBmcmFjdGlvbiBvciAlIHNvbHV0aW9uIGJ1dCBXb3V0ZXIg YmVhdCBtZSB0byBpdC4NCg0KTW9yZSBpbXBvcnRhbnRseSwgSSB0aGluayB3ZSBzaG91bGQgYmUg cHJhZ21hdGljIGFuZCBhaW0gZm9yIHRoZSA4MCUgc29sdXRpb24gKHdoaWNoLCBhY2NvcmRpbmcg dG8gdGhlIFBhcmV0byBwcmluY2lwbGUsIG1heSByZXF1aXJlIGRlZmluaXRpb24gb2Ygb25seSAy MCUgb2YgdXNlIGNhc2VzIDstKS4gIElNTywgbHVtaW5vc2l0eSBhZCBicmlnaHRuZXNzIGFyZSBl eGFtcGxlcyBvZiBhIHJlbGF0aXZlbHkgc2tld2VkIG1pbm9yIHVzZSBjYXNlIGluIGEgc3BlY2lm aWMgZG9tYWluIHRoYXQgaXMgY29uc3VtaW5nIGRpc3Byb3BvcnRpb25hdGUgYW1vdW50cyBvZiB0 aW1lIGFuZCBlZmZvcnQgdG8gYWRkcmVzcyBhbmQgdGhhdCBjb21wbGljYXRlcyBtYW55IGEgc29s dXRpb24gZm9yIHdoYXQgaXMgYXQgYmVzdCBhIHNtYWxsIGJlbmVmaXQuICBTdWNoIHRoaW5ncyBj YW4gYmUgdGFibGVkLCBhbmQgcG9zc2libHkgcmV2aXNpdGVkIGxhdGVyLCB0byBhbGxvdyBwcm9n cmVzcyBvbiBzb2x1dGlvbnMgZm9yIHRoZSBtb3N0IGNvbW1vbiB1c2UgY2FzZXMuDQoNClJlZ2Fy ZHMsDQpNaWxhbiBNaWxlbmtvdmljLCBQcmluY2lwYWwNCklvVHNlbnNlIExMQywgd3d3LmlvdHNl bnNlLmNvbSwgKzEgNjUwIDQzMS04MjgwDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBPbmUgRGF0YSBNb2RlbCBHcm91cCA8b25lZG1AaW90bGlhaXNvbi5vcmc+IE9uIEJlaGFs ZiBPZiBXb3V0ZXIgdmFuIGRlciBCZWVrICh3b3ZhbmRlcikNClNlbnQ6IE1vbmRheSwgQXVndXN0 IDMxLCAyMDIwIDc6NTEgQU0NClRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz47IGFz ZGZAaWV0Zi5vcmcNCkNjOiBPbmUgRGF0YSBNb2RlbCBHcm91cCA8b25lZG1AaW90bGlhaXNvbi5v cmc+OyB0MnRyZ0BpcnRmLm9yZw0KU3ViamVjdDogUkU6IFtPbmUgRGF0YSBNb2RlbCBHcm91cF0g W0FzZGZdIFJlcHJlc2VudGF0aW9uIGlzc3VlcyBhbmQgcHJvdG9jb2wgYmluZGluZ3MNCg0KSGkg Q2Fyc3RlbiwNCg0KSSB0aGluayB1c2luZyBKU09OIGFzIGEgbm90YXRpb24gYWN0dWFsbHkgaGVs cHMsIEl0IGF2b2lkcyB1c2luZyB0aGUgbW9yZSBwcmVjaXNlIHRodXMgbW9yZSBwcmVzY3JpcHRp dmUgIGludDMyLzY0Ly4uLiBkYXRhIHR5cGVzLg0KZS5nLiBqdXN0IEJvb2xlYW4sIG51bWJlciBh bmQgaW50ZWdlciBhcyBiYXNlLg0KDQpFbnVtIHZhbHVlcyBJIGhvcGUgZXZlcnlvbmUgd2lsbCBz dGFydCB1c2luZyBzdHJpbmcgdmFsdWUgYXMgZW51bSB2YWx1ZSwgd2hlcmUgdGhlIHN0cmluZyBj YW4gaGF2ZSBhbiBhY3R1YWwgbWVhbmluZywgZS5nLiANClN0YXRlID0gWyJzdG9wcGVkLCAicnVu bmluZyIsICJicm9rZW4iXSBpbnN0ZWFkIG9mIFsxLDIsM10gLi4uDQoNCkFzIGV4YW1wbGUgSSB0 aGluayBicmlnaHRuZXNzIHNob3VsZCBiZSBleHByZXNzZWQgYXMgJSBpbiBudW1iZXIgc28gdGhh dCBvbmUgY2FuIGNob29zZSBpdHMgcHJlY2lzaW9uIG9uIHRoZSB3aXJlLg0KQWxsIGV4YW1wbGVz IG9mIDAtMjU0LCAwLTEwMCwgMC4uNjU1MzUgQXJlIG9rIHdpdGggbWUgd2l0aCBhIHNwZWNpZmlj IG1hcHBpbmcuDQpTbyBpZiBvbmUgZW5jb3VudGVycyB0aGUgYnJpZ2h0bmVzcyBvbiBzeXN0ZW0g QSBvbmUgc2hvdWxkIGtub3cgdGhlIGFjdHVhbCBkYXRhIG9uIHRoZSB3aXJlIHNvIHRoYXQgb25l IGNhbiBtYXAgaXQgdG8gdGhlIG9uZURNIG1vZGVsIGluIFNERi4gSWYgb25lIG5lZWRzIHRvIHVz ZSBpdCBvbiBzeXN0ZW0gQiwgb25lIG5lZWRzIHRvIGtub3cgaG93IHRvIHdyaXRlIHRoZSBkYXRh IG9uIHRoZSB3aXJlIGZvciBTeXN0ZW0gQi4NCihub3RlIHRoYXQgdGhpcyBvbmx5IHdvcmtzIHdo ZW4gZXZlcnl0aGluZyBjYW4gYmUgbWFwcGVkIGxpbmVhciwgc28gZXZlbiB0aGlzIHNpbXBsZSBl eGFtcGxlIGlzIG5vdCB0aGF0IHNpbXBsZSkuDQoNCkFuZCBpZiB0aGVyZSBpcyBhIG5lZWQgKGUu Zy4gb3JpZ2luIGZyb20gYW4gY29udHJpYnV0aW5nIG9yZykgd2UgY2FuIGFkZCB0aGUgbW9yZSBw cmVjaXNlIGludDMyIGFzIHN1YiB0eXBlLg0KQnV0IEkgdGhpbmsgd2UgYWxsIGV4cGVyaWVuY2Vk IHRoYXQgb3ZlciB0aW1lIHJlc29sdXRpb25zIGdvIHVwLCBnb29kIGV4YW1wbGUgb2YgdGhpcyBp cyBSR0IsICAwLTI1NS0gOCBiaXRzLCB0aGVuIDE2IGJpdHMsIDI0IGJpdHMgLi4uDQoNClNvIEkg cmF0aGVyIHdvdWxkIGdvIGZvciB0aGUgODAlIHNvbHV0aW9uLCB3aGljaCBpcyBhbHJlYWR5IDgw JSBtb3JlIHRoYW4gd2hhdCBpcyB0aGVyZSB0b2RheS4NCg0KS2luZCBSZWdhcmRzLA0KV291dGVy DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBU0RGIDxhc2RmLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NClNlbnQ6IE1vbmRheSwgQXVn dXN0IDMxLCAyMDIwIDM6MjYgUE0NClRvOiBhc2RmQGlldGYub3JnDQpDYzogT25lIERhdGEgTW9k ZWwgR3JvdXAgPG9uZWRtQGlvdGxpYWlzb24ub3JnPjsgdDJ0cmdAaXJ0Zi5vcmcNClN1YmplY3Q6 IFtBc2RmXSBSZXByZXNlbnRhdGlvbiBpc3N1ZXMgYW5kIHByb3RvY29sIGJpbmRpbmdzDQoNCklu IHRvZGF54oCZcyBPbmVETSBjYWxsLCBCcnVjZSBOb3JkbWFuIGJyb3VnaHQgdXAgdGhlIGlzc3Vl IHRoYXQsIGluIHRoZSBlbmQsIHdl4oCZbGwgbmVlZCBjb25jcmV0ZSByZXByZXNlbnRhdGlvbnMg dG8gdGFsayB0byBkZXZpY2VzIGFuZCB1c2UgdGhlaXIgZGF0YS4NCg0KU28gaWYgd2UgaGF2ZSBv bmUgZWNvc3lzdGVtIHRoYXQgdXNlcyAwLi4xMDAgZm9yIGRlc2NyaWJpbmcgdGhlIGJyaWdodG5l c3Mgc2V0dGluZyBmb3IgYSBsYW1wLCBhbm90aGVyIG9uZSB0aGF0IHVzZXMgMC4uMjU0ICh3aGVy ZSAyNTUgbWVhbnMgc29tZXRoaW5nIGNvbXBsZXRlIGRpZmZlcmVudCksIGFuZCBhIHRoaXJkIHdp dGggMC4uNjU1MzUsIHdoYXQgZG8gd2UgZG8/ICAoQW5kIHRoZXNlIG1pZ2h0IGFsc28gZGlmZmVy IHdoZXRoZXIgdGhleSBkZXNjcmliZSBhIGVtaXR0ZWQgbGlnaHQgcG93ZXIgbGV2ZWwgb3IgYSBw ZXJjZXB0aXZlIGx1bWlub3VzIGZsdXggbGV2ZWwuKQ0KDQpUaGUgdW5kZXJseWluZyBwcm9ibGVt IGlzIHRoYXQgd2UgYXJlIGFidXNpbmcgZGF0YSBtb2RlbCBsZXZlbCBkZXNjcmlwdGlvbiB0ZWNo bmlxdWVzIChpbiBwYXJ0IGJvcnJvd2VkIGZyb20ganNvbi1zY2hlbWEub3JnKSB0byBkZXNjcmli ZSBpbmZvcm1hdGlvbiBtb2RlbHMuDQpUaGF0IHdvcmtzIHJlYXNvbmFibHkgd2VsbCB1bnRpbCB3 ZSBzdGFydCB0YWtpbmcgdGhlc2UgZGF0YSBtb2RlbCBsZXZlbCBkZXNjcmlwdGlvbnMgYXQgZmFj ZSB2YWx1ZS4gIFRoZSBmYWN0IHRoYXQgc29tZSBjb252ZXJnZWQgbW9kZWwgdXNlcyBhIHNjYWxl IGJhc2VkIG9uIHRoZSBMIGNvbXBvbmVudCBvZiBMdeKAmXbigJkgZG9lcyBub3QgbWVhbiB0aGF0 IGV2ZXJ5Ym9keSBoYXMgdG8gcmVwcmVzZW50IHRoZWlyIGVjb3N5c3RlbSBtb2RlbCB0aGUgc2Ft ZSB3YXkuDQoNClRoZSBvYnZpb3VzIHNlY29uZCBwcm9ibGVtIGlzIHRoYXQgd2UgaGF2ZW7igJl0 IHRhY2tsZWQgYSBmcmFtZXdvcmsgZm9yIGRlc2NyaWJpbmcgcHJvdG9jb2wgYmluZGluZ3MgKHdo aWNoLCBpbml0aWFsbHksIHdpbGwgbW9zdGx5IGJlIGVjb3N5c3RlbSBiaW5kaW5ncykuICBUaGF0 IHdvdWxkIGJlIHRoZSBwbGFjZSB3aGVyZSB3ZSBzYXkgaG93IHRoZSBMIGNvbXBvbmVudCBuZWVk cyB0byBtYXBwZWQgdG8gdGhlIGVjb3N5c3RlbSBzcGVjaWZpYyBjb25jcmV0ZSByZXByZXNlbnRh dGlvbi4gIFNpbmNlIHRoYXQgbWFwcGluZywgaW4gcHJpbmNpcGxlLCBjYW4gaGF2ZSBhcmJpdHJh cnkgY29tcGxleGl0eSwgY29tcGxldGVseSBjb3ZlcmluZyBhbGwgY2FzZXMgcmVxdWlyZXMgVHVy aW5nLWVxdWl2YWxlbnQgZnVuY3Rpb25hbGl0eSBpbiBhIGRlc2NyaXB0aW9uIGxhbmd1YWdlLiAg T3Igd2UgY291bGQgZ28gZm9yIGFuIDgwICUgc29sdXRpb24gYW5kIHRoZW4sIGZvciB0aGUgMjAg JSwgcmVnaXN0ZXIgbWFwcGluZyBjb21wb25lbnRzIHRoYXQgYXJlIG1vcmUgY29tcGxleCBpbiBh biBJQU5BIHJlZ2lzdHJ5Lg0KDQpMZXTigJlzIGRpc2N1c3MgdGhpcyBiYXNlZCBvbiBzb21lIHJl YWwtd29ybGQgZXhhbXBsZXMg4oCUIGl0IGlzIGVhc3kgdG8gY29uc3RydWN0IGFydGlmaWNpYWwg b25lcyB0aGF0IGhhdmUgbW9yZSBjb21wbGV4aXR5IHRoYW4gd2UgYWN0dWFsbHkgbmVlZC4NCg0K Q0NpbmcgVDJUUkcgYXMgd2VsbCBiZWNhdXNlIHF1aXRlIGEgZmV3IHBlb3BsZSB0aGVyZSBhcmUg ZmFtaWxpYXIgd2l0aCB0aGUgcHJvYmxlbTsgbWF5YmUgd2Ugd2FudCB0byBoYXZlIHRoZSBidWxr IG9mIHRoZSBkaXNjdXNzaW9uIG9uIGFzZGZAaWV0Zi5vcmcgdGhvdWdoLg0KDQpHcsO8w59lLCBD YXJzdGVuDQoNCi0tDQpBU0RGIG1haWxpbmcgbGlzdA0KQVNERkBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hc2RmDQo= From nobody Mon Aug 31 09:00:03 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE463A07E0 for ; Mon, 31 Aug 2020 08:59:56 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 ellDkBKz3wHc for ; Mon, 31 Aug 2020 08:59:53 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 8E2A23A1705 for ; Mon, 31 Aug 2020 08:59:53 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u126so6443476iod.12 for ; Mon, 31 Aug 2020 08:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R9VzFZujhKjsje2t4O41akGXSgt8a5w5IOlfizm+MfU=; b=y2EA76AQSkxcBgqfGmD9GlM0K83bWD7XubjvOxWxxD2WDbi9P/VCRQbjGedOyqwRY1 bYnhwktQdviex4vG73LgKhrB6bTmC+YY75CUsk11QXDbXJCyUPfx2m5LSi7Dyq6DvMqZ MztZ+ihRXQzX1nEvXceIfhL7Qgw2SGVBglWI/EIwlN4GdiBA5p/utquLRZ/cZowCxbAN QMa5MbsHeVQC8/r99Vk4lr1KZk4CONQ9YMSLyMGFp8vLCQASBMViTh3gZ1BdIYCgHKaU 69b8sj0nLRx3N3u2T1JuDLj9KbfTg8TbOkHxCPUQtI+MK3sFfVLBGVLGEWx87TnfYTKF zLMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R9VzFZujhKjsje2t4O41akGXSgt8a5w5IOlfizm+MfU=; b=C/NRJ16cWwL4jHIP+Kxr3ZHF5pDzvZvn45IGoaOvtVxsuTGp2LTvoThPx/zZNKPpzb ceIffBuZI73F9ho6vzX8W3fMGNAYz+jgOW+WL3NZu2npSwJls700h4pmuoJqJuUHyvnn SneOMqb0wDr0ps2GtSkDwaeXFHqh7Zm+sChQJMyl4RhgGb+4uTAN8Z7i1lISNnccFGVo hRspCLao3P8qjhNb+lMELdBf0W8ziZT+VIcUGoagThYnDmNcAMBMYVKOnlIaV3Cn146J HIQgy227QjcXayFTb0L8fFVTeq3/iEp5I+1QrvJdgwdNxIi8FPUUS3ZmemWeTp93O0o6 WW2Q== X-Gm-Message-State: AOAM530j87AZOCbTGqHmhNUUCF4SYYSQ9Sws8qIHdfrNhUzAZr6bHFVe La3smFrw81d2LIDhUi6hwSpOrEJxgVjkSHPL5JhKalWqxLlted0Q X-Google-Smtp-Source: ABdhPJxQ04qDheiUK2r+g2vbbXK8MwrAzxdEtq1+fbgPRgMKWCPczHlNpgrmMGJZksfv2q5oY3B5BFpumjhi/1CQY/8= X-Received: by 2002:a05:6602:2dd2:: with SMTP id l18mr1798934iow.81.1598889592226; Mon, 31 Aug 2020 08:59:52 -0700 (PDT) MIME-Version: 1.0 References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> In-Reply-To: From: Alexander Pelov Date: Mon, 31 Aug 2020 17:58:47 +0200 Message-ID: To: Milan Milenkovic Cc: "Wouter van der Beek (wovander)" , Carsten Bormann , "asdf@ietf.org" , One Data Model Group , "t2trg@irtf.org" Content-Type: multipart/alternative; boundary="0000000000002e173205ae2e7edd" Archived-At: Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 15:59:56 -0000 --0000000000002e173205ae2e7edd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, all, These are indeed some interesting questions, and I am not sure to what extent they can be solved in a generic way. In our work on adding parsing capabilities to YANG files (see https://tools.ietf.org/html/draft-petrov-t2trg-youpi-01 ) we've done some of the things you mentioned. For example, in YANG you have the built-in capability to describe the range of a value, e.g. if it goes from 0-100, or from 1-255. That of course would solve the first part of your question. I think that solving the full problem may be a little bit more delicate. For example, someone just might choose 0-1000, where 0 is max brightness, which then goes to min brightness at around 950 and then again to maximum brightness at 1000. Why would anyone do something like this? I think the question would be mostly - if someone does it, how to handle it graciously. There may be something like a mapping, two-way function, that first transforms the crazy thing into a linear graduation, which can then be handled in a more "understandable" way. So probably, a combination of the two: 1) having the hypothesis that a variable is "linear", with known MIN/MAX 2) annotating the MIN/MAX values (e.g. 0=3Doff, 255=3Dbright) 2.1) optionally annotation intermediate values (e.g. 10=3Dvery dim) 3) having an (optional) transformation function to/from the linear function used by ASDF (in case the variable is not linear) Cheers, Alexander On Mon, Aug 31, 2020 at 5:22 PM Milan Milenkovic wrote= : > Hi Karsten, Wouter et al. > > For your example, I was going to suggest the range fraction or % solution > but Wouter beat me to it. > > More importantly, I think we should be pragmatic and aim for the 80% > solution (which, according to the Pareto principle, may require definitio= n > of only 20% of use cases ;-). IMO, luminosity ad brightness are examples > of a relatively skewed minor use case in a specific domain that is > consuming disproportionate amounts of time and effort to address and that > complicates many a solution for what is at best a small benefit. Such > things can be tabled, and possibly revisited later, to allow progress on > solutions for the most common use cases. > > Regards, > Milan Milenkovic, Principal > IoTsense LLC, www.iotsense.com, +1 650 431-8280 > > -----Original Message----- > From: One Data Model Group On Behalf Of Wouter van > der Beek (wovander) > Sent: Monday, August 31, 2020 7:51 AM > To: Carsten Bormann ; asdf@ietf.org > Cc: One Data Model Group ; t2trg@irtf.org > Subject: RE: [One Data Model Group] [Asdf] Representation issues and > protocol bindings > > Hi Carsten, > > I think using JSON as a notation actually helps, It avoids using the more > precise thus more prescriptive int32/64/... data types. > e.g. just Boolean, number and integer as base. > > Enum values I hope everyone will start using string value as enum value, > where the string can have an actual meaning, e.g. > State =3D ["stopped, "running", "broken"] instead of [1,2,3] ... > > As example I think brightness should be expressed as % in number so that > one can choose its precision on the wire. > All examples of 0-254, 0-100, 0..65535 Are ok with me with a specific > mapping. > So if one encounters the brightness on system A one should know the actua= l > data on the wire so that one can map it to the oneDM model in SDF. If one > needs to use it on system B, one needs to know how to write the data on t= he > wire for System B. > (note that this only works when everything can be mapped linear, so even > this simple example is not that simple). > > And if there is a need (e.g. origin from an contributing org) we can add > the more precise int32 as sub type. > But I think we all experienced that over time resolutions go up, good > example of this is RGB, 0-255- 8 bits, then 16 bits, 24 bits ... > > So I rather would go for the 80% solution, which is already 80% more than > what is there today. > > Kind Regards, > Wouter > > -----Original Message----- > From: ASDF On Behalf Of Carsten Bormann > Sent: Monday, August 31, 2020 3:26 PM > To: asdf@ietf.org > Cc: One Data Model Group ; t2trg@irtf.org > Subject: [Asdf] Representation issues and protocol bindings > > In today=E2=80=99s OneDM call, Bruce Nordman brought up the issue that, i= n the > end, we=E2=80=99ll need concrete representations to talk to devices and u= se their > data. > > So if we have one ecosystem that uses 0..100 for describing the brightnes= s > setting for a lamp, another one that uses 0..254 (where 255 means somethi= ng > complete different), and a third with 0..65535, what do we do? (And thes= e > might also differ whether they describe a emitted light power level or a > perceptive luminous flux level.) > > The underlying problem is that we are abusing data model level descriptio= n > techniques (in part borrowed from json-schema.org) to describe > information models. > That works reasonably well until we start taking these data model level > descriptions at face value. The fact that some converged model uses a > scale based on the L component of Lu=E2=80=99v=E2=80=99 does not mean tha= t everybody has to > represent their ecosystem model the same way. > > The obvious second problem is that we haven=E2=80=99t tackled a framework= for > describing protocol bindings (which, initially, will mostly be ecosystem > bindings). That would be the place where we say how the L component need= s > to mapped to the ecosystem specific concrete representation. Since that > mapping, in principle, can have arbitrary complexity, completely covering > all cases requires Turing-equivalent functionality in a description > language. Or we could go for an 80 % solution and then, for the 20 %, > register mapping components that are more complex in an IANA registry. > > Let=E2=80=99s discuss this based on some real-world examples =E2=80=94 it= is easy to > construct artificial ones that have more complexity than we actually need= . > > CCing T2TRG as well because quite a few people there are familiar with th= e > problem; maybe we want to have the bulk of the discussion on asdf@ietf.or= g > though. > > Gr=C3=BC=C3=9Fe, Carsten > > -- > ASDF mailing list > ASDF@ietf.org > https://www.ietf.org/mailman/listinfo/asdf > -- > ASDF mailing list > ASDF@ietf.org > https://www.ietf.org/mailman/listinfo/asdf > --0000000000002e173205ae2e7edd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carsten, all,

These are indeed some = interesting questions, and I am not sure to what=C2=A0extent they can be so= lved in a generic way.

In our work on adding parsi= ng capabilities to YANG files (see=C2=A0https://tools.ietf.org/html/draft-petrov-t= 2trg-youpi-01 ) we've done some of the things you mentioned. For=C2= =A0example, in YANG you have the built-in capability to describe=C2=A0the r= ange of a value, e.g. if it goes from 0-100, or from 1-255. That of course = would solve the first part of your question.

I thi= nk that solving the full problem may be a little bit more delicate. For exa= mple, someone just might=C2=A0choose=C2=A00-1000, where 0 is max brightness= , which then goes to min brightness at around 950 and then again to maximum= brightness at 1000. Why would anyone do something like this? I think the q= uestion would be mostly - if someone does it, how to handle it graciously. = There may be something like a mapping, two-way function, that first transfo= rms the crazy thing into a linear graduation, which can then be handled in = a more "understandable" way.

So probably= , a combination of the two:
1) having the hypothesis that a varia= ble is "linear", with known MIN/MAX
2) annotating the M= IN/MAX values (e.g. 0=3Doff, 255=3Dbright)
2.1) optionally=C2=A0a= nnotation intermediate values (e.g. 10=3Dvery dim)
3) having an (= optional) transformation function to/from the linear function used by ASDF = (in case the variable is not linear)

Cheers,
=
Alexander


On Mon, Aug 31, 2020 at 5:22 PM Milan Mi= lenkovic <milan@iotsense.com&g= t; wrote:
Hi Kar= sten, Wouter et al.

For your example, I was going to suggest the range fraction or % solution b= ut Wouter beat me to it.

More importantly, I think we should be pragmatic and aim for the 80% soluti= on (which, according to the Pareto principle, may require definition of onl= y 20% of use cases ;-).=C2=A0 IMO, luminosity ad brightness are examples of= a relatively skewed minor use case in a specific domain that is consuming = disproportionate amounts of time and effort to address and that complicates= many a solution for what is at best a small benefit.=C2=A0 Such things can= be tabled, and possibly revisited later, to allow progress on solutions fo= r the most common use cases.

Regards,
Milan Milenkovic, Principal
IoTsense LLC, www.iotsense.com, +1 650 431-8280

-----Original Message-----
From: One Data Model Group <onedm@iotliaison.org> On Behalf Of Wouter van der Beek= (wovander)
Sent: Monday, August 31, 2020 7:51 AM
To: Carsten Bormann <c= abo@tzi.org>; asd= f@ietf.org
Cc: One Data Model Group <onedm@iotliaison.org>; t2trg@irtf.org
Subject: RE: [One Data Model Group] [Asdf] Representation issues and protoc= ol bindings

Hi Carsten,

I think using JSON as a notation actually helps, It avoids using the more p= recise thus more prescriptive=C2=A0 int32/64/... data types.
e.g. just Boolean, number and integer as base.

Enum values I hope everyone will start using string value as enum value, wh= ere the string can have an actual meaning, e.g.
State =3D ["stopped, "running", "broken"] instead = of [1,2,3] ...

As example I think brightness should be expressed as % in number so that on= e can choose its precision on the wire.
All examples of 0-254, 0-100, 0..65535 Are ok with me with a specific mappi= ng.
So if one encounters the brightness on system A one should know the actual = data on the wire so that one can map it to the oneDM model in SDF. If one n= eeds to use it on system B, one needs to know how to write the data on the = wire for System B.
(note that this only works when everything can be mapped linear, so even th= is simple example is not that simple).

And if there is a need (e.g. origin from an contributing org) we can add th= e more precise int32 as sub type.
But I think we all experienced that over time resolutions go up, good examp= le of this is RGB,=C2=A0 0-255- 8 bits, then 16 bits, 24 bits ...

So I rather would go for the 80% solution, which is already 80% more than w= hat is there today.

Kind Regards,
Wouter

-----Original Message-----
From: ASDF <a= sdf-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Monday, August 31, 2020 3:26 PM
To: asdf@ietf.org Cc: One Data Model Group <onedm@iotliaison.org>; t2trg@irtf.org
Subject: [Asdf] Representation issues and protocol bindings

In today=E2=80=99s OneDM call, Bruce Nordman brought up the issue that, in = the end, we=E2=80=99ll need concrete representations to talk to devices and= use their data.

So if we have one ecosystem that uses 0..100 for describing the brightness = setting for a lamp, another one that uses 0..254 (where 255 means something= complete different), and a third with 0..65535, what do we do?=C2=A0 (And = these might also differ whether they describe a emitted light power level o= r a perceptive luminous flux level.)

The underlying problem is that we are abusing data model level description = techniques (in part borrowed from json-schema.org) to describe information= models.
That works reasonably well until we start taking these data model level des= criptions at face value.=C2=A0 The fact that some converged model uses a sc= ale based on the L component of Lu=E2=80=99v=E2=80=99 does not mean that ev= erybody has to represent their ecosystem model the same way.

The obvious second problem is that we haven=E2=80=99t tackled a framework f= or describing protocol bindings (which, initially, will mostly be ecosystem= bindings).=C2=A0 That would be the place where we say how the L component = needs to mapped to the ecosystem specific concrete representation.=C2=A0 Si= nce that mapping, in principle, can have arbitrary complexity, completely c= overing all cases requires Turing-equivalent functionality in a description= language.=C2=A0 Or we could go for an 80 % solution and then, for the 20 %= , register mapping components that are more complex in an IANA registry.
Let=E2=80=99s discuss this based on some real-world examples =E2=80=94 it i= s easy to construct artificial ones that have more complexity than we actua= lly need.

CCing T2TRG as well because quite a few people there are familiar with the = problem; maybe we want to have the bulk of the discussion on asdf@ietf.org though.

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

--
ASDF mailing list
ASDF@ietf.org
https://www.ietf.org/mailman/listinfo/asdf
--
ASDF mailing list
ASDF@ietf.org
https://www.ietf.org/mailman/listinfo/asdf
--0000000000002e173205ae2e7edd-- From nobody Mon Aug 31 09:31:20 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C613A0B8C for ; Mon, 31 Aug 2020 09:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 SqR0GRy7rpja for ; Mon, 31 Aug 2020 09:31:13 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB52D3A0B8F for ; Mon, 31 Aug 2020 09:31:13 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id 185so1451293oie.11 for ; Mon, 31 Aug 2020 09:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8wguxWJBOaJoc9Lce25fGH8dHQ+DwDxfZQWkpUk3/9w=; b=Vh27y1Orf8ksPXEzcjqjIgZaljZ1z+u3HjqvPCvRdx34TrfFzbo/BAIpc9Kxlb6EZK DxpaLS5wB9n7rS8JLY3KpjZWlLOQ5RuF3/ltwQML+uDDrMQe4x3zQZwKXYqo4pW7qJhq 67PDU0cbETVkMowTQT5FEex4t5Uwl5+nzH0MaWpBLUgVg6JZd5YNlFHup0a7Tgf4j9WX RxXPg/h5YmC0xVxvteJrWs6nm+Xrh8UVLYRh8JbWfAQsTHHheRiw++MQHyEcZRyKFGbt FglJZthSSpU+Ef+khgkmFZKSQBaXfsGbIJ0pTB81UNnOtnQjnyVh320aCBsYoA7MmBBl wLKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8wguxWJBOaJoc9Lce25fGH8dHQ+DwDxfZQWkpUk3/9w=; b=RM9uS/Yar3eYXcdznFsaLVcasS+YADp+kMvAHRGGGMPEzYomBqOAgnW6i8DlTu2vW4 VnwdarQHnAoOB/35bAfCJSNvmjv/hvdx4izkg+1JsfHxYn0INvp9v5pm9wGX88urMyyR FmqWRwmCBO5OENnrIMqOO8wf8FEumHX8LhmKi8q/Ip16re8IHhxKZ/QdsiGqOIZK/+GD UgSWpA/8UDmj6o7MKCZMp38G6N92EQD6qvnl0hBEtL1Z0DVs+MbP26nj40LCTiIKAZ4s D1oooV32InIm3uffjbzID7MAX8of5wBA7iWEmZ9U+upGReLC+aRTz64G0cAsvTekFU2X 7yhg== X-Gm-Message-State: AOAM532CObCaiJ+h7U2pi8Owq2q1QsiR9O93gKPGLSVjWpaouCA8JN1Y vSN3Fuxb+MPro8JnhuND/+fV2Yh4esvQqOii+796Gfwn1Mk= X-Google-Smtp-Source: ABdhPJxG1HRiUIK5PDhr3SrKAdTf+VyPT+sBnb+ujZjfXGE/9kKuVa6EsG7WBHQomoFEDUz/VyIAFNWmjPWPYP8wV6g= X-Received: by 2002:aca:52d6:: with SMTP id g205mr140900oib.54.1598891472878; Mon, 31 Aug 2020 09:31:12 -0700 (PDT) MIME-Version: 1.0 References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> In-Reply-To: From: David Kemp Date: Mon, 31 Aug 2020 12:31:01 -0400 Message-ID: To: "asdf@ietf.org" , One Data Model Group , "t2trg@irtf.org" Content-Type: multipart/alternative; boundary="0000000000004682a305ae2eee57" Archived-At: Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 16:31:16 -0000 --0000000000004682a305ae2eee57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For the 80% case (e.g. temperature), a non-solution is to use an attribute called "temperature". Every device that deals with temperature must understand standard units of temperature, which should be communicated using attribute names like "kelvins", "degrees_f", or "degrees_c". The data format could (should?) be standardized as float, which doesn't make a difference in JSON but does in CBOR. What if you want to design a device that uses int8 between 0 and 100 to represent -40C to 200C? Then you're not in the 80% any more. The other 20% should be addressed using the same principle: "brightness" is a useless property name, "lumens" is better in that it specifies a measurable value, but has the disadvantage that it is absolute, not relative to the capacity of the device. A relative attribute would at least need to specify the gamma of the control function. Time could be defined similarly, specifying units (e.g., nanoseconds, milliseconds, seconds) of resolution for intervals and an epoch for date-times. Or for the simple 80% a cumbersome but generally-understood RFC 3339 string could be used, hopefully using an "rfc3339-date-time" attribute, not "date-time". The general principle is that standard units need to be defined in the first place, and then attribute names should refer to the standard, not a unitless name of a feature. Dave On Mon, Aug 31, 2020 at 11:22 AM Milan Milenkovic wrote: > For your example, I was going to suggest the range fraction or % solution > but Wouter beat me to it. > > More importantly, I think we should be pragmatic and aim for the 80% > solution (which, according to the Pareto principle, may require definitio= n > of only 20% of use cases ;-). IMO, luminosity ad brightness are examples > of a relatively skewed minor use case in a specific domain that is > consuming disproportionate amounts of time and effort to address and that > complicates many a solution for what is at best a small benefit. Such > things can be tabled, and possibly revisited later, to allow progress on > solutions for the most common use cases. > > -----Original Message----- > From: ASDF On Behalf Of Carsten Bormann > > In today=E2=80=99s OneDM call, Bruce Nordman brought up the issue that, i= n the > end, we=E2=80=99ll need concrete representations to talk to devices and u= se their > data. > > So if we have one ecosystem that uses 0..100 for describing the brightnes= s > setting for a lamp, another one that uses 0..254 (where 255 means somethi= ng > complete different), and a third with 0..65535, what do we do? (And thes= e > might also differ whether they describe a emitted light power level or a > perceptive luminous flux level.) > > The underlying problem is that we are abusing data model level descriptio= n > techniques (in part borrowed from json-schema.org) to describe > information models. > That works reasonably well until we start taking these data model level > descriptions at face value. The fact that some converged model uses a > scale based on the L component of Lu=E2=80=99v=E2=80=99 does not mean tha= t everybody has to > represent their ecosystem model the same way. > --0000000000004682a305ae2eee57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the 80% case (e.g. temperature), a non-solution i= s to use an attribute called "temperature".=C2=A0 Every device th= at deals with temperature must understand standard units of temperature, wh= ich should be communicated using attribute names like "kelvins", = "degrees_f", or "degrees_c".=C2=A0 The data format coul= d (should?) be standardized as float, which doesn't make a difference i= n JSON but does in CBOR.=C2=A0 What if you want to design a device that use= s int8 between 0 and 100 to represent -40C to 200C?=C2=A0 Then you're n= ot in the 80% any more.

The other 20% should be addressed using the = same principle: "brightness" is a useless property name, "lu= mens" is better in that it specifies a measurable value, but has the d= isadvantage that it is absolute, not relative to the capacity of the device= .=C2=A0 A relative attribute would at least need to specify the gamma of th= e control function.

Time could be defined similarly, specifying unit= s (e.g., nanoseconds, milliseconds, seconds) of resolution for intervals an= d an epoch for date-times.=C2=A0 Or for the simple 80% a cumbersome but gen= erally-understood RFC 3339 string could be used, hopefully using an "r= fc3339-date-time" attribute, not "date-time".

The gen= eral principle is that standard units need to be defined in the first place= , and then attribute names should refer to the standard, not a unitless nam= e of a feature.

Dave


On Mon, Aug 31, 2020 at 11:22 AM Milan Milen= kovic <milan@iotsense.com> = wrote:
For your example, I was going to suggest the range fraction or % solution b= ut Wouter beat me to it.

More importantly, I think we should be pragmatic and aim for the 80% soluti= on (which, according to the Pareto principle, may require definition of onl= y 20% of use cases ;-).=C2=A0 IMO, luminosity ad brightness are examples of= a relatively skewed minor use case in a specific domain that is consuming = disproportionate amounts of time and effort to address and that complicates= many a solution for what is at best a small benefit.=C2=A0 Such things can= be tabled, and possibly revisited later, to allow progress on solutions fo= r the most common use cases.

-----Original Message-----
From: ASDF <a= sdf-bounces@ietf.org> On Behalf Of Carsten Bormann

In today=E2=80=99s OneDM call, Bruce Nordman brought up the issue that, in = the end, we=E2=80=99ll need concrete representations to talk to devices and= use their data.

So if we have one ecosystem that uses 0..100 for describing the brightness = setting for a lamp, another one that uses 0..254 (where 255 means something= complete different), and a third with 0..65535, what do we do?=C2=A0 (And = these might also differ whether they describe a emitted light power level o= r a perceptive luminous flux level.)

The underlying problem is that we are abusing data model level description = techniques (in part borrowed from json-schema.org) to describe information= models.
That works reasonably well until we start taking these data model level des= criptions at face value.=C2=A0 The fact that some converged model uses a sc= ale based on the L component of Lu=E2=80=99v=E2=80=99 does not mean that ev= erybody has to represent their ecosystem model the same way.
--0000000000004682a305ae2eee57-- From nobody Mon Aug 31 12:03:18 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A81B3A18BF for ; Mon, 31 Aug 2020 12:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotsense.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 WICM2LDw78BH for ; Mon, 31 Aug 2020 12:03:14 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2110.outbound.protection.outlook.com [40.107.243.110]) (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 077B63A18D9 for ; Mon, 31 Aug 2020 12:03:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BS72VZ3YXAdlVVgHttEOp2UQopYi2cOVSDpSqve+02pwoyeFQWwx85WzvtQw0+Lvi2uUG5ate6p4h4bTNhv5YprIUDG7kc9kzZl2B07VFYXBT7lc7qb2KpQIqfAe+jCGGRtoQP/dyk00fT7jSSjCdb4m4RBrH8MDpFcYL60bn63IMzDiEARNDNBtweyeFn2Ini8XOhSBLcjqUVh3xSE6RgU93kiNN77Q3KFbR6O9gjQ5APd8MZuKkuT7Id8PiyT26Q5lS4jDAOUNUxzO+S3gss2PIKtq36/1UkNEaDPw7+BB0F7nfcA8xPYLXrFKXr+Gl+nySssbmzPWrdxA26kZ2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Iv/ea3xcO7dxIJloTgN+jqxqXUh2Cs6GYildAxY9V5Q=; b=n/W0XEE2Q2nWxHUT8GwVr4+9zQzkp0DuiaPHh7nke+EH+6XwYkt5LhVeLNqzCAlh/3phBqCaL/+Vg9czTDku2u65u0gB9T05lJv5pEzxd4bGbpiuOP5GABgQ3VRWOCFqfp4Tk+x1p7Mp8ndox77kgVvWrZ2L71Kx7d0eoPACCOOXIPOESlvQbRc8N2+dGecEapHmfU69aVFxceQqfjDOj27gVEiC9qE7Mdj4fLpj1SGCCr4KvvTYhkOwa6EfVMljaseZ4tDissn/ey9jlQekuPZgCYHSJhS8wApRTFbXIvUc0vXRcz1O+3Oo+o207O5J8w8CKkzJTQgQ5fFWhVBdgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotsense.com; dmarc=pass action=none header.from=iotsense.com; dkim=pass header.d=iotsense.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotsense.onmicrosoft.com; s=selector2-iotsense-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Iv/ea3xcO7dxIJloTgN+jqxqXUh2Cs6GYildAxY9V5Q=; b=NL/sP0IR7wgeP7bUm3IDyp9qj2Ue73dKIZqnLS4tVRE+IujpnzWo6fPzfdmcSTeOAv7KmL1cYfpNcVm13m5fW0XQUGSCYpxqM4at/0otQIkdrj+xWBUu/JU4sw5HYQYDjYFy0qlMlSgsmt5QLGNkOHpBeqbPoGSslSmZaq2OiHg= Received: from BYAPR18MB2536.namprd18.prod.outlook.com (2603:10b6:a03:136::32) by BYAPR18MB3078.namprd18.prod.outlook.com (2603:10b6:a03:102::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.23; Mon, 31 Aug 2020 19:03:04 +0000 Received: from BYAPR18MB2536.namprd18.prod.outlook.com ([fe80::7592:6a3e:a40:589d]) by BYAPR18MB2536.namprd18.prod.outlook.com ([fe80::7592:6a3e:a40:589d%4]) with mapi id 15.20.3326.025; Mon, 31 Aug 2020 19:03:04 +0000 From: Milan Milenkovic To: One Data Model Group CC: "asdf@ietf.org" , "t2trg@irtf.org" Thread-Topic: [One Data Model Group] [Asdf] Representation issues and protocol bindings Thread-Index: AQHWf6YhJFJ1diSpEk6fXKfeXFPwy6lSUhPggAAW2oCAACp8Ow== Date: Mon, 31 Aug 2020 19:03:04 +0000 Message-ID: References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=iotsense.com; x-originating-ip: [109.245.35.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f3365bdc-3e47-4e30-94e5-08d84de07d6d x-ms-traffictypediagnostic: BYAPR18MB3078: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zgMNgl7wo517VjIhHQdrV4i/YZhtmmVPIFcGJK/sY66Uc1NCswgxFR4RLZ0r9fiFzdxZsZqmLjBCt9ys0Jx/jHSufT48Ki39jKaRxVNK4UxDN3qk8UTdMTR36DSWNIXEYQF4FP+kIwnY7xmQw1iLt4tWx+zOtMWpHGGxLAhVo8UbGB5zvBm75fXRjzOZdGjeo1ZaMoNPcRDUxotOVKiwc/CQ3SelMwkzX89/jndONV85yFgkP/6AiypmKFqYN3J0liryubPZlX800E+QDEsCD0G53DLRpiHmYVIQCejaOSuVBk/zeu2kBksa0ZVGN+ygbtw9RyrYGAdxvMfuxiEwY2U5/RovvHtbcaQjOUxgEIdOh/cSrLcoNSsrtqO7C0FN1WoRBJSRnSf7lIw5N9B2VA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2536.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39830400003)(366004)(346002)(136003)(376002)(2616005)(64756008)(83380400001)(316002)(76116006)(91956017)(66476007)(26005)(66556008)(54906003)(6486002)(86362001)(53546011)(66446008)(166002)(66946007)(6506007)(5660300002)(186003)(6512007)(33656002)(6916009)(478600001)(8676002)(71200400001)(4326008)(2906002)(8936002)(36756003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: LCnu/jEG2oedZXaMW++89Jmx4jA7JEnBIOnjqTo/Qp4bjRkQQljM4uXTvcRKjiSGsYn4Hwsz9V1v1C3qUjNQGqR3lmM9VKg/YWjd4hnIBv1JbN0d5IMUJ9vNwLcCuQ0A7S1sTDrjx4Za9bMovDet4Uv16hidqOqbjaWEONvkFvWYLG4qQ4laB8CyrEf9mAbw8t8+C47gDTGyU3RhbBEEllqj3y7QMvu7ciTB+DF7slMWQ4rrluGIQQJRinNZ9FDYAY6UvAI0IrAlDolpUwEmuTc6smgphtvJxWPGAbEodZGZ56LhNJ47NTIHvRbXJHOCLT5h1bm9kw8AAQ5K5BGmcL0qPB6c3KHP8z3w2PsIVFDFE/7UgVnN0jjEjlOZAUV0b91NVEiX1A9iu2tiTRWClNZDNM68HZlOfgo4sOtaKM5sYljlQE/4LGLkVxBLvrY6h3kDWA0JmMOMZRWBo93ZsA4370ItSQ+txEWs/18PgfP42piMrgD8bT+SwB7zDRu0rce9vgiDb+44jUNuJT0pNxbHMziLLJNjVuusqyaVHrnJF9OijOOoPXYO/WvfVQL/qd8cVgbDOn7m6UKhoZGtbTKiSODWU4n+wu4FwApl3vsUuOEx4VVfiBCEDGNA3o1Em0PDvpMq322SUvb9OQBB0Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FA1E8E368B2F4C4D90AE7F867268ACA4iotsensecom_" MIME-Version: 1.0 X-OriginatorOrg: iotsense.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2536.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f3365bdc-3e47-4e30-94e5-08d84de07d6d X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 19:03:04.4702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b545f0f5-d78c-40e8-8d33-8972480ced5e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eN8aaMwHDUzMeXUHB0Lhzeb6ewUm/wCi6mN6EfIxGohUMzQIxvUoSv5ZoLkT1NOlV3Qu+9F43xcV5F4Jpw0mIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB3078 Archived-At: Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 19:03:16 -0000 --_000_FA1E8E368B2F4C4D90AE7F867268ACA4iotsensecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBicmluZ3MgdXAgYW5vdGhlciBwb2ludCBpbiBkZXRlcm1pbmluZyBzdGFuZGFyZHMgc3Ry YXRlZ3kgLSB3aG8gc2hvdWxkIGJlYXIgdGhlIGJ1cmRlbiBvZiBzdXBwb3J0aW5nIHVuY29tbW9u IHJlcHJlc2VudGF0aW9ucyBsaWtlIHlvdXIgdGVtcGVyYXR1cmUgZXhhbXBsZT8gSXQgaXMgZWl0 aGVyIGl0cyBjcmVhdG9yIChieSBhZGRpbmcgYSBmZXcgbGluZXMgb2YgY29kZSB0byBicmluZyBp dCB0byDigJw4MCXigJ0pIG9yIGV2ZXJ5Ym9keSBlbHNlIGJ5IGhhdmluZyB0byBpbXBsZW1lbnQg YSBtb3JlIGNvbXBsaWNhdGVkIGFjY29tbW9kYXRpbmcgIHN0YW5kYXJkPw0KDQpJIHRoaW5rIHNp bXBsZXIgc3BlY2lmaWNhdGlvbnMgdGhhdCBjb3ZlciBjb21tb24gY2FzZXMgYXJlIGEgYmV0dGVy IHdheSB0byBnby4NCg0KU2VudCBmcm9tIE1pbGFuJ3MgcGhvbmUuDQoNCk9uIEF1ZyAzMSwgMjAy MCwgYXQgMTg6MzEsIE9uZSBEYXRhIE1vZGVsIEdyb3VwIDxvbmVkbUBpb3RsaWFpc29uLm9yZz4g d3JvdGU6DQoNCu+7vw0KRm9yIHRoZSA4MCUgY2FzZSAoZS5nLiB0ZW1wZXJhdHVyZSksIGEgbm9u LXNvbHV0aW9uIGlzIHRvIHVzZSBhbiBhdHRyaWJ1dGUgY2FsbGVkICJ0ZW1wZXJhdHVyZSIuICBF dmVyeSBkZXZpY2UgdGhhdCBkZWFscyB3aXRoIHRlbXBlcmF0dXJlIG11c3QgdW5kZXJzdGFuZCBz dGFuZGFyZCB1bml0cyBvZiB0ZW1wZXJhdHVyZSwgd2hpY2ggc2hvdWxkIGJlIGNvbW11bmljYXRl ZCB1c2luZyBhdHRyaWJ1dGUgbmFtZXMgbGlrZSAia2VsdmlucyIsICJkZWdyZWVzX2YiLCBvciAi ZGVncmVlc19jIi4gIFRoZSBkYXRhIGZvcm1hdCBjb3VsZCAoc2hvdWxkPykgYmUgc3RhbmRhcmRp emVkIGFzIGZsb2F0LCB3aGljaCBkb2Vzbid0IG1ha2UgYSBkaWZmZXJlbmNlIGluIEpTT04gYnV0 IGRvZXMgaW4gQ0JPUi4gIFdoYXQgaWYgeW91IHdhbnQgdG8gZGVzaWduIGEgZGV2aWNlIHRoYXQg dXNlcyBpbnQ4IGJldHdlZW4gMCBhbmQgMTAwIHRvIHJlcHJlc2VudCAtNDBDIHRvIDIwMEM/ICBU aGVuIHlvdSdyZSBub3QgaW4gdGhlIDgwJSBhbnkgbW9yZS4NCg0KVGhlIG90aGVyIDIwJSBzaG91 bGQgYmUgYWRkcmVzc2VkIHVzaW5nIHRoZSBzYW1lIHByaW5jaXBsZTogImJyaWdodG5lc3MiIGlz IGEgdXNlbGVzcyBwcm9wZXJ0eSBuYW1lLCAibHVtZW5zIiBpcyBiZXR0ZXIgaW4gdGhhdCBpdCBz cGVjaWZpZXMgYSBtZWFzdXJhYmxlIHZhbHVlLCBidXQgaGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhh dCBpdCBpcyBhYnNvbHV0ZSwgbm90IHJlbGF0aXZlIHRvIHRoZSBjYXBhY2l0eSBvZiB0aGUgZGV2 aWNlLiAgQSByZWxhdGl2ZSBhdHRyaWJ1dGUgd291bGQgYXQgbGVhc3QgbmVlZCB0byBzcGVjaWZ5 IHRoZSBnYW1tYSBvZiB0aGUgY29udHJvbCBmdW5jdGlvbi4NCg0KVGltZSBjb3VsZCBiZSBkZWZp bmVkIHNpbWlsYXJseSwgc3BlY2lmeWluZyB1bml0cyAoZS5nLiwgbmFub3NlY29uZHMsIG1pbGxp c2Vjb25kcywgc2Vjb25kcykgb2YgcmVzb2x1dGlvbiBmb3IgaW50ZXJ2YWxzIGFuZCBhbiBlcG9j aCBmb3IgZGF0ZS10aW1lcy4gIE9yIGZvciB0aGUgc2ltcGxlIDgwJSBhIGN1bWJlcnNvbWUgYnV0 IGdlbmVyYWxseS11bmRlcnN0b29kIFJGQyAzMzM5IHN0cmluZyBjb3VsZCBiZSB1c2VkLCBob3Bl ZnVsbHkgdXNpbmcgYW4gInJmYzMzMzktZGF0ZS10aW1lIiBhdHRyaWJ1dGUsIG5vdCAiZGF0ZS10 aW1lIi4NCg0KVGhlIGdlbmVyYWwgcHJpbmNpcGxlIGlzIHRoYXQgc3RhbmRhcmQgdW5pdHMgbmVl ZCB0byBiZSBkZWZpbmVkIGluIHRoZSBmaXJzdCBwbGFjZSwgYW5kIHRoZW4gYXR0cmlidXRlIG5h bWVzIHNob3VsZCByZWZlciB0byB0aGUgc3RhbmRhcmQsIG5vdCBhIHVuaXRsZXNzIG5hbWUgb2Yg YSBmZWF0dXJlLg0KDQpEYXZlDQoNCg0KT24gTW9uLCBBdWcgMzEsIDIwMjAgYXQgMTE6MjIgQU0g TWlsYW4gTWlsZW5rb3ZpYyA8bWlsYW5AaW90c2Vuc2UuY29tPG1haWx0bzptaWxhbkBpb3RzZW5z ZS5jb20+PiB3cm90ZToNCkZvciB5b3VyIGV4YW1wbGUsIEkgd2FzIGdvaW5nIHRvIHN1Z2dlc3Qg dGhlIHJhbmdlIGZyYWN0aW9uIG9yICUgc29sdXRpb24gYnV0IFdvdXRlciBiZWF0IG1lIHRvIGl0 Lg0KDQpNb3JlIGltcG9ydGFudGx5LCBJIHRoaW5rIHdlIHNob3VsZCBiZSBwcmFnbWF0aWMgYW5k IGFpbSBmb3IgdGhlIDgwJSBzb2x1dGlvbiAod2hpY2gsIGFjY29yZGluZyB0byB0aGUgUGFyZXRv IHByaW5jaXBsZSwgbWF5IHJlcXVpcmUgZGVmaW5pdGlvbiBvZiBvbmx5IDIwJSBvZiB1c2UgY2Fz ZXMgOy0pLiAgSU1PLCBsdW1pbm9zaXR5IGFkIGJyaWdodG5lc3MgYXJlIGV4YW1wbGVzIG9mIGEg cmVsYXRpdmVseSBza2V3ZWQgbWlub3IgdXNlIGNhc2UgaW4gYSBzcGVjaWZpYyBkb21haW4gdGhh dCBpcyBjb25zdW1pbmcgZGlzcHJvcG9ydGlvbmF0ZSBhbW91bnRzIG9mIHRpbWUgYW5kIGVmZm9y dCB0byBhZGRyZXNzIGFuZCB0aGF0IGNvbXBsaWNhdGVzIG1hbnkgYSBzb2x1dGlvbiBmb3Igd2hh dCBpcyBhdCBiZXN0IGEgc21hbGwgYmVuZWZpdC4gIFN1Y2ggdGhpbmdzIGNhbiBiZSB0YWJsZWQs IGFuZCBwb3NzaWJseSByZXZpc2l0ZWQgbGF0ZXIsIHRvIGFsbG93IHByb2dyZXNzIG9uIHNvbHV0 aW9ucyBmb3IgdGhlIG1vc3QgY29tbW9uIHVzZSBjYXNlcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE9uZSBEYXRhIE1vZGVsIEdyb3VwIHNkZi1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQoNCkluIHRvZGF54oCZcyBPbmVETSBjYWxs LCBCcnVjZSBOb3JkbWFuIGJyb3VnaHQgdXAgdGhlIGlzc3VlIHRoYXQsIGluIHRoZSBlbmQsIHdl 4oCZbGwgbmVlZCBjb25jcmV0ZSByZXByZXNlbnRhdGlvbnMgdG8gdGFsayB0byBkZXZpY2VzIGFu ZCB1c2UgdGhlaXIgZGF0YS4NCg0KU28gaWYgd2UgaGF2ZSBvbmUgZWNvc3lzdGVtIHRoYXQgdXNl cyAwLi4xMDAgZm9yIGRlc2NyaWJpbmcgdGhlIGJyaWdodG5lc3Mgc2V0dGluZyBmb3IgYSBsYW1w LCBhbm90aGVyIG9uZSB0aGF0IHVzZXMgMC4uMjU0ICh3aGVyZSAyNTUgbWVhbnMgc29tZXRoaW5n IGNvbXBsZXRlIGRpZmZlcmVudCksIGFuZCBhIHRoaXJkIHdpdGggMC4uNjU1MzUsIHdoYXQgZG8g d2UgZG8/ICAoQW5kIHRoZXNlIG1pZ2h0IGFsc28gZGlmZmVyIHdoZXRoZXIgdGhleSBkZXNjcmli ZSBhIGVtaXR0ZWQgbGlnaHQgcG93ZXIgbGV2ZWwgb3IgYSBwZXJjZXB0aXZlIGx1bWlub3VzIGZs dXggbGV2ZWwuKQ0KDQpUaGUgdW5kZXJseWluZyBwcm9ibGVtIGlzIHRoYXQgd2UgYXJlIGFidXNp bmcgZGF0YSBtb2RlbCBsZXZlbCBkZXNjcmlwdGlvbiB0ZWNobmlxdWVzIChpbiBwYXJ0IGJvcnJv d2VkIGZyb20ganNvbi1zY2hlbWEub3JnPGh0dHA6Ly9qc29uLXNjaGVtYS5vcmc+KSB0byBkZXNj cmliZSBpbmZvcm1hdGlvbiBtb2RlbHMuDQpUaGF0IHdvcmtzIHJlYXNvbmFibHkgd2VsbCB1bnRp bCB3ZSBzdGFydCB0YWtpbmcgdGhlc2UgZGF0YSBtb2RlbCBsZXZlbCBkZXNjcmlwdGlvbnMgYXQg ZmFjZSB2YWx1ZS4gIFRoZSBmYWN0IHRoYXQgc29tZSBjb252ZXJnZWQgbW9kZWwgdXNlcyBhIHNj YWxlIGJhc2VkIG9uIHRoZSBMIGNvbXBvbmVudCBvZiBMdeKAmXbigJkgZG9lcyBub3QgbWVhbiB0 aGF0IGV2ZXJ5Ym9keSBoYXMgdG8gcmVwcmVzZW50IHRoZWlyIGVjb3N5c3RlbSBtb2RlbCB0aGUg c2FtZSB3YXkuDQo= --_000_FA1E8E368B2F4C4D90AE7F867268ACA4iotsensecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpU aGlzIGJyaW5ncyB1cCBhbm90aGVyIHBvaW50IGluIGRldGVybWluaW5nIHN0YW5kYXJkcyBzdHJh dGVneSAtIHdobyBzaG91bGQgYmVhciB0aGUgYnVyZGVuIG9mIHN1cHBvcnRpbmcgdW5jb21tb24g cmVwcmVzZW50YXRpb25zIGxpa2UgeW91ciB0ZW1wZXJhdHVyZSBleGFtcGxlPyBJdCBpcyBlaXRo ZXIgaXRzIGNyZWF0b3IgKGJ5IGFkZGluZyBhIGZldyBsaW5lcyBvZiBjb2RlIHRvIGJyaW5nIGl0 IHRvIOKAnDgwJeKAnSkgb3IgZXZlcnlib2R5IGVsc2UNCiBieSBoYXZpbmcgdG8gaW1wbGVtZW50 IGEgbW9yZSBjb21wbGljYXRlZCBhY2NvbW1vZGF0aW5nICZuYnNwO3N0YW5kYXJkPw0KPGRpdj48 YnI+DQo8ZGl2PkkgdGhpbmsgc2ltcGxlciBzcGVjaWZpY2F0aW9ucyB0aGF0IGNvdmVyIGNvbW1v biBjYXNlcyBhcmUgYSBiZXR0ZXIgd2F5IHRvIGdvLiZuYnNwOzxicj4NCjxicj4NCjxkaXYgZGly PSJsdHIiPlNlbnQgZnJvbSBNaWxhbidzIHBob25lLjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJy Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gQXVnIDMxLCAyMDIwLCBhdCAxODozMSwgT25l IERhdGEgTW9kZWwgR3JvdXAgJmx0O29uZWRtQGlvdGxpYWlzb24ub3JnJmd0OyB3cm90ZTo8YnI+ DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGRpdiBkaXI9Imx0ciI+77u/DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+Rm9yIHRoZSA4MCUgY2Fz ZSAoZS5nLiB0ZW1wZXJhdHVyZSksIGEgbm9uLXNvbHV0aW9uIGlzIHRvIHVzZSBhbiBhdHRyaWJ1 dGUgY2FsbGVkICZxdW90O3RlbXBlcmF0dXJlJnF1b3Q7LiZuYnNwOyBFdmVyeSBkZXZpY2UgdGhh dCBkZWFscyB3aXRoIHRlbXBlcmF0dXJlIG11c3QgdW5kZXJzdGFuZCBzdGFuZGFyZCB1bml0cyBv ZiB0ZW1wZXJhdHVyZSwgd2hpY2ggc2hvdWxkIGJlIGNvbW11bmljYXRlZCB1c2luZyBhdHRyaWJ1 dGUgbmFtZXMgbGlrZSAmcXVvdDtrZWx2aW5zJnF1b3Q7LA0KICZxdW90O2RlZ3JlZXNfZiZxdW90 Oywgb3IgJnF1b3Q7ZGVncmVlc19jJnF1b3Q7LiZuYnNwOyBUaGUgZGF0YSBmb3JtYXQgY291bGQg KHNob3VsZD8pIGJlIHN0YW5kYXJkaXplZCBhcyBmbG9hdCwgd2hpY2ggZG9lc24ndCBtYWtlIGEg ZGlmZmVyZW5jZSBpbiBKU09OIGJ1dCBkb2VzIGluIENCT1IuJm5ic3A7IFdoYXQgaWYgeW91IHdh bnQgdG8gZGVzaWduIGEgZGV2aWNlIHRoYXQgdXNlcyBpbnQ4IGJldHdlZW4gMCBhbmQgMTAwIHRv IHJlcHJlc2VudCAtNDBDIHRvIDIwMEM/Jm5ic3A7IFRoZW4geW91J3JlDQogbm90IGluIHRoZSA4 MCUgYW55IG1vcmUuPGJyPg0KPGJyPg0KVGhlIG90aGVyIDIwJSBzaG91bGQgYmUgYWRkcmVzc2Vk IHVzaW5nIHRoZSBzYW1lIHByaW5jaXBsZTogJnF1b3Q7YnJpZ2h0bmVzcyZxdW90OyBpcyBhIHVz ZWxlc3MgcHJvcGVydHkgbmFtZSwgJnF1b3Q7bHVtZW5zJnF1b3Q7IGlzIGJldHRlciBpbiB0aGF0 IGl0IHNwZWNpZmllcyBhIG1lYXN1cmFibGUgdmFsdWUsIGJ1dCBoYXMgdGhlIGRpc2FkdmFudGFn ZSB0aGF0IGl0IGlzIGFic29sdXRlLCBub3QgcmVsYXRpdmUgdG8gdGhlIGNhcGFjaXR5IG9mIHRo ZSBkZXZpY2UuJm5ic3A7IEEgcmVsYXRpdmUNCiBhdHRyaWJ1dGUgd291bGQgYXQgbGVhc3QgbmVl ZCB0byBzcGVjaWZ5IHRoZSBnYW1tYSBvZiB0aGUgY29udHJvbCBmdW5jdGlvbi48YnI+DQo8YnI+ DQpUaW1lIGNvdWxkIGJlIGRlZmluZWQgc2ltaWxhcmx5LCBzcGVjaWZ5aW5nIHVuaXRzIChlLmcu LCBuYW5vc2Vjb25kcywgbWlsbGlzZWNvbmRzLCBzZWNvbmRzKSBvZiByZXNvbHV0aW9uIGZvciBp bnRlcnZhbHMgYW5kIGFuIGVwb2NoIGZvciBkYXRlLXRpbWVzLiZuYnNwOyBPciBmb3IgdGhlIHNp bXBsZSA4MCUgYSBjdW1iZXJzb21lIGJ1dCBnZW5lcmFsbHktdW5kZXJzdG9vZCBSRkMgMzMzOSBz dHJpbmcgY291bGQgYmUgdXNlZCwgaG9wZWZ1bGx5IHVzaW5nDQogYW4gJnF1b3Q7cmZjMzMzOS1k YXRlLXRpbWUmcXVvdDsgYXR0cmlidXRlLCBub3QgJnF1b3Q7ZGF0ZS10aW1lJnF1b3Q7Ljxicj4N Cjxicj4NClRoZSBnZW5lcmFsIHByaW5jaXBsZSBpcyB0aGF0IHN0YW5kYXJkIHVuaXRzIG5lZWQg dG8gYmUgZGVmaW5lZCBpbiB0aGUgZmlyc3QgcGxhY2UsIGFuZCB0aGVuIGF0dHJpYnV0ZSBuYW1l cyBzaG91bGQgcmVmZXIgdG8gdGhlIHN0YW5kYXJkLCBub3QgYSB1bml0bGVzcyBuYW1lIG9mIGEg ZmVhdHVyZS48YnI+DQo8YnI+DQpEYXZlPC9kaXY+DQo8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gTW9uLCBB dWcgMzEsIDIwMjAgYXQgMTE6MjIgQU0gTWlsYW4gTWlsZW5rb3ZpYyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1pbGFuQGlvdHNlbnNlLmNvbSI+bWlsYW5AaW90c2Vuc2UuY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk ZGluZy1sZWZ0OjFleCI+DQpGb3IgeW91ciBleGFtcGxlLCBJIHdhcyBnb2luZyB0byBzdWdnZXN0 IHRoZSByYW5nZSBmcmFjdGlvbiBvciAlIHNvbHV0aW9uIGJ1dCBXb3V0ZXIgYmVhdCBtZSB0byBp dC48YnI+DQo8YnI+DQpNb3JlIGltcG9ydGFudGx5LCBJIHRoaW5rIHdlIHNob3VsZCBiZSBwcmFn bWF0aWMgYW5kIGFpbSBmb3IgdGhlIDgwJSBzb2x1dGlvbiAod2hpY2gsIGFjY29yZGluZyB0byB0 aGUgUGFyZXRvIHByaW5jaXBsZSwgbWF5IHJlcXVpcmUgZGVmaW5pdGlvbiBvZiBvbmx5IDIwJSBv ZiB1c2UgY2FzZXMgOy0pLiZuYnNwOyBJTU8sIGx1bWlub3NpdHkgYWQgYnJpZ2h0bmVzcyBhcmUg ZXhhbXBsZXMgb2YgYSByZWxhdGl2ZWx5IHNrZXdlZCBtaW5vciB1c2UgY2FzZSBpbg0KIGEgc3Bl Y2lmaWMgZG9tYWluIHRoYXQgaXMgY29uc3VtaW5nIGRpc3Byb3BvcnRpb25hdGUgYW1vdW50cyBv ZiB0aW1lIGFuZCBlZmZvcnQgdG8gYWRkcmVzcyBhbmQgdGhhdCBjb21wbGljYXRlcyBtYW55IGEg c29sdXRpb24gZm9yIHdoYXQgaXMgYXQgYmVzdCBhIHNtYWxsIGJlbmVmaXQuJm5ic3A7IFN1Y2gg dGhpbmdzIGNhbiBiZSB0YWJsZWQsIGFuZCBwb3NzaWJseSByZXZpc2l0ZWQgbGF0ZXIsIHRvIGFs bG93IHByb2dyZXNzIG9uIHNvbHV0aW9ucyBmb3INCiB0aGUgbW9zdCBjb21tb24gdXNlIGNhc2Vz Ljxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogT25lIERh dGEgTW9kZWwgR3JvdXAgPG9uZWRtQGlvdGxpYWlzb24ub3JnPnNkZi1ib3VuY2VzQGlldGYub3Jn Jmd0OyBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uPGJyPg0KPGJyPg0KSW4gdG9kYXnigJlz IE9uZURNIGNhbGwsIEJydWNlIE5vcmRtYW4gYnJvdWdodCB1cCB0aGUgaXNzdWUgdGhhdCwgaW4g dGhlIGVuZCwgd2XigJlsbCBuZWVkIGNvbmNyZXRlIHJlcHJlc2VudGF0aW9ucyB0byB0YWxrIHRv IGRldmljZXMgYW5kIHVzZSB0aGVpciBkYXRhLjxicj4NCjxicj4NClNvIGlmIHdlIGhhdmUgb25l IGVjb3N5c3RlbSB0aGF0IHVzZXMgMC4uMTAwIGZvciBkZXNjcmliaW5nIHRoZSBicmlnaHRuZXNz IHNldHRpbmcgZm9yIGEgbGFtcCwgYW5vdGhlciBvbmUgdGhhdCB1c2VzIDAuLjI1NCAod2hlcmUg MjU1IG1lYW5zIHNvbWV0aGluZyBjb21wbGV0ZSBkaWZmZXJlbnQpLCBhbmQgYSB0aGlyZCB3aXRo IDAuLjY1NTM1LCB3aGF0IGRvIHdlIGRvPyZuYnNwOyAoQW5kIHRoZXNlIG1pZ2h0IGFsc28gZGlm ZmVyIHdoZXRoZXIgdGhleQ0KIGRlc2NyaWJlIGEgZW1pdHRlZCBsaWdodCBwb3dlciBsZXZlbCBv ciBhIHBlcmNlcHRpdmUgbHVtaW5vdXMgZmx1eCBsZXZlbC4pPGJyPg0KPGJyPg0KVGhlIHVuZGVy bHlpbmcgcHJvYmxlbSBpcyB0aGF0IHdlIGFyZSBhYnVzaW5nIGRhdGEgbW9kZWwgbGV2ZWwgZGVz Y3JpcHRpb24gdGVjaG5pcXVlcyAoaW4gcGFydCBib3Jyb3dlZCBmcm9tDQo8YSBocmVmPSJodHRw Oi8vanNvbi1zY2hlbWEub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5qc29u LXNjaGVtYS5vcmc8L2E+KSB0byBkZXNjcmliZSBpbmZvcm1hdGlvbiBtb2RlbHMuPGJyPg0KVGhh dCB3b3JrcyByZWFzb25hYmx5IHdlbGwgdW50aWwgd2Ugc3RhcnQgdGFraW5nIHRoZXNlIGRhdGEg bW9kZWwgbGV2ZWwgZGVzY3JpcHRpb25zIGF0IGZhY2UgdmFsdWUuJm5ic3A7IFRoZSBmYWN0IHRo YXQgc29tZSBjb252ZXJnZWQgbW9kZWwgdXNlcyBhIHNjYWxlIGJhc2VkIG9uIHRoZSBMIGNvbXBv bmVudCBvZiBMdeKAmXbigJkgZG9lcyBub3QgbWVhbiB0aGF0IGV2ZXJ5Ym9keSBoYXMgdG8gcmVw cmVzZW50IHRoZWlyIGVjb3N5c3RlbSBtb2RlbCB0aGUgc2FtZQ0KIHdheS48YnI+DQo8L29uZWRt QGlvdGxpYWlzb24ub3JnPjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FA1E8E368B2F4C4D90AE7F867268ACA4iotsensecom_-- From nobody Mon Aug 31 13:19:01 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CDF3A1945 for ; Mon, 31 Aug 2020 13:18:59 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lbl-gov.20150623.gappssmtp.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 cZb0TaP8RvKX for ; Mon, 31 Aug 2020 13:18:57 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 7B6493A1942 for ; Mon, 31 Aug 2020 13:18:57 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id x203so2975633vsc.11 for ; Mon, 31 Aug 2020 13:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lbl-gov.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IYTIGTyUeTaWiM+XzdsyruOsXjmgSZwHKLKfzwu+e24=; b=PwSN1BOJvXQ9DncOrLkTe508iSVMBvFA+Tbztp1hHXfgTffy45GRNy3NMz4F4eOKr8 UfPr5g2p3V2wcetjczHUAc/I2D3kJMf2ueSZPvHhBwKMEfWlOLQbcHevfGNV0IXfZrTz JY07T1+blRvbwe5LqNYrf0f59V5mcj6qwte+zjdq7hy3s1SDNgJJvZbilf3EwREWHI3x ZjGIinXqKB1ldiz6JAZ+v+0tis4iC1CB2EVJtqDm1CSxHnrcurddd2rV1TbNI8nDrWOa i2Q0pjjsyfF6uSVGtZub72rXL8Vr1xWZe1uGmI/qUDIQIrUo+OgqYItk1GQRQIfOTudh ghtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IYTIGTyUeTaWiM+XzdsyruOsXjmgSZwHKLKfzwu+e24=; b=WXOVXLKOgD4AdZmdNy3yuW4Kj0mRVrxet5eNq1CZXJVsSAfhWNlHA7uDNuDMK2U+06 T9POCKXAE1V7P68RzNZ0dCY/zFSXdMaBFPf1CGKBsE0qBJz6G28ghLOLK4QFv95iU9py CGFfvf0+76wKUsUi8sd9V3qQy9L08gQS1/XWhxvNy0vghzN2NvllYc/RDBOEAci8ibJP VLeQ7T4jT1UZONjTn5T8fE1ORl2fMrPwZexuRKjYzDfsMtyjZsKa7O0iODFXtZXNtiJ4 iwdvIqprc8/NVP1qJIajIntpGZSEfF/QascuYMt4NuArLaXqiZmG332QaK7L6EJp80+h MpKw== X-Gm-Message-State: AOAM531osE/2PDzNuvuDpZV4SU879CpU40uW3YnWB7f7yMF2TpqjJmHN qcpL+rRRhwEWQ9jp9v6BLcZFgFX8APhC2WTKEtUKb0MaxIjdppb5b/U4L5XoUDV3FOPvamOOyIS qwu4PTPQfMGyUfdVlxQ5TAibdzmTg1wTjqiJ4eaiESzt+neJxSI0RBdI8nyrBmnoGVvJicEW97A == X-Google-Smtp-Source: ABdhPJxko1Rtf8Tpzqw5VJhIU7xiq87/JImWrf0iphod2lJbOeqJ2p0v2ijdFquL3YVHt7cf5lyr4Hd/i+HIGkywyuY= X-Received: by 2002:a67:7795:: with SMTP id s143mr2825014vsc.94.1598905135168; Mon, 31 Aug 2020 13:18:55 -0700 (PDT) MIME-Version: 1.0 References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> In-Reply-To: From: Bruce Nordman Date: Mon, 31 Aug 2020 13:18:43 -0700 Message-ID: To: Milan Milenkovic Cc: One Data Model Group , "asdf@ietf.org" , "t2trg@irtf.org" Content-Type: multipart/alternative; boundary="0000000000009ce38705ae321cb7" Archived-At: Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 20:19:00 -0000 --0000000000009ce38705ae321cb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm glad this topic has come up. I realize the work to date on SDF and such is an absolutely essential foundation to interoperability, but that other standardization is also needed. In the lighting case, Carsten noted originally that it can be specified with respect to emitted light or human-perceived light (we are non-linear), it could also be to light delivered to a surface or to input electrical power - and any of these could be absolute or relative to the maximum a source can provide. Another example is enumerated named light colors that can be spoken to smart speaker systems (e.g. Amazon or Google); these are similar but not the same, may not map to the same actual color, and colors are culturally varying in addition to varying with language. I had assumed from the start that ODM would define a reference semantic model that any protocol could be translated into, or out of, which necessarily requires picking some existing model to use directly or to adapt, or creating a new one. From the ODM call today I take it that this is a topic which ODM has not yet settled on an approach to. While standardizing on things like the naming and meaning of individual element is needed, in some cases information is represented in ways which is just different. I have worked for many years on the concept of 'power state' (and aided in our move from a 2 power state world - on/off - to one with 3 - on/sleep/off). In some cases, models combine power state with a functional state of device (e.g. if a printer/MFD is printing, scanning, neither, etc.) into one enumeration. I am not sure of the right name for this topic area -- "semantics" seems to cover a lot more than this -- and I will defer to the rest of you as to when it should be taken up. That said, I think it needs to be on the agenda somehow. I do think that IANA could play a useful role in hosting some standard content for this - certainly enumerations but also other content - when no quality existing content exists to point to and there isn't a good option for another org. to take it up. An example topic that I think could be usefully standardized through IANA is Device Classification: *Device Classification*. Report on Simple Universal Device Classificatio= n (2014), Internet Draft and Presentation from IETF 82. *Taxonomy* of electronic and miscellaneous products (2006) I do agree with the sentiment that complexity is an enemy here and that some sort of 80/20 principle should apply. I think that ASCII and UniCode show how one can have a basic functionality alongside a much more sophisticated one and make good use of both. We need to create ASCII first= . Thanks, --Bruce On Mon, Aug 31, 2020 at 12:17 PM Milan Milenkovic wrote: > This brings up another point in determining standards strategy - who > should bear the burden of supporting uncommon representations like your > temperature example? It is either its creator (by adding a few lines of > code to bring it to =E2=80=9C80%=E2=80=9D) or everybody else by having to= implement a more > complicated accommodating standard? > > I think simpler specifications that cover common cases are a better way t= o > go. > > Sent from Milan's phone. > > On Aug 31, 2020, at 18:31, One Data Model Group > wrote: > > =EF=BB=BF > For the 80% case (e.g. temperature), a non-solution is to use an attribut= e > called "temperature". Every device that deals with temperature must > understand standard units of temperature, which should be communicated > using attribute names like "kelvins", "degrees_f", or "degrees_c". The > data format could (should?) be standardized as float, which doesn't make = a > difference in JSON but does in CBOR. What if you want to design a device > that uses int8 between 0 and 100 to represent -40C to 200C? Then you're > not in the 80% any more. > > The other 20% should be addressed using the same principle: "brightness" > is a useless property name, "lumens" is better in that it specifies a > measurable value, but has the disadvantage that it is absolute, not > relative to the capacity of the device. A relative attribute would at > least need to specify the gamma of the control function. > > Time could be defined similarly, specifying units (e.g., nanoseconds, > milliseconds, seconds) of resolution for intervals and an epoch for > date-times. Or for the simple 80% a cumbersome but generally-understood > RFC 3339 string could be used, hopefully using an "rfc3339-date-time" > attribute, not "date-time". > > The general principle is that standard units need to be defined in the > first place, and then attribute names should refer to the standard, not a > unitless name of a feature. > > Dave > > > On Mon, Aug 31, 2020 at 11:22 AM Milan Milenkovic > wrote: > >> For your example, I was going to suggest the range fraction or % solutio= n >> but Wouter beat me to it. >> >> More importantly, I think we should be pragmatic and aim for the 80% >> solution (which, according to the Pareto principle, may require definiti= on >> of only 20% of use cases ;-). IMO, luminosity ad brightness are example= s >> of a relatively skewed minor use case in a specific domain that is >> consuming disproportionate amounts of time and effort to address and tha= t >> complicates many a solution for what is at best a small benefit. Such >> things can be tabled, and possibly revisited later, to allow progress on >> solutions for the most common use cases. >> >> -----Original Message----- >> From: One Data Model Group sdf-bounces@ietf.org> On Behalf Of Carsten >> Bormann >> >> In today=E2=80=99s OneDM call, Bruce Nordman brought up the issue that, = in the >> end, we=E2=80=99ll need concrete representations to talk to devices and = use their >> data. >> >> So if we have one ecosystem that uses 0..100 for describing the >> brightness setting for a lamp, another one that uses 0..254 (where 255 >> means something complete different), and a third with 0..65535, what do = we >> do? (And these might also differ whether they describe a emitted light >> power level or a perceptive luminous flux level.) >> >> The underlying problem is that we are abusing data model level >> description techniques (in part borrowed from json-schema.org) to >> describe information models. >> That works reasonably well until we start taking these data model level >> descriptions at face value. The fact that some converged model uses a >> scale based on the L component of Lu=E2=80=99v=E2=80=99 does not mean th= at everybody has to >> represent their ecosystem model the same way. >> > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov * BNordman@LBL.gov 510-486-7089; m: 510-501-7943 m: 510-501-7943 --0000000000009ce38705ae321cb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm glad this topic has come up. I realize the wo= rk to date on SDF and such is an absolutely essential foundation to interop= erability, but that other standardization is also needed. In the lighting c= ase, Carsten noted originally that it can be specified with respect to emit= ted light or human-perceived light (we are non-linear), it could also be to= light delivered to a surface or to input electrical power - and any of the= se could be absolute or relative to the maximum a source can provide.=C2=A0= Another example is enumerated named light colors that can be spoken to sma= rt speaker systems (e.g. Amazon or Google); these are similar but not the s= ame, may not map to the same actual color, and colors are culturally varyin= g in addition to varying with language.

I had assu= med from the start that ODM would define a reference semantic model that an= y protocol could be translated into, or out of, which necessarily requires = picking some existing model to use directly or to adapt, or creating a new = one.=C2=A0 From the ODM call today I take it that this is a topic which ODM= has not yet settled on an approach to.

While stan= dardizing on things like the naming and meaning of individual element is ne= eded, in some cases information is represented in ways which is just differ= ent.=C2=A0 I have worked for many years on the concept of 'power state&= #39; (and aided in our move from a 2 power state world - on/off - to one wi= th 3 - on/sleep/off). In some cases, models combine power state with a func= tional state of device (e.g. if a printer/MFD is printing, scanning, neithe= r, etc.) into one enumeration.

I am not sure of th= e right name for this topic area -- "semantics" seems to cover a = lot more than this -- and I will defer to the rest of you as to when it sho= uld be taken up.=C2=A0 That said, I think it needs to be on the agenda some= how.=C2=A0 I do think that IANA could play a useful role in hosting some st= andard content for this - certainly enumerations but also other content - w= hen no quality existing content exists to point to and there isn't a go= od option for another org. to take it up.=C2=A0 An example topic that I thi= nk could be usefully standardized through IANA is Device Classification:
=C2=A0=C2=A0 Device Classification. Report on Simple Universal Device Class= ification (2014), Internet Draft= and Presentation from IETF 82= . Taxonomy of electr= onic and miscellaneous products (2006)

I do agree = with the sentiment that complexity is an enemy here and that some sort of 8= 0/20 principle should apply.=C2=A0 I think that ASCII and UniCode show how = one can have a basic functionality alongside a much more sophisticated one = and make good use of both.=C2=A0 We need to create ASCII first.

Thanks,
--Bruce

On Mon, Aug 31, 2020= at 12:17 PM Milan Milenkovic <mil= an@iotsense.com> wrote:
This brings up another point in determining standards strategy - who should= bear the burden of supporting uncommon representations like your temperatu= re example? It is either its creator (by adding a few lines of code to brin= g it to =E2=80=9C80%=E2=80=9D) or everybody else by having to implement a more complicated accommodating =C2=A0standard?

I think simpler specifications that cover common cases are a better wa= y to go.=C2=A0

Sent from Milan's phone.

On Aug 31, 2020, at 18:31, One Data Model Group &= lt;onedm@iotliais= on.org> wrote:

=EF=BB=BF
For the 80% case (e.g. temperature), a non-solution is to use an attri= bute called "temperature".=C2=A0 Every device that deals with tem= perature must understand standard units of temperature, which should be com= municated using attribute names like "kelvins", "degrees_f", or "degrees_c".=C2=A0 The data format cou= ld (should?) be standardized as float, which doesn't make a difference = in JSON but does in CBOR.=C2=A0 What if you want to design a device that us= es int8 between 0 and 100 to represent -40C to 200C?=C2=A0 Then you're not in the 80% any more.

The other 20% should be addressed using the same principle: "brightnes= s" is a useless property name, "lumens" is better in that it= specifies a measurable value, but has the disadvantage that it is absolute= , not relative to the capacity of the device.=C2=A0 A relative attribute would at least need to specify the gamma of the control function= .

Time could be defined similarly, specifying units (e.g., nanoseconds, milli= seconds, seconds) of resolution for intervals and an epoch for date-times.= =C2=A0 Or for the simple 80% a cumbersome but generally-understood RFC 3339= string could be used, hopefully using an "rfc3339-date-time" attribute, not "date-time".

The general principle is that standard units need to be defined in the firs= t place, and then attribute names should refer to the standard, not a unitl= ess name of a feature.

Dave


On Mon, Aug 31, 2020 at 11:22 AM Mila= n Milenkovic <mi= lan@iotsense.com> wrote:
For your example, I was going to suggest the range fraction or % solution b= ut Wouter beat me to it.

More importantly, I think we should be pragmatic and aim for the 80% soluti= on (which, according to the Pareto principle, may require definition of onl= y 20% of use cases ;-).=C2=A0 IMO, luminosity ad brightness are examples of= a relatively skewed minor use case in a specific domain that is consuming disproportionate amounts of time and e= ffort to address and that complicates many a solution for what is at best a= small benefit.=C2=A0 Such things can be tabled, and possibly revisited lat= er, to allow progress on solutions for the most common use cases.

-----Original Message-----
From: One Data Model Group sdf-bounces@ietf.org> On Behalf Of Carsten Bormann<= br>
In today=E2=80=99s OneDM call, Bruce Nordman brought up the issue that, in = the end, we=E2=80=99ll need concrete representations to talk to devices and= use their data.

So if we have one ecosystem that uses 0..100 for describing the brightness = setting for a lamp, another one that uses 0..254 (where 255 means something= complete different), and a third with 0..65535, what do we do?=C2=A0 (And = these might also differ whether they describe a emitted light power level or a perceptive luminous flux level.)=

The underlying problem is that we are abusing data model level description = techniques (in part borrowed from jso= n-schema.org) to describe information models.
That works reasonably well until we start taking these data model level des= criptions at face value.=C2=A0 The fact that some converged model uses a sc= ale based on the L component of Lu=E2=80=99v=E2=80=99 does not mean that ev= erybody has to represent their ecosystem model the same way.


--
Bruce Nordman=
Lawrence Berkeley National La= boratory
nordman.lbl.gov
BNordm= an@LBL.gov
510-486-7089; m: 510-501-7943
m: 510-501-7943
--0000000000009ce38705ae321cb7-- From nobody Mon Aug 31 13:19:12 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD053A194D for ; Mon, 31 Aug 2020 13:19:02 -0700 (PDT) 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 KlZgx29RicMg for ; Mon, 31 Aug 2020 13:18:58 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713A63A1944 for ; Mon, 31 Aug 2020 13:18:58 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BgM3h1V10zyVj; Mon, 31 Aug 2020 22:18:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 31 Aug 2020 22:18:55 +0200 Cc: "asdf@ietf.org" , "t2trg@irtf.org" X-Mao-Original-Outgoing-Id: 620597935.6619591-ef8a1006a92bdfe8319c444c2ec2670e Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> To: One Data Model Group X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 20:19:04 -0000 I think it is already relatively easy to find the right level of = abstraction for information that can be expressed in SI units. =20 (Units can be specified in SDF 1.0.) SenML (RFC 8428) got that right, so I think we can follow that example = in SDF. We did have to make a little bit of a compromise (adding scaling = prefixes in RFC 8798) in areas where the natural units are habitually = scaled (there aren=E2=80=99t many electricity meters indicating J =E2=80=94= it=E2=80=99s always kWh), but even here it should be easy to agree on a = natural unit between domain experts. But the problem remains how the ecosystem specifications can relate to = the converged model if that had to abstract some more. And that=E2=80=99s= where the binding comes in. To make ecosystem experts feel at home, we = probably need to make this rather accessible. For information that is a ratio to a reference value (e.g., a lamp an = undefined metric of which can be set to a value between 0 to 100 %), = SenML has =E2=80=9C/=E2=80=9D (the dimensionless unit). So we would = normally not use percentages (or permille, or ppm, =E2=80=A6), but a = number that is typically clamped between 0 and 1. Of course, most = ecosystems will scale this to get an integer representation, and that is = probably the largest source of variation (*). Also, RFC 8798 is limited to linear scales (scale/offset). For sound = and RF power levels we can cheat with dB. For lighting, the models are = more complicated (which led to gamma and all that). If different = ecosystems use different models here, there may be no straightforward = way to do the conversions. So we have to be prepared to express these = anyway. Gr=C3=BC=C3=9Fe, Carsten (*) And that when it should have been plainly obvious that all IoT = devices should express temperatures as an integer value in centikelvin = (cK), so a 16-bit unsigned value from 0 to 65535 can express most = real-life sensor values (between absolute zero and 382.2 =C2=B0C), and = simply subtracting 27315 and dividing by 100 gives you the value in =C2=B0= C :-) From nobody Mon Aug 31 13:47:34 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940DD3A046E for ; Mon, 31 Aug 2020 13:47:29 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hP-ViQdza1cq for ; Mon, 31 Aug 2020 13:47:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAB13A0486 for ; Mon, 31 Aug 2020 13:47:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 030F3389DB; Mon, 31 Aug 2020 16:26:23 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BCI_AgcZ7L3x; Mon, 31 Aug 2020 16:26:12 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F4D9389D5; Mon, 31 Aug 2020 16:26:12 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56A26600; Mon, 31 Aug 2020 16:47:15 -0400 (EDT) From: Michael Richardson To: "asdf\@ietf.org" , "t2trg\@irtf.org" In-Reply-To: References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 20:47:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > But the problem remains how the ecosystem specifications can relate to > the converged model if that had to abstract some more. And that=E2= =80=99s > where the binding comes in. To make ecosystem experts feel at home, = we > probably need to make this rather accessible. > For information that is a ratio to a reference value (e.g., a lamp an > undefined metric of which can be set to a value between 0 to 100 %), > SenML has =E2=80=9C/=E2=80=9D (the dimensionless unit). So we would= normally not use > percentages (or permille, or ppm, =E2=80=A6), but a number that is ty= pically > clamped between 0 and 1. Of course, most ecosystems will scale this = to > get an integer representation, and that is probably the largest source > of variation (*). So for a lamp, the alternative to "/" is that the brightness be specified in lumens (or maybe candela in some cases). > (*) And that when it should have been plainly obvious that all IoT > devices should express temperatures as an integer value in centikelvin > (cK), so a 16-bit unsigned value from 0 to 65535 can express most > real-life sensor values (between absolute zero and 382.2 =C2=B0C), and > simply subtracting 27315 and dividing by 100 gives you the value in = =C2=B0C > :-) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9NYdMACgkQgItw+93Q 3WV/rgf/UaHE56HTWjpI61txNU3Jq+WaOHWRevcZcn46tCg5xaZS8SoTATSDJT69 0uvc6jL7CBl18nluwQdhfZiwBWDi6ORpLdhBovLeRVK9ZAT24t6ZsuCMg4Rwfs+w wh+lb2kKBgBEZCX4FJDLVMdFmkLi5zulo+sEkl34pPizb5R09b0xBsgyhJsJziXG 5QbAMz9vNuaKWxQDOZiRPypn+cZWuCqXASdvyZKZshXyRep4MgKCeba0+c4W+nlU VOYhsSbybwQ6IS64ORoc7ZsptaofY5D7QeBoxFbAOG9oK0W8Y68J+TjZY8WyT+H4 a1o5ow9bEWyTHTvLwfgOEp27ZMzfyA== =Bozv -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 31 16:23:14 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0603A19A2 for ; Mon, 31 Aug 2020 16:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBv8tMYojlJE for ; Mon, 31 Aug 2020 16:23:11 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1073A1997 for ; Mon, 31 Aug 2020 16:23:10 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BgR8F0g22zyWg; Tue, 1 Sep 2020 01:23:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <8AAE99C9-643A-4FAA-83DB-584D70BA0D4C@sjrb.ca> Date: Tue, 1 Sep 2020 01:23:08 +0200 Cc: One Data Model Group , "asdf@ietf.org" , "t2trg@irtf.org" X-Mao-Original-Outgoing-Id: 620608988.482533-26838d1061ade939c45b52ea3db98b99 Content-Transfer-Encoding: quoted-printable Message-Id: <260958BB-5AB0-489F-A3F8-F874BD66A2CC@tzi.org> References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> <8AAE99C9-643A-4FAA-83DB-584D70BA0D4C@sjrb.ca> To: Clarke Stevens X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 23:23:13 -0000 On 2020-09-01, at 01:16, Clarke Stevens wrote: >=20 > =E2=80=A2 NOTE: Currently, the code to map between = models is pseudo code represented as a comment rather than actual = executable code in a specific language. This choice was made to remain = independent of any programming language. Right. My hope was that maybe we can find an 80 % solution here that is = machine-processable, and leave the other 20 % to some registered = features. Converting between one of the RGBs and CMYK is probably going = to land in the 20 %. Gr=C3=BC=C3=9Fe, Carsten From Clarke.Stevens@sjrb.ca Mon Aug 31 16:17:04 2020 Return-Path: X-Original-To: asdf@ietfa.amsl.com Delivered-To: asdf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ACE3A19C3 for ; Mon, 31 Aug 2020 16:17:04 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sjrb.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 q29v3J0nMskh for ; Mon, 31 Aug 2020 16:17:02 -0700 (PDT) Received: from prdcg4ipta02x-ext.shaw.ca (prdcg4ipta02x-ext.shaw.ca [204.209.208.147]) (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 5BABB3A19C2 for ; Mon, 31 Aug 2020 16:17:02 -0700 (PDT) IronPort-SDR: bY31PbrF5GUHFolDKq4GWitWFNjZj7KwK3hEIcGKBHl6cD8v8XwAS1AnD0G44y1AITbEBh868Q njFgso+NENpg== X-IronPort-AV: E=McAfee;i="6000,8403,9730"; a="273266887" X-IronPort-AV: E=Sophos;i="5.76,376,1592892000"; d="scan'208,217";a="273266887" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BKP0tCXXtFYd6gZLMMhaH4LZSXQAorBUfHw62tNY+Ks3RANHyuie9CqHpCGxXquhsIxI9fkAWYZnGnXWAWiQxleNNxT2atVpgAwwzxJBgZ3j8T2/2hPLX534I4341odKIrg2cAbuOD7pkzkplDR4OAFySU96A4aHhWKU917lg1dZRs3NqNsAVDmfIfeAinAuQosIdE59rA5pkajrI35j+xTaxsGQxnI6a3PluPZPNpg6dUfvYFZ36v5h54JEvlT4cf0jXYGfp5OIfNEtfiENW4RUq/3tppqwvQ9526e/5ILZgdF7cGZBin8YYBzUgm42D5/p8/7a5/c0/3VEm7cmLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LBw4Llqi7Y+1wIOCd+dbu5zoyP5kpfP52oPD8NN1s1Q=; b=Kc7acK3iqSv0YTrguVlnJSoxwrKpJTn0Bw1E2hQfEyK8SITpsYMAR3M6GTuS7Muc8ywh7Vx/iXl1/EK9+1WJMwvIJXOMfn3mX22WUXrgnnp1dpwdxhzhRE1mRdLzsjaeiAWBlWq4HQaYuJ8EyH2N4JD7+qsONu4hoZTEENKxSWcnvQFfHgRqg5MPaoayweHVgNtokEL0g162CaODmsWfQK3nl7dbCNlsVuvTg4ZrDYc/E0mqM1P9seVdDnSYO2PxLaV70cJrrGgmByunXQ/Ib5aSDLNr/AEPrpouxZlbN1n7CNzQQEVZY+iTFqh4v+EBOZAynnS+MZkO4OUkrgnziQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sjrb.ca; dmarc=pass action=none header.from=sjrb.ca; dkim=pass header.d=sjrb.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SJRB.onmicrosoft.com; s=selector1-SJRB-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LBw4Llqi7Y+1wIOCd+dbu5zoyP5kpfP52oPD8NN1s1Q=; b=bBNdBqQN4BoAvdVJw4ubjM0Tzpwa2veiRhYmIv8c9tzCZXAfaDNur7CFRh5Soi8nujGYkO/Lh0bi1vHQbSUhGSU6eYfcHG9x5ftLKKjwwyG8hTWtQtb00HNSw05KfYSmcK0NLGyCaWACe6FngFbTeFoHlLxMjcC4bR+gc36hfck= From: Clarke Stevens To: Bruce Nordman CC: Milan Milenkovic , One Data Model Group , "asdf@ietf.org" , "t2trg@irtf.org" Thread-Topic: [One Data Model Group] [Asdf] Representation issues and protocol bindings Thread-Index: AQHWf6YgYGFYsj36u0iwzqdH3uQDlKlSUhPggAAW2oCAACp8O4AAFSKAgAAxyoA= Date: Mon, 31 Aug 2020 23:16:55 +0000 Message-ID: <8AAE99C9-643A-4FAA-83DB-584D70BA0D4C@sjrb.ca> References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.1) authentication-results: lbl.gov; dkim=none (message not signed) header.d=none;lbl.gov; dmarc=none action=none header.from=sjrb.ca; x-originating-ip: [2601:282:4000:78a0:9da3:978b:17d4:dce4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6112dd78-66e6-4b70-1303-08d84e03f412 x-ms-traffictypediagnostic: CY4PR04MB0903: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T/wUiQ7hAxrr9jxX2BVBW2rmGS8TEsVyZpwvhZagn7sM2KkrvKlTt37UvcNdnIW1grs6CYUPDKMWmdfemfHb6UweHd/4fTEKPlcYa9dLB5vSh3feGPEc51aXJrjrG1PugsiNj/AtS6k+6mJd95UYJhO+7NSrBhp4dVJY8YXDkvGoEE4/05B6RsEwhQepMluk3FgxPMvdFXGVGz/Ii6/PA1aAWKWYWqz2QUhOEOnWo6jUSkEPon/Xzdc+bbD6AD56Q0+HeUATByVwAUtZfOj/0IXBmXJrOkrRDwhrhscv5jSctD5hUL9tTssJN9TbnKFdWfLNB+9E7V5N53AG1YWeibo47oxrTegH6t+CWz2vIA0+JeDOP54VbAatCzPT6uw3XcmL3C2LIaUTv4v3vyTzeA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY1PR04MB2234.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(396003)(39860400002)(136003)(346002)(316002)(8676002)(76116006)(66946007)(66556008)(66476007)(64756008)(83380400001)(8936002)(186003)(66446008)(33656002)(2906002)(83080400001)(71200400001)(54906003)(6506007)(66574015)(53546011)(6916009)(166002)(86362001)(7066003)(5660300002)(6486002)(6512007)(36756003)(478600001)(2616005)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: J0II/nHA6oQUgWUS0jqKqTEJKppgrDczR/FLrZp8lSUvx3fxnpZCxtSG4LE7NmQhHWXNO53eHSlz8XN/+qIuJz28Pekib71pfsfLGpInDkrItOc10wWS3Yjh3rsA0deB36dOKftsOG7+RlhOO1Nh2Z0iI9Su3QIzhzd2CPaVLGTiGHm1MiHAn9L7eDVUil2llkKw+pO9vkXeouRexqg0oaG0LPCokmw7NJnQZO7qjYaPyGzs+5zolShpwAg0LywZwRYlsCSJxxzlCS+jtFUCMq/UTjPUScAvUhTarPGx7G0EAd5tjXIlSyRDUZdaFebJnbtjFqz2XMuH8nhDlxl03rIOmtzWIjCxzoNrXc0IeE4DCLAwLOc4zdezq+XKe6H2t6enP2UDu/TGYCr4fHboKr4TfAkcTVNKFwCJ2E8GBJR8ZolGYou9JP00RgQNu3ilXS/GmCRSeAdrBJF6nhi81/jvZ8SrvO7Qadyu+jZuTneEX9BNaCTy+V06ozkfvcDcm8v5x/ECy8kFFESAWGb6koWoIRjRWu4OYyKnlDviY8bu9NEXWAbuFqW631XkpO2SuWuWiNSwwu2ywr7E3kDwheJ9vHB74NLb4NxxOuqsqTMzZO/D2o1HvpC/i7e01VzMpc8Pl7AT6/Koj09RggMWSM0NY8FOAoftphWuKSbxS4I+9O3a8ugKnXJWsmbgw0SJsbsVDqsJpBBe5XI0zlTzHw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_8AAE99C9643A4FAA83DB584D70BA0D4Csjrbca_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY1PR04MB2234.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6112dd78-66e6-4b70-1303-08d84e03f412 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 23:16:55.8409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b30192e-1388-4ed6-8208-e35dd72ad2ad X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YUICyHyILSWzqjQ3Z+UpYo0995IKkITsKF6xsKfwRQvFQtcr4DW8fggww8NvVn633nZ54ypESGS8IX9UY+b0Dw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB0903 X-OriginatorOrg: sjrb.ca Archived-At: X-Mailman-Approved-At: Mon, 31 Aug 2020 22:42:19 -0700 Subject: Re: [Asdf] [One Data Model Group] Representation issues and protocol bindings X-BeenThere: asdf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 03:14:19 -0000 --_000_8AAE99C9643A4FAA83DB584D70BA0D4Csjrbca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdWdnZXN0IHdlIGNvbnNpZGVyIHRoZSBhcHByb2FjaCB1c2VkIGJ5IE9DRi4NCg0KSGVyZSBp cyB0aGUgZXNzZW5jZS4NCg0KICAqICAgQXMgQnJ1Y2Ugc3VnZ2VzdHMsIE9DRiBjaG9vc2VzIGEg bWluaW1hbCBjYW5vbmljYWwgbW9kZWwuDQogICogICBPQ0YgaG9zdHMgbW9kZWxzIGZyb20gb3Ro ZXIgb3JnYW5pemF0aW9ucyBvbiB0aGUgc2FtZSBkYXRhIHBsYXRmb3JtIGFzIHRoZSBjYW5vbmlj YWwgbW9kZWxzIChPRE0gYWxyZWFkeSBkb2VzIHRoaXMpLg0KICAqICAgT0NGIGhvc3RzIG1hcHBp bmcgcnVsZXMgYmV0d2VlbiB0aGUgdHdvIG1vZGVscyAoY2FsbGVkIOKAnGRlcml2ZWQgbW9kZWxz IiBpbiBPQ0YpDQogICogICBBbGwgb2YgdGhlc2UgbW9kZWxzIGFyZSBtYWNoaW5lIHJlYWRhYmxl DQogICogICBNZXRob2RzIGFyZSBkZWZpbmVkIGZvciBib3RoIGRpcmVjdGlvbnMgb2YgbWFwcGlu ZyAob3RoZXJfb3JnIC0+IE9DRiBhbmQgT0NGIC0+IG90aGVyX29yZykNCiAgKiAgIE1hcHBpbmdz IGFyZSBub3QgcmVxdWlyZWQgdG8gYmUgMSB0byAxLiBGb3IgZXhhbXBsZSB5b3UgY2FuIG1hcCBm cm9tIFJHQiBjb2xvciB0byBDTVlLIGNvbG9yIGluIGJvdGggZGlyZWN0aW9ucyAoc3VwcG9ydHMg aW50ZXJtZWRpYXRlIGNhbGN1bGF0aW9uIHZhbHVlcyBhbmQgY29tcGxleCBmb3JtdWxhcykNCiAg ICAgKiAgIE5PVEU6IEN1cnJlbnRseSwgdGhlIGNvZGUgdG8gbWFwIGJldHdlZW4gbW9kZWxzIGlz IHBzZXVkbyBjb2RlIHJlcHJlc2VudGVkIGFzIGEgY29tbWVudCByYXRoZXIgdGhhbiBhY3R1YWwg ZXhlY3V0YWJsZSBjb2RlIGluIGEgc3BlY2lmaWMgbGFuZ3VhZ2UuIFRoaXMgY2hvaWNlIHdhcyBt YWRlIHRvIHJlbWFpbiBpbmRlcGVuZGVudCBvZiBhbnkgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UuDQoN ClRoaXMgYWxsb3dzIE9DRiB0byBkZWZpbmUgYSDigJxub3J0aCBzdGFy4oCdIGNhbm9uaWNhbCBk YXRhIG1vZGVsIHdoaWxlIGFsbG93aW5nIG90aGVyIG9yZ2FuaXphdGlvbnMgdG8gbWFwIHdoYXRl dmVyIHRoZXkgaGF2ZSB0byB0aGlzIGNhbm9uaWNhbCBtb2RlbCBpbiBib3RoIGRpcmVjdGlvbnMu IElmIG90aGVyIG9yZ2FuaXphdGlvbnMgY2hvb3NlIHRvIG1pZ3JhdGUgdG8gdGhlIOKAnG5vcnRo IHN0YXIs4oCdIHRoZXkgY2FuIGNhbiBkbyBpdCBhdCB0aGVpciBvd24gcGFjZSBhbmQgb24gdGhl aXIgb3duIHRlcm1zLiBDb25jZWl2YWJseSwgT0RNIGNvdWxkIHN1cHBvcnQgZXZvbHZpbmcgbW9k ZWxzIGFuZCBzZXZlcmFsIHZlcnNpb25zIGZyb20gb3RoZXIgb3JnYW5pemF0aW9ucy4gT0RNIGNv dWxkIGFsc28gZ28gYmV5b25kIHdoYXQgT0NGIGRpZCBhbmQgYWN0dWFsbHkgY2hvb3NlIGFuIGlt cGxlbWVudGF0aW9uIGxhbmd1YWdlIGFuZCBjb21wbGV0ZWx5IGF1dG9tYXRlIHRoZSBtYXBwaW5n Lg0KDQpUaGFua3MsDQotQ2xhcmtlDQoNCk9uIEF1ZyAzMSwgMjAyMCwgYXQgMjoxOCBQTSwgQnJ1 Y2UgTm9yZG1hbiA8Ym5vcmRtYW5AbGJsLmdvdjxtYWlsdG86Ym5vcmRtYW5AbGJsLmdvdj4+IHdy b3RlOg0KDQoNCiAgQ0FVVElPTjogVGhpcyBlbWFpbCBpcyBmcm9tIGFuIGV4dGVybmFsIHNvdXJj ZS4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNv Z25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQpJJ20gZ2xh ZCB0aGlzIHRvcGljIGhhcyBjb21lIHVwLiBJIHJlYWxpemUgdGhlIHdvcmsgdG8gZGF0ZSBvbiBT REYgYW5kIHN1Y2ggaXMgYW4gYWJzb2x1dGVseSBlc3NlbnRpYWwgZm91bmRhdGlvbiB0byBpbnRl cm9wZXJhYmlsaXR5LCBidXQgdGhhdCBvdGhlciBzdGFuZGFyZGl6YXRpb24gaXMgYWxzbyBuZWVk ZWQuIEluIHRoZSBsaWdodGluZyBjYXNlLCBDYXJzdGVuIG5vdGVkIG9yaWdpbmFsbHkgdGhhdCBp dCBjYW4gYmUgc3BlY2lmaWVkIHdpdGggcmVzcGVjdCB0byBlbWl0dGVkIGxpZ2h0IG9yIGh1bWFu LXBlcmNlaXZlZCBsaWdodCAod2UgYXJlIG5vbi1saW5lYXIpLCBpdCBjb3VsZCBhbHNvIGJlIHRv IGxpZ2h0IGRlbGl2ZXJlZCB0byBhIHN1cmZhY2Ugb3IgdG8gaW5wdXQgZWxlY3RyaWNhbCBwb3dl ciAtIGFuZCBhbnkgb2YgdGhlc2UgY291bGQgYmUgYWJzb2x1dGUgb3IgcmVsYXRpdmUgdG8gdGhl IG1heGltdW0gYSBzb3VyY2UgY2FuIHByb3ZpZGUuICBBbm90aGVyIGV4YW1wbGUgaXMgZW51bWVy YXRlZCBuYW1lZCBsaWdodCBjb2xvcnMgdGhhdCBjYW4gYmUgc3Bva2VuIHRvIHNtYXJ0IHNwZWFr ZXIgc3lzdGVtcyAoZS5nLiBBbWF6b24gb3IgR29vZ2xlKTsgdGhlc2UgYXJlIHNpbWlsYXIgYnV0 IG5vdCB0aGUgc2FtZSwgbWF5IG5vdCBtYXAgdG8gdGhlIHNhbWUgYWN0dWFsIGNvbG9yLCBhbmQg Y29sb3JzIGFyZSBjdWx0dXJhbGx5IHZhcnlpbmcgaW4gYWRkaXRpb24gdG8gdmFyeWluZyB3aXRo IGxhbmd1YWdlLg0KDQpJIGhhZCBhc3N1bWVkIGZyb20gdGhlIHN0YXJ0IHRoYXQgT0RNIHdvdWxk IGRlZmluZSBhIHJlZmVyZW5jZSBzZW1hbnRpYyBtb2RlbCB0aGF0IGFueSBwcm90b2NvbCBjb3Vs ZCBiZSB0cmFuc2xhdGVkIGludG8sIG9yIG91dCBvZiwgd2hpY2ggbmVjZXNzYXJpbHkgcmVxdWly ZXMgcGlja2luZyBzb21lIGV4aXN0aW5nIG1vZGVsIHRvIHVzZSBkaXJlY3RseSBvciB0byBhZGFw dCwgb3IgY3JlYXRpbmcgYSBuZXcgb25lLiAgRnJvbSB0aGUgT0RNIGNhbGwgdG9kYXkgSSB0YWtl IGl0IHRoYXQgdGhpcyBpcyBhIHRvcGljIHdoaWNoIE9ETSBoYXMgbm90IHlldCBzZXR0bGVkIG9u IGFuIGFwcHJvYWNoIHRvLg0KDQpXaGlsZSBzdGFuZGFyZGl6aW5nIG9uIHRoaW5ncyBsaWtlIHRo ZSBuYW1pbmcgYW5kIG1lYW5pbmcgb2YgaW5kaXZpZHVhbCBlbGVtZW50IGlzIG5lZWRlZCwgaW4g c29tZSBjYXNlcyBpbmZvcm1hdGlvbiBpcyByZXByZXNlbnRlZCBpbiB3YXlzIHdoaWNoIGlzIGp1 c3QgZGlmZmVyZW50LiAgSSBoYXZlIHdvcmtlZCBmb3IgbWFueSB5ZWFycyBvbiB0aGUgY29uY2Vw dCBvZiAncG93ZXIgc3RhdGUnIChhbmQgYWlkZWQgaW4gb3VyIG1vdmUgZnJvbSBhIDIgcG93ZXIg c3RhdGUgd29ybGQgLSBvbi9vZmYgLSB0byBvbmUgd2l0aCAzIC0gb24vc2xlZXAvb2ZmKS4gSW4g c29tZSBjYXNlcywgbW9kZWxzIGNvbWJpbmUgcG93ZXIgc3RhdGUgd2l0aCBhIGZ1bmN0aW9uYWwg c3RhdGUgb2YgZGV2aWNlIChlLmcuIGlmIGEgcHJpbnRlci9NRkQgaXMgcHJpbnRpbmcsIHNjYW5u aW5nLCBuZWl0aGVyLCBldGMuKSBpbnRvIG9uZSBlbnVtZXJhdGlvbi4NCg0KSSBhbSBub3Qgc3Vy ZSBvZiB0aGUgcmlnaHQgbmFtZSBmb3IgdGhpcyB0b3BpYyBhcmVhIC0tICJzZW1hbnRpY3MiIHNl ZW1zIHRvIGNvdmVyIGEgbG90IG1vcmUgdGhhbiB0aGlzIC0tIGFuZCBJIHdpbGwgZGVmZXIgdG8g dGhlIHJlc3Qgb2YgeW91IGFzIHRvIHdoZW4gaXQgc2hvdWxkIGJlIHRha2VuIHVwLiAgVGhhdCBz YWlkLCBJIHRoaW5rIGl0IG5lZWRzIHRvIGJlIG9uIHRoZSBhZ2VuZGEgc29tZWhvdy4gIEkgZG8g dGhpbmsgdGhhdCBJQU5BIGNvdWxkIHBsYXkgYSB1c2VmdWwgcm9sZSBpbiBob3N0aW5nIHNvbWUg c3RhbmRhcmQgY29udGVudCBmb3IgdGhpcyAtIGNlcnRhaW5seSBlbnVtZXJhdGlvbnMgYnV0IGFs c28gb3RoZXIgY29udGVudCAtIHdoZW4gbm8gcXVhbGl0eSBleGlzdGluZyBjb250ZW50IGV4aXN0 cyB0byBwb2ludCB0byBhbmQgdGhlcmUgaXNuJ3QgYSBnb29kIG9wdGlvbiBmb3IgYW5vdGhlciBv cmcuIHRvIHRha2UgaXQgdXAuICBBbiBleGFtcGxlIHRvcGljIHRoYXQgSSB0aGluayBjb3VsZCBi ZSB1c2VmdWxseSBzdGFuZGFyZGl6ZWQgdGhyb3VnaCBJQU5BIGlzIERldmljZSBDbGFzc2lmaWNh dGlvbjoNCiAgIERldmljZSBDbGFzc2lmaWNhdGlvbi4gUmVwb3J0IG9uIFNpbXBsZSBVbml2ZXJz YWwgRGV2aWNlIENsYXNzaWZpY2F0aW9uPGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9vcGVuP2lk PTBCOEI5WFc2QjdwcmxjMHBmV0ROblVsVTVkbWM+ICgyMDE0KSwgSW50ZXJuZXQgRHJhZnQ8aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbm9yZG1hbi1jbGFzc2lmaWNhdGlvbi0wMD4g YW5kIFByZXNlbnRhdGlvbjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYWdlbmRhLzgyL3NsaWRlcy9h cHBzYXdnLTgucGRmPiBmcm9tIElFVEYgODIuIFRheG9ub215PGh0dHBzOi8vZHJpdmUuZ29vZ2xl LmNvbS9vcGVuP2lkPTBCOEI5WFc2QjdwcmxVMHRXZFZoRU5ERTNPRGc+IG9mIGVsZWN0cm9uaWMg YW5kIG1pc2NlbGxhbmVvdXMgcHJvZHVjdHMgKDIwMDYpDQoNCkkgZG8gYWdyZWUgd2l0aCB0aGUg c2VudGltZW50IHRoYXQgY29tcGxleGl0eSBpcyBhbiBlbmVteSBoZXJlIGFuZCB0aGF0IHNvbWUg c29ydCBvZiA4MC8yMCBwcmluY2lwbGUgc2hvdWxkIGFwcGx5LiAgSSB0aGluayB0aGF0IEFTQ0lJ IGFuZCBVbmlDb2RlIHNob3cgaG93IG9uZSBjYW4gaGF2ZSBhIGJhc2ljIGZ1bmN0aW9uYWxpdHkg YWxvbmdzaWRlIGEgbXVjaCBtb3JlIHNvcGhpc3RpY2F0ZWQgb25lIGFuZCBtYWtlIGdvb2QgdXNl IG9mIGJvdGguICBXZSBuZWVkIHRvIGNyZWF0ZSBBU0NJSSBmaXJzdC4NCg0KVGhhbmtzLA0KLS1C cnVjZQ0KDQpPbiBNb24sIEF1ZyAzMSwgMjAyMCBhdCAxMjoxNyBQTSBNaWxhbiBNaWxlbmtvdmlj IDxtaWxhbkBpb3RzZW5zZS5jb208bWFpbHRvOm1pbGFuQGlvdHNlbnNlLmNvbT4+IHdyb3RlOg0K VGhpcyBicmluZ3MgdXAgYW5vdGhlciBwb2ludCBpbiBkZXRlcm1pbmluZyBzdGFuZGFyZHMgc3Ry YXRlZ3kgLSB3aG8gc2hvdWxkIGJlYXIgdGhlIGJ1cmRlbiBvZiBzdXBwb3J0aW5nIHVuY29tbW9u IHJlcHJlc2VudGF0aW9ucyBsaWtlIHlvdXIgdGVtcGVyYXR1cmUgZXhhbXBsZT8gSXQgaXMgZWl0 aGVyIGl0cyBjcmVhdG9yIChieSBhZGRpbmcgYSBmZXcgbGluZXMgb2YgY29kZSB0byBicmluZyBp dCB0byDigJw4MCXigJ0pIG9yIGV2ZXJ5Ym9keSBlbHNlIGJ5IGhhdmluZyB0byBpbXBsZW1lbnQg YSBtb3JlIGNvbXBsaWNhdGVkIGFjY29tbW9kYXRpbmcgIHN0YW5kYXJkPw0KDQpJIHRoaW5rIHNp bXBsZXIgc3BlY2lmaWNhdGlvbnMgdGhhdCBjb3ZlciBjb21tb24gY2FzZXMgYXJlIGEgYmV0dGVy IHdheSB0byBnby4NCg0KU2VudCBmcm9tIE1pbGFuJ3MgcGhvbmUuDQoNCk9uIEF1ZyAzMSwgMjAy MCwgYXQgMTg6MzEsIE9uZSBEYXRhIE1vZGVsIEdyb3VwIDxvbmVkbUBpb3RsaWFpc29uLm9yZzxt YWlsdG86b25lZG1AaW90bGlhaXNvbi5vcmc+PiB3cm90ZToNCg0K77u/DQpGb3IgdGhlIDgwJSBj YXNlIChlLmcuIHRlbXBlcmF0dXJlKSwgYSBub24tc29sdXRpb24gaXMgdG8gdXNlIGFuIGF0dHJp YnV0ZSBjYWxsZWQgInRlbXBlcmF0dXJlIi4gIEV2ZXJ5IGRldmljZSB0aGF0IGRlYWxzIHdpdGgg dGVtcGVyYXR1cmUgbXVzdCB1bmRlcnN0YW5kIHN0YW5kYXJkIHVuaXRzIG9mIHRlbXBlcmF0dXJl LCB3aGljaCBzaG91bGQgYmUgY29tbXVuaWNhdGVkIHVzaW5nIGF0dHJpYnV0ZSBuYW1lcyBsaWtl ICJrZWx2aW5zIiwgImRlZ3JlZXNfZiIsIG9yICJkZWdyZWVzX2MiLiAgVGhlIGRhdGEgZm9ybWF0 IGNvdWxkIChzaG91bGQ/KSBiZSBzdGFuZGFyZGl6ZWQgYXMgZmxvYXQsIHdoaWNoIGRvZXNuJ3Qg bWFrZSBhIGRpZmZlcmVuY2UgaW4gSlNPTiBidXQgZG9lcyBpbiBDQk9SLiAgV2hhdCBpZiB5b3Ug d2FudCB0byBkZXNpZ24gYSBkZXZpY2UgdGhhdCB1c2VzIGludDggYmV0d2VlbiAwIGFuZCAxMDAg dG8gcmVwcmVzZW50IC00MEMgdG8gMjAwQz8gIFRoZW4geW91J3JlIG5vdCBpbiB0aGUgODAlIGFu eSBtb3JlLg0KDQpUaGUgb3RoZXIgMjAlIHNob3VsZCBiZSBhZGRyZXNzZWQgdXNpbmcgdGhlIHNh bWUgcHJpbmNpcGxlOiAiYnJpZ2h0bmVzcyIgaXMgYSB1c2VsZXNzIHByb3BlcnR5IG5hbWUsICJs dW1lbnMiIGlzIGJldHRlciBpbiB0aGF0IGl0IHNwZWNpZmllcyBhIG1lYXN1cmFibGUgdmFsdWUs IGJ1dCBoYXMgdGhlIGRpc2FkdmFudGFnZSB0aGF0IGl0IGlzIGFic29sdXRlLCBub3QgcmVsYXRp dmUgdG8gdGhlIGNhcGFjaXR5IG9mIHRoZSBkZXZpY2UuICBBIHJlbGF0aXZlIGF0dHJpYnV0ZSB3 b3VsZCBhdCBsZWFzdCBuZWVkIHRvIHNwZWNpZnkgdGhlIGdhbW1hIG9mIHRoZSBjb250cm9sIGZ1 bmN0aW9uLg0KDQpUaW1lIGNvdWxkIGJlIGRlZmluZWQgc2ltaWxhcmx5LCBzcGVjaWZ5aW5nIHVu aXRzIChlLmcuLCBuYW5vc2Vjb25kcywgbWlsbGlzZWNvbmRzLCBzZWNvbmRzKSBvZiByZXNvbHV0 aW9uIGZvciBpbnRlcnZhbHMgYW5kIGFuIGVwb2NoIGZvciBkYXRlLXRpbWVzLiAgT3IgZm9yIHRo ZSBzaW1wbGUgODAlIGEgY3VtYmVyc29tZSBidXQgZ2VuZXJhbGx5LXVuZGVyc3Rvb2QgUkZDIDMz Mzkgc3RyaW5nIGNvdWxkIGJlIHVzZWQsIGhvcGVmdWxseSB1c2luZyBhbiAicmZjMzMzOS1kYXRl LXRpbWUiIGF0dHJpYnV0ZSwgbm90ICJkYXRlLXRpbWUiLg0KDQpUaGUgZ2VuZXJhbCBwcmluY2lw bGUgaXMgdGhhdCBzdGFuZGFyZCB1bml0cyBuZWVkIHRvIGJlIGRlZmluZWQgaW4gdGhlIGZpcnN0 IHBsYWNlLCBhbmQgdGhlbiBhdHRyaWJ1dGUgbmFtZXMgc2hvdWxkIHJlZmVyIHRvIHRoZSBzdGFu ZGFyZCwgbm90IGEgdW5pdGxlc3MgbmFtZSBvZiBhIGZlYXR1cmUuDQoNCkRhdmUNCg0KDQpPbiBN b24sIEF1ZyAzMSwgMjAyMCBhdCAxMToyMiBBTSBNaWxhbiBNaWxlbmtvdmljIDxtaWxhbkBpb3Rz ZW5zZS5jb208bWFpbHRvOm1pbGFuQGlvdHNlbnNlLmNvbT4+IHdyb3RlOg0KRm9yIHlvdXIgZXhh bXBsZSwgSSB3YXMgZ29pbmcgdG8gc3VnZ2VzdCB0aGUgcmFuZ2UgZnJhY3Rpb24gb3IgJSBzb2x1 dGlvbiBidXQgV291dGVyIGJlYXQgbWUgdG8gaXQuDQoNCk1vcmUgaW1wb3J0YW50bHksIEkgdGhp bmsgd2Ugc2hvdWxkIGJlIHByYWdtYXRpYyBhbmQgYWltIGZvciB0aGUgODAlIHNvbHV0aW9uICh3 aGljaCwgYWNjb3JkaW5nIHRvIHRoZSBQYXJldG8gcHJpbmNpcGxlLCBtYXkgcmVxdWlyZSBkZWZp bml0aW9uIG9mIG9ubHkgMjAlIG9mIHVzZSBjYXNlcyA7LSkuICBJTU8sIGx1bWlub3NpdHkgYWQg YnJpZ2h0bmVzcyBhcmUgZXhhbXBsZXMgb2YgYSByZWxhdGl2ZWx5IHNrZXdlZCBtaW5vciB1c2Ug Y2FzZSBpbiBhIHNwZWNpZmljIGRvbWFpbiB0aGF0IGlzIGNvbnN1bWluZyBkaXNwcm9wb3J0aW9u YXRlIGFtb3VudHMgb2YgdGltZSBhbmQgZWZmb3J0IHRvIGFkZHJlc3MgYW5kIHRoYXQgY29tcGxp Y2F0ZXMgbWFueSBhIHNvbHV0aW9uIGZvciB3aGF0IGlzIGF0IGJlc3QgYSBzbWFsbCBiZW5lZml0 LiAgU3VjaCB0aGluZ3MgY2FuIGJlIHRhYmxlZCwgYW5kIHBvc3NpYmx5IHJldmlzaXRlZCBsYXRl ciwgdG8gYWxsb3cgcHJvZ3Jlc3Mgb24gc29sdXRpb25zIGZvciB0aGUgbW9zdCBjb21tb24gdXNl IGNhc2VzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJ1Y2UgTm9yZG1h biBhcmdldD0iX2JsYW5rIj5zZGYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2RmLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQoNCkluIHRvZGF54oCZcyBP bmVETSBjYWxsLCBCcnVjZSBOb3JkbWFuIGJyb3VnaHQgdXAgdGhlIGlzc3VlIHRoYXQsIGluIHRo ZSBlbmQsIHdl4oCZbGwgbmVlZCBjb25jcmV0ZSByZXByZXNlbnRhdGlvbnMgdG8gdGFsayB0byBk ZXZpY2VzIGFuZCB1c2UgdGhlaXIgZGF0YS4NCg0KU28gaWYgd2UgaGF2ZSBvbmUgZWNvc3lzdGVt IHRoYXQgdXNlcyAwLi4xMDAgZm9yIGRlc2NyaWJpbmcgdGhlIGJyaWdodG5lc3Mgc2V0dGluZyBm b3IgYSBsYW1wLCBhbm90aGVyIG9uZSB0aGF0IHVzZXMgMC4uMjU0ICh3aGVyZSAyNTUgbWVhbnMg c29tZXRoaW5nIGNvbXBsZXRlIGRpZmZlcmVudCksIGFuZCBhIHRoaXJkIHdpdGggMC4uNjU1MzUs IHdoYXQgZG8gd2UgZG8/ICAoQW5kIHRoZXNlIG1pZ2h0IGFsc28gZGlmZmVyIHdoZXRoZXIgdGhl eSBkZXNjcmliZSBhIGVtaXR0ZWQgbGlnaHQgcG93ZXIgbGV2ZWwgb3IgYSBwZXJjZXB0aXZlIGx1 bWlub3VzIGZsdXggbGV2ZWwuKQ0KDQpUaGUgdW5kZXJseWluZyBwcm9ibGVtIGlzIHRoYXQgd2Ug YXJlIGFidXNpbmcgZGF0YSBtb2RlbCBsZXZlbCBkZXNjcmlwdGlvbiB0ZWNobmlxdWVzIChpbiBw YXJ0IGJvcnJvd2VkIGZyb20ganNvbi1zY2hlbWEub3JnPGh0dHA6Ly9qc29uLXNjaGVtYS5vcmcv PikgdG8gZGVzY3JpYmUgaW5mb3JtYXRpb24gbW9kZWxzLg0KVGhhdCB3b3JrcyByZWFzb25hYmx5 IHdlbGwgdW50aWwgd2Ugc3RhcnQgdGFraW5nIHRoZXNlIGRhdGEgbW9kZWwgbGV2ZWwgZGVzY3Jp cHRpb25zIGF0IGZhY2UgdmFsdWUuICBUaGUgZmFjdCB0aGF0IHNvbWUgY29udmVyZ2VkIG1vZGVs IHVzZXMgYSBzY2FsZSBiYXNlZCBvbiB0aGUgTCBjb21wb25lbnQgb2YgTHXigJl24oCZIGRvZXMg bm90IG1lYW4gdGhhdCBldmVyeWJvZHkgaGFzIHRvIHJlcHJlc2VudCB0aGVpciBlY29zeXN0ZW0g bW9kZWwgdGhlIHNhbWUgd2F5Lg0KDQoNCi0tDQpCcnVjZSBOb3JkbWFuDQpMYXdyZW5jZSBCZXJr ZWxleSBOYXRpb25hbCBMYWJvcmF0b3J5DQpub3JkbWFuLmxibC5nb3Y8aHR0cDovL25vcmRtYW4u bGJsLmdvdi8+DQpCTm9yZG1hbkBMQkwuZ292PG1haWx0bzpCTm9yZG1hbkBMQkwuZ292Pg0KNTEw LTQ4Ni03MDg5OyBtOiA1MTAtNTAxLTc5NDMNCm06IDUxMC01MDEtNzk0Mw0KDQo= --_000_8AAE99C9643A4FAA83DB584D70BA0D4Csjrbca_ Content-Type: text/html; charset="utf-8" Content-ID: <2C80C7EE5EA9314E9A0441767C0C91E1@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgc3VnZ2VzdCB3ZSBjb25zaWRlciB0aGUgYXBw cm9hY2ggdXNlZCBieSBPQ0YuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5IZXJlIGlzIHRoZSBlc3NlbmNlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N Cjx1bCBjbGFzcz0iTWFpbE91dGxpbmUiPg0KPGxpIGNsYXNzPSIiPkFzIEJydWNlIHN1Z2dlc3Rz LCBPQ0YgY2hvb3NlcyBhIG1pbmltYWwgY2Fub25pY2FsIG1vZGVsLjwvbGk+PGxpIGNsYXNzPSIi Pk9DRiBob3N0cyBtb2RlbHMgZnJvbSBvdGhlciBvcmdhbml6YXRpb25zIG9uIHRoZSBzYW1lIGRh dGEgcGxhdGZvcm0gYXMgdGhlIGNhbm9uaWNhbCBtb2RlbHMgKE9ETSBhbHJlYWR5IGRvZXMgdGhp cykuPC9saT48bGkgY2xhc3M9IiI+T0NGIGhvc3RzIG1hcHBpbmcgcnVsZXMgYmV0d2VlbiB0aGUg dHdvIG1vZGVscyAoY2FsbGVkIOKAnGRlcml2ZWQgbW9kZWxzJnF1b3Q7IGluIE9DRik8L2xpPjxs aSBjbGFzcz0iIj5BbGwgb2YgdGhlc2UgbW9kZWxzIGFyZSBtYWNoaW5lIHJlYWRhYmxlPC9saT48 bGkgY2xhc3M9IiI+TWV0aG9kcyBhcmUgZGVmaW5lZCBmb3IgYm90aCBkaXJlY3Rpb25zIG9mIG1h cHBpbmcgKG90aGVyX29yZyAtJmd0OyBPQ0YgYW5kIE9DRiAtJmd0OyBvdGhlcl9vcmcpPC9saT48 bGkgY2xhc3M9IiI+TWFwcGluZ3MgYXJlIG5vdCByZXF1aXJlZCB0byBiZSAxIHRvIDEuIEZvciBl eGFtcGxlIHlvdSBjYW4gbWFwIGZyb20gUkdCIGNvbG9yIHRvIENNWUsgY29sb3IgaW4gYm90aCBk aXJlY3Rpb25zIChzdXBwb3J0cyBpbnRlcm1lZGlhdGUgY2FsY3VsYXRpb24gdmFsdWVzIGFuZCBj b21wbGV4IGZvcm11bGFzKTwvbGk+PHVsIGNsYXNzPSIiPg0KPGxpIGNsYXNzPSIiPk5PVEU6IEN1 cnJlbnRseSwgdGhlIGNvZGUgdG8gbWFwIGJldHdlZW4gbW9kZWxzIGlzIHBzZXVkbyBjb2RlIHJl cHJlc2VudGVkIGFzIGEgY29tbWVudCByYXRoZXIgdGhhbiBhY3R1YWwgZXhlY3V0YWJsZSBjb2Rl IGluIGEgc3BlY2lmaWMgbGFuZ3VhZ2UuIFRoaXMgY2hvaWNlIHdhcyBtYWRlIHRvIHJlbWFpbiBp bmRlcGVuZGVudCBvZiBhbnkgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UuPC9saT48L3VsPg0KPC91bD4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoaXMg YWxsb3dzIE9DRiB0byBkZWZpbmUgYSDigJxub3J0aCBzdGFy4oCdIGNhbm9uaWNhbCBkYXRhIG1v ZGVsIHdoaWxlIGFsbG93aW5nIG90aGVyIG9yZ2FuaXphdGlvbnMgdG8gbWFwIHdoYXRldmVyIHRo ZXkgaGF2ZSB0byB0aGlzIGNhbm9uaWNhbCBtb2RlbCBpbiBib3RoIGRpcmVjdGlvbnMuIElmIG90 aGVyIG9yZ2FuaXphdGlvbnMgY2hvb3NlIHRvIG1pZ3JhdGUgdG8gdGhlIOKAnG5vcnRoIHN0YXIs 4oCdIHRoZXkgY2FuIGNhbiBkbw0KIGl0IGF0IHRoZWlyIG93biBwYWNlIGFuZCBvbiB0aGVpciBv d24gdGVybXMuIENvbmNlaXZhYmx5LCBPRE0gY291bGQgc3VwcG9ydCBldm9sdmluZyBtb2RlbHMg YW5kIHNldmVyYWwgdmVyc2lvbnMgZnJvbSBvdGhlciBvcmdhbml6YXRpb25zLiBPRE0gY291bGQg YWxzbyBnbyBiZXlvbmQgd2hhdCBPQ0YgZGlkIGFuZCBhY3R1YWxseSBjaG9vc2UgYW4gaW1wbGVt ZW50YXRpb24gbGFuZ3VhZ2UgYW5kIGNvbXBsZXRlbHkgYXV0b21hdGUgdGhlIG1hcHBpbmcuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5U aGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1DbGFya2U8L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IEF1ZyAzMSwgMjAyMCwgYXQgMjoxOCBQTSwgQnJ1Y2UgTm9yZG1hbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJub3JkbWFuQGxibC5nb3YiIGNsYXNzPSIiPmJub3JkbWFuQGxibC5nb3Y8L2E+Jmd0OyB3 cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2 IGNsYXNzPSIiPg0KPHAgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgYm9yZGVy OiAxcHggc29saWQgcmdiKDE2MSwgMTA5LCAxMyk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDIzNSwgMTU2KTsiIGNsYXNzPSIiPg0KPGIgc3R5bGU9ImNvbG9yOiByZ2IoMTc3LCAxMzAsIDMz KTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwO0NBVVRJT046PC9iPiZuYnNwO1RoaXMgZW1haWwgaXMg ZnJvbSBhbiBleHRlcm5hbCBzb3VyY2UuIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFj aG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRl bnQgaXMgc2FmZS48L3A+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JJ20g Z2xhZCB0aGlzIHRvcGljIGhhcyBjb21lIHVwLiBJIHJlYWxpemUgdGhlIHdvcmsgdG8gZGF0ZSBv biBTREYgYW5kIHN1Y2ggaXMgYW4gYWJzb2x1dGVseSBlc3NlbnRpYWwgZm91bmRhdGlvbiB0byBp bnRlcm9wZXJhYmlsaXR5LCBidXQgdGhhdCBvdGhlciBzdGFuZGFyZGl6YXRpb24gaXMgYWxzbyBu ZWVkZWQuIEluIHRoZSBsaWdodGluZyBjYXNlLCBDYXJzdGVuIG5vdGVkIG9yaWdpbmFsbHkgdGhh dCBpdCBjYW4gYmUNCiBzcGVjaWZpZWQgd2l0aCByZXNwZWN0IHRvIGVtaXR0ZWQgbGlnaHQgb3Ig aHVtYW4tcGVyY2VpdmVkIGxpZ2h0ICh3ZSBhcmUgbm9uLWxpbmVhciksIGl0IGNvdWxkIGFsc28g YmUgdG8gbGlnaHQgZGVsaXZlcmVkIHRvIGEgc3VyZmFjZSBvciB0byBpbnB1dCBlbGVjdHJpY2Fs IHBvd2VyIC0gYW5kIGFueSBvZiB0aGVzZSBjb3VsZCBiZSBhYnNvbHV0ZSBvciByZWxhdGl2ZSB0 byB0aGUgbWF4aW11bSBhIHNvdXJjZSBjYW4gcHJvdmlkZS4mbmJzcDsgQW5vdGhlcg0KIGV4YW1w bGUgaXMgZW51bWVyYXRlZCBuYW1lZCBsaWdodCBjb2xvcnMgdGhhdCBjYW4gYmUgc3Bva2VuIHRv IHNtYXJ0IHNwZWFrZXIgc3lzdGVtcyAoZS5nLiBBbWF6b24gb3IgR29vZ2xlKTsgdGhlc2UgYXJl IHNpbWlsYXIgYnV0IG5vdCB0aGUgc2FtZSwgbWF5IG5vdCBtYXAgdG8gdGhlIHNhbWUgYWN0dWFs IGNvbG9yLCBhbmQgY29sb3JzIGFyZSBjdWx0dXJhbGx5IHZhcnlpbmcgaW4gYWRkaXRpb24gdG8g dmFyeWluZyB3aXRoIGxhbmd1YWdlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBoYWQgYXNzdW1lZCBmcm9tIHRoZSBzdGFydCB0aGF0 IE9ETSB3b3VsZCBkZWZpbmUgYSByZWZlcmVuY2Ugc2VtYW50aWMgbW9kZWwgdGhhdCBhbnkgcHJv dG9jb2wgY291bGQgYmUgdHJhbnNsYXRlZCBpbnRvLCBvciBvdXQgb2YsIHdoaWNoIG5lY2Vzc2Fy aWx5IHJlcXVpcmVzIHBpY2tpbmcgc29tZSBleGlzdGluZyBtb2RlbCB0byB1c2UgZGlyZWN0bHkg b3IgdG8gYWRhcHQsIG9yIGNyZWF0aW5nIGEgbmV3IG9uZS4mbmJzcDsgRnJvbQ0KIHRoZSBPRE0g Y2FsbCB0b2RheSBJIHRha2UgaXQgdGhhdCB0aGlzIGlzIGEgdG9waWMgd2hpY2ggT0RNIGhhcyBu b3QgeWV0IHNldHRsZWQgb24gYW4gYXBwcm9hY2ggdG8uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaGlsZSBzdGFuZGFyZGl6aW5nIG9u IHRoaW5ncyBsaWtlIHRoZSBuYW1pbmcgYW5kIG1lYW5pbmcgb2YgaW5kaXZpZHVhbCBlbGVtZW50 IGlzIG5lZWRlZCwgaW4gc29tZSBjYXNlcyBpbmZvcm1hdGlvbiBpcyByZXByZXNlbnRlZCBpbiB3 YXlzIHdoaWNoIGlzIGp1c3QgZGlmZmVyZW50LiZuYnNwOyBJIGhhdmUgd29ya2VkIGZvciBtYW55 IHllYXJzIG9uIHRoZSBjb25jZXB0IG9mICdwb3dlciBzdGF0ZScgKGFuZCBhaWRlZCBpbiBvdXIN CiBtb3ZlIGZyb20gYSAyIHBvd2VyIHN0YXRlIHdvcmxkIC0gb24vb2ZmIC0gdG8gb25lIHdpdGgg MyAtIG9uL3NsZWVwL29mZikuIEluIHNvbWUgY2FzZXMsIG1vZGVscyBjb21iaW5lIHBvd2VyIHN0 YXRlIHdpdGggYSBmdW5jdGlvbmFsIHN0YXRlIG9mIGRldmljZSAoZS5nLiBpZiBhIHByaW50ZXIv TUZEIGlzIHByaW50aW5nLCBzY2FubmluZywgbmVpdGhlciwgZXRjLikgaW50byBvbmUgZW51bWVy YXRpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5JIGFtIG5vdCBzdXJlIG9mIHRoZSByaWdodCBuYW1lIGZvciB0aGlzIHRvcGljIGFy ZWEgLS0gJnF1b3Q7c2VtYW50aWNzJnF1b3Q7IHNlZW1zIHRvIGNvdmVyIGEgbG90IG1vcmUgdGhh biB0aGlzIC0tIGFuZCBJIHdpbGwgZGVmZXIgdG8gdGhlIHJlc3Qgb2YgeW91IGFzIHRvIHdoZW4g aXQgc2hvdWxkIGJlIHRha2VuIHVwLiZuYnNwOyBUaGF0IHNhaWQsIEkgdGhpbmsgaXQgbmVlZHMg dG8gYmUgb24gdGhlIGFnZW5kYSBzb21laG93LiZuYnNwOyBJIGRvIHRoaW5rDQogdGhhdCBJQU5B IGNvdWxkIHBsYXkgYSB1c2VmdWwgcm9sZSBpbiBob3N0aW5nIHNvbWUgc3RhbmRhcmQgY29udGVu dCBmb3IgdGhpcyAtIGNlcnRhaW5seSBlbnVtZXJhdGlvbnMgYnV0IGFsc28gb3RoZXIgY29udGVu dCAtIHdoZW4gbm8gcXVhbGl0eSBleGlzdGluZyBjb250ZW50IGV4aXN0cyB0byBwb2ludCB0byBh bmQgdGhlcmUgaXNuJ3QgYSBnb29kIG9wdGlvbiBmb3IgYW5vdGhlciBvcmcuIHRvIHRha2UgaXQg dXAuJm5ic3A7IEFuIGV4YW1wbGUgdG9waWMNCiB0aGF0IEkgdGhpbmsgY291bGQgYmUgdXNlZnVs bHkgc3RhbmRhcmRpemVkIHRocm91Z2ggSUFOQSBpcyBEZXZpY2UgQ2xhc3NpZmljYXRpb246PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5EZXZpY2UgQ2xhc3NpZmljYXRpb248 L2I+LiBSZXBvcnQgb248c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tL29wZW4/aWQ9MEI4QjlYVzZC N3BybGMwcGZXRE5uVWxVNWRtYyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJEb3dubG9hZCB0aGlz IGRvY3VtZW50OyAxLjMgTUIiIGNsYXNzPSIiPlNpbXBsZQ0KIFVuaXZlcnNhbCBEZXZpY2UgQ2xh c3NpZmljYXRpb248L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPigyMDE0KSw8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbm9yZG1hbi1j bGFzc2lmaWNhdGlvbi0wMCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJDbGFzc2lmaWNhdGlvbiIg Y2xhc3M9IiI+SW50ZXJuZXQNCiBEcmFmdDwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+YW5kPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvODIv c2xpZGVzL2FwcHNhd2ctOC5wZGYiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iQ2xhc3NpZmljYXRp b24gUERGIiBjbGFzcz0iIj5QcmVzZW50YXRpb248L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmZyb20NCiBJRVRGIDgyLjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2RyaXZlLmdv b2dsZS5jb20vb3Blbj9pZD0wQjhCOVhXNkI3cHJsVTB0V2RWaEVOREUzT0RnIiB0YXJnZXQ9Il9i bGFuayIgdGl0bGU9InRheG9ub215IHBhcGVyIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5UYXhvbm9t eTwvYj48L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pm9mIGVsZWN0cm9uaWMNCiBhbmQgbWlzY2VsbGFuZW91cyBwcm9kdWN0cyAoMjAwNik8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgZG8g YWdyZWUgd2l0aCB0aGUgc2VudGltZW50IHRoYXQgY29tcGxleGl0eSBpcyBhbiBlbmVteSBoZXJl IGFuZCB0aGF0IHNvbWUgc29ydCBvZiA4MC8yMCBwcmluY2lwbGUgc2hvdWxkIGFwcGx5LiZuYnNw OyBJIHRoaW5rIHRoYXQgQVNDSUkgYW5kIFVuaUNvZGUgc2hvdyBob3cgb25lIGNhbiBoYXZlIGEg YmFzaWMgZnVuY3Rpb25hbGl0eSBhbG9uZ3NpZGUgYSBtdWNoIG1vcmUgc29waGlzdGljYXRlZCBv bmUgYW5kIG1ha2UgZ29vZA0KIHVzZSBvZiBib3RoLiZuYnNwOyBXZSBuZWVkIHRvIGNyZWF0ZSBB U0NJSSBmaXJzdC48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ LS1CcnVjZTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+ T24gTW9uLCBBdWcgMzEsIDIwMjAgYXQgMTI6MTcgUE0gTWlsYW4gTWlsZW5rb3ZpYyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1pbGFuQGlvdHNlbnNlLmNvbSIgY2xhc3M9IiI+bWlsYW5AaW90c2Vuc2Uu Y29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXIt bGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNv bG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2IGRpcj0i YXV0byIgY2xhc3M9IiI+VGhpcyBicmluZ3MgdXAgYW5vdGhlciBwb2ludCBpbiBkZXRlcm1pbmlu ZyBzdGFuZGFyZHMgc3RyYXRlZ3kgLSB3aG8gc2hvdWxkIGJlYXIgdGhlIGJ1cmRlbiBvZiBzdXBw b3J0aW5nIHVuY29tbW9uIHJlcHJlc2VudGF0aW9ucyBsaWtlIHlvdXIgdGVtcGVyYXR1cmUgZXhh bXBsZT8gSXQgaXMgZWl0aGVyIGl0cyBjcmVhdG9yIChieSBhZGRpbmcgYSBmZXcgbGluZXMgb2Yg Y29kZSB0byBicmluZyBpdCB0bw0KIOKAnDgwJeKAnSkgb3IgZXZlcnlib2R5IGVsc2UgYnkgaGF2 aW5nIHRvIGltcGxlbWVudCBhIG1vcmUgY29tcGxpY2F0ZWQgYWNjb21tb2RhdGluZyAmbmJzcDtz dGFuZGFyZD8NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIHRo aW5rIHNpbXBsZXIgc3BlY2lmaWNhdGlvbnMgdGhhdCBjb3ZlciBjb21tb24gY2FzZXMgYXJlIGEg YmV0dGVyIHdheSB0byBnby4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj5TZW50IGZyb20gTWlsYW4ncyBwaG9uZS48L2Rpdj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPk9uIEF1ZyAzMSwgMjAyMCwgYXQgMTg6MzEsIE9uZSBEYXRhIE1vZGVsIEdyb3Vw ICZsdDs8YSBocmVmPSJtYWlsdG86b25lZG1AaW90bGlhaXNvbi5vcmciIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5vbmVkbUBpb3RsaWFpc29uLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj7vu78NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Gb3IgdGhlIDgwJSBjYXNlIChlLmcuIHRl bXBlcmF0dXJlKSwgYSBub24tc29sdXRpb24gaXMgdG8gdXNlIGFuIGF0dHJpYnV0ZSBjYWxsZWQg JnF1b3Q7dGVtcGVyYXR1cmUmcXVvdDsuJm5ic3A7IEV2ZXJ5IGRldmljZSB0aGF0IGRlYWxzIHdp dGggdGVtcGVyYXR1cmUgbXVzdCB1bmRlcnN0YW5kIHN0YW5kYXJkIHVuaXRzIG9mIHRlbXBlcmF0 dXJlLCB3aGljaCBzaG91bGQgYmUgY29tbXVuaWNhdGVkIHVzaW5nIGF0dHJpYnV0ZSBuYW1lcyBs aWtlICZxdW90O2tlbHZpbnMmcXVvdDssDQogJnF1b3Q7ZGVncmVlc19mJnF1b3Q7LCBvciAmcXVv dDtkZWdyZWVzX2MmcXVvdDsuJm5ic3A7IFRoZSBkYXRhIGZvcm1hdCBjb3VsZCAoc2hvdWxkPykg YmUgc3RhbmRhcmRpemVkIGFzIGZsb2F0LCB3aGljaCBkb2Vzbid0IG1ha2UgYSBkaWZmZXJlbmNl IGluIEpTT04gYnV0IGRvZXMgaW4gQ0JPUi4mbmJzcDsgV2hhdCBpZiB5b3Ugd2FudCB0byBkZXNp Z24gYSBkZXZpY2UgdGhhdCB1c2VzIGludDggYmV0d2VlbiAwIGFuZCAxMDAgdG8gcmVwcmVzZW50 IC00MEMgdG8gMjAwQz8mbmJzcDsgVGhlbiB5b3UncmUNCiBub3QgaW4gdGhlIDgwJSBhbnkgbW9y ZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgb3RoZXIgMjAlIHNob3VsZCBiZSBh ZGRyZXNzZWQgdXNpbmcgdGhlIHNhbWUgcHJpbmNpcGxlOiAmcXVvdDticmlnaHRuZXNzJnF1b3Q7 IGlzIGEgdXNlbGVzcyBwcm9wZXJ0eSBuYW1lLCAmcXVvdDtsdW1lbnMmcXVvdDsgaXMgYmV0dGVy IGluIHRoYXQgaXQgc3BlY2lmaWVzIGEgbWVhc3VyYWJsZSB2YWx1ZSwgYnV0IGhhcyB0aGUgZGlz YWR2YW50YWdlIHRoYXQgaXQgaXMgYWJzb2x1dGUsIG5vdCByZWxhdGl2ZSB0byB0aGUgY2FwYWNp dHkgb2YgdGhlIGRldmljZS4mbmJzcDsgQSByZWxhdGl2ZQ0KIGF0dHJpYnV0ZSB3b3VsZCBhdCBs ZWFzdCBuZWVkIHRvIHNwZWNpZnkgdGhlIGdhbW1hIG9mIHRoZSBjb250cm9sIGZ1bmN0aW9uLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRpbWUgY291bGQgYmUgZGVmaW5lZCBzaW1pbGFy bHksIHNwZWNpZnlpbmcgdW5pdHMgKGUuZy4sIG5hbm9zZWNvbmRzLCBtaWxsaXNlY29uZHMsIHNl Y29uZHMpIG9mIHJlc29sdXRpb24gZm9yIGludGVydmFscyBhbmQgYW4gZXBvY2ggZm9yIGRhdGUt dGltZXMuJm5ic3A7IE9yIGZvciB0aGUgc2ltcGxlIDgwJSBhIGN1bWJlcnNvbWUgYnV0IGdlbmVy YWxseS11bmRlcnN0b29kIFJGQyAzMzM5IHN0cmluZyBjb3VsZCBiZSB1c2VkLCBob3BlZnVsbHkg dXNpbmcNCiBhbiAmcXVvdDtyZmMzMzM5LWRhdGUtdGltZSZxdW90OyBhdHRyaWJ1dGUsIG5vdCAm cXVvdDtkYXRlLXRpbWUmcXVvdDsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGdl bmVyYWwgcHJpbmNpcGxlIGlzIHRoYXQgc3RhbmRhcmQgdW5pdHMgbmVlZCB0byBiZSBkZWZpbmVk IGluIHRoZSBmaXJzdCBwbGFjZSwgYW5kIHRoZW4gYXR0cmlidXRlIG5hbWVzIHNob3VsZCByZWZl ciB0byB0aGUgc3RhbmRhcmQsIG5vdCBhIHVuaXRsZXNzIG5hbWUgb2YgYSBmZWF0dXJlLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkRhdmU8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSJnbWFpbF9hdHRyIj5PbiBNb24sIEF1ZyAzMSwgMjAyMCBhdCAxMToyMiBBTSBNaWxhbiBNaWxl bmtvdmljICZsdDs8YSBocmVmPSJtYWlsdG86bWlsYW5AaW90c2Vuc2UuY29tIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+bWlsYW5AaW90c2Vuc2UuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4 IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7 IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4 OyI+DQpGb3IgeW91ciBleGFtcGxlLCBJIHdhcyBnb2luZyB0byBzdWdnZXN0IHRoZSByYW5nZSBm cmFjdGlvbiBvciAlIHNvbHV0aW9uIGJ1dCBXb3V0ZXIgYmVhdCBtZSB0byBpdC48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpNb3JlIGltcG9ydGFudGx5LCBJIHRoaW5rIHdlIHNob3VsZCBi ZSBwcmFnbWF0aWMgYW5kIGFpbSBmb3IgdGhlIDgwJSBzb2x1dGlvbiAod2hpY2gsIGFjY29yZGlu ZyB0byB0aGUgUGFyZXRvIHByaW5jaXBsZSwgbWF5IHJlcXVpcmUgZGVmaW5pdGlvbiBvZiBvbmx5 IDIwJSBvZiB1c2UgY2FzZXMgOy0pLiZuYnNwOyBJTU8sIGx1bWlub3NpdHkgYWQgYnJpZ2h0bmVz cyBhcmUgZXhhbXBsZXMgb2YgYSByZWxhdGl2ZWx5IHNrZXdlZCBtaW5vciB1c2UgY2FzZSBpbg0K IGEgc3BlY2lmaWMgZG9tYWluIHRoYXQgaXMgY29uc3VtaW5nIGRpc3Byb3BvcnRpb25hdGUgYW1v dW50cyBvZiB0aW1lIGFuZCBlZmZvcnQgdG8gYWRkcmVzcyBhbmQgdGhhdCBjb21wbGljYXRlcyBt YW55IGEgc29sdXRpb24gZm9yIHdoYXQgaXMgYXQgYmVzdCBhIHNtYWxsIGJlbmVmaXQuJm5ic3A7 IFN1Y2ggdGhpbmdzIGNhbiBiZSB0YWJsZWQsIGFuZCBwb3NzaWJseSByZXZpc2l0ZWQgbGF0ZXIs IHRvIGFsbG93IHByb2dyZXNzIG9uIHNvbHV0aW9ucyBmb3INCiB0aGUgbW9zdCBjb21tb24gdXNl IGNhc2VzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyIGNsYXNzPSIiPg0KRnJvbTogQnJ1Y2UgTm9yZG1hbjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Ym5vcmRtYW5AbGJsLmdvdiBjbGFzcz0i Ij5hcmdldD0mcXVvdDtfYmxhbmsmcXVvdDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOnNkZi1ib3VuY2Vz QGlldGYub3JnIiBjbGFzcz0iIj5zZGYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFs ZiBPZiBDYXJzdGVuIEJvcm1hbm48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJbiB0b2Rh eeKAmXMgT25lRE0gY2FsbCwgQnJ1Y2UgTm9yZG1hbiBicm91Z2h0IHVwIHRoZSBpc3N1ZSB0aGF0 LCBpbiB0aGUgZW5kLCB3ZeKAmWxsIG5lZWQgY29uY3JldGUgcmVwcmVzZW50YXRpb25zIHRvIHRh bGsgdG8gZGV2aWNlcyBhbmQgdXNlIHRoZWlyIGRhdGEuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KU28gaWYgd2UgaGF2ZSBvbmUgZWNvc3lzdGVtIHRoYXQgdXNlcyAwLi4xMDAgZm9yIGRl c2NyaWJpbmcgdGhlIGJyaWdodG5lc3Mgc2V0dGluZyBmb3IgYSBsYW1wLCBhbm90aGVyIG9uZSB0 aGF0IHVzZXMgMC4uMjU0ICh3aGVyZSAyNTUgbWVhbnMgc29tZXRoaW5nIGNvbXBsZXRlIGRpZmZl cmVudCksIGFuZCBhIHRoaXJkIHdpdGggMC4uNjU1MzUsIHdoYXQgZG8gd2UgZG8/Jm5ic3A7IChB bmQgdGhlc2UgbWlnaHQgYWxzbyBkaWZmZXIgd2hldGhlciB0aGV5DQogZGVzY3JpYmUgYSBlbWl0 dGVkIGxpZ2h0IHBvd2VyIGxldmVsIG9yIGEgcGVyY2VwdGl2ZSBsdW1pbm91cyBmbHV4IGxldmVs Lik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgdW5kZXJseWluZyBwcm9ibGVtIGlz IHRoYXQgd2UgYXJlIGFidXNpbmcgZGF0YSBtb2RlbCBsZXZlbCBkZXNjcmlwdGlvbiB0ZWNobmlx dWVzIChpbiBwYXJ0IGJvcnJvd2VkIGZyb208c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2pzb24tc2NoZW1hLm9yZy8iIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmpzb24tc2NoZW1hLm9yZzwvYT4p IHRvIGRlc2NyaWJlDQogaW5mb3JtYXRpb24gbW9kZWxzLjxiciBjbGFzcz0iIj4NClRoYXQgd29y a3MgcmVhc29uYWJseSB3ZWxsIHVudGlsIHdlIHN0YXJ0IHRha2luZyB0aGVzZSBkYXRhIG1vZGVs IGxldmVsIGRlc2NyaXB0aW9ucyBhdCBmYWNlIHZhbHVlLiZuYnNwOyBUaGUgZmFjdCB0aGF0IHNv bWUgY29udmVyZ2VkIG1vZGVsIHVzZXMgYSBzY2FsZSBiYXNlZCBvbiB0aGUgTCBjb21wb25lbnQg b2YgTHXigJl24oCZIGRvZXMgbm90IG1lYW4gdGhhdCBldmVyeWJvZHkgaGFzIHRvIHJlcHJlc2Vu dCB0aGVpciBlY29zeXN0ZW0gbW9kZWwgdGhlIHNhbWUNCiB3YXkuPGJyIGNsYXNzPSIiPg0KPHUg Y2xhc3M9IiI+PC91PjwvYm5vcmRtYW5AbGJsLmdvdj48L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGVhcj0iYWxsIiBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCi0tPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPg0KPGRp diBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IHNpemU9IjQiIGNsYXNz PSIiPjxiIGNsYXNzPSIiPkJydWNlIE5vcmRtYW48L2I+PC9mb250PjxiciBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDE1Myk7IiBjbGFzcz0iIj5MYXdyZW5jZSBCZXJr ZWxleSBOYXRpb25hbCBMYWJvcmF0b3J5PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDEwMiwgMCk7IiBjbGFzcz0iIj48YSBocmVmPSJo dHRwOi8vbm9yZG1hbi5sYmwuZ292LyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm5vcmRtYW4u bGJsLmdvdjwvYT48L3NwYW4+PC9iPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpCTm9y ZG1hbkBMQkwuZ292IiBjbGFzcz0iIj5CTm9yZG1hbkBMQkwuZ292PC9hPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KNTEwLTQ4Ni03MDg5OyBtOiA1MTAtNTAxLTc5NDM8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPm06IDUxMC01MDEtNzk0MzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_8AAE99C9643A4FAA83DB584D70BA0D4Csjrbca_--