From nobody Tue Jan 5 01:13:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AAE1A1ABE for ; Tue, 5 Jan 2016 01:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jg1E-13P5vNF for ; Tue, 5 Jan 2016 01:13:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BBC1A1AB8 for ; Tue, 5 Jan 2016 01:13:08 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.18]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MHXd2-1aFHDS2oDk-003KNL for ; Tue, 05 Jan 2016 10:13:06 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <568B8922.4010802@gmx.net> Date: Tue, 5 Jan 2016 10:13:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="48RaoMBMVnWcDruSBoVmAd7shD5CcUL1e" X-Provags-ID: V03:K0:9w2vJnXfcLrvGjseBj2C8/MBk+6MfRxHNaSCzip8G400W7MFKkB ydyRbxyl2Ykccy1Ln8+JUPf6laAwjbYlNTFhulMyMkuCPA+oPX+YV191xB/0cuxpGTm3bt7 +hf70bYuqJk8nh9/+J4o+bmQ1YjzWV3ODhon1ugp4LAL9dU+7qp1HPrsYZoU3ULDS03fmf4 AwKhzLtbnrr1+4+uVIb9Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:Abbg0M8dcP0=:bexcMygoj/QJw3hVnwVBYC oN2PDGegsA106vpZvOSarBxktSGpTwPbZ+LVSIFIX+Rv4ixoE0M9oOIztYiOPosEUyQ85suNa ArIIwxGXwc7ucYe27+j5DqUaXKwq7mMQOsdsD9PBawtIlkNhwpUwJzq93Z53xXqTRKjEqQF3Y EpQvXKMjgCMQAVElUhuZv/5I/iytsikVbnMDTeQBXVx3+UFV+iJnBHGHSUYkCwuMBtvLBJdJ8 I7eDfjnAa6OwapIgAXM9ESJc3XHJXqLgovZR+yV3fJiqtZcl2GqVDp7MGSlm3Vy+G2XNeYycw WccwBf4pDFAVC6DBkJH1gqRYfPd7B4AcOXJXYAeKxfPT2Lk1HgqsRV/2k1Y80U+BKLhknWZQi kZijeCsR2sbZnP5GLygAyBteF5J1bNR245QgWzjbcZ6upQshkIqGx4itHZRRBI0p6AkYXA9O2 uNwUeOuSifYJSAJfx0I7vvWtV5QS2XfM8auKuPH6wFDZO9Gw6WOLaySMQIXotVE+MW4NU9RGm VJkJO44N6oCM5p8qfkhzu635ErumCuvHDq1/rmiR3bm3hDlS8nxVpZ3cBWIpgFvbijiCmA4A5 EOMziovpGpds1eV8jSG3I3pwtF964F/sH3dlx033geVg7y3ErFmCLhm48v8uBzAkZmeA67w8C 7aKlAYtBbUrZGfhWidtL5HZaj5e0Rf58xobFhiKDZV3nmF+tW3wXyU5ZdwSLCsncjeL3aQnhC TsR1QAlCZ1WUFx9Uawg0zQd9FiTjAbPkgAR1pnAlXXKsYnQvgHLcTD9j4NM= Archived-At: Subject: [core] IAB Workshop on Semantic Interoperability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 09:13:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --48RaoMBMVnWcDruSBoVmAd7shD5CcUL1e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, based on all the discussions related to COMI, COOL, and CBOR Encoding of Data Modeled with YANG I believe this workshop organized by the IAB could be of interest for you: https://www.iab.org/activities/workshops/iotsi/ Several questions are listed in the call for position papers in an effort to improve interoperability at the data & information model level.= Your input is appreciated! Ciao Hannes --48RaoMBMVnWcDruSBoVmAd7shD5CcUL1e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWi4kiAAoJEGhJURNOOiAtDggH/Rtdk/Msesxgfm3qQBWRG66M QG2l4a25xjZsJwXhs1cijaSk5b1RFmmwapFroA0Jnrzk7kpsPsCfBuKogRycn2dA HbxB+uVd6OYHnu+olX8XCj9ZnZwgjb+VglU+Bol19s7vuwgx3rKGtvTrM49isAs6 RflZ5rLjWAOKDUvAl1D6XO1uok74N7+MINVCh3rryURY3Vx7IP3oBli/+Pe8/ZKI J+0uw6gh437fknNl8IBqaiv04yoWl2kEQwl3JfVszeK9MEAfisPrQBl1is5BPH9Q dYGsbkdVxbCVkyV2noEaCPqul6t4podCzHYjZjB+51Yletuqd2lcPIR2ZK1ff/E= =XTeP -----END PGP SIGNATURE----- --48RaoMBMVnWcDruSBoVmAd7shD5CcUL1e-- From nobody Tue Jan 5 12:16:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9583D1B2D47 for ; Tue, 5 Jan 2016 12:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7hjmCb9sw1Fz for ; Tue, 5 Jan 2016 12:16:12 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 CF9FE1B2C35 for ; Tue, 5 Jan 2016 12:16:11 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 3663BFEE29781; Tue, 5 Jan 2016 20:16:05 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u05KG76a032336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jan 2016 20:16:07 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.17]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 5 Jan 2016 15:16:07 -0500 From: "Carey, Timothy (Timothy)" To: Hannes Tschofenig , "core@ietf.org WG" Thread-Topic: [core] IAB Workshop on Semantic Interoperability Thread-Index: AQHRR/PKJkRFRMkTdkmcXE3QH9tqJZ7tWpag Date: Tue, 5 Jan 2016 20:16:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A558376@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <568B8922.4010802@gmx.net> In-Reply-To: <568B8922.4010802@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] IAB Workshop on Semantic Interoperability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 20:16:13 -0000 SGFubmVzLA0KDQpTb3VuZHMgaW50ZXJlc3RpbmcuIG9uZU0yTSBoYXMgZG9uZSBhIGxvdCBvZiB3 b3JrIGluIHRoZSBhcmVhIG9mIEFic3RyYWN0aW9uIChpbmZvcm1hdGlvbiBtb2RlbGluZykgYW5k IFNlbWFudGljcy4gTWFueSBvZiB0aGUgcXVlc3Rpb25zIHJhaXNlZCBpbiB0aGUgYmFja2dyb3Vu ZCB0aGV5IGFsc28gaGFkIGFuZCBoYXZlIHNvbWUgYW5zd2Vycy4NCg0KVW5mb3J0dW5hdGVseSB0 aGUgd29ya3Nob3AgaXMgZHVyaW5nIHRoZWlyIHRlY2huaWNhbCBwbGVuYXJ5IGluIE1hcmNoIGJ1 dCBtYXliZSB0aGUgSUFCIHNob3VsZCBjb25zaWRlciBhIGxpYWlzb24gd2l0aCBvbmVNMk0gdG8g c2VlIGlmIGFueSBvZiB0aGVpciB3b3JrIGNhbiBoZWxwIGluIGFuc3dlcmluZyB0aGVzZSBxdWVz dGlvbnMgZm9yIHRoZSBJQUIuDQoJDQpQLlMuIC0gSSBkaWQgbGV0IHRoZSB3b3JraW5nIGdyb3Vw IHJlc3BvbnNpYmxlIGZvciBBYnN0cmFjdGlvbiBhbmQgU2VtYW50aWNzIGluIG9uZU0yTSBrbm93 IGFib3V0IHRoZSB3b3Jrc2hvcCBidXQgYWdhaW4gaXRzIGR1cmluZyB0aGVpciBwbGVuYXJ5Li4u Oi0vDQoNCg0KQlIsDQpUaW0gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBI YW5uZXMgVHNjaG9mZW5pZyBbbWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXRdIA0KU2Vu dDogVHVlc2RheSwgSmFudWFyeSAwNSwgMjAxNiAzOjEzIEFNDQpUbzogY29yZUBpZXRmLm9yZyBX Rw0KU3ViamVjdDogW2NvcmVdIElBQiBXb3Jrc2hvcCBvbiBTZW1hbnRpYyBJbnRlcm9wZXJhYmls aXR5DQoNCkhpIGFsbCwNCg0KYmFzZWQgb24gYWxsIHRoZSBkaXNjdXNzaW9ucyByZWxhdGVkIHRv IENPTUksIENPT0wsIGFuZCBDQk9SIEVuY29kaW5nIG9mIERhdGEgTW9kZWxlZCB3aXRoIFlBTkcg SSBiZWxpZXZlIHRoaXMgd29ya3Nob3Agb3JnYW5pemVkIGJ5IHRoZSBJQUIgY291bGQgYmUgb2Yg aW50ZXJlc3QgZm9yIHlvdToNCmh0dHBzOi8vd3d3LmlhYi5vcmcvYWN0aXZpdGllcy93b3Jrc2hv cHMvaW90c2kvDQoNClNldmVyYWwgcXVlc3Rpb25zIGFyZSBsaXN0ZWQgaW4gdGhlIGNhbGwgZm9y IHBvc2l0aW9uIHBhcGVycyBpbiBhbiBlZmZvcnQgdG8gaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5 IGF0IHRoZSBkYXRhICYgaW5mb3JtYXRpb24gbW9kZWwgbGV2ZWwuDQoNCllvdXIgaW5wdXQgaXMg YXBwcmVjaWF0ZWQhDQoNCkNpYW8NCkhhbm5lcw0KDQo= From nobody Tue Jan 5 12:20:06 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40781B2D6F for ; Tue, 5 Jan 2016 12:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tj8cQhVvU6WQ for ; Tue, 5 Jan 2016 12:20:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8DF1B2D6D for ; Tue, 5 Jan 2016 12:20:02 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.18]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lq9Ma-1ZluEW1ODI-00dk4p; Tue, 05 Jan 2016 21:19:56 +0100 To: "Carey, Timothy (Timothy)" , "core@ietf.org WG" References: <568B8922.4010802@gmx.net> <9966516C6EB5FC4381E05BF80AA55F77012A558376@US70UWXCHMBA05.zam.alcatel-lucent.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <568C256A.1040700@gmx.net> Date: Tue, 5 Jan 2016 21:19:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A558376@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cEtJXekj9BQKs7tb7740J3tQ6XsIhJ0a7" X-Provags-ID: V03:K0:5Ajse4Pfit2xHHj4LeSeIH1EZDwZ5+CDes8Lfr2N6M4izuMB8MZ pXT3t4IUpCg7GM3zXlJ84IGvKkH4a6M9/XS7hkwILhPg2Y/pzzJBdI1g4tRpNIIFeGBv3rF Yfg9qyQgVpp1zkHBTkKjBMej6dOp14B7Qfrpfzlio0gLRZ57CrP8vHTEfcTRtirLFL5BtJo KMpzumZtn/Xf/zeve3a5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:KIbMmIOQTHg=:pLqvHC4zZRHI5IOnBl5xuv SbbxE9Um6hNNMvVAnUD8SJiU89qpqZ+uqj3RMOOht7CPoN/iRCZ9M6gGMPBQ3WDMejrEGd4cJ hP08MCK4+uwpbqPRI3SsJlOwMd2e4TawiD8IeTyEMSyeYFSsMRzY4ixiWDyxKL8MBICwCbRC2 K3lUmjAMObqpr85sliM5sw2+nnLX8QE/BOimL19t7IEgGGT4d+rJ4cre18AOoBHh2b1C9rfEK 3eF5saxUvLboUs1fs2KUCP/o9eyCE0Y6vFpZIN5s3hK9u/o5Jnnq6JEV9WotAiHvAiLJoMpzK 8rlkP498jafiQmnX4QpeCAtiMcsPHubKC+mg59mxgxN2tfhO7kix8+lH8z7gxuI+bY5BSgtab l1OgJTOGpx3kS9/pG0wNMJ+8pfBGJaevTNEA4CMi2wSLjfcdzv4lfNOU8KbBmo7U2SzXHGBEO oR9H45lwqLyPUuAoJc6KYySSSwM9MbLM9Jy/6x1wc4jXPrA7d035ULOTVVMZjej7b4QZDeDjX T0ntU26VpORgm7otUP0TX8pyjdv6kCmPzkjHErrher0dmu4kQwRuVFX2+8C5E1tHMqP2uzLnh 7APXSHSzHoetoOUJ9+uacVIpGjOtEwpQp6hfdmrX3LSeAvR1YF3ovU5bPkGYq/ljisQJ/K9i9 JC1QrlGv6STDaKnPw9ozywP/uJ/Jo3pfuZMG6nHnYcCODa5ZOOozJkk90w/fPvqxWIzAivkM8 hpghx3Lq/hVfMI6/lzAekWLK28hGQ6mGShH2RtzW6utNBemo1A8Ti7Nu/Ms= Archived-At: Subject: Re: [core] IAB Workshop on Semantic Interoperability X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 20:20:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cEtJXekj9BQKs7tb7740J3tQ6XsIhJ0a7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for letting us know about their work. Please drop them a note about the workshop! Ciao Hannes PS: I will forward your note about the liaison to the relevant IAB folks.= On 01/05/2016 09:16 PM, Carey, Timothy (Timothy) wrote: > Hannes, >=20 > Sounds interesting. oneM2M has done a lot of work in the area of Abstra= ction (information modeling) and Semantics. Many of the questions raised = in the background they also had and have some answers. >=20 > Unfortunately the workshop is during their technical plenary in March b= ut maybe the IAB should consider a liaison with oneM2M to see if any of t= heir work can help in answering these questions for the IAB. > =09 > P.S. - I did let the working group responsible for Abstraction and Sema= ntics in oneM2M know about the workshop but again its during their plenar= y...:-/ >=20 >=20 > BR, > Tim=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Tuesday, January 05, 2016 3:13 AM > To: core@ietf.org WG > Subject: [core] IAB Workshop on Semantic Interoperability >=20 > Hi all, >=20 > based on all the discussions related to COMI, COOL, and CBOR Encoding o= f Data Modeled with YANG I believe this workshop organized by the IAB cou= ld be of interest for you: > https://www.iab.org/activities/workshops/iotsi/ >=20 > Several questions are listed in the call for position papers in an effo= rt to improve interoperability at the data & information model level. >=20 > Your input is appreciated! >=20 > Ciao > Hannes >=20 --cEtJXekj9BQKs7tb7740J3tQ6XsIhJ0a7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWjCVrAAoJEGhJURNOOiAtzZUIAJ6qwnADA9uAJkvEktbd4gwT 988PNNjMyiUFdAlIhol3tooXhpHlqCi7BeYNF74kpDvn9FsyLVUk+Cl5oBiX0EnW JOYhfGqxQHxXY0W8sat6A9y54c2bVA+n2lnPNYjw5gtchkFEoZZhkwrXabXEsNfs hEBFC+ra2DdpKCOF9UAx5bm0/XqqHBRM9st15MkVI9t7GKLMDJEi3UlHLrcFAzrk fVJmPfkcVnCheGc9VKfBf1tcgO53m+Iik2cNKWmHN6evZPsVetoh332rLA/XUxcC uYqnz6jYdYxKQrzeIxvlkcv0viKvr/2OCcjDrIqOxHsRsb9X5uISjhoKNh2MHIc= =j0fJ -----END PGP SIGNATURE----- --cEtJXekj9BQKs7tb7740J3tQ6XsIhJ0a7-- From nobody Thu Jan 7 19:58:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C064D1ACD1E for ; Thu, 7 Jan 2016 19:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 DHsOIf8bf76P for ; Thu, 7 Jan 2016 19:58:04 -0800 (PST) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 392151ACD1D for ; Thu, 7 Jan 2016 19:58:03 -0800 (PST) Received: by mail-io0-x243.google.com with SMTP id k127so36946442iok.1 for ; Thu, 07 Jan 2016 19:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ssn.edu.in; s=ssn; h=mime-version:date:message-id:subject:from:to:content-type; bh=jZTPJW6gwT9dt07jMh/buGOktdBH7F0uAROBQKAL8Tc=; b=g2L1oOth4yk74MwoT+X+IVCEdi4Hk8kqkF5Ai4fNPUaaeRXmiKaELlz/Uu9XhNLmBL 9YzSoOgm7wNSx3oCQtLipIKfB+LgH1keS2Y803CyggQY9MEzCwQKXgAFENxLRPmf9huH rPs3/iFy/gmSx4lIgEYEdPndP8R9YCsUkbi/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jZTPJW6gwT9dt07jMh/buGOktdBH7F0uAROBQKAL8Tc=; b=BFZgTz9rKw6UkJ58KW9NJ5RCGxviIodVLprnQ/yIMcPApSLuR7lXTTZZ1noOOJgJot Hjy1OQGSirBn2a+yu8uRUCds/b3cR/rlcacDkKH8ryeiMjZ1L1NbSX7GFWI2R1oHTBpf JfgZpLFVgDIZMbciMPMz+mPzjCn/7rIJtam1G0AlXea1EJAzedRYc/RRMK3skkLF5cH2 uaCqjYutmps4J+IDdeGeYSiTQU4SOIwd0QgGFnfrqVjoR99cSPJ+cy9DNph3PDGCFK1p Q2bdcWNmXVjn4yZiZauzS7UTTbdhQzMz/pTHVbQEy8knZRX2qUZdM9DW3XzSrYOxnJZV 6vIw== X-Gm-Message-State: ALoCoQleBc6JnFc1EcnS2f9Xvt2ab5R9Xxa9vjCu+s/MkYRr0Y7baIIx5bgFuwbMkkkj3QpjafBgEMr6yjaSGSF6CfuM7PgLvuMlmiHfomNUtrAZEFDWpeFMbSAik6u8cJg57riNh8spnxwtgw/61zWhQJ6HSGmwcg== MIME-Version: 1.0 X-Received: by 10.107.128.206 with SMTP id k75mr49950948ioi.76.1452225483134; Thu, 07 Jan 2016 19:58:03 -0800 (PST) Received: by 10.79.13.147 with HTTP; Thu, 7 Jan 2016 19:58:03 -0800 (PST) Date: Fri, 8 Jan 2016 09:28:03 +0530 Message-ID: From: "R.Vinob chander" To: "core@ietf.org" Content-Type: multipart/alternative; boundary=001a113f99300e63f60528ca986d Archived-At: Subject: [core] message correlation on CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 03:58:06 -0000 --001a113f99300e63f60528ca986d Content-Type: text/plain; charset=UTF-8 Hi All, sec. 4.4 of RFC 7252 specifies The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME I think the sentence is incorrect and should b, The same Message ID MUST NOT be reused (in communicating with the same endpoint) *beyond* the EXCHANGE_LIFETIME/NON_LIFETIME Regards, -- R. Vinob chander, B.E., M.E., (Ph.D) Assistant Professor, Department of IT SSN College of Engineering, Old Mahabalipuram Road Kalavakkam - 603 110 Tamil Nadu, India www.ssn.edu.in Phone: +9144-27469700 , +91 44 27474844/45/46 Extn: 370 Mob: +91-9566101580 -- ::DISCLAIMER:: --------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of SSN Institutions (SSN) or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of SSN is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. --------------------------------------------------------------------- Header of this mail should have a valid DKIM signature for the domain ssn.edu.in --001a113f99300e63f60528ca986d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

=C2=A0 sec. 4.4 of RFC 7252 spe= cifies=C2=A0
<= /div>
=C2=A0=C2=A0The same Message ID MUST NOT be reused (in communicating wi= th the
=09 =09 =09
=C2=A0 =C2=A0same= endpoint) within the EXCHANGE_LIFETIME=C2=A0

=C2=A0 I think the sentence is incorrect and should b,

=C2=A0=C2=A0The = same Message ID MUST NOT be reused (in communicating with the
<= div>=C2=A0 =C2=A0same en= dpoint) beyond the EXCHANGE_LIFETIME/NON_LIFETIME
<= span style=3D"font-family:Courier;font-size:10pt">
Regards,
--
R. Vinob chander, B.E., M.E., (Ph.D)
Assistant Professor, Department of IT
SSN College of Engineering,
Old Mahabalipuram Road
Kalavakkam - 603 110
Tamil Nadu, India

Phone: +9144-27469700 ,=C2=A0= +91 44 27474844/45/46
Extn: 370
Mob: +91-9566101580

::DISCLAIMER:: 
-------------------------------------=
--------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
-----------------------------------------------------------------=
----
Header of this mail should have a valid DKIM signature for the doma=
in ssn.edu.in
<=
/font>
--001a113f99300e63f60528ca986d-- From nobody Fri Jan 8 02:15:57 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399581AD05D for ; Fri, 8 Jan 2016 02:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 itJjoTKRmYDx for ; Fri, 8 Jan 2016 02:15:53 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 DE7211ACF55 for ; Fri, 8 Jan 2016 02:15:52 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id d17so6332218lfb.1 for ; Fri, 08 Jan 2016 02:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H8Qitf1H4gdm50kHig8yT9xzy2dOnwhMqMCJMBhK73k=; b=sj/YuMtXMYC1ykVj3Cw7Xmzoqth0tRwxQwZ9YG8P2UOll8f/OQxJqgfPogNrSwlwMH FRDrG014nNzTsMkP1/lZrnT3W9nx71tlZt0FAINOEgcJHWAa+2o6TMbsqkM22EXzYwcL QAsVYFTXTRqzt22zK/6tPxr5k7RxMxSWkjDOnWZBY93F/c2YUPtU9surfQJL76ZLjLBA jaGhtQ3tZejZkoUIRGxhIjPT8dNhB0y/fAqDavO17zcthHIgpAdEJ2Jt3E83rjo0sAqj +6Wii3JZgg/MdQf6km4IN+WjvMSe8AJvNBj5USkwTJxBbXD9lB3NCdwG9qmtnYFHxtN9 VaPg== MIME-Version: 1.0 X-Received: by 10.25.29.202 with SMTP id d193mr32608660lfd.55.1452248151150; Fri, 08 Jan 2016 02:15:51 -0800 (PST) Sender: robert.cragie@gmail.com Received: by 10.25.143.68 with HTTP; Fri, 8 Jan 2016 02:15:51 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 10:15:51 +0000 X-Google-Sender-Auth: XL0KtyCeMjyb7ia6oSyUpbbkoJ8 Message-ID: From: Robert Cragie To: "R.Vinob chander" Content-Type: multipart/alternative; boundary=001a114013a82cdb480528cfdf93 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] message correlation on CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:15:56 -0000 --001a114013a82cdb480528cfdf93 Content-Type: text/plain; charset=UTF-8 I think it is correct as written - the same ID must not be used within EXCHANGE_LIFETIME. You can add NON_LIFETIME as well. The message ID certainly can be reused beyond those lifetimes as the occurrence of the message ID for acknowledgement or duplication detection is no longer expected. Robert On 8 January 2016 at 03:58, R.Vinob chander wrote: > Hi All, > > sec. 4.4 of RFC 7252 specifies > > The same Message ID MUST NOT be reused (in communicating with the > same endpoint) within the EXCHANGE_LIFETIME > > I think the sentence is incorrect and should b, > > The same Message ID MUST NOT be reused (in communicating with the > same endpoint) *beyond* the EXCHANGE_LIFETIME/NON_LIFETIME > > Regards, > -- > R. Vinob chander, B.E., M.E., (Ph.D) > Assistant Professor, Department of IT > SSN College of Engineering, > Old Mahabalipuram Road > Kalavakkam - 603 110 > Tamil Nadu, India > www.ssn.edu.in > > Phone: +9144-27469700 , +91 44 27474844/45/46 > Extn: 370 > Mob: +91-9566101580 > > ::DISCLAIMER:: > > --------------------------------------------------------------------- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. Views or opinions, if any, > presented in this email are solely those of the author and may not > necessarily reflect the views or opinions of SSN Institutions (SSN) or its > affiliates. Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message without the > prior written consent of authorized representative of SSN is strictly > prohibited. If you have received this email in error please delete it and > notify the sender immediately. > --------------------------------------------------------------------- > Header of this mail should have a valid DKIM signature for the domain ssn.edu.in > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a114013a82cdb480528cfdf93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it is correct as written - the same ID must not be= used within EXCHANGE_LIFETIME. You can add NON_LIFETIME as well. The messa= ge ID certainly can be reused beyond those lifetimes as the occurrence of t= he message ID for acknowledgement or duplication detection is no longer exp= ected.

Robert

=
On 8 January 2016 at 03:58, R.Vinob chander <vinobchanderr@ssn.edu.in> wrote:
Hi All,

=C2=A0 sec. 4.4 of R= FC 7252 specifies=C2=A0

=C2=A0=C2=A0The same Message ID MUST NOT be reused (in communicating with the<= /div> =09 =09 =09
=C2=A0 =C2=A0same= endpoint) within the EXCHANGE_LIFETIME=C2=A0

=C2=A0 I think the sentence is incorrect and should b,

=C2=A0=C2=A0The = same Message ID MUST NOT be reused (in communicating with the
<= div>=C2=A0 =C2=A0same en= dpoint) beyond the EXCHANGE_LIFETIME/NON_LIFETIME
<= span style=3D"font-family:Courier;font-size:10pt">
Regards,
--
R. Vinob chan= der, B.E., M.E., (Ph.D)
Assistant Profe= ssor, Department of IT
SSN College of Engineering,
Old Mahabalipuram Road
Kalavakkam - 603 110
Tamil Nadu, I= ndia

Phone: +9144-27469700 ,=C2=A0+91 44 27474844/45/46
Extn: 370

::DISCLAIMER:: 
------------------------------------------=
---------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
---------------------------------------------------------------------
He=
ader of this mail should have a valid DKIM signature for the domain ssn.edu.in

_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core

--001a114013a82cdb480528cfdf93-- From nobody Fri Jan 8 07:37:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416571A8A79 for ; Fri, 8 Jan 2016 07:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 oTUJkSGAcffI for ; Fri, 8 Jan 2016 07:36:58 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 6C4201A8A77 for ; Fri, 8 Jan 2016 07:36:58 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 1so242596449ion.1 for ; Fri, 08 Jan 2016 07:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ssn.edu.in; s=ssn; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O+HWgoSWIgGzNtyVtMA7A0M1ro1mhhs5mUwTbbX5cMs=; b=o0+4vEQ52DMjhXiKacO0AGII0rcJoZngGfMkMtpx1zG41F0lNdNLnhiR9E4HXXOR6L HhhT05rbQPDLS6MUaPmZ+duJE0Y4mWZQeW+pZ5ORGmQ0QNnVBv258e8asnqW1ToHGiGY qzxfeamjDziRCU0Ls9y/Z3JOWB3ZDo9i/mUgA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O+HWgoSWIgGzNtyVtMA7A0M1ro1mhhs5mUwTbbX5cMs=; b=MzSjipoMppYNL8431ycS6WwhdVX15K/qyezoFVwqWnNenbA8gwN7O4z6BFlVS1PAA7 hCJ+pgZTTDKny0+96tgZtA5Vqqs1QyQpIlJiRUvVXn62etHUMSHbvY4ezJKhQ4yD6KcZ Mo4xYAbVTfJdfHeuyV3H5XgyNs07bvRO+mmj7qBNGWzPM/NJLkaPD9FDicGnxktRblq1 reKNxKVAxfdJ+xUL6xx0L1jXiy/k8QmRk0/Jk1rG7xgLcNvvXDbohr97Nwep4D3o2NU5 heRPyU4amLGeXa9sXxjSd6MQPpP7eAk1EgfVuDF3MeFfW5Um37jkK1NuodXl2W2nY5ff nkIA== X-Gm-Message-State: ALoCoQnwF6NEFAgYr6E026qIM+AulAh5mny6jm8T8hi6w7IeC4QPPvmNlzTrdqs6ZBKQp0XuzHWQZ+ELJP+DB/3UeSeNDuHI6tO7mghQ/MEoRKHQceEmUXV6E67hl0UQo3T0RT+ONl/D0A8ZkMp+3qj2I0b0320V+A== MIME-Version: 1.0 X-Received: by 10.107.3.71 with SMTP id 68mr59595543iod.48.1452267417544; Fri, 08 Jan 2016 07:36:57 -0800 (PST) Received: by 10.79.13.147 with HTTP; Fri, 8 Jan 2016 07:36:57 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 21:06:57 +0530 Message-ID: From: "R.Vinob chander" To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=001a113eb35c8ac36f0528d45bda Archived-At: Cc: "core@ietf.org" Subject: Re: [core] message correlation on CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:37:01 -0000 --001a113eb35c8ac36f0528d45bda Content-Type: text/plain; charset=UTF-8 thank u... u r right.....but the a receiver may get multiple copies of the same message if the ACK is lost in transit..(sec. 4.5). So in such cases the same message ID is used within the EXCHANGE_LIFETIME. Hence i think probably the sentence should be "The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the first timeout for CON and MAX_LATENCY for NON" 4.4. Message Correlation The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME 4.5. Message Deduplication A recipient might receive the same Confirmable message (as indicated by the Message ID and source endpoint) multiple times within the EXCHANGE_LIFETIME 4.8.2. NON_LIFETIME is the time from sending a Non-confirmable message to the time its Message ID can be safely reused. *If multiple transmission of a NON message is not used, its value is MAX_LATENCY, or 100 seconds*. However, *a CoAP sender might send a NON message multiple times*, in particular for multicast applications. While the period of reuse is not bounded by the specification, an expectation of reliable detection of duplication at the receiver is on the timescales of MAX_TRANSMIT_SPAN. Therefore, for this purpose, it is safer to use the value: MAX_TRANSMIT_SPAN + MAX_LATENCY please clarify.. On Fri, Jan 8, 2016 at 3:45 PM, Robert Cragie wrote: > I think it is correct as written - the same ID must not be used within > EXCHANGE_LIFETIME. You can add NON_LIFETIME as well. The message ID > certainly can be reused beyond those lifetimes as the occurrence of the > message ID for acknowledgement or duplication detection is no longer > expected. > > Robert > > On 8 January 2016 at 03:58, R.Vinob chander > wrote: > >> Hi All, >> >> sec. 4.4 of RFC 7252 specifies >> >> The same Message ID MUST NOT be reused (in communicating with the >> same endpoint) within the EXCHANGE_LIFETIME >> >> I think the sentence is incorrect and should b, >> >> The same Message ID MUST NOT be reused (in communicating with the >> same endpoint) *beyond* the EXCHANGE_LIFETIME/NON_LIFETIME >> >> Regards, >> -- >> R. Vinob chander, B.E., M.E., (Ph.D) >> Assistant Professor, Department of IT >> SSN College of Engineering, >> Old Mahabalipuram Road >> Kalavakkam - 603 110 >> Tamil Nadu, India >> www.ssn.edu.in >> >> Phone: +9144-27469700 , +91 44 27474844/45/46 >> Extn: 370 >> Mob: +91-9566101580 >> >> ::DISCLAIMER:: >> >> --------------------------------------------------------------------- >> The contents of this e-mail and any attachment(s) are confidential and >> intended for the named recipient(s) only. Views or opinions, if any, >> presented in this email are solely those of the author and may not >> necessarily reflect the views or opinions of SSN Institutions (SSN) or its >> affiliates. Any form of reproduction, dissemination, copying, disclosure, >> modification, distribution and / or publication of this message without the >> prior written consent of authorized representative of SSN is strictly >> prohibited. If you have received this email in error please delete it and >> notify the sender immediately. >> --------------------------------------------------------------------- >> Header of this mail should have a valid DKIM signature for the domain ssn.edu.in >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > -- R. Vinob chander, B.E., M.E., (Ph.D) Assistant Professor, Department of IT SSN College of Engineering, Old Mahabalipuram Road Kalavakkam - 603 110 Tamil Nadu, India www.ssn.edu.in Phone: +9144-27469700 , +91 44 27474844/45/46 Extn: 370 Mob: +91-9566101580 -- ::DISCLAIMER:: --------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of SSN Institutions (SSN) or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of SSN is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. --------------------------------------------------------------------- Header of this mail should have a valid DKIM signature for the domain ssn.edu.in --001a113eb35c8ac36f0528d45bda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=09 =09 =09 
thank u... u r righ=
t.....but the a receiver may get multiple copies of the same message if the=
 ACK is lost in transit..(sec. 4.5). So in such cases the same message ID i=
s used within the EXCHANGE_LIFETIME.
Hence i think probably the sentence should be  "The same Message ID MUST NO=
T be reused (in communicating with the same endpoint) within the first timeout for CON and M=
AX_LATENCY for NON"  						
<=
pre>4=
.4.  Message Corr=
elation
The same Message ID MUS= T NOT be reused (in communicating with the
   same endpoint) within the EXCHANGE_LIFETIM=
E

<=
/span>
4.5.  Message Deduplication

   A recipien=
t might receive the same Confirmable message (as indicated
   by the Message ID and source endpoint) multiple times within the
   EXCHANGE_LIFETIME=20


4.8.2.=
 		
NON_LIFETIME =
is the time from sending a Non-confirmable message to
   the time its Message ID can be safely reused.  If multiple
   transmission of a NON message is not used, its value is
   MAX_LATENCY, or 100 seconds.  However, a CoAP sender might send a
   NON message multiple times, in particular for multicast
   applications.  While the period of reuse is not bounded by the
   specification, an expectation of reliable detection of duplication
   at the receiver is on the timescales of MAX_TRANSMIT_SPAN.
   Therefore, for this purpose, it is safer to use the value:
<=
pre>      MAX_TRANSMIT_S=
PAN + MAX_LATENCY


please cla= rify..

On = Fri, Jan 8, 2016 at 3:45 PM, Robert Cragie <robert.cragie@gridme= rge.com> wrote:
I think it is correct as written - the same ID must not be used withi= n EXCHANGE_LIFETIME. You can add NON_LIFETIME as well. The message ID certa= inly can be reused beyond those lifetimes as the occurrence of the message = ID for acknowledgement or duplication detection is no longer expected.
=
Robert

On 8 January 2016 at 03:58, R.Vinob= chander <vinobchanderr@ssn.edu.in> wrote:
<= /div>
Hi All,

=C2=A0 sec. 4.4 of RFC 7252 specifies=C2=A0

=C2=A0=C2=A0The same Message ID MUST N= OT be reused (in communicating with the
=09 =09 =09
=C2=A0 =C2=A0same= endpoint) within the EXCHANGE_LIFETIME=C2=A0

=C2=A0 I think the sentence is incorrect and should b,

=C2=A0=C2=A0The = same Message ID MUST NOT be reused (in communicating with the
<= div>=C2=A0 =C2=A0same en= dpoint) beyond the EXCHANGE_LIFETIME/NON_LIFETIME
<= span style=3D"font-family:Courier;font-size:10pt">
Regards,
--
R. Vinob chan= der, B.E., M.E., (Ph.D)
Assistant Profe= ssor, Department of IT
SSN College of Engineering,
Old Mahabalipuram Road
Kalavakkam - 603 110
Tamil Nadu, I= ndia

Phone: +9144-27469700 ,=C2=A0+91 44 27474844/45/46
Extn: 370

::DISCLAIMER:: 
------------------------------------------=
---------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
---------------------------------------------------------------------
He=
ader of this mail should have a valid DKIM signature for the domain ssn.edu.in

_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core




--
R. Vinob chander, B.E., M.E., (Ph.D)
Assistant Professor, Department of IT
SSN Co= llege of Engineering,
Old Mahabalipuram Road
Kalavakkam - 603 110
T= amil Nadu, India

Phone: +9144-27469700 ,=C2=A0+91 44 27474844/45/46
Extn: 370
M= ob: +91-9566101580

::DISCLAIMER:: 
-------------------------------------=
--------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
-----------------------------------------------------------------=
----
Header of this mail should have a valid DKIM signature for the doma=
in ssn.edu.in
<=
/font>
--001a113eb35c8ac36f0528d45bda-- From nobody Fri Jan 8 08:17:06 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFB91B2A1E for ; Fri, 8 Jan 2016 08:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 wnWYzQUm0Kb6 for ; Fri, 8 Jan 2016 08:17:02 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 C412F1B2A1D for ; Fri, 8 Jan 2016 08:17:01 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id i124so10349435lfe.3 for ; Fri, 08 Jan 2016 08:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9KBvW2cK9oPszcEzkF14+6ps48AWH6v0PVzaYyXoFTM=; b=E05hOP2DeW/OS+bRwkeyyFxs05kBTGinGKk1UtKPj0kcV8i5ewo30BDEhpijl6y69q 0hF3qTYcze8XRtiqKh0aT8A3ZZKJ21CCr2zp/FncfJPFi/fL90sPGA3GWkgZwaQxff8B eLqRVUh6YElft482aaqyUxhSl0rlh2bcXiYf2ID+7KTbQPzBoZ72U2Q6BUHpvawHlwed dbuCg/2gMI+BJCHe7lrZ5qojQjvjrjYffDZVZCGY0NPllUY+btP1mOh8BmpBPNcstK8/ sQyTetMjZiDNn3kqYQJwt9T/YG3EnARHkRCbhZHzxX7V57DKerkNwefdCwgxPqCsoe8C 6tOg== MIME-Version: 1.0 X-Received: by 10.25.21.225 with SMTP id 94mr37287548lfv.159.1452269819804; Fri, 08 Jan 2016 08:16:59 -0800 (PST) Sender: robert.cragie@gmail.com Received: by 10.25.143.68 with HTTP; Fri, 8 Jan 2016 08:16:59 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 16:16:59 +0000 X-Google-Sender-Auth: zxfBxbFsKgwlbXnBhia7wwRgdGY Message-ID: From: Robert Cragie To: "R.Vinob chander" Content-Type: multipart/alternative; boundary=001a113f245eba44af0528d4ea91 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] message correlation on CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 16:17:05 -0000 --001a113f245eba44af0528d4ea91 Content-Type: text/plain; charset=UTF-8 Hi Vinod, Comments inline, bracketed by Robert On 8 January 2016 at 15:36, R.Vinob chander wrote: > thank u... u r right.....but the a receiver may get multiple copies of the same message if the ACK is lost in transit..(sec. 4.5). So in such cases the same message ID is used within the EXCHANGE_LIFETIME. > > Not really - retransmitting a CON message due to lost ACK does not constitute reusing the same Message ID as it is essentially the same message retransmitted. The emphasis is on *re*using; using the same message ID again in the retransmission is not *re*using. So I think the original text is OK. > Hence i think probably the sentence should be "The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the first timeout for CON and MAX_LATENCY for NON" > > 4.4. Message Correlation > > The same Message ID MUST NOT be reused (in communicating with the > > same endpoint) within the EXCHANGE_LIFETIME > > > 4.5. Message Deduplication > > A recipient might receive the same Confirmable message (as indicated > by the Message ID and source endpoint) multiple times within the > EXCHANGE_LIFETIME > > > 4.8.2. > > NON_LIFETIME is the time from sending a Non-confirmable message to > the time its Message ID can be safely reused. *If multiple > transmission of a NON message is not used, its value is > MAX_LATENCY, or 100 seconds*. However, *a CoAP sender might send a > NON message multiple times*, in particular for multicast > applications. While the period of reuse is not bounded by the > specification, an expectation of reliable detection of duplication > at the receiver is on the timescales of MAX_TRANSMIT_SPAN. > Therefore, for this purpose, it is safer to use the value: > > MAX_TRANSMIT_SPAN + MAX_LATENCY > > The same applies for NON; retransmitting a NON (for example, for robustness in the case of multicast) does not constitute reusing of the message ID as it is essentially the same message retransmitted. > please clarify.. > > I hope the above clarifies things > > On Fri, Jan 8, 2016 at 3:45 PM, Robert Cragie > wrote: > >> I think it is correct as written - the same ID must not be used within >> EXCHANGE_LIFETIME. You can add NON_LIFETIME as well. The message ID >> certainly can be reused beyond those lifetimes as the occurrence of the >> message ID for acknowledgement or duplication detection is no longer >> expected. >> >> Robert >> >> On 8 January 2016 at 03:58, R.Vinob chander >> wrote: >> >>> Hi All, >>> >>> sec. 4.4 of RFC 7252 specifies >>> >>> The same Message ID MUST NOT be reused (in communicating with the >>> same endpoint) within the EXCHANGE_LIFETIME >>> >>> I think the sentence is incorrect and should b, >>> >>> The same Message ID MUST NOT be reused (in communicating with the >>> same endpoint) *beyond* the EXCHANGE_LIFETIME/NON_LIFETIME >>> >>> Regards, >>> -- >>> R. Vinob chander, B.E., M.E., (Ph.D) >>> Assistant Professor, Department of IT >>> SSN College of Engineering, >>> Old Mahabalipuram Road >>> Kalavakkam - 603 110 >>> Tamil Nadu, India >>> www.ssn.edu.in >>> >>> Phone: +9144-27469700 , +91 44 27474844/45/46 >>> Extn: 370 >>> Mob: +91-9566101580 >>> >>> ::DISCLAIMER:: >>> >>> --------------------------------------------------------------------- >>> The contents of this e-mail and any attachment(s) are confidential and >>> intended for the named recipient(s) only. Views or opinions, if any, >>> presented in this email are solely those of the author and may not >>> necessarily reflect the views or opinions of SSN Institutions (SSN) or its >>> affiliates. Any form of reproduction, dissemination, copying, disclosure, >>> modification, distribution and / or publication of this message without the >>> prior written consent of authorized representative of SSN is strictly >>> prohibited. If you have received this email in error please delete it and >>> notify the sender immediately. >>> --------------------------------------------------------------------- >>> Header of this mail should have a valid DKIM signature for the domain ssn.edu.in >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >> > > > -- > R. Vinob chander, B.E., M.E., (Ph.D) > Assistant Professor, Department of IT > SSN College of Engineering, > Old Mahabalipuram Road > Kalavakkam - 603 110 > Tamil Nadu, India > www.ssn.edu.in > > Phone: +9144-27469700 , +91 44 27474844/45/46 > Extn: 370 > Mob: +91-9566101580 > > ::DISCLAIMER:: > > --------------------------------------------------------------------- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. Views or opinions, if any, > presented in this email are solely those of the author and may not > necessarily reflect the views or opinions of SSN Institutions (SSN) or its > affiliates. Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message without the > prior written consent of authorized representative of SSN is strictly > prohibited. If you have received this email in error please delete it and > notify the sender immediately. > --------------------------------------------------------------------- > Header of this mail should have a valid DKIM signature for the domain ssn.edu.in > > --001a113f245eba44af0528d4ea91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Vinod,

Comments inline, b= racketed by <RCC></RCC>

Robert

On 8 January 2016 a= t 15:36, R.Vinob chander <vinobchanderr@ssn.edu.in> w= rote:
=09 =09 =09 
thank u... u r righ=
t.....but the a receiver may get multiple copies of the same message if the=
 ACK is lost in transit..(sec. 4.5). So in such cases the same message ID i=
s used within the EXCHANGE_LIFETIME.
<RCC>Not really - retransmitting a CON message = due to lost ACK does not constitute reusing the same Message ID as it is es= sentially the same message retransmitted. The emphasis is on *re*using; usi= ng the same message ID again in the retransmission is not *re*using. So I t= hink the original text is OK.</RCC>=C2=A0
Hence i think probably the sentence should be  "The same Message ID MUST N=
OT be reused (in communicating with the same endpoint) within the first timeout for CON and =
MAX_LATENCY for NON"  <=
span style=3D"font-family:arial,sans-serif">						
4.4.  Message Correlation


 The same Message ID MUS=
T NOT be reused (in communicating with the
   same endpoint) within the EXCHANGE_LIFETIM=
E

<=
/span>
4.5.  Message Deduplication

   A recipien=
t might receive the same Confirmable message (as indicated
   by the Message ID and source endpoint) multiple times within the
   EXCHANGE_LIFETIME=20


4.8.2.=
 		
NON_LIFETIME is the time from sending a Non-confirmable me=
ssage to
   the time its Message ID can be safely reused.  If multiple
   transmission of a NON message is not used, its value is
   MAX_LATENCY, or 100 seconds.  However, a CoAP sender might send a
   NON message multiple times, in particular for multicast
   applications.  While the period of reuse is not bounded by the
   specification, an expectation of reliable detection of duplication
   at the receiver is on the timescales of MAX_TRANSMIT_SPAN.
   Therefore, for this purpose, it is safer to use the value:
<=
pre>      MAX_TRANSMIT_S=
PAN + MAX_LATENCY
<RCC>The same applies for NON; retra= nsmitting a NON (for example, for robustness in the case of multicast) does= not constitute reusing of the message ID as it is essentially the same mes= sage retransmitted.</RCC>
please clarify..
<RCC>I hope the= above clarifies things</RCC>=C2=A0
=
On Fri, Jan 8, 2016 at 3:45 PM, Robert Cragi= e <robert.cragie@gridmerge.com> wrote:
I think it is correct as written - the same ID mu= st not be used within EXCHANGE_LIFETIME. You can add NON_LIFETIME as well. = The message ID certainly can be reused beyond those lifetimes as the occurr= ence of the message ID for acknowledgement or duplication detection is no l= onger expected.

Robert

On 8 January 2016 at 03:58, R= .Vinob chander <vinobchanderr@ssn.edu.in> wrote:
<= /div>
Hi All,

=C2=A0 sec. 4.4 of RFC 7252 specifies=C2=A0

=C2=A0=C2=A0The same Message ID MUST NOT be reused (in comm= unicating with the
=09 =09 =09
=C2=A0 =C2=A0same= endpoint) within the EXCHANGE_LIFETIME=C2=A0

=C2=A0 I think the sentence is incorrect and should b,

=C2=A0=C2=A0The = same Message ID MUST NOT be reused (in communicating with the
<= div>=C2=A0 =C2=A0same en= dpoint) beyond the EXCHANGE_LIFETIME/NON_LIFETIME
<= span style=3D"font-family:Courier;font-size:10pt">
Regards,
--
R. Vinob chan= der, B.E., M.E., (Ph.D)
Assistant Profe= ssor, Department of IT
SSN College of Engineering,
Old Mahabalipuram Road
Kalavakkam - 603 110
Tamil Nadu, I= ndia

Phone: +9144-27469700 ,=C2=A0+91 44 27474844/45/46
Extn: 370

::DISCLAIMER:: 
------------------------------------------=
---------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
---------------------------------------------------------------------
He=
ader of this mail should have a valid DKIM signature for the domain ssn.edu.in

_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core




--
R. Vinob chander, B.E., M.= E., (Ph.D)
Assistant Professor, Departm= ent of IT
SSN College of Engineering,
Old Mahabalipuram Road
Kalavakka= m - 603 110
Tamil Nadu, India
www.ssn.edu.in

Phone: +9144-27469700 ,=C2=A0+91 44 27474844/45/46
Ex= tn: 370
Mob: +91-9566101580<= /div>

::DISCLAIMER:: 
------------------------------------------=
---------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
---------------------------------------------------------------------
He=
ader of this mail should have a valid DKIM signature for the domain ssn.edu.in



--001a113f245eba44af0528d4ea91--


From nobody Fri Jan  8 17:56:09 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AD41A0060 for ; Fri,  8 Jan 2016 17:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.322
X-Spam-Level: *
X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 D1B6LrO7IWN5 for ; Fri,  8 Jan 2016 17:56:05 -0800 (PST)
Received: from mail-ig0-x244.google.com (mail-ig0-x244.google.com [IPv6:2607:f8b0:4001:c05::244]) (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 294351A005B for ; Fri,  8 Jan 2016 17:56:05 -0800 (PST)
Received: by mail-ig0-x244.google.com with SMTP id ik10so9308970igb.1 for ; Fri, 08 Jan 2016 17:56:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ssn.edu.in; s=ssn; h=mime-version:date:message-id:subject:from:to:content-type; bh=QPxKp2ZLbIMosvKNP5gOSIVhvPrsAPzkPuIKdAUAxPo=; b=gBkxGTOKM3wgsIGRSHAZejGfrObnCGcwvyquCxANFu+q2Ajj0qwc3DZMYLj8PgxvAe BeeVHCwetNqe96QbKKgn0gEQ4Ie2mMCUfn5u3e4PcOQyufV7hoFhfvWgwbBDDpP9IhYX exvlQkjpqnY7E3LTLn4AmdniU8ctgkT/YkHcY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=QPxKp2ZLbIMosvKNP5gOSIVhvPrsAPzkPuIKdAUAxPo=; b=ajpjbvTLVDrRBjcu37/FlTqBM7AZk7ed6EhrJ2SIOpKFWStTQljfoayMi7eFDRMXH1 xAPKY9l/Q+hTY46wMQaKPxeA9HbJmW7xYPdDEYUiIivZw7lIoY/3Olxd0MM+78FsxvSe O6gtdLQOpxFc0HLT9+VXEmsc9eMG9iDeXk97lnJlX5cHiIsyxQMQVBO3tOKmnFEyqVYv PUeewO5tevkA/WaxvruvbkMAJ1z4CmZoBogB/Qwc+fG7MUKtFP+AOGydIhHhR2eSaZTB 1ekctJrQToGns+fVkzQjCqXQRr5dp5zDSZS5njgZ/0ja8+3kusKlCpITk0tM6eB07VcY TGnA==
X-Gm-Message-State: ALoCoQmwy80gRbxZBj+eiylDtNJRbXQpnXp4AEcoJ3uhG3f1R9H+Zjnil7gZ1gpugptgqnuTqpBynN0eCjmbhwmrfr54S88354QU7LJ1RfWLbiIWbczX2BtM+tpNHVY4mrSOKAQkbzdkb+q2w6n3u7l3eWlnN8Ch3g==
MIME-Version: 1.0
X-Received: by 10.50.28.37 with SMTP id y5mr1876780igg.93.1452304564471; Fri, 08 Jan 2016 17:56:04 -0800 (PST)
Received: by 10.79.120.216 with HTTP; Fri, 8 Jan 2016 17:56:04 -0800 (PST)
Date: Sat, 9 Jan 2016 07:26:04 +0530
Message-ID: 
From: "R.Vinob chander" 
To: core@ietf.org, Robert Cragie 
Content-Type: multipart/alternative; boundary=089e01538c36abe9120528dd018b
Archived-At: 
Subject: [core] congestion control
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Jan 2016 01:56:07 -0000

--089e01538c36abe9120528dd018b
Content-Type: text/plain; charset=UTF-8

Hi All,

   May i get a clear understanding for the following in sec 4.7:

 1. default value of NSTART is one. that means one outstanding interaction
(meaning the responses for two different requests may arrive at the same.*
am i right at this interpretation?*). *How does changing NSTART to a
different value impact congestion control ?*

2. what is the significance of PROBING_RATE to congestion control?

3. "The specific algorithm by which a client stops to "expect" a response to
a Confirmable request that was acknowledged, or to a Non-confirmable
request, *is not defined*."

*why does the spec not define this?*

4. Unless *this is* modified by additional congestion control
optimizations, it MUST be chosen in such a way that an endpoint does not
exceed an average data rate of PROBING_RATE in sending to another endpoint
that does not respond.

*can you explain the above sentence? what "this is" in the sentence refer
to? *
-- 
R. Vinob chander, B.E., M.E., (Ph.D)
Assistant Professor, Department of IT
SSN College of Engineering,
Old Mahabalipuram Road
Kalavakkam - 603 110
Tamil Nadu, India
www.ssn.edu.in

Phone: +9144-27469700 , +91 44 27474844/45/46
Extn: 370
Mob: +91-9566101580

-- 
::DISCLAIMER:: 

---------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
---------------------------------------------------------------------
Header of this mail should have a valid DKIM signature for the domain ssn.edu.in 


--089e01538c36abe9120528dd018b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi All,

=C2=A0 =C2=A0May i get a clear =
understanding for the following in sec 4.7:
=C2=A0 =C2=A0
=C2=A01. default value of NSTART is one. that means one outstanding inte=
raction (meaning the responses for two different requests may arrive at the=
 same. am i right at this interpretation?). How does changing NST=
ART to a different value impact congestion control ?

<=
/b>
2. what is the significance of PROBING_RATE to congestion con=
trol?

3. "The specific algorithm by which a client stops =
to "expect" a response=C2=A0to a Confirmable request that was acknowledged, or to =
a Non-confirmable=
 request, is not defined."=C2=A0

why does the spec not define this?

4.=C2=A0Unless this =
is modified by=C2=A0additional congestion control optimizations, it MUST be chosen in=C2=
=A0such a way tha=
t an endpoint does not exceed an average data rate of=C2=A0PROBING_RATE in sending to anothe=
r endpoint that does not respond.

can you explain the above sentence? wha=
t "this is" in the sentence refer to?=C2=A0-- 
R. Vinob chander, B.E., M.E., (Ph.D)
Assistant Professor, Department of IT
SSN College of Engineer=
ing,
Old Mahabalipuram Road=

Kalavakkam - 603 110
Tamil Nadu, India

Phone: +9144-2746970=
0 ,=C2=A0+91 44 27474844/45/46
Extn: 370
Mob: +91-9566101580






::DISCLAIMER::

-------------------------------------=
--------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
-----------------------------------------------------------------=
----
Header of this mail should have a valid DKIM signature for the doma=
in ssn.edu.in
<=
/font>

--089e01538c36abe9120528dd018b--


From nobody Tue Jan 12 06:06:49 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765DA1B2A2C for ; Tue, 12 Jan 2016 06:06:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.423
X-Spam-Level: *
X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 aOa_4c4smlD0 for ; Tue, 12 Jan 2016 06:06:46 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 6DFD91B2A29 for ; Tue, 12 Jan 2016 06:06:45 -0800 (PST)
Received: by mail-lb0-x236.google.com with SMTP id cl12so55523913lbc.1 for ; Tue, 12 Jan 2016 06:06:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XI77+Q7BexsxNpHpKtIWhR71Ce5Ql02NTb88xQtVeUg=; b=daQTa5SHiqlr8bW2TPboVVuzmfsm2W+vlSUp4bTesEnUWz/I+vY8ZpQWJFmjYH9Muy EX3I3my1d37Ex5xJdZROR7SP54oLu6Fh1zh2o8Xo7YipxNV10w5tAghdIFIXRuQJBO+E yefoasoKKoxeqP3AZ0GrEZ05glnhDbGZpEZhInObbvWBzTlKyV97MaWT5t/KiIView3b nBDQydf08UYu2fbaG19gjPdomNcrXyTlEKrNcRHZ/2L1nmgO/EeOT1EBvdr0DjJq3BVw /JoOYKxt1fRSmysCd3yAq/8pg1ocMNWnOLZjXCscfaNgtn5wFLxh+XobBdeVxrzyBNWc MnAg==
MIME-Version: 1.0
X-Received: by 10.112.25.40 with SMTP id z8mr49874002lbf.13.1452607603579; Tue, 12 Jan 2016 06:06:43 -0800 (PST)
Sender: robert.cragie@gmail.com
Received: by 10.25.143.68 with HTTP; Tue, 12 Jan 2016 06:06:43 -0800 (PST)
In-Reply-To: 
References: 
Date: Tue, 12 Jan 2016 14:06:43 +0000
X-Google-Sender-Auth: KS29inseUxlsea2FPIak1BaEwTY
Message-ID: 
From: Robert Cragie 
To: "R.Vinob chander" 
Content-Type: multipart/alternative; boundary=001a11c3f5a435a6970529239093
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] congestion control
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Jan 2016 14:06:48 -0000

--001a11c3f5a435a6970529239093
Content-Type: text/plain; charset=UTF-8

Hi Vinob,

Responses below, bracketed by 

Robert

On 9 January 2016 at 01:56, R.Vinob chander 
wrote:

> Hi All,
>
>    May i get a clear understanding for the following in sec 4.7:
>
>  1. default value of NSTART is one. that means one outstanding interaction
> (meaning the responses for two different requests may arrive at the same.*
> am i right at this interpretation?*). *How does changing NSTART to a
> different value impact congestion control ?*
>


NSTART is just the number of outstanding interactions possible at the same
time (i.e. simultaneous). There are two sorts of interactions considered:

1) CON, expecting an ACK (messaging layer)
2) Request, expecting a Response (request/response layer)

The section basically states that for (1), the time an interaction is
outstanding is EXCHANGE_LIFETIME. It also says it is undefined in the case
of (2) but puts requirements regarding around not sending too much traffic
to a server.

A value of 1 means a client can only have one outstanding interaction with
any server at a particular time. So with NSTART=1, a client can't get two
different responses from the same server. A client may have multiple
interactions to *different* servers outstanding at any one time.



> 2. what is the significance of PROBING_RATE to congestion control?
>

It has no significance to congestion control based on CON/ACK. It is
of significance to limit any attempt at congestion control using other
means above the messaging layer, which are undefined in RFC 7252. It is a
simple parameter aimed at limiting the amount of traffic which might be
sent if no response is received

>
> 3. "The specific algorithm by which a client stops to "expect" a response to
> a Confirmable request that was acknowledged, or to a Non-confirmable
> request, *is not defined*."
>
> *why does the spec not define this?*
>

Because it is really a higher layer matter. In addition to any lower
layer reliability mechanisms, for example, the CON/ACK reliability
mechanism, the application layer normally has its own methods for
reliability, usually involving expecting a response to a specific request.
This is specific to the application therefore cannot really be expressed in
a transfer protocol specification

>
> 4. Unless *this is* modified by additional congestion control
> optimizations, it MUST be chosen in such a way that an endpoint does not
> exceed an average data rate of PROBING_RATE in sending to another
> endpoint that does not respond.
>
> *can you explain the above sentence? what "this is" in the sentence refer
> to? *
>

"this" refers to "the specific algorithm". All this sentence is saying
is that whichever algorithm you choose, at the very least that algorithm
must not cause data to be sent at rates averaging more than
PROBING_RATE.

-- 
> R. Vinob chander, B.E., M.E., (Ph.D)
> Assistant Professor, Department of IT
> SSN College of Engineering,
> Old Mahabalipuram Road
> Kalavakkam - 603 110
> Tamil Nadu, India
> www.ssn.edu.in
>
> Phone: +9144-27469700 , +91 44 27474844/45/46
> Extn: 370
> Mob: +91-9566101580
>
> ::DISCLAIMER::
>
> ---------------------------------------------------------------------
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. Views or opinions, if any,
> presented in this email are solely those of the author and may not
> necessarily reflect the views or opinions of SSN Institutions (SSN) or its
> affiliates. Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of this message without the
> prior written consent of authorized representative of SSN is strictly
> prohibited. If you have received this email in error please delete it and
> notify the sender immediately.
> ---------------------------------------------------------------------
> Header of this mail should have a valid DKIM signature for the domain ssn.edu.in 
>
>

--001a11c3f5a435a6970529239093
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Vinob,

Responses below, bracketed by=
 <RCC></RCC>

Robert

On 9 January 2016 at 01:56, R.Vi=
nob chander <vinobchanderr@ssn.edu.in> wrote:
Hi All,

=C2=
=A0 =C2=A0May i get a clear understanding for the following in sec 4.7:
=C2=A0 =C2=A0
=C2=A01. default value of NSTART is one. tha=
t means one outstanding interaction (meaning the responses for two differen=
t requests may arrive at the same. am i right at this interpretation?). How does changing NSTART to a different value impact congestion cont=
rol ?

<RCC>
NSTART is just the number of outstanding interactions possible at the same=
 time (i.e. simultaneous). There are two sorts of interactions considered:<=
/div>

1) CON, expecting an ACK (messaging layer)
2) Request, expecting a Response (request/response layer)

=

The section basically states that for (1), the time an interacti=
on is outstanding is EXCHANGE_LIFETIME. It also says it is undefined in the=
 case of (2) but puts requirements regarding around not sending too much tr=
affic to a server.

A value of 1 means a client can=
 only have one outstanding interaction with any server at a particular time=
. So with NSTART=3D1, a client can't get two different responses from t=
he same server. A client may have multiple interactions to *different* serv=
ers outstanding at any one time.
</RCC>


2. what is the significance of PROBING_RATE to congestion control?

<RCC>It has no=
 significance to congestion control based on CON/ACK. It is of significance=
 to limit any attempt at congestion control using other means above the mes=
saging layer, which are undefined in RFC 7252. It is a simple parameter aim=
ed at limiting the amount of traffic which might be sent if no response is =
received</RCC>
<=
div>

3. "The specific algorithm by which a client stops to "expect&quo=
t; a response=C2=A0to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not=
 defined."=C2=A0

why does the s=
pec not define this?

=
<RCC>Because it is really a higher layer matter. In addition to any l=
ower layer reliability mechanisms, for example, the CON/ACK reliability mec=
hanism, the application layer normally has its own methods for reliability,=
 usually involving expecting a response to a specific request. This is spec=
ific to the application therefore cannot really be expressed in a transfer =
protocol specification</RCC>

4.=C2=A0Unless this is modified by=C2=A0=
additional congestion co=
ntrol optimizations, it MUST be chosen in=C2=A0such a way that an endpoint does not exceed a=
n average data rate of=C2=A0PROBING_RATE in sending to another endpoint that does not respon=
d.

=

can you explain the above sentence? what "this is" in the se=
ntence refer to?=C2=A0

<RCC>"this" refers to "the specific al=
gorithm". All this sentence is saying is that whichever algorithm you =
choose, at the very least that algorithm must not cause data to be sent at =
rates averaging more than PROBING_RATE.</RCC>

-- 
R. Vinob chander, B.E., M.E., (P=
h.D)
Assistant Professor, Department of=
 IT
S=
SN College of Engineering,
=
Old Mahabalipuram Road
Kalavakkam - 60=
3 110
Tamil Nadu, India
www.ssn.edu.in

Phone: +9144-27469700 ,=C2=A0+9=
1 44 27474844/45/46
Extn: 3=
70
=







::DISCLAIMER::

------------------------------------------=
---------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
---------------------------------------------------------------------
He=
ader of this mail should have a valid DKIM signature for the domain ssn.edu.in



--001a11c3f5a435a6970529239093--


From nobody Wed Jan 13 05:57:08 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA8F1B2DFD for ; Wed, 13 Jan 2016 05:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.502
X-Spam-Level: 
X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
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 BCpFy_5AngMz for ; Wed, 13 Jan 2016 05:57:04 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9624F1B2DEE for ; Wed, 13 Jan 2016 05:57:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3660; q=dns/txt; s=iport; t=1452693424; x=1453903024; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=vrX9UqDnbmOMYwZ6T26c3Av7thbFBmAZrUJ77HLLPOg=; b=Y6IMSfn+uw57rgOrbrlL96EvRaFAPuq1nPVb4gZkofRswbN8pXUtEHdj 9rnZIvB45A1YDhHsPHZqFYqTFMd7WaJjgTI0nf/i1xda2mIEc3kabt4S6 fYzCRMqUSZPGy9EM6rvR3D4F+/YRdvFwOE3N0w9WDgY/j3usikaBdJ+qR M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLBQDKVpZW/5FdJa1egzpSc4hUsymBZ?= =?us-ascii?q?CKFbYEzORMBAQEBAQEBgQqENwR5EgGBACcEDogzDsABAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBFASIZYc6g1iBGwWNQTqJGgGBDoQ0iBePAI5TASQBP4QKhgaBCAEBA?= =?us-ascii?q?Q?=
X-IronPort-AV: E=Sophos;i="5.22,289,1449532800"; d="scan'208";a="62977339"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2016 13:57:03 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u0DDv3Ql032692 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 13:57:03 GMT
Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Jan 2016 08:57:02 -0500
Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Wed, 13 Jan 2016 08:57:02 -0500
From: "Cullen Jennings (fluffy)" 
To: core 
Thread-Topic: Designs to resolve streaming issues in SenML
Thread-Index: AQHRTgpHsd3LX6zsUkSZYQNHY6fdOQ==
Date: Wed, 13 Jan 2016 13:57:02 +0000
Message-ID: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.249.165]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <0AAFF9F1DAC3EB45B6BEDE016340B300@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 13:57:06 -0000

The changes we made to SenML to support streaming in the -02 version raised=
 many issues for lots of people. In the end, one of the biggest problems is=
 it forces all things receiving SenML to support streaming.=20

I have an alternative design for streaming that I think addresses the issue=
s raised and I would like the WG to think about two alternative designs for=
 SenML and give me some direction on which one to use.=20

The first design is the current -02 design with simple fixes and is in draf=
t draft-jennings-core-senml-03

The second design is the new design I am proposing and is in draft-jennings=
-core-senml-04. It many way it moves back to be much closer to what was in =
-01 than what is in -02.=20

The drafts can be found at=20

https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/

and=20

https://datatracker.ietf.org/doc/draft-jennings-core-senml/04/


Practically speaking the differences are not that much between the two but =
they do resolve a bunch of the issue. Let me discuss this in terms of the J=
SON representation and the rest of the representations mirror that.  In the=
 new design measurements are put in JSON object as always. The object are p=
ut in array to represent a series of measurements. The objects can also hav=
e the base values right in the object and the base values apply to all the =
things in the object and any future objects in the array.=20

Here is an example of something that is not a stream in both old and new de=
sign.

OLD=20

[{"bn": "urn:dev:mac:0024befffe804ff1/"},
 [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
   { "n": "current", "t": 0, "u": "A", "v": 1.2 } ]
]

NEW

[{"bn": "urn:dev:mac:0024befffe804ff1/"},
 { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
 { "n": "current", "t": 0, "u": "A", "v": 1.2 }=20
]

Note the old design has an array with a base object, followed by a second a=
rray of measurements. The new design just has an single array and the first=
 object happens to only have base values that apply to future object in the=
 array.=20

This could also be sent as

[
    {
	"t": 0,=20
      	"n": "voltage",=20
	"u": "V",=20
     	"bn": "urn:dev:mac:0024befffe804ff1/",
	"v": 120.1
   },
   {=20
	"n": "current",=20
	"t": 0,=20
	"u": "A",=20
	"v": 1.2=20
   }=20
]

Here is an example of streaming with old and new design=20

OLD=20

[{"bn": "http://[2001:db8::1]",
  "bt": 1320067464,
  "bu": "%RH"},
 [ { "v": 21.2, "t": 0 },
   { "v": 21.3, "t": 10 },
   { "v": 21.4, "t": 20 },
   { "v": 21.4, "t": 30 },
   { "v": 21.5, "t": 40 },
   { "v": 21.5, "t": 50 },
   { "v": 21.5, "t": 60 },
   { "v": 21.6, "t": 70 },
   { "v": 21.7, "t": 80 },
   { "v": 21.5, "t": 90 },
...

NEW=20

[ {"bn": "http://[2001:db8::1]",
  "bt": 1320067464,
  "bu": "%RH"},
   { "v": 21.2, "t": 0 },
   { "v": 21.3, "t": 10 },
   { "v": 21.4, "t": 20 },
   { "v": 21.4, "t": 30 },
   { "v": 21.5, "t": 40 },
   { "v": 21.5, "t": 50 },
   { "v": 21.5, "t": 60 },
   { "v": 21.6, "t": 70 },
   { "v": 21.7, "t": 80 },
   { "v": 21.5, "t": 90 },
...


The draft does not have it yet but an applications that supports receiving =
streaming is written is a substantially different way that one that does no=
t. I think the best way to deal with this is simply use a different mine ty=
pe for streaming ( calls it senml_stream for now but send me suggestions on=
 name for it). That way it can be clearly indicated and negotiated in exist=
ing transport protocols.=20

Appreciate any thoughts people have on pro / cons of the -03 design vs -04 =
design.





From nobody Wed Jan 13 06:31:16 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B281B2E31 for ; Wed, 13 Jan 2016 06:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 fIr_NmqmyFjC for ; Wed, 13 Jan 2016 06:31:13 -0800 (PST)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA80A1B2E33 for ; Wed, 13 Jan 2016 06:31:12 -0800 (PST)
Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 4FDB9FB8D4; Wed, 13 Jan 2016 15:31:11 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id bfaPoSzheYh5; Wed, 13 Jan 2016 15:30:39 +0100 (CET)
X-Originating-IP: 134.102.17.180
Received: from eduroam-0436.wlan.uni-bremen.de (eduroam-0436.wlan.uni-bremen.de [134.102.17.180]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id DBE6EFB8E1; Wed, 13 Jan 2016 15:30:38 +0100 (CET)
Message-ID: <56965F8D.9040309@tzi.org>
Date: Wed, 13 Jan 2016 15:30:37 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" 
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com>
In-Reply-To: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 14:31:14 -0000

Cullen Jennings (fluffy) wrote:
> pro / cons of the -03 design vs -04 design.

One comment I made when this was discussed in Yokohama was that the -04
design makes the processor examine every single measurement record
whether there is a change to the base values (and, if there are only
changes to base values so that record isn't really a measurement
record).  That might impede high speed processing a bit.  E.g., it could
become harder to merge two time sequences because each single entry in
them might be changing a base value that is relevant to entries in the
other stream.  But I haven't implemented either model, so that is just a
hunch.

Apart from that kind of consideration, that part of the approach -04 is
pretty much equivalent to -03.

Grüße, Carsten


From nobody Thu Jan 14 18:43:47 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926971A87D7 for ; Thu, 14 Jan 2016 18:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level: 
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_mvHscfiZt5 for ; Thu, 14 Jan 2016 18:43:42 -0800 (PST)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF401A87D4 for ; Thu, 14 Jan 2016 18:43:42 -0800 (PST)
Received: by mail-pf0-x233.google.com with SMTP id n128so109813609pfn.3 for ; Thu, 14 Jan 2016 18:43:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7hTDdntUdOMB+ygBcxZxVuW2LVwi/3Kk3xu+f9ucAQI=; b=ihMrlTXwqp0ZBwy0cYzSWu18wqcGI1S/8EIxY2TmtEdIhvU8RLPSFnpOxEYs6DKqlu wgBYZz2w+WIlRJUVAKhaOUcnHuraniNp52A5+cumqvgsCpYV/94sTlwGpF/YBeLj0/qP xWl6aS5g4EY1N0DdM+6jklwLwKJ4L1UoGcqXk3fprRtD0wjorCXTrBNMPnqkBC/W3Kxg 89DBNhilyZjpBfWI6PAK3F+Ucgt/OsJmoInzqtMQTAPMUvLp7osUxGVrPqMmyb0Li5CG juhpo7thEOOih8ys3evmvGN6+wuKuBMiM4bQuISHDL+yzdtnJP78/fKTYtvGkUrJrgNc nu4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=7hTDdntUdOMB+ygBcxZxVuW2LVwi/3Kk3xu+f9ucAQI=; b=D4hCOs+4pqfxLgZ7TdIqCOHVmNLja7CJi8O0c5Suat4qoF0f13z7QvFsj0U8f6PPgV ksDUzsVL6DNzwBH1e4PcEx/ISQOH9tXyZZ1LdfD9w20e1zrZAwYrGBiAC83gh3OlhX0P Yyf0cZ7NmGTem6Ib5luZC7XoBVRhYNByaaTBCIcybQRyMzMo/Tknk6M/5gnajm22Jyrj 1Geztt0b4m+naDM8G56AS/yskE+Ri0ig2zm/9ahQOtFaAiF9nUUlB8A6oGPegG7JS8J1 GLAZzbVsSVyAKEqpolPMXP4qQxGfzvGnL0jMgZKERABn84AUXBgzapa4xVPHmxR5XTBk e9qA==
X-Gm-Message-State: ALoCoQntzEjrLcj5SDkOkk1YQF5Lp5HV/uVBnZBtEYbgSVTUXRBoSYTjN1UEz0VY/z/QkyhbNUW7il1Louo4iKFObZiifafnJg==
X-Received: by 10.98.93.195 with SMTP id n64mr11552221pfj.67.1452825821711; Thu, 14 Jan 2016 18:43:41 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 72sm12125692pfk.28.2016.01.14.18.43.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jan 2016 18:43:40 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F96250A-4C95-4D78-8C35-44E48418CC83"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com>
Date: Thu, 14 Jan 2016 18:43:38 -0800
Message-Id: <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com>
To: "Cullen Jennings (fluffy)" 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 02:43:45 -0000

--Apple-Mail=_5F96250A-4C95-4D78-8C35-44E48418CC83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

I have been working with JSON serializations of senml and link data =
lately and I have some comments on the new SenML draft. I haven=E2=80=99t =
kept up with the format changes because I have something already working =
that I like that is based on the senml core wg draft-01.=20

There are two problems with the new formats (-02 and -04) for my use =
case. The first is that I have added more element types to extend senml =
to represent collections that may have links, forms, and data items. The =
second is the issue of mapping vs. streaming as discussed previously.  =
First, I=E2=80=99ll try to explain the issue as I see it with mapping =
vs. streaming.

This is how the =E2=80=9Ccollection=E2=80=9D example appears in section =
6.1.4 of draft-04:

   [{"bn": "http://[2001:db8::2]/",
     "bt": 1320078429,
     "ver": 3},
      { "n": "temperature", "v": 27.2, "u": "Cel" },
      { "n": "humidity", "v": 80, "u": "%RH" }
   ]

The block formatting of the first map and addition of whitespace to the =
second 2 maps gives the visual impression that there is some hierarchy. =
The reformatted example below using standard json pretty print makes it =
easier to see how this parses into a data structure using standard json =
tools. I=E2=80=99d recommend following this format to make the examples =
consistent and easy to read. I will do the same in my drafts.

[
  {
    "bn": "http://[2001:db8::2]/",
    "bt": 1320078429,
    "ver": 3
  },
  {
    "n": "temperature",
    "u": "Cel",
    "v": 27.2
  },
  {
    "n": "humidity",
    "u": "%RH",
    "v": 80
  }
]
As pointed out, the streaming format can only be processed in streaming =
form. Storing this in memory using a JSON parser does not result in a =
structure that can be easily sorted or indexed by base element. If I =
were to design a parser for this, it would have a state machine that =
would consume the top level array elements in sequence and create an =
in-memory structure that looks like the structures described in =
draft-02:

[
  {
    "bn": "http://[2001:db8::2]/",
    "bt": 1320078429,
    "ver": 1
  },
  [
    {
      "n": "temperature",
      "u": "Cel",
      "v": 27.2
    },
    {
      "n": "humidity",
      "u": "%RH",
      "v": 80
    }
  ]
]
Or draft-01:

{
  "bn": "http://[2001:db8::2]/",
  "bt": 1320078429,
  "ver": 1
  "e": [
    {
      "n": "temperature",
      "u": "Cel",
      "v": 27.2
    },
    {
      "n": "humidity",
      "u": "%RH",
      "v": 80
    }
  ],
}
With these earlier structures I could use standard JSON parse tools and =
then selection algorithms that match the =E2=80=9Cbn=E2=80=9D value and =
select the contents within that item=E2=80=99s scope (for patching, =
etc.). With the streaming formats I need to add another level of =
serialize/deserialize between the content format and the actual program =
data model and process elements in order.

IOW, I already have a JSON parser and a JSON data structure filter that =
work together. Now with this format change, I need to add another layer =
of deserializing to create an index or remap the base elements.

The other issue is that in draft-01 the element tag =E2=80=9Ce=E2=80=9D =
maps to the XML serialization  tags nicely. I have tools that =
process both XML and JSON that understand this. Also, this is easily =
extensible to add more element classes to the senml data model, which I =
have done of links and forms.

{
  "bn": "/",
  "e": [
    {
      "n": "test",
      "sv": "testValue"
    }
  ],
  "l": [
    {
      "href": "",
      "rel": [
        "self"
      ]
    },
    {
      "href": "test",
      "rel": "sub"
    }
  ]
}

I have indicated this with a content format =E2=80=9Ccollection+senml+json=
=E2=80=9D, to indicate the senml data model with a collection extension =
or subtype.

Since the recent changes in senml, I have considered forking -01 and =
creating a new set of media types called hyper-senml, or =E2=80=9Chsml=E2=80=
=9D, so =E2=80=9Capplication/hsml+json=E2=80=9D, =
=E2=80=9Capplication/hsml+xml=E2=80=9D, =
=E2=80=9Capplication/collection+hsml+json=E2=80=9D, etc.

I guess my preferred outcome would be a senml optimized for mapping that =
looks like -01 and can be extended to add element classes, and a =
separate, streaming optimized format.

Best regards,

Michael


> On Jan 13, 2016, at 5:57 AM, Cullen Jennings (fluffy) =
 wrote:
>=20
> The changes we made to SenML to support streaming in the -02 version =
raised many issues for lots of people. In the end, one of the biggest =
problems is it forces all things receiving SenML to support streaming.=20=

>=20
> I have an alternative design for streaming that I think addresses the =
issues raised and I would like the WG to think about two alternative =
designs for SenML and give me some direction on which one to use.=20
>=20
> The first design is the current -02 design with simple fixes and is in =
draft draft-jennings-core-senml-03
>=20
> The second design is the new design I am proposing and is in =
draft-jennings-core-senml-04. It many way it moves back to be much =
closer to what was in -01 than what is in -02.=20
>=20
> The drafts can be found at=20
>=20
> https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/
>=20
> and=20
>=20
> https://datatracker.ietf.org/doc/draft-jennings-core-senml/04/
>=20
>=20
> Practically speaking the differences are not that much between the two =
but they do resolve a bunch of the issue. Let me discuss this in terms =
of the JSON representation and the rest of the representations mirror =
that.  In the new design measurements are put in JSON object as always. =
The object are put in array to represent a series of measurements. The =
objects can also have the base values right in the object and the base =
values apply to all the things in the object and any future objects in =
the array.=20
>=20
> Here is an example of something that is not a stream in both old and =
new design.
>=20
> OLD=20
>=20
> [{"bn": "urn:dev:mac:0024befffe804ff1/"},
> [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
>   { "n": "current", "t": 0, "u": "A", "v": 1.2 } ]
> ]
>=20
> NEW
>=20
> [{"bn": "urn:dev:mac:0024befffe804ff1/"},
> { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
> { "n": "current", "t": 0, "u": "A", "v": 1.2 }=20
> ]
>=20
> Note the old design has an array with a base object, followed by a =
second array of measurements. The new design just has an single array =
and the first object happens to only have base values that apply to =
future object in the array.=20
>=20
> This could also be sent as
>=20
> [
>    {
> 	"t": 0,=20
>      	"n": "voltage",=20
> 	"u": "V",=20
>     	"bn": "urn:dev:mac:0024befffe804ff1/",
> 	"v": 120.1
>   },
>   {=20
> 	"n": "current",=20
> 	"t": 0,=20
> 	"u": "A",=20
> 	"v": 1.2=20
>   }=20
> ]
>=20
> Here is an example of streaming with old and new design=20
>=20
> OLD=20
>=20
> [{"bn": "http://[2001:db8::1]",
>  "bt": 1320067464,
>  "bu": "%RH"},
> [ { "v": 21.2, "t": 0 },
>   { "v": 21.3, "t": 10 },
>   { "v": 21.4, "t": 20 },
>   { "v": 21.4, "t": 30 },
>   { "v": 21.5, "t": 40 },
>   { "v": 21.5, "t": 50 },
>   { "v": 21.5, "t": 60 },
>   { "v": 21.6, "t": 70 },
>   { "v": 21.7, "t": 80 },
>   { "v": 21.5, "t": 90 },
> ...
>=20
> NEW=20
>=20
> [ {"bn": "http://[2001:db8::1]",
>  "bt": 1320067464,
>  "bu": "%RH"},
>   { "v": 21.2, "t": 0 },
>   { "v": 21.3, "t": 10 },
>   { "v": 21.4, "t": 20 },
>   { "v": 21.4, "t": 30 },
>   { "v": 21.5, "t": 40 },
>   { "v": 21.5, "t": 50 },
>   { "v": 21.5, "t": 60 },
>   { "v": 21.6, "t": 70 },
>   { "v": 21.7, "t": 80 },
>   { "v": 21.5, "t": 90 },
> ...
>=20
>=20
> The draft does not have it yet but an applications that supports =
receiving streaming is written is a substantially different way that one =
that does not. I think the best way to deal with this is simply use a =
different mine type for streaming ( calls it senml_stream for now but =
send me suggestions on name for it). That way it can be clearly =
indicated and negotiated in existing transport protocols.=20
>=20
> Appreciate any thoughts people have on pro / cons of the -03 design vs =
-04 design.
>=20
>=20
>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


--Apple-Mail=_5F96250A-4C95-4D78-8C35-44E48418CC83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi,

I have been working with JSON =
serializations of senml and link data lately and I have some comments on =
the new SenML draft. I haven=E2=80=99t kept up with the format changes =
because I have something already working that I like that is based on =
the senml core wg draft-01. 

There are two problems with the new =
formats (-02 and -04) for my use case. The first is that I have added =
more element types to extend senml to represent collections that may =
have links, forms, and data items. The second is the issue of mapping =
vs. streaming as discussed previously.  First, I=E2=80=99ll try to =
explain the issue as I see it with mapping vs. streaming.

This is =
how the =E2=80=9Ccollection=E2=80=9D example appears in section =
6.1.4 of draft-04:

   [{"bn": "http://[2001:db8::2]/",
     "bt": 1320078429,
     "ver": 3},
      { "n": "temperature", "v": 27.2, "u": "Cel" },
      { "n": "humidity", "v": 80, "u": "%RH" }
   ]


The =
block formatting of the first map and addition of whitespace to the =
second 2 maps gives the visual impression that there is some =
hierarchy. The reformatted example below using standard =
json pretty print makes it easier to see how this parses into =
a data structure using standard json tools. I=E2=80=99d recommend =
following this format to make the examples consistent and easy to read. =
I will do the same in my drafts.

[
  {
    "bn": =
"http://[2001:db8::2]/",
  =
  "bt": 1320078429,
    "ver": =
3
  },
  {
    "n": =
"temperature",
    "u": =
"Cel",
    "v": 27.2
  },
  {
    "n": =
"humidity",
    "u": =
"%RH",
    "v": 80
  }
]
As pointed =
out, the streaming format can only be processed in streaming form. =
Storing this in memory using a JSON parser does not result in a =
structure that can be easily sorted or indexed by base element. If I =
were to design a parser for this, it would have a state machine that =
would consume the top level array elements in sequence and create an =
in-memory structure that looks like the structures described in =
draft-02:

[
  {
  =
  "bn": "http://[2001:db8::2]/",
    "bt": 1320078429,
    "ver": 1
  },
  =
[
    =
{
      "n": =
"temperature",
    =
  "u": "Cel",
    =
  "v": 27.2
    =
},
    =
{
      "n": =
"humidity",
      "u": =
"%RH",
      "v": =
80
    =
}
  ]
]
Or =
draft-01:

{
 =
 "bn": "http://[2001:db8::2]/",
  "bt": =
1320078429,
  "ver": 1
 =
 "e": [
    {
 =
     "n": "temperature",
      =
"u": "Cel",
      "v": =
27.2
    },
    =
{
      "n": "humidity",
 =
     "u": "%RH",
      "v": =
80
    }
  ],
}
With these =
earlier structures I could use standard JSON parse tools and then =
selection algorithms that match the =E2=80=9Cbn=E2=80=9D value and =
select the contents within that item=E2=80=99s scope (for patching, =
etc.). With the streaming formats I need to add another level of =
serialize/deserialize between the content format and the actual program =
data model and process elements in order.

IOW, I already have a JSON parser and a =
JSON data structure filter that work together. Now with this format =
change, I need to add another layer of deserializing to create an index =
or remap the base elements.

The other issue is that in draft-01 the element tag =E2=80=9Ce=
=E2=80=9D maps to the XML serialization <e/> tags nicely. I have =
tools that process both XML and JSON that understand this. Also, this is =
easily extensible to add more element classes to the senml data model, =
which I have done of links and forms.

{
  "bn": =
"/",
  "e": [
    =
{
      "n": "test",
    =
  "sv": "testValue"
    }
  ],
  "l": [
    =
{
      "href": "",
    =
  "rel": [
        =
"self"
      ]
    =
},
    {
      =
"href": "test",
      "rel": =
"sub"
    }
  ]
}


I have indicated this with a content format =
=E2=80=9Ccollection+senml+json=E2=80=9D, to indicate the senml data =
model with a collection extension or subtype.

Since the recent changes in senml, I =
have considered forking -01 and creating a new set of media types called =
hyper-senml, or =E2=80=9Chsml=E2=80=9D, so =E2=80=9Capplication/hsml+json=E2=
=80=9D, =E2=80=9Capplication/hsml+xml=E2=80=9D, =
=E2=80=9Capplication/collection+hsml+json=E2=80=9D, etc.

I guess my preferred =
outcome would be a senml optimized for mapping that looks like -01 and =
can be extended to add element classes, and a separate, streaming =
optimized format.

Best regards,

Michael


On Jan 13, 2016, at 5:57 AM, Cullen Jennings =
(fluffy) <fluffy@cisco.com> wrote:

The changes we made =
to SenML to support streaming in the -02 version raised many issues for =
lots of people. In the end, one of the biggest problems is it forces all =
things receiving SenML to support streaming. 

I have an alternative design for streaming that I think =
addresses the issues raised and I would like the WG to think about two =
alternative designs for SenML and give me some direction on which one to =
use. 

The first design is the current -02 =
design with simple fixes and is in draft draft-jennings-core-senml-03

The second design is the new design I am =
proposing and is in draft-jennings-core-senml-04. It many way it moves =
back to be much closer to what was in -01 than what is in -02. 

The drafts can be found at 

https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/<=
/a>

and 

https://datatracker.ietf.org/doc/draft-jennings-core-senml/04/<=
br class=3D"">

Practically speaking the =
differences are not that much between the two but they do resolve a =
bunch of the issue. Let me discuss this in terms of the JSON =
representation and the rest of the representations mirror that.  In =
the new design measurements are put in JSON object as always. The object =
are put in array to represent a series of measurements. The objects can =
also have the base values right in the object and the base values apply =
to all the things in the object and any future objects in the array. 

Here is an example of something that is not a =
stream in both old and new design.

OLD 

[{"bn": "urn:dev:mac:0024befffe804ff1/"},
 [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
   { "n": "current", "t": 0, "u": "A", "v": 1.2 } =
]
]

NEW

[{"bn": "urn:dev:mac:0024befffe804ff1/"},
 { =
"n": "voltage", "t": 0, "u": "V", "v": 120.1 },
 { "n": =
"current", "t": 0, "u": "A", "v": 1.2 } 
]
Note the old design has an array with a base object, =
followed by a second array of measurements. The new design just has an =
single array and the first object happens to only have base values that =
apply to future object in the array. 

This =
could also be sent as

[
 =
   {
	"t": 0, 
 =
     	"n": "voltage", 
	=
"u": "V", 
     	"bn": =
"urn:dev:mac:0024befffe804ff1/",
	"v": =
120.1
   },
   { 
	=
"n": "current", 
	"t": 0, 
	"u": "A", =

	=
"v": 1.2 
   } 
]

Here is an example of streaming with old and =
new design 

OLD 

[{"bn": "http://[2001:db8::1]",
  "bt": =
1320067464,
  "bu": "%RH"},
 [ { "v": =
21.2, "t": 0 },
   { "v": 21.3, "t": 10 },
   { "v": 21.4, "t": 20 },
 =
  { "v": 21.4, "t": 30 },
   { "v": =
21.5, "t": 40 },
   { "v": 21.5, "t": 50 },
   { "v": 21.5, "t": 60 },
 =
  { "v": 21.6, "t": 70 },
   { "v": =
21.7, "t": 80 },
   { "v": 21.5, "t": 90 },
...

NEW 

[ {"bn": "http://[2001:db8::1]",
  "bt": =
1320067464,
  "bu": "%RH"},
 =
  { "v": 21.2, "t": 0 },
   { "v": =
21.3, "t": 10 },
   { "v": 21.4, "t": 20 },
   { "v": 21.4, "t": 30 },
 =
  { "v": 21.5, "t": 40 },
   { "v": =
21.5, "t": 50 },
   { "v": 21.5, "t": 60 },
   { "v": 21.6, "t": 70 },
 =
  { "v": 21.7, "t": 80 },
   { "v": =
21.5, "t": 90 },
...


The draft does not have it yet but an applications that =
supports receiving streaming is written is a substantially different way =
that one that does not. I think the best way to deal with this is simply =
use a different mine type for streaming ( calls it senml_stream for now =
but send me suggestions on name for it). That way it can be clearly =
indicated and negotiated in existing transport protocols. 

Appreciate any thoughts people have on pro / =
cons of the -03 design vs -04 design.




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

=

--Apple-Mail=_5F96250A-4C95-4D78-8C35-44E48418CC83--


From nobody Thu Jan 14 19:04:23 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0BF1A888A for ; Thu, 14 Jan 2016 19:04:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham
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 20Eu5XIc6akd for ; Thu, 14 Jan 2016 19:04:18 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 CC0AA1A8886 for ; Thu, 14 Jan 2016 19:04:18 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id q63so113371250pfb.1 for ; Thu, 14 Jan 2016 19:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/2+QBejbWjRl9Ub247BkD6THBdD1xNQAZbXaS4nc2p4=; b=ZXiTBObolEhDbCBN21ktVh02rb/mHZifeoOK7OwZzStMasmo4dRnHTscmudbNQbknq KkTWmEYHeF79ViWyoWQvkVpMUyty7rCRnGFFPpel0DN78o9q57iCJc0yZgZMzngO0kCw B2J8ytFoQTlXKSnnz1OB6Wh3qWw+ePcy0Tv70Zc4aWnf2pFb77eXCEYdRAlyfEd6TSlA 8z0/1HoEC9ShP4wZ85exKuPK9m8/V2rBbqdWK6Ee6ZfZClEXYqoyzXkMChuDPAH2GWa5 2pZJsPlaZc3nZe5n3QI7+Rh25xPjHkK8A/Nm9BTUnFZyDYp5/SzjC2Y5rtXbWFg/ZzCh HoDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=/2+QBejbWjRl9Ub247BkD6THBdD1xNQAZbXaS4nc2p4=; b=DlABARW302lLrw18XzixYseJTes98sBg5Z/kqcun7Qkpkah4u7yfyBzrtZWt3g00ep 9Gp8Nchdw5Ys92EK5Xqr7dq84/pid+uCqhQwenTQoCH0ZSgQkU5C3l5yJ0s3ZmG8c1m8 +M/26HejGaV6Muw+cUoMMgpMKl1zrT45M2hQtb3v5kuMsVINa9vYPNJovreuLgjhnkHn syqRMuxCQkwjhVZulY5kMX+VivmiHzD8uG18MUrnwH3HRGDHTAWOB2tFncB5EGPMa4yZ kEzea+9lulWr7S4B6G5YDcWBtLFwtJZa2QB2rI6nIWZ3awqM1hc6Zg9CQX0t1+g0YdH7 6R/g==
X-Gm-Message-State: AG10YOR8HBWaLrRmZ25QHiI3hqiZ/sr/UDHKHK9tAzQ6WjG1RLTbz2wOc+OUtMInCSA6UA==
X-Received: by 10.98.0.66 with SMTP id 63mr5813131pfa.61.1452827058451; Thu, 14 Jan 2016 19:04:18 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id sm8sm12105191pac.43.2016.01.14.19.04.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jan 2016 19:04:17 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_18A2B176-3F4E-4EFB-AB9B-49F1A1F53333"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
Date: Thu, 14 Jan 2016 19:04:15 -0800
Message-Id: <7ABA380B-AEA8-4025-B582-2C168CAEE6D3@gmail.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
To: "Cullen Jennings (fluffy)" 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 03:04:22 -0000

--Apple-Mail=_18A2B176-3F4E-4EFB-AB9B-49F1A1F53333
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Note: A reference implementation (in progress) of the Hypermedia =
Collection described in =
https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ =
 uses the =
collection+senml content type mentioned below and is available at =
https://github.com/mjkoster/MachineHypermediaToolkit =
 for an example of =
the use case.

> On Jan 14, 2016, at 6:43 PM, Michael Koster =
 wrote:
>=20
> Hi,
>=20
> I have been working with JSON serializations of senml and link data =
lately and I have some comments on the new SenML draft. I haven=E2=80=99t =
kept up with the format changes because I have something already working =
that I like that is based on the senml core wg draft-01.=20
>=20
> There are two problems with the new formats (-02 and -04) for my use =
case. The first is that I have added more element types to extend senml =
to represent collections that may have links, forms, and data items. The =
second is the issue of mapping vs. streaming as discussed previously.  =
First, I=E2=80=99ll try to explain the issue as I see it with mapping =
vs. streaming.
>=20
> This is how the =E2=80=9Ccollection=E2=80=9D example appears in =
section 6.1.4 of draft-04:
>=20
>    [{"bn": "http://[2001:db8::2]/ ",
>      "bt": 1320078429,
>      "ver": 3},
>       { "n": "temperature", "v": 27.2, "u": "Cel" },
>       { "n": "humidity", "v": 80, "u": "%RH" }
>    ]
>=20
> The block formatting of the first map and addition of whitespace to =
the second 2 maps gives the visual impression that there is some =
hierarchy. The reformatted example below using standard json pretty =
print makes it easier to see how this parses into a data structure using =
standard json tools. I=E2=80=99d recommend following this format to make =
the examples consistent and easy to read. I will do the same in my =
drafts.
>=20
> [
>   {
>     "bn": "http://[2001:db8::2]/ ",
>     "bt": 1320078429,
>     "ver": 3
>   },
>   {
>     "n": "temperature",
>     "u": "Cel",
>     "v": 27.2
>   },
>   {
>     "n": "humidity",
>     "u": "%RH",
>     "v": 80
>   }
> ]
> As pointed out, the streaming format can only be processed in =
streaming form. Storing this in memory using a JSON parser does not =
result in a structure that can be easily sorted or indexed by base =
element. If I were to design a parser for this, it would have a state =
machine that would consume the top level array elements in sequence and =
create an in-memory structure that looks like the structures described =
in draft-02:
>=20
> [
>   {
>     "bn": "http://[2001:db8::2]/ ",
>     "bt": 1320078429,
>     "ver": 1
>   },
>   [
>     {
>       "n": "temperature",
>       "u": "Cel",
>       "v": 27.2
>     },
>     {
>       "n": "humidity",
>       "u": "%RH",
>       "v": 80
>     }
>   ]
> ]
> Or draft-01:
>=20
> {
>   "bn": "http://[2001:db8::2]/ ",
>   "bt": 1320078429,
>   "ver": 1
>   "e": [
>     {
>       "n": "temperature",
>       "u": "Cel",
>       "v": 27.2
>     },
>     {
>       "n": "humidity",
>       "u": "%RH",
>       "v": 80
>     }
>   ],
> }
> With these earlier structures I could use standard JSON parse tools =
and then selection algorithms that match the =E2=80=9Cbn=E2=80=9D value =
and select the contents within that item=E2=80=99s scope (for patching, =
etc.). With the streaming formats I need to add another level of =
serialize/deserialize between the content format and the actual program =
data model and process elements in order.
>=20
> IOW, I already have a JSON parser and a JSON data structure filter =
that work together. Now with this format change, I need to add another =
layer of deserializing to create an index or remap the base elements.
>=20
> The other issue is that in draft-01 the element tag =E2=80=9Ce=E2=80=9D =
maps to the XML serialization  tags nicely. I have tools that =
process both XML and JSON that understand this. Also, this is easily =
extensible to add more element classes to the senml data model, which I =
have done of links and forms.
>=20
> {
>   "bn": "/",
>   "e": [
>     {
>       "n": "test",
>       "sv": "testValue"
>     }
>   ],
>   "l": [
>     {
>       "href": "",
>       "rel": [
>         "self"
>       ]
>     },
>     {
>       "href": "test",
>       "rel": "sub"
>     }
>   ]
> }
>=20
> I have indicated this with a content format =
=E2=80=9Ccollection+senml+json=E2=80=9D, to indicate the senml data =
model with a collection extension or subtype.
>=20
> Since the recent changes in senml, I have considered forking -01 and =
creating a new set of media types called hyper-senml, or =E2=80=9Chsml=E2=80=
=9D, so =E2=80=9Capplication/hsml+json=E2=80=9D, =
=E2=80=9Capplication/hsml+xml=E2=80=9D, =
=E2=80=9Capplication/collection+hsml+json=E2=80=9D, etc.
>=20
> I guess my preferred outcome would be a senml optimized for mapping =
that looks like -01 and can be extended to add element classes, and a =
separate, streaming optimized format.
>=20
> Best regards,
>=20
> Michael
>=20
>=20
>> On Jan 13, 2016, at 5:57 AM, Cullen Jennings (fluffy) =
> wrote:
>>=20
>> The changes we made to SenML to support streaming in the -02 version =
raised many issues for lots of people. In the end, one of the biggest =
problems is it forces all things receiving SenML to support streaming.=20=

>>=20
>> I have an alternative design for streaming that I think addresses the =
issues raised and I would like the WG to think about two alternative =
designs for SenML and give me some direction on which one to use.=20
>>=20
>> The first design is the current -02 design with simple fixes and is =
in draft draft-jennings-core-senml-03
>>=20
>> The second design is the new design I am proposing and is in =
draft-jennings-core-senml-04. It many way it moves back to be much =
closer to what was in -01 than what is in -02.=20
>>=20
>> The drafts can be found at=20
>>=20
>> https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/ =

>>=20
>> and=20
>>=20
>> https://datatracker.ietf.org/doc/draft-jennings-core-senml/04/
>>=20
>>=20
>> Practically speaking the differences are not that much between the =
two but they do resolve a bunch of the issue. Let me discuss this in =
terms of the JSON representation and the rest of the representations =
mirror that.  In the new design measurements are put in JSON object as =
always. The object are put in array to represent a series of =
measurements. The objects can also have the base values right in the =
object and the base values apply to all the things in the object and any =
future objects in the array.=20
>>=20
>> Here is an example of something that is not a stream in both old and =
new design.
>>=20
>> OLD=20
>>=20
>> [{"bn": "urn:dev:mac:0024befffe804ff1/"},
>> [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
>>   { "n": "current", "t": 0, "u": "A", "v": 1.2 } ]
>> ]
>>=20
>> NEW
>>=20
>> [{"bn": "urn:dev:mac:0024befffe804ff1/"},
>> { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
>> { "n": "current", "t": 0, "u": "A", "v": 1.2 }=20
>> ]
>>=20
>> Note the old design has an array with a base object, followed by a =
second array of measurements. The new design just has an single array =
and the first object happens to only have base values that apply to =
future object in the array.=20
>>=20
>> This could also be sent as
>>=20
>> [
>>    {
>> 	"t": 0,=20
>>      	"n": "voltage",=20
>> 	"u": "V",=20
>>     	"bn": "urn:dev:mac:0024befffe804ff1/",
>> 	"v": 120.1
>>   },
>>   {=20
>> 	"n": "current",=20
>> 	"t": 0,=20
>> 	"u": "A",=20
>> 	"v": 1.2=20
>>   }=20
>> ]
>>=20
>> Here is an example of streaming with old and new design=20
>>=20
>> OLD=20
>>=20
>> [{"bn": "http://[2001:db8::1]",
>>  "bt": 1320067464,
>>  "bu": "%RH"},
>> [ { "v": 21.2, "t": 0 },
>>   { "v": 21.3, "t": 10 },
>>   { "v": 21.4, "t": 20 },
>>   { "v": 21.4, "t": 30 },
>>   { "v": 21.5, "t": 40 },
>>   { "v": 21.5, "t": 50 },
>>   { "v": 21.5, "t": 60 },
>>   { "v": 21.6, "t": 70 },
>>   { "v": 21.7, "t": 80 },
>>   { "v": 21.5, "t": 90 },
>> ...
>>=20
>> NEW=20
>>=20
>> [ {"bn": "http://[2001:db8::1]",
>>  "bt": 1320067464,
>>  "bu": "%RH"},
>>   { "v": 21.2, "t": 0 },
>>   { "v": 21.3, "t": 10 },
>>   { "v": 21.4, "t": 20 },
>>   { "v": 21.4, "t": 30 },
>>   { "v": 21.5, "t": 40 },
>>   { "v": 21.5, "t": 50 },
>>   { "v": 21.5, "t": 60 },
>>   { "v": 21.6, "t": 70 },
>>   { "v": 21.7, "t": 80 },
>>   { "v": 21.5, "t": 90 },
>> ...
>>=20
>>=20
>> The draft does not have it yet but an applications that supports =
receiving streaming is written is a substantially different way that one =
that does not. I think the best way to deal with this is simply use a =
different mine type for streaming ( calls it senml_stream for now but =
send me suggestions on name for it). That way it can be clearly =
indicated and negotiated in existing transport protocols.=20
>>=20
>> Appreciate any thoughts people have on pro / cons of the -03 design =
vs -04 design.
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>=20


--Apple-Mail=_18A2B176-3F4E-4EFB-AB9B-49F1A1F53333
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Note: A reference implementation (in progress) of the =
Hypermedia Collection described in https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ uses the collection+senml content type mentioned below and is =
available at https://github.com/mjkoster/MachineHypermediaToolkit f=
or an example of the use case.

On =
Jan 14, 2016, at 6:43 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi,

I=
 have been working with JSON serializations of senml and link data =
lately and I have some comments on the new SenML draft. I haven=E2=80=99t =
kept up with the format changes because I have something already working =
that I like that is based on the senml core wg draft-01. 

There are two problems =
with the new formats (-02 and -04) for my use case. The first is that I =
have added more element types to extend senml to represent collections =
that may have links, forms, and data items. The second is the issue of =
mapping vs. streaming as discussed previously.  First, I=E2=80=99ll =
try to explain the issue as I see it with mapping vs. =
streaming.

This is how the =E2=80=9Ccollection=E2=80=9D example =
appears in section 6.1.4 of draft-04:

   [{"bn": "http://[2001:db8::2]/",
     "bt": 1320078429,
     "ver": 3},
      { "n": "temperature", "v": 27.2, "u": "Cel" },
      { "n": "humidity", "v": 80, "u": "%RH" }
   ]


The =
block formatting of the first map and addition of whitespace to the =
second 2 maps gives the visual impression that there is some =
hierarchy. The reformatted example below using standard =
json pretty print makes it easier to see how this parses into =
a data structure using standard json tools. I=E2=80=99d recommend =
following this format to make the examples consistent and easy to read. =
I will do the same in my drafts.

[
  {
    "bn": =
"http://[2001:db8::2]/",
  =
  "bt": 1320078429,
    "ver": =
3
  },
  {
    "n": =
"temperature",
    "u": =
"Cel",
    "v": 27.2
  },
  {
    "n": =
"humidity",
    "u": =
"%RH",
    "v": 80
  }
]
As pointed =
out, the streaming format can only be processed in streaming form. =
Storing this in memory using a JSON parser does not result in a =
structure that can be easily sorted or indexed by base element. If I =
were to design a parser for this, it would have a state machine that =
would consume the top level array elements in sequence and create an =
in-memory structure that looks like the structures described in =
draft-02:

[
  {
  =
  "bn": "http://[2001:db8::2]/",
    "bt": 1320078429,
    "ver": 1
  },
  =
[
    =
{
      "n": =
"temperature",
    =
  "u": "Cel",
    =
  "v": 27.2
    =
},
    =
{
      "n": =
"humidity",
      "u": =
"%RH",
      "v": =
80
    =
}
  ]
]
Or =
draft-01:

{
 =
 "bn": "http://[2001:db8::2]/",
  "bt": =
1320078429,
  "ver": 1
 =
 "e": [
    {
 =
     "n": "temperature",
      =
"u": "Cel",
      "v": =
27.2
    },
    =
{
      "n": "humidity",
 =
     "u": "%RH",
      "v": =
80
    }
  ],
}
With these =
earlier structures I could use standard JSON parse tools and then =
selection algorithms that match the =E2=80=9Cbn=E2=80=9D value and =
select the contents within that item=E2=80=99s scope (for patching, =
etc.). With the streaming formats I need to add another level of =
serialize/deserialize between the content format and the actual program =
data model and process elements in order.

IOW, I already have a JSON parser and a =
JSON data structure filter that work together. Now with this format =
change, I need to add another layer of deserializing to create an index =
or remap the base elements.

The other issue is that in draft-01 the element tag =E2=80=9Ce=
=E2=80=9D maps to the XML serialization <e/> tags nicely. I have =
tools that process both XML and JSON that understand this. Also, this is =
easily extensible to add more element classes to the senml data model, =
which I have done of links and forms.

{
  "bn": =
"/",
  "e": [
    =
{
      "n": "test",
    =
  "sv": "testValue"
    }
  ],
  "l": [
    =
{
      "href": "",
    =
  "rel": [
        =
"self"
      ]
    =
},
    {
      =
"href": "test",
      "rel": =
"sub"
    }
  ]
}


I have indicated this with a content format =
=E2=80=9Ccollection+senml+json=E2=80=9D, to indicate the senml data =
model with a collection extension or subtype.

Since the recent changes in senml, I =
have considered forking -01 and creating a new set of media types called =
hyper-senml, or =E2=80=9Chsml=E2=80=9D, so =E2=80=9Capplication/hsml+json=E2=
=80=9D, =E2=80=9Capplication/hsml+xml=E2=80=9D, =
=E2=80=9Capplication/collection+hsml+json=E2=80=9D, etc.

I guess my preferred =
outcome would be a senml optimized for mapping that looks like -01 and =
can be extended to add element classes, and a separate, streaming =
optimized format.

Best regards,

Michael


On Jan 13, 2016, at 5:57 AM, Cullen Jennings =
(fluffy) <fluffy@cisco.com> wrote:

The changes we made =
to SenML to support streaming in the -02 version raised many issues for =
lots of people. In the end, one of the biggest problems is it forces all =
things receiving SenML to support streaming. 

I have an alternative design for streaming that I think =
addresses the issues raised and I would like the WG to think about two =
alternative designs for SenML and give me some direction on which one to =
use. 

The first design is the current -02 =
design with simple fixes and is in draft draft-jennings-core-senml-03

The second design is the new design I am =
proposing and is in draft-jennings-core-senml-04. It many way it moves =
back to be much closer to what was in -01 than what is in -02. 

The drafts can be found at 

https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/<=
/a>

and 

https://datatracker.ietf.org/doc/draft-jennings-core-senml/04/<=
/a>


Practically speaking the =
differences are not that much between the two but they do resolve a =
bunch of the issue. Let me discuss this in terms of the JSON =
representation and the rest of the representations mirror that.  In =
the new design measurements are put in JSON object as always. The object =
are put in array to represent a series of measurements. The objects can =
also have the base values right in the object and the base values apply =
to all the things in the object and any future objects in the array. 

Here is an example of something that is not a =
stream in both old and new design.

OLD 

[{"bn": "urn:dev:mac:0024befffe804ff1/"},
 [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
   { "n": "current", "t": 0, "u": "A", "v": 1.2 } =
]
]

NEW

[{"bn": "urn:dev:mac:0024befffe804ff1/"},
 { =
"n": "voltage", "t": 0, "u": "V", "v": 120.1 },
 { "n": =
"current", "t": 0, "u": "A", "v": 1.2 } 
]
Note the old design has an array with a base object, =
followed by a second array of measurements. The new design just has an =
single array and the first object happens to only have base values that =
apply to future object in the array. 

This =
could also be sent as

[
 =
   {
	"t": 0, 
 =
     	"n": "voltage", 
	=
"u": "V", 
     	"bn": =
"urn:dev:mac:0024befffe804ff1/",
	"v": =
120.1
   },
   { 
	=
"n": "current", 
	"t": 0, 
	"u": "A", =

	=
"v": 1.2 
   } 
]

Here is an example of streaming with old and =
new design 

OLD 

[{"bn": "http://[2001:db8::1]",
  "bt": =
1320067464,
  "bu": "%RH"},
 [ { "v": =
21.2, "t": 0 },
   { "v": 21.3, "t": 10 },
   { "v": 21.4, "t": 20 },
 =
  { "v": 21.4, "t": 30 },
   { "v": =
21.5, "t": 40 },
   { "v": 21.5, "t": 50 },
   { "v": 21.5, "t": 60 },
 =
  { "v": 21.6, "t": 70 },
   { "v": =
21.7, "t": 80 },
   { "v": 21.5, "t": 90 },
...

NEW 

[ {"bn": "http://[2001:db8::1]",
  "bt": =
1320067464,
  "bu": "%RH"},
 =
  { "v": 21.2, "t": 0 },
   { "v": =
21.3, "t": 10 },
   { "v": 21.4, "t": 20 },
   { "v": 21.4, "t": 30 },
 =
  { "v": 21.5, "t": 40 },
   { "v": =
21.5, "t": 50 },
   { "v": 21.5, "t": 60 },
   { "v": 21.6, "t": 70 },
 =
  { "v": 21.7, "t": 80 },
   { "v": =
21.5, "t": 90 },
...


The draft does not have it yet but an applications that =
supports receiving streaming is written is a substantially different way =
that one that does not. I think the best way to deal with this is simply =
use a different mine type for streaming ( calls it senml_stream for now =
but send me suggestions on name for it). That way it can be clearly =
indicated and negotiated in existing transport protocols. 

Appreciate any thoughts people have on pro / =
cons of the -03 design vs -04 design.




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


=

--Apple-Mail=_18A2B176-3F4E-4EFB-AB9B-49F1A1F53333--


From nobody Fri Jan 15 00:41:48 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4784D1A89B3 for ; Fri, 15 Jan 2016 00:41:46 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
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_05=-0.5, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3] autolearn=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 jEqNTyiOJ3wd for ; Fri, 15 Jan 2016 00:41:44 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661D61A89B1 for ; Fri, 15 Jan 2016 00:41:44 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id CC9644184F; Fri, 15 Jan 2016 09:41:41 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4A8A82D; Fri, 15 Jan 2016 09:41:39 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CD9D92F; Fri, 15 Jan 2016 09:41:38 +0100 (CET)
Received: (nullmailer pid 27834 invoked by uid 1000); Fri, 15 Jan 2016 08:41:38 -0000
Date: Fri, 15 Jan 2016 09:41:38 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Michael Koster 
Message-ID: <20160115084138.GA18563@hephaistos.amsuess.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0"
Content-Disposition: inline
In-Reply-To: <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 08:41:46 -0000

--k+w/mQv8wyuph6w0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Michael,

On Thu, Jan 14, 2016 at 06:43:38PM -0800, Michael Koster wrote:
> As pointed out, the streaming format can only be processed in
> streaming form. Storing this in memory using a JSON parser does not
> result in a structure that can be easily sorted or indexed by base
> element. If I were to design a parser for this, it would have a state
> machine that would consume the top level array elements in sequence
> and create an in-memory structure that looks like the structures
> described in draft-02:

thank you for clarifying what's meant by "forced to do stream
processing" (after all, I thought, you can still buffer things).

As I understand it, your concern is keeping your language's native
representation of the JSON structures as the internal state of your
SenML objects -- I'll argue that this is possible with -3 as well as
with -2.

> With these earlier structures I could use standard JSON parse tools
> and then selection algorithms that match the =E2=80=9Cbn=E2=80=9D value a=
nd select the
> contents within that item=E2=80=99s scope (for patching, etc.)

I'll be assuming a Python implementation derived from
resource/SenmlHandler.py in your MachineHypermediaToolkit; other query
schemes should be similar to adapt. I'll also assume an older variant of
-03 where there are only two top-level elements allowed (the even-odd
scheme came from another thread) in the interest of brevity, but would
be happy to demonstrate a repeating-elements version if this is
unsatisfying.

Where a -01 implementation would be initialized as

    class Senml():
        def __init__(self, items=3DNone, baseName=3DNone):
            self._items =3D SenmlItems(items)
            self._senml =3D {}
            self._senml["e"] =3D self._items._items

replacing the last two lines with

            self._senml =3D [{}, self._items._items]

deals with the item locations, and base name assignment goes from

    self._senml["bn"] =3D baseName

to

    self._senml[0]["bn"] =3D baseName

=2E One or two more changes along similar lines should have the code base
covered, with no changes to SenmlItems being required.


That being said, I think that even with -01, such a data structure might
not be an ideal candidate for many applications, because it necessitates
(even though unimplemented in MachineHypermediaToolkit) that access to
both event names and values, they be added to the respective base
values for meaningful comparison. When elements are accessed repeatedly,
going over the whole structure at read time and building decompressed
values in memory would make things more straightforward as a whole. I
don't want to get into a discussion about implementation of memory
structures, though -- my point is that the mechanisms that incite such
discussion are present both in -01 and later.

> The other issue is that in draft-01 the element tag =E2=80=9Ce=E2=80=9D m=
aps to the
> XML serialization  tags nicely. I have tools that process both XML
> and JSON that understand this.

Both -03 and -04 update their XML serializations to match the JSON
pretty. I see shortcomings in -03 (how would extensions with non-scalar
data store their elements in the head?), but they could probably be
mitigated by moving the head elements in a dedicated  element
and all the children into an  element.

> Also, this is easily extensible to add more element classes to the
> senml data model, which I have done of links and forms.

How is this not possible any more by adding them to the first
dictionary?

Extensions whose interpretations do not depend on "bn" or other entries
in the base dictionary are even processable easily by constrained
devices.

(I'm still unconvinced that a root "l":{links} is better than a
"v":{links} in elements, but would prefer to stick to the topic of "is
-03/-04 a regression" here).


I'm confident we can work a single SenML that works for all relevant
applications.

Christian

--=20
You don't become great by trying to be great. You become great by
wanting to do something, and then doing it so hard that you become great
in the process.
  -- Marie Curie (as quoted by Randall Munroe)

--k+w/mQv8wyuph6w0
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWmLC+AAoJEDmNERLTpL3hjC0P/j2Z84fAzSECOPzp9LMMA2Kx
j6TRLVUaBYErDyA00hBucxw5oCUK9lVb8kTLMejrLtnUvU1eiC9V+jWbotkF0l2l
S2rOH8yebzzKcEDYxIRZ8npFDzUS/IfGVT8/WdqcNutrpnm7Kjp/4EPuvisaiHMP
3Wyi61M1qi5FZcA+yzf5dRqvXF+b4ojsXmClyUjjaTvrpREMBCPjPjeTm2XWKwXI
onb4l5dGSpBmKAXDM+WK7vKckVCYd9PpJ/c6VUCGPg2RAwpMuK+IiWisId+kd6M/
hihpxDQhVh+f7eTiDo7TwSQC5TicIo+Xmfi1UPnAnsQnvZ3AbxY/7zs/MEncbGfB
Qx+N4AGUxV8BAJvcL7Wmgx03h5bur2uT+SyzZQ5Sa1P+8SPmDW8gAgjOVym6jhPq
4/M140LLq5SDgTaXE7VXNcuo+CclA4I6aKr4HlnN5jIxAElcoCKDt5tez9IYrcJd
SLRFxgClCZmxkKjzfaYxeP1VQXYrIJI0gllqZKn9cx0jPfp1rmtpZRYw/sWz7DGy
0Ui89haZ9vj3yj/YRpeXCJ4Qhj1NXILpY2INMu0W0KYLRfgmWYKmsYPlEDoO4rU+
tSf9hKlMOBlyxyJPDve+JTrYq3BlD6V8Gs0k5Lg7tzBLT//NUhr+IXpbBpE9Kk+B
gsFhcT84GVZezMKxI72z
=e7Pi
-----END PGP SIGNATURE-----

--k+w/mQv8wyuph6w0--


From nobody Fri Jan 15 01:17:37 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4881A8AFE for ; Fri, 15 Jan 2016 01:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 A5ObBncThWeZ for ; Fri, 15 Jan 2016 01:17:34 -0800 (PST)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E9A1A8AF6 for ; Fri, 15 Jan 2016 01:17:34 -0800 (PST)
Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1A5AA41C0B1; Fri, 15 Jan 2016 10:17:33 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 4VTqpAGDmm3R; Fri, 15 Jan 2016 10:17:31 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 65D0C41C0A2; Fri, 15 Jan 2016 10:17:31 +0100 (CET)
Message-ID: <5698B929.90008@tzi.org>
Date: Fri, 15 Jan 2016 10:17:29 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Michael Koster 
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
In-Reply-To: <85DB69FC-A20E-4314-AAB0-5E8AA8B5E5E6@gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 09:17:35 -0000

Indeed, SenML -01 is optimized for implementations that ingest the
entire SenML document and then work on the result -- exactly what
happens in your Python implementation.

What -02 was trying to do was to also enable implementations operating
sequentially (what somewhat misleadingly has been called "streaming" --
well yes, enabling sequential processing is a prerequisite to enabling
streaming, but streaming is not the only reason for wanting to enable
sequential processing).

But of course this should not detract from the usefulness of the format
for ingest-bang implementations.
I think the structure in -02 is quite close to meeting both objectives.
I agree that the recent changes have led us away from that.

(I must admit I don't care as much about a complete analogy between XML
and CBOR formats; but as we now have found someone who cares about the
XML variant, we might be able to fix that.)

Grüße, Carsten


From nobody Sat Jan 16 05:27:59 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D7C1A8851 for ; Sat, 16 Jan 2016 05:27:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.299
X-Spam-Level: 
X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3] autolearn=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 SBOr5SOREj1I for ; Sat, 16 Jan 2016 05:27:56 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0221C1A884F for ; Sat, 16 Jan 2016 05:27:55 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D7A0B41880; Sat, 16 Jan 2016 14:27:52 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 096912D; Sat, 16 Jan 2016 14:27:52 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CC9582E; Sat, 16 Jan 2016 14:27:51 +0100 (CET)
Received: (nullmailer pid 3812 invoked by uid 1000); Sat, 16 Jan 2016 13:27:51 -0000
Date: Sat, 16 Jan 2016 14:27:51 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: "Cullen Jennings (fluffy)" 
Message-ID: <20160116132751.GB18563@hephaistos.amsuess.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5/uDoXvLw7AC5HRs"
Content-Disposition: inline
In-Reply-To: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 13:27:58 -0000

--5/uDoXvLw7AC5HRs
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Cullen,

On Wed, Jan 13, 2016 at 01:57:02PM +0000, Cullen Jennings (fluffy) wrote:
> The objects can also have the base values right in the object and the
> base values apply to all the things in the object and any future
> objects in the array.=20
>
> Appreciate any thoughts people have on pro / cons of the -03 design vs -0=
4 design.

The -03 draft is parsable with minimum RAM: I've assembled a crude
demo[1] that shows that given a list of known integer-valued resources
on a device, it is possible to parse incoming SenML-03 with less than 30
bytes of state, with support for arbitrary SenML extensions, all legal
JSON number representations and full URL concatenation semantics.

With the -04 draft, one would have to allocate a buffer for the "n"
value, because before the object finishes, the "bn" might change later
in the same object, and change the context in which it needs to be
interpreted. This could be remedied by making base and entry updates
mutually exclusive (arguably a less straight-forward design), but as
things are, I'd prefer -03.

Best regards
Christian

[1] https://gitlab.com/c.amsuess-energyharvesting/senml-03-streaming-parser=
-demo/tree/master

--=20
Christian Ams=FCss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--5/uDoXvLw7AC5HRs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWmkVUAAoJEDmNERLTpL3hZgcP/3WiM114iLZTW0uBxuLSHWxq
wHtLT1AbTji0xX6C9jf7bJ9nkIZq/0BTPbceW4doz09iCecf1jnU0n6uLNyAHHxT
a2GXsebUTH1D5HqK5nXkA3WbHI9kzABwT39jFfOkgQ9tNQdfkdvx7ImtMElHLW82
Mmj6zq5o4mq7yEKWl8YSPHL2QiK9UhcpT1Grwd1hmwSWjgulIOS1I+Dkw4h+kLpG
7+jKnL8WdHZOO8+xsY+Q3j+777mMMnnuYx9HWcImXCq4VUT4RrmAnSCxvt3imcYr
d2l/dWkgzUeNbUQgRgnkwfoDdmwTE36ez7OvjS3sVfIF/iCpnR+WYVC/t0Bd949Q
7OP2kwN1hlmfOFpPo+7Sx2hnXgzQXwXrnQbsxreyTu9qeFE4MDNKpYBqgJS7meZa
bj/FwV+qAAZgKqzNF+V0zD+HCRZ2LZLa5MMCKkhTBJhgwm81DQyirmOHOxJtlDM2
aY54vH8vQSXQ1/Lwy9pUVDRRwHQt29wBcLgXpSiIvUyKBUxZx1WxkHcJkC7snKcS
nC8rFw0FROUp8f94h0jf0ztU8FV2/SE+v90IdAJPp2AyQenZCr+xsWj/VzTd59VA
n7TwJII6IjkiOpp3pu62aEBHJlojrJ4ZRVixTW2Pcy6ix7HnvTXwDNjPzbrIzJbd
huV3zwIblSvscMOszXaJ
=0Cmm
-----END PGP SIGNATURE-----

--5/uDoXvLw7AC5HRs--


From nobody Sat Jan 16 07:24:48 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745F21A8998 for ; Sat, 16 Jan 2016 07:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 a6kbNOCUyGxd for ; Sat, 16 Jan 2016 07:24:44 -0800 (PST)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 2DE451A8997 for ; Sat, 16 Jan 2016 07:24:44 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id n128so133298620pfn.3 for ; Sat, 16 Jan 2016 07:24:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=h30q72Hf6su1MAvzSTBglqtxvBzgDVM+5MBLiVbXetA=; b=lkSHNdhzF2F2JR5k6l4Kp8nOv5ZULid7nxZ0OLGBxPm0PD4DTps2OVSeJ7qiA12648 DW2F5sOXYVsG81l4JidhZUn6UvifJBBPpPxA1nEMtAyKD2WXF4+rPU7DOmLBw4KTUBF6 Ibu4iPftb2junxZPHATn+m6Zi1TNnA8WE6Ap4dY6uVY5NHhxI8MwstlH0/mcVVn3BpEs n29lLC20zYvejtes4LYH3yCAebv0bK5U0AFALz4+YDxqqFAkmuL224Vxj6jM2qD/wQs0 9FsBpB74qzKe2ZEFxipo/+RvaMC27qETeYDkyG7Bo9uyEutGWTSFGs8zJZUrSBGwOQ/T ZKlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=h30q72Hf6su1MAvzSTBglqtxvBzgDVM+5MBLiVbXetA=; b=FvJ0hMa8hnnn0R2Ap09Rphfq9b9Mu52+2GmkyIr/KzYiAj13iQM8BFlEnOs3QiBDGK jXLK1Rp0Y4Pah93+6L6Mj3wdB4fuXW99T6qvfrbBtpj9W8jWeNOH+vyfQgFTFK5/HQtk uIgCUnvolPOAC4XHRFQy/dw5Bg0IvdjJWrUQCRO1wAgsL6VhwtDqI26KZ8svWv5kB93X rjtWmKzv0u9Eojl0gieBJ0WoYQZ2WoZyfP5qmV7nWFfAz99IxEIPtPRNRGDCswbN3GdG blD9EbNmmyndTNfu0lz2wKZGKqom9V651QAFh/QURc1cCNtBlHyZzwYsE5RxwwkoDBpJ mQ+Q==
X-Gm-Message-State: ALoCoQmqNcvzTKiPedZ283oIj4d04pJb1Qm6n4vCxa2PGmZ4P5yUuyYNx253sp+xaxDPF5h300xUh/EK4pCJlpMqtPEBSirtNQ==
X-Received: by 10.98.10.81 with SMTP id s78mr21030151pfi.119.1452957883822; Sat, 16 Jan 2016 07:24:43 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id e82sm22538962pfb.76.2016.01.16.07.24.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 07:24:42 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_592F1A71-5F12-43F7-80F2-470CD99AB5BB"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <20160116132751.GB18563@hephaistos.amsuess.com>
Date: Sat, 16 Jan 2016 07:24:41 -0800
Message-Id: 
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 15:24:46 -0000

--Apple-Mail=_592F1A71-5F12-43F7-80F2-470CD99AB5BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Christian,

1.
Thanks for the code example! It seems well optimized indeed.

It also serves to highlight one of the points.=20

It=92s more than just a matter of me liking my own favorite language =
(actually library) internal representation of JSON. Most modern =
libraries produce dictionary and array representations for parsed JSON =
that work more or less the same way.

The optimizations you recommend require a new string input parser, where =
I am using the JSON parser that comes with the library. My point was =
that I will need to either make my own string parser for SenML or make a =
re-parser with the state machine I described in order to use -02 + but =
there is another issue anyway:

One of the big advantages of using JSON is connecting the embedded world =
to the web world. To do this in a low-friction way, it=92s good to be =
able to use well known tools and patterns. Streaming JSON=20
2.=20
Thanks also for looking into my code. I could easily use the -02 or -03 =
in the senml processing as you show. What is missing still from =
everything after -01 is the element tag that I am re-using to indicate =
links and forms in the document:

{
  "bn":"/3300/1/",
  "e":[
    {"n":"5700","v":"31.3"},
    {"n":"5602","v":"37.1"},
    {"n":"5601","v":"18.3"},
    {"n":"5605"},
    {"n":"5603","v":"0"},
    {"n":"5604","v":"100"},
    {"n":"5750","sv":"Inboard Bearing"}
  ],
  "l":[
    {"href":"","rel":"self","rt":"temperature","u":"C"},
    {"href":"5700","rt":"currentValue","u":"C"},
    {"href":"5602","rt":"maxValue","u":"C"},
    {"href":"5601","rt":"minValue","u":"C"},
    {"href":"5605","rt":"resetMaxMin"},
    {"href":"5603","rt":"minScale","u":"C"},
    {"href":"5604","rt":"maxScale","u":"C"},
    {"href":"5750","rt":"appType"}
  ]
}

I will think about other designs that do not depend on entity tags in =
the representation; maybe there is a better design for the content =
format in general. But I would still like to use SenML. Maybe not extend =
it but embed it in another new format=85

In the meantime, I don=92t have a good alternative yet.

Best regards,

Michael

PS Can we succinctly describe the use case for ordered serial processing =
of senml+json elements being important? =46rom reading the draft, it =
seems like the important bit is saving the buffer memory for large =
responses. Is it a bigger deal with CBOR encoding or less important.=20

Is the most important consideration being able to know the base values =
ahead of the data?=20

Also, where is -03? there doesn=92t seem to be a version -03 that you =
all are talking about on the IETF website:
https://tools.ietf.org/html/draft-jennings-core-senml-04 =



> On Jan 16, 2016, at 5:27 AM, Christian Ams=FCss =
 wrote:
>=20
> Hello Cullen,
>=20
> On Wed, Jan 13, 2016 at 01:57:02PM +0000, Cullen Jennings (fluffy) =
wrote:
>> The objects can also have the base values right in the object and the
>> base values apply to all the things in the object and any future
>> objects in the array.=20
>>=20
>> Appreciate any thoughts people have on pro / cons of the -03 design =
vs -04 design.
>=20
> The -03 draft is parsable with minimum RAM: I've assembled a crude
> demo[1] that shows that given a list of known integer-valued resources
> on a device, it is possible to parse incoming SenML-03 with less than =
30
> bytes of state, with support for arbitrary SenML extensions, all legal
> JSON number representations and full URL concatenation semantics.
>=20
> With the -04 draft, one would have to allocate a buffer for the "n"
> value, because before the object finishes, the "bn" might change later
> in the same object, and change the context in which it needs to be
> interpreted. This could be remedied by making base and entry updates
> mutually exclusive (arguably a less straight-forward design), but as
> things are, I'd prefer -03.
>=20
> Best regards
> Christian
>=20
> [1] =
https://gitlab.com/c.amsuess-energyharvesting/senml-03-streaming-parser-de=
mo/tree/master
>=20
> --=20
> Christian Ams=FCss                      | Energy Harvesting Solutions =
GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>                                      | ATU68476614
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


--Apple-Mail=_592F1A71-5F12-43F7-80F2-470CD99AB5BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hi Christian,

1.
Thanks for the code example! It seems =
well optimized indeed.

It also serves to highlight one of the =
points. 

It=92s more than just a matter of me liking my own favorite =
language (actually library) internal representation of JSON. Most modern =
libraries produce dictionary and array representations for parsed JSON =
that work more or less the same way.

The optimizations you recommend require =
a new string input parser, where I am using the JSON parser that comes =
with the library. My point was that I will need to either make my own =
string parser for SenML or make a re-parser with the state machine I =
described in order to use -02 + but there is another issue =
anyway:

One of =
the big advantages of using JSON is connecting the embedded world to the =
web world. To do this in a low-friction way, it=92s good to be able to =
use well known tools and patterns. Streaming JSON 
2. 
Thanks also for looking into my =
code. I could easily use the -02 or -03 in the senml processing as you =
show. What is missing still from everything after -01 is the element tag =
that I am re-using to indicate links and forms in the =
document:


I will think about other designs that =
do not depend on entity tags in the representation; maybe there is a =
better design for the content format in general. But I would still like =
to use SenML. Maybe not extend it but embed it in another new =
format=85

In =
the meantime, I don=92t have a good alternative yet.

Best regards,

Michael

PS Can we succinctly =
describe the use case for ordered serial processing of senml+json =
elements being important? =46rom reading the draft, it seems like the =
important bit is saving the buffer memory for large responses. Is it a =
bigger deal with CBOR encoding or less important. 

Is the most important =
consideration being able to know the base values ahead of the =
data? 

Also, where is -03? there doesn=92t seem to be a version -03 =
that you all are talking about on the IETF website:
https://tools.ietf.org/html/draft-jennings-core-senml-04


On Jan 16, 2016, at 5:27 AM, Christian Ams=FCss=
 <c.amsuess@energyharvesting.at> wrote:

Hello Cullen,

On Wed, Jan 13, 2016 at 01:57:02PM +0000, =
Cullen Jennings (fluffy) wrote:
The objects can also have the base values right in the object =
and the
base values apply to all the things in the object =
and any future
objects in the array. 

Appreciate any thoughts people have on pro / cons of the -03 =
design vs -04 design.

The -03 =
draft is parsable with minimum RAM: I've assembled a crude
demo[1] that shows that given a list of known integer-valued =
resources
on a device, it is possible to parse incoming =
SenML-03 with less than 30
bytes of state, with support =
for arbitrary SenML extensions, all legal
JSON number =
representations and full URL concatenation semantics.

With the -04 draft, one would have to allocate a buffer for =
the "n"
value, because before the object finishes, the =
"bn" might change later
in the same object, and change the =
context in which it needs to be
interpreted. This could be =
remedied by making base and entry updates
mutually =
exclusive (arguably a less straight-forward design), but as
things are, I'd prefer -03.

Best =
regards
Christian

[1] https://gitlab.com/c.amsuess-energyharvesting/senml-03-streamin=
g-parser-demo/tree/master

-- 
Christian Ams=FCss =
            &n=
bsp;        | Energy Harvesting =
Solutions GmbH
founder, system architect =
            | =
headquarter:
mailto:c.amsuess@energyharvesting.at  | =
Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =
            &n=
bsp;  | http://www.energyharvesting.at/
 =
            &n=
bsp;           &nbs=
p;            =
| ATU68476614
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

=

--Apple-Mail=_592F1A71-5F12-43F7-80F2-470CD99AB5BB--


From nobody Sat Jan 16 08:09:18 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F811A8A52 for ; Sat, 16 Jan 2016 08:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 d9nmV79V8DQS for ; Sat, 16 Jan 2016 08:09:15 -0800 (PST)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB9F1A8A54 for ; Sat, 16 Jan 2016 08:09:15 -0800 (PST)
Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id C81BE1720A3; Sat, 16 Jan 2016 17:09:13 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3uEfuEcGzvak; Sat, 16 Jan 2016 17:09:12 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 4B16617209D; Sat, 16 Jan 2016 17:09:11 +0100 (CET)
Message-ID: <569A6B27.50404@tzi.org>
Date: Sat, 16 Jan 2016 17:09:11 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Michael Koster 
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core , =?UTF-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 16:09:17 -0000

Michael Koster wrote:
> What is missing still from everything after -01 is the element tag that
> I am re-using to indicate links and forms in the document:

What would be wrong with including this in the metadata part of -02:

   [{"bn": "urn:dev:mac:0024befffe804ff1/",
     "l": [
      {"href"...}...
     ]},
    [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
      { "n": "current", "t": 0, "u": "A", "v": 1.2 } ]
   ]

Grüße, Carsten


From nobody Sat Jan 16 09:44:03 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE751A905C for ; Sat, 16 Jan 2016 09:44:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 8pxw_lMcMSim for ; Sat, 16 Jan 2016 09:43:59 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 1CEA71A905D for ; Sat, 16 Jan 2016 09:43:59 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id q63so138360713pfb.1 for ; Sat, 16 Jan 2016 09:43:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MR+nx1AodjxYVd/PXKjz3ipCk6DZc4E/Luj9hdd2qvo=; b=NtcTHSzv5WwnpbXNy5F1PaqlSOZtqLM418nAZB7itgN2syBQbrnBAWiPxquvMBFTtR wCvPYvwFa9P2ZQbsfYwR6GSsxA5C7jgmpIFH39UtWPvyFrPGxBCS8ec6JTPLao/XGL1c FMMoKUsSFHdNNxkNzmymVcumGAPPB9+Sq4trQ0I7AkcbMjwn3brXQFO3lQFvNu+51AV3 psqa9/DWIek3YXwDyX9pWEBEiSiBp3vtL26EN6VqDwuWC4karngLuIgxS0Re03ItArlz fbjwGKTRPY42IM1OU/BG+975osvrzIiDgKUWSZCkHiZnW6HPENyjQTvydSkgL8mSJPa5 jVMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=MR+nx1AodjxYVd/PXKjz3ipCk6DZc4E/Luj9hdd2qvo=; b=fNqjMXAMYJn8u3NHbyVEH7S4uUoWWO0pfv23nyV2Hx9rvRx6R5WutA15rXpNQKy6Uq F3ZbFX4GGTRrb3RYHOUsVihQIPDBckZryybKyu8CUMGXwtGPH7/vf2mvS05ZCyPADG3g /XbowLx9j8fp8xBuAZExZsm/0UxEM7scku5fOVrvandO8vVx7kBrzayLqDY3UYXhTbD4 xuy0xeyeMyKnFKL6LyoSM7ZjXHjry5tR92ycxLj26r/hN7gqmiby6dgvruY67ns8rgx3 gkjKdH94/Ob+R89tlJbTUo2xvPWoYUJP6GGF2xycQDRAaqMgbnp694OtsyAaiCEbknxH /WRQ==
X-Gm-Message-State: ALoCoQmh+198IY5s+hCx6yH4zaTMfcfpSVqaWnem+PnA9KEVmFYAa82ckfAX9nwUzW/rYVtnsCFKxbsAVdUoWLysTD8RQv3Q1A==
X-Received: by 10.98.68.193 with SMTP id m62mr23966658pfi.153.1452966238537; Sat, 16 Jan 2016 09:43:58 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id l9sm23144589pfb.29.2016.01.16.09.43.56 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 09:43:57 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6C3C2692-6D73-4D56-B1A9-67908E9D02A4"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <569A6B27.50404@tzi.org>
Date: Sat, 16 Jan 2016 09:43:55 -0800
Message-Id: <7DA00BBA-4869-4351-97E3-6B45311B28A2@gmail.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com>  <569A6B27.50404@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core , =?utf-8?Q?Christian_Ams=C3=BCss?= 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 17:44:02 -0000

--Apple-Mail=_6C3C2692-6D73-4D56-B1A9-67908E9D02A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Carsten,

Yes, of course! This approach reminds me of JSON streaming, where actual =
delimiters are inserted into a text stream, but this is much better =
because it uses the JSON array itself to encapsulate elements that can =
be individually parsed.

That makes the outer element an array and the inner elements either =
array type or map map type, and the map can be extended to embed element =
types representing the links, forms, and data within the base element =
dictionary.

It would be useful if the order of top level element types could be =
arbitrary e.g.: [ {},[],[],[],{},[],{},{} ... ]

So for example, to use this format I will extend the base element map as =
you indicated:

[=20
  { "bn": "urn:dev:mac:0024befffe804ff1/",
    "l": [
       {"href"...}...
    ]

  },
  [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
    { "n": "current", "t": 0, "u": "A", "v": 1.2 }=20
  ]
]

If the order of top element types is optional, then the presence also =
could be, so I can adapt the new format by extending the base element to =
include links, forms, and items (getting rid of the =E2=80=9Ce=E2=80=9D =
tag):

[=20
  {=20
    "bn": =E2=80=9C/light/brightness",
    "l": [
      { =E2=80=9Chref=E2=80=9D: =E2=80=9Cchange=E2=80=9D,
        =E2=80=9Crt=E2=80=9D: [=E2=80=9Cchange=E2=80=9D,=E2=80=9Dform=E2=80=
=9D],
        =E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/forms+senml+json=E2=80=9D=

      },
      { =E2=80=9Chref=E2=80=9D: =E2=80=9Ctbr=E2=80=9D,
        =E2=80=9Crt=E2=80=9D: [=E2=80=9Cproperty=E2=80=9D, =E2=80=9Citem=E2=
=80=9D, =E2=80=9Cparam"],
        =E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/senml+json=E2=80=9D
      },     =20
      { =E2=80=9Chref=E2=80=9D: =E2=80=9Ctt=E2=80=9D,
        =E2=80=9Crt=E2=80=9D: [=E2=80=9Cproperty=E2=80=9D, =E2=80=9Citem=E2=
=80=9D, =E2=80=9Cparam"],
        =E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/senml+json=E2=80=9D
      },
      { =E2=80=9Chref=E2=80=9D: =E2=80=9Cactuations=E2=80=9D,
        =E2=80=9Crt=E2=80=9D: =E2=80=9Cactuation=E2=80=9D,
        =E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/collection+senml+json=E2=
=80=9D
      }    =20
    ],
    =E2=80=9Cf=E2=80=9D: [
      { =E2=80=9Cid=E2=80=9D: =E2=80=9Cchange=E2=80=9D,
        "href=E2=80=9D: =E2=80=9Cactuations=E2=80=9D,
        =E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/collection+json=E2=80=9D=
,
        =E2=80=9Cmethod=E2=80=9D: =E2=80=9Cpost=E2=80=9D,
        =E2=80=9Ctype=E2=80=9D: =E2=80=9Cchange=E2=80=9D
        =E2=80=9Ctemplate=E2=80=9D: {
          =E2=80=9Ctbr=E2=80=9D: =E2=80=9C$targetbrightness=E2=80=9D
          =E2=80=9Ctt=E2=80=9D: =E2=80=9C$transitiontime=E2=80=9D
        }
      }
    ],
    =E2=80=9Ci=E2=80=9D: [
      { =E2=80=9Cn=E2=80=9D: =E2=80=9Ctbr=E2=80=9D,
        =E2=80=9Cv=E2=80=9D: =E2=80=9C44.3=E2=80=9D,
      },
      { =E2=80=9Cn=E2=80=9D: =E2=80=9Ctt=E2=80=9D,
        =E2=80=9Cv=E2=80=9D: =E2=80=9C1.0=E2=80=9D,
      }
    ]=09
  }
]

Having a top level array will allow me to accommodate collective =
operations on multiple object (bases) and allow the underlying =
implementation to chunk things at lease to the granularity of base =
objects mapped to top level elements.

So I=E2=80=99m OK with this if it allows me to use base elements as =
above.

Best regards,

Michael



> On Jan 16, 2016, at 8:09 AM, Carsten Bormann  wrote:
>=20
> Michael Koster wrote:
>> What is missing still from everything after -01 is the element tag =
that
>> I am re-using to indicate links and forms in the document:
>=20
> What would be wrong with including this in the metadata part of -02:
>=20
>   [{"bn": "urn:dev:mac:0024befffe804ff1/",
>     "l": [
>      {"href"...}...
>     ]},
>    [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
>      { "n": "current", "t": 0, "u": "A", "v": 1.2 } ]
>   ]
>=20
> Gr=C3=BC=C3=9Fe, Carsten


--Apple-Mail=_6C3C2692-6D73-4D56-B1A9-67908E9D02A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi Carsten,

Yes, of course! This =
approach reminds me of JSON streaming, where actual delimiters are =
inserted into a text stream, but this is much better because it uses the =
JSON array itself to encapsulate elements that can be individually =
parsed.

That makes the =
outer element an array and the inner elements either array type or map =
map type, and the map can be extended to embed element types =
representing the links, forms, and data within the base element =
dictionary.

It would =
be useful if the order of top level element types could be arbitrary =
e.g.: [ {},[],[],[],{},[],{},{} ... =
]

So for example, to use this =
format I will extend the base element map as you indicated:

[ 
  { "bn": =
"urn:dev:mac:0024befffe804ff1/",
    "l": [
       {"href"...}...
    ]

  },
  [ { "n": "voltage", =
"t": 0, "u": "V", "v": 120.1 },
    { "n": =
"current", "t": 0, "u": "A", "v": 1.2 } 
  ]
]

If the order of top element =
types is optional, then the presence also could be, so I can adapt the =
new format by extending the base element to include links, forms, and =
items (getting rid of the =E2=80=9Ce=E2=80=9D tag):

[ 
  =
{ 
    =
"bn": =E2=80=9C/light/brightness",
    "l": [
      { =
=E2=80=9Chref=E2=80=9D: =E2=80=9Cchange=E2=80=9D,
        =
=E2=80=9Crt=E2=80=9D: [=E2=80=9Cchange=E2=80=9D,=E2=80=9Dform=E2=80=9D],
  =
      =
=E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/forms+senml+json=E2=80=9D<=
/font>
  =
    },
      { =
=E2=80=9Chref=E2=80=9D: =E2=80=9Ctbr=E2=80=9D,
        =
=E2=80=9Crt=E2=80=9D: =
[=E2=80=9Cproperty=E2=80=9D, =E2=80=9Citem=E2=80=9D, =E2=80=9Cpa=
ram"],
        =
=E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/senml+json=E2=80=9D=

    =
  },  =
    
      { =
=E2=80=9Chref=E2=80=9D: =E2=80=9Ctt=E2=80=9D,
        =
=E2=80=9Crt=E2=80=9D: [=E2=80=9Cproperty=E2=80=9D, =E2=80=9Citem=
=E2=80=9D, =E2=80=9Cparam"],
        =
=E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/senml+json=E2=80=9D=

      },
      { =
=E2=80=9Chref=E2=80=9D: =E2=80=9Cactuations=E2=80=9D,
      =
  =E2=80=9Crt=E2=80=9D: =E2=80=9Cactuation=E2=80=9D,
      =
  =
=E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/collection+senml+json=E2=80=
=9D
  =
    }     
    ],
    =E2=80=9Cf=
=E2=80=9D: [
      =
{ =E2=80=9Cid=E2=80=9D: =E2=80=9Cchange=E2=80=9D,
      =
  "href=E2=80=9D: =E2=80=9Cactuations=E2=80=9D,
      =
  =E2=80=9Cct=E2=80=9D: =E2=80=9Capplication/collection+jso=
n=E2=80=9D,
        =
=E2=80=9Cmethod=E2=80=9D: =E2=80=9Cpost=E2=80=9D,
        =
=E2=80=9Ctype=E2=80=9D: =E2=80=9Cchange=E2=80=9D
  =
      =E2=80=9Ctemplate=E2=80=9D: {
        =
  =E2=80=9Ctbr=E2=80=9D: =E2=80=9C$targetbrightness=E2=80=9D
    =
      =
=E2=80=9Ctt=E2=80=9D: =E2=80=9C$transitiontime=E2=80=9D
<=
div class=3D"">      =
  }
      }
    ],
    =E2=80=9Ci=
=E2=80=9D: [
      { =
=E2=80=9Cn=E2=80=9D: =E2=80=9Ctbr=E2=80=9D,
        =
=E2=80=9Cv=E2=80=9D: =E2=80=9C44.3=E2=80=9D,
  =
    },
      { =
=E2=80=9Cn=E2=80=9D: =E2=80=9Ctt=E2=80=9D,
        =
=E2=80=9Cv=E2=80=9D: =E2=80=9C1.0=E2=80=9D,
  =
    }
    ]	=

  =
}
]

Having a =
top level array will allow me to accommodate collective operations on =
multiple object (bases) and allow the underlying implementation to chunk =
things at lease to the granularity of base objects mapped to top level =
elements.

So I=E2=80=99m OK with this if it allows me to use base =
elements as above.

Best regards,

Michael



On Jan 16, 2016, at 8:09 AM, =
Carsten Bormann <cabo@tzi.org> wrote:

Michael Koster =
wrote:
What is =
missing still from everything after -01 is the element tag that
I am re-using to indicate links and forms in the document:

What would be wrong with =
including this in the metadata part of -02:

 =
  [{"bn": "urn:dev:mac:0024befffe804ff1/",
 =
    "l": [
 =
     {"href"...}...
 =
    ]},
    [ { "n": =
"voltage", "t": 0, "u": "V", "v": 120.1 },
 =
     { "n": "current", "t": 0, "u": "A", "v": =
1.2 } ]
   ]

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

=

--Apple-Mail=_6C3C2692-6D73-4D56-B1A9-67908E9D02A4--


From nobody Sat Jan 16 09:53:12 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666711A90F7 for ; Sat, 16 Jan 2016 09:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 Z9X5BrOKmIb2 for ; Sat, 16 Jan 2016 09:53:07 -0800 (PST)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 AB4F31A90F3 for ; Sat, 16 Jan 2016 09:53:07 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id q63so138432430pfb.1 for ; Sat, 16 Jan 2016 09:53:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JtcFmWgzoRTr4kXn7JNEl+VBLmjj54BTqwEEDLMBn9g=; b=PkEwx5gbntXT/cU4d1Bnx9yvr8OkEGanW8/TJU5ZKRqNsJxE7X1dTQd0HBAS2KB8yu uxi0ErQjPD54TpZ9OFGOcgGGeu0gO4e6aA0vubJtPJJ7Ka6ovyHdBMMZ43I6VCF9KPBX VsLUq5d94WrHokjfRZuYOL0Cae94XECipaOppVCspGGwwFiehQ8nSpY2ynSkrn+oOaa/ SYFgquni97sBuHduvLB/GTw47r5yK7SLTux3RhbbN/wfRVuh0PKOK4MYP1JF5WHjY9Ti kCcde61Hj7UMeCqRVSEROikS6tNA6V+wfWLzCGoi9SKNmfQhCnvvVV72xrzKRBygukOI ar+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=JtcFmWgzoRTr4kXn7JNEl+VBLmjj54BTqwEEDLMBn9g=; b=N+CUHJUG9k4akE9I1sXA2jovVPpyj/uX4mEx/qUO4o33YpzWy7bL1s5fRjxss+wRsK r9EVASnzk1rvGojYGzLWNsrCenGFHHkTXwekfwJlkTi16+/u5qSLpPrzH/8HcN4ZWoXk 8TQz3nLH2TaQ1/U8/3YFarhgkK+mjW8rzHHLXTz89WyE9NOXW09J4I9rasrKdTrP4nwp fvxBlP68t8y4KW9jkjkBfGlf5K+kkPomN/rw8038sCt3g8wfjfJ1K5WdDp9+wgaNF/HX ad35if7rxUgohZEhuj2Aas0TPiWA1K658vwE7A9RLY2A/onGsKBJI1dbN1u98zkv/xP5 qqHg==
X-Gm-Message-State: ALoCoQkCA/dlq1YQwAgS9UJj3Pl54RDqz/AIgMdnB8TuflPccr2paNn57Jrn1krcFC0OliKk/O9+VO2VjYzTnfX3T49kU7ecJA==
X-Received: by 10.98.79.4 with SMTP id d4mr23777484pfb.46.1452966787367; Sat, 16 Jan 2016 09:53:07 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 20sm23213749pfa.5.2016.01.16.09.53.06 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 09:53:06 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C2B0A943-0428-47DD-A651-7F9334C4CA52"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: 
Date: Sat, 16 Jan 2016 09:53:04 -0800
Message-Id: <0D5538ED-D126-4A1B-AFDD-D9D54580D48B@gmail.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com> 
To: =?utf-8?Q?Christian_Ams=C3=BCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 17:53:10 -0000

--Apple-Mail=_C2B0A943-0428-47DD-A651-7F9334C4CA52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Here is a concrete proposal.=20

My goal with the collection+senml content format is to create a format =
for machine hypermedia representations that is roughly analogous to a =
HTML web page in the web of documents world.=20

The idea was a compact representation that can represent machine =
hypermedia data, links, and forms and would leverage existing formats =
and processors; link-format, senml, json.=20

When I started, it looked like SenML was a good base due to what =
appeared to be an extension mechanism: the element tag that was an =
artifact of the XML serialization. I didn=92t expect it to be removed =
because I have XML/JSON tools that programmatically generate that style =
as a lossless XML-JSON transform. This is generally useful because EXI =
is still a very popular format and in many cases more compact than CBOR.

If we can allow the base element to retain this functionality, and put =
the streaming support in the sequence of top level array elements, it =
seems like exactly what is needed. It retains backward compatibility =
with current senml implementations and allows some extensibility at both =
levels, while supporting sequential processing.

I propose to restore the base senml functionality of draft -01 within =
the base element definition in the new draft, that is to allow =
measurement data within the base element using the =93e=94 key. To =
facilitate sequential processing, a topmost structure of array will =
allow an arbitrary sequence of base element maps and data element arrays =
as defined in draft -04.

Are there any issues with this construction?=20

Best regards,

Michael


> On Jan 16, 2016, at 7:24 AM, Michael Koster =
 wrote:
>=20
> Hi Christian,
>=20
> 1.
> Thanks for the code example! It seems well optimized indeed.
>=20
> It also serves to highlight one of the points.=20
>=20
> It=92s more than just a matter of me liking my own favorite language =
(actually library) internal representation of JSON. Most modern =
libraries produce dictionary and array representations for parsed JSON =
that work more or less the same way.
>=20
> The optimizations you recommend require a new string input parser, =
where I am using the JSON parser that comes with the library. My point =
was that I will need to either make my own string parser for SenML or =
make a re-parser with the state machine I described in order to use -02 =
+ but there is another issue anyway:
>=20
> One of the big advantages of using JSON is connecting the embedded =
world to the web world. To do this in a low-friction way, it=92s good to =
be able to use well known tools and patterns. Streaming JSON=20
> 2.=20
> Thanks also for looking into my code. I could easily use the -02 or =
-03 in the senml processing as you show. What is missing still from =
everything after -01 is the element tag that I am re-using to indicate =
links and forms in the document:
>=20
> {
>   "bn":"/3300/1/",
>   "e":[
>     {"n":"5700","v":"31.3"},
>     {"n":"5602","v":"37.1"},
>     {"n":"5601","v":"18.3"},
>     {"n":"5605"},
>     {"n":"5603","v":"0"},
>     {"n":"5604","v":"100"},
>     {"n":"5750","sv":"Inboard Bearing"}
>   ],
>   "l":[
>     {"href":"","rel":"self","rt":"temperature","u":"C"},
>     {"href":"5700","rt":"currentValue","u":"C"},
>     {"href":"5602","rt":"maxValue","u":"C"},
>     {"href":"5601","rt":"minValue","u":"C"},
>     {"href":"5605","rt":"resetMaxMin"},
>     {"href":"5603","rt":"minScale","u":"C"},
>     {"href":"5604","rt":"maxScale","u":"C"},
>     {"href":"5750","rt":"appType"}
>   ]
> }
>=20
> I will think about other designs that do not depend on entity tags in =
the representation; maybe there is a better design for the content =
format in general. But I would still like to use SenML. Maybe not extend =
it but embed it in another new format=85
>=20
> In the meantime, I don=92t have a good alternative yet.
>=20
> Best regards,
>=20
> Michael
>=20
> PS Can we succinctly describe the use case for ordered serial =
processing of senml+json elements being important? =46rom reading the =
draft, it seems like the important bit is saving the buffer memory for =
large responses. Is it a bigger deal with CBOR encoding or less =
important.=20
>=20
> Is the most important consideration being able to know the base values =
ahead of the data?=20
>=20
> Also, where is -03? there doesn=92t seem to be a version -03 that you =
all are talking about on the IETF website:
> https://tools.ietf.org/html/draft-jennings-core-senml-04 =

>=20
>=20
>> On Jan 16, 2016, at 5:27 AM, Christian Ams=FCss =
> =
wrote:
>>=20
>> Hello Cullen,
>>=20
>> On Wed, Jan 13, 2016 at 01:57:02PM +0000, Cullen Jennings (fluffy) =
wrote:
>>> The objects can also have the base values right in the object and =
the
>>> base values apply to all the things in the object and any future
>>> objects in the array.=20
>>>=20
>>> Appreciate any thoughts people have on pro / cons of the -03 design =
vs -04 design.
>>=20
>> The -03 draft is parsable with minimum RAM: I've assembled a crude
>> demo[1] that shows that given a list of known integer-valued =
resources
>> on a device, it is possible to parse incoming SenML-03 with less than =
30
>> bytes of state, with support for arbitrary SenML extensions, all =
legal
>> JSON number representations and full URL concatenation semantics.
>>=20
>> With the -04 draft, one would have to allocate a buffer for the "n"
>> value, because before the object finishes, the "bn" might change =
later
>> in the same object, and change the context in which it needs to be
>> interpreted. This could be remedied by making base and entry updates
>> mutually exclusive (arguably a less straight-forward design), but as
>> things are, I'd prefer -03.
>>=20
>> Best regards
>> Christian
>>=20
>> [1] =
https://gitlab.com/c.amsuess-energyharvesting/senml-03-streaming-parser-de=
mo/tree/master =

>>=20
>> --=20
>> Christian Ams=FCss                      | Energy Harvesting Solutions =
GmbH
>> founder, system architect             | headquarter:
>> mailto:c.amsuess@energyharvesting.at =
  | Arbeitergasse 15, A-4400 Steyr
>> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/ 
>>                                      | ATU68476614
>> _______________________________________________
>> core mailing list
>> core@ietf.org 
>> https://www.ietf.org/mailman/listinfo/core
>=20


--Apple-Mail=_C2B0A943-0428-47DD-A651-7F9334C4CA52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Here is a concrete proposal. 

My goal with the collection+senml =
content format is to create a format for machine hypermedia =
representations that is roughly analogous to a HTML web page in the web =
of documents world. 

The idea was a compact representation that can represent =
machine hypermedia data, links, and forms and would leverage existing =
formats and processors; link-format, senml, json. 

When I started, it =
looked like SenML was a good base due to what appeared to be an =
extension mechanism: the element tag that was an artifact of the XML =
serialization. I didn=92t expect it to be removed because I have =
XML/JSON tools that programmatically generate that style as a lossless =
XML-JSON transform. This is generally useful because EXI is still a very =
popular format and in many cases more compact than CBOR.

If we can allow the base =
element to retain this functionality, and put the streaming support in =
the sequence of top level array elements, it seems like exactly what is =
needed. It retains backward compatibility with current senml =
implementations and allows some extensibility at both levels, while =
supporting sequential processing.

I propose to restore the base senml =
functionality of draft -01 within the base element definition in the new =
draft, that is to allow measurement data within the base element using =
the =93e=94 key. To facilitate sequential processing, a topmost =
structure of array will allow an arbitrary sequence of base element maps =
and data element arrays as defined in draft -04.

Are there any issues with this =
construction? 

Best regards,

Michael

On =
Jan 16, 2016, at 7:24 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi =
Christian,

1.
Thanks for the code example! It seems =
well optimized indeed.

It also serves to highlight one of the =
points. 

It=92s more than just a matter of me liking my own favorite =
language (actually library) internal representation of JSON. Most modern =
libraries produce dictionary and array representations for parsed JSON =
that work more or less the same way.

The optimizations you recommend require =
a new string input parser, where I am using the JSON parser that comes =
with the library. My point was that I will need to either make my own =
string parser for SenML or make a re-parser with the state machine I =
described in order to use -02 + but there is another issue =
anyway:

One of =
the big advantages of using JSON is connecting the embedded world to the =
web world. To do this in a low-friction way, it=92s good to be able to =
use well known tools and patterns. Streaming JSON 
2. 
Thanks also for looking into my =
code. I could easily use the -02 or -03 in the senml processing as you =
show. What is missing still from everything after -01 is the element tag =
that I am re-using to indicate links and forms in the =
document:

{
  =
"bn":"/3300/1/",
  "e":[
    {"n":"5700","v":"31.3"},
    =
{"n":"5602","v":"37.1"},
    {"n":"5601","v":"18.3"},
    =
{"n":"5605"},
    {"n":"5603","v":"0"},
    =
{"n":"5604","v":"100"},
    {"n":"5750","sv":"Inboard =
Bearing"}
  ],
  "l":[
    =
{"href":"","rel":"self","rt":"temperature","u":"C"},
    =
{"href":"5700","rt":"currentValue","u":"C"},
    =
{"href":"5602","rt":"maxValue","u":"C"},
    =
{"href":"5601","rt":"minValue","u":"C"},
    =
{"href":"5605","rt":"resetMaxMin"},
    =
{"href":"5603","rt":"minScale","u":"C"},
    =
{"href":"5604","rt":"maxScale","u":"C"},
    =
{"href":"5750","rt":"appType"}
  ]
}

I will think about other designs that =
do not depend on entity tags in the representation; maybe there is a =
better design for the content format in general. But I would still like =
to use SenML. Maybe not extend it but embed it in another new =
format=85

In =
the meantime, I don=92t have a good alternative yet.

Best regards,

Michael

PS Can we succinctly =
describe the use case for ordered serial processing of senml+json =
elements being important? =46rom reading the draft, it seems like the =
important bit is saving the buffer memory for large responses. Is it a =
bigger deal with CBOR encoding or less important. 

Is the most important =
consideration being able to know the base values ahead of the =
data? 

Also, where is -03? there doesn=92t seem to be a version -03 =
that you all are talking about on the IETF website:
https://tools.ietf.org/html/draft-jennings-core-senml-04


On Jan 16, 2016, at 5:27 AM, Christian =
Ams=FCss <c.amsuess@energyharvesting.at> wrote:

Hello Cullen,

On Wed, Jan 13, 2016 at 01:57:02PM +0000, =
Cullen Jennings (fluffy) wrote:
The objects can also have the base values right in the object =
and the
base values apply to all the things in the object =
and any future
objects in the array. 

Appreciate any thoughts people have on pro / cons of the -03 =
design vs -04 design.

The -03 =
draft is parsable with minimum RAM: I've assembled a crude
demo[1] that shows that given a list of known integer-valued =
resources
on a device, it is possible to parse incoming =
SenML-03 with less than 30
bytes of state, with support =
for arbitrary SenML extensions, all legal
JSON number =
representations and full URL concatenation semantics.

With the -04 draft, one would have to allocate a buffer for =
the "n"
value, because before the object finishes, the =
"bn" might change later
in the same object, and change the =
context in which it needs to be
interpreted. This could be =
remedied by making base and entry updates
mutually =
exclusive (arguably a less straight-forward design), but as
things are, I'd prefer -03.

Best =
regards
Christian

[1] https://gitlab.com/c.amsuess-energyharvesting/senml-03-streamin=
g-parser-demo/tree/master

-- 
Christian Ams=FCss =
            &n=
bsp;        | Energy Harvesting =
Solutions GmbH
founder, system architect =
            | =
headquarter:
mailto:c.amsuess@energyharvesting.at  | =
Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =
            &n=
bsp;  | http://www.energyharvesting.at/
 =
            &n=
bsp;           &nbs=
p;            =
| ATU68476614
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


=

--Apple-Mail=_C2B0A943-0428-47DD-A651-7F9334C4CA52--


From nobody Sat Jan 16 10:33:07 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D761A1EB7 for ; Sat, 16 Jan 2016 10:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 yhGVMhKdGAR0 for ; Sat, 16 Jan 2016 10:33:03 -0800 (PST)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 5B00E1A1B65 for ; Sat, 16 Jan 2016 10:33:03 -0800 (PST)
Received: by mail-pa0-x22e.google.com with SMTP id ho8so150563242pac.2 for ; Sat, 16 Jan 2016 10:33:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=xEfsyaIANnehcUT6royZmK/CVd04Xg/k7qqZ5g2qF1o=; b=oB41sVbUM2CN1E4aoUWQFfajWAQPRURpIFqR2c/6gI6oRE9zyzeGPLS1y3JHeRk6Pw bgvu7uDYYyyPFgYH6Xc1sUJS7rSMGal6zdDf2y25seUYZwQpOy1AFe3NigFYxd8ppGOD 9dp7Pdi+Z/vZYrsXjJVNDMiXOygeakNQm6F7Fy/qmegfEwfs+74bYRiFPByf+UWPnDUg 6RX+J4mctEEmBsE4krP4tb5Bzgms6dzo2Lr5oVM4OA6D2DCzNPs1vK5bgnp4onus84Y3 kIPwcR0QTiAuu1SLcTailsu6t6w9NuZcVHoSthSrKstXooWeQt2lb6MtJRkc2HuSdxkI A0Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xEfsyaIANnehcUT6royZmK/CVd04Xg/k7qqZ5g2qF1o=; b=jUHHQxtrkVy9iPlTcTC4bVN2Wmx/VKFA0z2ucQVfQ+E9zILS1C01QvVzQVZ2+5BGER hBDY37cWK6h+MQOole1Ug+0o0UXzsf9nmpU4K839LcmNTb2C35BkwtsYLYKReBZwQLCS eflryWlMtJccc2fsag7ol1C+Rku8gjSUDwTPBcNVaE4Bo8VL5j21/VRf6adBIAHZioVv uq5FbbwOvyYrJ6Xs8z3r3xvhkZxKHHQWZVwTwJLdRsV/2eT2AwCL0Cgopw5Qn4HzqJGV aQjtmw0buDj3f3qSm+a/4powOePBA928gK26W0Do07V1GZLTr2mDLL4gLJxq7mEAGEpp 2ZWA==
X-Gm-Message-State: ALoCoQlss3PB1CtjwGwg8nII6UiM/uyEioZ70WaZ/N0VhsfLfDv1pG/k0OPAi1PqEcTc/jvjQ5EdiIfIx8QcEqmvPGUYleiLXQ==
X-Received: by 10.67.6.67 with SMTP id cs3mr24363928pad.143.1452969182909; Sat, 16 Jan 2016 10:33:02 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id m75sm23324553pfj.38.2016.01.16.10.33.01 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 10:33:01 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E013333B-066A-46A0-87FB-60EF6794F4D0"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <0D5538ED-D126-4A1B-AFDD-D9D54580D48B@gmail.com>
Date: Sat, 16 Jan 2016 10:33:00 -0800
Message-Id: 
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com>  <0D5538ED-D126-4A1B-AFDD-D9D54580D48B@gmail.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 18:33:06 -0000

--Apple-Mail=_E013333B-066A-46A0-87FB-60EF6794F4D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

A small correction. draft -02 and -04 have different top level =
structures. -02 is [ {b} [ {e} {e} ] ]  and -04 is [ {b} {e} {e} ] =
Either one both will work for me, since the I will be able to extend the =
base item as needed.=20

Michael

PS for correctness my example should look more like this:
[=20
  {=20
    "bn": "/light/brightness",
    "l": [
      { "href": "",
        "rel": ["self"],
        "rt": ["brightness", "action"]
      },
      { "href": "change",
        "rel": ["form", "item"],
        "rt": ["change", "form"],
        "ct": "application/forms+senml+json"
      },
      { "href": "tbr",
        "rel": ["item"],
        "rt": ["property", "param"],
        "ct": "application/senml+json"
      },     =20
      { "href": "tt",
        "rel": ["item"],
        "rt": ["property", "param"],
        "ct": "application/senml+json"
      },
      { "href": "actuations",
        "rel": ["sub"],
        "rt": "actuation",
        "ct": "application/collection+senml+json"
      }    =20
    ],
    "f": [
      { "id": "change",
        =93anchor": "../brightness"
        "rel": "change"
        "method": "post",
        "href": "actuations",
        "ct": "application/collection+json",
        "template": {
          "tbr": "$targetbrightness"
          "tt": "$transitiontime"
        }
      }
    ],
    "e": [
      { "n": "tbr",
        "v": "44.3",
      },
      { "n": "tt",
        "v": "1.0",
      }
    ]=09
  }
]

> On Jan 16, 2016, at 9:53 AM, Michael Koster =
 wrote:
>=20
> Here is a concrete proposal.=20
>=20
> My goal with the collection+senml content format is to create a format =
for machine hypermedia representations that is roughly analogous to a =
HTML web page in the web of documents world.=20
>=20
> The idea was a compact representation that can represent machine =
hypermedia data, links, and forms and would leverage existing formats =
and processors; link-format, senml, json.=20
>=20
> When I started, it looked like SenML was a good base due to what =
appeared to be an extension mechanism: the element tag that was an =
artifact of the XML serialization. I didn=92t expect it to be removed =
because I have XML/JSON tools that programmatically generate that style =
as a lossless XML-JSON transform. This is generally useful because EXI =
is still a very popular format and in many cases more compact than CBOR.
>=20
> If we can allow the base element to retain this functionality, and put =
the streaming support in the sequence of top level array elements, it =
seems like exactly what is needed. It retains backward compatibility =
with current senml implementations and allows some extensibility at both =
levels, while supporting sequential processing.
>=20
> I propose to restore the base senml functionality of draft -01 within =
the base element definition in the new draft, that is to allow =
measurement data within the base element using the =93e=94 key. To =
facilitate sequential processing, a topmost structure of array will =
allow an arbitrary sequence of base element maps and data element arrays =
as defined in draft -04.
>=20
> Are there any issues with this construction?=20
>=20
> Best regards,
>=20
> Michael
>=20
>=20
>> On Jan 16, 2016, at 7:24 AM, Michael Koster =
> =
wrote:
>>=20
>> Hi Christian,
>>=20
>> 1.
>> Thanks for the code example! It seems well optimized indeed.
>>=20
>> It also serves to highlight one of the points.=20
>>=20
>> It=92s more than just a matter of me liking my own favorite language =
(actually library) internal representation of JSON. Most modern =
libraries produce dictionary and array representations for parsed JSON =
that work more or less the same way.
>>=20
>> The optimizations you recommend require a new string input parser, =
where I am using the JSON parser that comes with the library. My point =
was that I will need to either make my own string parser for SenML or =
make a re-parser with the state machine I described in order to use -02 =
+ but there is another issue anyway:
>>=20
>> One of the big advantages of using JSON is connecting the embedded =
world to the web world. To do this in a low-friction way, it=92s good to =
be able to use well known tools and patterns. Streaming JSON=20
>> 2.=20
>> Thanks also for looking into my code. I could easily use the -02 or =
-03 in the senml processing as you show. What is missing still from =
everything after -01 is the element tag that I am re-using to indicate =
links and forms in the document:
>>=20
>> {
>>   "bn":"/3300/1/",
>>   "e":[
>>     {"n":"5700","v":"31.3"},
>>     {"n":"5602","v":"37.1"},
>>     {"n":"5601","v":"18.3"},
>>     {"n":"5605"},
>>     {"n":"5603","v":"0"},
>>     {"n":"5604","v":"100"},
>>     {"n":"5750","sv":"Inboard Bearing"}
>>   ],
>>   "l":[
>>     {"href":"","rel":"self","rt":"temperature","u":"C"},
>>     {"href":"5700","rt":"currentValue","u":"C"},
>>     {"href":"5602","rt":"maxValue","u":"C"},
>>     {"href":"5601","rt":"minValue","u":"C"},
>>     {"href":"5605","rt":"resetMaxMin"},
>>     {"href":"5603","rt":"minScale","u":"C"},
>>     {"href":"5604","rt":"maxScale","u":"C"},
>>     {"href":"5750","rt":"appType"}
>>   ]
>> }
>>=20
>> I will think about other designs that do not depend on entity tags in =
the representation; maybe there is a better design for the content =
format in general. But I would still like to use SenML. Maybe not extend =
it but embed it in another new format=85
>>=20
>> In the meantime, I don=92t have a good alternative yet.
>>=20
>> Best regards,
>>=20
>> Michael
>>=20
>> PS Can we succinctly describe the use case for ordered serial =
processing of senml+json elements being important? =46rom reading the =
draft, it seems like the important bit is saving the buffer memory for =
large responses. Is it a bigger deal with CBOR encoding or less =
important.=20
>>=20
>> Is the most important consideration being able to know the base =
values ahead of the data?=20
>>=20
>> Also, where is -03? there doesn=92t seem to be a version -03 that you =
all are talking about on the IETF website:
>> https://tools.ietf.org/html/draft-jennings-core-senml-04 =

>>=20
>>=20
>>> On Jan 16, 2016, at 5:27 AM, Christian Ams=FCss =
> =
wrote:
>>>=20
>>> Hello Cullen,
>>>=20
>>> On Wed, Jan 13, 2016 at 01:57:02PM +0000, Cullen Jennings (fluffy) =
wrote:
>>>> The objects can also have the base values right in the object and =
the
>>>> base values apply to all the things in the object and any future
>>>> objects in the array.=20
>>>>=20
>>>> Appreciate any thoughts people have on pro / cons of the -03 design =
vs -04 design.
>>>=20
>>> The -03 draft is parsable with minimum RAM: I've assembled a crude
>>> demo[1] that shows that given a list of known integer-valued =
resources
>>> on a device, it is possible to parse incoming SenML-03 with less =
than 30
>>> bytes of state, with support for arbitrary SenML extensions, all =
legal
>>> JSON number representations and full URL concatenation semantics.
>>>=20
>>> With the -04 draft, one would have to allocate a buffer for the "n"
>>> value, because before the object finishes, the "bn" might change =
later
>>> in the same object, and change the context in which it needs to be
>>> interpreted. This could be remedied by making base and entry updates
>>> mutually exclusive (arguably a less straight-forward design), but as
>>> things are, I'd prefer -03.
>>>=20
>>> Best regards
>>> Christian
>>>=20
>>> [1] =
https://gitlab.com/c.amsuess-energyharvesting/senml-03-streaming-parser-de=
mo/tree/master =

>>>=20
>>> --=20
>>> Christian Ams=FCss                      | Energy Harvesting =
Solutions GmbH
>>> founder, system architect             | headquarter:
>>> mailto:c.amsuess@energyharvesting.at =
  | Arbeitergasse 15, A-4400 Steyr
>>> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/ 
>>>                                      | ATU68476614
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/core =

>>=20
>=20


--Apple-Mail=_E013333B-066A-46A0-87FB-60EF6794F4D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

A small correction. draft -02 and -04 have different top =
level structures. -02 is [ {b} [ {e} {e} ] ]  and -04 is [ {b} {e} =
{e} ] Either one both will work for me, since the I will be able to =
extend the base item as needed. 

Michael

PS for correctness my example should =
look more like this:
[ 
  =
{ 
    "bn": "/light/brightness",
    "l": =
[
  =
    { "href": "",
        "rel": =
["self"],
        "rt": ["brightness", =
"action"]
      },
      { "href": =
"change",
        "rel": ["form", =
"item"],
        "rt": ["change", =
"form"],
        "ct": =
"application/forms+senml+json"
      },
      { =
"href": "tbr",
        "rel": ["item"],
        =
"rt": ["property", "param"],
        "ct": =
"application/senml+json"
      },     =
 
      { "href": "tt",
        =
"rel": ["item"],
        "rt": ["property", =
"param"],
        "ct": =
"application/senml+json"
      },
      { "href": =
"actuations",
        "rel": ["sub"],
        =
"rt": "actuation",
        "ct": =
"application/collection+senml+json"
      }   =
  
    ],
    "f": [
      { "id": =
"change",
        =93anchor": =
"../brightness"
        "rel": "change"
        =
"method": "post",
        "href": =
"actuations",
        "ct": =
"application/collection+json",
        "template": =
{
  =
        "tbr": "$targetbrightness"
        =
  "tt": "$transitiontime"
        =
}
  =
    }
    ],
    "e": [
      { "n": =
"tbr",
        "v": "44.3",
      =
},
  =
    { "n": "tt",
        "v": =
"1.0",
      }
    ]	
  }
]

On Jan 16, 2016, at 9:53 AM, Michael Koster =
<michaeljohnkoster@gmail.com> wrote:

Here is a =
concrete proposal. 

My goal with the collection+senml content format is to create =
a format for machine hypermedia representations that is roughly =
analogous to a HTML web page in the web of documents world. 

The idea was a compact =
representation that can represent machine hypermedia data, links, and =
forms and would leverage existing formats and processors; link-format, =
senml, json. 

When I started, it looked like SenML was a good base due to =
what appeared to be an extension mechanism: the element tag that was an =
artifact of the XML serialization. I didn=92t expect it to be removed =
because I have XML/JSON tools that programmatically generate that style =
as a lossless XML-JSON transform. This is generally useful because EXI =
is still a very popular format and in many cases more compact than =
CBOR.

If we =
can allow the base element to retain this functionality, and put the =
streaming support in the sequence of top level array elements, it seems =
like exactly what is needed. It retains backward compatibility with =
current senml implementations and allows some extensibility at both =
levels, while supporting sequential processing.

I propose to restore the base senml =
functionality of draft -01 within the base element definition in the new =
draft, that is to allow measurement data within the base element using =
the =93e=94 key. To facilitate sequential processing, a topmost =
structure of array will allow an arbitrary sequence of base element maps =
and data element arrays as defined in draft -04.

Are there any issues with this =
construction? 

Best regards,

Michael

On Jan 16, 2016, at 7:24 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi =
Christian,

1.
Thanks for the code example! It seems =
well optimized indeed.

It also serves to highlight one of the =
points. 

It=92s more than just a matter of me liking my own favorite =
language (actually library) internal representation of JSON. Most modern =
libraries produce dictionary and array representations for parsed JSON =
that work more or less the same way.

The optimizations you recommend require =
a new string input parser, where I am using the JSON parser that comes =
with the library. My point was that I will need to either make my own =
string parser for SenML or make a re-parser with the state machine I =
described in order to use -02 + but there is another issue =
anyway:

One of =
the big advantages of using JSON is connecting the embedded world to the =
web world. To do this in a low-friction way, it=92s good to be able to =
use well known tools and patterns. Streaming JSON 
2. 
Thanks also for looking into my =
code. I could easily use the -02 or -03 in the senml processing as you =
show. What is missing still from everything after -01 is the element tag =
that I am re-using to indicate links and forms in the =
document:

{
  =
"bn":"/3300/1/",
  "e":[
    {"n":"5700","v":"31.3"},
    =
{"n":"5602","v":"37.1"},
    {"n":"5601","v":"18.3"},
    =
{"n":"5605"},
    {"n":"5603","v":"0"},
    =
{"n":"5604","v":"100"},
    {"n":"5750","sv":"Inboard =
Bearing"}
  ],
  "l":[
    =
{"href":"","rel":"self","rt":"temperature","u":"C"},
    =
{"href":"5700","rt":"currentValue","u":"C"},
    =
{"href":"5602","rt":"maxValue","u":"C"},
    =
{"href":"5601","rt":"minValue","u":"C"},
    =
{"href":"5605","rt":"resetMaxMin"},
    =
{"href":"5603","rt":"minScale","u":"C"},
    =
{"href":"5604","rt":"maxScale","u":"C"},
    =
{"href":"5750","rt":"appType"}
  ]
}

I will think about other designs that =
do not depend on entity tags in the representation; maybe there is a =
better design for the content format in general. But I would still like =
to use SenML. Maybe not extend it but embed it in another new =
format=85

In =
the meantime, I don=92t have a good alternative yet.

Best regards,

Michael

PS Can we succinctly =
describe the use case for ordered serial processing of senml+json =
elements being important? =46rom reading the draft, it seems like the =
important bit is saving the buffer memory for large responses. Is it a =
bigger deal with CBOR encoding or less important. 

Is the most important =
consideration being able to know the base values ahead of the =
data? 

Also, where is -03? there doesn=92t seem to be a version -03 =
that you all are talking about on the IETF website:
https://tools.ietf.org/html/draft-jennings-core-senml-04


On Jan 16, 2016, at 5:27 AM, Christian =
Ams=FCss <c.amsuess@energyharvesting.at> wrote:

Hello Cullen,

On Wed, Jan 13, 2016 at 01:57:02PM +0000, =
Cullen Jennings (fluffy) wrote:
The objects can also have the base values right in the object =
and the
base values apply to all the things in the object =
and any future
objects in the array. 

Appreciate any thoughts people have on pro / cons of the -03 =
design vs -04 design.

The -03 =
draft is parsable with minimum RAM: I've assembled a crude
demo[1] that shows that given a list of known integer-valued =
resources
on a device, it is possible to parse incoming =
SenML-03 with less than 30
bytes of state, with support =
for arbitrary SenML extensions, all legal
JSON number =
representations and full URL concatenation semantics.

With the -04 draft, one would have to allocate a buffer for =
the "n"
value, because before the object finishes, the =
"bn" might change later
in the same object, and change the =
context in which it needs to be
interpreted. This could be =
remedied by making base and entry updates
mutually =
exclusive (arguably a less straight-forward design), but as
things are, I'd prefer -03.

Best =
regards
Christian

[1] https://gitlab.com/c.amsuess-energyharvesting/senml-03-streamin=
g-parser-demo/tree/master

-- 
Christian Ams=FCss =
            &n=
bsp;        | Energy Harvesting =
Solutions GmbH
founder, system architect =
            | =
headquarter:
mailto:c.amsuess@energyharvesting.at  | =
Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =
            &n=
bsp;  | http://www.energyharvesting.at/
 =
            &n=
bsp;           &nbs=
p;            =
| ATU68476614
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core



=

--Apple-Mail=_E013333B-066A-46A0-87FB-60EF6794F4D0--


From nobody Sat Jan 16 10:55:00 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC8B1A9053 for ; Sat, 16 Jan 2016 10:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 BkU1nWpu4_tx for ; Sat, 16 Jan 2016 10:54:57 -0800 (PST)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0A41A9047 for ; Sat, 16 Jan 2016 10:54:56 -0800 (PST)
Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 30B15A80CD; Sat, 16 Jan 2016 19:54:55 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id LrEHgb-DRLPp; Sat, 16 Jan 2016 19:54:53 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C1FE2A80CA; Sat, 16 Jan 2016 19:54:52 +0100 (CET)
Message-ID: <569A91FD.3020709@tzi.org>
Date: Sat, 16 Jan 2016 19:54:53 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Michael Koster 
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com>  <0D5538ED-D126-4A1B-AFDD-D9D54580D48B@gmail.com>
In-Reply-To: <0D5538ED-D126-4A1B-AFDD-D9D54580D48B@gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core , =?UTF-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 18:54:58 -0000

Michael Koster wrote:
> allow measurement data within the base element using the “e” key.

The reason -02 doesn't do that is that a sequentially operating
implementation may get process the "e" key before the base values,
possibly requiring it to buffer the values.  That's why we tried to
separate the measurements from the base values into different maps.

Grüße, Carsten


From nobody Sat Jan 16 11:02:59 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771CA1A9088 for ; Sat, 16 Jan 2016 11:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 iw3lF5zJAO_8 for ; Sat, 16 Jan 2016 11:02:57 -0800 (PST)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 E27471A908D for ; Sat, 16 Jan 2016 11:02:56 -0800 (PST)
Received: by mail-pa0-x229.google.com with SMTP id yy13so318867682pab.3 for ; Sat, 16 Jan 2016 11:02:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cj6fxClnZM0of7xBtpLt73bfiWyVtl478xhEwrdc0V4=; b=EIJ+NeTt5bKLm491Y8FW/JGRwTsYai2t3+npcmq9q5HWXUuYN3PgZ5ngbA3TIa2KEr KpLTfBPO75Q6uui33ijeRMkonfXl16EOMhQR2Ya6Lo3yi/JsdI/QPaayn6OBv7kqCcAT wHwS6zbhcMr3JJZu2xfPYhao8QZcmqifzjO4b1NSXZLRcmnfQzaHvzz36FZvpXcZvr3C BpIHOWysd+EgR3RYF/zwCdLjiGe4VGVwgfIS1T26evzbqIQlYeFzWjfxC1a33eGKpqne udnvbXQvb2ua+zht4OjTWgswa3P3vcL5/rY5kZB3r+RNiVAfwe7tJrRXbTZyaPNL8pQ3 khxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cj6fxClnZM0of7xBtpLt73bfiWyVtl478xhEwrdc0V4=; b=k0eKiJwyvqxa2xN5qgKJJfyDPw+WHP900rEar/0hGEMOJI9q6DYefgda5KUkn0bQUD f9ZEBmHeK0FSr5plXq4xsGsXflXXw90bGb6xB5wB2szg0EULRBQfdRDCM4OuqKNEXQzL 2c7vxWNEMfduRNtBQM8lZ5VldG+6l39PBcGG5YcYDUannBaxOYYVtQjTJFTxHVMjiK3M brVOIJqadCje0dyEDCnkw595qnleYD4XocjQxFl6pp97XSpkLhZ5WREElacHxVeYjLTQ KdYJGZmqbqR3WYEr2aXWrHW9Qd+Cj+1s6Xj15GdL6ADSk7dcPor88aNhotObVWsxm1rl i13g==
X-Gm-Message-State: AG10YOTIWtjHdB9tTi1uL48Fw8/VNUbKN59HIpFmV1zaLEXf7+72FuZHxNbAOwm7zjU0IQ==
X-Received: by 10.66.121.194 with SMTP id lm2mr13852503pab.27.1452970976580; Sat, 16 Jan 2016 11:02:56 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id ux2sm23389307pac.46.2016.01.16.11.02.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 11:02:55 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <569A91FD.3020709@tzi.org>
Date: Sat, 16 Jan 2016 11:02:54 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DDF2957-1F11-414B-82D6-8BB721060750@gmail.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com>  <0D5538ED-D126-4A1B-AFDD-D9D54580D48B@gmail.com> <569A91FD.3020709@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core , =?utf-8?Q?Christian_Ams=C3=BCss?= 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 19:02:58 -0000

Yes, so if you want to stream, create an array with a base record and =
value records.

If you want to map, put your values into the base element with a =E2=80=9C=
e=E2=80=9D tag.

Michael

> On Jan 16, 2016, at 10:54 AM, Carsten Bormann  wrote:
>=20
> Michael Koster wrote:
>> allow measurement data within the base element using the =E2=80=9Ce=E2=80=
=9D key.
>=20
> The reason -02 doesn't do that is that a sequentially operating
> implementation may get process the "e" key before the base values,
> possibly requiring it to buffer the values.  That's why we tried to
> separate the measurements from the base values into different maps.
>=20
> Gr=C3=BC=C3=9Fe, Carsten


From nobody Sat Jan 16 11:04:02 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC581A908D for ; Sat, 16 Jan 2016 11:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 kypd17d2zzIq for ; Sat, 16 Jan 2016 11:03:59 -0800 (PST)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 AABA41A9088 for ; Sat, 16 Jan 2016 11:03:59 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id 65so134965801pff.2 for ; Sat, 16 Jan 2016 11:03:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hNSs3s2B/bjQWfBobvStUQDIC04uBd6fBGaaaJqxQW0=; b=kVbnElvk7/8NXsmLfohQBogfHEQPHHGFUQMXePYh7Wbz3bi7VJVix4l+CfGhvb4wFo 2//lnR06q8rdFAXp1lv/53n4MCCVibbc1CUc1qxHqEcCJqss67K4kU1BCFTR1vOEhVzi JTMEFzOc5A36HkMtBZI00pSFDazQFmah+NomrlmH8HJrfrELg/bc14lzr4uxPKROdtcm E7Rz2tOq2e62EU6IOuQeTaLytDyZ+s+7H3mDi8ZPiwtyaBYIqEO0tPiQEgUXijXenIlT obJ/OOTQMzgul1BMKBXSp0fJXkRveIBNf1O40EuRMBfXz8KhB3TVSgpkJVy8xTbTmP6N MRig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hNSs3s2B/bjQWfBobvStUQDIC04uBd6fBGaaaJqxQW0=; b=XSvjeN/gETEKG92igsMNsHlc4YGsrDSsJaMAkDc6y1GRh3tFMvOPVBaozJE380dH6H m6u4RIje5kklU5GxXQaEN1qfGrizAfsFS/QpG5fyd+huQxnyb8XgWLF9IjGmcoQbiAUf m6+NT9ir3/TfUQ7y7KsUVWpgY9HXOZ8AQR1MOpKpBVpupGZWyGSc15httUIP4VK1LQUb x1uH143dOl0fg8SEYoPDGxQxWqXGgpqtRCvJvdb//AVDKHNc6VcrxfRKrvKX7HV1vSrs bYAIWxU79aGtq38yo7/eFPgGAWDeynbFs2H0AMze0dwQwZ9bp7aDPolXxcnJnM53yX8l hTKg==
X-Gm-Message-State: ALoCoQl5xKVeT8hl1Qx6KAiDavhPwjpgIxiNAUyExWFmME7zsY8VWhKCQ0AV6/QeaHt51aWNCMOHjgR3xMFzfvH/tanAgXBQ2A==
X-Received: by 10.98.68.193 with SMTP id m62mr24379594pfi.153.1452971039410; Sat, 16 Jan 2016 11:03:59 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id x10sm23386949pas.37.2016.01.16.11.03.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 11:03:58 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <569A91FD.3020709@tzi.org>
Date: Sat, 16 Jan 2016 11:03:57 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <56702BF4-625F-4364-9D2D-76912CC8F7EB@gmail.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com>  <0D5538ED-D126-4A1B-AFDD-D9D54580D48B@gmail.com> <569A91FD.3020709@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core , =?utf-8?Q?Christian_Ams=C3=BCss?= 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 19:04:01 -0000

The processing rule is each array element may (must in some cases) be =
processed in sequence

> On Jan 16, 2016, at 10:54 AM, Carsten Bormann  wrote:
>=20
> Michael Koster wrote:
>> allow measurement data within the base element using the =E2=80=9Ce=E2=80=
=9D key.
>=20
> The reason -02 doesn't do that is that a sequentially operating
> implementation may get process the "e" key before the base values,
> possibly requiring it to buffer the values.  That's why we tried to
> separate the measurements from the base values into different maps.
>=20
> Gr=C3=BC=C3=9Fe, Carsten


From nobody Sat Jan 16 11:06:01 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2005C1A9092 for ; Sat, 16 Jan 2016 11:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 dcqfe_1sGHwE for ; Sat, 16 Jan 2016 11:05:59 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 E744D1A9091 for ; Sat, 16 Jan 2016 11:05:58 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id q63so139004102pfb.1 for ; Sat, 16 Jan 2016 11:05:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3O1FpJLsMISdDUJJi45ClU3Kj+6HvNuiAH/TxBcAeJU=; b=sX8uPt8TPFifZQrAU7BGHdKhRdSScIdFVT3KvMBpaILqBEiB40lgGEoRF6Awt2QBVQ UnTOTmtuzarbzFvkz0wXG0Cy91V3bIU4+ss79NwwIbq7nI9AuMVHpF2McPOKO2sVsZmy ysmUmP9f7e+sJLUVKgI3mGcBLWfgoU8RMg2dgpHXjO0Vfov7gRNLOHIhK9ssdIz6lLhG cNtg/5gyiYbw7sI3Jg+Fbe7M043VWRBBibId+4mGisl22VVsVz1AYRm+MfS1DnHyT+jb l8cxl6Pvl9m0/ur5wmNAUs4he5L1RM/jL2wkcT+Jfnk79GGC1hU1ZdJlTXNZqN0jQRXu /TJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3O1FpJLsMISdDUJJi45ClU3Kj+6HvNuiAH/TxBcAeJU=; b=QYz6HZZKJ23uE3B2hxAjVNxyMHu2OjndsOWodJx61QCq37HngwpfXe+bjUtDvKznT8 eIHpe1Bpl5NBiYF6ROdTjj4t2/MOIOzDtcBQ04MXMVVdf7uZjjXKhrGqibG5tn1K9oc0 JS0lrf0LhfIS1FinopqLFfacfeZsIPb/0bZgrDgu9epzdO5ZqzOiUiHYXbbTErGFwEa3 rO64x5TRWpLeg+r2XBgDTmuiDo1XSawuC9Io5b12aIxzXM7v2ce8jyDToNdJg3OBc6MG O3qrhZii8kchWwMSwRmT4JSBPKtoH7VpHdLReLh5m1Z+9kvqb5pvBwlmG1LCMOQDPfYu JMoA==
X-Gm-Message-State: ALoCoQkx+Z1o31yrAtG0U6HBzmiHvOAS7XebhZ2dx2XZEZxZMCUEhJpwWFmWwgzvGnhG4YkCm/5eFSKyelontWKkJkVrcLdV7Q==
X-Received: by 10.98.2.150 with SMTP id 144mr24594199pfc.11.1452971158553; Sat, 16 Jan 2016 11:05:58 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 89sm22217998pfs.63.2016.01.16.11.05.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 11:05:58 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <56702BF4-625F-4364-9D2D-76912CC8F7EB@gmail.com>
Date: Sat, 16 Jan 2016 11:05:56 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <20160116132751.GB18563@hephaistos.amsuess.com>  <0D5538ED-D126-4A1B-AFDD-D9D54580D48B@gmail.com> <569A91FD.3020709@tzi.org> <56702BF4-625F-4364-9D2D-76912CC8F7EB@gmail.com>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core , =?utf-8?Q?Christian_Ams=C3=BCss?= 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 19:06:00 -0000

And maps must be consumed before processing. So keep your maps small and =
use arrays

> On Jan 16, 2016, at 11:03 AM, Michael Koster =
 wrote:
>=20
> The processing rule is each array element may (must in some cases) be =
processed in sequence
>=20
>> On Jan 16, 2016, at 10:54 AM, Carsten Bormann  wrote:
>>=20
>> Michael Koster wrote:
>>> allow measurement data within the base element using the =E2=80=9Ce=E2=
=80=9D key.
>>=20
>> The reason -02 doesn't do that is that a sequentially operating
>> implementation may get process the "e" key before the base values,
>> possibly requiring it to buffer the values.  That's why we tried to
>> separate the measurements from the base values into different maps.
>>=20
>> Gr=C3=BC=C3=9Fe, Carsten
>=20


From nobody Mon Jan 18 03:05:11 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E261B34BA for ; Mon, 18 Jan 2016 03:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.886
X-Spam-Level: *
X-Spam-Status: No, score=1.886 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FAKE_REPLY_C=1.486, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3] autolearn=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 qEimzwH3jiaW for ; Mon, 18 Jan 2016 03:05:07 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636701B34B4 for ; Mon, 18 Jan 2016 03:05:06 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 68960418AB; Mon, 18 Jan 2016 12:05:03 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4AA5C2D; Mon, 18 Jan 2016 12:05:01 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 10B132F; Mon, 18 Jan 2016 12:05:01 +0100 (CET)
Received: (nullmailer pid 15079 invoked by uid 1000); Mon, 18 Jan 2016 11:05:00 -0000
Date: Mon, 18 Jan 2016 12:05:00 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Michael Koster 
Message-ID: <20160118110500.GA7789@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn"
Content-Disposition: inline
In-Reply-To: <7DA00BBA-4869-4351-97E3-6B45311B28A2@gmail.com>  
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 11:05:10 -0000

--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Michael,

it appears that there are three concepts both being called or related to
"streaming" that get mixed up in this thread, I'll try to flesh them out
fist, describing their purpose, status of drafts, and interaction with
client and server side.

A. The draft paragraph about "store or transmit SenML in a stream-like
  fashion" in the "Multiple Datapoints" section:

  This is more about transportation, and implies that there is some kind
  of boundary between elements at which transmission can pause.
 =20
  Such boundaries are present in all drafts so far.

  It appears to me that this would primarily work with HTTP in a fashion
  similar to long polling, which is something both communicating parties
  need to be aware of (all drafts: "MUST specify that they are doing
  this"), lest they time out the connection.

B. Buffer-less operation:

  For very small applications (eg. using uIP and few kB of RAM), it is
  desirable to use data formats that never require back-seeking, that
  limit back-seeks to a fixed length or that can do with a fixed-length
  buffer to hold information for that. The specification does not need
  to actively describe those operations, requiring some basic structure
  is sufficient.

  It has been suggested earlier on this list that -01 with an additional
  requirement that "bn" and "bt" to come first in the dictionaries would
  allow this mode of operation too -- truth, but hard to achieve with
  generic JSON implementations and semantics.

  Thus, this goal is only achieved by drafts -02 and later. (This is
  also what my demo is about, which shows that -03 is particularly
  suitable).

  That this only an issue for the receiving side (the sender is free
  to choose element sequences as is most practical for it anyway, as
  long as it follows the specification). Having this negotiable would
  defeat its purpose: If receivers may rely on it, we can't allow
  senders to not support it.

C. Multiple base elements:

  The idea to have multiple base elements came up independently of the
  others, and gives smaller data streams for cases in which different
  sensors' time series are produced, or when there are larger gaps in a
  timeline. The proposal worked well with the array-as-root scheme
  envisioned with exactly 2 elements for B., and was implemented
  together.

  It is present in -03 and -04.

  Senders are free not to use it. In my impression, this is easily to
  implement in receivers. (Even if they desire to directly access
  in-memory representations of JSON; the key to an entry might then be
  (list-number, list-position) instead of just list-position).


> PS Can we succinctly describe the use case for ordered serial
> processing of senml+json elements being important? From reading the
> draft, it seems like the important bit is saving the buffer memory for
> large responses.=20

The one I'm arguing here is B., the buffer-less operation. The use case
are devices with limited heap memory (say 4k for incoming and outgoing
packages). I'm using SenML in core-interfaces batches[1] to get and set
device state. When those devices announce supporting batch operation,
they need to accept SenML PUTs to as many resources as are batched
together, so far without arbitrary constraints. Due to the proposed
extensibility of SenML, even if I limited the number of resources in a
batch, I couldn't predict the maximum size of an incoming update.

Now when the update arrives and a SenML that does not satisfy B. comes
in, all I can do is to store the whole message body and parse it when
the last block arrived. If the sender updated too many resources or used
too large extensions, I'd need to 4.13-Request-Entity-too-large out.
Still, until then (particularly until the overflowing package arrives),
memory is clogged with unparsable data.

> Is it a bigger deal with CBOR encoding or less important.=20

Whether CBOR or JSON is being parsed is almost irrelevant here. The only
difference that comes to my mind is that with CBOR, we might be able to
prescribe a serialization where "bn" and "bt" always precede "e" even in
-01-style, but even that would make it harder to utilize for whomever
implement this with a native-object-style library.

> Is the most important consideration being able to know the base values
> ahead of the data?

This is about all information that may be in the dictionary and modifies
how to interpret the elements' data. In core SenML, that information is
the base attributes, and the version -- that is, all the possible root
variables. (In a scenario .)

For extensions, this completely depends on them unless the receiver
chooses to ignore them anyway. As far as I understand, your link format
extension could add items to a core-interfaces linked batch, and then
set a value in one go; for that, the extension data would need to
precede the elements in parsing. Other extensions (say, metadata about
when to expect changes) may be useful no matter where in the data stream
it appears.

[1] https://tools.ietf.org/html/draft-ietf-core-interfaces-04#section-6.2

> Also, where is -03? there doesn=E2=80=99t seem to be a version -03 that y=
ou all are talking about on the IETF website:
> https://tools.ietf.org/html/draft-jennings-core-senml-04 

The data tracker (or rather tools.ietf.org) seems not to take drafts
submitted on the same day well. You can view it as [2].

[2] https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/?include_=
text=3D1

On Sat, Jan 16, 2016 at 07:24:41AM -0800, Michael Koster wrote:
> The optimizations you recommend require a new string input parser,
> where I am using the JSON parser that comes with the library. My point
> was that I will need to either make my own string parser for SenML or
> make a re-parser with the state machine I described in order to use
> -02 +[...]

I don't see yet where the state machine comes in. Surely, much
state-machingin is going on in the optimized example, but when it comes
to the core difference from -01 to -02, that is, that

    {any-key-but-e: any-data, "e": elements-list}

becomes

    [{any-key-but-e: any-data}, elements-list]

, I don't see how this is not changing access from _senml[key] to
_senml[0][key] or _senml["e"] to _senml[1].

(If it's about the C. multiple-base-elements, I'd ask to keep these
issues separate -- if C. breaks too much, although I like it, we could
have a -02 with only two elements and still satisfy B., but I don't
think we need to resort to that.)

> [...] but there is another issue anyway:
>=20
> One of the big advantages of using JSON is connecting the embedded
> world to the web world. To do this in a low-friction way, it=E2=80=99s go=
od to
> be able to use well known tools and patterns.

I fully agree that easy use of established web tools is essential here:
but these very threads are where we should come up with mechanisms that
work both with them and constrained devices.


There is one point where I think that state-machining over incoming JSON
objects does make sense, that is when it comes to names -- I like to see
them as URIs (that's consistent with the examples given, but not fully
required in the drafts), and when the "n" elements are relative URIs,
they are not useful until joined with the base name. But that is not a
change introduced in -01, but a preference of mine that is reflected in
the demo to show that relative URIs are not that complicated even for
embedded systems. (Existing web tools usually have their ways of joining
URIs shipped).


> Thanks also for looking into my code. I could easily use the -02 or
> -03 in the senml processing as you show. What is missing still from
> everything after -01 is the element tag that I am re-using to indicate
> links and forms in the document:

I did see that you had extensions in your code, but as Carsten
suggested, the "l" could stay in the first dictionary alongside the "bn"
and "ver". Maybe the name "base dictionary" is suboptimal here -- the
dictionary itself is not something that gets somehow prefixed to the
following entries, it's just the place where the base attributes reside
along with other things, like "ver" and extensions.


On Sat, Jan 16, 2016 at 09:43:55AM -0800, Michael Koster wrote:
> It would be useful if the order of top level element types could be arbit=
rary e.g.: [ {},[],[],[],{},[],{},{} ... ]

That's something I could well see in a -05. It would also make minimal
SenML files that don't use any base attributes a little smaller, and
embedded parsing wouldn't suffer from it AFAICT.

On Sat, Jan 16, 2016 at 10:33:00AM -0800, Michael Koster wrote:
> PS for correctness my example should look more like this:
> [=20
>   {=20
>     "bn": "/light/brightness",
>     "l": [ ... ],
>     "f": [ ...],
>     "e": [
>       { "n": "tbr", "v": "44.3", },
>       { "n": "tt", "v": "1.0", }
>     ]
>   }
> ]

Just let's please not allow the "e" element any more. Anything with a
top-level array is incompatible with older draft users anyway.


Best regards
Christian

--=20
Christian Ams=C3=BCss                      | Energy Harvesting Solutions Gm=
bH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--bp/iNruPH9dso1Pn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWnMbYAAoJEDmNERLTpL3hmzsQAJQ02wadyWZtRTp3eTnROUqU
H2H8PEJlVMEWSRZy/POJEZ0BS5kPHJjf8Kuwez3Tu/lQmcvp1IKkiNtyR5eGcfoh
FoK59/x1I1mhgS2JAx6h0jjRD8/jHe36S6f+INwTtA0USc1Y9ck5XbZ+85RQ+6WX
XXBI+6nbgSxSSI1i5mc9eUv7QOisCt2IQXzFsyjPGNgLNnaZnF/+bQcqsi8PcY4R
bJYZ26Q2EypUCL7ZIquHGG//OmPZjcKrhxns2jS7L64CrruT1tf6vBv1UhKlL44m
7esu59o27JxNWIgNTy/KwWVsBEJCmMgll82sR8jq+OTa+sojQQkkw7ausVmC/Xv4
0jRm0zmqttxDh8uMPuL4Bc0BNokW8Lw7/Pk7PuzJu4NXCbjZpiYTGuk9TysbJPKd
kHoW4CpAP6oLsVRhWuvSIbnOG9ovgp1lab1T9GmQct5HOhE5kOaWzwqiggKUeJL5
0vYJ2eMoDqLh9obQyYZ8fv3iJeKf1ZNov5OzLiB1VeInXWZJuUpaxJe2hCV/8xIg
MuclPAp5skK5cKYOJFBv/yrxi/CJHFSbRh3PsgiClfPq+XvtkNzzHsXm5C3ma/gh
NontsCNEUdlEIGieSgq7+sBA2dfDA6G1uFGDcKVFaCdSvZdNmAxzgx43eJ5L1I7i
d/fGc0vZMoLeq+qAi4sc
=Tdy0
-----END PGP SIGNATURE-----

--bp/iNruPH9dso1Pn--


From nobody Mon Jan 18 07:42:20 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893611B38AC for ; Mon, 18 Jan 2016 07:42:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 3v3WHzMAAr5L for ; Mon, 18 Jan 2016 07:42:14 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 D82361B389D for ; Mon, 18 Jan 2016 07:42:13 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id n128so159453906pfn.3 for ; Mon, 18 Jan 2016 07:42:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ll8QwTD8sH1yxB1lOGpwYyKgiqhus36eNhfgZ4yGOhY=; b=YgbTGEBy07MJmwM6sfyK9LF4+JB1fiJnEP2TzbzF6SwuVK+F1bichep0b35/Y7EE8v gXy39xl6rULlkcMuNA939OkbvT7ukY4XugRt6MPMOccqWjWDDJQOyWbYzFIz36x3at9G h9UOnJpVY7pAVevWPY3CXzpGUobhyT2WkWfJuoH6KT4QBU1mRYrGI4nDEMM3mrhDSfb/ f6opLX80C7iKo41l6TQ2xFvX9VadOK9qb8vOHOKjC5IW2815TbGpPK1Bo0WjlwMpjcf3 mddUk4XL90oFffBgnNDl404MWKYs6FlEgMKOLLKqBxFH8kUd5iE9vbwCslj7NK8r0PYJ HFbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Ll8QwTD8sH1yxB1lOGpwYyKgiqhus36eNhfgZ4yGOhY=; b=kUa2t43unf+VHq+NwfxKx1wTghc+AkjvTQgRX5Oi/cIspDI9I1OBEllUZxBAQYaHwj ZMHvZ3471NvwEbC/3sBybCFYR/fGCpI5r0jZuyEgBjj4Yl6Ga09S9EJ6fiLZUtoYspRY Z3GoTFCs6SqKx5xY7iTDZu/tCpVHu9+W5BiwmTDR7e3NVUW1Eom4C1zUXTOeqcZXirCA 3rOfKDtGOBwDQ40Ry2EnnrGY0qjgiMaNJ2E69ZQYJUPS+5F/jzpO7vd5HPXVzad9GzLs 0H2tzUlFaDO5VAFCdSp6BjaL0Xh5QVz//uAjy5akpkNwoOBKk5dHWefgPTPXxFxHorDW 0hhg==
X-Gm-Message-State: ALoCoQnwvpGXqAvzO7U8EWMrnan058XoNShXzzJKbGz8fp60w0OPwlQo/LJjKHY6//4R7UUcKomJEmEMPRtrP/d/HcEpqX04Iw==
X-Received: by 10.98.42.213 with SMTP id q204mr37305565pfq.141.1453131733425;  Mon, 18 Jan 2016 07:42:13 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id i76sm34866904pfj.68.2016.01.18.07.42.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 07:42:12 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_21C4F613-C5D6-4029-B236-219FDE45F1B6"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <20160118110500.GA7789@hephaistos.amsuess.com>
Date: Mon, 18 Jan 2016 07:42:10 -0800
Message-Id: <7BEAC3D7-C2B8-42A2-9496-DDED5837ACF2@gmail.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 15:42:18 -0000

--Apple-Mail=_21C4F613-C5D6-4029-B236-219FDE45F1B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Christian,

Thanks for the comprehensive reply. I understand better now the bigger =
picture.

I have added a few comments below.=20

> On Jan 18, 2016, at 3:05 AM, Christian Ams=C3=BCss =
 wrote:
>=20
> Hello Michael,
>=20
> it appears that there are three concepts both being called or related =
to
> "streaming" that get mixed up in this thread, I'll try to flesh them =
out
> fist, describing their purpose, status of drafts, and interaction with
> client and server side.
>=20
> A. The draft paragraph about "store or transmit SenML in a stream-like
>  fashion" in the "Multiple Datapoints" section:
>=20
>  This is more about transportation, and implies that there is some =
kind
>  of boundary between elements at which transmission can pause.
>=20
>  Such boundaries are present in all drafts so far.
>=20
>  It appears to me that this would primarily work with HTTP in a =
fashion
>  similar to long polling, which is something both communicating =
parties
>  need to be aware of (all drafts: "MUST specify that they are doing
>  this"), lest they time out the connection.
>=20
Yes, I understand. I=E2=80=99m assuming that any array structure with =
small enough elements
will satisfy this goal. In this case the base needs to be remembered at =
the receiver=20
anyway, so  having base in a separate element makes sense. We are =
receiving data=20
with a state machine which stores each base value as a new state and =
context from=20
which to interpret new data elements.

> B. Buffer-less operation:
>=20
>  For very small applications (eg. using uIP and few kB of RAM), it is
>  desirable to use data formats that never require back-seeking, that
>  limit back-seeks to a fixed length or that can do with a fixed-length
>  buffer to hold information for that. The specification does not need
>  to actively describe those operations, requiring some basic structure
>  is sufficient.
>=20
>  It has been suggested earlier on this list that -01 with an =
additional
>  requirement that "bn" and "bt" to come first in the dictionaries =
would
>  allow this mode of operation too -- truth, but hard to achieve with
>  generic JSON implementations and semantics.
>=20
Limiting the size of each element in the array will limit the =
back-seeking needed
thus the size of the buffer will need to be related to the maximum size =
of an array
element. Having the outermost structure be an array enables that in the =
drafts
post -01.

>  Thus, this goal is only achieved by drafts -02 and later. (This is
>  also what my demo is about, which shows that -03 is particularly
>  suitable).
>=20
>  That this only an issue for the receiving side (the sender is free
>  to choose element sequences as is most practical for it anyway, as
>  long as it follows the specification). Having this negotiable would
>  defeat its purpose: If receivers may rely on it, we can't allow
>  senders to not support it.
>=20
This to me is key. For reliable operation the system designer needs to =
insure=20
about the maximum message sizes and buffers. The limit on the size of =
any=20
array element, base or data, can=E2=80=99t be specified in this RFC, =
right?

> C. Multiple base elements:
>=20
>  The idea to have multiple base elements came up independently of the
>  others, and gives smaller data streams for cases in which different
>  sensors' time series are produced, or when there are larger gaps in a
>  timeline. The proposal worked well with the array-as-root scheme
>  envisioned with exactly 2 elements for B., and was implemented
>  together.
>=20
>  It is present in -03 and -04.
>=20
>  Senders are free not to use it. In my impression, this is easily to
>  implement in receivers. (Even if they desire to directly access
>  in-memory representations of JSON; the key to an entry might then be
>  (list-number, list-position) instead of just list-position).
>=20
I am using a multiple base format in my reference implementation.
Some of my examples are for just one element in the outermost array.
>=20
>> PS Can we succinctly describe the use case for ordered serial
>> processing of senml+json elements being important? =46rom reading the
>> draft, it seems like the important bit is saving the buffer memory =
for
>> large responses.=20
>=20
> The one I'm arguing here is B., the buffer-less operation. The use =
case
> are devices with limited heap memory (say 4k for incoming and outgoing
> packages). I'm using SenML in core-interfaces batches[1] to get and =
set
> device state. When those devices announce supporting batch operation,
> they need to accept SenML PUTs to as many resources as are batched
> together, so far without arbitrary constraints. Due to the proposed
> extensibility of SenML, even if I limited the number of resources in a
> batch, I couldn't predict the maximum size of an incoming update.
>=20
> Now when the update arrives and a SenML that does not satisfy B. comes
> in, all I can do is to store the whole message body and parse it when
> the last block arrived. If the sender updated too many resources or =
used
> too large extensions, I'd need to 4.13-Request-Entity-too-large out.
> Still, until then (particularly until the overflowing package =
arrives),
> memory is clogged with unparsable data.
>=20
My use case is the hypermedia collection in CoRE Interfaces-04, which =
has batch=20
and linked batch (and group). I like the idea of being able to do these =
multi-resource=20
updates in chunked operations on small devices. It seems the array =
format is suitable
for this use case. It does require a state machine at the receiver to =
map all of the elements
to the most recently sent base, but that is the nature of buffer-less =
processing.

>> Is it a bigger deal with CBOR encoding or less important.=20
>=20
> Whether CBOR or JSON is being parsed is almost irrelevant here. The =
only
> difference that comes to my mind is that with CBOR, we might be able =
to
> prescribe a serialization where "bn" and "bt" always precede "e" even =
in
> -01-style, but even that would make it harder to utilize for whomever
> implement this with a native-object-style library.
>=20
>> Is the most important consideration being able to know the base =
values
>> ahead of the data?
>=20
> This is about all information that may be in the dictionary and =
modifies
> how to interpret the elements' data. In core SenML, that information =
is
> the base attributes, and the version -- that is, all the possible root
> variables. (In a scenario .)
>=20
> For extensions, this completely depends on them unless the receiver
> chooses to ignore them anyway. As far as I understand, your link =
format
> extension could add items to a core-interfaces linked batch, and then
> set a value in one go; for that, the extension data would need to
> precede the elements in parsing. Other extensions (say, metadata about
> when to expect changes) may be useful no matter where in the data =
stream
> it appears.
>=20
> [1] =
https://tools.ietf.org/html/draft-ietf-core-interfaces-04#section-6.2 =


The base and elements need to both be known to start the action. There =
is not=20
a requirement  to know the base any time in advance of the elements. =
This is=20
why mapping is OK, it just requires a buffer.
>=20
>> Also, where is -03? there doesn=E2=80=99t seem to be a version -03 =
that you all are talking about on the IETF website:
>> https://tools.ietf.org/html/draft-jennings-core-senml-04 =

>=20
> The data tracker (or rather tools.ietf.org) seems not to take drafts
> submitted on the same day well. You can view it as [2].
>=20
> [2] =
https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/?include_tex=
t=3D1
>=20
> On Sat, Jan 16, 2016 at 07:24:41AM -0800, Michael Koster wrote:
>> The optimizations you recommend require a new string input parser,
>> where I am using the JSON parser that comes with the library. My =
point
>> was that I will need to either make my own string parser for SenML or
>> make a re-parser with the state machine I described in order to use
>> -02 +[...]
>=20
> I don't see yet where the state machine comes in. Surely, much
> state-machingin is going on in the optimized example, but when it =
comes
> to the core difference from -01 to -02, that is, that
>=20
>    {any-key-but-e: any-data, "e": elements-list}
>=20
> becomes
>=20
>    [{any-key-but-e: any-data}, elements-list]
>=20
> , I don't see how this is not changing access from _senml[key] to
> _senml[0][key] or _senml["e"] to _senml[1].
>=20
> (If it's about the C. multiple-base-elements, I'd ask to keep these
> issues separate -- if C. breaks too much, although I like it, we could
> have a -02 with only two elements and still satisfy B., but I don't
> think we need to resort to that.)

The state machine comes in from assuming multiple base format. If there
is exactly one base and zero or more data elements, the array semantics=20=

can be used as you show.

If there is an array of maps, each with base and elements, then it=E2=80=99=
s natural=20
to sequentially process them as separate base items.

If it=E2=80=99s an array with a base map followed by data elements, I =
will probably=20
transform that to a map anyway and coalesce the data elements rather=20
than refer to elements by [0] and [1:] in my higher level code.

senml[=E2=80=9Ce=E2=80=9D] has semantic meaning, but I wrap it an an =
elements class anyway.
I guess I was using the format itself as a data model, thus refer to =
objects as=20
=E2=80=9Csenml=E2=80=9D objects. That is what feels broken by the new =
formats. I should not
tie the data model to the format.

>=20
>> [...] but there is another issue anyway:
>>=20
>> One of the big advantages of using JSON is connecting the embedded
>> world to the web world. To do this in a low-friction way, it=E2=80=99s =
good to
>> be able to use well known tools and patterns.
>=20
> I fully agree that easy use of established web tools is essential =
here:
> but these very threads are where we should come up with mechanisms =
that
> work both with them and constrained devices.
>=20
>=20
> There is one point where I think that state-machining over incoming =
JSON
> objects does make sense, that is when it comes to names -- I like to =
see
> them as URIs (that's consistent with the examples given, but not fully
> required in the drafts), and when the "n" elements are relative URIs,
> they are not useful until joined with the base name. But that is not a
> change introduced in -01, but a preference of mine that is reflected =
in
> the demo to show that relative URIs are not that complicated even for
> embedded systems. (Existing web tools usually have their ways of =
joining
> URIs shipped).
>=20
It is very important to the proper operation of collections and link =
embedding=20
that the base name (uri of the collection) and resource names in the =
collection
(relative references from that base) are consistently and easily handled
(by the tools for the developer).=20

Collection templates need to be reusable, therefore relative references =
to=20
late binding base URIs and hypermedia controls are important.

That is our motivation to use the senml data model in the CoRE =
Interfaces=20
collection models. It also why to me it makes sense to have a format =
where=20
links and items are combined, for hypermedia operation.
>=20
>> Thanks also for looking into my code. I could easily use the -02 or
>> -03 in the senml processing as you show. What is missing still from
>> everything after -01 is the element tag that I am re-using to =
indicate
>> links and forms in the document:
>=20
> I did see that you had extensions in your code, but as Carsten
> suggested, the "l" could stay in the first dictionary alongside the =
"bn"
> and "ver". Maybe the name "base dictionary" is suboptimal here -- the
> dictionary itself is not something that gets somehow prefixed to the
> following entries, it's just the place where the base attributes =
reside
> along with other things, like "ver" and extensions.
>=20
Yes, putting the links in with the base makes perfect sense. this would=20=

allow hypermedia based assembly of the following data elements. The
links would have =E2=80=9Chref=E2=80=9D items that can be used to match =
and select=20
items by name (=E2=80=9Cn=E2=80=9D:) in the data stream.
>=20
> On Sat, Jan 16, 2016 at 09:43:55AM -0800, Michael Koster wrote:
>> It would be useful if the order of top level element types could be =
arbitrary e.g.: [ {},[],[],[],{},[],{},{} ... ]
>=20
> That's something I could well see in a -05. It would also make minimal
> SenML files that don't use any base attributes a little smaller, and
> embedded parsing wouldn't suffer from it AFAICT.
>=20
It would give the system designer more options to optimize the semantics=20=

while keeping the required buffer size small.

> On Sat, Jan 16, 2016 at 10:33:00AM -0800, Michael Koster wrote:
>> PS for correctness my example should look more like this:
>> [=20
>>  {=20
>>    "bn": "/light/brightness",
>>    "l": [ ... ],
>>    "f": [ ...],
>>    "e": [
>>      { "n": "tbr", "v": "44.3", },
>>      { "n": "tt", "v": "1.0", }
>>    ]
>>  }
>> ]
>=20
> Just let's please not allow the "e" element any more. Anything with a
> top-level array is incompatible with older draft users anyway.
>=20
We seem to be in agreement mostly. If it is important to get rid of the =
=E2=80=9Ce=E2=80=9D
tag and it=E2=80=99s remnant from the flattened  in the xml, that =
makes sense.
I am not attached at all to using the =E2=80=9Ce=E2=80=9D tag.

Best regards,

Michael

>=20
> Best regards
> Christian
>=20
> --=20
> Christian Ams=C3=BCss                      | Energy Harvesting =
Solutions GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>                                      | ATU68476614


--Apple-Mail=_21C4F613-C5D6-4029-B236-219FDE45F1B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi Christian,

Thanks for the comprehensive reply. I understand better now =
the bigger picture.

I have added a few comments below. 

On Jan 18, 2016, at 3:05 AM, Christian Ams=C3=BCss <c.amsuess@energyharvesting.at> wrote:

Hello Michael,

it appears that there are three concepts both =
being called or related to
"streaming" that get mixed up =
in this thread, I'll try to flesh them out
fist, =
describing their purpose, status of drafts, and interaction with
client and server side.

A. The =
draft paragraph about "store or transmit SenML in a stream-like
  fashion" in the "Multiple Datapoints" section:

  This is more about transportation, and =
implies that there is some kind
  of boundary between =
elements at which transmission can pause.

 =
 Such boundaries are present in all drafts so far.

  It appears to me that this would primarily work with =
HTTP in a fashion
  similar to long polling, which is =
something both communicating parties
  need to be =
aware of (all drafts: "MUST specify that they are doing
 =
 this"), lest they time out the connection.

Yes, I understand. I=E2=80=99m assuming =
that any array structure with small enough elements
will =
satisfy this goal. In this case the base needs to be remembered at the =
receiver 
anyway, so  having base in a separate =
element makes sense. We are receiving data 
with a state =
machine which stores each base value as a new state and context =
from 
which to interpret new data elements.

B. =
Buffer-less operation:

  For very =
small applications (eg. using uIP and few kB of RAM), it is
=
  desirable to use data formats that never require back-seeking, =
that
  limit back-seeks to a fixed length or that can =
do with a fixed-length
  buffer to hold information =
for that. The specification does not need
  to =
actively describe those operations, requiring some basic structure
  is sufficient.

  It =
has been suggested earlier on this list that -01 with an additional
  requirement that "bn" and "bt" to come first in the =
dictionaries would
  allow this mode of operation too =
-- truth, but hard to achieve with
  generic JSON =
implementations and semantics.

Limiting the size of each element in the =
array will limit the back-seeking needed
thus the size of the =
buffer will need to be related to the maximum size of an =
array
element. Having the outermost structure be an array =
enables that in the drafts
post -01.

 =
 Thus, this goal is only achieved by drafts -02 and later. (This =
is
  also what my demo is about, which shows that -03 =
is particularly
  suitable).

  That this only an issue for the receiving side (the =
sender is free
  to choose element sequences as is =
most practical for it anyway, as
  long as it follows =
the specification). Having this negotiable would
 =
 defeat its purpose: If receivers may rely on it, we can't allow
  senders to not support it.

This to me is key. For reliable operation =
the system designer needs to insure 
about the maximum =
message sizes and buffers. The limit on the size of =
any 
array element, base or data, can=E2=80=99t be =
specified in this RFC, right?

C. Multiple base elements:

 =
 The idea to have multiple base elements came up independently of =
the
  others, and gives smaller data streams for =
cases in which different
  sensors' time series are =
produced, or when there are larger gaps in a
 =
 timeline. The proposal worked well with the array-as-root =
scheme
  envisioned with exactly 2 elements for B., =
and was implemented
  together.

  It is present in -03 and -04.

  Senders are free not to use it. In my impression, this =
is easily to
  implement in receivers. (Even if they =
desire to directly access
  in-memory representations =
of JSON; the key to an entry might then be
 =
 (list-number, list-position) instead of just list-position).

I am using a multiple base =
format in my reference implementation.
Some of my examples are =
for just one element in the outermost array.

PS Can we succinctly describe the use case for =
ordered serial
processing of senml+json elements being =
important? =46rom reading the
draft, it seems like the =
important bit is saving the buffer memory for
large =
responses. 

The one I'm =
arguing here is B., the buffer-less operation. The use case
are devices with limited heap memory (say 4k for incoming and =
outgoing
packages). I'm using SenML in core-interfaces =
batches[1] to get and set
device state. When those devices =
announce supporting batch operation,
they need to accept =
SenML PUTs to as many resources as are batched
together, =
so far without arbitrary constraints. Due to the proposed
extensibility of SenML, even if I limited the number of =
resources in a
batch, I couldn't predict the maximum size =
of an incoming update.

Now when the update =
arrives and a SenML that does not satisfy B. comes
in, all =
I can do is to store the whole message body and parse it when
the last block arrived. If the sender updated too many =
resources or used
too large extensions, I'd need to =
4.13-Request-Entity-too-large out.
Still, until then =
(particularly until the overflowing package arrives),
memory=
 is clogged with unparsable data.

My use case is the hypermedia collection =
in CoRE Interfaces-04, which has batch 
and linked batch =
(and group). I like the idea of being able to do these =
multi-resource 
updates in chunked operations on small =
devices. It seems the array format is suitable
for this use =
case. It does require a state machine at the receiver to map all of the =
elements
to the most recently sent base, but that is the =
nature of buffer-less processing.

Is it a bigger deal with CBOR encoding or less important. 

Whether CBOR or JSON is being =
parsed is almost irrelevant here. The only
difference that =
comes to my mind is that with CBOR, we might be able to
prescribe a serialization where "bn" and "bt" always precede =
"e" even in
-01-style, but even that would make it harder =
to utilize for whomever
implement this with a =
native-object-style library.

Is the most important consideration being able =
to know the base values
ahead of the data?

This is about all information =
that may be in the dictionary and modifies
how to =
interpret the elements' data. In core SenML, that information is
the base attributes, and the version -- that is, all the =
possible root
variables. (In a scenario .)
For extensions, this completely depends on them unless the =
receiver
chooses to ignore them anyway. As far as I =
understand, your link format
extension could add items to =
a core-interfaces linked batch, and then
set a value in =
one go; for that, the extension data would need to
precede =
the elements in parsing. Other extensions (say, metadata about
when to expect changes) may be useful no matter where in the =
data stream
it appears.

[1] =
https://tools.ietf.org/html/draft-ietf-core-interfaces-04#secti=
on-6.2

The base and =
elements need to both be known to start the action. There is =
not 
a requirement  to know the base any time in =
advance of the elements. This is 
why mapping is OK, it =
just requires a buffer.

Also, where is -03? there doesn=E2=80=99t seem to be a =
version -03 that you all are talking about on the IETF website:
https://tools.ietf.org/html/draft-jennings-core-senml-04 =
<https://tools.ietf.org/html/draft-jennings-core-senml-04>=
;

The data tracker (or rather =
tools.ietf.org) seems =
not to take drafts
submitted on the same day well. You can =
view it as [2].

[2] https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/?=
include_text=3D1

On Sat, Jan 16, 2016 =
at 07:24:41AM -0800, Michael Koster wrote:
The optimizations you recommend require a new =
string input parser,
where I am using the JSON parser that =
comes with the library. My point
was that I will need to =
either make my own string parser for SenML or
make a =
re-parser with the state machine I described in order to use
-02 +[...]

I don't =
see yet where the state machine comes in. Surely, much
state-machingin is going on in the optimized example, but =
when it comes
to the core difference from -01 to -02, that =
is, that

    {any-key-but-e: =
any-data, "e": elements-list}

becomes

    [{any-key-but-e: any-data}, =
elements-list]

, I don't see how this is =
not changing access from _senml[key] to
_senml[0][key] or =
_senml["e"] to _senml[1].

(If it's about =
the C. multiple-base-elements, I'd ask to keep these
issues =
separate -- if C. breaks too much, although I like it, we could
have a -02 with only two elements and still satisfy B., but I =
don't
think we need to resort to that.)

The state machine comes in =
from assuming multiple base format. If there
is exactly one =
base and zero or more data elements, the array =
semantics 
can be used as you show.

If there is an array of maps, each with base and =
elements, then it=E2=80=99s natural 
to sequentially =
process them as separate base items.

If it=E2=80=99s an array with a base map followed =
by data elements, I will probably 
transform that to a =
map anyway and coalesce the data elements rather 
than =
refer to elements by [0] and [1:] in my higher level code.

senml[=E2=80=9Ce=E2=80=9D] has semantic meaning, =
but I wrap it an an elements class anyway.
I guess I was using =
the format itself as a data model, thus refer to objects =
as 
=E2=80=9Csenml=E2=80=9D objects. That is what feels =
broken by the new formats. I should not
tie the data model to =
the format.


[...] but there is another issue anyway:

One of the big advantages of using JSON is connecting the =
embedded
world to the web world. To do this in a =
low-friction way, it=E2=80=99s good to
be able to use well =
known tools and patterns.

I =
fully agree that easy use of established web tools is essential here:
but these very threads are where we should come up with =
mechanisms that
work both with them and constrained =
devices.


There is one point =
where I think that state-machining over incoming JSON
objects does make sense, that is when it comes to names -- I =
like to see
them as URIs (that's consistent with the =
examples given, but not fully
required in the drafts), and =
when the "n" elements are relative URIs,
they are not =
useful until joined with the base name. But that is not a
change introduced in -01, but a preference of mine that is =
reflected in
the demo to show that relative URIs are not =
that complicated even for
embedded systems. (Existing web =
tools usually have their ways of joining
URIs shipped).

It is very important to the =
proper operation of collections and link embedding 
that =
the base name (uri of the collection) and resource names in the =
collection
(relative references from that base) are =
consistently and easily handled
(by the tools for the =
developer). 

Collection =
templates need to be reusable, therefore relative references =
to 
late binding base URIs and hypermedia controls are =
important.

That is our motivation to =
use the senml data model in the CoRE =
Interfaces 
collection models. It also why to me it makes =
sense to have a format where 
links and items are =
combined, for hypermedia operation.

Thanks also for looking into my code. I could easily use the =
-02 or
-03 in the senml processing as you show. What is =
missing still from
everything after -01 is the element tag =
that I am re-using to indicate
links and forms in the =
document:

I did see that you =
had extensions in your code, but as Carsten
suggested, the =
"l" could stay in the first dictionary alongside the "bn"
and "ver". Maybe the name "base dictionary" is suboptimal =
here -- the
dictionary itself is not something that gets =
somehow prefixed to the
following entries, it's just the =
place where the base attributes reside
along with other =
things, like "ver" and extensions.

Yes, putting the links in with the base =
makes perfect sense. this would 
allow hypermedia based =
assembly of the following data elements. The
links would have =
=E2=80=9Chref=E2=80=9D items that can be used to match and =
select 
items by name (=E2=80=9Cn=E2=80=9D:) in the data =
stream.
On Sat, Jan 16, 2016 at 09:43:55AM -0800, Michael Koster =
wrote:
It would be =
useful if the order of top level element types could be arbitrary e.g.: =
[ {},[],[],[],{},[],{},{} ... ]

That's something I could well see in a -05. It would also =
make minimal
SenML files that don't use any base =
attributes a little smaller, and
embedded parsing wouldn't =
suffer from it AFAICT.

It =
would give the system designer more options to optimize the =
semantics 
while keeping the required buffer size =
small.

On Sat, Jan 16, 2016 at 10:33:00AM -0800, =
Michael Koster wrote:
PS for correctness my example should look more like this:
[ 
  { 
 =
   "bn": "/light/brightness",
 =
   "l": [ ... ],
    "f": [ =
...],
    "e": [
 =
     { "n": "tbr", "v": "44.3", },
=
      { "n": "tt", "v": "1.0", }
 =
   ]
  }
]

Just let's please not allow the =
"e" element any more. Anything with a
top-level array is =
incompatible with older draft users anyway.

We seem to be in agreement mostly. If =
it is important to get rid of the =E2=80=9Ce=E2=80=9D
tag and =
it=E2=80=99s remnant from the flattened <e/> in the xml, that =
makes sense.
I am not attached at all to using the =E2=80=9Ce=E2=
=80=9D tag.

Best =
regards,

Michael


Best regards
Christian

-- 
Christian Ams=C3=BCss =
            &n=
bsp;        | Energy Harvesting =
Solutions GmbH
founder, system architect =
            | =
headquarter:
mailto:c.amsuess@energyharvesting.at  | =
Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =
            &n=
bsp;  | http://www.energyharvesting.at/
 =
            &n=
bsp;           &nbs=
p;            =
| ATU68476614

=

--Apple-Mail=_21C4F613-C5D6-4029-B236-219FDE45F1B6--


From nobody Mon Jan 18 08:23:09 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97151B3959 for ; Mon, 18 Jan 2016 08:23:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 CKqLbwS8MGSf for ; Mon, 18 Jan 2016 08:23:03 -0800 (PST)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 994DB1B3958 for ; Mon, 18 Jan 2016 08:23:03 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id q63so164715476pfb.1 for ; Mon, 18 Jan 2016 08:23:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LnBM+Nvn+iqlbL2hae5mH++YikPP/gmsIIpLzvz3UH0=; b=wLlTDo9ptRjAlvxnB6VOerMt6AIHdJacIByFYVxwx0M7Cd6Zn7grIEed5bmJpiS1gv xNgQseVGBFSGFbVrwSFGOcNncj4X4meI+sIACOJeGO3tUyCWW+KvhkiIIXkFKgxtdldg uo3ErEQPhzB22Wg08IxVhnqBhNUXnQf9j7EJ0eWeR6EWKDRMBfBpWi910oMh76KJkzvD +fuI+wTmyVqVgsJmPTV6yXmaJr12DGoGrkGx/JxpoKlaq/dFFijBLDj3Z0kSBrL2b4Pk ZgjYgEIavkMivLBtlmsY7Xq2V/XLLSK+RckXAuj7tjTDnpEM0FPKIDPhGwpnxyLlLk7j H8ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LnBM+Nvn+iqlbL2hae5mH++YikPP/gmsIIpLzvz3UH0=; b=ToDSqTA8mGsrexSRhQRFStWLHrObFLQK5lznEcugIMSHwY9xfQafMT3JsSu4YZx7J7 j0mLydvJK2DTzQ+CqD8VN31AX2HobLtylTEVdYpkgR66TRoTR873BSmF7ccjt013xM6t zNzIKsKcakMZbolcVcvNEQDNmZV/nIzzUeED4H+9p3SQoqfcyIBXkaaTGz3dkVz3iTWY nKQHuw5Ug026hc1+EG1SOB9RVB+LCS7SpDqvYedcSjXsUMD/Tz4INMCYDZztYBiR5b8N BhwNnofvlPjDZ/BZXIhGlTzas5v3XV37pyvElS18DR7WUr0kEjKajA59qEVSxgWScese A+PQ==
X-Gm-Message-State: AG10YOSRg51ezud+WpnTqZhG6HxF2woNe5bmu0ztrrAznYJ4qR4ccODHKJJhuyqYVB1eiw==
X-Received: by 10.98.10.73 with SMTP id s70mr31769470pfi.85.1453134183067; Mon, 18 Jan 2016 08:23:03 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id xv2sm35230902pab.10.2016.01.18.08.23.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 08:23:01 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_73275927-8DB7-4B60-9388-2C8F439BD747"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <20160118110500.GA7789@hephaistos.amsuess.com>
Date: Mon, 18 Jan 2016 08:23:00 -0800
Message-Id: <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 16:23:08 -0000

--Apple-Mail=_73275927-8DB7-4B60-9388-2C8F439BD747
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Some more thoughts on data model.

It turns out to be more than just convenient that the senml =
representation=20
itself is an explicit mapping of a data model.

the =E2=80=9Ce=E2=80=9D tag is more than just a semantic glitch in =
converting XML to JSON.=20
To preserve the semantics of the data model, the data items as a set are=20=

related to the base at the same scope level in the model. The XML form
is =E2=80=9Cflattened=E2=80=9D and JSON is not.=20

I used this to extend the data model by adding a links class at the same=20=

scope level as base name and items.

This is how the collection with links and items can be expressed in both
machine and human comprehensible form as a model:

{
"bn":"/3300/1/",
=E2=80=9Ci":[
{"n":"5700","v":"31.3"},
{"n":"5602","v":"37.1"},
{"n":"5601","v":"18.3"},
{"n":"5605"},
{"n":"5603","v":"0"},
{"n":"5604","v":"100"},
{"n":"5750","sv":"Inboard Bearing"}
],
"l":[
{"href":"","rel":"self","rt":"temperature","u":"C"},
{"href":"5700","rt":"currentValue","u":"C"},
{"href":"5602","rt":"maxValue","u":"C"},
{"href":"5601","rt":"minValue","u":"C"},
{"href":"5605","rt":"resetMaxMin"},
{"href":"5603","rt":"minScale","u":"C"},
{"href":"5604","rt":"maxScale","u":"C"},
{"href":"5750","rt":"appType"}
]
}

Base name, links, and items all are easily mapped to property names
using a simple JSON-LD context and can be understood and modeled=20
by higher level tools as-is. Removing the =E2=80=9Ci=E2=80=9D or =E2=80=9C=
l=E2=80=9D tags gives the modeling=20
tool nothing to use to identify property instances (like base name, =
links,=20
and items). This is extensible by adding new property  classes (element=20=

tags).

It is very useful to have the representation match the model so closely.
I think there will be future generalizations of this pattern that =
don=E2=80=99t need
such explicit representation formats, but for now I find it more than =
just
convenient.

If the representation wasn=E2=80=99t structured in this way, I would =
need to=20
create an internal representation that is, in order to make use of
the model tools that I=E2=80=99m already using. Doing this would IMO not
be good for the human understanding, which is important in the
phase here where people are learning.

Maybe there is a way to preserve the model semantics in the=20
representation and at the same time support efficient sequential=20
processing of elements.

Best regards,

Michael


> On Jan 18, 2016, at 3:05 AM, Christian Ams=C3=BCss =
 wrote:
>=20
> Hello Michael,
>=20
> it appears that there are three concepts both being called or related =
to
> "streaming" that get mixed up in this thread, I'll try to flesh them =
out
> fist, describing their purpose, status of drafts, and interaction with
> client and server side.
>=20
> A. The draft paragraph about "store or transmit SenML in a stream-like
>  fashion" in the "Multiple Datapoints" section:
>=20
>  This is more about transportation, and implies that there is some =
kind
>  of boundary between elements at which transmission can pause.
>=20
>  Such boundaries are present in all drafts so far.
>=20
>  It appears to me that this would primarily work with HTTP in a =
fashion
>  similar to long polling, which is something both communicating =
parties
>  need to be aware of (all drafts: "MUST specify that they are doing
>  this"), lest they time out the connection.
>=20
> B. Buffer-less operation:
>=20
>  For very small applications (eg. using uIP and few kB of RAM), it is
>  desirable to use data formats that never require back-seeking, that
>  limit back-seeks to a fixed length or that can do with a fixed-length
>  buffer to hold information for that. The specification does not need
>  to actively describe those operations, requiring some basic structure
>  is sufficient.
>=20
>  It has been suggested earlier on this list that -01 with an =
additional
>  requirement that "bn" and "bt" to come first in the dictionaries =
would
>  allow this mode of operation too -- truth, but hard to achieve with
>  generic JSON implementations and semantics.
>=20
>  Thus, this goal is only achieved by drafts -02 and later. (This is
>  also what my demo is about, which shows that -03 is particularly
>  suitable).
>=20
>  That this only an issue for the receiving side (the sender is free
>  to choose element sequences as is most practical for it anyway, as
>  long as it follows the specification). Having this negotiable would
>  defeat its purpose: If receivers may rely on it, we can't allow
>  senders to not support it.
>=20
> C. Multiple base elements:
>=20
>  The idea to have multiple base elements came up independently of the
>  others, and gives smaller data streams for cases in which different
>  sensors' time series are produced, or when there are larger gaps in a
>  timeline. The proposal worked well with the array-as-root scheme
>  envisioned with exactly 2 elements for B., and was implemented
>  together.
>=20
>  It is present in -03 and -04.
>=20
>  Senders are free not to use it. In my impression, this is easily to
>  implement in receivers. (Even if they desire to directly access
>  in-memory representations of JSON; the key to an entry might then be
>  (list-number, list-position) instead of just list-position).
>=20
>=20
>> PS Can we succinctly describe the use case for ordered serial
>> processing of senml+json elements being important? =46rom reading the
>> draft, it seems like the important bit is saving the buffer memory =
for
>> large responses.=20
>=20
> The one I'm arguing here is B., the buffer-less operation. The use =
case
> are devices with limited heap memory (say 4k for incoming and outgoing
> packages). I'm using SenML in core-interfaces batches[1] to get and =
set
> device state. When those devices announce supporting batch operation,
> they need to accept SenML PUTs to as many resources as are batched
> together, so far without arbitrary constraints. Due to the proposed
> extensibility of SenML, even if I limited the number of resources in a
> batch, I couldn't predict the maximum size of an incoming update.
>=20
> Now when the update arrives and a SenML that does not satisfy B. comes
> in, all I can do is to store the whole message body and parse it when
> the last block arrived. If the sender updated too many resources or =
used
> too large extensions, I'd need to 4.13-Request-Entity-too-large out.
> Still, until then (particularly until the overflowing package =
arrives),
> memory is clogged with unparsable data.
>=20
>> Is it a bigger deal with CBOR encoding or less important.=20
>=20
> Whether CBOR or JSON is being parsed is almost irrelevant here. The =
only
> difference that comes to my mind is that with CBOR, we might be able =
to
> prescribe a serialization where "bn" and "bt" always precede "e" even =
in
> -01-style, but even that would make it harder to utilize for whomever
> implement this with a native-object-style library.
>=20
>> Is the most important consideration being able to know the base =
values
>> ahead of the data?
>=20
> This is about all information that may be in the dictionary and =
modifies
> how to interpret the elements' data. In core SenML, that information =
is
> the base attributes, and the version -- that is, all the possible root
> variables. (In a scenario .)
>=20
> For extensions, this completely depends on them unless the receiver
> chooses to ignore them anyway. As far as I understand, your link =
format
> extension could add items to a core-interfaces linked batch, and then
> set a value in one go; for that, the extension data would need to
> precede the elements in parsing. Other extensions (say, metadata about
> when to expect changes) may be useful no matter where in the data =
stream
> it appears.
>=20
> [1] =
https://tools.ietf.org/html/draft-ietf-core-interfaces-04#section-6.2
>=20
>> Also, where is -03? there doesn=E2=80=99t seem to be a version -03 =
that you all are talking about on the IETF website:
>> https://tools.ietf.org/html/draft-jennings-core-senml-04 =

>=20
> The data tracker (or rather tools.ietf.org) seems not to take drafts
> submitted on the same day well. You can view it as [2].
>=20
> [2] =
https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/?include_tex=
t=3D1
>=20
> On Sat, Jan 16, 2016 at 07:24:41AM -0800, Michael Koster wrote:
>> The optimizations you recommend require a new string input parser,
>> where I am using the JSON parser that comes with the library. My =
point
>> was that I will need to either make my own string parser for SenML or
>> make a re-parser with the state machine I described in order to use
>> -02 +[...]
>=20
> I don't see yet where the state machine comes in. Surely, much
> state-machingin is going on in the optimized example, but when it =
comes
> to the core difference from -01 to -02, that is, that
>=20
>    {any-key-but-e: any-data, "e": elements-list}
>=20
> becomes
>=20
>    [{any-key-but-e: any-data}, elements-list]
>=20
> , I don't see how this is not changing access from _senml[key] to
> _senml[0][key] or _senml["e"] to _senml[1].
>=20
> (If it's about the C. multiple-base-elements, I'd ask to keep these
> issues separate -- if C. breaks too much, although I like it, we could
> have a -02 with only two elements and still satisfy B., but I don't
> think we need to resort to that.)
>=20
>> [...] but there is another issue anyway:
>>=20
>> One of the big advantages of using JSON is connecting the embedded
>> world to the web world. To do this in a low-friction way, it=E2=80=99s =
good to
>> be able to use well known tools and patterns.
>=20
> I fully agree that easy use of established web tools is essential =
here:
> but these very threads are where we should come up with mechanisms =
that
> work both with them and constrained devices.
>=20
>=20
> There is one point where I think that state-machining over incoming =
JSON
> objects does make sense, that is when it comes to names -- I like to =
see
> them as URIs (that's consistent with the examples given, but not fully
> required in the drafts), and when the "n" elements are relative URIs,
> they are not useful until joined with the base name. But that is not a
> change introduced in -01, but a preference of mine that is reflected =
in
> the demo to show that relative URIs are not that complicated even for
> embedded systems. (Existing web tools usually have their ways of =
joining
> URIs shipped).
>=20
>=20
>> Thanks also for looking into my code. I could easily use the -02 or
>> -03 in the senml processing as you show. What is missing still from
>> everything after -01 is the element tag that I am re-using to =
indicate
>> links and forms in the document:
>=20
> I did see that you had extensions in your code, but as Carsten
> suggested, the "l" could stay in the first dictionary alongside the =
"bn"
> and "ver". Maybe the name "base dictionary" is suboptimal here -- the
> dictionary itself is not something that gets somehow prefixed to the
> following entries, it's just the place where the base attributes =
reside
> along with other things, like "ver" and extensions.
>=20
>=20
> On Sat, Jan 16, 2016 at 09:43:55AM -0800, Michael Koster wrote:
>> It would be useful if the order of top level element types could be =
arbitrary e.g.: [ {},[],[],[],{},[],{},{} ... ]
>=20
> That's something I could well see in a -05. It would also make minimal
> SenML files that don't use any base attributes a little smaller, and
> embedded parsing wouldn't suffer from it AFAICT.
>=20
> On Sat, Jan 16, 2016 at 10:33:00AM -0800, Michael Koster wrote:
>> PS for correctness my example should look more like this:
>> [=20
>>  {=20
>>    "bn": "/light/brightness",
>>    "l": [ ... ],
>>    "f": [ ...],
>>    "e": [
>>      { "n": "tbr", "v": "44.3", },
>>      { "n": "tt", "v": "1.0", }
>>    ]
>>  }
>> ]
>=20
> Just let's please not allow the "e" element any more. Anything with a
> top-level array is incompatible with older draft users anyway.
>=20
>=20
> Best regards
> Christian
>=20
> --=20
> Christian Ams=C3=BCss                      | Energy Harvesting =
Solutions GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>                                      | ATU68476614


--Apple-Mail=_73275927-8DB7-4B60-9388-2C8F439BD747
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Some more thoughts on data model.

It turns out to be more than just =
convenient that the senml representation 
itself=
 is an explicit mapping of a data model.

the =E2=80=9Ce=E2=80=9D tag is more =
than just a semantic glitch in converting XML to JSON. 
To preserve the semantics of the data model, the data items =
as a set are 
related to the base at the same =
scope level in the model. The XML form
is =
=E2=80=9Cflattened=E2=80=9D and JSON is not. 

I used this to extend =
the data model by adding a links class at the same 
scope level as base name and items.

This is how the collection with links =
and items can be expressed in both
machine and =
human comprehensible form as a model:

{
"bn":"/3300/1/",
=E2=80=9Ci":[
{"n":"5700","v":"31.3"},
{"n":"5602","v":"37.1"},
{"n":"5601","v":"18.3"},
{"n":"5605"},
{"n":"5603","v":"0"},
{"n":"5604","v":"100"},
{"n":"5750","sv":"Inboard =
Bearing"}
],
"l":[
{"href":"","rel":"self","rt":"temperature","u":"C"},
{"href":"5700","rt":"currentValue","u":"C"},
{"href":"5602","rt":"maxValue","u":"C"},
{"href":"5601","rt":"minValue","u":"C"},
{"href":"5605","rt":"resetMaxMin"},
{"href":"5603","rt":"minScale","u":"C"},
{"href":"5604","rt":"maxScale","u":"C"},{"href":"5750","rt":"appType"}
]
}

Base name, links, and items all are easily mapped to property =
names
using a simple JSON-LD context and can be =
understood and modeled 
by higher level =
tools as-is. Removing the =E2=80=9Ci=E2=80=9D or =E2=80=9Cl=E2=80=9D =
tags gives the modeling 
tool nothing to use =
to identify property instances (like base name, links, 
and items). This is extensible by adding new property =
 classes (element 
tags).

It is very useful to =
have the representation match the model so closely.
I think there will be future generalizations =
of this pattern that don=E2=80=99t need
such explicit representation formats, but for now I find it =
more than just
convenient.

If the representation =
wasn=E2=80=99t structured in this way, I would need =
to 
create an internal =
representation that is, in order to make use of
the model tools that I=E2=80=99m already =
using. Doing this would IMO not
be good for the human understanding, which =
is important in the
phase =
here where people are learning.

Maybe there is a =
way to preserve the model semantics in the 
representation and at the same time support efficient =
sequential 
processing of elements.

Best regards,

Michael


On =
Jan 18, 2016, at 3:05 AM, Christian Ams=C3=BCss <c.amsuess@energyharvesting.at> wrote:

Hello Michael,

it appears that there are three concepts both =
being called or related to
"streaming" that get mixed up =
in this thread, I'll try to flesh them out
fist, =
describing their purpose, status of drafts, and interaction with
client and server side.

A. The =
draft paragraph about "store or transmit SenML in a stream-like
  fashion" in the "Multiple Datapoints" section:

  This is more about transportation, and =
implies that there is some kind
  of boundary between =
elements at which transmission can pause.

 =
 Such boundaries are present in all drafts so far.

  It appears to me that this would primarily work with =
HTTP in a fashion
  similar to long polling, which is =
something both communicating parties
  need to be =
aware of (all drafts: "MUST specify that they are doing
 =
 this"), lest they time out the connection.

B. Buffer-less operation:

 =
 For very small applications (eg. using uIP and few kB of RAM), it =
is
  desirable to use data formats that never require =
back-seeking, that
  limit back-seeks to a fixed =
length or that can do with a fixed-length
  buffer to =
hold information for that. The specification does not need
 =
 to actively describe those operations, requiring some basic =
structure
  is sufficient.

  It has been suggested earlier on this list that -01 =
with an additional
  requirement that "bn" and "bt" =
to come first in the dictionaries would
  allow this =
mode of operation too -- truth, but hard to achieve with
 =
 generic JSON implementations and semantics.

  Thus, this goal is only achieved by drafts -02 and =
later. (This is
  also what my demo is about, which =
shows that -03 is particularly
  suitable).

  That this only an issue for the =
receiving side (the sender is free
  to choose =
element sequences as is most practical for it anyway, as
 =
 long as it follows the specification). Having this negotiable =
would
  defeat its purpose: If receivers may rely on =
it, we can't allow
  senders to not support it.

C. Multiple base elements:

  The idea to have multiple base elements came up =
independently of the
  others, and gives smaller data =
streams for cases in which different
  sensors' time =
series are produced, or when there are larger gaps in a
 =
 timeline. The proposal worked well with the array-as-root =
scheme
  envisioned with exactly 2 elements for B., =
and was implemented
  together.

  It is present in -03 and -04.

  Senders are free not to use it. In my impression, this =
is easily to
  implement in receivers. (Even if they =
desire to directly access
  in-memory representations =
of JSON; the key to an entry might then be
 =
 (list-number, list-position) instead of just list-position).


PS Can we succinctly describe the use case for ordered =
serial
processing of senml+json elements being important? =
=46rom reading the
draft, it seems like the important bit =
is saving the buffer memory for
large responses. 

The one I'm arguing here is B., =
the buffer-less operation. The use case
are devices with =
limited heap memory (say 4k for incoming and outgoing
packages). I'm using SenML in core-interfaces batches[1] to =
get and set
device state. When those devices announce =
supporting batch operation,
they need to accept SenML PUTs =
to as many resources as are batched
together, so far =
without arbitrary constraints. Due to the proposed
extensibility of SenML, even if I limited the number of =
resources in a
batch, I couldn't predict the maximum size =
of an incoming update.

Now when the update =
arrives and a SenML that does not satisfy B. comes
in, all =
I can do is to store the whole message body and parse it when
the last block arrived. If the sender updated too many =
resources or used
too large extensions, I'd need to =
4.13-Request-Entity-too-large out.
Still, until then =
(particularly until the overflowing package arrives),
memory=
 is clogged with unparsable data.

Is it a bigger deal with CBOR encoding or less =
important. 

Whether CBOR or =
JSON is being parsed is almost irrelevant here. The only
difference that comes to my mind is that with CBOR, we might =
be able to
prescribe a serialization where "bn" and "bt" =
always precede "e" even in
-01-style, but even that would =
make it harder to utilize for whomever
implement this with =
a native-object-style library.

Is the most important consideration being able =
to know the base values
ahead of the data?

This is about all information =
that may be in the dictionary and modifies
how to =
interpret the elements' data. In core SenML, that information is
the base attributes, and the version -- that is, all the =
possible root
variables. (In a scenario .)
For extensions, this completely depends on them unless the =
receiver
chooses to ignore them anyway. As far as I =
understand, your link format
extension could add items to =
a core-interfaces linked batch, and then
set a value in =
one go; for that, the extension data would need to
precede =
the elements in parsing. Other extensions (say, metadata about
when to expect changes) may be useful no matter where in the =
data stream
it appears.

[1] =
https://tools.ietf.org/html/draft-ietf-core-interfaces-04#secti=
on-6.2

Also, where is -03? there doesn=E2=80=99t seem to be a =
version -03 that you all are talking about on the IETF website:
https://tools.ietf.org/html/draft-jennings-core-senml-04 =
<https://tools.ietf.org/html/draft-jennings-core-senml-04>=
;

The data tracker (or rather =
tools.ietf.org) seems =
not to take drafts
submitted on the same day well. You can =
view it as [2].

[2] https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/?=
include_text=3D1

On Sat, Jan 16, 2016 =
at 07:24:41AM -0800, Michael Koster wrote:
The optimizations you recommend require a new =
string input parser,
where I am using the JSON parser that =
comes with the library. My point
was that I will need to =
either make my own string parser for SenML or
make a =
re-parser with the state machine I described in order to use
-02 +[...]

I don't =
see yet where the state machine comes in. Surely, much
state-machingin is going on in the optimized example, but =
when it comes
to the core difference from -01 to -02, that =
is, that

    {any-key-but-e: =
any-data, "e": elements-list}

becomes

    [{any-key-but-e: any-data}, =
elements-list]

, I don't see how this is =
not changing access from _senml[key] to
_senml[0][key] or =
_senml["e"] to _senml[1].

(If it's about =
the C. multiple-base-elements, I'd ask to keep these
issues =
separate -- if C. breaks too much, although I like it, we could
have a -02 with only two elements and still satisfy B., but I =
don't
think we need to resort to that.)

[...] but there is =
another issue anyway:

One of the big =
advantages of using JSON is connecting the embedded
world =
to the web world. To do this in a low-friction way, it=E2=80=99s good =
to
be able to use well known tools and patterns.

I fully agree that easy use of =
established web tools is essential here:
but these very =
threads are where we should come up with mechanisms that
work both with them and constrained devices.


There is one point where I think that =
state-machining over incoming JSON
objects does make =
sense, that is when it comes to names -- I like to see
them =
as URIs (that's consistent with the examples given, but not fully
required in the drafts), and when the "n" elements are =
relative URIs,
they are not useful until joined with the =
base name. But that is not a
change introduced in -01, but =
a preference of mine that is reflected in
the demo to show =
that relative URIs are not that complicated even for
embedded systems. (Existing web tools usually have their ways =
of joining
URIs shipped).


Thanks also for looking =
into my code. I could easily use the -02 or
-03 in the =
senml processing as you show. What is missing still from
everything after -01 is the element tag that I am re-using to =
indicate
links and forms in the document:

I did see that you had extensions =
in your code, but as Carsten
suggested, the "l" could stay =
in the first dictionary alongside the "bn"
and "ver". =
Maybe the name "base dictionary" is suboptimal here -- the
dictionary itself is not something that gets somehow prefixed =
to the
following entries, it's just the place where the =
base attributes reside
along with other things, like "ver" =
and extensions.


On Sat, Jan =
16, 2016 at 09:43:55AM -0800, Michael Koster wrote:
It would be useful if =
the order of top level element types could be arbitrary e.g.: [ =
{},[],[],[],{},[],{},{} ... ]

That's something I could well see in a -05. It would also =
make minimal
SenML files that don't use any base =
attributes a little smaller, and
embedded parsing wouldn't =
suffer from it AFAICT.

On Sat, Jan 16, 2016 =
at 10:33:00AM -0800, Michael Koster wrote:
PS for correctness my example should look more =
like this:
[ 
  { 
 =
   "bn": "/light/brightness",
 =
   "l": [ ... ],
    "f": [ =
...],
    "e": [
 =
     { "n": "tbr", "v": "44.3", },
=
      { "n": "tt", "v": "1.0", }
 =
   ]
  }
]

Just let's please not allow the =
"e" element any more. Anything with a
top-level array is =
incompatible with older draft users anyway.


Best regards
Christian

-- 
Christian Ams=C3=BCss =
            &n=
bsp;        | Energy Harvesting =
Solutions GmbH
founder, system architect =
            | =
headquarter:
mailto:c.amsuess@energyharvesting.at  | =
Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =
            &n=
bsp;  | http://www.energyharvesting.at/
 =
            &n=
bsp;           &nbs=
p;            =
| ATU68476614

=

--Apple-Mail=_73275927-8DB7-4B60-9388-2C8F439BD747--


From nobody Mon Jan 18 08:26:28 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF301B3966 for ; Mon, 18 Jan 2016 08:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.299
X-Spam-Level: 
X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3] autolearn=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 j5D-XBUVYJiH for ; Mon, 18 Jan 2016 08:26:25 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1151B3960 for ; Mon, 18 Jan 2016 08:26:25 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1C6BB418AB; Mon, 18 Jan 2016 17:26:23 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4A1841D0; Mon, 18 Jan 2016 17:26:22 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CC6832E; Mon, 18 Jan 2016 17:26:21 +0100 (CET)
Received: (nullmailer pid 15462 invoked by uid 1000); Mon, 18 Jan 2016 16:26:21 -0000
Date: Mon, 18 Jan 2016 17:26:21 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Michael Koster 
Message-ID: <20160118162621.GB7789@hephaistos.amsuess.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <7BEAC3D7-C2B8-42A2-9496-DDED5837ACF2@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf"
Content-Disposition: inline
In-Reply-To: <7BEAC3D7-C2B8-42A2-9496-DDED5837ACF2@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 16:26:27 -0000

--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Just a quick reply before going through the whole mail:

On Mon, Jan 18, 2016 at 07:42:10AM -0800, Michael Koster wrote:
> >  For very small applications (eg. using uIP and few kB of RAM), it is
> >  desirable to use data formats that never require back-seeking, that
> >  limit back-seeks to a fixed length or that can do with a fixed-length
> >  buffer to hold information for that. The specification does not need
> >  to actively describe those operations, requiring some basic structure
> >  is sufficient.
>
> Limiting the size of each element in the array will limit the back-seekin=
g needed
> thus the size of the buffer will need to be related to the maximum size o=
f an array
> element. Having the outermost structure be an array enables that in the d=
rafts
> post -01.

With all the "e"-less proposals, for the applications I'm describing, no
element size limits (neither in serialized bytes length nor in elements)
are required at all as there is no back-seeking.

Best regards
Christian

--=20
Christian Ams=FCss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--wq9mPyueHGvFACwf
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWnRInAAoJEDmNERLTpL3h2+QP/j+T3pArhOo41SEFssqIptDN
XaNuc6jp8W4srgAghbSGo8Xn1QBIcHnuSeQrAUvZGXn1cuaShk2uTfIMcWAxSUjR
8gVc/363kfHDbi4eU4FArS05mUmEhsO/MipQ5rTQsfwnT0YssXcfGvKKIqxKlwo6
+ztyimZHV/J3KI70w4ryVf3iw3M14emOQ2ZQK6IFoGXxxuzVtGpVW8tWdaYg5kjc
WFd2P7k0WaGKZAZ4CC34KmtCzV3uyKhIpBWuwFEv1IY+CMDLeG2q5eT6Qrf9GB8f
6SKZcZE80tTSeXcIM/H+07R/lbWVBAAUXwhf+kIpI/+pQ1/TUDSOyov205ViYhol
oZjzC1J7ME6hfUBKJdCCQ4DAwezijtvsW562IJ64z3Y8DtZvHB7PDyHykBHiCBTK
N7NhIirYXkfvo6/xSHONbCdOZXJLLmhvTvJUlok4oM/B6Agu0spf1EUxt6wE88sH
mRFaiOGdKmDC6d0HsepLwOB9LLJFX8phtNLJqqhsXsgCY+gEfO6nNfvKoBvTR/Z0
ZyLEe5iWNlTK7mLL6h0ystHSrKUvWYRDVfwxJQZtWzSWUwZn9Qf4v/umVuEvekSh
r5xW4NaFf99AbbCsSqpMMIge6BCgToRbLl8o5mNGvuvVNXCybyJ9kIaCQpp2cSZ9
H5A2bZMPvs+Cw7p8B5gj
=jc5K
-----END PGP SIGNATURE-----

--wq9mPyueHGvFACwf--


From nobody Mon Jan 18 08:58:21 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2091B3A14 for ; Mon, 18 Jan 2016 08:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.9
X-Spam-Level: **
X-Spam-Status: No, score=2.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  J_CHICKENPOX_41=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6,  MIME_8BIT_HEADER=0.3] autolearn=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 05_tx5CNLEVX for ; Mon, 18 Jan 2016 08:58:18 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2FC1B3A13 for ; Mon, 18 Jan 2016 08:58:17 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 68856418AB; Mon, 18 Jan 2016 17:58:15 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4B1CE2D; Mon, 18 Jan 2016 17:58:13 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C02C92E; Mon, 18 Jan 2016 17:58:12 +0100 (CET)
Received: (nullmailer pid 16859 invoked by uid 1000); Mon, 18 Jan 2016 16:58:12 -0000
Date: Mon, 18 Jan 2016 17:58:11 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Michael Koster 
Message-ID: <20160118165811.GF7454@hephaistos.amsuess.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PGNNI9BzQDUtgA2J"
Content-Disposition: inline
In-Reply-To: <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 16:58:19 -0000

--PGNNI9BzQDUtgA2J
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Again a short reply before going through the full mail:

On Mon, Jan 18, 2016 at 08:23:00AM -0800, Michael Koster wrote:
> {
> "bn":"/3300/1/",
> =E2=80=9Ci":[ {"n":"5700","v":"31.3"} ],
> "l":[
>   {"href":"","rel":"self","rt":"temperature core.s","u":"C"},
>   {"href":"5700","rt":"currentValue","u":"C"}
> ]
> }
>=20
> Base name, links, and items all are easily mapped to property names
> using a simple JSON-LD context and can be understood and modeled=20
> by higher level tools as-is. Removing the =E2=80=9Ci=E2=80=9D or =E2=80=
=9Cl=E2=80=9D tags gives the modeling=20
> tool nothing to use to identify property instances (like base name, links=
,=20
> and items). This is extensible by adding new property  classes (element=
=20
> tags).

I'm curious: Is JSON-LD at all able to derive, from the above (I took
the liberty to abbreviate and add a second rt), statements like

 a core:s, some:temperature ;
    some:self ; core:unit "C" ;
 a some:currentValue ;
    core:grp ;
    some:value "31.3"

? That would require matching the bn and n for URI concatenation and
whitespace-splitting the rt attribute.

If it is possible -- great, and it might serve as a criterion for a
bufferlessly parsable SenML that it can be transformed using JSON-LD.
But as far as I remember, it can't do that even for -01, and unless that
can be fixed, I don't see much of a point in using it as an example.

Best regards
Christian

--=20
Christian Ams=C3=BCss                      | Energy Harvesting Solutions Gm=
bH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--PGNNI9BzQDUtgA2J
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWnRmdAAoJEDmNERLTpL3hgxgP/RHeO9OBFGzEx+aZRIANaFBh
i9lPdLAbSC9DrJFrwOL0f/wmll3r46bPd8iMqlYjaZViBZfExyrFoY5noYRWMNx/
OWRp04/B4Z9B5V111oNAfdlhvCR+hk6r0KqgdXMJxbuNi1/rP5/T0DEcVbFE7p4S
pOYI7Cgyy0B5KPADPiMm2ymnyx3bCpvY4yNfW4V/ZEdsYcSFtBHQGIuI7o7R9j5n
tTNrgf0AO2enf8qHv4Pbttlo5XCChWHSFNQjJG3tbGgNRxmr5PZ/CzWgk/VUrmz6
mS6plTIPfv0zJ3l1FW1XWo7f9r94qP+MC110g4eJmiOg8MnLL3BE3Dgt2MFGcxJ/
lrvR/Ov0oHVpm+ZLwwnesP2UYHd2ZUixJdQNLHPKvXjeY6exJsqFO/4+gETypeNk
rresXYsWegUuzHMQBBkWkgXL2Bd9eqPkcyQtxCDep5bCAewGEJ0lbvFgZX6UKliI
m53qRP/ExodqtA0UgLNjgr7KMA8Nww2Oh6Lg7TTD8b1uDmxP8FP1IybKBaT0/59D
QIdIDDDbDBywzqxflkqRO4fpJa5I8Db66y4UccV5GFluI1/Ib+VxCxsrzqDQMIPW
ryrA2XpCqgdWCVZBD8uSl0ZIGHy8ZMkPuKsIuP1C60OgFaMoEN1SujsgwUi2HRku
Zo5/i6lDZpp2e8B/XxSC
=ZvIL
-----END PGP SIGNATURE-----

--PGNNI9BzQDUtgA2J--


From nobody Mon Jan 18 09:31:00 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404DE1B3AF4 for ; Mon, 18 Jan 2016 09:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 RD-d70H6dZ5H for ; Mon, 18 Jan 2016 09:30:50 -0800 (PST)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 C22C91B3AF0 for ; Mon, 18 Jan 2016 09:30:50 -0800 (PST)
Received: by mail-pa0-x232.google.com with SMTP id yy13so344260913pab.3 for ; Mon, 18 Jan 2016 09:30:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iCpK/bemi1O0BZPdw/tEwPVoDUaqT2/18gY1maprXv8=; b=m25EnJ7LqzmnEN3GySaFIY1QTyEzdRp7XHftbxaMsn4l5Vv7fUSUVg+HDRAKBkZh5s dOCfNADyvjwK4JnkNUChnWd90intpP3up7c/TWAS58q07Xi4kBJ7cLT6MRBQfHlWgMII 0qg49WV1Ms6R3PIgCIFJbFDaY06c6WPYb9YNkyX+KqYurufO1g3h4h0rTRegrHvXKYwk ABCqktLaXH2nWASQp5gKyWEWzlUV0J2tjdSKqoXeIyPNxfx1FL3mzuzUy7HPVNLrLWIA qvDCdzd4aG8k9pIGbQA2+edTtMpz1fgNyjPwhVKN+2+4dxW66scixBNc1kbHkjIiWISo cXQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=iCpK/bemi1O0BZPdw/tEwPVoDUaqT2/18gY1maprXv8=; b=c5Guy/ezVPZ7jNzET0t0kmIECiqVAC1LinV8900JNN1gWF0d1YLUMCf0E3INEjvHWR H7j9ikIrOlMjRVCj6L7pWpIWacjtUUXduP9Y5r8I3D+p+K6GGDfRNBBQdFQtxdXyyrNx IMZPdSWiI+B1v9Apr0PGhqi/+WQrck+virF9X+pBnGRMTQKisiSmvlncvLQfYE1W78an snO2oWfrpmB3Vg17Z5RKnK0nI9V3czQwgxzyfaWwy1n9g+nfPNtrRhQmeXuVpFG7K60N +ayt4XFJcyjlUiemy9AvhAIIIG6t+NMI/juxfGCiy1VFteiwSKqF3wb8B1V4OuG448u8 Y5xQ==
X-Gm-Message-State: ALoCoQnsJIn0QATjNOnYk1frkEk70rYd7a3f6uwKuNhnjGtGAA+0u44PMtZAqyxPbzOGY7j3NSuXjAs8GkeJky7SMC/jkWqOgw==
X-Received: by 10.66.219.98 with SMTP id pn2mr37740658pac.113.1453138250375; Mon, 18 Jan 2016 09:30:50 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id p66sm35357795pfi.34.2016.01.18.09.30.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 09:30:49 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <20160118165811.GF7454@hephaistos.amsuess.com>
Date: Mon, 18 Jan 2016 09:30:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 17:30:52 -0000

> On Jan 18, 2016, at 8:58 AM, Christian Ams=C3=BCss =
 wrote:
>=20
> Again a short reply before going through the full mail:
>=20
> On Mon, Jan 18, 2016 at 08:23:00AM -0800, Michael Koster wrote:
>> {
>> "bn":"/3300/1/",
>> =E2=80=9Ci":[ {"n":"5700","v":"31.3"} ],
>> "l":[
>>  {"href":"","rel":"self","rt":"temperature core.s","u":"C"},
>>  {"href":"5700","rt":"currentValue","u":"C"}
>> ]
>> }
>>=20
>> Base name, links, and items all are easily mapped to property names
>> using a simple JSON-LD context and can be understood and modeled=20
>> by higher level tools as-is. Removing the =E2=80=9Ci=E2=80=9D or =
=E2=80=9Cl=E2=80=9D tags gives the modeling=20
>> tool nothing to use to identify property instances (like base name, =
links,=20
>> and items). This is extensible by adding new property  classes =
(element=20
>> tags).
>=20
> I'm curious: Is JSON-LD at all able to derive, from the above (I took
> the liberty to abbreviate and add a second rt), statements like
>=20
>  a core:s, some:temperature ;
>    some:self ; core:unit "C" ;
>  a some:currentValue ;
>    core:grp ;
>    some:value "31.3"
>=20
> ? That would require matching the bn and n for URI concatenation and
> whitespace-splitting the rt attribute.
>=20
JSON-LD needs JSON document format to start with, so I first transform=20=

link-format to link-format+json which makes multi-valued attributes an =
array.=20

The tags are mapped to property names in the JSON-LD context using maps
like in this example context for my W3C WoT schema.=20

"capabilities": {"@id": "ts:hasCapability", "@type": "@id"},
"actions": {"@id": "ts:hasAction", "@type": "@id"}
=E2=80=9Cevents": {"@id": "ts:hasEvent", "@type": "@id"}
=E2=80=9Cproperties": {"@id": "ts:hasProperty", "@type": "@id"}

@type:@id maps the key to a URI. for senml I might start with these=20
maps in the context (where some is also defined somewhere).

=E2=80=9Cbn": {"@id": =E2=80=9Csome:baseURI", "@type": "@id"}
=E2=80=9Ci": {"@id": =E2=80=9Csome:collectionItems", "@type": "@id=E2=80=9D=
}
=E2=80=9Cl": {"@id": =E2=80=9Csome:collectionLinks", "@type": "@id"}
=E2=80=9Cn": {"@id": =E2=80=9Csome:baseURI", "@type": "@id=E2=80=9D}
=E2=80=9Cv": {"@id": =E2=80=9Csome:numberValue", "@type": "@id"}
=E2=80=9Cvs": {"@id": =E2=80=9Csome:stringValue", "@type": "@id"}
=E2=80=9Cvb": {"@id": =E2=80=9Csome:booleanValue", "@type": "@id=E2=80=9D}=


and define xsd types, etc. at the referenced URI in some namespace,=20
but there are other ways that the tools could also comprehend.

> If it is possible -- great, and it might serve as a criterion for a
> bufferlessly parsable SenML that it can be transformed using JSON-LD.
> But as far as I remember, it can't do that even for -01, and unless =
that
> can be fixed, I don't see much of a point in using it as an example.
>=20
> Best regards
> Christian
>=20
> --=20
> Christian Ams=C3=BCss                      | Energy Harvesting =
Solutions GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>                                      | ATU68476614


From nobody Thu Jan 21 03:06:19 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E776C1A7013 for ; Thu, 21 Jan 2016 03:06:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level: 
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 dfJK6PXZ0W_1 for ; Thu, 21 Jan 2016 03:06:16 -0800 (PST)
Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9E00B1A7011 for ; Thu, 21 Jan 2016 03:06:14 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2DOAQC9uqBW/wQXEqxchAxtiFeyFgENgWQYAQGHXBQBAQEBAQEBgQqEKwuBHAEDBjJNIggbtDwBAQGQUoUPaYpTgX0LQBiBDwWOJoheaJt3jkMeAQGEMWKHEgEBAQ
X-IPAS-Result: A2DOAQC9uqBW/wQXEqxchAxtiFeyFgENgWQYAQGHXBQBAQEBAQEBgQqEKwuBHAEDBjJNIggbtDwBAQGQUoUPaYpTgX0LQBiBDwWOJoheaJt3jkMeAQGEMWKHEgEBAQ
X-IronPort-AV: E=Sophos;i="5.22,325,1449513000"; d="scan'208";a="44501626"
To: core@ietf.org
MIME-Version: 1.0
X-KeepSent: 70FDA61F:29FDBC67-65257F41:003C9944; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: 
From: Abhijan Bhattacharyya 
Date: Thu, 21 Jan 2016 16:35:59 +0530
X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4|June  07, 2015) at 01/21/2016 16:36:00, Serialize complete at 01/21/2016 16:36:00
Content-Type: multipart/alternative; boundary="=_alternative 003CF94765257F41_="
Archived-At: 
Subject: [core] CoAP implementation for TCP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 11:06:18 -0000

This is a multipart message in MIME format.
--=_alternative 003CF94765257F41_=
Content-Type: text/plain; charset="US-ASCII"

Dear List,
Is there any available CoAP implementation that supports CoAP over TCP as 
suggested in "draft-ietf-core-coap-tcp-tls-01"? 

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



--=_alternative 003CF94765257F41_=
Content-Type: text/html; charset="US-ASCII"

Dear List,

Is there any available CoAP implementation
that supports CoAP over TCP as suggested in "draft-ietf-core-coap-tcp-tls-01"?




Regards

Abhijan Bhattacharyya

Associate Consultant

Scientist, Innovation Lab, Kolkata, India

Tata Consultancy Services

Mailto: abhijan.bhattacharyya@tcs.com

Website: http://www.tcs.com

____________________________________________

Experience certainty.        IT Services

                
       Business Solutions

                
       Consulting

____________________________________________


=====-----=====-----=====

Notice: The information contained in this e-mail

message and/or attachments to it may contain 

confidential or privileged information. If you are 

not the intended recipient, any dissemination, use, 

review, distribution, printing or copying of the 

information contained in this e-mail message 

and/or attachments to it are strictly prohibited. If 

you have received this communication in error, 

please notify us by reply e-mail or telephone and 

immediately and permanently delete the message 

and any attachments. Thank you




--=_alternative 003CF94765257F41_=--


From nobody Thu Jan 21 04:09:09 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595F21ACD15 for ; Thu, 21 Jan 2016 04:09:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 pDIa4hvu7M3v for ; Thu, 21 Jan 2016 04:09:06 -0800 (PST)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414B91ACD02 for ; Thu, 21 Jan 2016 04:09:06 -0800 (PST)
Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 91641FB8C4; Thu, 21 Jan 2016 13:09:04 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id km-ke7kUnvwp; Thu, 21 Jan 2016 13:08:53 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id A90EBFB883; Thu, 21 Jan 2016 13:08:52 +0100 (CET)
Message-ID: <56A0CA52.8010101@tzi.org>
Date: Thu, 21 Jan 2016 13:08:50 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Abhijan Bhattacharyya 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] CoAP implementation for TCP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 12:09:08 -0000

Last time I looked at the libcoap variant employed by IoTivity, their
CoAP over TCP implementation was based on the L3 proposal -- the CoRE WG
chose L1 instead.
But changing that detail that is probably just a very small matter of
coding (and might have been done already, you may want to check).

Grüße, Carsten


Abhijan Bhattacharyya wrote:
> Dear List,
> Is there any available CoAP implementation that supports CoAP over TCP
> as suggested in "draft-ietf-core-coap-tcp-tls-01"?
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, Innovation Lab, Kolkata, India
> Tata Consultancy Services
> Mailto: abhijan.bhattacharyya@tcs.com
> Website: http://www.tcs.com 
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
> 
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From nobody Thu Jan 21 07:36:41 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D811B3204 for ; Thu, 21 Jan 2016 07:36:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 MNhjADg9LY25 for ; Thu, 21 Jan 2016 07:36:38 -0800 (PST)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 4314C1B31FE for ; Thu, 21 Jan 2016 07:36:38 -0800 (PST)
Received: by mail-pa0-x22b.google.com with SMTP id cy9so24975452pac.0 for ; Thu, 21 Jan 2016 07:36:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ArAd4nvPshlyhUlT/nmsHxE6miOhI1J+H7ATkW9kkg8=; b=x6SPUA+IxnyrGgamgZ93PrO+8HqMbxYG8/C9elB40bFW8keimES1L0pvK8VPtKyjLJ T+M9QcM/QkHOD2Hpzw0iRY22xqB03s1BBtH33l1tmFYG2clVkFmhtLEKeahJeu7Fabom QtzlWHGFydSDy4E0T88SGCTimgVnHzb/ScnpotVcrM+T4nkd87vuScrFcomEmVRilRGN c7RpdtHrgLoNoCBtZNXOTdJIzP24g0PllcLP6HnHG62w3mIEiA04YbTWsQoAO+nsNT7h av/rqxuzw1fSP/OWBLcmUALMfB7MyF6y3LpPaulwwcG612PI5LTX9c8geAexrGbZ4+qa xg6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ArAd4nvPshlyhUlT/nmsHxE6miOhI1J+H7ATkW9kkg8=; b=R+e9JV2ShTaNw9x3fHjaMTyDYr/6lX6xsaAcQuOjiFUnxwVYC6mSe+FW4/yS9eQDKb 1Pt4UFmjNYmjzOb6SDj7JdlFtljVoJFi1MPZvn2cS5ILkkvwDSoXaydnbdnFYI43YxbW FBz+5qujuFlk82uYKIVCnCivmcNxH/e0EsXB6KaVWRYj+yH7PRkwwVjODbMRMqKb1xaN WH3q1+NapjewL4qQkMunRSbMfPGXJsFObG6wc4WBwCN6xvVSP+P07OhUlCkdRNUFOr9T dpytTSDVqm1CgVAG7eim4J0m9TilOH/hVBzu1SKy0Eac4KkAGy0DVYKoFywbolTKoufA b2dQ==
X-Gm-Message-State: AG10YORDBf20zM89WjgfcmFKdjJnznAPHqibbYgOD09Oj6Pd5LJM3T/Ekmv5hALPyKk2kw==
X-Received: by 10.67.22.166 with SMTP id ht6mr17438736pad.9.1453390597833; Thu, 21 Jan 2016 07:36:37 -0800 (PST)
Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id yh5sm3527703pab.13.2016.01.21.07.36.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 07:36:37 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1E0467D6-E464-48D0-9D6E-13D2C9FEF2A7"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <56A0CA52.8010101@tzi.org>
Date: Thu, 21 Jan 2016 07:36:35 -0800
Message-Id: 
References:  <56A0CA52.8010101@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] CoAP implementation for TCP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 15:36:40 -0000

--Apple-Mail=_1E0467D6-E464-48D0-9D6E-13D2C9FEF2A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Crsten,

I am participating in the OIC core and smarthome task groups now.=20

I have noted the WG choice of L1 to the OIC core tg mailing list and =
could follow up in Bangkok next week.

Michael


> On Jan 21, 2016, at 4:08 AM, Carsten Bormann  wrote:
>=20
> Last time I looked at the libcoap variant employed by IoTivity, their
> CoAP over TCP implementation was based on the L3 proposal -- the CoRE =
WG
> chose L1 instead.
> But changing that detail that is probably just a very small matter of
> coding (and might have been done already, you may want to check).
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>=20
> Abhijan Bhattacharyya wrote:
>> Dear List,
>> Is there any available CoAP implementation that supports CoAP over =
TCP
>> as suggested in "draft-ietf-core-coap-tcp-tls-01"?
>>=20
>> Regards
>> Abhijan Bhattacharyya
>> Associate Consultant
>> Scientist, Innovation Lab, Kolkata, India
>> Tata Consultancy Services
>> Mailto: abhijan.bhattacharyya@tcs.com =

>> Website: http://www.tcs.com  =
>
>> ____________________________________________
>> Experience certainty.        IT Services
>>                       Business Solutions
>>                       Consulting
>> ____________________________________________
>>=20
>> =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
>> Notice: The information contained in this e-mail
>> message and/or attachments to it may contain
>> confidential or privileged information. If you are
>> not the intended recipient, any dissemination, use,
>> review, distribution, printing or copying of the
>> information contained in this e-mail message
>> and/or attachments to it are strictly prohibited. If
>> you have received this communication in error,
>> please notify us by reply e-mail or telephone and
>> immediately and permanently delete the message
>> and any attachments. Thank you
>>=20
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>=20
> _______________________________________________
> core mailing list
> core@ietf.org 
> https://www.ietf.org/mailman/listinfo/core =


--Apple-Mail=_1E0467D6-E464-48D0-9D6E-13D2C9FEF2A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi Crsten,

I am participating in the OIC core and smarthome task groups =
now. 

I have =
noted the WG choice of L1 to the OIC core tg mailing list and could =
follow up in Bangkok next week.

Michael


On Jan 21, 2016, at 4:08 AM, Carsten Bormann <cabo@tzi.org> =
wrote:

Last time I looked at the libcoap variant =
employed by IoTivity, their
CoAP over TCP =
implementation was based on the L3 proposal -- the CoRE WG
chose L1 instead.
But changing that detail that is probably just a =
very small matter of
coding (and might have =
been done already, you may want to check).

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


Abhijan Bhattacharyya wrote:
Dear List,
Is there any available CoAP implementation that supports CoAP =
over TCP
as suggested in =
"draft-ietf-core-coap-tcp-tls-01"?

RegardsAbhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata =
Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com <http://www.tcs.com/>
____________________________________________
Experience certainty. =
       IT Services
          &nb=
sp;           Busin=
ess Solutions
          &nb=
sp;           Consu=
lting
____________________________________________

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=
=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

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

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

=

--Apple-Mail=_1E0467D6-E464-48D0-9D6E-13D2C9FEF2A7--


From nobody Sun Jan 24 02:27:48 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0391B3A4C; Sat, 23 Jan 2016 17:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 JvcsnODSWGW9; Sat, 23 Jan 2016 17:26:03 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 AC5751B3A4A; Sat, 23 Jan 2016 17:26:03 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id n128so62351046pfn.3; Sat, 23 Jan 2016 17:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Q+IfsrppBWQvv4ZIQD0/3YnGq4UM6LM1092YysDtK0U=; b=ZOw1YVN1QkDqhgVk+kWFoipOXVkRdqGJnxhSEsCyr+DjeoZ9+FeKWriJch+a7uF6K4 fWVwJj6Gmjvvlm0Wp+GmCgxyiON1qgpUGyKGsI+thoQiiZqt72+9NjaycTbRzHltHvzI 4hkSRRaUv1OmQUCJnpP1FHCaMo8lKGGDI7cMZJQjHNq67Cs9CGkQt9pQT7hI/cRNtnYK 8jPHE5wmQhKW7yrvEH0EqNHFcOQ2jP2HOIgwjk9R0siAKZICJX8WLLq2XoOkUSTNkNnU NCJqSSp6PyMHPYAMtFhfrplQk4m4i2Au8x4bcGU59Vyg2WkhLL91N2wHBIRPqn7EaZ8b A5TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Q+IfsrppBWQvv4ZIQD0/3YnGq4UM6LM1092YysDtK0U=; b=i0Q8Hs7Pvs4PBAvSA6j9qaN7w7bGdDjruuMxSKBDwq6l15UR+SUG+6X5UEpPRu1TOa n5PhFJNZcB2oEAeFYfSht2lQnXr92Rv3mMXLb+JCotqzc26ydw6Bdx7stXVOtDBFjlV+ 9YIsJ2mL/f7p24yz4YnRtAlxVmo6YluS5cEF4QCbwRjVxSlfQ5wg2JDJpFDYQeBFj8pj pPXUSr+nSZ1L8U3az2Pm3ktOyEm2gJEFAa4XdwNLcGat5YGXK8HnFKamekneI6XMwwUo B0xbMN2wvMUw8NkcGIwxiByIphtbXK4DNaRnKEHzvjOtQHKVGapx+JWSwIXzXcNBdvEt dTcA==
X-Gm-Message-State: AG10YOQGo6EbEfN6FHv/yNcL68/+fEzrYdTxeDPyZnApSRP650eKVMy38BOA0wgUpc1I+Q==
X-Received: by 10.98.70.151 with SMTP id o23mr15450815pfi.124.1453598763215; Sat, 23 Jan 2016 17:26:03 -0800 (PST)
Received: from [10.24.22.192] ([128.107.241.181]) by smtp.gmail.com with ESMTPSA id 68sm18820675pfa.78.2016.01.23.17.26.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 23 Jan 2016 17:26:01 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Sat, 23 Jan 2016 18:25:59 -0700
Message-Id: 
References: 
To: NETCONF 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
X-Mailman-Approved-At: Sun, 24 Jan 2016 02:27:48 -0800
Cc: i2rs@ietf.org, 6tisch@ietf.org, core@ietf.org, "netmod@ietf.org" , 6lo@ietf.org
Subject: Re: [core] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2016 01:26:06 -0000

--Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The Last Call period for the above three drafts closed yesterday. Thanks =
to everyone who provided comments on the three drafts.

The authors will update the documents based on the comments received and =
post an updated version of the draft(s).

Mahesh & Mehmet.

> On Dec 15, 2015, at 2:09 PM, Ersue, Mehmet (Nokia - DE/Munich) =
 wrote:
>=20
> FYI and attention.
> =20
> Please provide your comments to NETCONF WG maillist.
> =20
> Mehmet
> =20
> From: Ersue, Mehmet (Nokia - DE/Munich)=20
> Sent: Tuesday, December 15, 2015 9:59 PM
> To: netconf@ietf.org 
> Cc: 'core@ietf.org ' >; 'i2rs@ietf.org ' =
>; '6lo@ietf.org =
' <6lo@ietf.org >; =
'6tisch@ietf.org ' <6tisch@ietf.org =
>
> Subject: WG Last Call for draft-ietf-netconf-restconf-09, =
draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03
> =20
> Dear NETCONF WG,
> =20
> we hereby issue a WG Last Call for the drafts below:
> =20
> http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt =

> http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt =

> http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt =

> =20
> Please review and send your comments to the NETCONF WG mailing list by =
January 22, 2015 EOB PT.
> =20
> The drafts on RESTCONF, YANG patch and YANG library are planned to =
publish as standard track documents.
> =20
> As RESTCONF is a major protocol we seek a detailed and thorough review =
within NETCONF WG but also by the related WGs before publishing.
> Therefore the WGLC is planned to finalize on January 22th (covering =
the holiday time in between) and APP, INT and RTG area ADs will be =
informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to =
review.
> =20
> Please take your time to review the documents and send your comments =
to the NETCONF maillist by the deadline.
> Please state on NETCONF maillist also explicitly, whether you have =
read/reviewed and whether you support the publication.
> Furthermore please indicate if you plan to implement or have already =
implementations for RESTCONF and its supplementary drafts.
> =20
> Thank you for your review and kind help getting RESTCONF =
specifications stable.
> =20
> Best Regards,
> Mehmet and Mahesh






--Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

The Last Call period for the above three drafts closed =
yesterday. Thanks to everyone who provided comments on the three =
drafts.

The authors =
will update the documents based on the comments received and post an =
updated version of the draft(s).

Mahesh & Mehmet.

On Dec 15, 2015, at 2:09 PM, Ersue, Mehmet (Nokia - =
DE/Munich) <mehmet.ersue@nokia.com> wrote:

FYI and attention.
 
Please provide your =
comments to NETCONF WG maillist.
 
Mehmet
 
From: Ersue, =
Mehmet (Nokia - DE/Munich) 
Sent: Tuesday, December 15, 2015 =
9:59 PM
To: netconf@ietf.org
Cc: 'core@ietf.org' <core@ietf.org>; 'i2rs@ietf.org' <i2rs@ietf.org>; '6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch@ietf.org>
Subject: WG Last Call for =
draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and =
draft-ietf-netconf-yang-library-03
 
Dear NETCONF WG,
 
we hereby issue a WG Last =
Call for the drafts below:
 
http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt
 
Please review and send =
your comments to the NETCONF WG mailing list by January 22, 2015 EOB =
PT.
 
The =
drafts on RESTCONF, YANG patch and YANG library are planned to publish =
as standard track documents.
 
As RESTCONF is a major protocol we seek a =
detailed and thorough review within NETCONF WG but also by the related =
WGs before publishing.
Therefore the WGLC is planned to finalize on January 22th =
(covering the holiday time in between) and APP, INT and RTG area ADs =
will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited =
to review.
 
Please take your time to review the documents and send your =
comments to the NETCONF maillist by the deadline.
Please state on NETCONF maillist also =
explicitly, whether you have read/reviewed and whether you support the =
publication.
Furthermore please =
indicate if you plan to implement or have already =
implementations for RESTCONF and its supplementary =
drafts.
 
Thank=
 you for your review and kind help getting RESTCONF specifications =
stable.
 
Best =
Regards,
Mehmet and =
Mahesh








=

--Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC--


From nobody Mon Jan 25 14:14:50 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB061A1A87 for ; Mon, 25 Jan 2016 14:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.502
X-Spam-Level: 
X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
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 RwnNy4POIEj5 for ; Mon, 25 Jan 2016 14:14:46 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA521A1A83 for ; Mon, 25 Jan 2016 14:14:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1606; q=dns/txt; s=iport; t=1453760086; x=1454969686; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=K4HVFbbqSRM22L2JYdXH2nZr0+MoCrtUCayCf3w3V6k=; b=eB5rQIntmTdJObGv+byJjFhm+bc3hLixy74J0HQw3Lp/x9ciYNyLhcYr uG0OCk0HK/efmyLMwmd3aztMf7LyIn23jPdTeFBtLNjR9Vj/y1tVXLpKc 0r+ezwrKW5pGtwHaMm2Mt4OJwKpHa9tzf7sTO3GmISAq3Tl4r2KC0CVLG 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDAnaZW/4sNJK1egzpSbQaIUbIUA?= =?us-ascii?q?Q2BYxgKhW0CHIEpOBQBAQEBAQEBgQqEQQEBAQMBAQEBIBE6CwULAgEGAg4KAgI?= =?us-ascii?q?mAgICJQsVEAIEDgWIEwgOkiadFI8FAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQR7h?= =?us-ascii?q?zsIgmGESYMDK4EPAQSWdgGNVY55jj4BHgEBQoNpaoZAfAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,346,1449532800"; d="scan'208";a="66982463"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jan 2016 22:14:45 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0PMEjlF028584 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jan 2016 22:14:45 GMT
Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Jan 2016 17:14:44 -0500
Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Mon, 25 Jan 2016 17:14:44 -0500
From: "Cullen Jennings (fluffy)" 
To: Carsten Bormann 
Thread-Topic: [core] Designs to resolve streaming issues in SenML
Thread-Index: AQHRTg8O1qrVpL28FUOtKmOA3wV52J8NM0kA
Date: Mon, 25 Jan 2016 22:14:44 +0000
Message-ID: <7B9B6160-3AD4-4637-8430-540B99E6BDA2@cisco.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <56965F8D.9040309@tzi.org>
In-Reply-To: <56965F8D.9040309@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.120.33]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 22:14:48 -0000

DQo+IE9uIEphbiAxMywgMjAxNiwgYXQgNzozMCBBTSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6
aS5vcmc+IHdyb3RlOg0KPiANCj4gQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIHdyb3RlOg0KPj4g
cHJvIC8gY29ucyBvZiB0aGUgLTAzIGRlc2lnbiB2cyAtMDQgZGVzaWduLg0KPiANCj4gT25lIGNv
bW1lbnQgSSBtYWRlIHdoZW4gdGhpcyB3YXMgZGlzY3Vzc2VkIGluIFlva29oYW1hIHdhcyB0aGF0
IHRoZSAtMDQNCj4gZGVzaWduIG1ha2VzIHRoZSBwcm9jZXNzb3IgZXhhbWluZSBldmVyeSBzaW5n
bGUgbWVhc3VyZW1lbnQgcmVjb3JkDQo+IHdoZXRoZXIgdGhlcmUgaXMgYSBjaGFuZ2UgdG8gdGhl
IGJhc2UgdmFsdWVzIChhbmQsIGlmIHRoZXJlIGFyZSBvbmx5DQo+IGNoYW5nZXMgdG8gYmFzZSB2
YWx1ZXMgc28gdGhhdCByZWNvcmQgaXNuJ3QgcmVhbGx5IGEgbWVhc3VyZW1lbnQNCj4gcmVjb3Jk
KS4gIFRoYXQgbWlnaHQgaW1wZWRlIGhpZ2ggc3BlZWQgcHJvY2Vzc2luZyBhIGJpdC4gIEUuZy4s
IGl0IGNvdWxkDQo+IGJlY29tZSBoYXJkZXIgdG8gbWVyZ2UgdHdvIHRpbWUgc2VxdWVuY2VzIGJl
Y2F1c2UgZWFjaCBzaW5nbGUgZW50cnkgaW4NCj4gdGhlbSBtaWdodCBiZSBjaGFuZ2luZyBhIGJh
c2UgdmFsdWUgdGhhdCBpcyByZWxldmFudCB0byBlbnRyaWVzIGluIHRoZQ0KPiBvdGhlciBzdHJl
YW0uICBCdXQgSSBoYXZlbid0IGltcGxlbWVudGVkIGVpdGhlciBtb2RlbCwgc28gdGhhdCBpcyBq
dXN0IGENCj4gaHVuY2guDQo+IA0KPiBBcGFydCBmcm9tIHRoYXQga2luZCBvZiBjb25zaWRlcmF0
aW9uLCB0aGF0IHBhcnQgb2YgdGhlIGFwcHJvYWNoIC0wNCBpcw0KPiBwcmV0dHkgbXVjaCBlcXVp
dmFsZW50IHRvIC0wMy4NCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0
DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9jb3JlDQoNClNlZW1zIGxpa2UgYSBnb29kIGFyZ3VtZW50IGZvciBvbmx5IHRoZSBmaXJzdCBy
ZWNvcmQgY2FuIGhhdmUgYmFzZSB2YWx1ZXMuIEFueSBvYmplY3Rpb25zIHRvIG1ha2luZyB0aGF0
IGNoYW5nZSBmb3IgbmV4dCB2ZXJzaW9uID8NCg0KDQo=


From nobody Mon Jan 25 14:16:03 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5751A1A91 for ; Mon, 25 Jan 2016 14:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.102
X-Spam-Level: 
X-Spam-Status: No, score=-111.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
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 ZYDJlyBmp-7J for ; Mon, 25 Jan 2016 14:15:57 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497291A1A97 for ; Mon, 25 Jan 2016 14:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42716; q=dns/txt; s=iport; t=1453760157; x=1454969757; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LZqGTqXy23dIObDQ3vCPI6kId5NEfStG0Gg0QsHBdqg=; b=Q0wbQn/Rzxf4jTfxnUz9huvJrWFYV2K8HSBxZi//U1JdNxR7dk7izIdK bQYWsOHcUEGfy45o0OF5wL0BHhUAAkd0JkLb/RFRO3LH/C4ukcVAYLknJ nVxkgHg+HzdCiO/iVTD+gXRpIjY0Mzk7j659ZFcTRsGabDKEhCll1PeGD k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBQBOnaZW/5RdJa1egzpSbQaBE4c+t?= =?us-ascii?q?AUkhWsCHIEpPBABAQEBAQEBgQqEQgEBBBoJVhACAQg4BwMCAgIwFBECBAENBQk?= =?us-ascii?q?SiAAOrzqPAwEBAQEBAQEBAQEBAQEBAQEBAQEBARWINoFmgQOEJQENLhcRgkMrg?= =?us-ascii?q?Q8FjSqJTAGFRYJxhR8GgVhKg3qIV4VuhH6DUgEPKCuCARiBUGoBhgIBHx18AQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.22,346,1449532800";  d="scan'208,217";a="231303451"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2016 22:15:55 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u0PMFtuV003543 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jan 2016 22:15:55 GMT
Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Jan 2016 17:15:54 -0500
Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Mon, 25 Jan 2016 17:15:54 -0500
From: "Cullen Jennings (fluffy)" 
To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , Michael Koster 
Thread-Topic: [core] Designs to resolve streaming issues in SenML
Thread-Index: AQHRUeAS1qrVpL28FUOtKmOA3wV52J8NK/sA
Date: Mon, 25 Jan 2016 22:15:54 +0000
Message-ID: 
References: <20160118110500.GA7789@hephaistos.amsuess.com>
In-Reply-To: <20160118110500.GA7789@hephaistos.amsuess.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.120.33]
Content-Type: multipart/alternative; boundary="_000_E149F2E558BC46D7B4AD53CFC0BA3283ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 22:16:02 -0000

--_000_E149F2E558BC46D7B4AD53CFC0BA3283ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpUaGlzIG1lc3NhZ2UgcmVhbGx5IGhlbHBzIGNsYXJpZnkgdGhpbmdzLiBUaGFua3MuIE1vcmUg
aW5saW5lDQoNCg0KT24gSmFuIDE4LCAyMDE2LCBhdCA0OjA1IEFNLCBDaHJpc3RpYW4gQW1zw7xz
cyA8Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQ8bWFpbHRvOmMuYW1zdWVzc0BlbmVyZ3lo
YXJ2ZXN0aW5nLmF0Pj4gd3JvdGU6DQoNCkhlbGxvIE1pY2hhZWwsDQoNCml0IGFwcGVhcnMgdGhh
dCB0aGVyZSBhcmUgdGhyZWUgY29uY2VwdHMgYm90aCBiZWluZyBjYWxsZWQgb3IgcmVsYXRlZCB0
bw0KInN0cmVhbWluZyIgdGhhdCBnZXQgbWl4ZWQgdXAgaW4gdGhpcyB0aHJlYWQsIEknbGwgdHJ5
IHRvIGZsZXNoIHRoZW0gb3V0DQpmaXN0LCBkZXNjcmliaW5nIHRoZWlyIHB1cnBvc2UsIHN0YXR1
cyBvZiBkcmFmdHMsIGFuZCBpbnRlcmFjdGlvbiB3aXRoDQpjbGllbnQgYW5kIHNlcnZlciBzaWRl
Lg0KDQpBLiBUaGUgZHJhZnQgcGFyYWdyYXBoIGFib3V0ICJzdG9yZSBvciB0cmFuc21pdCBTZW5N
TCBpbiBhIHN0cmVhbS1saWtlDQogZmFzaGlvbiIgaW4gdGhlICJNdWx0aXBsZSBEYXRhcG9pbnRz
IiBzZWN0aW9uOg0KDQogVGhpcyBpcyBtb3JlIGFib3V0IHRyYW5zcG9ydGF0aW9uLCBhbmQgaW1w
bGllcyB0aGF0IHRoZXJlIGlzIHNvbWUga2luZA0KIG9mIGJvdW5kYXJ5IGJldHdlZW4gZWxlbWVu
dHMgYXQgd2hpY2ggdHJhbnNtaXNzaW9uIGNhbiBwYXVzZS4NCg0KIFN1Y2ggYm91bmRhcmllcyBh
cmUgcHJlc2VudCBpbiBhbGwgZHJhZnRzIHNvIGZhci4NCg0KIEl0IGFwcGVhcnMgdG8gbWUgdGhh
dCB0aGlzIHdvdWxkIHByaW1hcmlseSB3b3JrIHdpdGggSFRUUCBpbiBhIGZhc2hpb24NCiBzaW1p
bGFyIHRvIGxvbmcgcG9sbGluZywgd2hpY2ggaXMgc29tZXRoaW5nIGJvdGggY29tbXVuaWNhdGlu
ZyBwYXJ0aWVzDQogbmVlZCB0byBiZSBhd2FyZSBvZiAoYWxsIGRyYWZ0czogIk1VU1Qgc3BlY2lm
eSB0aGF0IHRoZXkgYXJlIGRvaW5nDQogdGhpcyIpLCBsZXN0IHRoZXkgdGltZSBvdXQgdGhlIGNv
bm5lY3Rpb24uDQoNCmFncmVlIGFuZCBJIHRoaW5rIGEgZGlmZmVyZW50IG1pbmUgdHlwZSBjYW4g
YmUgdXNlZCBmb3IgYm90aCBzaWRlcyB0byB1bmRlcnN0YW5kIHRoZXkgYXJlIGRvaW5nIHRoaXMu
IEluIHNvbWUgY2FzZXMgdGhlIHN0cmVhbSBtYXkgbmV2ZXIgZW5kIGFuZCB0aGUgSlNPTiB0byBj
bG9zZSB0aGUgZGF0YSBzdHJ1Y3R1cmVzIHdvdWxkIG5ldmVyIGJlIHNlbnQgc28gYXQgc29tZSBs
ZXZlbCBpdOKAmXMgbm90IGV2ZW4gdmFsaWQgSlNPTi4NCg0KDQpCLiBCdWZmZXItbGVzcyBvcGVy
YXRpb246DQoNCiBGb3IgdmVyeSBzbWFsbCBhcHBsaWNhdGlvbnMgKGVnLiB1c2luZyB1SVAgYW5k
IGZldyBrQiBvZiBSQU0pLCBpdCBpcw0KIGRlc2lyYWJsZSB0byB1c2UgZGF0YSBmb3JtYXRzIHRo
YXQgbmV2ZXIgcmVxdWlyZSBiYWNrLXNlZWtpbmcsIHRoYXQNCiBsaW1pdCBiYWNrLXNlZWtzIHRv
IGEgZml4ZWQgbGVuZ3RoIG9yIHRoYXQgY2FuIGRvIHdpdGggYSBmaXhlZC1sZW5ndGgNCiBidWZm
ZXIgdG8gaG9sZCBpbmZvcm1hdGlvbiBmb3IgdGhhdC4gVGhlIHNwZWNpZmljYXRpb24gZG9lcyBu
b3QgbmVlZA0KIHRvIGFjdGl2ZWx5IGRlc2NyaWJlIHRob3NlIG9wZXJhdGlvbnMsIHJlcXVpcmlu
ZyBzb21lIGJhc2ljIHN0cnVjdHVyZQ0KIGlzIHN1ZmZpY2llbnQuDQoNCiBJdCBoYXMgYmVlbiBz
dWdnZXN0ZWQgZWFybGllciBvbiB0aGlzIGxpc3QgdGhhdCAtMDEgd2l0aCBhbiBhZGRpdGlvbmFs
DQogcmVxdWlyZW1lbnQgdGhhdCAiYm4iIGFuZCAiYnQiIHRvIGNvbWUgZmlyc3QgaW4gdGhlIGRp
Y3Rpb25hcmllcyB3b3VsZA0KIGFsbG93IHRoaXMgbW9kZSBvZiBvcGVyYXRpb24gdG9vIC0tIHRy
dXRoLCBidXQgaGFyZCB0byBhY2hpZXZlIHdpdGgNCiBnZW5lcmljIEpTT04gaW1wbGVtZW50YXRp
b25zIGFuZCBzZW1hbnRpY3MuDQoNCiBUaHVzLCB0aGlzIGdvYWwgaXMgb25seSBhY2hpZXZlZCBi
eSBkcmFmdHMgLTAyIGFuZCBsYXRlci4gKFRoaXMgaXMNCiBhbHNvIHdoYXQgbXkgZGVtbyBpcyBh
Ym91dCwgd2hpY2ggc2hvd3MgdGhhdCAtMDMgaXMgcGFydGljdWxhcmx5DQogc3VpdGFibGUpLg0K
DQogVGhhdCB0aGlzIG9ubHkgYW4gaXNzdWUgZm9yIHRoZSByZWNlaXZpbmcgc2lkZSAodGhlIHNl
bmRlciBpcyBmcmVlDQogdG8gY2hvb3NlIGVsZW1lbnQgc2VxdWVuY2VzIGFzIGlzIG1vc3QgcHJh
Y3RpY2FsIGZvciBpdCBhbnl3YXksIGFzDQogbG9uZyBhcyBpdCBmb2xsb3dzIHRoZSBzcGVjaWZp
Y2F0aW9uKS4gSGF2aW5nIHRoaXMgbmVnb3RpYWJsZSB3b3VsZA0KIGRlZmVhdCBpdHMgcHVycG9z
ZTogSWYgcmVjZWl2ZXJzIG1heSByZWx5IG9uIGl0LCB3ZSBjYW4ndCBhbGxvdw0KIHNlbmRlcnMg
dG8gbm90IHN1cHBvcnQgaXQuDQoNCkkgdGhpbmsgc3VwcG9ydGluZyB0aGlzIGlzIGltcG9ydGFu
dC4gSXTigJlzIGdvb2QgZm9yIHNtYWxsIHRoaW5ncyBidXQgaXQgYWxzbyB0ZW5kcyB0byBzdXBw
b3J0IHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUgbGFyZ2UgYnV0IG5lZWQgdG8gYmUg
YWJsZSB0byBwcm9jZXNzIHJlYWxseSBhIGxvdCBvZiBkYXRhIHF1aWNrbHkuDQoNCg0KQy4gTXVs
dGlwbGUgYmFzZSBlbGVtZW50czoNCg0KIFRoZSBpZGVhIHRvIGhhdmUgbXVsdGlwbGUgYmFzZSBl
bGVtZW50cyBjYW1lIHVwIGluZGVwZW5kZW50bHkgb2YgdGhlDQogb3RoZXJzLCBhbmQgZ2l2ZXMg
c21hbGxlciBkYXRhIHN0cmVhbXMgZm9yIGNhc2VzIGluIHdoaWNoIGRpZmZlcmVudA0KIHNlbnNv
cnMnIHRpbWUgc2VyaWVzIGFyZSBwcm9kdWNlZCwgb3Igd2hlbiB0aGVyZSBhcmUgbGFyZ2VyIGdh
cHMgaW4gYQ0KIHRpbWVsaW5lLiBUaGUgcHJvcG9zYWwgd29ya2VkIHdlbGwgd2l0aCB0aGUgYXJy
YXktYXMtcm9vdCBzY2hlbWUNCiBlbnZpc2lvbmVkIHdpdGggZXhhY3RseSAyIGVsZW1lbnRzIGZv
ciBCLiwgYW5kIHdhcyBpbXBsZW1lbnRlZA0KIHRvZ2V0aGVyLg0KDQoNCknigJltIHN0YXJ0aW5n
IHRvIHRoaW5rIHRoYXQgdGhlIHVzZSBjYXNlIGZvciBtdWx0aXBsZSBiYXNlIGVsZW1lbnRzIGlz
IHZlcnkgd2VhayBhbmQgdGhhdCBwZXJoYXBzIHdlIHNob3VsZCBvbmx5IGFsbG93IGEgc2luZ2xl
IHNldCBvZiBiYXNlIHVuaXRzIHdoaWNoIGFyZSBiZWZvcmUgYW55IG9mIHRoZSBtZWFzdXJlbWVu
dHMuIElmIHdlIGdldCB0aGlzIGZvciBmcmVlIG9yIGNoZWFwLCBncmVhdCwgYnV0IG5vdCBzb21l
dGhpbmcgSSBjYXJlIGEgbG90IGFib3V0Lg0KDQoNCiBJdCBpcyBwcmVzZW50IGluIC0wMyBhbmQg
LTA0Lg0KDQogU2VuZGVycyBhcmUgZnJlZSBub3QgdG8gdXNlIGl0LiBJbiBteSBpbXByZXNzaW9u
LCB0aGlzIGlzIGVhc2lseSB0bw0KIGltcGxlbWVudCBpbiByZWNlaXZlcnMuIChFdmVuIGlmIHRo
ZXkgZGVzaXJlIHRvIGRpcmVjdGx5IGFjY2Vzcw0KIGluLW1lbW9yeSByZXByZXNlbnRhdGlvbnMg
b2YgSlNPTjsgdGhlIGtleSB0byBhbiBlbnRyeSBtaWdodCB0aGVuIGJlDQogKGxpc3QtbnVtYmVy
LCBsaXN0LXBvc2l0aW9uKSBpbnN0ZWFkIG9mIGp1c3QgbGlzdC1wb3NpdGlvbikuDQoNCg0KUFMg
Q2FuIHdlIHN1Y2NpbmN0bHkgZGVzY3JpYmUgdGhlIHVzZSBjYXNlIGZvciBvcmRlcmVkIHNlcmlh
bA0KcHJvY2Vzc2luZyBvZiBzZW5tbCtqc29uIGVsZW1lbnRzIGJlaW5nIGltcG9ydGFudD8gRnJv
bSByZWFkaW5nIHRoZQ0KZHJhZnQsIGl0IHNlZW1zIGxpa2UgdGhlIGltcG9ydGFudCBiaXQgaXMg
c2F2aW5nIHRoZSBidWZmZXIgbWVtb3J5IGZvcg0KbGFyZ2UgcmVzcG9uc2VzLg0KDQpUaGUgb25l
IEknbSBhcmd1aW5nIGhlcmUgaXMgQi4sIHRoZSBidWZmZXItbGVzcyBvcGVyYXRpb24uIFRoZSB1
c2UgY2FzZQ0KYXJlIGRldmljZXMgd2l0aCBsaW1pdGVkIGhlYXAgbWVtb3J5IChzYXkgNGsgZm9y
IGluY29taW5nIGFuZCBvdXRnb2luZw0KcGFja2FnZXMpLiBJJ20gdXNpbmcgU2VuTUwgaW4gY29y
ZS1pbnRlcmZhY2VzIGJhdGNoZXNbMV0gdG8gZ2V0IGFuZCBzZXQNCmRldmljZSBzdGF0ZS4gV2hl
biB0aG9zZSBkZXZpY2VzIGFubm91bmNlIHN1cHBvcnRpbmcgYmF0Y2ggb3BlcmF0aW9uLA0KdGhl
eSBuZWVkIHRvIGFjY2VwdCBTZW5NTCBQVVRzIHRvIGFzIG1hbnkgcmVzb3VyY2VzIGFzIGFyZSBi
YXRjaGVkDQp0b2dldGhlciwgc28gZmFyIHdpdGhvdXQgYXJiaXRyYXJ5IGNvbnN0cmFpbnRzLiBE
dWUgdG8gdGhlIHByb3Bvc2VkDQpleHRlbnNpYmlsaXR5IG9mIFNlbk1MLCBldmVuIGlmIEkgbGlt
aXRlZCB0aGUgbnVtYmVyIG9mIHJlc291cmNlcyBpbiBhDQpiYXRjaCwgSSBjb3VsZG4ndCBwcmVk
aWN0IHRoZSBtYXhpbXVtIHNpemUgb2YgYW4gaW5jb21pbmcgdXBkYXRlLg0KDQpOb3cgd2hlbiB0
aGUgdXBkYXRlIGFycml2ZXMgYW5kIGEgU2VuTUwgdGhhdCBkb2VzIG5vdCBzYXRpc2Z5IEIuIGNv
bWVzDQppbiwgYWxsIEkgY2FuIGRvIGlzIHRvIHN0b3JlIHRoZSB3aG9sZSBtZXNzYWdlIGJvZHkg
YW5kIHBhcnNlIGl0IHdoZW4NCnRoZSBsYXN0IGJsb2NrIGFycml2ZWQuIElmIHRoZSBzZW5kZXIg
dXBkYXRlZCB0b28gbWFueSByZXNvdXJjZXMgb3IgdXNlZA0KdG9vIGxhcmdlIGV4dGVuc2lvbnMs
IEknZCBuZWVkIHRvIDQuMTMtUmVxdWVzdC1FbnRpdHktdG9vLWxhcmdlIG91dC4NClN0aWxsLCB1
bnRpbCB0aGVuIChwYXJ0aWN1bGFybHkgdW50aWwgdGhlIG92ZXJmbG93aW5nIHBhY2thZ2UgYXJy
aXZlcyksDQptZW1vcnkgaXMgY2xvZ2dlZCB3aXRoIHVucGFyc2FibGUgZGF0YS4NCg0KSXMgaXQg
YSBiaWdnZXIgZGVhbCB3aXRoIENCT1IgZW5jb2Rpbmcgb3IgbGVzcyBpbXBvcnRhbnQuDQoNCldo
ZXRoZXIgQ0JPUiBvciBKU09OIGlzIGJlaW5nIHBhcnNlZCBpcyBhbG1vc3QgaXJyZWxldmFudCBo
ZXJlLiBUaGUgb25seQ0KZGlmZmVyZW5jZSB0aGF0IGNvbWVzIHRvIG15IG1pbmQgaXMgdGhhdCB3
aXRoIENCT1IsIHdlIG1pZ2h0IGJlIGFibGUgdG8NCnByZXNjcmliZSBhIHNlcmlhbGl6YXRpb24g
d2hlcmUgImJuIiBhbmQgImJ0IiBhbHdheXMgcHJlY2VkZSAiZSIgZXZlbiBpbg0KLTAxLXN0eWxl
LCBidXQgZXZlbiB0aGF0IHdvdWxkIG1ha2UgaXQgaGFyZGVyIHRvIHV0aWxpemUgZm9yIHdob21l
dmVyDQppbXBsZW1lbnQgdGhpcyB3aXRoIGEgbmF0aXZlLW9iamVjdC1zdHlsZSBsaWJyYXJ5Lg0K
DQpJcyB0aGUgbW9zdCBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbiBiZWluZyBhYmxlIHRvIGtub3cg
dGhlIGJhc2UgdmFsdWVzDQphaGVhZCBvZiB0aGUgZGF0YT8NCg0KVGhpcyBpcyBhYm91dCBhbGwg
aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgaW4gdGhlIGRpY3Rpb25hcnkgYW5kIG1vZGlmaWVzDQpo
b3cgdG8gaW50ZXJwcmV0IHRoZSBlbGVtZW50cycgZGF0YS4gSW4gY29yZSBTZW5NTCwgdGhhdCBp
bmZvcm1hdGlvbiBpcw0KdGhlIGJhc2UgYXR0cmlidXRlcywgYW5kIHRoZSB2ZXJzaW9uIC0tIHRo
YXQgaXMsIGFsbCB0aGUgcG9zc2libGUgcm9vdA0KdmFyaWFibGVzLiAoSW4gYSBzY2VuYXJpbyAu
KQ0KDQpGb3IgZXh0ZW5zaW9ucywgdGhpcyBjb21wbGV0ZWx5IGRlcGVuZHMgb24gdGhlbSB1bmxl
c3MgdGhlIHJlY2VpdmVyDQpjaG9vc2VzIHRvIGlnbm9yZSB0aGVtIGFueXdheS4gQXMgZmFyIGFz
IEkgdW5kZXJzdGFuZCwgeW91ciBsaW5rIGZvcm1hdA0KZXh0ZW5zaW9uIGNvdWxkIGFkZCBpdGVt
cyB0byBhIGNvcmUtaW50ZXJmYWNlcyBsaW5rZWQgYmF0Y2gsIGFuZCB0aGVuDQpzZXQgYSB2YWx1
ZSBpbiBvbmUgZ287IGZvciB0aGF0LCB0aGUgZXh0ZW5zaW9uIGRhdGEgd291bGQgbmVlZCB0bw0K
cHJlY2VkZSB0aGUgZWxlbWVudHMgaW4gcGFyc2luZy4gT3RoZXIgZXh0ZW5zaW9ucyAoc2F5LCBt
ZXRhZGF0YSBhYm91dA0Kd2hlbiB0byBleHBlY3QgY2hhbmdlcykgbWF5IGJlIHVzZWZ1bCBubyBt
YXR0ZXIgd2hlcmUgaW4gdGhlIGRhdGEgc3RyZWFtDQppdCBhcHBlYXJzLg0KDQpbMV0gaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1pbnRlcmZhY2VzLTA0I3NlY3Rp
b24tNi4yDQoNCkFsc28sIHdoZXJlIGlzIC0wMz8gdGhlcmUgZG9lc27igJl0IHNlZW0gdG8gYmUg
YSB2ZXJzaW9uIC0wMyB0aGF0IHlvdSBhbGwgYXJlIHRhbGtpbmcgYWJvdXQgb24gdGhlIElFVEYg
d2Vic2l0ZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qZW5uaW5ncy1jb3Jl
LXNlbm1sLTA0IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamVubmluZ3MtY29y
ZS1zZW5tbC0wND4NCg0KVGhlIGRhdGEgdHJhY2tlciAob3IgcmF0aGVyIHRvb2xzLmlldGYub3Jn
PGh0dHA6Ly90b29scy5pZXRmLm9yZz4pIHNlZW1zIG5vdCB0byB0YWtlIGRyYWZ0cw0Kc3VibWl0
dGVkIG9uIHRoZSBzYW1lIGRheSB3ZWxsLiBZb3UgY2FuIHZpZXcgaXQgYXMgWzJdLg0KDQpbMl0g
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamVubmluZ3MtY29yZS1zZW5t
bC8wMy8/aW5jbHVkZV90ZXh0PTENCg0KT24gU2F0LCBKYW4gMTYsIDIwMTYgYXQgMDc6MjQ6NDFB
TSAtMDgwMCwgTWljaGFlbCBLb3N0ZXIgd3JvdGU6DQpUaGUgb3B0aW1pemF0aW9ucyB5b3UgcmVj
b21tZW5kIHJlcXVpcmUgYSBuZXcgc3RyaW5nIGlucHV0IHBhcnNlciwNCndoZXJlIEkgYW0gdXNp
bmcgdGhlIEpTT04gcGFyc2VyIHRoYXQgY29tZXMgd2l0aCB0aGUgbGlicmFyeS4gTXkgcG9pbnQN
CndhcyB0aGF0IEkgd2lsbCBuZWVkIHRvIGVpdGhlciBtYWtlIG15IG93biBzdHJpbmcgcGFyc2Vy
IGZvciBTZW5NTCBvcg0KbWFrZSBhIHJlLXBhcnNlciB3aXRoIHRoZSBzdGF0ZSBtYWNoaW5lIEkg
ZGVzY3JpYmVkIGluIG9yZGVyIHRvIHVzZQ0KLTAyICtbLi4uXQ0KDQpJIGRvbid0IHNlZSB5ZXQg
d2hlcmUgdGhlIHN0YXRlIG1hY2hpbmUgY29tZXMgaW4uIFN1cmVseSwgbXVjaA0Kc3RhdGUtbWFj
aGluZ2luIGlzIGdvaW5nIG9uIGluIHRoZSBvcHRpbWl6ZWQgZXhhbXBsZSwgYnV0IHdoZW4gaXQg
Y29tZXMNCnRvIHRoZSBjb3JlIGRpZmZlcmVuY2UgZnJvbSAtMDEgdG8gLTAyLCB0aGF0IGlzLCB0
aGF0DQoNCiAgIHthbnkta2V5LWJ1dC1lOiBhbnktZGF0YSwgImUiOiBlbGVtZW50cy1saXN0fQ0K
DQpiZWNvbWVzDQoNCiAgIFt7YW55LWtleS1idXQtZTogYW55LWRhdGF9LCBlbGVtZW50cy1saXN0
XQ0KDQosIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGlzIG5vdCBjaGFuZ2luZyBhY2Nlc3MgZnJvbSBf
c2VubWxba2V5XSB0bw0KX3Nlbm1sWzBdW2tleV0gb3IgX3Nlbm1sWyJlIl0gdG8gX3Nlbm1sWzFd
Lg0KDQooSWYgaXQncyBhYm91dCB0aGUgQy4gbXVsdGlwbGUtYmFzZS1lbGVtZW50cywgSSdkIGFz
ayB0byBrZWVwIHRoZXNlDQppc3N1ZXMgc2VwYXJhdGUgLS0gaWYgQy4gYnJlYWtzIHRvbyBtdWNo
LCBhbHRob3VnaCBJIGxpa2UgaXQsIHdlIGNvdWxkDQpoYXZlIGEgLTAyIHdpdGggb25seSB0d28g
ZWxlbWVudHMgYW5kIHN0aWxsIHNhdGlzZnkgQi4sIGJ1dCBJIGRvbid0DQp0aGluayB3ZSBuZWVk
IHRvIHJlc29ydCB0byB0aGF0LikNCg0KWy4uLl0gYnV0IHRoZXJlIGlzIGFub3RoZXIgaXNzdWUg
YW55d2F5Og0KDQpPbmUgb2YgdGhlIGJpZyBhZHZhbnRhZ2VzIG9mIHVzaW5nIEpTT04gaXMgY29u
bmVjdGluZyB0aGUgZW1iZWRkZWQNCndvcmxkIHRvIHRoZSB3ZWIgd29ybGQuIFRvIGRvIHRoaXMg
aW4gYSBsb3ctZnJpY3Rpb24gd2F5LCBpdOKAmXMgZ29vZCB0bw0KYmUgYWJsZSB0byB1c2Ugd2Vs
bCBrbm93biB0b29scyBhbmQgcGF0dGVybnMuDQoNCkkgZnVsbHkgYWdyZWUgdGhhdCBlYXN5IHVz
ZSBvZiBlc3RhYmxpc2hlZCB3ZWIgdG9vbHMgaXMgZXNzZW50aWFsIGhlcmU6DQpidXQgdGhlc2Ug
dmVyeSB0aHJlYWRzIGFyZSB3aGVyZSB3ZSBzaG91bGQgY29tZSB1cCB3aXRoIG1lY2hhbmlzbXMg
dGhhdA0Kd29yayBib3RoIHdpdGggdGhlbSBhbmQgY29uc3RyYWluZWQgZGV2aWNlcy4NCg0KDQpU
aGVyZSBpcyBvbmUgcG9pbnQgd2hlcmUgSSB0aGluayB0aGF0IHN0YXRlLW1hY2hpbmluZyBvdmVy
IGluY29taW5nIEpTT04NCm9iamVjdHMgZG9lcyBtYWtlIHNlbnNlLCB0aGF0IGlzIHdoZW4gaXQg
Y29tZXMgdG8gbmFtZXMgLS0gSSBsaWtlIHRvIHNlZQ0KdGhlbSBhcyBVUklzICh0aGF0J3MgY29u
c2lzdGVudCB3aXRoIHRoZSBleGFtcGxlcyBnaXZlbiwgYnV0IG5vdCBmdWxseQ0KcmVxdWlyZWQg
aW4gdGhlIGRyYWZ0cyksIGFuZCB3aGVuIHRoZSAibiIgZWxlbWVudHMgYXJlIHJlbGF0aXZlIFVS
SXMsDQp0aGV5IGFyZSBub3QgdXNlZnVsIHVudGlsIGpvaW5lZCB3aXRoIHRoZSBiYXNlIG5hbWUu
IEJ1dCB0aGF0IGlzIG5vdCBhDQpjaGFuZ2UgaW50cm9kdWNlZCBpbiAtMDEsIGJ1dCBhIHByZWZl
cmVuY2Ugb2YgbWluZSB0aGF0IGlzIHJlZmxlY3RlZCBpbg0KdGhlIGRlbW8gdG8gc2hvdyB0aGF0
IHJlbGF0aXZlIFVSSXMgYXJlIG5vdCB0aGF0IGNvbXBsaWNhdGVkIGV2ZW4gZm9yDQplbWJlZGRl
ZCBzeXN0ZW1zLiAoRXhpc3Rpbmcgd2ViIHRvb2xzIHVzdWFsbHkgaGF2ZSB0aGVpciB3YXlzIG9m
IGpvaW5pbmcNClVSSXMgc2hpcHBlZCkuDQoNCkl0IG1pZ2h0IGJlIGJldHRlciBpZiBzcGVjaWZp
Y2F0aW9uIHdoaWNoIHVzZWQgU2VuTUwgc2FpZCB0aGUgY29tYmluYXRpb24gb2YgYm4rbiBNVVNU
IGJlIGEgVVJJIGFuZCBwZXJoYXBzIGV2ZW4gY29uc3RyYWluIHdoYXQgdHlwZSBvZiBVUkkgYXJl
IE9LLg0KDQoNClRoYW5rcyBhbHNvIGZvciBsb29raW5nIGludG8gbXkgY29kZS4gSSBjb3VsZCBl
YXNpbHkgdXNlIHRoZSAtMDIgb3INCi0wMyBpbiB0aGUgc2VubWwgcHJvY2Vzc2luZyBhcyB5b3Ug
c2hvdy4gV2hhdCBpcyBtaXNzaW5nIHN0aWxsIGZyb20NCmV2ZXJ5dGhpbmcgYWZ0ZXIgLTAxIGlz
IHRoZSBlbGVtZW50IHRhZyB0aGF0IEkgYW0gcmUtdXNpbmcgdG8gaW5kaWNhdGUNCmxpbmtzIGFu
ZCBmb3JtcyBpbiB0aGUgZG9jdW1lbnQ6DQoNCkkgZGlkIHNlZSB0aGF0IHlvdSBoYWQgZXh0ZW5z
aW9ucyBpbiB5b3VyIGNvZGUsIGJ1dCBhcyBDYXJzdGVuDQpzdWdnZXN0ZWQsIHRoZSAibCIgY291
bGQgc3RheSBpbiB0aGUgZmlyc3QgZGljdGlvbmFyeSBhbG9uZ3NpZGUgdGhlICJibiINCmFuZCAi
dmVyIi4gTWF5YmUgdGhlIG5hbWUgImJhc2UgZGljdGlvbmFyeSIgaXMgc3Vib3B0aW1hbCBoZXJl
IC0tIHRoZQ0KZGljdGlvbmFyeSBpdHNlbGYgaXMgbm90IHNvbWV0aGluZyB0aGF0IGdldHMgc29t
ZWhvdyBwcmVmaXhlZCB0byB0aGUNCmZvbGxvd2luZyBlbnRyaWVzLCBpdCdzIGp1c3QgdGhlIHBs
YWNlIHdoZXJlIHRoZSBiYXNlIGF0dHJpYnV0ZXMgcmVzaWRlDQphbG9uZyB3aXRoIG90aGVyIHRo
aW5ncywgbGlrZSAidmVyIiBhbmQgZXh0ZW5zaW9ucy4NCg0KaWYgYW55IG9mIHRoZSBwb3N0IC0w
MSB2ZXJzaW9uIGJyb2tlIHRoZSBhYmlsaXR5IHRvIGFkZCBleHRlbnNpb25zLCB0aGF0IGlzIGp1
c3QgYW4gbWlzdGFrZSBvciBteSBwYXJ0IGFuZCB3ZSBjYW4gZml4IGl0LiBBbGxvd2luZyBKU09O
LUxEIHN0eWxlIGxpbmtzIGluIHRoZSBibiBtYWtlcyBzZW5zZSB0byBtZS4NCg0KDQoNCk9uIFNh
dCwgSmFuIDE2LCAyMDE2IGF0IDA5OjQzOjU1QU0gLTA4MDAsIE1pY2hhZWwgS29zdGVyIHdyb3Rl
Og0KSXQgd291bGQgYmUgdXNlZnVsIGlmIHRoZSBvcmRlciBvZiB0b3AgbGV2ZWwgZWxlbWVudCB0
eXBlcyBjb3VsZCBiZSBhcmJpdHJhcnkgZS5nLjogWyB7fSxbXSxbXSxbXSx7fSxbXSx7fSx7fSAu
Li4gXQ0KDQpUaGF0J3Mgc29tZXRoaW5nIEkgY291bGQgd2VsbCBzZWUgaW4gYSAtMDUuIEl0IHdv
dWxkIGFsc28gbWFrZSBtaW5pbWFsDQpTZW5NTCBmaWxlcyB0aGF0IGRvbid0IHVzZSBhbnkgYmFz
ZSBhdHRyaWJ1dGVzIGEgbGl0dGxlIHNtYWxsZXIsIGFuZA0KZW1iZWRkZWQgcGFyc2luZyB3b3Vs
ZG4ndCBzdWZmZXIgZnJvbSBpdCBBRkFJQ1QuDQoNCkkgbmVlZCB0byBzZW5kIG1vcmUganVzdGlm
aWNhdGlvbiBhYm91dCB0aGlzIHRvIHRoZSBsaXN0IGJ1dCBsb29raW5nIGF0IGNvbW1vbiBKU09O
IHBhcnNlcnMgZm9yIGxhbmd1YWdlcyB0aGF0IGRvIG5vIGFsbG93IHZhcmlhbnQgYXJyYXlzLCBp
dCBzZWVtcyB0aGF0IG1hbnkgb2YgdGhlc2VzIGxpYnJhcmllcyBkb27igJl0IGVhc2lseSBzdXBw
b3J0IEpTT04gd2l0aCBhcnJheSBvZiBkaWZmZXJlbnQgdHlwZXMuDQoNCkZvciBleGFtcGxlIHRo
ZSBnb2xhbmcgSlNPTiBzdHVmZi4gWW91IGNhbiBzZWUgaG93IHRoaXMgd29ya3MgYXQNCg0KaHR0
cHM6Ly9naXRodWIuY29tL2Npc2NvL3Nlbm1sQ2F0L2Jsb2IvbWFzdGVyL3Nlbm1sQ2F0LmdvDQoN
Ck9uIGEgc2lkZSBub3RlLCBzZW5tbENhdCBjYW4gY292ZXJ0IFNlbk1MIHRvIGFuZCBmcm9tIHZh
cmlvdXMgZm9ybWF0cyBhbmQgY2FuIGFsc28gYWN0IGFzIGEgSFRUUCBzZXJ2ZXIgdGhhdCByZWNl
aXZlcyBQT1NUIG9mIFNlbk1MIGFuZCB0aGVuIHdyaXRlcyB0aGVtIGZpbGVzLCBvciBpbmZsdXhk
Yiwgb3Iga2Fma2EuIEkgd291bGQgbm90IGNhbGwgaXQgbW9yZSBhbHBoYSB0aGFuIGRvbmUgYnV0
IGhleSwgc2VuZCBhIHB1bGwgcmVxdWVzdC4gIEkgY291bGQgbm90IHRhbGsgYWJvdXQgc29tZSBv
ZiB0aGUgU2VuTUwgcHJvamVjdCBidXQgaGF2aW5nIHNvbWUgb3BlbiBzb3VyY2UgY29kZSB0byBw
b2ludCBhdCB0aGF0IHdlIGNhbiB0YWxrIGFib3V0IGlzIHVzZWZ1bC4NCg0KSWYgeW91IHBva2Ug
dGhvdWdodCB0aGUgbGlicmFyaWVzIGF0IGh0dHA6Ly93d3cuanNvbi5vcmcvIGZvciBhIGxhbmd1
YWdlIGxpa2UgQywgeW91IGNhbiBzZWUgdGhleSBlaXRoZXIgZG8gbWFsbG9jcyBmb3IgZXZlcnkg
ZWxlbWVudCBpbiB0aGUgbGlzdCAtIHdoaWNoIGdldHMgdmVyeSBzbG93IGNvbXBhcmVkIHRvIHNv
bWV0aGluZyBsaWtlIHByb3RvYnVmIC0gb3IgdGhlIHNjaGVtYSB0ZWxscyB0aGUgc3lzdGVtIHRo
ZSB0eXBlIG9mIGVsZW1lbnQgaW4gdGhlIGFycmF5Lg0KDQpOb3cgY2xlYXJseSBKU09OLCBYTUws
IENCT1IgZXRjIGNhbiBhbGwgc3VwcG9ydCB2YXJpYW50IGFycmF5cy4gQW5kIGNsZWFybHkgaW4g
YW55IGxhbmd1YWdlIHlvdSBjYW4gd3JpdGUgYSBwYXJzZXIgYW5kIGRhdGEgc3RydWN0dXJlIHRo
YXQgYWxsb3dzIHRoZW0gKGV2ZW4gRm9ydHJhbikuIFdlIGFyZSBqdXN0IHRhbGtpbmcgYWJvdXQg
cGVyZm9ybWFuY2UgYW5kIGNvbnZlbmllbmNlICBvZiB1c2luZyB2YXJpYW50IGFycmF5cyBpbiBh
IGxhbmd1YWdlIGxpa2UgQy4gSSB0aGluayBpdCB3b3VsZCB2ZXJ5IG5pY2UgdG8gYmUgYWJsZSB0
byBhdm9pZCB2YXJpYW50IGFycmF5cyBpZiB3ZSBkb27igJl0IG5lZWQgdGhlbS4NCg0KDQoNCk9u
IFNhdCwgSmFuIDE2LCAyMDE2IGF0IDEwOjMzOjAwQU0gLTA4MDAsIE1pY2hhZWwgS29zdGVyIHdy
b3RlOg0KUFMgZm9yIGNvcnJlY3RuZXNzIG15IGV4YW1wbGUgc2hvdWxkIGxvb2sgbW9yZSBsaWtl
IHRoaXM6DQpbDQogew0KICAgImJuIjogIi9saWdodC9icmlnaHRuZXNzIiwNCiAgICJsIjogWyAu
Li4gXSwNCiAgICJmIjogWyAuLi5dLA0KICAgImUiOiBbDQogICAgIHsgIm4iOiAidGJyIiwgInYi
OiAiNDQuMyIsIH0sDQogICAgIHsgIm4iOiAidHQiLCAidiI6ICIxLjAiLCB9DQogICBdDQogfQ0K
XQ0KDQpKdXN0IGxldCdzIHBsZWFzZSBub3QgYWxsb3cgdGhlICJlIiBlbGVtZW50IGFueSBtb3Jl
LiBBbnl0aGluZyB3aXRoIGENCnRvcC1sZXZlbCBhcnJheSBpcyBpbmNvbXBhdGlibGUgd2l0aCBv
bGRlciBkcmFmdCB1c2VycyBhbnl3YXkuDQoNCg0KQmVzdCByZWdhcmRzDQpDaHJpc3RpYW4NCg0K
LS0NCkNocmlzdGlhbiBBbXPDvHNzICAgICAgICAgICAgICAgICAgICAgIHwgRW5lcmd5IEhhcnZl
c3RpbmcgU29sdXRpb25zIEdtYkgNCmZvdW5kZXIsIHN5c3RlbSBhcmNoaXRlY3QgICAgICAgICAg
ICAgfCBoZWFkcXVhcnRlcjoNCm1haWx0bzpjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdCAg
fCBBcmJlaXRlcmdhc3NlIDE1LCBBLTQ0MDAgU3RleXINCnRlbDorNDMtNjY0LTk3LTkwLTYtMzkg
ICAgICAgICAgICAgICAgfCBodHRwOi8vd3d3LmVuZXJneWhhcnZlc3RpbmcuYXQvDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBBVFU2ODQ3NjYxNA0KDQo=

--_000_E149F2E558BC46D7B4AD53CFC0BA3283ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NClRoaXMgbWVzc2FnZSByZWFsbHkgaGVscHMgY2xhcmlmeSB0aGluZ3Mu
IFRoYW5rcy4gTW9yZSBpbmxpbmUmbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSmFuIDE4LCAyMDE2LCBhdCA0
OjA1IEFNLCBDaHJpc3RpYW4gQW1zw7xzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmMuYW1zdWVzc0Bl
bmVyZ3loYXJ2ZXN0aW5nLmF0IiBjbGFzcz0iIj5jLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5h
dDwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds
aW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhlbGxvIE1pY2hhZWwsPGJyIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KaXQgYXBwZWFycyB0aGF0IHRoZXJlIGFyZSB0aHJlZSBj
b25jZXB0cyBib3RoIGJlaW5nIGNhbGxlZCBvciByZWxhdGVkIHRvPGJyIGNsYXNzPSIiPg0KJnF1
b3Q7c3RyZWFtaW5nJnF1b3Q7IHRoYXQgZ2V0IG1peGVkIHVwIGluIHRoaXMgdGhyZWFkLCBJJ2xs
IHRyeSB0byBmbGVzaCB0aGVtIG91dDxiciBjbGFzcz0iIj4NCmZpc3QsIGRlc2NyaWJpbmcgdGhl
aXIgcHVycG9zZSwgc3RhdHVzIG9mIGRyYWZ0cywgYW5kIGludGVyYWN0aW9uIHdpdGg8YnIgY2xh
c3M9IiI+DQpjbGllbnQgYW5kIHNlcnZlciBzaWRlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NCkEuIFRoZSBkcmFmdCBwYXJhZ3JhcGggYWJvdXQgJnF1b3Q7c3RvcmUgb3IgdHJhbnNtaXQg
U2VuTUwgaW4gYSBzdHJlYW0tbGlrZTxiciBjbGFzcz0iIj4NCiZuYnNwO2Zhc2hpb24mcXVvdDsg
aW4gdGhlICZxdW90O011bHRpcGxlIERhdGFwb2ludHMmcXVvdDsgc2VjdGlvbjo8YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDtUaGlzIGlzIG1vcmUgYWJvdXQgdHJhbnNwb3J0YXRp
b24sIGFuZCBpbXBsaWVzIHRoYXQgdGhlcmUgaXMgc29tZSBraW5kPGJyIGNsYXNzPSIiPg0KJm5i
c3A7b2YgYm91bmRhcnkgYmV0d2VlbiBlbGVtZW50cyBhdCB3aGljaCB0cmFuc21pc3Npb24gY2Fu
IHBhdXNlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwO1N1Y2ggYm91bmRhcmll
cyBhcmUgcHJlc2VudCBpbiBhbGwgZHJhZnRzIHNvIGZhci48YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQombmJzcDtJdCBhcHBlYXJzIHRvIG1lIHRoYXQgdGhpcyB3b3VsZCBwcmltYXJpbHkg
d29yayB3aXRoIEhUVFAgaW4gYSBmYXNoaW9uPGJyIGNsYXNzPSIiPg0KJm5ic3A7c2ltaWxhciB0
byBsb25nIHBvbGxpbmcsIHdoaWNoIGlzIHNvbWV0aGluZyBib3RoIGNvbW11bmljYXRpbmcgcGFy
dGllczxiciBjbGFzcz0iIj4NCiZuYnNwO25lZWQgdG8gYmUgYXdhcmUgb2YgKGFsbCBkcmFmdHM6
ICZxdW90O01VU1Qgc3BlY2lmeSB0aGF0IHRoZXkgYXJlIGRvaW5nPGJyIGNsYXNzPSIiPg0KJm5i
c3A7dGhpcyZxdW90OyksIGxlc3QgdGhleSB0aW1lIG91dCB0aGUgY29ubmVjdGlvbi48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCmFncmVlIGFuZCBJIHRoaW5rIGEgZGlmZmVyZW50IG1pbmUgdHlwZSBjYW4gYmUg
dXNlZCBmb3IgYm90aCBzaWRlcyB0byB1bmRlcnN0YW5kIHRoZXkgYXJlIGRvaW5nIHRoaXMuIElu
IHNvbWUgY2FzZXMgdGhlIHN0cmVhbSBtYXkgbmV2ZXIgZW5kIGFuZCB0aGUgSlNPTiB0byBjbG9z
ZSB0aGUgZGF0YSBzdHJ1Y3R1cmVzIHdvdWxkIG5ldmVyIGJlIHNlbnQgc28gYXQgc29tZSBsZXZl
bCBpdOKAmXMgbm90IGV2ZW4gdmFsaWQgSlNPTi48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj48YnIgY2xhc3M9IiI+DQpCLiBCdWZmZXItbGVzcyBvcGVyYXRpb246PGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Rm9yIHZlcnkgc21hbGwgYXBwbGljYXRpb25zIChl
Zy4gdXNpbmcgdUlQIGFuZCBmZXcga0Igb2YgUkFNKSwgaXQgaXM8YnIgY2xhc3M9IiI+DQombmJz
cDtkZXNpcmFibGUgdG8gdXNlIGRhdGEgZm9ybWF0cyB0aGF0IG5ldmVyIHJlcXVpcmUgYmFjay1z
ZWVraW5nLCB0aGF0PGJyIGNsYXNzPSIiPg0KJm5ic3A7bGltaXQgYmFjay1zZWVrcyB0byBhIGZp
eGVkIGxlbmd0aCBvciB0aGF0IGNhbiBkbyB3aXRoIGEgZml4ZWQtbGVuZ3RoPGJyIGNsYXNzPSIi
Pg0KJm5ic3A7YnVmZmVyIHRvIGhvbGQgaW5mb3JtYXRpb24gZm9yIHRoYXQuIFRoZSBzcGVjaWZp
Y2F0aW9uIGRvZXMgbm90IG5lZWQ8YnIgY2xhc3M9IiI+DQombmJzcDt0byBhY3RpdmVseSBkZXNj
cmliZSB0aG9zZSBvcGVyYXRpb25zLCByZXF1aXJpbmcgc29tZSBiYXNpYyBzdHJ1Y3R1cmU8YnIg
Y2xhc3M9IiI+DQombmJzcDtpcyBzdWZmaWNpZW50LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NCiZuYnNwO0l0IGhhcyBiZWVuIHN1Z2dlc3RlZCBlYXJsaWVyIG9uIHRoaXMgbGlzdCB0aGF0
IC0wMSB3aXRoIGFuIGFkZGl0aW9uYWw8YnIgY2xhc3M9IiI+DQombmJzcDtyZXF1aXJlbWVudCB0
aGF0ICZxdW90O2JuJnF1b3Q7IGFuZCAmcXVvdDtidCZxdW90OyB0byBjb21lIGZpcnN0IGluIHRo
ZSBkaWN0aW9uYXJpZXMgd291bGQ8YnIgY2xhc3M9IiI+DQombmJzcDthbGxvdyB0aGlzIG1vZGUg
b2Ygb3BlcmF0aW9uIHRvbyAtLSB0cnV0aCwgYnV0IGhhcmQgdG8gYWNoaWV2ZSB3aXRoPGJyIGNs
YXNzPSIiPg0KJm5ic3A7Z2VuZXJpYyBKU09OIGltcGxlbWVudGF0aW9ucyBhbmQgc2VtYW50aWNz
LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwO1RodXMsIHRoaXMgZ29hbCBpcyBv
bmx5IGFjaGlldmVkIGJ5IGRyYWZ0cyAtMDIgYW5kIGxhdGVyLiAoVGhpcyBpczxiciBjbGFzcz0i
Ij4NCiZuYnNwO2Fsc28gd2hhdCBteSBkZW1vIGlzIGFib3V0LCB3aGljaCBzaG93cyB0aGF0IC0w
MyBpcyBwYXJ0aWN1bGFybHk8YnIgY2xhc3M9IiI+DQombmJzcDtzdWl0YWJsZSkuPGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7VGhhdCB0aGlzIG9ubHkgYW4gaXNzdWUgZm9yIHRo
ZSByZWNlaXZpbmcgc2lkZSAodGhlIHNlbmRlciBpcyBmcmVlPGJyIGNsYXNzPSIiPg0KJm5ic3A7
dG8gY2hvb3NlIGVsZW1lbnQgc2VxdWVuY2VzIGFzIGlzIG1vc3QgcHJhY3RpY2FsIGZvciBpdCBh
bnl3YXksIGFzPGJyIGNsYXNzPSIiPg0KJm5ic3A7bG9uZyBhcyBpdCBmb2xsb3dzIHRoZSBzcGVj
aWZpY2F0aW9uKS4gSGF2aW5nIHRoaXMgbmVnb3RpYWJsZSB3b3VsZDxiciBjbGFzcz0iIj4NCiZu
YnNwO2RlZmVhdCBpdHMgcHVycG9zZTogSWYgcmVjZWl2ZXJzIG1heSByZWx5IG9uIGl0LCB3ZSBj
YW4ndCBhbGxvdzxiciBjbGFzcz0iIj4NCiZuYnNwO3NlbmRlcnMgdG8gbm90IHN1cHBvcnQgaXQu
PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQpJIHRoaW5rIHN1cHBvcnRpbmcgdGhpcyBpcyBpbXBvcnRhbnQuIEl0
4oCZcyBnb29kIGZvciBzbWFsbCB0aGluZ3MgYnV0IGl0IGFsc28gdGVuZHMgdG8gc3VwcG9ydCBz
ZXJ2ZXIgaW1wbGVtZW50YXRpb25zIHRoYXQgYXJlIGxhcmdlIGJ1dCBuZWVkIHRvIGJlIGFibGUg
dG8gcHJvY2VzcyByZWFsbHkgYSBsb3Qgb2YgZGF0YSBxdWlja2x5LiZuYnNwOzwvZGl2Pg0KPGRp
dj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkMuIE11bHRpcGxlIGJhc2Ug
ZWxlbWVudHM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7VGhlIGlkZWEgdG8g
aGF2ZSBtdWx0aXBsZSBiYXNlIGVsZW1lbnRzIGNhbWUgdXAgaW5kZXBlbmRlbnRseSBvZiB0aGU8
YnIgY2xhc3M9IiI+DQombmJzcDtvdGhlcnMsIGFuZCBnaXZlcyBzbWFsbGVyIGRhdGEgc3RyZWFt
cyBmb3IgY2FzZXMgaW4gd2hpY2ggZGlmZmVyZW50PGJyIGNsYXNzPSIiPg0KJm5ic3A7c2Vuc29y
cycgdGltZSBzZXJpZXMgYXJlIHByb2R1Y2VkLCBvciB3aGVuIHRoZXJlIGFyZSBsYXJnZXIgZ2Fw
cyBpbiBhPGJyIGNsYXNzPSIiPg0KJm5ic3A7dGltZWxpbmUuIFRoZSBwcm9wb3NhbCB3b3JrZWQg
d2VsbCB3aXRoIHRoZSBhcnJheS1hcy1yb290IHNjaGVtZTxiciBjbGFzcz0iIj4NCiZuYnNwO2Vu
dmlzaW9uZWQgd2l0aCBleGFjdGx5IDIgZWxlbWVudHMgZm9yIEIuLCBhbmQgd2FzIGltcGxlbWVu
dGVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7dG9nZXRoZXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K
PC9kaXY+DQo8ZGl2PknigJltIHN0YXJ0aW5nIHRvIHRoaW5rIHRoYXQgdGhlIHVzZSBjYXNlIGZv
ciBtdWx0aXBsZSBiYXNlIGVsZW1lbnRzIGlzIHZlcnkgd2VhayBhbmQgdGhhdCBwZXJoYXBzIHdl
IHNob3VsZCBvbmx5IGFsbG93IGEgc2luZ2xlIHNldCBvZiBiYXNlIHVuaXRzIHdoaWNoIGFyZSBi
ZWZvcmUgYW55IG9mIHRoZSBtZWFzdXJlbWVudHMuIElmIHdlIGdldCB0aGlzIGZvciBmcmVlIG9y
IGNoZWFwLCBncmVhdCwgYnV0IG5vdCBzb21ldGhpbmcgSSBjYXJlDQogYSBsb3QgYWJvdXQuJm5i
c3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz
cz0iIj4mbmJzcDtJdCBpcyBwcmVzZW50IGluIC0wMyBhbmQgLTA0LjxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCiZuYnNwO1NlbmRlcnMgYXJlIGZyZWUgbm90IHRvIHVzZSBpdC4gSW4gbXkg
aW1wcmVzc2lvbiwgdGhpcyBpcyBlYXNpbHkgdG88YnIgY2xhc3M9IiI+DQombmJzcDtpbXBsZW1l
bnQgaW4gcmVjZWl2ZXJzLiAoRXZlbiBpZiB0aGV5IGRlc2lyZSB0byBkaXJlY3RseSBhY2Nlc3M8
YnIgY2xhc3M9IiI+DQombmJzcDtpbi1tZW1vcnkgcmVwcmVzZW50YXRpb25zIG9mIEpTT047IHRo
ZSBrZXkgdG8gYW4gZW50cnkgbWlnaHQgdGhlbiBiZTxiciBjbGFzcz0iIj4NCiZuYnNwOyhsaXN0
LW51bWJlciwgbGlzdC1wb3NpdGlvbikgaW5zdGVhZCBvZiBqdXN0IGxpc3QtcG9zaXRpb24pLjxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIGNsYXNzPSIiPlBTIENhbiB3ZSBzdWNjaW5jdGx5IGRlc2NyaWJlIHRoZSB1c2Ug
Y2FzZSBmb3Igb3JkZXJlZCBzZXJpYWw8YnIgY2xhc3M9IiI+DQpwcm9jZXNzaW5nIG9mIHNlbm1s
JiM0Mztqc29uIGVsZW1lbnRzIGJlaW5nIGltcG9ydGFudD8gRnJvbSByZWFkaW5nIHRoZTxiciBj
bGFzcz0iIj4NCmRyYWZ0LCBpdCBzZWVtcyBsaWtlIHRoZSBpbXBvcnRhbnQgYml0IGlzIHNhdmlu
ZyB0aGUgYnVmZmVyIG1lbW9yeSBmb3I8YnIgY2xhc3M9IiI+DQpsYXJnZSByZXNwb25zZXMuIDxi
ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRoZSBvbmUgSSdtIGFy
Z3VpbmcgaGVyZSBpcyBCLiwgdGhlIGJ1ZmZlci1sZXNzIG9wZXJhdGlvbi4gVGhlIHVzZSBjYXNl
PGJyIGNsYXNzPSIiPg0KYXJlIGRldmljZXMgd2l0aCBsaW1pdGVkIGhlYXAgbWVtb3J5IChzYXkg
NGsgZm9yIGluY29taW5nIGFuZCBvdXRnb2luZzxiciBjbGFzcz0iIj4NCnBhY2thZ2VzKS4gSSdt
IHVzaW5nIFNlbk1MIGluIGNvcmUtaW50ZXJmYWNlcyBiYXRjaGVzWzFdIHRvIGdldCBhbmQgc2V0
PGJyIGNsYXNzPSIiPg0KZGV2aWNlIHN0YXRlLiBXaGVuIHRob3NlIGRldmljZXMgYW5ub3VuY2Ug
c3VwcG9ydGluZyBiYXRjaCBvcGVyYXRpb24sPGJyIGNsYXNzPSIiPg0KdGhleSBuZWVkIHRvIGFj
Y2VwdCBTZW5NTCBQVVRzIHRvIGFzIG1hbnkgcmVzb3VyY2VzIGFzIGFyZSBiYXRjaGVkPGJyIGNs
YXNzPSIiPg0KdG9nZXRoZXIsIHNvIGZhciB3aXRob3V0IGFyYml0cmFyeSBjb25zdHJhaW50cy4g
RHVlIHRvIHRoZSBwcm9wb3NlZDxiciBjbGFzcz0iIj4NCmV4dGVuc2liaWxpdHkgb2YgU2VuTUws
IGV2ZW4gaWYgSSBsaW1pdGVkIHRoZSBudW1iZXIgb2YgcmVzb3VyY2VzIGluIGE8YnIgY2xhc3M9
IiI+DQpiYXRjaCwgSSBjb3VsZG4ndCBwcmVkaWN0IHRoZSBtYXhpbXVtIHNpemUgb2YgYW4gaW5j
b21pbmcgdXBkYXRlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vdyB3aGVuIHRoZSB1
cGRhdGUgYXJyaXZlcyBhbmQgYSBTZW5NTCB0aGF0IGRvZXMgbm90IHNhdGlzZnkgQi4gY29tZXM8
YnIgY2xhc3M9IiI+DQppbiwgYWxsIEkgY2FuIGRvIGlzIHRvIHN0b3JlIHRoZSB3aG9sZSBtZXNz
YWdlIGJvZHkgYW5kIHBhcnNlIGl0IHdoZW48YnIgY2xhc3M9IiI+DQp0aGUgbGFzdCBibG9jayBh
cnJpdmVkLiBJZiB0aGUgc2VuZGVyIHVwZGF0ZWQgdG9vIG1hbnkgcmVzb3VyY2VzIG9yIHVzZWQ8
YnIgY2xhc3M9IiI+DQp0b28gbGFyZ2UgZXh0ZW5zaW9ucywgSSdkIG5lZWQgdG8gNC4xMy1SZXF1
ZXN0LUVudGl0eS10b28tbGFyZ2Ugb3V0LjxiciBjbGFzcz0iIj4NClN0aWxsLCB1bnRpbCB0aGVu
IChwYXJ0aWN1bGFybHkgdW50aWwgdGhlIG92ZXJmbG93aW5nIHBhY2thZ2UgYXJyaXZlcyksPGJy
IGNsYXNzPSIiPg0KbWVtb3J5IGlzIGNsb2dnZWQgd2l0aCB1bnBhcnNhYmxlIGRhdGEuPGJyIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+
SXMgaXQgYSBiaWdnZXIgZGVhbCB3aXRoIENCT1IgZW5jb2Rpbmcgb3IgbGVzcyBpbXBvcnRhbnQu
DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpXaGV0aGVyIENC
T1Igb3IgSlNPTiBpcyBiZWluZyBwYXJzZWQgaXMgYWxtb3N0IGlycmVsZXZhbnQgaGVyZS4gVGhl
IG9ubHk8YnIgY2xhc3M9IiI+DQpkaWZmZXJlbmNlIHRoYXQgY29tZXMgdG8gbXkgbWluZCBpcyB0
aGF0IHdpdGggQ0JPUiwgd2UgbWlnaHQgYmUgYWJsZSB0bzxiciBjbGFzcz0iIj4NCnByZXNjcmli
ZSBhIHNlcmlhbGl6YXRpb24gd2hlcmUgJnF1b3Q7Ym4mcXVvdDsgYW5kICZxdW90O2J0JnF1b3Q7
IGFsd2F5cyBwcmVjZWRlICZxdW90O2UmcXVvdDsgZXZlbiBpbjxiciBjbGFzcz0iIj4NCi0wMS1z
dHlsZSwgYnV0IGV2ZW4gdGhhdCB3b3VsZCBtYWtlIGl0IGhhcmRlciB0byB1dGlsaXplIGZvciB3
aG9tZXZlcjxiciBjbGFzcz0iIj4NCmltcGxlbWVudCB0aGlzIHdpdGggYSBuYXRpdmUtb2JqZWN0
LXN0eWxlIGxpYnJhcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSIgY2xhc3M9IiI+SXMgdGhlIG1vc3QgaW1wb3J0YW50IGNvbnNpZGVyYXRpb24g
YmVpbmcgYWJsZSB0byBrbm93IHRoZSBiYXNlIHZhbHVlczxiciBjbGFzcz0iIj4NCmFoZWFkIG9m
IHRoZSBkYXRhPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRo
aXMgaXMgYWJvdXQgYWxsIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIGluIHRoZSBkaWN0aW9uYXJ5
IGFuZCBtb2RpZmllczxiciBjbGFzcz0iIj4NCmhvdyB0byBpbnRlcnByZXQgdGhlIGVsZW1lbnRz
JyBkYXRhLiBJbiBjb3JlIFNlbk1MLCB0aGF0IGluZm9ybWF0aW9uIGlzPGJyIGNsYXNzPSIiPg0K
dGhlIGJhc2UgYXR0cmlidXRlcywgYW5kIHRoZSB2ZXJzaW9uIC0tIHRoYXQgaXMsIGFsbCB0aGUg
cG9zc2libGUgcm9vdDxiciBjbGFzcz0iIj4NCnZhcmlhYmxlcy4gKEluIGEgc2NlbmFyaW8gLik8
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpGb3IgZXh0ZW5zaW9ucywgdGhpcyBjb21wbGV0
ZWx5IGRlcGVuZHMgb24gdGhlbSB1bmxlc3MgdGhlIHJlY2VpdmVyPGJyIGNsYXNzPSIiPg0KY2hv
b3NlcyB0byBpZ25vcmUgdGhlbSBhbnl3YXkuIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHlvdXIg
bGluayBmb3JtYXQ8YnIgY2xhc3M9IiI+DQpleHRlbnNpb24gY291bGQgYWRkIGl0ZW1zIHRvIGEg
Y29yZS1pbnRlcmZhY2VzIGxpbmtlZCBiYXRjaCwgYW5kIHRoZW48YnIgY2xhc3M9IiI+DQpzZXQg
YSB2YWx1ZSBpbiBvbmUgZ287IGZvciB0aGF0LCB0aGUgZXh0ZW5zaW9uIGRhdGEgd291bGQgbmVl
ZCB0bzxiciBjbGFzcz0iIj4NCnByZWNlZGUgdGhlIGVsZW1lbnRzIGluIHBhcnNpbmcuIE90aGVy
IGV4dGVuc2lvbnMgKHNheSwgbWV0YWRhdGEgYWJvdXQ8YnIgY2xhc3M9IiI+DQp3aGVuIHRvIGV4
cGVjdCBjaGFuZ2VzKSBtYXkgYmUgdXNlZnVsIG5vIG1hdHRlciB3aGVyZSBpbiB0aGUgZGF0YSBz
dHJlYW08YnIgY2xhc3M9IiI+DQppdCBhcHBlYXJzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NClsxXSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j
b3JlLWludGVyZmFjZXMtMDQjc2VjdGlvbi02LjIiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1pbnRlcmZhY2VzLTA0I3NlY3Rpb24tNi4yPC9h
PjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs
YXNzPSIiPkFsc28sIHdoZXJlIGlzIC0wMz8gdGhlcmUgZG9lc27igJl0IHNlZW0gdG8gYmUgYSB2
ZXJzaW9uIC0wMyB0aGF0IHlvdSBhbGwgYXJlIHRhbGtpbmcgYWJvdXQgb24gdGhlIElFVEYgd2Vi
c2l0ZTo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtamVubmluZ3MtY29yZS1zZW5tbC0wNCIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWplbm5pbmdzLWNvcmUtc2VubWwtMDQ8L2E+ICZsdDs8YSBocmVmPSJo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamVubmluZ3MtY29yZS1zZW5tbC0wNCIg
Y2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWplbm5pbmdzLWNvcmUt
c2VubWwtMDQ8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0i
Ij4NClRoZSBkYXRhIHRyYWNrZXIgKG9yIHJhdGhlciA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0
Zi5vcmciIGNsYXNzPSIiPnRvb2xzLmlldGYub3JnPC9hPikgc2VlbXMgbm90IHRvIHRha2UgZHJh
ZnRzPGJyIGNsYXNzPSIiPg0Kc3VibWl0dGVkIG9uIHRoZSBzYW1lIGRheSB3ZWxsLiBZb3UgY2Fu
IHZpZXcgaXQgYXMgWzJdLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClsyXSA8YSBocmVm
PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qZW5uaW5ncy1jb3JlLXNl
bm1sLzAzLz9pbmNsdWRlX3RleHQ9MSIgY2xhc3M9IiI+DQpodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1qZW5uaW5ncy1jb3JlLXNlbm1sLzAzLz9pbmNsdWRlX3RleHQ9MTwv
YT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBTYXQsIEphbiAxNiwgMjAxNiBhdCAw
NzoyNDo0MUFNIC0wODAwLCBNaWNoYWVsIEtvc3RlciB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGUgb3B0aW1pemF0aW9ucyB5b3UgcmVjb21t
ZW5kIHJlcXVpcmUgYSBuZXcgc3RyaW5nIGlucHV0IHBhcnNlciw8YnIgY2xhc3M9IiI+DQp3aGVy
ZSBJIGFtIHVzaW5nIHRoZSBKU09OIHBhcnNlciB0aGF0IGNvbWVzIHdpdGggdGhlIGxpYnJhcnku
IE15IHBvaW50PGJyIGNsYXNzPSIiPg0Kd2FzIHRoYXQgSSB3aWxsIG5lZWQgdG8gZWl0aGVyIG1h
a2UgbXkgb3duIHN0cmluZyBwYXJzZXIgZm9yIFNlbk1MIG9yPGJyIGNsYXNzPSIiPg0KbWFrZSBh
IHJlLXBhcnNlciB3aXRoIHRoZSBzdGF0ZSBtYWNoaW5lIEkgZGVzY3JpYmVkIGluIG9yZGVyIHRv
IHVzZTxiciBjbGFzcz0iIj4NCi0wMiAmIzQzO1suLi5dPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1
b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSBkb24ndCBzZWUgeWV0IHdoZXJlIHRoZSBzdGF0ZSBtYWNo
aW5lIGNvbWVzIGluLiBTdXJlbHksIG11Y2g8YnIgY2xhc3M9IiI+DQpzdGF0ZS1tYWNoaW5naW4g
aXMgZ29pbmcgb24gaW4gdGhlIG9wdGltaXplZCBleGFtcGxlLCBidXQgd2hlbiBpdCBjb21lczxi
ciBjbGFzcz0iIj4NCnRvIHRoZSBjb3JlIGRpZmZlcmVuY2UgZnJvbSAtMDEgdG8gLTAyLCB0aGF0
IGlzLCB0aGF0PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7
e2FueS1rZXktYnV0LWU6IGFueS1kYXRhLCAmcXVvdDtlJnF1b3Q7OiBlbGVtZW50cy1saXN0fTxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmJlY29tZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtbe2FueS1rZXktYnV0LWU6IGFueS1kYXRhfSwgZWxl
bWVudHMtbGlzdF08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQosIEkgZG9uJ3Qgc2VlIGhv
dyB0aGlzIGlzIG5vdCBjaGFuZ2luZyBhY2Nlc3MgZnJvbSBfc2VubWxba2V5XSB0bzxiciBjbGFz
cz0iIj4NCl9zZW5tbFswXVtrZXldIG9yIF9zZW5tbFsmcXVvdDtlJnF1b3Q7XSB0byBfc2VubWxb
MV0uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKElmIGl0J3MgYWJvdXQgdGhlIEMuIG11
bHRpcGxlLWJhc2UtZWxlbWVudHMsIEknZCBhc2sgdG8ga2VlcCB0aGVzZTxiciBjbGFzcz0iIj4N
Cmlzc3VlcyBzZXBhcmF0ZSAtLSBpZiBDLiBicmVha3MgdG9vIG11Y2gsIGFsdGhvdWdoIEkgbGlr
ZSBpdCwgd2UgY291bGQ8YnIgY2xhc3M9IiI+DQpoYXZlIGEgLTAyIHdpdGggb25seSB0d28gZWxl
bWVudHMgYW5kIHN0aWxsIHNhdGlzZnkgQi4sIGJ1dCBJIGRvbid0PGJyIGNsYXNzPSIiPg0KdGhp
bmsgd2UgbmVlZCB0byByZXNvcnQgdG8gdGhhdC4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Wy4uLl0gYnV0IHRoZXJlIGlzIGFu
b3RoZXIgaXNzdWUgYW55d2F5OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uZSBvZiB0
aGUgYmlnIGFkdmFudGFnZXMgb2YgdXNpbmcgSlNPTiBpcyBjb25uZWN0aW5nIHRoZSBlbWJlZGRl
ZDxiciBjbGFzcz0iIj4NCndvcmxkIHRvIHRoZSB3ZWIgd29ybGQuIFRvIGRvIHRoaXMgaW4gYSBs
b3ctZnJpY3Rpb24gd2F5LCBpdOKAmXMgZ29vZCB0bzxiciBjbGFzcz0iIj4NCmJlIGFibGUgdG8g
dXNlIHdlbGwga25vd24gdG9vbHMgYW5kIHBhdHRlcm5zLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx
dW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgZnVsbHkgYWdyZWUgdGhhdCBlYXN5IHVzZSBvZiBlc3Rh
Ymxpc2hlZCB3ZWIgdG9vbHMgaXMgZXNzZW50aWFsIGhlcmU6PGJyIGNsYXNzPSIiPg0KYnV0IHRo
ZXNlIHZlcnkgdGhyZWFkcyBhcmUgd2hlcmUgd2Ugc2hvdWxkIGNvbWUgdXAgd2l0aCBtZWNoYW5p
c21zIHRoYXQ8YnIgY2xhc3M9IiI+DQp3b3JrIGJvdGggd2l0aCB0aGVtIGFuZCBjb25zdHJhaW5l
ZCBkZXZpY2VzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRo
ZXJlIGlzIG9uZSBwb2ludCB3aGVyZSBJIHRoaW5rIHRoYXQgc3RhdGUtbWFjaGluaW5nIG92ZXIg
aW5jb21pbmcgSlNPTjxiciBjbGFzcz0iIj4NCm9iamVjdHMgZG9lcyBtYWtlIHNlbnNlLCB0aGF0
IGlzIHdoZW4gaXQgY29tZXMgdG8gbmFtZXMgLS0gSSBsaWtlIHRvIHNlZTxiciBjbGFzcz0iIj4N
CnRoZW0gYXMgVVJJcyAodGhhdCdzIGNvbnNpc3RlbnQgd2l0aCB0aGUgZXhhbXBsZXMgZ2l2ZW4s
IGJ1dCBub3QgZnVsbHk8YnIgY2xhc3M9IiI+DQpyZXF1aXJlZCBpbiB0aGUgZHJhZnRzKSwgYW5k
IHdoZW4gdGhlICZxdW90O24mcXVvdDsgZWxlbWVudHMgYXJlIHJlbGF0aXZlIFVSSXMsPGJyIGNs
YXNzPSIiPg0KdGhleSBhcmUgbm90IHVzZWZ1bCB1bnRpbCBqb2luZWQgd2l0aCB0aGUgYmFzZSBu
YW1lLiBCdXQgdGhhdCBpcyBub3QgYTxiciBjbGFzcz0iIj4NCmNoYW5nZSBpbnRyb2R1Y2VkIGlu
IC0wMSwgYnV0IGEgcHJlZmVyZW5jZSBvZiBtaW5lIHRoYXQgaXMgcmVmbGVjdGVkIGluPGJyIGNs
YXNzPSIiPg0KdGhlIGRlbW8gdG8gc2hvdyB0aGF0IHJlbGF0aXZlIFVSSXMgYXJlIG5vdCB0aGF0
IGNvbXBsaWNhdGVkIGV2ZW4gZm9yPGJyIGNsYXNzPSIiPg0KZW1iZWRkZWQgc3lzdGVtcy4gKEV4
aXN0aW5nIHdlYiB0b29scyB1c3VhbGx5IGhhdmUgdGhlaXIgd2F5cyBvZiBqb2luaW5nPGJyIGNs
YXNzPSIiPg0KVVJJcyBzaGlwcGVkKS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkl0IG1pZ2h0IGJlIGJldHRl
ciBpZiBzcGVjaWZpY2F0aW9uIHdoaWNoIHVzZWQgU2VuTUwgc2FpZCB0aGUgY29tYmluYXRpb24g
b2YgYm4mIzQzO24gTVVTVCBiZSBhIFVSSSBhbmQgcGVyaGFwcyBldmVuIGNvbnN0cmFpbiB3aGF0
IHR5cGUgb2YgVVJJIGFyZSBPSy4gJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5U
aGFua3MgYWxzbyBmb3IgbG9va2luZyBpbnRvIG15IGNvZGUuIEkgY291bGQgZWFzaWx5IHVzZSB0
aGUgLTAyIG9yPGJyIGNsYXNzPSIiPg0KLTAzIGluIHRoZSBzZW5tbCBwcm9jZXNzaW5nIGFzIHlv
dSBzaG93LiBXaGF0IGlzIG1pc3Npbmcgc3RpbGwgZnJvbTxiciBjbGFzcz0iIj4NCmV2ZXJ5dGhp
bmcgYWZ0ZXIgLTAxIGlzIHRoZSBlbGVtZW50IHRhZyB0aGF0IEkgYW0gcmUtdXNpbmcgdG8gaW5k
aWNhdGU8YnIgY2xhc3M9IiI+DQpsaW5rcyBhbmQgZm9ybXMgaW4gdGhlIGRvY3VtZW50OjxiciBj
bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgZGlkIHNlZSB0aGF0IHlv
dSBoYWQgZXh0ZW5zaW9ucyBpbiB5b3VyIGNvZGUsIGJ1dCBhcyBDYXJzdGVuPGJyIGNsYXNzPSIi
Pg0Kc3VnZ2VzdGVkLCB0aGUgJnF1b3Q7bCZxdW90OyBjb3VsZCBzdGF5IGluIHRoZSBmaXJzdCBk
aWN0aW9uYXJ5IGFsb25nc2lkZSB0aGUgJnF1b3Q7Ym4mcXVvdDs8YnIgY2xhc3M9IiI+DQphbmQg
JnF1b3Q7dmVyJnF1b3Q7LiBNYXliZSB0aGUgbmFtZSAmcXVvdDtiYXNlIGRpY3Rpb25hcnkmcXVv
dDsgaXMgc3Vib3B0aW1hbCBoZXJlIC0tIHRoZTxiciBjbGFzcz0iIj4NCmRpY3Rpb25hcnkgaXRz
ZWxmIGlzIG5vdCBzb21ldGhpbmcgdGhhdCBnZXRzIHNvbWVob3cgcHJlZml4ZWQgdG8gdGhlPGJy
IGNsYXNzPSIiPg0KZm9sbG93aW5nIGVudHJpZXMsIGl0J3MganVzdCB0aGUgcGxhY2Ugd2hlcmUg
dGhlIGJhc2UgYXR0cmlidXRlcyByZXNpZGU8YnIgY2xhc3M9IiI+DQphbG9uZyB3aXRoIG90aGVy
IHRoaW5ncywgbGlrZSAmcXVvdDt2ZXImcXVvdDsgYW5kIGV4dGVuc2lvbnMuPGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQppZiBhbnkgb2YgdGhlIHBvc3QgLTAxIHZlcnNpb24gYnJva2UgdGhlIGFiaWxpdHkgdG8g
YWRkIGV4dGVuc2lvbnMsIHRoYXQgaXMganVzdCBhbiBtaXN0YWtlIG9yIG15IHBhcnQgYW5kIHdl
IGNhbiBmaXggaXQuIEFsbG93aW5nIEpTT04tTEQgc3R5bGUgbGlua3MgaW4gdGhlIGJuIG1ha2Vz
IHNlbnNlIHRvIG1lLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIFNhdCwgSmFuIDE2LCAyMDE2IGF0IDA5OjQzOjU1QU0g
LTA4MDAsIE1pY2hhZWwgS29zdGVyIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIGNsYXNzPSIiPkl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB0aGUgb3JkZXIgb2YgdG9w
IGxldmVsIGVsZW1lbnQgdHlwZXMgY291bGQgYmUgYXJiaXRyYXJ5IGUuZy46IFsge30sW10sW10s
W10se30sW10se30se30gLi4uIF08YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh
c3M9IiI+DQpUaGF0J3Mgc29tZXRoaW5nIEkgY291bGQgd2VsbCBzZWUgaW4gYSAtMDUuIEl0IHdv
dWxkIGFsc28gbWFrZSBtaW5pbWFsPGJyIGNsYXNzPSIiPg0KU2VuTUwgZmlsZXMgdGhhdCBkb24n
dCB1c2UgYW55IGJhc2UgYXR0cmlidXRlcyBhIGxpdHRsZSBzbWFsbGVyLCBhbmQ8YnIgY2xhc3M9
IiI+DQplbWJlZGRlZCBwYXJzaW5nIHdvdWxkbid0IHN1ZmZlciBmcm9tIGl0IEFGQUlDVC48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCkkgbmVlZCB0byBzZW5kIG1vcmUganVzdGlmaWNhdGlvbiBhYm91dCB0aGlz
IHRvIHRoZSBsaXN0IGJ1dCBsb29raW5nIGF0IGNvbW1vbiBKU09OIHBhcnNlcnMgZm9yIGxhbmd1
YWdlcyB0aGF0IGRvIG5vIGFsbG93IHZhcmlhbnQgYXJyYXlzLCBpdCBzZWVtcyB0aGF0IG1hbnkg
b2YgdGhlc2VzIGxpYnJhcmllcyBkb27igJl0IGVhc2lseSBzdXBwb3J0IEpTT04gd2l0aCBhcnJh
eSBvZiBkaWZmZXJlbnQgdHlwZXMuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPGRpdj5Gb3IgZXhhbXBsZSB0aGUgZ29sYW5nIEpTT04gc3R1ZmYuIFlvdSBjYW4gc2Vl
IGhvdyB0aGlzIHdvcmtzIGF0Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2
Pg0KPGRpdj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY2lzY28vc2VubWxDYXQvYmxvYi9t
YXN0ZXIvc2VubWxDYXQuZ28iIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9jaXNjby9zZW5t
bENhdC9ibG9iL21hc3Rlci9zZW5tbENhdC5nbzwvYT48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2Pk9uIGEgc2lkZSBub3RlLCBzZW5tbENhdCBjYW4gY292ZXJ0IFNlbk1M
IHRvIGFuZCBmcm9tIHZhcmlvdXMgZm9ybWF0cyBhbmQgY2FuIGFsc28gYWN0IGFzIGEgSFRUUCBz
ZXJ2ZXIgdGhhdCByZWNlaXZlcyBQT1NUIG9mIFNlbk1MIGFuZCB0aGVuIHdyaXRlcyB0aGVtIGZp
bGVzLCBvciBpbmZsdXhkYiwgb3Iga2Fma2EuIEkgd291bGQgbm90IGNhbGwgaXQgbW9yZSBhbHBo
YSB0aGFuIGRvbmUgYnV0IGhleSwgc2VuZCBhIHB1bGwgcmVxdWVzdC4NCiAmbmJzcDtJIGNvdWxk
IG5vdCB0YWxrIGFib3V0IHNvbWUgb2YgdGhlIFNlbk1MIHByb2plY3QgYnV0IGhhdmluZyBzb21l
IG9wZW4gc291cmNlIGNvZGUgdG8gcG9pbnQgYXQgdGhhdCB3ZSBjYW4gdGFsayBhYm91dCBpcyB1
c2VmdWwuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JZiB5
b3UgcG9rZSB0aG91Z2h0IHRoZSBsaWJyYXJpZXMgYXQmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3
Lmpzb24ub3JnLyIgY2xhc3M9IiI+aHR0cDovL3d3dy5qc29uLm9yZy88L2E+Jm5ic3A7Zm9yIGEg
bGFuZ3VhZ2UgbGlrZSBDLCB5b3UgY2FuIHNlZSB0aGV5IGVpdGhlciBkbyBtYWxsb2NzIGZvciBl
dmVyeSBlbGVtZW50IGluIHRoZSBsaXN0IC0gd2hpY2ggZ2V0cyB2ZXJ5IHNsb3cgY29tcGFyZWQg
dG8gc29tZXRoaW5nIGxpa2UgcHJvdG9idWYgLSBvcg0KIHRoZSBzY2hlbWEgdGVsbHMgdGhlIHN5
c3RlbSB0aGUgdHlwZSBvZiBlbGVtZW50IGluIHRoZSBhcnJheS4mbmJzcDs8L2Rpdj4NCjxkaXY+
PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pk5vdyBjbGVhcmx5IEpTT04sIFhNTCwgQ0JPUiBl
dGMgY2FuIGFsbCBzdXBwb3J0IHZhcmlhbnQgYXJyYXlzLiBBbmQgY2xlYXJseSBpbiBhbnkgbGFu
Z3VhZ2UgeW91IGNhbiB3cml0ZSBhIHBhcnNlciBhbmQgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBhbGxv
d3MgdGhlbSAoZXZlbiBGb3J0cmFuKS4gV2UgYXJlIGp1c3QgdGFsa2luZyBhYm91dCBwZXJmb3Jt
YW5jZSBhbmQgY29udmVuaWVuY2UgJm5ic3A7b2YgdXNpbmcgdmFyaWFudCBhcnJheXMgaW4gYSBs
YW5ndWFnZQ0KIGxpa2UgQy4gSSB0aGluayBpdCB3b3VsZCB2ZXJ5IG5pY2UgdG8gYmUgYWJsZSB0
byBhdm9pZCB2YXJpYW50IGFycmF5cyBpZiB3ZSBkb27igJl0IG5lZWQgdGhlbS4mbmJzcDs8L2Rp
dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KT24gU2F0LCBKYW4gMTYsIDIwMTYgYXQgMTA6MzM6MDBBTSAtMDgw
MCwgTWljaGFlbCBLb3N0ZXIgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSIgY2xhc3M9IiI+UFMgZm9yIGNvcnJlY3RuZXNzIG15IGV4YW1wbGUgc2hvdWxkIGxvb2sg
bW9yZSBsaWtlIHRoaXM6PGJyIGNsYXNzPSIiPg0KWyA8YnIgY2xhc3M9IiI+DQombmJzcDt7IDxi
ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2JuJnF1b3Q7OiAmcXVvdDsvbGln
aHQvYnJpZ2h0bmVzcyZxdW90Oyw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmcXVv
dDtsJnF1b3Q7OiBbIC4uLiBdLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZxdW90
O2YmcXVvdDs6IFsgLi4uXSw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtl
JnF1b3Q7OiBbPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7eyAm
cXVvdDtuJnF1b3Q7OiAmcXVvdDt0YnImcXVvdDssICZxdW90O3YmcXVvdDs6ICZxdW90OzQ0LjMm
cXVvdDssIH0sPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7eyAm
cXVvdDtuJnF1b3Q7OiAmcXVvdDt0dCZxdW90OywgJnF1b3Q7diZxdW90OzogJnF1b3Q7MS4wJnF1
b3Q7LCB9PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7XTxiciBjbGFzcz0iIj4NCiZu
YnNwO308YnIgY2xhc3M9IiI+DQpdPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNs
YXNzPSIiPg0KSnVzdCBsZXQncyBwbGVhc2Ugbm90IGFsbG93IHRoZSAmcXVvdDtlJnF1b3Q7IGVs
ZW1lbnQgYW55IG1vcmUuIEFueXRoaW5nIHdpdGggYTxiciBjbGFzcz0iIj4NCnRvcC1sZXZlbCBh
cnJheSBpcyBpbmNvbXBhdGlibGUgd2l0aCBvbGRlciBkcmFmdCB1c2VycyBhbnl3YXkuPGJyIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQmVzdCByZWdhcmRzPGJyIGNs
YXNzPSIiPg0KQ2hyaXN0aWFuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNs
YXNzPSIiPg0KQ2hyaXN0aWFuIEFtc8O8c3MgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBFbmVyZ3kgSGFydmVzdGlu
ZyBTb2x1dGlvbnMgR21iSDxiciBjbGFzcz0iIj4NCmZvdW5kZXIsIHN5c3RlbSBhcmNoaXRlY3Qg
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7fCBoZWFkcXVhcnRlcjo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWls
dG86Yy5hbXN1ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQiIGNsYXNzPSIiPm1haWx0bzpjLmFtc3Vl
c3NAZW5lcmd5aGFydmVzdGluZy5hdDwvYT4gJm5ic3A7fCBBcmJlaXRlcmdhc3NlIDE1LCBBLTQ0
MDAgU3RleXI8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJ0ZWw6JiM0Mzs0My02NjQtOTctOTAtNi0z
OSIgY2xhc3M9IiI+dGVsOiYjNDM7NDMtNjY0LTk3LTkwLTYtMzk8L2E+ICZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwO3wNCjxhIGhyZWY9Imh0dHA6Ly93d3cuZW5lcmd5aGFydmVzdGlu
Zy5hdC8iIGNsYXNzPSIiPmh0dHA6Ly93d3cuZW5lcmd5aGFydmVzdGluZy5hdC88L2E+PGJyIGNs
YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7fCBBVFU2ODQ3NjYxNDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_E149F2E558BC46D7B4AD53CFC0BA3283ciscocom_--


From nobody Mon Jan 25 14:43:49 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74041A1B5D for ; Mon, 25 Jan 2016 14:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level: 
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 RTN61XQU1N6H for ; Mon, 25 Jan 2016 14:43:43 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6963A1A1B46 for ; Mon, 25 Jan 2016 14:43:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 437B0BE3F; Mon, 25 Jan 2016 22:43:41 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4yJnIQGescT; Mon, 25 Jan 2016 22:43:37 +0000 (GMT)
Received: from [10.87.48.91] (unknown [86.46.16.108]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6FB95BE39; Mon, 25 Jan 2016 22:43:36 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453761817; bh=ddlKpoAHuCmI2dxBJqtm9tn8er+IYMOVizYtrgDVH6I=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=r8E4afhMsHsgyAqqR1v5gXy2w3LMvycc7sHIa3NPvGcjEUln3olr7M8GQ5vS5kNRi Di2Mw9w+Gyg3DboHIKDF0nqFxih/BkpIcfQ74sKC6worOA62L3ofmwumFkUbxgGnON 21DWqeQb4kewn7w5R+VU2msoGPKR9GfdujQze6sI=
To: "Cullen Jennings (fluffy)" , =?UTF-8?Q?Christian_Ams=c3=bcss?= , Michael Koster 
References: <20160118110500.GA7789@hephaistos.amsuess.com> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56A6A514.9070105@cs.tcd.ie>
Date: Mon, 25 Jan 2016 22:43:32 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: core 
Subject: [core] privacy issues (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 22:43:48 -0000

I'm willing to take the serious risk of diving at entirely
the wrong place, (and apologies in advance if so;-), but...

[1] seems to be using a MAC address to identify a sensor
reading. Ick. Even if a sensor never moves, that can be
bad if the sensor reading is only emitted as a result of
some privacy-relevant occurrence in the environment. If
a sensor gets carried about then it can be much worse.

I really hope we can provide something better than
such a long-term stable and easily tracked identifier,
even if that requires a bit more work. I don't think
section 13 [2] is really there yet either.

Is there text in some other place that could be
referenced or is this the document that ought define
some way to use identifiers that are less privacy
unfriendly? I do think we (IETF) should somewhere do
the work to define some such identifiers so that the
folks developing sensors and sinks for sensor data
can do a lot better.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-jennings-core-senml-04#section-6.1.2
[2] https://tools.ietf.org/html/draft-jennings-core-senml-04#section-13

On 25/01/16 22:15, Cullen Jennings (fluffy) wrote:
> 
> This message really helps clarify things. Thanks. More inline
> 
> 
> On Jan 18, 2016, at 4:05 AM, Christian Amsüss > wrote:
> 
> Hello Michael,
> 
> it appears that there are three concepts both being called or related to
> "streaming" that get mixed up in this thread, I'll try to flesh them out
> fist, describing their purpose, status of drafts, and interaction with
> client and server side.
> 
> A. The draft paragraph about "store or transmit SenML in a stream-like
>  fashion" in the "Multiple Datapoints" section:
> 
>  This is more about transportation, and implies that there is some kind
>  of boundary between elements at which transmission can pause.
> 
>  Such boundaries are present in all drafts so far.
> 
>  It appears to me that this would primarily work with HTTP in a fashion
>  similar to long polling, which is something both communicating parties
>  need to be aware of (all drafts: "MUST specify that they are doing
>  this"), lest they time out the connection.
> 
> agree and I think a different mine type can be used for both sides to understand they are doing this. In some cases the stream may never end and the JSON to close the data structures would never be sent so at some level it’s not even valid JSON.
> 
> 
> B. Buffer-less operation:
> 
>  For very small applications (eg. using uIP and few kB of RAM), it is
>  desirable to use data formats that never require back-seeking, that
>  limit back-seeks to a fixed length or that can do with a fixed-length
>  buffer to hold information for that. The specification does not need
>  to actively describe those operations, requiring some basic structure
>  is sufficient.
> 
>  It has been suggested earlier on this list that -01 with an additional
>  requirement that "bn" and "bt" to come first in the dictionaries would
>  allow this mode of operation too -- truth, but hard to achieve with
>  generic JSON implementations and semantics.
> 
>  Thus, this goal is only achieved by drafts -02 and later. (This is
>  also what my demo is about, which shows that -03 is particularly
>  suitable).
> 
>  That this only an issue for the receiving side (the sender is free
>  to choose element sequences as is most practical for it anyway, as
>  long as it follows the specification). Having this negotiable would
>  defeat its purpose: If receivers may rely on it, we can't allow
>  senders to not support it.
> 
> I think supporting this is important. It’s good for small things but it also tends to support server implementations that are large but need to be able to process really a lot of data quickly.
> 
> 
> C. Multiple base elements:
> 
>  The idea to have multiple base elements came up independently of the
>  others, and gives smaller data streams for cases in which different
>  sensors' time series are produced, or when there are larger gaps in a
>  timeline. The proposal worked well with the array-as-root scheme
>  envisioned with exactly 2 elements for B., and was implemented
>  together.
> 
> 
> I’m starting to think that the use case for multiple base elements is very weak and that perhaps we should only allow a single set of base units which are before any of the measurements. If we get this for free or cheap, great, but not something I care a lot about.
> 
> 
>  It is present in -03 and -04.
> 
>  Senders are free not to use it. In my impression, this is easily to
>  implement in receivers. (Even if they desire to directly access
>  in-memory representations of JSON; the key to an entry might then be
>  (list-number, list-position) instead of just list-position).
> 
> 
> PS Can we succinctly describe the use case for ordered serial
> processing of senml+json elements being important? From reading the
> draft, it seems like the important bit is saving the buffer memory for
> large responses.
> 
> The one I'm arguing here is B., the buffer-less operation. The use case
> are devices with limited heap memory (say 4k for incoming and outgoing
> packages). I'm using SenML in core-interfaces batches[1] to get and set
> device state. When those devices announce supporting batch operation,
> they need to accept SenML PUTs to as many resources as are batched
> together, so far without arbitrary constraints. Due to the proposed
> extensibility of SenML, even if I limited the number of resources in a
> batch, I couldn't predict the maximum size of an incoming update.
> 
> Now when the update arrives and a SenML that does not satisfy B. comes
> in, all I can do is to store the whole message body and parse it when
> the last block arrived. If the sender updated too many resources or used
> too large extensions, I'd need to 4.13-Request-Entity-too-large out.
> Still, until then (particularly until the overflowing package arrives),
> memory is clogged with unparsable data.
> 
> Is it a bigger deal with CBOR encoding or less important.
> 
> Whether CBOR or JSON is being parsed is almost irrelevant here. The only
> difference that comes to my mind is that with CBOR, we might be able to
> prescribe a serialization where "bn" and "bt" always precede "e" even in
> -01-style, but even that would make it harder to utilize for whomever
> implement this with a native-object-style library.
> 
> Is the most important consideration being able to know the base values
> ahead of the data?
> 
> This is about all information that may be in the dictionary and modifies
> how to interpret the elements' data. In core SenML, that information is
> the base attributes, and the version -- that is, all the possible root
> variables. (In a scenario .)
> 
> For extensions, this completely depends on them unless the receiver
> chooses to ignore them anyway. As far as I understand, your link format
> extension could add items to a core-interfaces linked batch, and then
> set a value in one go; for that, the extension data would need to
> precede the elements in parsing. Other extensions (say, metadata about
> when to expect changes) may be useful no matter where in the data stream
> it appears.
> 
> [1] https://tools.ietf.org/html/draft-ietf-core-interfaces-04#section-6.2
> 
> Also, where is -03? there doesn’t seem to be a version -03 that you all are talking about on the IETF website:
> https://tools.ietf.org/html/draft-jennings-core-senml-04 
> 
> The data tracker (or rather tools.ietf.org) seems not to take drafts
> submitted on the same day well. You can view it as [2].
> 
> [2] https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/?include_text=1
> 
> On Sat, Jan 16, 2016 at 07:24:41AM -0800, Michael Koster wrote:
> The optimizations you recommend require a new string input parser,
> where I am using the JSON parser that comes with the library. My point
> was that I will need to either make my own string parser for SenML or
> make a re-parser with the state machine I described in order to use
> -02 +[...]
> 
> I don't see yet where the state machine comes in. Surely, much
> state-machingin is going on in the optimized example, but when it comes
> to the core difference from -01 to -02, that is, that
> 
>    {any-key-but-e: any-data, "e": elements-list}
> 
> becomes
> 
>    [{any-key-but-e: any-data}, elements-list]
> 
> , I don't see how this is not changing access from _senml[key] to
> _senml[0][key] or _senml["e"] to _senml[1].
> 
> (If it's about the C. multiple-base-elements, I'd ask to keep these
> issues separate -- if C. breaks too much, although I like it, we could
> have a -02 with only two elements and still satisfy B., but I don't
> think we need to resort to that.)
> 
> [...] but there is another issue anyway:
> 
> One of the big advantages of using JSON is connecting the embedded
> world to the web world. To do this in a low-friction way, it’s good to
> be able to use well known tools and patterns.
> 
> I fully agree that easy use of established web tools is essential here:
> but these very threads are where we should come up with mechanisms that
> work both with them and constrained devices.
> 
> 
> There is one point where I think that state-machining over incoming JSON
> objects does make sense, that is when it comes to names -- I like to see
> them as URIs (that's consistent with the examples given, but not fully
> required in the drafts), and when the "n" elements are relative URIs,
> they are not useful until joined with the base name. But that is not a
> change introduced in -01, but a preference of mine that is reflected in
> the demo to show that relative URIs are not that complicated even for
> embedded systems. (Existing web tools usually have their ways of joining
> URIs shipped).
> 
> It might be better if specification which used SenML said the combination of bn+n MUST be a URI and perhaps even constrain what type of URI are OK.
> 
> 
> Thanks also for looking into my code. I could easily use the -02 or
> -03 in the senml processing as you show. What is missing still from
> everything after -01 is the element tag that I am re-using to indicate
> links and forms in the document:
> 
> I did see that you had extensions in your code, but as Carsten
> suggested, the "l" could stay in the first dictionary alongside the "bn"
> and "ver". Maybe the name "base dictionary" is suboptimal here -- the
> dictionary itself is not something that gets somehow prefixed to the
> following entries, it's just the place where the base attributes reside
> along with other things, like "ver" and extensions.
> 
> if any of the post -01 version broke the ability to add extensions, that is just an mistake or my part and we can fix it. Allowing JSON-LD style links in the bn makes sense to me.
> 
> 
> 
> On Sat, Jan 16, 2016 at 09:43:55AM -0800, Michael Koster wrote:
> It would be useful if the order of top level element types could be arbitrary e.g.: [ {},[],[],[],{},[],{},{} ... ]
> 
> That's something I could well see in a -05. It would also make minimal
> SenML files that don't use any base attributes a little smaller, and
> embedded parsing wouldn't suffer from it AFAICT.
> 
> I need to send more justification about this to the list but looking at common JSON parsers for languages that do no allow variant arrays, it seems that many of theses libraries don’t easily support JSON with array of different types.
> 
> For example the golang JSON stuff. You can see how this works at
> 
> https://github.com/cisco/senmlCat/blob/master/senmlCat.go
> 
> On a side note, senmlCat can covert SenML to and from various formats and can also act as a HTTP server that receives POST of SenML and then writes them files, or influxdb, or kafka. I would not call it more alpha than done but hey, send a pull request.  I could not talk about some of the SenML project but having some open source code to point at that we can talk about is useful.
> 
> If you poke thought the libraries at http://www.json.org/ for a language like C, you can see they either do mallocs for every element in the list - which gets very slow compared to something like protobuf - or the schema tells the system the type of element in the array.
> 
> Now clearly JSON, XML, CBOR etc can all support variant arrays. And clearly in any language you can write a parser and data structure that allows them (even Fortran). We are just talking about performance and convenience  of using variant arrays in a language like C. I think it would very nice to be able to avoid variant arrays if we don’t need them.
> 
> 
> 
> On Sat, Jan 16, 2016 at 10:33:00AM -0800, Michael Koster wrote:
> PS for correctness my example should look more like this:
> [
>  {
>    "bn": "/light/brightness",
>    "l": [ ... ],
>    "f": [ ...],
>    "e": [
>      { "n": "tbr", "v": "44.3", },
>      { "n": "tt", "v": "1.0", }
>    ]
>  }
> ]
> 
> Just let's please not allow the "e" element any more. Anything with a
> top-level array is incompatible with older draft users anyway.
> 
> 
> Best regards
> Christian
> 
> --
> Christian Amsüss                      | Energy Harvesting Solutions GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
>                                      | ATU68476614
> 
> 
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> 


From nobody Mon Jan 25 23:35:24 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3DA1A6F59 for ; Mon, 25 Jan 2016 23:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 G2jJFtzDn9lT for ; Mon, 25 Jan 2016 23:35:22 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FF81A6F3B for ; Mon, 25 Jan 2016 23:35:21 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 64B39419D4; Tue, 26 Jan 2016 08:35:18 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A5BD62D; Tue, 26 Jan 2016 08:35:17 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 73CFA55; Tue, 26 Jan 2016 08:35:17 +0100 (CET)
Received: (nullmailer pid 17194 invoked by uid 1000); Tue, 26 Jan 2016 07:35:16 -0000
Date: Tue, 26 Jan 2016 08:35:16 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: "Cullen Jennings (fluffy)" 
Message-ID: <20160126073516.GC7789@hephaistos.amsuess.com>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <56965F8D.9040309@tzi.org> <7B9B6160-3AD4-4637-8430-540B99E6BDA2@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7"
Content-Disposition: inline
In-Reply-To: <7B9B6160-3AD4-4637-8430-540B99E6BDA2@cisco.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 07:35:23 -0000

--oJ71EGRlYNjSvfq7
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 25, 2016 at 10:14:44PM +0000, Cullen Jennings (fluffy) wrote:
> Seems like a good argument for only the first record can have base
> values. Any objections to making that change for next version ?

Not from my side; I'd suggest going as far as forbidding per-item
members in the first record. (Extensions would be free to allow their
members in both a (or the) base object and in item objects).

Best regards
Christian

--=20
Christian Ams=FCss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--oJ71EGRlYNjSvfq7
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWpyG0AAoJEDmNERLTpL3h/pQP/RbpLqIRymmE5Yprrp/Q4Mcn
VgASwS7mnHPdEuJQ1dx3GeLn/7FCyAqjA8yebels06eR94TIbJYNczGYHEqpP7A3
OPuMrUho2MCU12cBCQFyUv89cfKVku7LubVILrHza9NrSiM1JXLwHhbajxGdz2oe
4uUDTfkdgGQm5K5+0XfGJYZYbgmGj9LbpX2u3clpZJbJvCdgbt0iUoYDe7dh7DJA
2UGd7QQC6NKqUPhhP9ibEdGh3IzjxlZyrlWSTaX6o7ntYKUr5sLPzkrJ9XRgmgaO
BRiHyw2eoa81FqKbUHz8b+gZK3VGb1SKdmp2ietnZhwLxj0NB9XeN5nyQMHuBtqT
j9L/tO66Fk240KORDG1wUfWHbf6/sXlHBv9zBJnOIIOLTitMSQFtQnLsj2mua0Jr
5EyfuTmdHn4mhwhS8pSwZSwgCQ2eq1IUiO8XmNMDYrGDE0tffUqgtM1FAKMvD3r2
p9oLtP3kUu72U8T2uGqhITRDnVyLMNFWT5d3dGXvITo+tP82KjHIEdQ8GRQXSXJ6
K8jOQ/tdRNt6A/fV/72hApvQEYW8643MScBf59fFbnQ3k9yw8DuYlYcfU0TwjTWX
S9OT7+QgQ3hjOCzmrsYt7ALb1J501Z88UMrxnrHFGurAB7Yv1OTCMQynRXZQPyxr
YlG1ShcQ/6da1APmIW0G
=5caQ
-----END PGP SIGNATURE-----

--oJ71EGRlYNjSvfq7--


From nobody Tue Jan 26 01:27:06 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8E1A884E for ; Tue, 26 Jan 2016 01:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Level: 
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 rq37CdDvcXDR for ; Tue, 26 Jan 2016 01:27:02 -0800 (PST)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689451A884B for ; Tue, 26 Jan 2016 01:27:02 -0800 (PST)
Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 7E025FB8DD; Tue, 26 Jan 2016 10:27:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Fn39Y8RWdm9b; Tue, 26 Jan 2016 10:26:58 +0100 (CET)
X-Originating-IP: 134.102.218.240
Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9E56EFB930; Tue, 26 Jan 2016 10:26:56 +0100 (CET)
Message-ID: <56A73BE0.1050704@tzi.org>
Date: Tue, 26 Jan 2016 10:26:56 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: =?UTF-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= 
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <56965F8D.9040309@tzi.org> <7B9B6160-3AD4-4637-8430-540B99E6BDA2@cisco.com> <20160126073516.GC7789@hephaistos.amsuess.com>
In-Reply-To: <20160126073516.GC7789@hephaistos.amsuess.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 09:27:04 -0000

That would be a radical simplification, indeed:

senml = [header, * measurement]

header = {
      ? bn: tstr,    ; Base Name
      ? bt: number,  ; Base Time
      ? bu: tstr,    ; Base Units
      ? ver: number, ; Version
      * tstr => any, ; (Extension)
}

measurement = {
      ? n: tstr,     ; Name
      ? u: tstr,     ; Units
      ? v: float,    ; Value
      ? sv: tstr,    ; String Value
      ? bv: bool,    ; Boolean Value
      ? s: float,    ; Value Sum
      ? t: number,   ; Time
      ? ut: number,  ; Update Time
}

Grüße, Carsten


Christian Amsüss wrote:
> On Mon, Jan 25, 2016 at 10:14:44PM +0000, Cullen Jennings (fluffy) wrote:
>> Seems like a good argument for only the first record can have base
>> values. Any objections to making that change for next version ?
> 
> Not from my side; I'd suggest going as far as forbidding per-item
> members in the first record. (Extensions would be free to allow their
> members in both a (or the) base object and in item objects).
> 
> Best regards
> Christian
> 


From nobody Tue Jan 26 04:01:36 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050221B29B6 for ; Tue, 26 Jan 2016 04:01:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3] autolearn=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 KleRPvY6dRiy for ; Tue, 26 Jan 2016 04:01:32 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609D51B29B5 for ; Tue, 26 Jan 2016 04:01:31 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id C565B419D4; Tue, 26 Jan 2016 13:01:29 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 38A132D; Tue, 26 Jan 2016 13:01:27 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 060A655; Tue, 26 Jan 2016 13:01:27 +0100 (CET)
Received: (nullmailer pid 4689 invoked by uid 1000); Tue, 26 Jan 2016 12:01:26 -0000
Date: Tue, 26 Jan 2016 13:01:26 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Michael Koster 
Message-ID: <20160126120126.GD7789@hephaistos.amsuess.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IMjqdzrDRly81ofr"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 12:01:35 -0000

--IMjqdzrDRly81ofr
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 18, 2016 at 09:30:47AM -0800, Michael Koster wrote:
> =E2=80=9Cbn": {"@id": =E2=80=9Csome:baseURI", "@type": "@id"}
> =E2=80=9Cn": {"@id": =E2=80=9Csome:baseURI", "@type": "@id=E2=80=9D}

I think that this is one point where any of the existing SenML drafts
fail to produce meaningful statements for arbitrary SenML documents;
with a context as sketched above, the bn would be ignored completely,
and the value of the event's n would be a concatenation of the document
URI and the n.

After processing this into RDF, there wouldn't even be enough
information left to post-process bn into the names even if that were
somehow more practical than pre-processing the JSON.

Unless we go full JSON-LD by changing "bn" into "@base" in some way, or
JSON-LD is extended to allow something like {"@base":{"@query":
"[0].bn"}} (like xpath for json, no idea if something exists or is
feasible), I don't see how we can have the semantics of SenML
transformed into RDF by JSON-LD.

We could probably describe a subset of SenML that works for a specific
context (for example by completely ruling out bn), but how useful would
that be out in the wild?

(Similar issues exist with the whitespace separated fields in the rt
field in link-format. draft-ietf-core-links-json-04 mentions JSON-LD,
but at the same time makes "[n]o attempt [...] to decode the possibly
space-separated values for rt=3D" -- as long as neither links-json nor
JSON-LD deals with string splitting, we can't have JSON-LD parsing for
generic link-format).


To compare this to RDFa which could probably work with the XML
serialization as JSON-LD could work with the JSON one: To have support
for the HTML base element, RDFa had to specify (X)HTML+RDFa as a "host
language" to cover the base tag -- which basically means that whatever
processes HTML+RDFa needs to do preprocessing.

Unless those issues can be managed in any way, I don't see much point in
engineering the SenML standard towards JSON-LD convertibility. How do
you overcome them in your own applications?

Best regards
Christian

--=20
Christian Ams=C3=BCss                      | Energy Harvesting Solutions Gm=
bH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--IMjqdzrDRly81ofr
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWp2ASAAoJEDmNERLTpL3hMGkP/i3Fz2oKGpE4XAbyozAtW/xx
Qr8u27B+OdK2nCBX0w99lNddhLbCyrmAg5LK7feaLqqAysnzaPqucEwQlrkmHI/l
VXQsymAVBeqOEZBdLuCown+ZAAiti/4pnHa2XILTsW1K4WWI8IoqaSUatd8U1UE5
jgzthD1Fpp1HqjVgFHrEH1XNcKep5kdeDnYsJs1RJ/RNMNexCseQEwxs3NlKW7A4
X/0Q5xYhzJq1+r0WlzFQKFn5zGo+ihjf3Byksc6TZcWrmNFRJkq39h40pDm4hqvI
Z0IrNq3SusYCVgh2StJUbqO6hmEYjmcx5JoEw4DEUcJHp152be9BksxbPhi+/tcb
tIN+2XHisBkVBUJu0X55/6aGPXCmZ0MJsXZhF6qGawwvdXfz+KUFFxZPuN0xVIE1
dz5z5QSyF+5Y9Or/6yuvMv2UQT4jUdPhmXohjfkV50ghPDMEg/R0BNF9QbdQj/BC
xeOy4ip5OVjrkBuDf8rk0YIM3VUdWtDBbYpyIq44JTnuq+2ePjL0di10ct5uPi7J
BxM0PndIC+c413kk37QWjHbuQGZwLkmdPLsk/irI18YDXmqmQZjyTPf5f+FFRlxd
CN/TEUAFg7pXo0MFYW2dC0eTtRejjhmNffmJxy3f+kqEULLAuIZWCskeGSXmIhyT
gXb9/o7vVsn+EeSkSSjW
=GUvI
-----END PGP SIGNATURE-----

--IMjqdzrDRly81ofr--


From nobody Tue Jan 26 05:28:41 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74011A89F0 for ; Tue, 26 Jan 2016 05:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 4dtaEclyE_jw for ; Tue, 26 Jan 2016 05:28:36 -0800 (PST)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 27CD11A89D3 for ; Tue, 26 Jan 2016 05:28:36 -0800 (PST)
Received: by mail-pa0-x232.google.com with SMTP id ho8so97605446pac.2 for ; Tue, 26 Jan 2016 05:28:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cvicYIEp7qGL7AJ9fk6R72/nthKjVeqKLZeymCRLOKE=; b=ekeLedAASLOvSNOt2Of9ThWVReyiBx/RWUUzohVKJRODqIaSxB4eQUxV+EDhwt2Mbm EnBPC6ZhbWSlrA1lf0oeP9FE+keznBz9eFV9ZO+D64eomJI1EB/Z3kkwwRsVDdNj6buO NKNwFLTMyjukvT4lshMqFZxxqIFzcf5sodpdG0zIw1/1AW15UWW+rL3nrNDJOGtE6dM5 ZXn1SpqUOzs6FMxEYAPi3Mv9OSBtrGQITzfutQU51EoyjcN1Y5Bb3zscBN5hGSz1wU1L yhZMPzEhdenoIn87qfQDh4pKh9NnfSoSq0PAs22SO1/LnxzFUWaY22zxiGLaA71CbxBi vVHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=cvicYIEp7qGL7AJ9fk6R72/nthKjVeqKLZeymCRLOKE=; b=McpWPQiM4X5e9sZhN5nb/IAEnlqi2AUselbE2ntPZL1hoNt5tROkZkOYseuxlTSNQq T5Be+a511OWiXFnzuE1uVyR/YsFC0hqpFhlRrgDqLQXPRNMQ64hZqF0sCM98LgHt09A4 Y06wA0wZq0Bvc/ufIrvE6zK3Ey/oE7SvbdazIaPpcCX88TEkkvPdW7yLrlTr/qwWdvXX Q2sUJ+rGnKSMWCKUU8unoZ+qW8kqADPYGKQoWbGpUEGGn1yc7YK8sJr9ujPl0Dz0S5zi UxuXCph6vXGNiYXtaCGu+470ijcxS81kOvQpKU5rBrn/S1aU/kNTKpZ85AjDy88sLVBN iN7Q==
X-Gm-Message-State: AG10YORy6tHGl4L4hxIJJu5+XkkU21j/PTq9C10TqOqXIExMIqqg7DlNjMnyJe76+xUjpQ==
X-Received: by 10.66.119.71 with SMTP id ks7mr7703088pab.151.1453814915755; Tue, 26 Jan 2016 05:28:35 -0800 (PST)
Received: from [172.27.14.129] (58-97-125-4.static.asianet.co.th. [58.97.125.4]) by smtp.gmail.com with ESMTPSA id v86sm1973527pfa.83.2016.01.26.05.28.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 05:28:34 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C7CC2C72-C742-40EC-90B3-7C5840EB5353"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <20160126120126.GD7789@hephaistos.amsuess.com>
Date: Tue, 26 Jan 2016 20:28:31 +0700
Message-Id: 
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 13:28:39 -0000

--Apple-Mail=_C7CC2C72-C742-40EC-90B3-7C5840EB5353
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Christian,

I'm not sure how you expect the document conversion to work, but I used =
a JSON-LD context to transform a SenML-draft-01 format file to semantic =
triples in Nquads using the processor at http://json-ld.org/playground/ =
 . The JSON-LD is simply the SenML file =
with the @context statement inserted after the opening bracket.

The SenML is a representation of an IPSO Smart Object:

{
    "@context" : "http://thingschema.org",
    "bn":"/3303/1/",
    "i":[
    {"n":"5700","v":"31.3","u":"Cel"},
    {"n":"5701","sv":"Cel"},
    {"n":"5602","v":"87.1","u":"Cel"},
    {"n":"5601","v":"18.3","u":"Cel"},
    {"n":"5605"},
    {"n":"5603","v":"0","u":"Cel"},
    {"n":"5604","v":"260","u":"Cel"},
    {"n":"5750","sv":"Inboard Bearing"}
    ],
    "l":[
    {"href":"","rel":"self","rt":"temperature","u":"Cel"},
    {"href":"5700","rt":"currentValue","u":"Cel"},
    {"href":"5701","rt":"units"},
    {"href":"5602","rt":"maxValue","u":"Cel"},
    {"href":"5601","rt":"minValue","u":"Cel"},
    {"href":"5605","rt":"resetMaxMin"},
    {"href":"5603","rt":"minRange","u":"Cel"},
    {"href":"5604","rt":"maxRange","u":"Cel"},
    {"href":"5750","rt":"appType"}
    ]
}

And here are semantic triples generated from the SenML, having used =
http://json-ld.org/playground/  to =
process the elements into RDF subjects, properties, and values and =
serialize into N-quads.

_:b0  "/3303/1/" .
_:b0  _:b1 .
_:b0  _:b2 .
_:b0  _:b3 .
_:b0  _:b4 .
_:b0  _:b5 .
_:b0  _:b6 .
_:b0  _:b7 .
_:b0  _:b8 .
_:b0  _:b10 .
_:b0  _:b11 .
_:b0  _:b12 .
_:b0  _:b13 .
_:b0  _:b14 .
_:b0  _:b15 .
_:b0  _:b16 .
_:b0  _:b17 .
_:b0  _:b9 .

_:b1  "5700" .
_:b1  "Cel" .
_:b1  "31.3" .

_:b10  "5700" .
_:b10  "currentValue" .
_:b10  "Cel" .

_:b11  "5701" .
_:b11  "units" .

_:b12  "5602" .
_:b12  "maxValue" .
_:b12  "Cel" .

_:b13  "5601" .
_:b13  "minValue" .
_:b13  "Cel" .

_:b14  "5605" .
_:b14  "resetMaxMin" .

_:b15  "5603" .
_:b15  "minRange" .
_:b15  "Cel" .

_:b16  "5604" .
_:b16  "maxRange" .
_:b16  "Cel" .

_:b17  "5750" .
_:b17  "appType" .

_:b2  "5701" .
_:b2  "Cel" .

_:b3  "5602" .
_:b3  "Cel" .
_:b3  "87.1" .

_:b4  "5601" .
_:b4  "Cel" .
_:b4  "18.3" .

_:b5  "5605" .
_:b6  "5603" .
_:b6  "Cel" .
_:b6  "0" .

_:b7  "5604" .
_:b7  "Cel" .
_:b7  "260" .

_:b8  "5750" .
_:b8  "Inboard Bearing" .

_:b9  "self" .
_:b9  "" .
_:b9  "temperature" .
_:b9  "Cel" .

I think this result is quite useful to be able to use the information in =
the context of fully qualified references and nodes of triples that =
describe the original SenML.

Best regards,

Michael

> On Jan 26, 2016, at 7:01 PM, Christian Ams=C3=BCss =
 wrote:
>=20
> On Mon, Jan 18, 2016 at 09:30:47AM -0800, Michael Koster wrote:
>> =E2=80=9Cbn": {"@id": =E2=80=9Csome:baseURI", "@type": "@id"}
>> =E2=80=9Cn": {"@id": =E2=80=9Csome:baseURI", "@type": "@id=E2=80=9D}
>=20
> I think that this is one point where any of the existing SenML drafts
> fail to produce meaningful statements for arbitrary SenML documents;
> with a context as sketched above, the bn would be ignored completely,
> and the value of the event's n would be a concatenation of the =
document
> URI and the n.
>=20
> After processing this into RDF, there wouldn't even be enough
> information left to post-process bn into the names even if that were
> somehow more practical than pre-processing the JSON.
>=20
> Unless we go full JSON-LD by changing "bn" into "@base" in some way, =
or
> JSON-LD is extended to allow something like {"@base":{"@query":
> "[0].bn"}} (like xpath for json, no idea if something exists or is
> feasible), I don't see how we can have the semantics of SenML
> transformed into RDF by JSON-LD.
>=20
> We could probably describe a subset of SenML that works for a specific
> context (for example by completely ruling out bn), but how useful =
would
> that be out in the wild?
>=20
> (Similar issues exist with the whitespace separated fields in the rt
> field in link-format. draft-ietf-core-links-json-04 mentions JSON-LD,
> but at the same time makes "[n]o attempt [...] to decode the possibly
> space-separated values for rt=3D" -- as long as neither links-json nor
> JSON-LD deals with string splitting, we can't have JSON-LD parsing for
> generic link-format).
>=20
>=20
> To compare this to RDFa which could probably work with the XML
> serialization as JSON-LD could work with the JSON one: To have support
> for the HTML base element, RDFa had to specify (X)HTML+RDFa as a "host
> language" to cover the base tag -- which basically means that whatever
> processes HTML+RDFa needs to do preprocessing.
>=20
> Unless those issues can be managed in any way, I don't see much point =
in
> engineering the SenML standard towards JSON-LD convertibility. How do
> you overcome them in your own applications?
>=20
> Best regards
> Christian
>=20
> --=20
> Christian Ams=C3=BCss                      | Energy Harvesting =
Solutions GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>                                      | ATU68476614


--Apple-Mail=_C7CC2C72-C742-40EC-90B3-7C5840EB5353
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi Christian,

I'm not sure how you =
expect the document conversion to work, but I used a JSON-LD context to =
transform a SenML-draft-01 format file to semantic triples in Nquads =
using the processor at http://json-ld.org/playground/ . The JSON-LD is =
simply the SenML file with the @context statement inserted after the =
opening bracket.

The SenML is a representation of an IPSO Smart =
Object:

{
    "@context" : "http://thingschema.org",
    "bn":"/3303/1/",
  =
  "i":[
    =
{"n":"5700","v":"31.3","u":"Cel"},
    =
{"n":"5701","sv":"Cel"},
    =
{"n":"5602","v":"87.1","u":"Cel"},
    =
{"n":"5601","v":"18.3","u":"Cel"},
    =
{"n":"5605"},
    =
{"n":"5603","v":"0","u":"Cel"},
    =
{"n":"5604","v":"260","u":"Cel"},
    =
{"n":"5750","sv":"Inboard Bearing"}
    =
],
    "l":[
  =
  {"href":"","rel":"self","rt":"temperature","u":"Cel"},
    =
{"href":"5700","rt":"currentValue","u":"Cel"},
 =
   {"href":"5701","rt":"units"},
    =
{"href":"5602","rt":"maxValue","u":"Cel"},
  =
  {"href":"5601","rt":"minValue","u":"Cel"},
    {"href":"5605","rt":"resetMaxMin"},
    =
{"href":"5603","rt":"minRange","u":"Cel"},
  =
  {"href":"5604","rt":"maxRange","u":"Cel"},
    {"href":"5750","rt":"appType"}
    ]
}

And here are semantic =
triples generated from the SenML, having used http://json-ld.org/playground/ to process the =
elements into RDF subjects, properties, and values and serialize into =
N-quads.

_:b0 =
<http://thingschema.org/schema#baseName> "/3303/1/" =
.
_:b0 <http://thingschema.org/schema#hasItem> _:b1 =
.
_:b0 <http://thingschema.org/schema#hasItem> _:b2 =
.
_:b0 <http://thingschema.org/schema#hasItem> _:b3 =
.
_:b0 <http://thingschema.org/schema#hasItem> _:b4 =
.
_:b0 <http://thingschema.org/schema#hasItem> _:b5 =
.
_:b0 <http://thingschema.org/schema#hasItem> _:b6 =
.
_:b0 <http://thingschema.org/schema#hasItem> _:b7 =
.
_:b0 <http://thingschema.org/schema#hasItem> _:b8 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b10 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b11 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b12 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b13 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b14 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b15 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b16 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b17 =
.
_:b0 <http://thingschema.org/schema#hasLink> _:b9 =
.

_:b1 <http://thingschema.org/schema#resourceName> "5700" =
.
_:b1 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.
_:b1 <http://thingschema.org/schema#value> "31.3" =
.

_:b10 <http://thingschema.org/schema#href> "5700" .
_:b10 <http://thingschema.org/schema#resourceType> =
"currentValue" .
_:b10 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.

_:b11 <http://thingschema.org/schema#href> "5701" .
_:b11 <http://thingschema.org/schema#resourceType> "units" =
.

_:b12 <http://thingschema.org/schema#href> "5602" .
_:b12 <http://thingschema.org/schema#resourceType> "maxValue" =
.
_:b12 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.

_:b13 <http://thingschema.org/schema#href> "5601" .
_:b13 <http://thingschema.org/schema#resourceType> "minValue" =
.
_:b13 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.

_:b14 <http://thingschema.org/schema#href> "5605" .
_:b14 <http://thingschema.org/schema#resourceType> =
"resetMaxMin" .

_:b15 <http://thingschema.org/schema#href> "5603" .
_:b15 <http://thingschema.org/schema#resourceType> "minRange" =
.
_:b15 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.

_:b16 <http://thingschema.org/schema#href> "5604" .
_:b16 <http://thingschema.org/schema#resourceType> "maxRange" =
.
_:b16 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.

_:b17 <http://thingschema.org/schema#href> "5750" .
_:b17 <http://thingschema.org/schema#resourceType> "appType" =
.

_:b2 <http://thingschema.org/schema#resourceName> "5701" =
.
_:b2 <http://thingschema.org/sv> "Cel" .

_:b3 <http://thingschema.org/schema#resourceName> "5602" =
.
_:b3 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.
_:b3 <http://thingschema.org/schema#value> "87.1" =
.

_:b4 <http://thingschema.org/schema#resourceName> "5601" =
.
_:b4 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.
_:b4 <http://thingschema.org/schema#value> "18.3" =
.

_:b5 <http://thingschema.org/schema#resourceName> "5605" =
.
_:b6 <http://thingschema.org/schema#resourceName> "5603" =
.
_:b6 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.
_:b6 <http://thingschema.org/schema#value> "0" .

_:b7 <http://thingschema.org/schema#resourceName> "5604" =
.
_:b7 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.
_:b7 <http://thingschema.org/schema#value> "260" .

_:b8 <http://thingschema.org/schema#resourceName> "5750" =
.
_:b8 <http://thingschema.org/sv> "Inboard Bearing" =
.

_:b9 <http://thingschema.org/rel> "self" .
_:b9 <http://thingschema.org/schema#href> "" .
_:b9 <http://thingschema.org/schema#resourceType> =
"temperature" .
_:b9 <http://thingschema.org/schema#unitsOfMeasure> "Cel" =
.

I think this =
result is quite useful to be able to use the information in the context =
of fully qualified references and nodes of triples that describe the =
original SenML.

Best regards,

Michael

On Jan 26, 2016, at 7:01 PM, Christian Ams=C3=BCss <c.amsuess@energyharvesting.at> wrote:

On Mon, Jan 18, 2016 =
at 09:30:47AM -0800, Michael Koster wrote:
=E2=80=9Cbn": {"@id": =E2=80=9Csome:baseURI", =
"@type": "@id"}
=E2=80=9Cn": {"@id": =E2=80=9Csome:baseURI",=
 "@type": "@id=E2=80=9D}

I =
think that this is one point where any of the existing SenML drafts
fail to produce meaningful statements for arbitrary SenML =
documents;
with a context as sketched above, the bn would =
be ignored completely,
and the value of the event's n =
would be a concatenation of the document
URI and the n.

After processing this into RDF, there wouldn't =
even be enough
information left to post-process bn into =
the names even if that were
somehow more practical than =
pre-processing the JSON.

Unless we go full =
JSON-LD by changing "bn" into "@base" in some way, or
JSON-LD is extended to allow something like =
{"@base":{"@query":
"[0].bn"}} (like xpath for json, no =
idea if something exists or is
feasible), I don't see how =
we can have the semantics of SenML
transformed into RDF by =
JSON-LD.

We could probably describe a =
subset of SenML that works for a specific
context (for =
example by completely ruling out bn), but how useful would
that be out in the wild?

(Similar =
issues exist with the whitespace separated fields in the rt
field in link-format. draft-ietf-core-links-json-04 mentions =
JSON-LD,
but at the same time makes "[n]o attempt [...] to =
decode the possibly
space-separated values for rt=3D" -- =
as long as neither links-json nor
JSON-LD deals with =
string splitting, we can't have JSON-LD parsing for
generic =
link-format).


To compare =
this to RDFa which could probably work with the XML
serialization as JSON-LD could work with the JSON one: To =
have support
for the HTML base element, RDFa had to =
specify (X)HTML+RDFa as a "host
language" to cover the =
base tag -- which basically means that whatever
processes =
HTML+RDFa needs to do preprocessing.

Unless =
those issues can be managed in any way, I don't see much point in
engineering the SenML standard towards JSON-LD =
convertibility. How do
you overcome them in your own =
applications?

Best regards
Christian

-- 
Christian Ams=C3=BCss =
            &n=
bsp;        | Energy Harvesting =
Solutions GmbH
founder, system architect =
            | =
headquarter:
mailto:c.amsuess@energyharvesting.at  | =
Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =
            &n=
bsp;  | http://www.energyharvesting.at/
 =
            &n=
bsp;           &nbs=
p;            =
| ATU68476614

=

--Apple-Mail=_C7CC2C72-C742-40EC-90B3-7C5840EB5353--


From nobody Tue Jan 26 07:11:59 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9A31B2AE0; Tue, 26 Jan 2016 07:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 UlsaAoVxatwS; Tue, 26 Jan 2016 07:11:56 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 4C3631B2AB8; Tue, 26 Jan 2016 07:11:56 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id z14so60753300igp.1; Tue, 26 Jan 2016 07:11:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=fn5kAA/u9WwnmUar1OriKqN4bZ0rCPhhzVq3KFDBTb8=; b=GosuZVRt3ugF8sc8OwfBUXCmJSxWV1pmOUcZkmlO/vMU6fYx/tdX5MtzMyyjnbTdOe 9Rk9unVxcZsECk//UGIhAio3445VZ1wtSw+iZsKHsyGH963sx2Vzl3D5Xnk7JN6dJbw8 s2K7QMkf9t9vztf1IwdrzKm5Fw1vGKDFEBpz/BBAbf3lqpL+h7ilQ+yLlPKHE6wFIIuA trCJIDdDP4vcFKcRm26n83Pn62XrFp6RHiqkpCpzAY8PlW7MYVUEVdJ7pUm380pqV6QK fZgIG9JugICEIPfQp9NKThxApd6lYyxiHX7MSsxpZN1KHAPe/BWJgLxHe1gtSTuFHcd3 yZCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fn5kAA/u9WwnmUar1OriKqN4bZ0rCPhhzVq3KFDBTb8=; b=MjiJAbqo+OIKNYmJLJyUShLgMVcApCA4xPb40NFDlABYtLC6Qy3Iu3nuaP0kpCLoE5 5AySsaV/iiGGTAGfqFKLcNzmc5WqeFyF0A2oM/BTT0DcOE9xTJv74hpf61aN4sMoMuRW l6JeHi7kGp0pBPtISIoAduCfSIFOpYu20dEYS6g2isEFVtbFwdmyhP7098gatVDm7NDs +aieptCKe13rLxRk3wAYP1zL+5kyhXs3rq0rBIPB+fdHpbBCR9YThIzxZX2wsgfse4cd gO6nM/mrYr5EnM4cCY2baI9GYyHhRTT8itb7U+ZMv7OlKbCcyTqmd6qe7CvY0eT4rzeL uHEg==
X-Gm-Message-State: AG10YORovkVPiTP3g85J0+RjniX1/jBvspTILi2dw+4RlncuRWllXiVUJTqZh52JMGC2zxWkmrMTASMHH7SlUA==
MIME-Version: 1.0
X-Received: by 10.50.183.11 with SMTP id ei11mr23671406igc.81.1453821115691; Tue, 26 Jan 2016 07:11:55 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.107.140.65 with HTTP; Tue, 26 Jan 2016 07:11:55 -0800 (PST)
In-Reply-To: <56289F96.1090608@cisco.com>
References: <20151020210304.27062.87223.idtracker@ietfa.amsl.com> <5626AE89.70305@tzi.org> <56289F96.1090608@cisco.com>
Date: Tue, 26 Jan 2016 10:11:55 -0500
X-Google-Sender-Auth: SBY6CNV93HBRLFDJT_TY43nADPw
Message-ID: 
From: Barry Leiba 
To: Benoit Claise 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: core-chairs@ietf.org, The IESG , "core@ietf.org WG" 
Subject: Re: [core] Benoit Claise's Block on charter-ietf-core-01-01: (with BLOCK)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:11:57 -0000

Carsten and CORE working group:
This has been sitting unresolved since October.  Can we wrap this up
now, and get the recharter finished?  I need text changes for Beno=C3=AEt's
block position, and also rewording of the dependency on DICE
(Stephen's comments).

Please put this on the high priority list and let's take care of this
right away.

Thanks,
Barry
---------------------------
Key to reading this:
>>> and > are Beno=C3=AEt; >> are Carsten
---------------------------
On Thu, Oct 22, 2015 at 4:34 AM, Benoit Claise  wrote:
>
>> Hi Benoit,
>>
>> these are indeed useful clarifications.

>>> Two points I would like to discuss.
>>>
>>> - "CoRE will also develop a way to make RESTCONF-style management
>>> functions
>>> available via CoAP that is appropriate for constrained node networks.
>>> This
>>> will require very close coordination with NETCONF and other operations
>>> and
>>> management working groups."
>>>
>>> What is the goal of this coordination with NETCONF?
>>> Could RESTCONF be reused? If not, why not?
>>> If yes, will RESTCONF need to be modified?

>> We want to coordinate with the NETCONF WG to ensure that the result of
>> our work makes sense as a part of the overall NETCONF family.

> Thanks. The coordination objectives should be mentioned in the charter.

>> The basis for COMI is RESTCONF, but there will be a need for some
>> streamlining.

> Can you expand on this, or point to a draft section/email thread.

>> It is not clear whether this will lead to modifications
>> of RESTCONF itself; more likely COMI will just be a dialect that is
>> applicable to very constrained devices.  There are different approaches
>> on the question whether the YANG models have to take some specific care
>> about being used in COMI,

> (I've not been following the core mailing list and I don't know which
> specifics you speak about)
> I hope you will not go that path.
> This would be a failure from an OPS point of view: we need a single YANG
> data model language, and not another data model language. In the end, if
> there are YANG specifics for constrained node networks, then it's a
> different data model language.
> To illustrate my point: shall we see RFC 7223bis, A YANG Data Model for
> Interface Management for constrained networks?
>
> Unless I miss something on the above, this should even mentioned in the c=
ore
> charter.
>
>     CoRE will also develop a way to make RESTCONF-style management
>     functions available, based on YANG, via CoAP that is appropriate for
>     constrained
>     node networks.
>
>     +
>
>     No YANG specifics for constrained nodes network ...

>> or whether COMI covers all kinds of
>> RESTCONF-capable YANG models, possibly with varying degrees of
>> efficiency based on how COMI-aware their design is.

>>> - What is the data model (language) used for the resources? For example=
,
>>> RESTCONF uses YANG

>> YANG.

>>> Maybe, this information is in this paragraph
>>>
>>> CoRE will work on related data formats, such as alternative
>>> representations
>>> of RFC 6690 link format and RFC 7390 group communication information.
>>> The
>>> working group will complete the SenML specification, again with
>>> consideration to its adoption in OMA LWM2M.
>>>
>>> However, I have no clue what the second sentence means.

>> This paragraph is not about management information, but about formats
>> for the actual content data (e.g., SenML is used to represent [time
>> series of] sensor data) and application interaction.

> thanks.
> And LWM2M?
>
> Do we need to expand a bit on those in the charter? I guess so


From nobody Tue Jan 26 08:40:44 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF73F1B30BD for ; Tue, 26 Jan 2016 08:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 NQWXRB6vhqhS for ; Tue, 26 Jan 2016 08:40:40 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749DD1B30AE for ; Tue, 26 Jan 2016 08:40:40 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B2EDE419DE; Tue, 26 Jan 2016 17:40:38 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1B7712D; Tue, 26 Jan 2016 17:40:37 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E1F5455; Tue, 26 Jan 2016 17:40:36 +0100 (CET)
Received: (nullmailer pid 32676 invoked by uid 1000); Tue, 26 Jan 2016 16:40:36 -0000
Date: Tue, 26 Jan 2016 17:40:36 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Michael Koster 
Message-ID: <20160126164036.GE7789@hephaistos.amsuess.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3XA6nns4nE4KvaS/"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 16:40:43 -0000

--3XA6nns4nE4KvaS/
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Michael,

On Tue, Jan 26, 2016 at 08:28:31PM +0700, Michael Koster wrote:
> {
>     "@context" : "http://thingschema.org",
>     "bn":"/3303/1/",
>     "i":[
>     {"n":"5700","v":"31.3","u":"Cel"}, ...
>     ],
>     "l":[
>     {"href":"","rel":"self","rt":"temperature","u":"Cel"},
>     ...

thanks for the example, that's a good starting point to work with.

> And here are semantic triples generated from the SenML, having used
> http://json-ld.org/playground/  to
> process the elements into RDF subjects, properties, and values and
> serialize into N-quads.
>=20
> _:b0  _:b1 .
> _:b0  "/3303/1/" .
> _:b1  "5700" .
> _:b1  "Cel" .
> _:b1  "31.3" .
> _:b10  "5700" .
> _:b10  "currentValue" .
> _:b10  "Cel" .

These are quads that contain the information of the SenML, but not
really in an RDFish way.

RDF is all about using URIs to describe things. What I'd expect of such
a conversion when done right would be N-triples like

_:b1   .
_:b1  "31.3"^^xsd:float .
_:b1  "Cel" .
  "currentValue" .
  "Cel" .

where statements are made about actual resources. _b:1 would still be a
blank node, because it reflects a single description of the resource's
state (were it a time series, the necessity for that would be more
obvious). A converter might want to even emit a statement like

_:b1   .

to make that clear.

The output produced by the thingschema.org still reads a little like a
combination of text fragments; to compare it with relational databases,
it looks to me as if there were no foreign keys in use yet, and
everything were stored in text fields. The output is RDF, but it can't
effectively be used as RDF yet.

> I think this result is quite useful to be able to use the information
> in the context of fully qualified references and nodes of triples that
> describe the original SenML.

I do not understand what you mean by this, could you elaborate? AFAICT,
were I fed the N-quad output from above, I couldn't even establish any
relationship between the "/3303/1/" URI fragment and the "5700", let
alone use that in a query about .


There are things brewing at W3C's Web of Things initiative[1], there has
for some time been work on semantically connected IoT devices[2], and I
am confident that RDF metadata are the way to go.

But both with a SenML that looks anything like the drafts so far and
with draft-ietf-core-links-json, I think that JSON-LD does not have what
it takes to produce the meaning of the respective JSON representations
for the semantic web.

I've long ago asked on this list about a canonical RDF representation of
a link-format resource. Back then, there was nothing, and I had only a
rough idea of what I'd need as well. I'd be all in for going ahead here
and sketching up what a generic link-format document would look like in
an RDF representation, and possibly SenML as well; that should be a
separate discussion, though, and not deeply interfere with the SenML
process itself. I could sketch up some parts that've been brewing with
me and are partially implemented as well -- would that be suitable for
this list?


Best regards
Christian

[1] http://www.w3.org/WoT/
[2] https://iotdb.org/

--=20
Christian Ams=FCss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--3XA6nns4nE4KvaS/
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWp6GBAAoJEDmNERLTpL3hPPYP/1Perqr+oonHa+oMtO7JKwmN
tAbRL/mub3tV6Wj9edGO90u5jdN3n9Mb7dqGcL47BqQ6q+770TmlXfCPxEfgYPi1
r53WvEWedTwv9sL3mzf7SS8vsfjmebo7nDdA6K09IZeDy3owTViqcR3DeFT8QWug
3PzowEwQbBgj6bFUQtwSY+JDutrXtFqx81vhrsCeAljWOvbMCwp4zksoSEXus10C
mY1MgCniZXlVr/duV8Vb11mBQBcVFn/yFXRScuR+8m7h95sdw00OzepuOr2o4XfL
RUVjBt8DtR1qbrz1geKn+EpSf60n1pvNgN7FvL37OzrGukf7GCCWY1d01aE4pZTP
1o5DWCCJYQAXo76vprQILZwauS5n8Qi8mHS2BzV74PF1YbmjZab5/pVytd8T+b7z
9iF+0v10iCopb1gC7tjDZO4c+V1XjFp0UtH9RQX1qIWQERooQDscLy/Ow6s3BbPx
cbE/6VZpwzRCF0dzEzgoOu3cnnLf27e6itCcIEscb7svpoJEZ0BI7CZ98v6tFaIY
PS1KF1teuDhYfoOB1MI7Fx0w85a8oHghz/04JWsY1N19hywpxejA9DguF4yuQZGK
v3DkCJTYVzXVFOBu/2tphyvlbDd7EhkdKDVSKLspt3GUwh/ATOc0z+2h2sSZ5Oe+
S20SIyELjVKVgAALD/xN
=ODoR
-----END PGP SIGNATURE-----

--3XA6nns4nE4KvaS/--


From nobody Tue Jan 26 12:22:05 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220BC1B2CCB for ; Tue, 26 Jan 2016 12:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 IOrIbzpaUkVR for ; Tue, 26 Jan 2016 12:22:02 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 6592F1B2CD8 for ; Tue, 26 Jan 2016 12:22:02 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id e65so104698722pfe.0 for ; Tue, 26 Jan 2016 12:22:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vgS163z+3/pGCW9t5czCA4t1HNu9C8x6+DLpVKVYIhs=; b=T7HmuLq7A+lQKCxBGMHakZgECm8hFXJMXUR53AdBxbXmoxkCi4/MlsTbrCXw3HA7Bi vlZKM/m8s2Oo+nVI0bbYRhHt/zCbPk7tzXRtW7mWgn8ZU9owXVwtlHc76oyKOIA+Vnzt eERzXwj4yMwh+sx3fEYIrAXqnyQiD89MzH5LX/C1Ej7u/owIE/57kO5xxUmmrFlxv9no GPspl/ggNRy2udvq4tXc411ushFQhOEdQj188J5q3/on6zlXwsLFbdT+o5Dd7xuLUBN7 DQeD3Fl21Jpz/RbW6uzZ7qIq61r2HECg4kxb2ydj9BYTWUkDSQdN3a5rQYdzZN5CUvUj Zo3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vgS163z+3/pGCW9t5czCA4t1HNu9C8x6+DLpVKVYIhs=; b=fMJpt4xKJ3QnF6X/SWlLSilkVxvy07xvS8nhWBuTu7A8/VB0mRAP0UvLdXiRNlDweu R6dsw76aZvgbsWyu/VyNpSrdNw8Q2ZpaI6N/IfKRD1pUF4PTQryCyNOke9vbhIt2Hcgc RZOy+qDkz0M09esFTfXlnL2gLJUGB9ZxKcMeJx3qO4Okrv9BCARONRrajd8g2NTuUyIa ctzRIAyYT9av1+J5syYtB+n3ntnM9uA7vOtqC3xVw26+J4HGwk95EgZMy/CAczswIKOQ yu9VDnatYdNVY3IxnmAM/llZZMO/dT3A9ZvrNJ/rL+V76KeDvYcYKs0A8l2htcyDRcbu T8fQ==
X-Gm-Message-State: AG10YOSA93DgVea/PYM2WteOpz0sglu/5y/PR0/jSzFA8WF+ZTBqimqblzu50HF4pphCUQ==
X-Received: by 10.98.74.9 with SMTP id x9mr36847503pfa.14.1453839722022; Tue, 26 Jan 2016 12:22:02 -0800 (PST)
Received: from [172.27.14.129] (58-97-125-4.static.asianet.co.th. [58.97.125.4]) by smtp.gmail.com with ESMTPSA id g87sm3765342pfj.1.2016.01.26.12.22.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 12:22:01 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <20160126164036.GE7789@hephaistos.amsuess.com>
Date: Wed, 27 Jan 2016 03:21:58 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com>  <20160126164036.GE7789@hephaistos.amsuess.com>
To: =?iso-8859-1?Q?Christian_Ams=FCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 20:22:04 -0000

> On Jan 26, 2016, at 11:40 PM, Christian Ams=FCss =
 wrote:
>=20
> Hi Michael,
>=20
> On Tue, Jan 26, 2016 at 08:28:31PM +0700, Michael Koster wrote:
>> {
>>    "@context" : "http://thingschema.org",
>>    "bn":"/3303/1/",
>>    "i":[
>>    {"n":"5700","v":"31.3","u":"Cel"}, ...
>>    ],
>>    "l":[
>>    {"href":"","rel":"self","rt":"temperature","u":"Cel"},
>>    ...
>=20
> thanks for the example, that's a good starting point to work with.
>=20
>> And here are semantic triples generated from the SenML, having used
>> http://json-ld.org/playground/  to
>> process the elements into RDF subjects, properties, and values and
>> serialize into N-quads.
>>=20
>> _:b0  _:b1 .
>> _:b0  "/3303/1/" .
>> _:b1  "5700" .
>> _:b1  "Cel" .
>> _:b1  "31.3" .
>> _:b10  "5700" .
>> _:b10  "currentValue" .
>> _:b10  "Cel" .
>=20
> These are quads that contain the information of the SenML, but not
> really in an RDFish way.
>=20
> RDF is all about using URIs to describe things. What I'd expect of =
such
> a conversion when done right would be N-triples like
>=20
> _:b1   .
> _:b1  "31.3"^^xsd:float .
> _:b1  "Cel" .
>   =
"currentValue" .
>   "Cel" .
>=20
Hmm so I can't know from the schema that baseName and href are =
concatenated to form /3303/1/5700?
That seems to be all that's missing.

> where statements are made about actual resources. _b:1 would still be =
a
> blank node, because it reflects a single description of the resource's
> state (were it a time series, the necessity for that would be more
> obvious). A converter might want to even emit a statement like
>=20
> _:b1  =
 .
>=20
> to make that clear.
>=20
> The output produced by the thingschema.org still reads a little like a
> combination of text fragments; to compare it with relational =
databases,
> it looks to me as if there were no foreign keys in use yet, and
> everything were stored in text fields. The output is RDF, but it can't
> effectively be used as RDF yet.
>=20
>> I think this result is quite useful to be able to use the information
>> in the context of fully qualified references and nodes of triples =
that
>> describe the original SenML.
>=20
> I do not understand what you mean by this, could you elaborate? =
AFAICT,
> were I fed the N-quad output from above, I couldn't even establish any
> relationship between the "/3303/1/" URI fragment and the "5700", let
> alone use that in a query about .
>=20
>=20
> There are things brewing at W3C's Web of Things initiative[1], there =
has
> for some time been work on semantically connected IoT devices[2], and =
I
> am confident that RDF metadata are the way to go.
>=20
> But both with a SenML that looks anything like the drafts so far and
> with draft-ietf-core-links-json, I think that JSON-LD does not have =
what
> it takes to produce the meaning of the respective JSON representations
> for the semantic web.
>=20
> I've long ago asked on this list about a canonical RDF representation =
of
> a link-format resource. Back then, there was nothing, and I had only a
> rough idea of what I'd need as well. I'd be all in for going ahead =
here
> and sketching up what a generic link-format document would look like =
in
> an RDF representation, and possibly SenML as well; that should be a
> separate discussion, though, and not deeply interfere with the SenML
> process itself. I could sketch up some parts that've been brewing with
> me and are partially implemented as well -- would that be suitable for
> this list?
>=20
>=20
> Best regards
> Christian
>=20
> [1] http://www.w3.org/WoT/
> [2] https://iotdb.org/
>=20
> --=20
> Christian Ams=FCss                      | Energy Harvesting Solutions =
GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>                                      | ATU68476614


From nobody Tue Jan 26 23:05:28 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D58D1B29F3 for ; Tue, 26 Jan 2016 23:05:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 pVCblRBitlIw for ; Tue, 26 Jan 2016 23:05:25 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7E21B2A12 for ; Tue, 26 Jan 2016 23:05:24 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 274FB419F7; Wed, 27 Jan 2016 08:05:23 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 783B72D; Wed, 27 Jan 2016 08:05:21 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8A25F2E; Wed, 27 Jan 2016 08:05:20 +0100 (CET)
Received: (nullmailer pid 29191 invoked by uid 1000); Wed, 27 Jan 2016 07:05:19 -0000
Date: Wed, 27 Jan 2016 08:05:19 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Michael Koster 
Message-ID: <20160127070519.GF7789@hephaistos.amsuess.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com>  <20160126164036.GE7789@hephaistos.amsuess.com> <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6v9BRtpmy+umdQlo"
Content-Disposition: inline
In-Reply-To: <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 07:05:27 -0000

--6v9BRtpmy+umdQlo
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 27, 2016 at 03:21:58AM +0700, Michael Koster wrote:
> Hmm so I can't know from the schema that baseName and href are concatenat=
ed to form /3303/1/5700?

For all I know, no, neither in the JSON-LD step (because "@base" can be
only a single string and not some JSON-path), nor at the RDF step (if
there were a trick to synthesize the statements, I don't think that most
tools could use them).

> That seems to be all that's missing.

That, and string splitting (when it comes to parsing the "l" entries'
"rt" attributes).

They are annoyingly small details, but unless JSON-LD can be extended to
be more XSLT-like, I think they are show stoppers here.

Best regards
Christian

--=20
Christian Ams=FCss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--6v9BRtpmy+umdQlo
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWqGwqAAoJEDmNERLTpL3hv/gP/1Sph9BbAjYp9aeffqUHKyoC
+4qRvF6Wmf1S3CWo37knvp7jYJEyJ43VBTq5cna3Fj1VJGLcUubgMKKLPlKHY/ut
i9nhEzZwtGsMhmljRRoQhOzIx9yjMRY3gClYSdNLpmx0IGmprD7hwpijiVVvN3ak
dNrqwZVTk1is8hOLjDi7T+DY96odep5pBvRhhTk1Q7y4CPVr7I8ewD1FG/jUGS/6
tVpjWhisDb+/SKKXgDxP9XW8BWIK8bijsSKM5i65f5hC6z3YmmGA4dC83NnuM0Bi
KdQV6mkL7TCd3hI6DRCe8GWqv25Cyt55HjD6JDHyzdwiO/ve09zixMyawHBvznSK
N5j5p/Z57Fbc3F0W7p9de8RL2zVf6NozEAnnx81Y3fKRe7xi9ipunIragIN92DR0
NRPkNKBwXA4hDKINUwZdlAVoKHzJ4B9Rz2u6v7B5Da3dIUxbMQdKd0XlM3SaArTs
wqoaU0tHJnPekKD+BAMqQeb6keQlTMA3ngWH6tixv60ZVy0DdA0ObjCSQAGRDeMt
if+eb2DMDZHvQP/h3KbRtimotXYj3hn7Dq+pmWmyDtcCYl8qBrm/UZaUDse9cpj5
fpUI3P4WFN7iuLTNC0nMEHyOjX7GDoGg9tEWoBVc2YXn+/DudmEuYwWkWjQHyM4V
Tr28f+OjZsV3NL2TQdBa
=6upy
-----END PGP SIGNATURE-----

--6v9BRtpmy+umdQlo--


From nobody Tue Jan 26 23:32:22 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0441B3518 for ; Tue, 26 Jan 2016 23:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 XmAtayWznJps for ; Tue, 26 Jan 2016 23:32:20 -0800 (PST)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 7EB351B3515 for ; Tue, 26 Jan 2016 23:32:20 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id n128so317577pfn.3 for ; Tue, 26 Jan 2016 23:32:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hBrC734mkAd0/bycW/vqKje/aDCiyyztXalwE0bMtyA=; b=kH/OC9YhuMk9IUEBLl/QLnlgRWUc5mAvTGYM2DzUvn4Fda0uK7iconqmcOmaTMV9x2 WqwcPt+Wx+PjUsI6Pbffo6i3SDADUjK6JA+CBHoxsr3X4ZBxC5bZqYE5OMqsDCRo7SZX lCukS4XumO/iNXFqqxPZa9ds8qPFwlAvs2A3hr8yX3eGnFelq97Myq6QZpWKkAtobg3N +xmrEnYTD4MvlPmyIQwhxVpUKQnJCSaKYYMOhyaYzNwqQIStgtzVfNt+C3jliRrQoTBF D6+0vZIg0zsGXWI5JVpdGLlp+F9GiFcVNJOqFG7gFrzOFBe/ifdYQ85YizYPmZ7CLFuR kGXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hBrC734mkAd0/bycW/vqKje/aDCiyyztXalwE0bMtyA=; b=EG74ra9CTWgjUbc0ISXQT5ClnYcURIV14t882cSCLA3WLVS8JPW37XinCr//MK4Iiu gve+mtNp4HaylXIdqUdd/bKDksyEvSicQtypqKdKga1r025mwpn0djHmrnCbkUtGd8t1 xFwZXdPSqNXs+HdX5dNRhy6ROa1jH0SAvyx3/tvIujKizaUMBjjZY5V5GXeoBpPNN/bG F3pbZBRoKm5AbhgN84CJG0lXC7Zb2dHNujn7eYlJnBcjmWqOeGbKJR6M8eTMWTMyhR/P AaFSMAlpmyD8k5M5un9UP2+VLEOcjq5EEvqb8PTdSwHn+Tk3aBtWwmzmmKAB6wkZF4Pt +N8A==
X-Gm-Message-State: AG10YOTv6UCrGnM2MXCYrOqAXqQ5UAgJlQNUGuETQj4sjTTRPBhTzI6uisLnTyW90ek+mQ==
X-Received: by 10.98.31.8 with SMTP id f8mr39702998pff.71.1453879940114; Tue, 26 Jan 2016 23:32:20 -0800 (PST)
Received: from [172.27.14.129] (58-97-125-4.static.asianet.co.th. [58.97.125.4]) by smtp.gmail.com with ESMTPSA id v2sm6476505pfi.93.2016.01.26.23.32.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 23:32:19 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <20160127070519.GF7789@hephaistos.amsuess.com>
Date: Wed, 27 Jan 2016 14:32:15 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CD6395A-0B3B-4C48-B173-14FF8A90C2F0@gmail.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com>  <20160126164036.GE7789@hephaistos.amsuess.com> <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com> <20160127070519.GF7789@hephaistos.amsuess.com>
To: =?iso-8859-1?Q?Christian_Ams=FCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 07:32:21 -0000

> On Jan 27, 2016, at 2:05 PM, Christian Ams=FCss =
 wrote:
>=20
> On Wed, Jan 27, 2016 at 03:21:58AM +0700, Michael Koster wrote:
>> Hmm so I can't know from the schema that baseName and href are =
concatenated to form /3303/1/5700?
>=20
> For all I know, no, neither in the JSON-LD step (because "@base" can =
be
> only a single string and not some JSON-path), nor at the RDF step (if
> there were a trick to synthesize the statements, I don't think that =
most
> tools could use them).
>=20
>> That seems to be all that's missing.
>=20
> That, and string splitting (when it comes to parsing the "l" entries'
> "rt" attributes).
>=20
I don't see where any string splitting is needed. The "l" entries are =
all JSON parseable, as are the rt attribute values.

> They are annoyingly small details, but unless JSON-LD can be extended =
to
> be more XSLT-like, I think they are show stoppers here.
>=20
> Best regards
> Christian
>=20
> --=20
> Christian Ams=FCss                      | Energy Harvesting Solutions =
GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>                                      | ATU68476614


From nobody Wed Jan 27 00:19:49 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210CA1B35DD for ; Wed, 27 Jan 2016 00:19:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, WEIRD_QUOTING=0.001] autolearn=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 xKVr_cHby5Z9 for ; Wed, 27 Jan 2016 00:19:46 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAC01B35DC for ; Wed, 27 Jan 2016 00:19:45 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9E312419FF; Wed, 27 Jan 2016 09:19:43 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 952DD2D; Wed, 27 Jan 2016 09:19:42 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 68D1F2E; Wed, 27 Jan 2016 09:19:42 +0100 (CET)
Received: (nullmailer pid 32680 invoked by uid 1000); Wed, 27 Jan 2016 08:19:41 -0000
Date: Wed, 27 Jan 2016 09:19:41 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Michael Koster 
Message-ID: <20160127081941.GY7454@hephaistos.amsuess.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com>  <20160126164036.GE7789@hephaistos.amsuess.com> <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com> <20160127070519.GF7789@hephaistos.amsuess.com> <2CD6395A-0B3B-4C48-B173-14FF8A90C2F0@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mFWIsQnH1d6uRhsN"
Content-Disposition: inline
In-Reply-To: <2CD6395A-0B3B-4C48-B173-14FF8A90C2F0@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 08:19:48 -0000

--mFWIsQnH1d6uRhsN
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 27, 2016 at 02:32:15PM +0700, Michael Koster wrote:
> > That, and string splitting (when it comes to parsing the "l" entries'
> > "rt" attributes).
>
> I don't see where any string splitting is needed. The "l" entries are all=
 JSON parseable, as are the rt attribute values.

The rt and if attributes of application/link-format requires that all
resource types assigned to a resource be stored in a single rt=3D""/if=3D""
attribute in a space separated fashion (rfc6690 3.1, as is also the case
for rel per rfc5988), and draft-ietf-core-links-json-04 makes no attempt
to split those up (2.2).

If resource types were to be used in a way they can be queried in an RDF
context, the statements produced from ;if=3D"core.s some.delayable"
should at least contain[1]

   .
   .

because a statement like

  "core.s some.delayable" .

would again mean shifting the load of string parsing into the RDF
domain, where the expectation is that reasoning can be done based on URI
metadata and not on string parsing. (Again, the analogy of the
relational database comes into my mind: You wouldn't want to have
resource types you'll query for in a space-separated text field of a
database).

Also, again drawing the parallel to RDFa, when this HTML document
test.html is parsed as RDFa (eg. using the rapper tool that is aware of
the registered describedby relationship)



then the resulting statements are

<./test.html> <./unspecified> <./next-address> .
<./test.html>  .
<./test.html>  <./next-addr=
ess> .


Best regards
Christian


[1] If it turns out that JSON-LD is unsuitable for this task anyway, as
I have the impression which I'm trying to convey, then I'd even propose
introducing URI CURIEs into link-format, so we have strong meaning for
some.temperature:

,rel=3D"ns",curie=3D"some";
;if=3D"core.s some.delayable";rt=3D"some.temperature"

would be interpreted (for a predefined meaning of core) as

   .
   .

but details of that are for if and when it turns out that I am right
about JSON-LD's applicability.

--=20
Christian Ams=FCss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

--mFWIsQnH1d6uRhsN
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWqH2aAAoJEDmNERLTpL3h9ZIP/12o4rxZSSOXmJ1DYFVNKKIs
VwvkKZLDyX5QHIUKRDRE7bh7Mfus3b31eGJ+w0I9V09F+yHppqMPJcgYoeK1txTq
tCpef2Z8ZEDXKdGrjDTemhfOR5yobbHWNPDNr0xJxg4ZCzi19wwgurwM37sb08EW
z3LpW6kx2POZBi0uL6PKnLsOs4XtZExf3RI6CYr+F4vgAiHGrWnnTO0+DpZ3/pup
zKSBqjwI3FmxwVXpDv1EhNRECL/NAFcK+trKpOpwKp1n0IX2NLM39hznDEKAMKYN
Zf1API6EhrJq5bINAw0J1PDuBAN1sLJ3NLxgYt6f3bkWEbj8grHiOct9GR8f1oGi
kykdQuw+vC/X90Ugh0pyh19gVL6tG5Z6TlQWklcr2Z6nv/NQGkyVb9fx2X0YWR0N
cbg1btJ5I/H96gsjdhfs54qVbjoVbkwF+vOV/WaQH6qGjDcgAU7R0GXpm7yHyDDw
eDX42Ge43Id5KnBcJ7qHty6oKDffHMdufIBkAaWcqNGjTZ72vF9GdWWiBfn/xv1a
JAtzuKFb0F2TkjxzJQHMFK/kuLjZ0nmB/l6Tfa3lnzX0VCeUfhTE/E29BlB8V2Ug
PSNRzFUP3mb6aaswFoHSm/bF6uY29wpXcuCRFVYUZNWon+KgG8lB+iZAVHTI1WTT
rXvPdpxOfr121puabgYE
=0xe+
-----END PGP SIGNATURE-----

--mFWIsQnH1d6uRhsN--


From nobody Wed Jan 27 03:24:18 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C11D1A6FBE for ; Wed, 27 Jan 2016 03:24:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=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 UuV7Y2lAoSEJ for ; Wed, 27 Jan 2016 03:24:15 -0800 (PST)
Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com [IPv6:2607:f8b0:400e:c03::244]) (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 D6C651A6FBC for ; Wed, 27 Jan 2016 03:24:14 -0800 (PST)
Received: by mail-pa0-x244.google.com with SMTP id gi1so294837pac.2 for ; Wed, 27 Jan 2016 03:24:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IgOxojI7fe7GrxO2RditCZxJqAyXzXt9TOkImAkhlZI=; b=OgK1tdEIRMaQXrxavf0JVsCXyW5jNlpNOoFkNuaSXGdgQcAtO706imutSFgOn1d6aV yeQZM09fBx6SkwXrf0Br94OfqUideYK7IEzlt+Lq2ZylcuuFd0gahAMYRu+ty30Cuslq /P9shAMJfKhxkibRjjbNoCeE8j/G/DClWyRjnmHSCymAja20GHcwuo9Yom/0WaSirI/o pnYIrw/ZkiTcKUW+OVpnI1cusXii9+IT+fPSNwLpfa8tdDKUPrKJ19BJ3fH/pRMFvLIQ wM1TscGOEDcXg9tT23lmrABxVEUygQfjoH3meGHGsF1hMhGQaVqNwTUYpL1ak/0GCnpe FPLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IgOxojI7fe7GrxO2RditCZxJqAyXzXt9TOkImAkhlZI=; b=e0EAIRPnspJybWywcfd/R9tLTu2+fWWOOiK6mMg7gSJXLj18sVj6j5v1bQUGKKGP02 GRVAXIdH0MF0e+UrR7VEfrC6dCEBo2K2dXbO37O1zsxnXx3Pf3WZ/aUiPZ1Bc9wbHLm7 ACPuBR+5rYL+ehDN3I2s6FWu6Rcg+w7Vl845Z8CyrrGxCur+BBZysEe/Nw4u9pVJHmRk otFoITdWwcN00sJcKCWyYLe+5nclk4I7n/FVNHI4bHZrWgXqJ5WkSQQxeL6NorVrZjev XB/09Qcnpp7L6Y/3UQlmchBnO7PioBn6VF7a5LRtpUZoGzwcgZBM58PGv9gArpkH9oDr GzcQ==
X-Gm-Message-State: AG10YORByhNdOoD8IESQ/trOK70qa8lzjv39ajaAcNlq/a6QEJH/CRG2W220XWx4tjs+yw==
X-Received: by 10.66.255.97 with SMTP id ap1mr41542798pad.135.1453893854455; Wed, 27 Jan 2016 03:24:14 -0800 (PST)
Received: from [172.27.14.129] (58-97-125-4.static.asianet.co.th. [58.97.125.4]) by smtp.gmail.com with ESMTPSA id r26sm8411072pfb.21.2016.01.27.03.24.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 03:24:13 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: <20160127081941.GY7454@hephaistos.amsuess.com>
Date: Wed, 27 Jan 2016 18:24:10 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com>  <20160126164036.GE7789@hephaistos.amsuess.com> <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com> <20160127070519.GF7789@hephaistos.amsuess.com> <2CD6395A-0B3B-4C48-B173-14FF8A90C2F0@gmail.com> <20160127081941.GY7454@hephaistos.amsuess.com>
To: =?iso-8859-1?Q?Christian_Ams=FCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 11:24:16 -0000

> On Jan 27, 2016, at 3:19 PM, Christian Ams=FCss =
 wrote:
>=20
> On Wed, Jan 27, 2016 at 02:32:15PM +0700, Michael Koster wrote:
>>> That, and string splitting (when it comes to parsing the "l" =
entries'
>>> "rt" attributes).
>>=20
>> I don't see where any string splitting is needed. The "l" entries are =
all JSON parseable, as are the rt attribute values.
>=20
> The rt and if attributes of application/link-format requires that all
> resource types assigned to a resource be stored in a single =
rt=3D""/if=3D""
> attribute in a space separated fashion (rfc6690 3.1, as is also the =
case
> for rel per rfc5988), and draft-ietf-core-links-json-04 makes no =
attempt
> to split those up (2.2).
>=20

Oh, I see. I think this is an omission in the document. As I understand, =
it is the=20
intention for the JSON serialization of links with multiple attribute =
values to use=20
JSON arrays to represent those values.

I will discuss with the draft editor and confirm this.

My examples are built from JSON serializations that use array type to =
represent=20
multiple attribute values.

> If resource types were to be used in a way they can be queried in an =
RDF
> context, the statements produced from ;if=3D"core.s some.delayable"
> should at least contain[1]
>=20
>   =
 .
>   =
 .
>=20
> because a statement like
>=20
>   "core.s some.delayable" .
>=20
> would again mean shifting the load of string parsing into the RDF
> domain, where the expectation is that reasoning can be done based on =
URI
> metadata and not on string parsing. (Again, the analogy of the
> relational database comes into my mind: You wouldn't want to have
> resource types you'll query for in a space-separated text field of a
> database).
>=20
> Also, again drawing the parallel to RDFa, when this HTML document
> test.html is parsed as RDFa (eg. using the rapper tool that is aware =
of
> the registered describedby relationship)
>=20
> 
>=20
> then the resulting statements are
>=20
> <./test.html> <./unspecified> <./next-address> .
> <./test.html>  .
> <./test.html>  =
<./next-address> .
>=20
>=20
> Best regards
> Christian
>=20
>=20
> [1] If it turns out that JSON-LD is unsuitable for this task anyway, =
as
> I have the impression which I'm trying to convey, then I'd even =
propose
> introducing URI CURIEs into link-format, so we have strong meaning for
> some.temperature:
>=20
> ,rel=3D"ns",curie=3D"some";
> ;if=3D"core.s some.delayable";rt=3D"some.temperature"
>=20
> would be interpreted (for a predefined meaning of core) as
>=20
>    =
.
>   =
 .
>=20
> but details of that are for if and when it turns out that I am right
> about JSON-LD's applicability.
>=20
> --=20
> Christian Ams=FCss                      | Energy Harvesting Solutions =
GmbH
> founder, system architect             | headquarter:
> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>                                      | ATU68476614


From nobody Wed Jan 27 10:54:08 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DD01B2B3B for ; Wed, 27 Jan 2016 10:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=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 Z1ZGyr9xZWmR for ; Wed, 27 Jan 2016 10:54:04 -0800 (PST)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 A79B61B2B3A for ; Wed, 27 Jan 2016 10:54:04 -0800 (PST)
Received: by mail-pa0-x22e.google.com with SMTP id uo6so9136521pac.1 for ; Wed, 27 Jan 2016 10:54:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GXyfuS18WxvpAcxbkWDMkEK1XvgNBM+DxqdN3cnkNxo=; b=lI6gSyIqW1+a0eMgCXmbNks5U+q0D/PdqHuEfGWypAR0XOQe2un437zcuIs4VG++WY xhc00qrig4VvspUDfVk4dJcaDvMQP4ZnyzpVc9WvLG/ja911YCQ92xPFsHAiP2F32tSC 6bMkEKcf+xuA2dykxlruDQmw8P4McItQqJs9Ys/3e4xJ4FxuRRN0RUVhzpVQVMNqc3Uz b/IwR5mnKc41Sb1dZajCWNI5eJuudMM54OEm1Ypc2uLpGYqbbn1jJ3/lHf0Fg7APASyb w9QzQ9X762DuJVnYWxbko2NZ8bjG5ewjSXtzDv6PK8qAdSQ+UZpPeH/kItKwYrwx405U IpBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=GXyfuS18WxvpAcxbkWDMkEK1XvgNBM+DxqdN3cnkNxo=; b=Zr1LljcBfXVVdRnltbkVEQX1Pk69ZlpdQ3e8OJuPE8FmB9Mzv1da4tAVxQwlXDCo6F Rrenm9W30rWwiLumCyFo0028OenG1jURGsH/1iD2DPMLR3wFzsRdksprCBDIc9cbu1wV 2GVR2zmpoFZ2xyi4y90DCy1AOkAA5heUIzQXkE8kXdinq6Q5JoBwgdTqYqVFIniz0d8d 0ENc8H9dcxWY+B30JiGCArYhMurC78DIQx0d2TVW4Xa7hv8bZ7f4621apJeToQI14V/w wj2o+aK6URkva95WoTm+FTYn56N/tPZtjOsFTpBIjCiteKCCpW+HzHfjFgTDHnZRYSso oyGw==
X-Gm-Message-State: AG10YOT7t4ZajQqsIgoIXYKgcBXgJ4TGQJIVXXdYZHMQYYPfZBzmW3nQ1syQJoM1VT5Tfw==
X-Received: by 10.66.102.106 with SMTP id fn10mr45345059pab.60.1453920844358;  Wed, 27 Jan 2016 10:54:04 -0800 (PST)
Received: from [172.27.14.129] (58-97-125-4.static.asianet.co.th. [58.97.125.4]) by smtp.gmail.com with ESMTPSA id dg1sm10745875pad.18.2016.01.27.10.54.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 10:54:03 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E8AFC253-260F-42D4-AE5F-65B19A80DF95"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster 
In-Reply-To: 
Date: Thu, 28 Jan 2016 01:54:00 +0700
Message-Id: 
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com>  <20160126164036.GE7789@hephaistos.amsuess.com> <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com> <20160127070519.GF7789@hephaistos.amsuess.com> <2CD6395A-0B3B-4C48-B173-14FF8A90C2F0@gmail.com> <20160127081941.GY7454@hephaistos.amsuess.com> 
To: =?utf-8?Q?Christian_Ams=C3=BCss?= 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core 
Subject: Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 18:54:07 -0000

--Apple-Mail=_E8AFC253-260F-42D4-AE5F-65B19A80DF95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Excuse me, I was wrong. On reading the draft =
https://tools.ietf.org/html/draft-ietf-core-links-json-04 =

there is clear normative text in the draft that requires multiple valued =
parameters to be represented as=20
JSON arays (sec 2.2):

   If a Link attribute ("parmname") is present more than once in a
   "link-value", its values are then represented as a JSON array of JSON
   string values; this array becomes the value of the JSON name/value
   pair where the attribute name is the JSON name.  Attributes occurring
   just once MUST NOT be represented as JSON arrays but MUST be directly
   represented as JSON strings.=20

There is no example of this in the draft, nor is there a formal syntax =
production to show it, but the text is clear.

Sorry for the confusion.

Michael

> On Jan 27, 2016, at 6:24 PM, Michael Koster =
 wrote:
>=20
>=20
>> On Jan 27, 2016, at 3:19 PM, Christian Ams=FCss =
 wrote:
>>=20
>> On Wed, Jan 27, 2016 at 02:32:15PM +0700, Michael Koster wrote:
>>>> That, and string splitting (when it comes to parsing the "l" =
entries'
>>>> "rt" attributes).
>>>=20
>>> I don't see where any string splitting is needed. The "l" entries =
are all JSON parseable, as are the rt attribute values.
>>=20
>> The rt and if attributes of application/link-format requires that all
>> resource types assigned to a resource be stored in a single =
rt=3D""/if=3D""
>> attribute in a space separated fashion (rfc6690 3.1, as is also the =
case
>> for rel per rfc5988), and draft-ietf-core-links-json-04 makes no =
attempt
>> to split those up (2.2).
>>=20
>=20
> Oh, I see. I think this is an omission in the document. As I =
understand, it is the=20
> intention for the JSON serialization of links with multiple attribute =
values to use=20
> JSON arrays to represent those values.
>=20
> I will discuss with the draft editor and confirm this.
>=20
> My examples are built from JSON serializations that use array type to =
represent=20
> multiple attribute values.
>=20
>> If resource types were to be used in a way they can be queried in an =
RDF
>> context, the statements produced from ;if=3D"core.s =
some.delayable"
>> should at least contain[1]
>>=20
>>   =
 .
>>   =
 .
>>=20
>> because a statement like
>>=20
>>   "core.s some.delayable" .
>>=20
>> would again mean shifting the load of string parsing into the RDF
>> domain, where the expectation is that reasoning can be done based on =
URI
>> metadata and not on string parsing. (Again, the analogy of the
>> relational database comes into my mind: You wouldn't want to have
>> resource types you'll query for in a space-separated text field of a
>> database).
>>=20
>> Also, again drawing the parallel to RDFa, when this HTML document
>> test.html is parsed as RDFa (eg. using the rapper tool that is aware =
of
>> the registered describedby relationship)
>>=20
>> 
>>=20
>> then the resulting statements are
>>=20
>> <./test.html> <./unspecified> <./next-address> .
>> <./test.html>  .
>> <./test.html>  =
<./next-address> .
>>=20
>>=20
>> Best regards
>> Christian
>>=20
>>=20
>> [1] If it turns out that JSON-LD is unsuitable for this task anyway, =
as
>> I have the impression which I'm trying to convey, then I'd even =
propose
>> introducing URI CURIEs into link-format, so we have strong meaning =
for
>> some.temperature:
>>=20
>> ,rel=3D"ns",curie=3D"some";
>> ;if=3D"core.s some.delayable";rt=3D"some.temperature"
>>=20
>> would be interpreted (for a predefined meaning of core) as
>>=20
>>   =
 .
>>   =
 .
>>=20
>> but details of that are for if and when it turns out that I am right
>> about JSON-LD's applicability.
>>=20
>> --=20
>> Christian Ams=FCss                      | Energy Harvesting Solutions =
GmbH
>> founder, system architect             | headquarter:
>> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 =
Steyr
>> tel:+43-664-97-90-6-39                | =
http://www.energyharvesting.at/
>>                                     | ATU68476614
>=20


--Apple-Mail=_E8AFC253-260F-42D4-AE5F-65B19A80DF95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Excuse me, I was wrong. On reading the draft https://tools.ietf.org/html/draft-ietf-core-links-json-04there is clear normative text in the draft that requires =
multiple valued parameters to be represented as 
JSON arays (sec 2.2):

   If a Link attribute ("parmname") is present more than once in a
   "link-value", its values are then represented as a JSON array of JSON
   string values; this array becomes the value of the JSON name/value
   pair where the attribute name is the JSON name.  Attributes occurring
   just once MUST NOT be represented as JSON arrays but MUST be directly
   represented as JSON strings. 

There is no example of this in the =
draft, nor is there a formal syntax production to show it, but the text =
is clear.

Sorry =
for the confusion.

Michael

On Jan 27, 2016, at 6:24 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:


On Jan 27, 2016, at 3:19 =
PM, Christian Ams=FCss <c.amsuess@energyharvesting.at> wrote:

On Wed, Jan 27, 2016 at 02:32:15PM +0700, Michael Koster =
wrote:
That, and string splitting (when it comes to =
parsing the "l" entries'
"rt" attributes).

I don't see where any string =
splitting is needed. The "l" entries are all JSON parseable, as are the =
rt attribute values.

The rt =
and if attributes of application/link-format requires that all
resource types assigned to a resource be stored in a single =
rt=3D""/if=3D""
attribute in a space separated fashion =
(rfc6690 3.1, as is also the case
for rel per rfc5988), =
and draft-ietf-core-links-json-04 makes no attempt
to =
split those up (2.2).


Oh, I see. I think this is an omission in the document. As I =
understand, it is the 
intention for the JSON =
serialization of links with multiple attribute values to use 
JSON arrays to represent those values.

I will discuss with the draft editor and confirm this.

My examples are built from JSON serializations =
that use array type to represent 
multiple attribute =
values.

If resource types were to be used in a way they can be =
queried in an RDF
context, the statements produced from =
<x>;if=3D"core.s some.delayable"
should at least =
contain[1]

<x> <http://thingschema.org/schema#if> <http://thingschema.org/if#core.s> .
<x> <http://thingschema.org/schema#if> <http://thingschema.org/if#some.delayable> .

because a statement like

<x> <http://thingschema.org/schema#if> "core.s =
some.delayable" .

would again mean shifting =
the load of string parsing into the RDF
domain, where the =
expectation is that reasoning can be done based on URI
metadata and not on string parsing. (Again, the analogy of =
the
relational database comes into my mind: You wouldn't =
want to have
resource types you'll query for in a =
space-separated text field of a
database).
Also, again drawing the parallel to RDFa, when this HTML =
document
test.html is parsed as RDFa (eg. using the rapper =
tool that is aware of
the registered describedby =
relationship)

<html prefix=3D"demo: http://example.com/demo"><link rel=3D"demo:next =
describedby unspecified" href=3D"./next-address" /></html>

then the resulting statements are

<./test.html> <./unspecified> =
<./next-address> .
<./test.html> <http://example.com/demo#next <./next-address> .
<./test.html> <http://www.w3.org/2007/05/powder-s#describedby> =
<./next-address> .


Best =
regards
Christian


[1] If it turns out that JSON-LD is unsuitable for this task =
anyway, as
I have the impression which I'm trying to =
convey, then I'd even propose
introducing URI CURIEs into =
link-format, so we have strong meaning for
some.temperature:

<http://example.org/some/v1#>,rel=3D"ns",curie=3D"some";<=
br class=3D""><x>;if=3D"core.s =
some.delayable";rt=3D"some.temperature"

would=
 be interpreted (for a predefined meaning of core) as

<x> <http://thingschema.org/schema#if> <http://thingschema.org/core#s> .
<x>=
 <http://thingschema.org/schema#if> <http://example.org/some/v1#delayable> .

but details of that are for if and when it =
turns out that I am right
about JSON-LD's =
applicability.

-- 
Christian =
Ams=FCss =
            &n=
bsp;        | Energy Harvesting =
Solutions GmbH
founder, system architect =
            | =
headquarter:
mailto:c.amsuess@energyharvesting.at  | =
Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 =
            &n=
bsp;  | http://www.energyharvesting.at/
 =
            &n=
bsp;           &nbs=
p;           | =
ATU68476614


=

--Apple-Mail=_E8AFC253-260F-42D4-AE5F-65B19A80DF95--


From nobody Wed Jan 27 11:14:36 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872A11B2FDB for ; Wed, 27 Jan 2016 11:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 GZZR1XmrEOnJ for ; Wed, 27 Jan 2016 11:14:33 -0800 (PST)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54231B2FD8 for ; Wed, 27 Jan 2016 11:14:32 -0800 (PST)
Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 0E0B6FB8A4; Wed, 27 Jan 2016 20:14:31 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id LRn2Q07nOZ40; Wed, 27 Jan 2016 20:14:29 +0100 (CET)
X-Originating-IP: 134.102.218.240
Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 3FC77FB86D; Wed, 27 Jan 2016 20:14:28 +0100 (CET)
Message-ID: <56A91712.40906@tzi.org>
Date: Wed, 27 Jan 2016 20:14:26 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Michael Koster 
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com>  <20160126120126.GD7789@hephaistos.amsuess.com>  <20160126164036.GE7789@hephaistos.amsuess.com> <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com> <20160127070519.GF7789@hephaistos.amsuess.com> <2CD6395A-0B3B-4C48-B173-14FF8A90C2F0@gmail.com> <20160127081941.GY7454@hephaistos.amsuess.com>  
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "Cullen Jennings \(fluffy\)" , core , =?UTF-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= 
Subject: Re: [core] SenML and link-format in RDF
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 19:14:34 -0000

Michael Koster wrote:
> There is no example of this in the draft, nor is there a formal syntax
> production to show it, but the text is clear.

A link relation can be present more than once, and this rule defines how
to handle this.
A link relation with a single value that is a space-separated list of
items (NMTOKENS style) cannot be handled that way, because the
RFC6690-JSON/CBOR converter does not know which link relations use
NMTOKENS-style values.  That is sad, but I don't know a better way.
(Related to having "ct": "60".)

The formal syntax production indeed needs to be updated with this,
thanks for pointing that out!

Grüße, Carsten


From nobody Thu Jan 28 15:20:46 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7CB1B2A0A; Thu, 28 Jan 2016 15:20:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 JeSKZKY1Wi_i; Thu, 28 Jan 2016 15:20:40 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BA61B2A06; Thu, 28 Jan 2016 15:20:40 -0800 (PST)
Received: from hebrews (unknown [12.185.22.226]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id D370738EA5; Thu, 28 Jan 2016 15:20:37 -0800 (PST)
From: "Jim Schaad" 
To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , 
References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Date: Thu, 28 Jan 2016 15:18:00 -0800
Message-ID: <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQH/N40dZG+wyPslqrIqOShIBqjspwKyJuasnqA+LnA=
Archived-At: 
Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, barryleiba@gmail.com, core@ietf.org
Subject: Re: [core] Last Call:  (Block-wise transfers in CoAP) to Proposed Standard
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 23:20:43 -0000

G=C3=B6ran,

I finally got caught up on reading the CORE mailing list (lots of =
boredom on issues I don=E2=80=99t think I care about) and I did not find =
any responses to your mail on this issue.  I would like to propose a =
different solution to the problem which I think you will find both =
workable and potential not requiring any updates to the current draft.

When I read this draft the first time, I read it as a network =
fragmentation draft rather than as a messaging draft.  As such I did not =
have the same concerns about object security as you seem to have.  I =
made the decision that I would apply the security to the entirety of the =
message being sent, and then fragment it into blocks afterwards.  Such =
an approach allows for a number of things that you are having problems =
with to be ignored.

How the fragmentation is done, is change or is removed become immaterial =
as the end recipient would need to have all of the fragments delivered =
and in the correct order in order to process the message and do =
validation.

Overhead is smaller because the overhead of encrypting/signing at the =
object security level is done once rather than once per fragment.  This =
allows for fewer bytes to be sent across the wire.

The headers of the first message in the fragment are the ones that the =
object security system would be using both for security calculation =
purposes and for the receiver to process the validated message.

There are still some question that potentially need to be dealt with:

1) Are the block option headers authenticated?  The probable answer =
should be no as they are designed to be changed by intermediaries.  This =
can be deferred until the general discussion about the rest of the =
current headers.

2) What options are required to be copied forward into subsequent =
messages and which can be omitted?  I was unable to find any guidance on =
this issue from reading the document and thus would naively make the =
assumption that all options not specified by this document are copied =
forward and should be checked to make sure that they are unchanged in =
future messages.  However I doubt that is the desire of the authors.  =
This however is not a security specific issue and needs to be addressed =
in this document.

3) Do we want to apply per message security as well - that is an issue =
that can and should be punted to a future object security draft.  =
However, I don't see the point except to protect the ACK/NACK or lack of =
on each individual hop.  But this is point-to-point not end-to-end.

Jim



> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of G=C3=B6ran =
Selander
> Sent: Wednesday, November 25, 2015 11:07 PM
> To: ietf@ietf.org
> Cc: draft-ietf-core-block@ietf.org; core-chairs@ietf.org; =
core@ietf.org;
> barryleiba@gmail.com
> Subject: Re: [core] Last Call:  =
(Block-wise transfers
> in CoAP) to Proposed Standard
>=20
>=20
>=20
> There was a thread on the CoRE WG mailing list a couple of months ago =
on the
> topic of blockwise and object security. The starting point was a =
question if CoAP
> proxies can (re-)partition messages into blocks as defined in this =
draft, and the
> implications on end-to-end security between client and server through =
such a
> proxy. The conclusions of that discussion has an impact on this draft, =
but there
> are no considerations of this kind made in version -18. More details =
are given
> below, including some alternative proposals for how to address this. =
Apologies
> for the long e-mail.
>=20
>=20
> Background:
>=20
> There is an ongoing discussion in CoRE and ACE WGs since a year on the =
end-to-
> end security properties of CoAP, i.e. protecting the communication =
between a
> client and a server through proxies. RFC 7252 and other specifications =
in the
> CoAP suite define a set of legitimate proxy operations on CoAP =
messages which
> requires DTLS to be terminated at proxies. This implies that the proxy =
has access
> not only with the data required for perform the intended proxy =
operation but is
> also able to eavesdrop or manipulate any part of the CoAP payload and
> metadata in transit between client and server without being protected =
or
> detected by DTLS.
>=20
>=20
> One way to mitigate this threat is to complement or replace DTLS with
> application layer protection of CoAP payload and metadata between =
client and
> server for the use cases where the proxy should not be fully trusted.
> This has been discussed in the CoRE WG meetings during the three last =
IETF F2F
> meetings and there are draft solutions using the message format being
> developed in the COSE WG.
>=20
>=20
> With the COAP proxy operations standardized so far it has been =
possible to
> protect the CoAP messages adequately with security on transport layer,
> application layer or a combination thereof. In the case where the =
legitimate
> proxy operation is predictable by client and server, application layer =
security can
> be defined to both verify that no illegitimate changes has been =
performed as
> well as verifying the legitimate changes. In the case where proxy =
operations are
> not predictable =E2=80=94 even if the data the proxy is operating on =
cannot be protected
> =E2=80=94 it has so far been possible to use other information =
elements to provide the
> required end-to-end security properities.  For example, the CoAP =
header field
> Token may be changed by a proxy, but instead a transaction identifier =
can be
> introduced in the application security wrapper (COSE
> header) to define a message (exchange) identifier common to client and =
server.
>=20
>=20
> Blockwise:
>=20
> With the definition of blockwise transfer as specified in this draft a =
proxy may
> partition or re-partitioning a message into blocks where the size of =
the blocks
> are decided by the proxy. As a consequence, it is not possible to =
integrity protect
> individual blocks end-to-end between client and server: DTLS does not =
protect
> the message data within the proxy, and application layer integrity =
protection of
> individual blocks cannot be performed unless the partitioning into =
blocks as
> received by one endpoint is identical to that sent by the other =
endpoint. Hence,
> when CoAP Block options are used as defined in this draft, end-to-end =
security
> of the individual CoAP request and response breaks down. For example: =
a proxy
> may addBlock options, send any number of blocks with any payload to an
> endpoint without being possible to detect or protect against. In =
contrast to the
> existing standards in the CoAP suite, in this case it is not possible =
to bypass the
> construction and define a secure end-to-end block partitioning with =
less than
> disabling block partitioning as specified in this draft.
>=20
>=20
> One solution to this is to disallow proxies to re-partition a message, =
thus
> redefine the Block options such that they are possible to integrity =
protect end-
> to-end.  Integrity protecting each block and corresponding Block =
options as
> defined in the current draft has additional benefits: If any block in =
the sequence
> fails verification, it can be individually requested to be resent. =
When all blocks
> has been verified the entire message has been verified.  A receiving =
node may
> even perform certain actions based on received verified blocks before =
the entire
> message has been received.
>=20
>=20
> Instead of delegating to proxies to partition into blocks, the sending =
endpoint
> would need to anticipate or get information about the relevant block =
size, e.g.
> using a size indication in the link-format description [RFC6990]. =
Additional
> methods for blocksize discovery may also be defined.
> While this may not be as simple as leaving it entirely to the proxy to =
decide,
> considering the additional security benefits I believe this is the =
right trade off to
> make.
>=20
>=20
> An alternative solution is to prevent proxies from re-partitioning a =
message only
> in the case where end-to-end security of CoAP message is applied, =
which in
> current solution proposals is indicated with the presence of a certain =
CoAP
> option X (which e.g. contains the COSE object).
> This would have the same benefits as the previous solution, but =
requires the
> code in the proxy implementing this draft to be aware of option X, and =
hence
> that dependency needs to be specified in this draft. And option X is =
not
> standardized yet, so would require introducing a placeholder.
>=20
>=20
> There are other alternatives as well but this e-mail is already too =
long.
> The main point I wanted to make is that given that we now have a =
better
> understanding of how to achieve security between client and server =
through
> proxies compared to when RFC7252 was written, my opinon is that we =
should
> not ignore these security issues in new standards.
>=20
>=20
>=20
> G=C3=B6ran
>=20
>=20
>=20
> On 2015-11-20 22:32, "The IESG"  wrote:
>=20
> >
> >The IESG has received a request from the Constrained RESTful
> >Environments WG (core) to consider the following document:
> >- 'Block-wise transfers in CoAP'
> >   as Proposed Standard
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action. Please send substantive comments to =
the
> >ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments =
may
> >be sent to iesg@ietf.org instead. In either case, please retain the
> >beginning of the Subject line to allow automated sorting.
> >
> >Abstract
> >
> >
> >   CoAP is a RESTful transfer protocol for constrained nodes and
> >   networks.  Basic CoAP messages work well for the small payloads we
> >   expect from temperature sensors, light switches, and similar
> >   building-automation devices.  Occasionally, however, applications
> >   will need to transfer larger payloads -- for instance, for =
firmware
> >   updates.  With HTTP, TCP does the grunt work of slicing large
> >   payloads up into multiple packets and ensuring that they all =
arrive
> >   and are handled in the right order.
> >
> >   CoAP is based on datagram transports such as UDP or DTLS, which
> >   limits the maximum size of resource representations that can be
> >   transferred without too much fragmentation.  Although UDP supports
> >   larger payloads through IP fragmentation, it is limited to 64 KiB
> >   and, more importantly, doesn't really work well for constrained
> >   applications and networks.
> >
> >   Instead of relying on IP fragmentation, this specification extends
> >   basic CoAP with a pair of "Block" options, for transferring =
multiple
> >   blocks of information from a resource representation in multiple
> >   request-response pairs.  In many important cases, the Block =
options
> >   enable a server to be truly stateless: the server can handle each
> >   block transfer separately, with no need for a connection setup or
> >   other server-side memory of previous block transfers.
> >
> >   In summary, the Block options provide a minimal way to transfer
> >   larger representations in a block-wise fashion.
> >
> >
> >
> >
> >The file can be obtained via
> >https://datatracker.ietf.org/doc/draft-ietf-core-block/
> >
> >IESG discussion can be tracked via
> >https://datatracker.ietf.org/doc/draft-ietf-core-block/ballot/
> >
> >
> >No IPR declarations have been submitted directly on this I-D.
> >
> >
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From nobody Thu Jan 28 16:33:37 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9D91B2DDF for ; Thu, 28 Jan 2016 16:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.907
X-Spam-Level: *
X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[BAYES_50=0.8, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 Ld5tdGZQaDlQ for ; Thu, 28 Jan 2016 16:33:35 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094361B2DC1 for ; Thu, 28 Jan 2016 16:33:34 -0800 (PST)
Received: from hebrews (unknown [12.40.199.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 665C638EA5; Thu, 28 Jan 2016 16:33:34 -0800 (PST)
From: "Jim Schaad" 
To: 
Date: Thu, 28 Jan 2016 16:30:59 -0800
Message-ID: <064601d15a2c$53b55a70$fb200f50$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AdFaKo5GkgS+N5BaRh2j2/IE/FPReA==
Archived-At: 
Cc: core@ietf.org
Subject: [core] draft-koster-core-coap-pubsub
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 00:33:36 -0000

This draft came to my attention at the last F2F meeting.  In thinking about
it at the time and since then I have come up with a desire to have some
additional functionality applied to it.  I am unsure what is the best way to
proceed on this.

Consider the case of having two different types of messages coming on a
stream.  The simple case would be a rebase message and a delta value
message.  One cannot understand the delta value message without having
received and processed the rebase message.  If the sense emits ,
series of deltas,  series of deltas.  The series of deltas does
necessarily need to be delivered to the client.  But the last rebase message
must be delivered to the client.

The actual case that I am looking at is a message security scenario.  Two
types of messages are sent over the data stream.  The first are going to be
regular encrypted messages that have the least possible amount of overhead.
The second type of messages are going to send some additional context
information when any of a number of changes are made to the security state.
These would include a re-key event, an ACL change event (requiring going
back to an access server for a new base key), or events relating to dealing
with multicast responses back to the resource server.

I have come up with two easy ways to look at this:

1.  There is a single stream with multiple messages.  Some of which are
marked as confirmable (and thus must be delivered) and some of which are
not.  This involves logic on the subscription server to keep all of the
confirmable messages for all of the active subscriptions until they have
been confirmed back but only the last non-confirmed message.  They are then
delivered in order.

2.  We create multiple related streams each of which only has the last
message of each type in it.  When one subscribes to the main feed, one is
automatically subscribed to the related feeds.  The problem with this
solution is that synchronization is not present between the two streams so
that some type of sync state in messages might be required as well.

Does this ring any bells in people's heads as something that needs to be
done or am I in limbo.

Jim
 


From nobody Thu Jan 28 23:36:27 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E091A0217; Thu, 28 Jan 2016 23:36:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 gWIQ5mOaua0i; Thu, 28 Jan 2016 23:36:20 -0800 (PST)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CD41A0211; Thu, 28 Jan 2016 23:36:20 -0800 (PST)
Received: from mfilter46-d.gandi.net (mfilter46-d.gandi.net [217.70.178.177]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 8E83EA80AA; Fri, 29 Jan 2016 08:36:18 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter46-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter46-d.gandi.net (mfilter46-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eLgvhgM5R9Tc; Fri, 29 Jan 2016 08:36:16 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 4C49EA80F1; Fri, 29 Jan 2016 08:36:16 +0100 (CET)
Message-ID: <56AB166F.9040404@tzi.org>
Date: Fri, 29 Jan 2016 08:36:15 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Jim Schaad 
References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com>  <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com>
In-Reply-To: <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: ietf@ietf.org, core@ietf.org
Subject: Re: [core] Last Call:  (Block-wise transfers in CoAP) to Proposed Standard
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 07:36:23 -0000

Hi Jim,

great discussion, thank you.
Retroactively adding security over insecure channels to CoAP is not an
area with easy answers.

A couple of random observations:

-- indeed, block is meant to help getting larger messages through the
network.  The individual blocks are generally not really worth
individual protection.  I think the biggest remaining question with this
is what to do against an attacker polluting a cache with a bad block
(creating a problem for availability, not integrity).  (In RFC7252's
security model, DTLS prevents that from happening.)

-- in CoAP, options are given option numbers that expose some of their
characteristics, e.g., critical/elective, safe-to-forward, cache-key, so
some operations are possible on options that the system handling them
doesn't know.  We didn't think to have bits in the option number for the
security properties of the option.  Can we possibly derive everything we
need from the existing bits?  Do we maybe have to carry that information
separately with a message secured at the CoAP level?

-- A small group is working on classifying the desirable security
objectives for the existing CoAP options.  That is not an easy project,
but I hope we will have something to look at for Buenos Aires.

-- As a random coincidence, have a look at the new
https://tools.ietf.org/html/draft-thomson-http-mice-00

Grüße, Carsten


From nobody Fri Jan 29 11:46:25 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957471B3295; Fri, 29 Jan 2016 11:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 QsPbkEPOfDct; Fri, 29 Jan 2016 11:46:22 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1FD1B3299; Fri, 29 Jan 2016 11:46:22 -0800 (PST)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id E3B272C9BB; Fri, 29 Jan 2016 11:46:21 -0800 (PST)
From: "Jim Schaad" 
To: "'Carsten Bormann'" 
References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com>  <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> <56AB166F.9040404@tzi.org>
In-Reply-To: <56AB166F.9040404@tzi.org>
Date: Fri, 29 Jan 2016 11:43:47 -0800
Message-ID: <06d301d15acd$5f37c120$1da74360$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQH/N40dZG+wyPslqrIqOShIBqjspwKyJuasAbm/U5kA9GZ54p6MKAIg
Archived-At: 
Cc: ietf@ietf.org, core@ietf.org
Subject: Re: [core] Last Call:  (Block-wise transfers in CoAP) to Proposed Standard
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 19:46:24 -0000

> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: Thursday, January 28, 2016 11:36 PM
> To: Jim Schaad 
> Cc: ietf@ietf.org; core@ietf.org
> Subject: Re: [core] Last Call:  =
(Block-wise transfers
> in CoAP) to Proposed Standard
>=20
> Hi Jim,
>=20
> great discussion, thank you.
> Retroactively adding security over insecure channels to CoAP is not an =
area with
> easy answers.
>=20
> A couple of random observations:
>=20
> -- indeed, block is meant to help getting larger messages through the =
network.
> The individual blocks are generally not really worth individual =
protection.  I think
> the biggest remaining question with this is what to do against an =
attacker
> polluting a cache with a bad block (creating a problem for =
availability, not
> integrity).  (In RFC7252's security model, DTLS prevents that from =
happening.)
>=20
> -- in CoAP, options are given option numbers that expose some of their
> characteristics, e.g., critical/elective, safe-to-forward, cache-key, =
so some
> operations are possible on options that the system handling them =
doesn't know.
> We didn't think to have bits in the option number for the security =
properties of
> the option.  Can we possibly derive everything we need from the =
existing bits?
> Do we maybe have to carry that information separately with a message =
secured
> at the CoAP level?

This is not dealing with the issue that I raised.  Consider the =
following case

In block 1, the content type is set to 1.
In block 2, the content type is set to 2.

Now, this can be an error.  This can be a use the first value.  This can =
be a use the last value.

Which of the above three cases should I evaluate to on the base =
protocol.  Nothing to do with security.

The same question arises when if content type is absent in block2.=20

There are going to be some item which can and will change.  This are =
probably the unsafe to forward items.  The behavior might change based =
on some type of criticality bit in the option number.   This should be =
documented in the core protocol.

Jim

>=20
> -- A small group is working on classifying the desirable security =
objectives for the
> existing CoAP options.  That is not an easy project, but I hope we =
will have
> something to look at for Buenos Aires.
>=20
> -- As a random coincidence, have a look at the new
> https://tools.ietf.org/html/draft-thomson-http-mice-00
>=20
> Gr=C3=BC=C3=9Fe, Carsten


From nobody Sun Jan 31 08:12:13 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2691A6FF9; Sun, 31 Jan 2016 08:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 NiPt0jBZ9bZ2; Sun, 31 Jan 2016 08:12:05 -0800 (PST)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03AB1A6FEC; Sun, 31 Jan 2016 08:12:04 -0800 (PST)
Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 277D5FB8A1; Sun, 31 Jan 2016 17:12:03 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id QrMzKMLWrCbY; Sun, 31 Jan 2016 17:12:01 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 2071FFB881; Sun, 31 Jan 2016 17:11:59 +0100 (CET)
Message-ID: <56AE324E.2010403@tzi.org>
Date: Sun, 31 Jan 2016 17:11:58 +0100
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Barry Leiba 
References: <20151020210304.27062.87223.idtracker@ietfa.amsl.com> <5626AE89.70305@tzi.org> <56289F96.1090608@cisco.com> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: core-chairs@ietf.org, The IESG , "core@ietf.org WG" 
Subject: Re: [core] Benoit Claise's Block on charter-ietf-core-01-01: (with BLOCK)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2016 16:12:07 -0000

Hi Barry,

I'm back in Germany.

I have expunged DICE (which has now closed) by replacing it with a
reference to the security area in general (for DTLS over SMS), with a
reference to the TLS WG (on DTLS specific efficiency work), and simply
striking DICE from the list of WGs to coordinate with.  That should
cover Stephen's comments.

Re Benoit's input (key:
>>>> and >> are Benoît; >>> are Carsten)

>>>> - "CoRE will also develop a way to make RESTCONF-style management
>>>> functions
>>>> available via CoAP that is appropriate for constrained node networks.
>>>> This
>>>> will require very close coordination with NETCONF and other operations
>>>> and
>>>> management working groups."
>>>>
>>>> What is the goal of this coordination with NETCONF?
>>>> Could RESTCONF be reused? If not, why not?
>>>> If yes, will RESTCONF need to be modified?
> 
>>> We want to coordinate with the NETCONF WG to ensure that the result of
>>> our work makes sense as a part of the overall NETCONF family.
> 
>> Thanks. The coordination objectives should be mentioned in the charter.
> 
>>> The basis for COMI is RESTCONF, but there will be a need for some
>>> streamlining.
> 
>> Can you expand on this, or point to a draft section/email thread.

The main draft is draft-vanderstok-core-comi, and there are some
additional considerations in draft-veillette-core-cool.

(Or did you ask for text/pointers to be in the charter?)

>>> It is not clear whether this will lead to modifications
>>> of RESTCONF itself; more likely COMI will just be a dialect that is
>>> applicable to very constrained devices.  There are different approaches
>>> on the question whether the YANG models have to take some specific care
>>> about being used in COMI,

(I was alluding to the COOL work here.)

>> (I've not been following the core mailing list and I don't know which
>> specifics you speak about)
>> I hope you will not go that path.
>> This would be a failure from an OPS point of view: we need a single YANG
>> data model language, and not another data model language. 

One objective that has been repeatedly stated in the COMI work is that
any random YANG module should be usable with COMI, but there are still
discussions whether this will be a less efficient mode and/or we should
be leaving out some parts (RPC has been stated as an example).  I think
we have been progressing towards enabling full coverage.  There may,
however, be some considerable efficiency gains that can be reaped by
evolving YANG modules in a specific way.

>> In the end, if
>> there are YANG specifics for constrained node networks, then it's a
>> different data model language.

I think this statement reflects the current direction well, however,
there may be some willingness to do additional work (such as COOL's SID
files) in exchange for significant reductions in the message size.

>> To illustrate my point: shall we see RFC 7223bis, A YANG Data Model for
>> Interface Management for constrained networks?

We already have RFC 7388, and we'd rather get more integration with the
YANG world than less.

>>
>> Unless I miss something on the above, this should even mentioned in the core
>> charter.
>>
>>     CoRE will also develop a way to make RESTCONF-style management
>>     functions available, based on YANG, via CoAP that is appropriate for
>>     constrained
>>     node networks.
>>
>>     +
>>
>>     No YANG specifics for constrained nodes network ...

I somewhat nebulously phrased that as:

  Besides continuing to examine operational and manageability aspects of
  the CoAP protocol itself, CoRE will also develop a way to make
  RESTCONF-style management functions available via CoAP that is
  appropriate for constrained node networks.  This will require very close
  coordination with NETCONF and other operations and management working
  groups.  The YANG modeling language is not a target for change in
  this process, however additional supporting mechanisms may be
  employed in specific cases where significant performance gains are
  both attainable and required.

(Maybe this can still be improved.)

>> And LWM2M?
>>
>> Do we need to expand a bit on those in the charter? I guess so

I have added to the above:

  The working
  group will continue to consider the OMA LWM2M management functions
  as a well-accepted alternative form of management and provide
  support at the CoAP protocol level where required.

That wording is obviously even more up for discussion: WG, please chime
in (potentially after limiting the CC list to core@ietf.org).

An edited version charter-ietf-core-01-01 with detailed history is now at
https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt

Grüße, Carsten


{
  =
"bn":"/3300/1/",
  "e":[
    {"n":"5700","v":"31.3"},
    =
{"n":"5602","v":"37.1"},
    {"n":"5601","v":"18.3"},
    =
{"n":"5605"},
    {"n":"5603","v":"0"},
    =
{"n":"5604","v":"100"},
    {"n":"5750","sv":"Inboard =
Bearing"}
  ],
  "l":[
    =
{"href":"","rel":"self","rt":"temperature","u":"C"},
    =
{"href":"5700","rt":"currentValue","u":"C"},
    =
{"href":"5602","rt":"maxValue","u":"C"},
    =
{"href":"5601","rt":"minValue","u":"C"},
    =
{"href":"5605","rt":"resetMaxMin"},
    =
{"href":"5603","rt":"minScale","u":"C"},
    =
{"href":"5604","rt":"maxScale","u":"C"},
    =
{"href":"5750","rt":"appType"}
  ]
}