From nobody Wed Feb 1 00:50:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA136129407 for ; Wed, 1 Feb 2017 00:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1gWFGlG8xcu for ; Wed, 1 Feb 2017 00:50:25 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0112.outbound.protection.outlook.com [104.47.1.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC01212957C for ; Wed, 1 Feb 2017 00:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i1lfCavbBwU1JUI2NoZqWos7sPxx3fUEBBKFkwit7/U=; b=p7qQavyhKiG+y0oOmNB/AOFuDFVp71mh6ZlAUW0ciaTn/A2PZzo126dl5Ew/a9md41m8nBJLWg0MctZ9iNGoi3sSb2BdVvKrrQD2fIjZvXcg2wkdMUUjlehLzd0xJwu2RMqoNw7vwaXmQ0wM+4yOxg5wnIneCg+d8yTOeTXSeNg= Received: from DB5P122CA0003.EURP122.PROD.OUTLOOK.COM (129.75.100.209) by DB5P122MB0021.EURP122.PROD.OUTLOOK.COM (129.75.100.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Wed, 1 Feb 2017 08:50:22 +0000 Received: from AM1FFO11FD006.protection.gbl (2a01:111:f400:7e00::180) by DB5P122CA0003.outlook.office365.com (2603:10a6:20:2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12 via Frontend Transport; Wed, 1 Feb 2017 08:50:22 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.247.132 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.247.132) by AM1FFO11FD006.mail.protection.outlook.com (10.174.64.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2 via Frontend Transport; Wed, 1 Feb 2017 08:50:22 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0172.MGDPHG.emi.philips.com (141.251.190.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 1 Feb 2017 08:50:21 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0860.026; Wed, 1 Feb 2017 08:50:21 +0000 From: "Dijk, Esko" To: Carsten Bormann , Lauri Piikivi Thread-Topic: [core] CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AdJ71Z2t7xvTLii1QoWlumXEa75yfQAEP+wAABxuBgAAAN+rgAACdXTQ Date: Wed, 1 Feb 2017 08:50:20 +0000 Message-ID: <7faf37debedb4743b8ab65bdd48bbea2@HE1PR9001MB0170.MGDPHG.emi.philips.com> References: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> In-Reply-To: <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.122] X-MS-Office365-Filtering-Correlation-Id: 53c88e4d-b140-4d2c-0f54-08d44a7f5b7b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9001MB0172.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(2980300002)(55904004)(374574003)(199003)(13464003)(85714005)(189002)(102836003)(4326007)(6116002)(3846002)(68736007)(2906002)(53936002)(626004)(305945005)(7736002)(69596002)(66066001)(229853002)(55016002)(356003)(47776003)(24736003)(38730400001)(8936002)(106466001)(105586002)(93886004)(189998001)(97736004)(86362001)(5001770100001)(50466002)(108616004)(2900100001)(5660300001)(2950100002)(92566002)(7696004)(33646002)(81156014)(8676002)(81166006)(76176999)(50986999)(54356999)(23676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5P122MB0021; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD006; 1:29kKEPmkmSMVj5YJspBYuvQe9MEOMe/xLBZsOTO7Fv9XcA2zeRP316LWnF6U0GRWbXxMWi2h+KfsneNLPVC3/v41KZ6JZ8Yn6y01ZtT+5sD4QDMPXd7/WP3aRPKhsICzjk5vfMnI4RA5EeDiWEUxFf/TuJnQAwqbIEC27JKKpqAWNND8H88tExJuYBmKrybislKefCMogxADg361haKFUZfAokdvYLuN9AqTQJAo4E05GxZwF4LZbDehAy8XbmgIr1YSCxyIsMoK2L7e8so41xdzlIaEc/eeV8wT6wWE1njm6K1HFYTNVN2yPNJpvG80KTYe2m7sDx8aLipJhyQ8jcOqYxsBVnmhsloxwhRKyh4N2//LRkFlkSCnHXTWkwhAwQ12O+TU2Di6y58MMRCujAn/eOn6fRAsAFiWIkQJsyXxqU6+4X4M4nEOZwyJ922QYW2/MwR4xXSZ1Z4VtNuaBHz+1oBPgohosVyqM5M0pIo= X-CrossPremisesHeadersPromoted: AM1FFO11FD006.protection.gbl X-CrossPremisesHeadersFiltered: AM1FFO11FD006.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5P122MB0021; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 3:SuotBqq0nPNIsmeRDA5sXO3aX6v1ROqVPuzSv3otIFYXKcdGhWetxHQAP82PNI8U5xG8IrlQ9NCF4lH+4VSGkRPFrRkIzUJgpP+ndHn/63vWXN2iPE2IygZn961DJ/BFGfd05UZAqTTG/Uo97/w5HqwPSN6ucjxjQ/rGR3/6k7GqeJqa0LsqhqtqyUGfA1azqnMx8Oc265PSNJhE4x+HlUAUevyCiAXDmthJGQgndk4IEPQ6z3FWtdkz4tKPcWsk2JDVzS4tUopAo61Bx7024dkkZe1gdzs9xZDfy6iiuhAyagg9hgn1hsCORzMWm34Lm+5m5D6fFzRC3LNI5OouuGXHHlJBsjhGgLrTJv7hZ7U=; 25:r3zj7OZ4JdaZRCnuDkLtSJE6ksqNIaBGKE1v/LbZcsMqRDV7cTxhSibA0NZCHiUqRXrya3DpvAFW0F67lSXDIx0VOakvd1bIpJQOJq69uH6cG4SxW+BiHii57X9JNlzUcL/wih52lHWO44OMXNhZGLa2N4x9JAqJdmr3dm25veWeHPpeD+DDrYY+kf+Gtl+Yqb3gdKjpgHHGo/jpuIamuIEPgh+KJwwdXwLbE2574tdzzYEbD8HGbAfanYRkMyDgB0a5fZN+4lfPkoPei8ZX3+4oaXHWoKXuVBX5ZRGZXxT/ja0wcSpl2CHmweTbCs6DosId3RBpIQ2PY88fK0txq6XaucbcWkJFI9BSt3ESQFSXm8agLPO4G3UgC0emgUJpMq4RbEGNWSVxnV6ZD0n96O7ODwrp2ZtiByzfmVeX7VqxsBIxZA3rTX4E9L763FyxyQEqgfKR6yDZqk15FwMR3w== X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 31:VCxcUc6wO0v4XkWkIEAwrly60BLdIp9hLP5QBsIdGbCP4NViCqN5BqIhaMg5BEuNWTQz/1oUdv+uYLApQMC6A6cYFJ8MYWkkluOtOZ61K8+pm4XGKcTBg4XiSyU0dvsxz7+ycY3kf4ogO6eMd5gxY1hMGHNEjFAi8m/p/obOwHihmynSuRhcOW3ppm2inanuK++7nX4O+ih7C1FW9MfaYZP4prSZpSpkx9Xk4n5PBLPrH/uD2GB5cW8NkU1sha5n/jCcMpo9jWumaG3xWqY+Fe5Gs91ROgbz5h74DgUJ6V8=; 20:5iZEE1bRW9CZbCMgWWdl46pjS2/FbW1W0fiuHSC0n8pESYjI+MtNRcSNiJam6bkPCL8UdWYAWHYSjbE6Jk7oj3hBzRQdx+N74ELvT/clBnqo/5kppE5Pxx0wFpz04B4nzV+S+cLC0PzoFeKrbsrVXCGC/JzsHZg8al0UvVgwT3jZ/zegZqGN88W6FBn4SnpY1MvoFfIdA6xltvcKmnB0Ore+Mg7hlCsYcjnDWRfL9SvaiJGVG/xENkRGva1ZOJ17veDyggHdJzF5g2JybBfN888wWntGuFALa2cNvTMSTHAsy0AfIqkrL80umvpZb9v/KaEMzJS/Gx5my5f/l9+faFLKpEM/I1a5BAIegPF1wfmRwq+xEQk1ik0dzQVZik12+AgN3XeCrnJKkh1zf76iD3hxJU0jehu2vBQUozSzSHPtzW8o32qE/M4NyI9j+xWRRlyp124CZZ1Y3XRzaZV2S8w+Q0JHFH0nLoMHkBGoN0v+FzaFVqwCVfZ4V+6U9H6e X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(180628864354917)(260087099026482); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(13016025)(8121501046)(13018025)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:DB5P122MB0021; BCL:0; PCL:0; RULEID:; SRVR:DB5P122MB0021; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 4:DhX6clMcWuYSx/cWhsCYMqWsGOYRxGJ3gF3fXQbgMqh8fh+LFBcO3orcVNKFPyTbCLouDl1WQEbCRfCgnAe9XADrcaRRALYt2xvNzHwVuyXYGKecUfU2ZJEAzHIyeG9UtiWrbFHt/5RRb1jDehpSbQArEJTZxVDzFb600QwYlZHkp9qln71gzbkyY88+a/Thg/+KrDdbziMtW7FQn96z23qAwzCj5AhSlAL2u37MMM7exr2yVOsxhmKHxMx6v5r6SwIz/gXGU2ATm3lg4yDqruMEXsBGEgL4rXOayqlGVkEVHGdwlGV7JsSFN0LACKSWWHmJBJGSQ0rKRB/rfNFr5YG0XsiB6RRjpZMG00HPzJhUpzhnEtFfVnUkYu9uTRXbLPan1O+YjAS0s2c6sBL0WYPUPOlCU3ezmmDxzrueIJpevHF5M9LKcY6kXU5WxhpPU5uco2gzTaNwVLLGAEvlBkC+ibArSEk+UC7kI1ltdnMZHxnmn3adTKG8Bu6RjroKFKpMh9pixWwOhflvvnn0R8rBru6TWuJV47kOGRATC9yYM6dX3lFyItHP61rmxwFd1j9HNJydY2N+kaK7oEui8HJoVzXFT638ncFMWmsccuP1vl+vVGH0TxKEFSj0HODvjxC7c1EP1O4gbgtUB5w2H31kA6CaTXfQRqqK60z2dKW1z+sYez8Aj5r7hn4ja6J0cqpSj13+BPQdGgvLDVU8uj8vBUH1yIqzgmdVYX6MEZL0psy8y3SE2aKdJmnLjIY2 X-Forefront-PRVS: 0205EDCD76 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQMTIyTUIwMDIxOzIzOjBSbXBrRGJObnpBNXAwMUdDdzEyS2xHTFd6?= =?utf-8?B?M042VEZ6UFplM2lMSWE1bDhpOW5KZEFMZmV5S3hZK0ZUWENQVytPWk1jS1JU?= =?utf-8?B?RTVhR1NpRnk2T3NROW5jM1ZKbHQ0N0t5RDFuUTA3dnhoNFhDcS93NlBMc3Nh?= =?utf-8?B?T0ZuY01lQkhnQkJiZWhVUUYrVmVOaVc4V1pwVDFkSU1HZWdmUHJvRDFNaHNx?= =?utf-8?B?NFVqYk9sOE5zWWdibVpuL010dmltTFdoR2JVQS9Mc01HdzlGME1nQ2hQY1hT?= =?utf-8?B?bm5hZHRLeHZOSDZhTUhkWDU3TDZBSk94amdlUVBYUXd0ZlVwMzZZeDRQS001?= =?utf-8?B?bFQzbmF2eTYxN3B6TmNVaG8vOTRndFprWG5xcmhGR1cvYnZIdWU5WmtiaVpE?= =?utf-8?B?dEJ1Z1RtWTBxU2RFaE1LN2IweGZqKy93LzJldTArd2NRcVRjZTc5eHJNYzBj?= =?utf-8?B?dVFsQzdUenFVT0p0YnBrN3g3VVlTY2NwNUFsa3NQYXBqUlgwV2dPcVVDYkVj?= =?utf-8?B?aGFpc00yTGJSUTlqSnRkUTJUVEZMZEZxK3FZK0dqR0piTm5QRzdQTlg1Zm1E?= =?utf-8?B?eW0wZXF4enhQN0duRUh6eVFSN1ovQXJsbkpZaTJaWjhMVEMyMElhSjAzMldm?= =?utf-8?B?TnRTcWFjWGJFM0ZNUXl1R3B5N2lkK0FrNTZOUmtEejFlblYvZE96KzJOSmJO?= =?utf-8?B?Z3Nya2E0V1dGb0pSUmlxMFJqQW9lVyttSS9oUGI2aGQrb2MvYTJmR2tZMEgy?= =?utf-8?B?RUUwWTFzRUczNWJ0VzhBUnVWaUo0cVczUnVSLzM2UDJsT2FycHBxVk9QMlg3?= =?utf-8?B?WkJ3dzBldkh5aTNnSkprWis2MXNwT0YwT1ptak1iRVhsSVlaL2hkR1dQODJP?= =?utf-8?B?Z1pDR0ltNHBTRHRDMVJqdGNCT0NMcm5NQTd3TTJCMW1neXR6NXR5MEh5Nzk5?= =?utf-8?B?ZHhOREE0RE9BdXU1VjJGV2psdkpoL2dOMnFJSHRiRFRXdTNDZTU1eGVoM0Rz?= =?utf-8?B?UzgzOVRXd0lIdko2Q0c5ekpIYnlVM1Y2NTBVSVp0SlBwenVUZ3FGS1pXT1Ar?= =?utf-8?B?MGxhZ3hSRlR6RCtLRkV6ZTJKMi91SWpGeTJENW1DYWlzb09OdklxQ0RJMzZT?= =?utf-8?B?cnA1Zzl3cmpGTUdPOUdSdit1WUhQYnNRUUdqbm1vMk1UQU9KejNyRC9KbXdO?= =?utf-8?B?WllzaDNBazVFNFczelM3dTNRTTJQUDduYW5acGpIQ2ZlNXg2bGFDWUIvMlN0?= =?utf-8?B?QXRNSlNNcTZ4TUluY2s2VGVYMDh4Skg0bzVHZHNKcEtMSVBEWlRUY09qdW5q?= =?utf-8?B?MktNK3VaN0l4UG9kamptOFNrNHQ5RWFSSTduTkk4WTFtSko1V01Xbk43SU5F?= =?utf-8?B?TzhLRDQwSFU0ZU1rbnV3MWh3VFZ1bkFNUVNDZnNFSCt0UUdEbVR1ZXlFeFdP?= =?utf-8?B?dDEwbzhmQmxoT2poN2I2N3VVbEFzdFhUMmNsNG5tRzV2Z043QXV2N2JmdTRx?= =?utf-8?B?NGRIWW1TT0xsaHpRNEVyTHZSdlFtWHlxMENYdnAzWWdiYVdVbTh5OGhacC81?= =?utf-8?B?MnptbmhUUlRSTE0zdk44aXlCMVJYd1pZdUZ5NnA0bUhJb2hTYkozQVAxcnlz?= =?utf-8?B?ZDAxbkVXN2E5aDQ4NjVGTzZ0eWFkc0xXS2FNMzJIdEZuU1F5RGJkSUxvYlJL?= =?utf-8?B?aTlkc1hGOTFUd0h0QU5WOGtmQi90NkhhbldFZXdaVEpiaGJhbHhGcFFXOGt4?= =?utf-8?B?OHZOOUxUYmxDSlRXTkpPMUl0WXpHM3A5Ni9uQ0czRndwTWxEL3NHYVNFY2Rr?= =?utf-8?Q?pCJw7hj59MaJe?= X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 6:yWaDzxdePnd8Ry6rpA48EvmLRyCUY6+JJCUbJLC2UfU9su4Bu5K1TQQWQpROyYqcobRu06+5Rsq8N5y9WUXZo3Vt6/6hrzxOz47lEo4GqvGPnqhwyOxcmYk6CBDl0uvRxfbiudKZ258RElDLemeWi+MY0oepImh+x+TpXj+DH1UBDWeZrYci+8rafz3Fy6XN3DAlw9/xiG5JXLZ2RJEbOEPeHb+XFkkNEAjbtKvAoMd1vE7t4JZeHf39nH6x5J6V0iwbqj3Lz7PqQFf9ELn7zxtXk2fJkIf18Uajm5P3RldWAVTH7cxa9yDokWXhSIlywhlUp7Um7stcDYZn5/LWEkk3JcBdPx3XSzRFHX8xFlCsGAwND5N4LfrygN2Xu3T8SNKn43nl0xh5AyLzY21z/wm6DSS2ZQ/iTXX8MWQoVCM=; 5:9J9w3JND+fhz8xZBexEsHJBOi5vfJ89EyjoKxGIZ8mAwoyS92vPliIKagymi1PLxHPRjhgG3f3PlE8phe3E8Lj2VYeMgHdOmbaimmI7YkOtGiFHwnHtVYEypOdyze0LLFxQto3jSJvZ6eb9nPhESng==; 24:xPvm/AaA2r0s0pKubx/vYs4OL0X+ZPUC2ZilIkuSLO8w495iA4d145TcZUvKHAQTTn+RmLdJOHjlzX65fpQf/4a4SV74YJombnKkPhT8oEo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 7:FGj0Mf8/FO3U8aulGOwXc26PdlaX71++d538yGEFyfN+AfCKQozGiz80nLKUMU2g2HuC+t+SDnhA4oG0xuT+sgNnAmAyVe1RSq1mGHIExP1EhI/SVNHLk3PJl/9mIGeM9Jl1Go+goscVSJV+4zWVpch0u0JaZThsTdGWgE0jsMelY2YhngF7VtdRWyHvv+r1/y2o1QiC9/FuasFAk6YELsY1hzJXSoyMYfAO5W8rmCDgjjlcyJR7ebw7fkYXBRv4FX2FrL6vI4QRN5o3/MisNheYM0y3FKo9vMOb+86PhUsu39ME5HeMJ9heShJQJ7fitdzHM8oauVP/Hws53fJPLPw0FsAQykZCeadSkziaZMx1XYlwbYYDQH/Z8yBmDloB5KgmcnllVbeqcymgCTszDDWM/R73JQlHFLe25r6CGfp+nLx6jjREqZdXOdv878EGGCmaXRj04zlPb0bN3kFEqOgsfsRymNBnfTBnNfGfI02r9EoA8qhQjpX9Bdokdei14d/pboIJR2OOJCGGfqaOrw== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2017 08:50:22.1396 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5P122MB0021 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR9001MB0170.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 194.171.252.122 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: DB5P122MB0021.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 08:50:27 -0000 VGhhbmtzIENhcnN0ZW4sIFBhZGR5LCBMYXVyaSwNCg0KZm9yIHRoZSBjYXNlIEkgcmVmZXJyZWQg dG8gaW5kZWVkIHRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBtYWNoaW5lLXJlYWRhYmxlIHNvIHRo YXQgdGhlIGNsaWVudCBjYW4gbGltaXQgaXRzIHF1ZXJ5IHNjb3BlLiBGb3Igb3VyIGNvbnN0cmFp bmVkIGRldmljZSBjb250ZXh0IEkgd291bGQgYXQgZmlyc3QgZXhwZWN0IGEgZmV3IGFkZGl0aW9u YWwgcmVzcG9uc2UgY29kZXMgZGVmaW5lZCwgYSBwZXJoYXBzIG1vcmUgaW50byB0aGUgZnV0dXJl IGEgY29tcGxldGUgInByb2JsZW0gZGV0YWlsIiBwYXlsb2FkLg0KDQpGb3IgdGhlIHRpbWUgYmVp bmcgaXQgY2FuIGJlIG9uZSBvZiA1LjAwLCA1LjAxIG9yIDQuMDMuDQoNCkVza28NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9A dHppLm9yZ10NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDEsIDIwMTcgODoyMg0KVG86IExh dXJpIFBpaWtpdmkgPExhdXJpLlBpaWtpdmlAYXJtLmNvbT4NCkNjOiBEaWprLCBFc2tvIDxlc2tv LmRpamtAcGhpbGlwcy5jb20+OyBjb3JlIChjb3JlQGlldGYub3JnKSA8Y29yZUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbY29yZV0gQ29BUCByZXNwb25zZSBjb2RlIGluIGNhc2Ugb2YgInJlc3Bv bnNlIHBheWxvYWQgdG9vIGxhcmdlIiA/IDQuMTM/DQoNCkhpIExhdXJpLA0KDQppbmRlZWQsIHRo ZSBDb1JFIHdvcmxkIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBIVFRQIHdvcmxkLg0KDQo+IEkgcHJv cG9zZSBhIGJpdCBvZiBpbmZvIGdhdGhlcmluZywgSSAgaW1hZ2luZSB0aGVyZSBhcmUgbW9yZSBz aW1pbGFyIGtpbmRzIG9mIHNpdHVhdGlvbnMgd2hlcmUgSFRUUCBoYXMgbm90IGhhZCB0aGUgcmln aHQgY29kZS4NCg0KV2hlbiB3ZSBkbyB0aGlzLCBJIHdvdWxkIGxpa2UgdG8gYXBwcm9hY2ggbmV3 IGNvZGVzIG5vdCBqdXN0IHdpdGgg4oCcd2hhdCBzaG91bGQgdGhlIHNlcnZlciBkb+KAnSBidXQg bW9yZSBpbXBvcnRhbnRseSB3aXRoIOKAnGhvdyBpcyB0aGUgY2xpZW50IGdvaW5nIHRvIHJlYWN0 IGRpZmZlcmVudGx54oCdLiAgSWYgdGhlIGVycm9yIHJlc3BvbnNlIGlzIGp1c3QgYWJvdXQgdGVs bGluZyB3aGF0IHdlbnQgd3Jvbmcgc28gYSBodW1hbiBjYW4gZGVidWcgdGhlIHNpdHVhdGlvbiwg ZGlhZ25vc3RpYyBwYXlsb2FkcyBhcmUgZmluZS4gIElmIHdlIG5lZWQgbW9yZSBkZXRhaWwgaW4g YW4gZXJyb3IgcmVzcG9uc2Ugc28gdGhlIGNsaWVudCBjYW4gZm9ybXVsYXRlIGEgYmV0dGVyIHJl cXVlc3QgYmFzZWQgb24gdGhvc2UgZGV0YWlscywgd2UgbWF5IHdhbnQgdG8gc3RhbmRhcmRpemUg 4oCccHJvYmxlbSBkZXRhaWzigJ0gcGF5bG9hZHMsIGluc3BpcmVkIGJ5IFJGQyA3ODA3Lg0KDQpH csO8w59lLCBDYXJzdGVuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRp YWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMg bWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5h bCBtZXNzYWdlLg0K From nobody Wed Feb 1 01:24:49 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71D4129407 for ; Wed, 1 Feb 2017 01:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE7066qQnI6D for ; Wed, 1 Feb 2017 01:16:43 -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 8FE8C12963B for ; Wed, 1 Feb 2017 01:16:37 -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 9144D46153; Wed, 1 Feb 2017 10:16:35 +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 36CD031B; Wed, 1 Feb 2017 10:16:34 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E17AC76B; Wed, 1 Feb 2017 10:16:33 +0100 (CET) Received: (nullmailer pid 11325 invoked by uid 1000); Wed, 01 Feb 2017 09:16:33 -0000 Date: Wed, 1 Feb 2017 10:16:33 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Message-ID: <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> References: <008901d27606$e70aed20$b520c760$@augustcellars.com> <821E2C39-5DA1-4A26-8B45-7F4FE4F8B7E4@tzi.org> <03a201d27750$930038c0$b900aa40$@augustcellars.com> <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="siw3zv4rzuh5w55d" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: X-Mailman-Approved-At: Wed, 01 Feb 2017 01:24:47 -0800 Cc: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , core , Martin Gunnarsson Subject: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 09:16:44 -0000 --siw3zv4rzuh5w55d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 01, 2017 at 08:32:24AM +0100, Carsten Bormann wrote: > Maybe we should move this discussion on-list. Now CC'd. (Context from the previous thread: What about plain IP addresses? What if a host has no name? What if a proxy needs to switch schemes inbetween due to modified transports?) > On 1 Feb 2017, at 08:08, Jim Schaad wrote: > >=20 > > URL of the server >=20 > Well, we need to authenticate the Uri-Path/Uri-Query part, as that may be= the essence of the request. >=20 > But you are right that the authority part of the URL is more volatile > in CoAP than in HTTP, as may be the scheme. So maybe authenticating > the origin (scheme + authority) can be substituted by some data > destination authentication. Is that something we always want to do? If we switched to merely using the security context when facing the application (ie. the part that trusts OSCOAP with its unprotected messages), I'm uncertain about what addresses the application would use, and what that would mean for being part of the linkable web. To me, using crypto parts (be it the CID or some derivative of the key) reminds me of the .onion naming scheme (and the troubles it causes). Would an application that uses OSCOAP really want to substitute linking to `coap://host.domain/path` with `coap+oscoap://hex-key/path`? (Because if that's what we're protecting, that's what the application gets as trustworthy data). Is there a middle ground, where applications can still use name resolution and rely on the OSCOAP layer to figure out which keys are trusted to sign off the given host name? > Is the security association for data destination authentication always > identical to that we use for the authentication in general? Do you mean situations in which the individual device can vouch for its data but is ignorant of its own name, and a device inbetween (like a bus arbiter) would add a secured name to the data? Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --siw3zv4rzuh5w55d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAliRp2kACgkQOY0REtOk veE9ew//eXXgihAKPPlpfVp91c3xB2BHWDQT54NyxsmAiiGbw3sq+L4ZxDsEusht i9Lz6djX8jljZr7LmLqdKQrJ1IeWDZzcbtxQm/1AOf0pZbX2Jhe6kMzlwyH+OyJI e+D7r527GVuxsdr9HNNdsjbAbUs7+HIjW9j37bxq5EK/hzFP7G7W7s6rxhzJf5jf w7t/dgOTgwA0nRNAvKwXrDDeRup+Xo5SxxNvxY6MvMz5k5qlVNoTqCEX8P1cjS9j ZEsHvEXsbCwnOWnSiz+LFHirmWdPPvh829Vnnfootq9tTBEaUxFRUkndlPHQtqEg MPEcYQY1C8mvcKoEN+Zc0TxoBgYXlBO5feY8pE7E13+MneeAuW6Rw8aW3RF5/MBv 9FVRJ51pcBknJpofpFEF+F0tuSpk1+BwBPkDa/2ybKXFhdGsrSlYu22TfAphZTC1 QnIGpqp/8/FPHiSWADE4fKMwoKloxaxmPBunDw6IGQlCErD9iPHnwszHz35Boq2L 9Ntc/GGraaELSi4DiH7TtKE6NSxMhMkexlT/mdMwfO9mahf0MZVe7onXOrNMzmgm 4JBA8ECtdqk/2bo7EAqsZLrtT/JDY2kqsTXR+4QZPFO6b/RbkJeuIaEyNKXyeB2F /4wCSFWs4aBGa1ygC3UJiy8NcqO7pgSjYpVtd4u6/EbQWdD+i7g= =mSJh -----END PGP SIGNATURE----- --siw3zv4rzuh5w55d-- From nobody Wed Feb 1 01:34:17 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBACB129970 for ; Wed, 1 Feb 2017 01:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivv62aN1_sG9 for ; Wed, 1 Feb 2017 01:34:15 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205F212996A for ; Wed, 1 Feb 2017 01:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v119YCw6005727 for ; Wed, 1 Feb 2017 10:34:12 +0100 (CET) Received: from [192.168.217.124] (p5DC7E5A6.dip0.t-ipconnect.de [93.199.229.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vCyd02DkVz3Zqt; Wed, 1 Feb 2017 10:34:12 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> Date: Wed, 1 Feb 2017 10:34:10 +0100 X-Mao-Original-Outgoing-Id: 507634450.232559-860b232c0781deb52dc80c4368348a7a Content-Transfer-Encoding: quoted-printable Message-Id: References: <008901d27606$e70aed20$b520c760$@augustcellars.com> <821E2C39-5DA1-4A26-8B45-7F4FE4F8B7E4@tzi.org> <03a201d27750$930038c0$b900aa40$@augustcellars.com> <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> To: core X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 09:34:17 -0000 (When you reply to the referenced message, please trim the recipient = list =E2=80=94 with a very long CC list, the chairs have to moderate = every single message.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Feb 1 02:03:51 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F16E1298D3 for ; Wed, 1 Feb 2017 02:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVaTHhbBcn6O for ; Wed, 1 Feb 2017 02:03:47 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.173]) (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 C21B0129412 for ; Wed, 1 Feb 2017 02:03:46 -0800 (PST) Received: from [85.158.138.179] by server-13.bemta-3.messagelabs.com id 0F/AC-25657-082B1985; Wed, 01 Feb 2017 10:03:44 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRWlGSWpSXmKPExsVy+MUXQ92GTRM jDHou8VgcmXKX1WLf2/XMFu/uvWV2YPZYM28No8eSJT+ZPKYtygxgjmLNzEvKr0hgzVjyZw5T wW3pism3+1gaGNdIdzFycQgJbGOUaOzYzA7hHGKUWLa8mRHOebfyKwuEs4lR4mvTGtYuRk4ON gFXiaO77rCD2CICnhI/519n6mLk4GAW0JKYO8kRJCwsEC5xoeUHVEmExPvJc5kgbCeJyYcWsY KUswioSEz7LAYS5hUIlZi89CozxKqnjBLnHtwEW8UpYC3x8UQ7G4jNKCAr8aVxNTOIzSwgLnH ryXywmRICAhJL9pxnhrBFJV4+/scKcY6mxPpd+hDlihJTuh+yQ+wSlDg58wkLiC0koCpx4tAc tgmMYrOQTJ2F0D0LSfcsJN0LGFlWMaoXpxaVpRbpGuklFWWmZ5TkJmbm6BoaGOvlphYXJ6an5 iQmFesl5+duYgTGWj0DA+MOxlPNzocYJTmYlER50zsmRAjxJeWnVGYkFmfEF5XmpBYfYpTh4F CS4K3eODFCSLAoNT21Ii0zBxj1MGkJDh4lEV4NkDRvcUFibnFmOkTqFKOilDjvJpCEAEgiozQ Prg2WaC4xykoJ8zIyMDAI8RSkFuVmlqDKv2IU52BUEuZ9CDKFJzOvBG76K6DFTECL3V/1gSwu SURISTUwVoodFnHWNpZvVZivVcx4yWZSVWnw2y6DwtNX/X+UfPi4Rab6ngXzmoPtFf8nNZdeN Xu9YfWMU9FSDuIfG43XC89ov/fU+9XZu3EbbrnVbJsWXF6nvfBCpmGlmZ7aaX9Lo1uvZYvkC1 mNZwr4H5yppNoxQX9hf9zkT8e3zcgynmrtluA+5ZuBEktxRqKhFnNRcSIA3oJ/ny8DAAA= X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-10.tower-169.messagelabs.com!1485943423!90349687!1 X-Originating-IP: [195.232.244.49] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15856 invoked from network); 1 Feb 2017 10:03:44 -0000 Received: from msedge4.vodafone.com (HELO voxe04hw.internal.vodafone.com) (195.232.244.49) by server-10.tower-169.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 1 Feb 2017 10:03:44 -0000 Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Feb 2017 11:03:42 +0100 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH09W.internal.vodafone.com (47.73.211.213) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 1 Feb 2017 11:03:27 +0100 Received: from VOEXC15W.internal.vodafone.com (145.230.101.17) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 1 Feb 2017 11:03:26 +0100 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.118]) by voexc15w.internal.vodafone.com ([145.230.101.17]) with mapi id 14.03.0294.000; Wed, 1 Feb 2017 11:03:26 +0100 From: "Smith, Kevin, (R&D) Vodafone Group" To: Carsten Bormann , Lauri Piikivi Thread-Topic: [core] CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AQHSe+ap8EBavsJo8kadePi0QO/zP6FTqBoAgAAG/YCAADcoAA== Date: Wed, 1 Feb 2017 10:03:25 +0000 Message-ID: References: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> In-Reply-To: <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 10:03:49 -0000 SEkgYWxsLA0KDQpJIGdlbmVyYWwgaXQgbWFrZXMgc2Vuc2UgdG8gbGV0IHRoZSBjbGllbnQga25v dyB3aGV0aGVyIGl0IGNhbi9zaG91bGQgcmVwZWF0IHRoZSByZXF1ZXN0LiBJbiB0aGlzIGNhc2Ug d2UgY2FuIGFzc3VtZSB0aGF0ICdyZXNwb25zZSB0b28gbGFyZ2UnIGlzIGEgdGVtcG9yYXJ5IGNv bmRpdGlvbiAoaWYgbm90IHRoZW4gdGhlcmUgaXMgYSBiaWdnZXIgcHJvYmxlbSA6KSkNCg0KVGhl IGNsaWVudCBzaG91bGQgdGhlcmVmb3JlIGJlIGluZm9ybWVkIHRoYXQgKDEpIHRoZSBjb25kaXRp b24gaXMgcGVyY2VpdmVkIHRvIGJlIHRlbXBvcmFyeSBhbmQgKDIpIGEgcmVjb21tZW5kZWQgZGVs YXkgYmVmb3JlIHRoZSBjbGllbnQgcmVwZWF0cyB0aGUgcmVxdWVzdC4gVGhpcyBJTU8gcHV0cyB0 aGUgZXJyb3IgaW4gdGhlIDV4eCByYW5nZSwgYXMgdGhlIGNsaWVudCBoYXMgbm90IGRvbmUgYW55 dGhpbmcgd3JvbmcgYXMgc3VjaCwgYW5kIHRoZSBzYW1lIHJlcXVlc3QgYmVpbmcgbWFkZSBuIHNl Y29uZHMgbGF0ZXIgY291bGQgcmV0dXJuIGEgc3VjY2VzcyBjb2RlIGFuZCBhIG1hbmFnZWFibGUg cmVzcG9uc2UuDQoNClNvIG15IHByZWZlcmVuY2Ugd291bGQgc2ltcGx5IGJlIDUwMyBTZXJ2aWNl IFVuYXZhaWxhYmxlIFsxXSwgd2l0aCBhIFJldHJ5LUFmdGVyIGhlYWRlciBbMl06DQoNCiJUaGUg c2VydmVyIGlzIGN1cnJlbnRseSB1bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBh IHRlbXBvcmFyeSBvdmVybG9hZCBvciBzY2hlZHVsZWQgbWFpbnRlbmFuY2UsIHdoaWNoIHdpbGwg bGlrZWx5IGJlIGFsbGV2aWF0ZWQgYWZ0ZXIgc29tZSBkZWxheS4gVGhlIHNlcnZlciBNQVkgc2Vu ZCBhIFJldHJ5LUFmdGVyIGhlYWRlciBmaWVsZDEgdG8gc3VnZ2VzdCBhbiBhcHByb3ByaWF0ZSBh bW91bnQgb2YgdGltZSBmb3IgdGhlIGNsaWVudCB0byB3YWl0IGJlZm9yZSByZXRyeWluZyB0aGUg cmVxdWVzdC4iDQoNClNpbmNlIDV4eCBhbHNvIHJlY29tbWVuZHMgInRoZSBzZXJ2ZXIgU0hPVUxE IHNlbmQgYSByZXByZXNlbnRhdGlvbiBjb250YWluaW5nIGFuIGV4cGxhbmF0aW9uIG9mIHRoZSBl cnJvciBzaXR1YXRpb24sIGFuZCB3aGV0aGVyIGl0IGlzIGEgdGVtcG9yYXJ5IG9yIHBlcm1hbmVu dCBjb25kaXRpb24iIFszXSwgdGhlbiB0aGUgY2xpZW50IGNhbiBiZSBpbmZvcm1lZCB2aWEgdGhl IHJlcHJlc2VudGF0aW9uIHRoYXQgJ3Jlc3BvbnNlIHRvbyBsYXJnZScgd2FzIHRoZSB0ZW1wb3Jh cnkgY2F1c2UuDQoNCkFsbCBiZXN0LA0KS2V2aW4NClZvZGFmb25lIA0KDQpbMV0gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi02LjYuNCANClsyXSBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzIzMSNzZWN0aW9uLTcuMS4zDQpbM10gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi02LjYgDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQpTZW50OiAwMSBGZWJydWFyeSAyMDE3IDA3OjIyDQpU bzogTGF1cmkgUGlpa2l2aSA8TGF1cmkuUGlpa2l2aUBhcm0uY29tPg0KQ2M6IGNvcmUgKGNvcmVA aWV0Zi5vcmcpIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBDb0FQIHJlc3Bv bnNlIGNvZGUgaW4gY2FzZSBvZiAicmVzcG9uc2UgcGF5bG9hZCB0b28gbGFyZ2UiID8gNC4xMz8N Cg0KSGkgTGF1cmksDQoNCmluZGVlZCwgdGhlIENvUkUgd29ybGQgaXMgZGlmZmVyZW50IGZyb20g dGhlIEhUVFAgd29ybGQuDQoNCj4gSSBwcm9wb3NlIGEgYml0IG9mIGluZm8gZ2F0aGVyaW5nLCBJ ICBpbWFnaW5lIHRoZXJlIGFyZSBtb3JlIHNpbWlsYXIga2luZHMgb2Ygc2l0dWF0aW9ucyB3aGVy ZSBIVFRQIGhhcyBub3QgaGFkIHRoZSByaWdodCBjb2RlLg0KDQpXaGVuIHdlIGRvIHRoaXMsIEkg d291bGQgbGlrZSB0byBhcHByb2FjaCBuZXcgY29kZXMgbm90IGp1c3Qgd2l0aCDigJx3aGF0IHNo b3VsZCB0aGUgc2VydmVyIGRv4oCdIGJ1dCBtb3JlIGltcG9ydGFudGx5IHdpdGgg4oCcaG93IGlz IHRoZSBjbGllbnQgZ29pbmcgdG8gcmVhY3QgZGlmZmVyZW50bHnigJ0uICBJZiB0aGUgZXJyb3Ig cmVzcG9uc2UgaXMganVzdCBhYm91dCB0ZWxsaW5nIHdoYXQgd2VudCB3cm9uZyBzbyBhIGh1bWFu IGNhbiBkZWJ1ZyB0aGUgc2l0dWF0aW9uLCBkaWFnbm9zdGljIHBheWxvYWRzIGFyZSBmaW5lLiAg SWYgd2UgbmVlZCBtb3JlIGRldGFpbCBpbiBhbiBlcnJvciByZXNwb25zZSBzbyB0aGUgY2xpZW50 IGNhbiBmb3JtdWxhdGUgYSBiZXR0ZXIgcmVxdWVzdCBiYXNlZCBvbiB0aG9zZSBkZXRhaWxzLCB3 ZSBtYXkgd2FudCB0byBzdGFuZGFyZGl6ZSDigJxwcm9ibGVtIGRldGFpbOKAnSBwYXlsb2Fkcywg aW5zcGlyZWQgYnkgUkZDIDc4MDcuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpj b3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUN Cg== From nobody Wed Feb 1 11:24:25 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C256A129E89 for ; Wed, 1 Feb 2017 11:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkkkJ4Bx-gR7 for ; Wed, 1 Feb 2017 11:24:16 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01D2129E80 for ; Wed, 1 Feb 2017 11:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v11JNSWU014937; Wed, 1 Feb 2017 20:23:28 +0100 (CET) Received: from [192.168.217.124] (p5DC7E5A6.dip0.t-ipconnect.de [93.199.229.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vDChw0Z0Cz3bD7; Wed, 1 Feb 2017 20:23:28 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <011401d27cbf$83711630$8a534290$@augustcellars.com> Date: Wed, 1 Feb 2017 20:23:27 +0100 X-Mao-Original-Outgoing-Id: 507669807.453414-8a422dfb7fc41991a1d00fbd47044954 Content-Transfer-Encoding: quoted-printable Message-Id: <0E329A4B-C0B5-45A8-8177-E683B67640DF@tzi.org> References: <008901d27606$e70aed20$b520c760$@augustcellars.com> <821E2C39-5DA1-4A26-8B45-7F4FE4F8B7E4@tzi.org> <03a201d27750$930038c0$b900aa40$@augustcellars.com> <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> To: Jim Schaad , core X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 19:24:23 -0000 > On 1 Feb 2017, at 20:15, Jim Schaad wrote: >=20 > URL of the server That would be the origin part of the URI (scheme, authority, port) =E2=80=94= the rest of the URI of course still needs to be authenticated. (RFC 6454 defines the concept of origin, and explains why it is so = important in the HTTP Web =E2=80=94 may be less so in the CoAP Web.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Feb 1 11:34:25 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BAB129E7E for ; Wed, 1 Feb 2017 11:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY5Q4IZJBF4p for ; Wed, 1 Feb 2017 11:25:15 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE8B129552 for ; Wed, 1 Feb 2017 11:15:36 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Feb 2017 11:38:16 -0800 From: Jim Schaad To: =?iso-8859-2?Q?'Christian_Ams=FCss'?= , 'Carsten Bormann' References: <008901d27606$e70aed20$b520c760$@augustcellars.com> <821E2C39-5DA1-4A26-8B45-7F4FE4F8B7E4@tzi.org> <03a201d27750$930038c0$b900aa40$@augustcellars.com> <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> In-Reply-To: <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> Date: Wed, 1 Feb 2017 11:15:09 -0800 Message-ID: <011401d27cbf$83711630$8a534290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKV/B3tak6Mr3x9cqSiAkTOHxLF6gHSFUiTAmiUIIcCvyyE4QG6z+LLAJ/oYwMBRVQyBgGdOb3mApH468EBeJI6sAJqzZu3nzghPpA= Content-Language: en-gb X-Originating-IP: [24.21.96.37] Archived-At: X-Mailman-Approved-At: Wed, 01 Feb 2017 11:34:23 -0800 Cc: =?iso-8859-2?B?J01hbGm5YSBWdehpbmnmJw==?= , 'core' , 'Martin Gunnarsson' Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 19:25:16 -0000 I have apparently done a bad job of explaining what I was talking about = in my original message. Some of the original context appears to have been lost. 1. The key that is going to be used is still identified by a key = identifier in the message. That does not change from today. 2. Currently the URL of the server is included in a request as part of = the externally authenticated information. Thus, for example the string "coap:/[::1]" might be included in the authenticated information if I = was sending a message back to a server on the same machine. 3. It is my belief that having the text string URL for the server as = part of the authenticated information is both extraneous, the fact that the message can be decrypted is essentially equivalent, and potentially a problem if there are NATs or multiple proxies involved in the system. My suggestion has nothing to do with how messages are routed or how keys = are identified. Jim > -----Original Message----- > From: Christian Ams=FCss [mailto:c.amsuess@energyharvesting.at] > Sent: 01 February 2017 01:17 > To: Carsten Bormann > Cc: core ; Jim Schaad ; = Francesca > Palombini ; G=F6ran Selander > ; Martin Gunnarsson > ; John Mattsson > ; Jaime Jim=E9nez > ; Mali=B9a Vu=E8ini=E6 = ; > Ludwig Seitz > Subject: OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug = test) >=20 > On Wed, Feb 01, 2017 at 08:32:24AM +0100, Carsten Bormann wrote: > > Maybe we should move this discussion on-list. >=20 > Now CC'd. >=20 > (Context from the previous thread: What about plain IP addresses? What = if a > host has no name? What if a proxy needs to switch schemes inbetween = due > to modified transports?) >=20 > > On 1 Feb 2017, at 08:08, Jim Schaad wrote: > > > > > > URL of the server > > > > Well, we need to authenticate the Uri-Path/Uri-Query part, as that = may be > the essence of the request. > > > > But you are right that the authority part of the URL is more = volatile > > in CoAP than in HTTP, as may be the scheme. So maybe authenticating > > the origin (scheme + authority) can be substituted by some data > > destination authentication. Is that something we always want to do? >=20 > If we switched to merely using the security context when facing the > application (ie. the part that trusts OSCOAP with its unprotected messages), > I'm uncertain about what addresses the application would use, and what that > would mean for being part of the linkable web. >=20 > To me, using crypto parts (be it the CID or some derivative of the = key) > reminds me of the .onion naming scheme (and the troubles it causes). > Would an application that uses OSCOAP really want to substitute = linking to > `coap://host.domain/path` with `coap+oscoap://hex-key/path`? (Because = if > that's what we're protecting, that's what the application gets as trustworthy > data). >=20 > Is there a middle ground, where applications can still use name = resolution > and rely on the OSCOAP layer to figure out which keys are trusted to = sign off > the given host name? >=20 > > Is the security association for data destination authentication = always > > identical to that we use for the authentication in general? >=20 > Do you mean situations in which the individual device can vouch for = its data > but is ignorant of its own name, and a device inbetween (like a bus > arbiter) would add a secured name to the data? >=20 >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Wed Feb 1 12:58:00 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFF2129525 for ; Wed, 1 Feb 2017 12:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hguRnfSinEeO for ; Wed, 1 Feb 2017 12:57:51 -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 2E4311299E9 for ; Wed, 1 Feb 2017 12:57:50 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3F2DB46221; Wed, 1 Feb 2017 21:57:49 +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 8248F31B; Wed, 1 Feb 2017 21:57:48 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5822732; Wed, 1 Feb 2017 21:57:48 +0100 (CET) Received: (nullmailer pid 8521 invoked by uid 1000); Wed, 01 Feb 2017 20:57:47 -0000 Date: Wed, 1 Feb 2017 21:57:47 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Message-ID: <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> References: <03a201d27750$930038c0$b900aa40$@augustcellars.com> <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tn7w42ofyua3ythr" Content-Disposition: inline In-Reply-To: <011401d27cbf$83711630$8a534290$@augustcellars.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: 'Martin Gunnarsson' , =?utf-8?B?J01hbGnFoWEgVnXEjWluacSHJw==?= , 'core' Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 20:57:53 -0000 --tn7w42ofyua3ythr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, On Wed, Feb 01, 2017 at 11:15:09AM -0800, Jim Schaad wrote: > 3. It is my belief that having the text string URL for the server as part > of the authenticated information is both extraneous, the fact that the > message can be decrypted is essentially equivalent, and potentially a > problem if there are NATs or multiple proxies involved in the system. >=20 > My suggestion has nothing to do with how messages are routed or how keys = are > identified. thank you, that does make the topic of this thread clearer to me. Relying plainly on the CID or similar would interact badly with scenarios where virtual hosting is employed, or where a forward proxy is the termination point of OSCOAP: Say a CoAP gateway to a proprietary (or otherwise non-CoAP-capable) network is using virtual hosts to present devices behind it. In such a situation, if the host name were left out of the AAD, the Uri-Host could be switched out by a MITM, and the gateway would forward the request to the wrong device without that triggering security measures. We could move Uri-Host inside OSCOAP in such situations (however they're identified), but when proxying is involved, the information would still be needed outside, which I think led to the "A" category of options in OSCOAP. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --tn7w42ofyua3ythr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAliSS8QACgkQOY0REtOk veFswA/8DovU84uaSkfjxaZTUoBkt2WydTM3LNGpoPNy0i2Id1qcHuoa3qhRahxk 5wtSKu5pvULpIGyxD7RNI7TvghN/H99rEgzjjfVNTJXwVl+JnSlFjEA4GEJL92/1 Ms/p0P1xxEUC3curPFAtPEGhvv8Jv8ti5tTN0b4boLMC0i+Y2RoWv8LiVDmxOUSx opSU79xUyWQ/HmyrSTEozVDUY9CWY+WyVyFdaCMWFzfw5SWOcFKuWozXdySrK2+d fczqmqOkSibFtDuKdXxdHvaFegkjs3SJ+HUC8+9OVzDc+BiUbvhNG8z55qjWtXFX VTmS5IegE9AAAK8/cR9j+nOoYj2q37sE77xBKoNDzI4JqtjBc9skIdJROY2Mm7mk +kEI//y7uviny/1+khZMC/zMHSs11LI0oA1ZNluSFSb3C3gvRUxhKvr6RRuvmvzP 0YHk6CZRGQxVL3+IaeNzIYf10+a2v8RWRpyITkfj8VhOdG3NlRpZzCf7c9dYse8a tpczF7gDErdHrOodFLbOEI1y5UE5Z+Iw3LR2+APKF0nq4Z01iTW7BpbePs06Qnyv usCzkOVDN141Vq3DkgaT5V1L3Voli8OthNSmBnJ5nOU7xIlscQdQ3Mew9BhfRb6c XmycCuLyJHidvdzsAu5llg9AE4SS7d1tioFKcAtKW9D+qhgV8Ow= =A5+s -----END PGP SIGNATURE----- --tn7w42ofyua3ythr-- From nobody Wed Feb 1 13:22:16 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BEB12957F for ; Wed, 1 Feb 2017 13:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7oW-MqpMAA0 for ; Wed, 1 Feb 2017 13:22:12 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0107.outbound.protection.outlook.com [104.47.34.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E9A129594 for ; Wed, 1 Feb 2017 13:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GptaajWcoqUp7P9QXa8LLFlfdl1zGk4cprRgoREDsp0=; b=SHFeFPcSe8vzpGSXmUHOw8r315Uaz/vzkDMwEMd9BFJXNUdtrLiza4ucns45LuMHc/C44cEkBnWqV3BxQZcmi+o0wUGpWAL5XoAhFkuP39hJ426AdHoXPsIqydqdkXq9hogxaxMOXqQrPrzQFJoDH0PG09Bv3fTem9pU0fx9oH8= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Wed, 1 Feb 2017 21:22:10 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0874.021; Wed, 1 Feb 2017 21:22:09 +0000 From: Michel Veillette To: Core Thread-Topic: [I-D.ietf-core-yang-cbor] Thread-Index: AdJ8z4763NgupNsOQPuL+3tAsqx8xg== Date: Wed, 1 Feb 2017 21:22:09 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 44c29852-fa78-4490-c1d7-08d44ae861bd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2305; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 7:pyaqp29XVsu4rSU1WMnuaRYp7LCYD/oyUiBoOmdV5UE7W9Cl1X38OfI8tqpsOfFmc/jVeMwWfsF7CvLK0sjac9efbF7SCIpQk0u5Lum3cJ7B+oMOxIC51pd/Bo2xg0JgcTHl+rnb7/T2agxGDnWSLLc7vKrgDgzpTso96czODn2NXcblPrXGvUsblGhK6ZDufwzCFS33Uq3Ove3CAC9WzyOT6QTz3kjf/bhGkBu47X9fXyr8oF4zcuBjzTlwq0suD2oocjbmIucfaB1zUyCwSTXHddvGycSYfRnpts/Moh37RM1wuPY15NZRN4+SZkAv4TpglLHG9mHX+UvFbj+oWkjOCvuxuSRw79nlRRcO2aX5W6L/sWiU6u/HCNVTAkA20x0vf6d3fxzt4bbEYSWNysMlEht/Vk+Wrw1SuWXvIfuYHvMy3YvoX992bSfcSDbL3nXgViilRWYFn4Swkcf6H8NFMlI5Hh3SHKYbFuFCp3D52/Pj/AdD3oFLnEx4Gucycrq0/Zb0d5q/v8cp3hiPHJv9WWKBJaDvDT7Oe4O3cLCgwb5uY+ypt9S7KF5nHIB+ x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2305; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(199003)(189002)(25786008)(9686003)(6306002)(55016002)(99286003)(38730400001)(86362001)(6436002)(966004)(81156014)(81166006)(6506006)(2900100001)(77096006)(5660300001)(97736004)(54356999)(50986999)(8936002)(107886002)(92566002)(74316002)(66066001)(53936002)(7736002)(3660700001)(33656002)(305945005)(68736007)(102836003)(2906002)(189998001)(101416001)(3846002)(450100001)(6116002)(6916009)(110136003)(230783001)(3280700002)(7696004)(8676002)(105586002)(122556002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2017 21:22:09.5433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Subject: [core] [I-D.ietf-core-yang-cbor] X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 21:22:15 -0000 Draft [I-D.ietf-core-yang-cbor] have been updated based on the different co= mments received. In summary: - The normative references to [I-D.ietf-core-sid] have been removed. The YANG Schema Item iDentifier (SID) is now defined directly within this= draft (section 2.1). - Comments in diagnostic notations have been updated to adopt the new synta= x supported by "cbor.me" and used in different drafts. - CBOR keys are now identified as such to avoid confusion with keys defined= in YANG lists. Clean version available at: http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt=20 Diff available at: https://tools.ietf.org/rfcdiff?url1=3Dhttps://www.ietf.org/id/draft-ietf-co= re-yang-cbor-03.txt&url2=3Dhttp://core-wg.github.io/yang-cbor/draft-ietf-co= re-yang-cbor-latest.txt=20 Please send me your comments by Wednesday, February 8 for inclusion in this= revision. Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-531-3109 From nobody Wed Feb 1 13:26:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AFE129A0D for ; Wed, 1 Feb 2017 13:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV9QvDR-nets for ; Wed, 1 Feb 2017 13:26:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE0B12959F for ; Wed, 1 Feb 2017 13:26:35 -0800 (PST) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Feb 2017 13:49:30 -0800 From: Jim Schaad To: 'Carsten Bormann' , 'core' References: <008901d27606$e70aed20$b520c760$@augustcellars.com> <821E2C39-5DA1-4A26-8B45-7F4FE4F8B7E4@tzi.org> <03a201d27750$930038c0$b900aa40$@augustcellars.com> <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> <0E329A4B-C0B5-45A8-8177-E683B67640DF@tzi.org> In-Reply-To: <0E329A4B-C0B5-45A8-8177-E683B67640DF@tzi.org> Date: Wed, 1 Feb 2017 13:26:23 -0800 Message-ID: <014f01d27cd1$d8660760$89321620$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKV/B3tak6Mr3x9cqSiAkTOHxLF6gHSFUiTAmiUIIcCvyyE4QG6z+LLAJ/oYwMBRVQyBgGdOb3mApH468EBeJI6sAJqzZu3AUyK9EoC5ZEXip8Wtiiw Content-Language: en-gb X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 21:26:38 -0000 Right, but given that CoAP is using different security primitives I = think that the analysis is going to be completely different. In HTTP we are using public key cryptography. This means that we need = to match the origin as testified by the certificate with the origin that = we expected. We need to verify that we are not getting an answer back = from somebody else. In the CoAP web, we are using mutual authentication from shared secrets. = This means that we have the origin testified by the shared secret = rather than from the public key. The secret itself is the = authentication proof. Jim > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: 01 February 2017 11:23 > To: Jim Schaad ; core > Subject: Re: OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug > test) >=20 >=20 > > On 1 Feb 2017, at 20:15, Jim Schaad wrote: > > > > URL of the server >=20 > That would be the origin part of the URI (scheme, authority, port) = =E2=80=94 the rest > of the URI of course still needs to be authenticated. >=20 > (RFC 6454 defines the concept of origin, and explains why it is so = important in > the HTTP Web =E2=80=94 may be less so in the CoAP Web.) >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Feb 1 23:14:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194E01293EB for ; Wed, 1 Feb 2017 23:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5dfxCEIJKGI for ; Wed, 1 Feb 2017 23:14:48 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0BD127735 for ; Wed, 1 Feb 2017 23:14:48 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-0c-5892dc668acf Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id C5.96.28805.66CD2985; Thu, 2 Feb 2017 08:14:46 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 08:14:16 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , Jim Schaad , 'core' Thread-Topic: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) Thread-Index: AQHSfGvjE6VaMkshukypezc5Z2aFzaFUdWaAgAAcrYCAAL0BgA== Date: Thu, 2 Feb 2017 07:14:16 +0000 Message-ID: References: <03a201d27750$930038c0$b900aa40$@augustcellars.com> <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> In-Reply-To: <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <8A8C0673BA5AC6499D6ECB4859C4D9E0@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7hG7anUkRBvPWqFgsv/CcxWLf2/XM Fqunf2dzYPbYOGc6m8fW/XeZPJYs+ckUwBzFZZOSmpNZllqkb5fAldEx4T5bwSm5igmnt7A3 MD6R7WLk5JAQMJF4fLyBvYuRi0NIYB2jxPm739hAEkICixkl3k4VBLHZBFwkHjQ8YgIpEhFo Z5Q4s/wrO0hCWCBE4vHBBawgtohAqMTFuavZIWwnifebjoINYhFQkZh7eQcTiM0rYCGx8N1U Voht91klFnQvYwRJcAq4Ssy9+QfMZhQQk/h+ag1YA7OAuMStJ/OZIE4VkFiy5zwzhC0q8fLx P7DFogJ6Esufr4GKK0ms2H4JaA4HUK+mxPpd+hBjrCXWTP/FDmErSkzpfsgOcY+gxMmZT1gm MIrNQrJtFkL3LCTds5B0z0LSvYCRdRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYKwd3PLb YAfjy+eOhxgFOBiVeHgNDCZFCLEmlhVX5h5ilOBgVhLhVb8BFOJNSaysSi3Kjy8qzUktPsQo zcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNTqoEx5/Kc6B3nj9+7JGttEPPkXM5RjlnKzg94 Y29o1tTcDyvjPbS0/M77Hy9bmN5xnVmYe4lDuaOo3thdbkvo8XypBT+rHrScaFO3Vo/7/Efv sMpHw/vc0k8+pzMv/6QZ1y+g5PVxv+OGW6c3pNxqvB/a/s3ylX+u2enI4qKdDU9un+Brnmch f65ViaU4I9FQi7moOBEA4408MLECAAA= Archived-At: Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 07:14:50 -0000 DQoNCk9uIDIwMTctMDItMDEgMjE6NTcsICJjb3JlIG9uIGJlaGFsZiBvZiBDaHJpc3RpYW4gQW1z w7xzcyINCjxjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGMuYW1zdWVzc0BlbmVy Z3loYXJ2ZXN0aW5nLmF0PiB3cm90ZToNCg0KPkhlbGxvIEppbSwNCj4NCj5PbiBXZWQsIEZlYiAw MSwgMjAxNyBhdCAxMToxNTowOUFNIC0wODAwLCBKaW0gU2NoYWFkIHdyb3RlOg0KPj4gMy4gIEl0 IGlzIG15IGJlbGllZiB0aGF0IGhhdmluZyB0aGUgdGV4dCBzdHJpbmcgVVJMIGZvciB0aGUgc2Vy dmVyIGFzDQo+PnBhcnQNCj4+IG9mIHRoZSBhdXRoZW50aWNhdGVkIGluZm9ybWF0aW9uIGlzIGJv dGggZXh0cmFuZW91cywgdGhlIGZhY3QgdGhhdCB0aGUNCj4+IG1lc3NhZ2UgY2FuIGJlIGRlY3J5 cHRlZCBpcyBlc3NlbnRpYWxseSBlcXVpdmFsZW50LCBhbmQgcG90ZW50aWFsbHkgYQ0KPj4gcHJv YmxlbSBpZiB0aGVyZSBhcmUgTkFUcyBvciBtdWx0aXBsZSBwcm94aWVzIGludm9sdmVkIGluIHRo ZSBzeXN0ZW0uDQo+PiANCj4+IE15IHN1Z2dlc3Rpb24gaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBo b3cgbWVzc2FnZXMgYXJlIHJvdXRlZCBvciBob3cNCj4+a2V5cyBhcmUNCj4+IGlkZW50aWZpZWQu DQo+DQo+dGhhbmsgeW91LCB0aGF0IGRvZXMgbWFrZSB0aGUgdG9waWMgb2YgdGhpcyB0aHJlYWQg Y2xlYXJlciB0byBtZS4NCj4NCj5SZWx5aW5nIHBsYWlubHkgb24gdGhlIENJRCBvciBzaW1pbGFy IHdvdWxkIGludGVyYWN0IGJhZGx5IHdpdGgNCj5zY2VuYXJpb3Mgd2hlcmUgdmlydHVhbCBob3N0 aW5nIGlzIGVtcGxveWVkLCBvciB3aGVyZSBhIGZvcndhcmQgcHJveHkgaXMNCj50aGUgdGVybWlu YXRpb24gcG9pbnQgb2YgT1NDT0FQOiBTYXkgYSBDb0FQIGdhdGV3YXkgdG8gYSBwcm9wcmlldGFy eSAob3INCj5vdGhlcndpc2Ugbm9uLUNvQVAtY2FwYWJsZSkgbmV0d29yayBpcyB1c2luZyB2aXJ0 dWFsIGhvc3RzIHRvIHByZXNlbnQNCj5kZXZpY2VzIGJlaGluZCBpdC4gSW4gc3VjaCBhIHNpdHVh dGlvbiwgaWYgdGhlIGhvc3QgbmFtZSB3ZXJlIGxlZnQgb3V0DQo+b2YgdGhlIEFBRCwgdGhlIFVy aS1Ib3N0IGNvdWxkIGJlIHN3aXRjaGVkIG91dCBieSBhIE1JVE0sIGFuZCB0aGUNCj5nYXRld2F5 IHdvdWxkIGZvcndhcmQgdGhlIHJlcXVlc3QgdG8gdGhlIHdyb25nIGRldmljZSB3aXRob3V0IHRo YXQNCj50cmlnZ2VyaW5nIHNlY3VyaXR5IG1lYXN1cmVzLg0KPg0KPldlIGNvdWxkIG1vdmUgVXJp LUhvc3QgaW5zaWRlIE9TQ09BUCBpbiBzdWNoIHNpdHVhdGlvbnMgKGhvd2V2ZXIgdGhleSdyZQ0K PmlkZW50aWZpZWQpLCBidXQgd2hlbiBwcm94eWluZyBpcyBpbnZvbHZlZCwgdGhlIGluZm9ybWF0 aW9uIHdvdWxkIHN0aWxsDQo+YmUgbmVlZGVkIG91dHNpZGUsIHdoaWNoIEkgdGhpbmsgbGVkIHRv IHRoZSAiQSIgY2F0ZWdvcnkgb2Ygb3B0aW9ucyBpbg0KPk9TQ09BUC4NCg0KDQpJbmRlZWQuIElu IHRoZSBmb3J3YXJkIHByb3h5IHNldHRpbmcgdGFyZ2V0ZWQgYnkgT1NDT0FQIHRoZSBjbGllbnQg a25vd3MNCnRoZSBVUkkgb2YgdGhlIG9yaWdpbiBzZXJ2ZXIgYW5kIGlzIHByb3RlY3RpbmcgdGhl IG1lc3NhZ2UgZm9yIHRoaXMgb3JpZ2luDQpzZXJ2ZXIsIHN1Y2ggdGhhdCB0aGUgb3JpZ2luIHNl cnZlciBpcyBhYmxlIHRvIHZlcmlmeSB0aGF0IHRoZSBtZXNzYWdlDQpyZWNlaXZlZCBmcm9tIHRo ZSBmb3J3YXJkIHByb3h5IGhhZCB0aGUgaW50ZW5kZWQgVVJJLg0KDQpJZiB3ZSB3YW50IHRvIHN1 cHBvcnQgYSBtb3JlIGdlbmVyYWwgc2V0dGluZyB3aGVyZSB0aGUgdXJpLWhvc3QvcGF0aCBjb3Vs ZA0KYmUgcmVwbGFjZWQvcmVtb3ZlZCAoc3RpbGwgbWFpbnRhaW5pbmcgdGhlIHVyaS1wYXRoL3F1 ZXJ5IGFzIENhcnN0ZW4NCnBvaW50ZWQgb3V0KSB3ZSBjb3VsZCByZW1vdmUgdGhlIHVuZW5jcnlw dGVkLXVyaSBpbiB0aGUgZXh0ZXJuYWxfYWFkLg0KDQpJZiB1bmVuY3J5cHRlZC11cmkgaXMgbm90 IHVzZWQsIGl0IGRvZXMgbm90IGxlYWQgdG8gdGhlIHdyb25nIHNlcnZlcg0KYmVsaWV2aW5nIGl0 IGlzIHRoZSB0YXJnZXQgZm9yIHRoZSByZXF1ZXN0LiBBcyBKaW0gcG9pbnRlZCBvdXQsIHRoZSBr ZXkNCnVzZWQgdG8gcHJvdGVjdCB0aGUgbWVzc2FnZSB3b3VsZCBiZSBkaWZmZXJlbnQgYW5kIHNv IHRoZSBpbnRlZ3JpdHkNCnZlcmlmaWNhdGlvbiB3b3VsZCBmYWlsIGluIHRoaXMgY2FzZS4NCg0K Tm90ZSB0aGF0IGluZGVwZW5kZW50bHkgb2YgdW5lbmNyeXB0ZWQtdXJpLCB0aGUgcHJveHkgaXMg YW55d2F5IG5vdCBhYmxlDQp0byB2ZXJpZnkgaWYgYSBNSVRNIGhhcyBzd2l0Y2hlZCB0aGUgdXJp LWhvc3QvcG9ydC4gVG8gdGhlIHByb3h5LCB0aGUNCnVyaS1ob3N0L3BvcnQgaXMgbmVlZGVkIHRv IGhhbmRsZSB0aGUgbWVzc2FnZSwgaW5jbHVkaW5nIHRoZSBjYXNlIG9mIHRoZQ0KcHJveHkgaXRz ZWxmIG9yIGEgdmlydHVhbCBob3N0LCBidXQgc2VjdXJpdHktd2lzZSBpdCBpcyBqdXN0IGEg4oCc aGludOKAnSwNCmFuYWxvZ291c2x5IHRvIHRoZSBraWQgYmVpbmcgYSBoaW50IHRvIHdoaWNoIGtl eSBpcyB1c2VkLiBUaGlzIGlzIGFzc3VtaW5nDQpkaWZmZXJlbnQgdmlydHVhbCBob3N0cyBldGMu IGhhdmUgZGlmZmVyZW50IGtleXMsIHdoaWNoIGFueXdheSBzaG91bGQgYmUNCnRoZSBzZWN1cml0 eSBwcmFjdGlzZS4NCg0KVGhlIGN1cnJlbnQgZm9ybWF0IGVuYWJsZXMgdGhlIHNlcnZlciB0byB2 ZXJpZnkgYm90aCB0aGF0IGl0IGlzIHRoZSB0YXJnZXQNCmFuZCB0aGF0IHRoZSByaWdodCBVUkkg aGFzIGJlZW4gdXNlZCwgbWF5YmUgdGhlIGxhdHRlciBpcyB0b28gYW1iaXRpb3VzPw0KDQoNCkfD tnJhbg0KDQo= From nobody Wed Feb 1 23:16:20 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328FB1293DA for ; Wed, 1 Feb 2017 23:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coeHVgWPD19J for ; Wed, 1 Feb 2017 23:16:17 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5106D127735 for ; Wed, 1 Feb 2017 23:16:17 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Feb 2017 23:39:13 -0800 From: Jim Schaad To: =?iso-8859-2?Q?'Christian_Ams=FCss'?= References: <03a201d27750$930038c0$b900aa40$@augustcellars.com> <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> In-Reply-To: <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> Date: Wed, 1 Feb 2017 23:16:04 -0800 Message-ID: <023801d27d24$39d2d9e0$ad788da0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJolCCH/z+Bq2eUKNECGHiVRh8LqwK/LIThAbrP4ssAn+hjAwFFVDIGAZ05veYCkfjrwQF4kjqwAmrNm7cBTIr0SgIKUQb4n5rVcVA= Content-Language: en-gb X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'core' Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 07:16:19 -0000 > -----Original Message----- > From: Christian Ams=FCss [mailto:c.amsuess@energyharvesting.at] > Sent: 01 February 2017 12:58 > To: Jim Schaad > Cc: 'Carsten Bormann' ; 'Mali=B9a Vu=E8ini=E6' > ; 'core' ; 'Martin Gunnarsson' > > Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: = OSCOAP > plug test) >=20 > Hello Jim, >=20 > On Wed, Feb 01, 2017 at 11:15:09AM -0800, Jim Schaad wrote: > > 3. It is my belief that having the text string URL for the server = as > > part of the authenticated information is both extraneous, the fact > > that the message can be decrypted is essentially equivalent, and > > potentially a problem if there are NATs or multiple proxies involved = in the > system. > > > > My suggestion has nothing to do with how messages are routed or how > > keys are identified. >=20 > thank you, that does make the topic of this thread clearer to me. >=20 > Relying plainly on the CID or similar would interact badly with = scenarios > where virtual hosting is employed, or where a forward proxy is the > termination point of OSCOAP: Say a CoAP gateway to a proprietary (or > otherwise non-CoAP-capable) network is using virtual hosts to present > devices behind it. In such a situation, if the host name were left out = of the > AAD, the Uri-Host could be switched out by a MITM, and the gateway = would > forward the request to the wrong device without that triggering = security > measures. >=20 > We could move Uri-Host inside OSCOAP in such situations (however = they're > identified), but when proxying is involved, the information would = still be > needed outside, which I think led to the "A" category of options in OSCOAP. If all we need is to have Uri-Host there is another alternative. Iff a Uri-Host field exists then authenticate JUST that field. I find the above case interesting as it demonstrates a need for this specific field in a way that is useful. I keep having this problem that = I am not sure what the setups are that CoAP is using. In this case do you = see a need for being able to have the scheme and port protected as well? It might make sense to do the same that as above, that is only authenticate = the fields if they are present and not try to infer what the content might = be. I still worry about having schemas change as you go through proxies = however. Jim >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Feb 2 01:27:41 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15A11293E8 for ; Thu, 2 Feb 2017 01:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgbgqXJkYlEH for ; Thu, 2 Feb 2017 01:27:38 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6401289B0 for ; Thu, 2 Feb 2017 01:27:37 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id AAC4F4622B; Thu, 2 Feb 2017 10:27:35 +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 E5C82220; Thu, 2 Feb 2017 10:27:34 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7CEA33BE; Thu, 2 Feb 2017 10:27:34 +0100 (CET) Received: (nullmailer pid 11935 invoked by uid 1000); Thu, 02 Feb 2017 09:27:32 -0000 Date: Thu, 2 Feb 2017 10:27:32 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?G=F6ran?= Selander Message-ID: <20170202092731.oavplivivbmcfws2@hephaistos.amsuess.com> References: <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cmr5s63tode6jd6i" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: 'core' Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 09:27:39 -0000 --cmr5s63tode6jd6i Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 02, 2017 at 07:14:16AM +0000, G=F6ran Selander wrote: > [...] This is assuming different virtual hosts etc. have different > keys, which anyway should be the security practise. I think this is key here. If we state that a context is bound to a host name, we don't need to verify the host name. This would, however, open up another question: How does this interact with role interchange (3.2, "endpoints MAY interchange [...] roles while maintaining the same security context")? Could a host name be bound to each of the sender/recipient IDs, and role reversal would not be possible if the possible if the client didn't have a hostname assigned for the context? Note that this topic *is* tricky already now, for the server asking back a client might not know what to put in the outer Uri-Host field, but it can at least work around it by picking something like `123456.client.my-hostname.my-domaincom` and send it for the client to ignore but verify. I hope I'm not overly nitpicking here (please tell me if I am). Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --cmr5s63tode6jd6i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAliS+34ACgkQOY0REtOk veGJnRAAlHWMwU2TQ0b+Ftfy1x3VaqyIDpcQLtenVRfcY+b9A9hHnLoHppISjd8M wR5OuSEiNCwX9L26IvLgPamo/peH0nW0dGHxGMsLoE0ovOn2nmWs0ApraupYscW7 umnGs0/lUqh7fpYxjVySYBvSvPju9sSTe12lbmc87cUW6tiEdG6Xy8DTtwqQOAzX efKicSEYqmRzR9sy5G7NXkuGMX1aw6K/vWAb62eB0vUv6PjOjnDhQCpotKTbbp8Y M48G8EoTZRew8J4DTjiFymX891az6kq99ov39KyNnh/Tiur3B2/FJZOR0+ideeIY 0rRDTtmzZTwBFIyG2a4iwZmu1N2/FYYLMP4wk+/Rs4czSoB8oLpa3Eck6jBYFsxv pUcOMotTqKI9dDVZ7SyvIUmUpBdT2Oe9qeRRecqGHY1f32iChLGIMxsqSgdVuW0C ckji7E3zq+AW+zo6XqJYeZWLUccwTjo+GihG4QnbxN6wWw3xU7cMfqOV/Webdz8o ClitNxg9hPTl4UgguUnoDCFfuzZ96heqnmTh6/27uZDVI+4bwhYyaDl8wRT4z6Tv af8hqDDFs+sUBuKbdD69lpJk+BteGrvCwDwiCrqefLnw9Bi2q5180uLCHrfA9tIg KJNHcboPZvlP1O+xRzzoDjza5bRj42u0x34iwzECfB5vDK9TZEs= =ZcD/ -----END PGP SIGNATURE----- --cmr5s63tode6jd6i-- From nobody Thu Feb 2 02:43:57 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CC2129422 for ; Thu, 2 Feb 2017 02:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HNXOTazJbkj for ; Thu, 2 Feb 2017 02:43:54 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 62937127076 for ; Thu, 2 Feb 2017 02:43:54 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-84-58930d68684f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 83.A5.14025.86D03985; Thu, 2 Feb 2017 11:43:52 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 11:43:00 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) Thread-Index: AQHSfGvjE6VaMkshukypezc5Z2aFzaFUdWaAgAAcrYCAAL0BgIAAFHkAgAAl2IA= Date: Thu, 2 Feb 2017 10:43:00 +0000 Message-ID: References: <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> <20170202092731.oavplivivbmcfws2@hephaistos.amsuess.com> In-Reply-To: <20170202092731.oavplivivbmcfws2@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7iG4G7+QIg64OQ4vlF56zWOx7u57Z YvX072wOzB4b50xn89i6/y6Tx5IlP5kCmKO4bFJSczLLUov07RK4Mi73r2Qu+CBecX1fA3sD 4wLxLkZODgkBE4kdXYfYQWwhgXWMEhsnVXQxcgHZixklJszcywSSYBNwkXjQ8AjMFhHwkJi4 9AtQAwcHs4C9xKu3xSBhYYEQiccHF7BClIRKXJy7mh3C9pPYveQyI4jNIqAi0fdpJVicV8BC 4tmH9ywQu/awSiyb3wxWxCngKjF9+3WwIkYBMYnvp9aA7WUWEJe49WQ+E8TRAhJL9pxnhrBF JV4+/ge2WFRAT2L58zVQcUWJj6/2MULcqSmxfpc+xBhrie1bb7JD2IoSU7ofQt0jKHFy5hOW CYzis5Bsm4XQPQtJ9ywk3bOQdC9gZF3FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERh/B7f8 Vt3BePmN4yFGAQ5GJR5eA4NJEUKsiWXFlbmHGCU4mJVEeEtYJkcI8aYkVlalFuXHF5XmpBYf YpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwBh+7/xn8Ttz0tkdti9yuFWrcOkjr+iN C5z5gZa9XclxjKZeT7at62nPmSCmdMRpmln0/qamq6/r3b7Fz46+W7H0+fHcbZ+lZST5l/hW 7Zdf12ewQFH/lNKipMqm86nJdpuEHJWsfr9oV9252I21zniKtfGnPXpcJaVbKt6cWDnlrMj1 J/e03iixFGckGmoxFxUnAgBkYb5huwIAAA== Archived-At: Cc: 'core' Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 10:43:56 -0000 SGkgQ2hyaXN0aWFuLA0KDQpJbmxpbmUuDQoNCk9uIDIwMTctMDItMDIgMTA6MjcsICJDaHJpc3Rp YW4gQW1zw7xzcyIgPGMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0Pg0Kd3JvdGU6DQoNCj5P biBUaHUsIEZlYiAwMiwgMjAxNyBhdCAwNzoxNDoxNkFNICswMDAwLCBHw7ZyYW4gU2VsYW5kZXIg d3JvdGU6DQo+PiBbLi4uXSBUaGlzIGlzIGFzc3VtaW5nIGRpZmZlcmVudCB2aXJ0dWFsIGhvc3Rz IGV0Yy4gaGF2ZSBkaWZmZXJlbnQNCj4+IGtleXMsIHdoaWNoIGFueXdheSBzaG91bGQgYmUgdGhl IHNlY3VyaXR5IHByYWN0aXNlLg0KPg0KPkkgdGhpbmsgdGhpcyBpcyBrZXkgaGVyZS4gSWYgd2Ug c3RhdGUgdGhhdCBhIGNvbnRleHQgaXMgYm91bmQgdG8gYSBob3N0DQo+bmFtZSwgd2UgZG9uJ3Qg bmVlZCB0byB2ZXJpZnkgdGhlIGhvc3QgbmFtZS4NCg0KR29vZCwgdGhlbiB3ZSBtYXkgaGF2ZSBh IHJlc29sdXRpb24gdG8gSmlt4oCZcyBpc3N1ZS4NCg0KPg0KPlRoaXMgd291bGQsIGhvd2V2ZXIs IG9wZW4gdXAgYW5vdGhlciBxdWVzdGlvbjoNCj4NCj5Ib3cgZG9lcyB0aGlzIGludGVyYWN0IHdp dGggcm9sZSBpbnRlcmNoYW5nZSAoMy4yLCAiZW5kcG9pbnRzIE1BWQ0KPmludGVyY2hhbmdlIFsu Li5dIHJvbGVzIHdoaWxlIG1haW50YWluaW5nIHRoZSBzYW1lIHNlY3VyaXR5IGNvbnRleHQiKT8N Cj5Db3VsZCBhIGhvc3QgbmFtZSBiZSBib3VuZCB0byBlYWNoIG9mIHRoZSBzZW5kZXIvcmVjaXBp ZW50IElEcywgYW5kIHJvbGUNCj5yZXZlcnNhbCB3b3VsZCBub3QgYmUgcG9zc2libGUgaWYgdGhl IHBvc3NpYmxlIGlmIHRoZSBjbGllbnQgZGlkbid0IGhhdmUNCj5hIGhvc3RuYW1lIGFzc2lnbmVk IGZvciB0aGUgY29udGV4dD8NCj4NCj5Ob3RlIHRoYXQgdGhpcyB0b3BpYyAqaXMqIHRyaWNreSBh bHJlYWR5IG5vdywgZm9yIHRoZSBzZXJ2ZXIgYXNraW5nIGJhY2sNCj5hIGNsaWVudCBtaWdodCBu b3Qga25vdyB3aGF0IHRvIHB1dCBpbiB0aGUgb3V0ZXIgVXJpLUhvc3QgZmllbGQsIGJ1dCBpdA0K PmNhbiBhdCBsZWFzdCB3b3JrIGFyb3VuZCBpdCBieSBwaWNraW5nIHNvbWV0aGluZyBsaWtlDQo+ YDEyMzQ1Ni5jbGllbnQubXktaG9zdG5hbWUubXktZG9tYWluY29tYCBhbmQgc2VuZCBpdCBmb3Ig dGhlIGNsaWVudCB0bw0KPmlnbm9yZSBidXQgdmVyaWZ5Lg0KPg0KDQpJ4oCZbSBub3Qgc3VyZSBJ IHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBleGFjdGx5LCBidXQgSSB0aGluayB5b3UgbWF5IGhh dmUNCmEgcG9pbnQuIA0KDQpPU0NPQVAgYXNzdW1lcyB0aGF0IHRoZSBjbGllbnQgY2FuIHJldHJp ZXZlIHRoZSBzZWN1cml0eSBjb250ZXh0IGZvciBhDQp0YXJnZXQgaG9zdC9yZXNvdXJjZSwgYW5k IGhvdyB0aGlzIGlzIGVzdGFibGlzaGVkIGlzIG91dCBvZiBzY29wZSAoZS5nLg0KdXNpbmcgYSB0 cnVzdGVkIHRoaXJkIHBhcnR5IGxpa2UgYW4gYXV0aG9yaXNhdGlvbiBzZXJ2ZXIgb3Igc29tZSBk aXNjb3ZlcnkNCnByb2NlZHVyZSkuIFRoZSBzYW1lIGFsc28gYXBwbGllcyB0byB0aGUgcm9sZSBp bnRlcmNoYW5nZSBhbmQgaG93IHRoZSBuZXcNCmNsaWVudC9mb3JtZXIgc2VydmVyIGFzc29jaWF0 ZXMgYSBob3N0L3Jlc291cmNlIG9mIHRoZSBuZXcgc2VydmVyL2Zvcm1lcg0KY2xpZW50IHRvIGFu IGV4aXN0aW5nIHNlY3VyaXR5IGNvbnRleHQuDQoNCkhvd2V2ZXIsIHRvIHN1cHBvcnQgdGhhdCBj YXNlIHdlIG1heSB3YW50IHRvIGdpdmUgYW4gZXhhbXBsZSBmb3IgaG93IGENCmNsaWVudCBjYW4g c2VjdXJlbHkgcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCB3aGF0IGhvc3QgbmFtZSB0byB1c2Ug d2hlbg0KYWNjZXNzaW5nIHJlc291cmNlcyBvbiBpdHMgaG9zdCBwcm90ZWN0ZWQgd2l0aCB0aGUg Y3VycmVudCBzZWN1cml0eQ0KY29udGV4dC4gRS5nLiB0aGUgY2xpZW50IGNvdWxkIG1ha2UgYSBQ T1NUIHRvIGEgY2VydGFpbiByZXNvdXJjZSBvbiB0aGUNCnNlcnZlciAodG8tYmUgY2xpZW50KSBj b250YWluaW5nIHN1Y2ggaW5mb3JtYXRpb24uIFdvdWxkIHNvbWV0aGluZyBsaWtlDQp0aGF0IGJl IHVzZWZ1bD8NCg0KDQo+DQo+SSBob3BlIEknbSBub3Qgb3Zlcmx5IG5pdHBpY2tpbmcgaGVyZSAo cGxlYXNlIHRlbGwgbWUgaWYgSSBhbSkuDQoNClRoYW5rcyBmb3IgYXNraW5nIGdvb2QgcXVlc3Rp b25zLCB5b3UgYXJlIGluIG5vIChiYWQpIHdheSBuaXRwaWNraW5nIGhlcmUhDQoNCkfDtnJhbiAN Cg0KDQoNCg== From nobody Thu Feb 2 03:07:07 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007CD129422 for ; Thu, 2 Feb 2017 03:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ntdaj1kE1ChH for ; Thu, 2 Feb 2017 03:07:05 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1914129405 for ; Thu, 2 Feb 2017 03:07:04 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-6a-589312d6a979 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 96.46.32317.6D213985; Thu, 2 Feb 2017 12:07:03 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 12:07:01 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) Thread-Index: AQHSfGvjE6VaMkshukypezc5Z2aFzaFUdWaAgAAcrYCAAL0BgIAAFHkAgAAsiQA= Date: Thu, 2 Feb 2017 11:07:01 +0000 Message-ID: References: <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> <20170202092731.oavplivivbmcfws2@hephaistos.amsuess.com> In-Reply-To: <20170202092731.oavplivivbmcfws2@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: <34C0D9B38208E14397E5849CB96DF572@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2J7uO51ockRBmfWsVksv/CcxWLf2/XM Fqunf2dzYPbYOGc6m8fW/XeZPJYs+ckUwBzFZZOSmpNZllqkb5fAlXHk3EbWghmcFU/vNbE1 MP7g6GLk5JAQMJE4dWgWI4gtJLCOUWLXCfsuRi4gezGjxNGO52wgCTYBF4kHDY+YQGwRAQ+J iUu/sHcxcnAwC9hLvHpbDBIWFgiReHxwAStESajExbmr2SFsP4mn196CxVkEVCT+fVvGBNLK K2AhMXMxC8SqPawSy+Y3g93AKeAqMX37dbBeRgExie+n1oCtZRYQl7j1ZD4TxM0CEkv2nGeG sEUlXj7+BzZfVEBPYvnzNVBxRYmPr/YxQpypKbF+lz7EGGuJtQ9a2SBsRYkp3Q/BVvEKCEqc nPmEZQKj+Cwk22YhdM9C0j0LSfcsJN0LGFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRG 38Etv3V3MK5+7XiIUYCDUYmH18BgUoQQa2JZcWXuIUYJDmYlEd6bvJMjhHhTEiurUovy44tK c1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamA0qTWXSZgTnPvKYWlyM6u1RalP 405lhW9Tgx4XM++zmRS0yyZzfmqhgZim7/Wq8HBB0Z4bfHv2TA1P3rHsSVTZ2QpL8YivXP+9 N2vc3/Bt46FF6n7ftPlv1fT8nXa6sp5Zp2n3P4/8EA6tF05mN7i5ozboPdziwp211/viM6nd G7xTtv3t+qXEUpyRaKjFXFScCAAVlgvLugIAAA== Archived-At: Cc: 'core' Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 11:07:06 -0000 DQpKdXN0IG9uZSBjbGFyaWZpY2F0aW9uOg0KDQpPbiAyMDE3LTAyLTAyIDEwOjI3LCAiQ2hyaXN0 aWFuIEFtc8O8c3MiIDxjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdD4NCndyb3RlOg0KDQo+ T24gVGh1LCBGZWIgMDIsIDIwMTcgYXQgMDc6MTQ6MTZBTSArMDAwMCwgR8O2cmFuIFNlbGFuZGVy IHdyb3RlOg0KPj4gWy4uLl0gVGhpcyBpcyBhc3N1bWluZyBkaWZmZXJlbnQgdmlydHVhbCBob3N0 cyBldGMuIGhhdmUgZGlmZmVyZW50DQo+PiBrZXlzLCB3aGljaCBhbnl3YXkgc2hvdWxkIGJlIHRo ZSBzZWN1cml0eSBwcmFjdGlzZS4NCj4NCj5JIHRoaW5rIHRoaXMgaXMga2V5IGhlcmUuIElmIHdl IHN0YXRlIHRoYXQgYSBjb250ZXh0IGlzIGJvdW5kIHRvIGEgaG9zdA0KPm5hbWUsIHdlIGRvbid0 IG5lZWQgdG8gdmVyaWZ5IHRoZSBob3N0IG5hbWUuDQoNClRoZXJlIG1heSBzdGlsbCBiZSBkaWZm ZXJlbnQgc2VjdXJpdHkgY29udGV4dHMgZm9yIGRpZmZlcmVudCByZXNvdXJjZXMsIG9yDQptdWx0 aXBsZSBzZWN1cml0eSBjb250ZXh0cyBmb3IgYSBnaXZlbiByZXNvdXJjZSwgb24gYSBnaXZlbiBz ZXJ2ZXIuIFRoZQ0KaW1wb3J0YW50IHRoaW5ncyBoZXJlIGFyZToNCg0KLSB0aGUgc2VydmVyIGNh biByZXNvbHZlIGEgcmVjZWl2ZWQgY29udGV4dCBpZGVudGlmaWVyIHRvIGEgc2VjdXJpdHkNCmNv bnRleHQNCg0KLSB0aGUgc2FtZSBzZWN1cml0eSBjb250ZXh0IGlzIG5vdCB1c2VkIG9uIGRpZmZl cmVudCBzZXJ2ZXJzIChzbyB0aGUNCmNvbnRleHQva2V5ICsgcmVzb3VyY2UgaWRlbnRpZmllciB1 bmlxdWVseSBpZGVudGlmaWVzIHRoZSByZXNvdXJjZSkuDQogDQoNCg0KR8O2cmFuDQoNCg0KDQoN Cg== From nobody Thu Feb 2 12:47:20 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4DD129566 for ; Thu, 2 Feb 2017 12:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d35whItXMDj6 for ; Thu, 2 Feb 2017 12:47:17 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA2D1294ED for ; Thu, 2 Feb 2017 12:47:17 -0800 (PST) Received: from hebrews (50.45.239.150) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Feb 2017 13:10:11 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , =?iso-8859-1?Q?'G=F6ran_Selander'?= References: <000401d27c5a$16499e70$42dcdb50$@augustcellars.com> <20170201091632.vs7eqbjwjmkj6idy@hephaistos.amsuess.com> <011401d27cbf$83711630$8a534290$@augustcellars.com> <20170201205746.rl6fa3wemytzr5lg@hephaistos.amsuess.com> <20170202092731.oavplivivbmcfws2@hephaistos.amsuess.com> In-Reply-To: <20170202092731.oavplivivbmcfws2@hephaistos.amsuess.com> Date: Thu, 2 Feb 2017 12:46:51 -0800 Message-ID: <034601d27d95$8467f410$8d37dc30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG6z+LLPt/JUFgg2xEJRMYpUn0YdwCf6GMDAUVUMgYBnTm95gKR+OvBAXiSOrACas2btwFMivRKAgpRBvgCoORkSwLruSo0oO6smoA= Content-Language: en-gb X-Originating-IP: [50.45.239.150] Archived-At: Cc: 'core' Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 20:47:19 -0000 > -----Original Message----- > From: Christian Ams=FCss [mailto:c.amsuess@energyharvesting.at] > Sent: 02 February 2017 01:28 > To: G=F6ran Selander > Cc: Jim Schaad ; 'core' > Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: = OSCOAP > plug test) >=20 > On Thu, Feb 02, 2017 at 07:14:16AM +0000, G=F6ran Selander wrote: > > [...] This is assuming different virtual hosts etc. have different > > keys, which anyway should be the security practise. >=20 > I think this is key here. If we state that a context is bound to a = host name, we > don't need to verify the host name. >=20 > This would, however, open up another question: >=20 > How does this interact with role interchange (3.2, "endpoints MAY > interchange [...] roles while maintaining the same security context")? > Could a host name be bound to each of the sender/recipient IDs, and = role > reversal would not be possible if the possible if the client didn't = have a > hostname assigned for the context? >=20 > Note that this topic *is* tricky already now, for the server asking = back a client > might not know what to put in the outer Uri-Host field, but it can at least > work around it by picking something like = `123456.client.my-hostname.my- > domaincom` and send it for the client to ignore but verify. >=20 >=20 > I hope I'm not overly nitpicking here (please tell me if I am). I think you might be overly nitpicking - however that is where I find = most of the problems in the world is when I do that. So don't stop on my account. The server name would be tied to the "recipient" name in side of the context. When you distribute, you could actually use the server name as = the recipient id in some cases - or in addition to it. Thus I would distribute: Context ID: abcd Master Secret: 12345 Recipient ID: Server Name Recipient ID: Server Name This could then be repeated for the multicast case. If the concept of a server name for an entity does not make sense, then the field could be omitted and you can continue per normal. You are going to have a server name tied to each end of the context, not = a single name for the context. Jim >=20 > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Feb 2 13:04:30 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3813129576 for ; Thu, 2 Feb 2017 13:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1oOxp5aE5qB for ; Thu, 2 Feb 2017 13:04:26 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0139.outbound.protection.outlook.com [104.47.38.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313A612954C for ; Thu, 2 Feb 2017 13:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GFCJ0GfMo1KekHEJPtSfiKRveKeJcIcidKmvQoz4CQg=; b=h3IqQWxEX4I0o1RBHYQFDqKVVmM95h8GObaAakJFWtZQk7dlN2wipn457rV/FjtfLL9cX/CmD0UPklX/Wio/1uQxLNWkAhxs4OILV9BTSDOtaMYJP0dBzgi+8OmazKrGYD5uOv10OtrPRyhvI0XYXl9rvQgX2SsmgdNCOxCJIa0= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2377.namprd03.prod.outlook.com (10.166.207.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 2 Feb 2017 21:04:22 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0860.027; Thu, 2 Feb 2017 21:04:22 +0000 From: Brian Raymor To: "core@ietf.org WG" Thread-Topic: Update on coap-tcp-tls Thread-Index: AdJxScsC6iI1fqrBQMWxOzkXD5og6wMSjYyA Date: Thu, 2 Feb 2017 21:04:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: dd7c0e04-7196-4271-4cf2-08d44baf1024 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2377; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2377; 7:11giA/fABrP0VyKTU8BsXmi+ZdhMO4WOGpnOh0ZSGEpO9B08Y/TjyQtrh9nlCr4uYcSlBxcF/7eNU/0ZMBUF3cAAZlbZ0XcEirfmlv49NTGDhL5D2HeT6Y/zz+l8d4eu0Ui/CgaLCeqXyi01VcV2ha00a/Y+HuSl8SAgPbsxVPPBvnNlyfIdO/VIDSImpt8JIETRocO3aMpAWJpU6kBg1laYVWoXTLOg8X6waUB3mT77V4luNSKzq3GpCMtcEmPqnkYhxEo3nKrgv/Yd6ZXoDObpzJVMyhHt3dMoZTDmcJtUmjmE2CwpCtntl201l1jyvZchwEVvgVjQZ5zmVKFE5t+66c5CDk5LGE6q2oHg2wv8r/te/5aXBqPhL241J52EM7CMVr1V6sprEZ34jbjVulbCbIjlH15SkJdJaE0nNCa2erByWEhOUSKKkqWBvM14hgZdPuBr63uL11yg4odfuFtC22EmIw9KVX9P4/pQ+6YshMOy3myLrvdPzEKPpX9/zkBK2wpjbDQjt/RZarIV09spiP2dLmju2Xz1bSNl7qroKyABlArk59FvT1NYYIah x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(6042181); SRVR:CY1PR03MB2377; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2377; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(199003)(99286003)(38730400001)(107886002)(2900100001)(97736004)(74316002)(7906003)(76176999)(50986999)(7736002)(54356999)(189998001)(7110500001)(86612001)(236005)(10090500001)(92566002)(10290500002)(230783001)(5005710100001)(86362001)(790700001)(102836003)(8990500004)(6116002)(3846002)(33656002)(81166006)(101416001)(561944003)(81156014)(229853002)(68736007)(8676002)(3660700001)(8936002)(2950100002)(106356001)(5660300001)(105586002)(6916009)(7696004)(6246003)(110136003)(3280700002)(10710500007)(6506006)(77096006)(66066001)(15650500001)(6306002)(54896002)(2420400007)(9686003)(606005)(55016002)(450100001)(25786008)(6436002)(53936002)(122556002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2377; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2380030B363CB75EDBBDADA2834C0CY1PR03MB2380namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 21:04:22.5084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2377 Archived-At: Subject: Re: [core] Update on coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 21:04:29 -0000 --_000_CY1PR03MB2380030B363CB75EDBBDADA2834C0CY1PR03MB2380namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jaime and I had a conference call with the draft-bormann-core-coap-sig-02 a= uthors (Carsten, Hannes, Klaus) to review https://github.com/core-wg/coap= -tcp-tls/issues and a related pull request - https://github.com/core-wg/coa= p-tcp-tls/pull/103 - related to Signaling. There were some design proposals from the meeting that I would like to shar= e for WG comment: https://github.com/core-wg/coap-tcp-tls/issues/82 There was consensus to remove the Server-Name Option in the upcoming coap= -tcp-tls-06. This feature has not been implemented. It provided minimal value at the cost of additional security consideratio= ns. It did offer a mechanism to set the default value for the URI-Host option= : For TLS, the base value for the Server-Name Option is given by the SNI v= alue. For Websockets, the base value for the Server-Name Option is given by th= e HTTP Host header field. Similar text will need to be added to -06 per - https://github.com/core-w= g/coap-tcp-tls/issues/108 https://github.com/core-wg/coap-tcp-tls/issues/69 Changing: Upon receipt of a Ping message, a single Pong message is returned wit= h the identical token. To [big breath]: Upon receipt of a Ping message, the receiver SHOULD return a single Pon= g message with the identical token as soon as practical, unless there is an option with delaying semantics, such as the Custody Option. ...Brian From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Raymor Sent: Tuesday, January 17, 2017 9:21 PM To: core@ietf.org WG Subject: [core] Update on coap-tcp-tls Most (21) of the WGLC issues have been addressed in the editor's draft and = closed: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=3D1 7 open issues remain - https://github.com/core-wg/coap-tcp-tls/issues: Signaling (5) Could the authors/contributors (Carsten, Hannes, Klaus) of draft-bormann-co= re-coap-sig-02 help clarify this set of issues - https://github.com/core-w= g/coap-tcp-tls/labels/request-clarification - Let me know if you'd prefer a= conference call to address. The remaining Signaling issue explores whether there are new requirements w= hen responding to a Ping - https://github.com/core-wg/coap-tcp-tls/issues/6= 9. Please review the issue for background and potential solutions. I'd welc= ome your thoughts. Securing CoAP issues (2) The Securing CoAP proposal was reviewed by G=F6ran and Hannes and "baked" o= n the list. It's ready to be closed: https://github.com/core-wg/coap-tcp-tls/issues/11 Bill has proposed an amendment for Securing WebSockets. Any WG comments? https://github.com/core-wg/coap-tcp-tls/issues/102 Thanks, ...Brian --_000_CY1PR03MB2380030B363CB75EDBBDADA2834C0CY1PR03MB2380namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Jaime and I had a conference call with the draft-bor= mann-core-coap-sig-02 authors (Carsten, Hannes, Klaus)  to review &nbs= p;https://github= .com/core-wg/coap-tcp-tls/issues and a related pull request - https://github.com/core-wg/coap-tcp-tls/pull/103 - related to Signali= ng.

 

There were some design proposals from the meeting th= at I would like to share for WG comment:

 

https://github.com/core-wg/coap-tcp-tls/issues/82<= /p>

 

  There was consensus to remove the Server-Name= Option in the upcoming coap-tcp-tls-06. This feature has not been implemen= ted.

  It provided minimal value at the cost of addi= tional security considerations.

 

  It did offer a mechanism to set the defa= ult value for the URI-Host option:

 

   For TLS, the base value for the= Server-Name Option is given by the SNI value.

   For Websockets, the base value = for the Server-Name Option is given by the HTTP Host header field.

 

  Similar text will need to be added to -06 per= - https://github.com/core-wg/coap-tcp-tls/issues/108

 

https://github.com/core-wg/coap-tcp-tls/issues/69<= /p>

 

  Changing:

 

      Upon receipt of a Pin= g message, a single Pong message is returned with the identical token.=

 

  To [big breath]:

 

    Upon receipt of a Ping message, t= he receiver SHOULD return a single Pong message with the identical token as= soon as practical, unless

    there is an option with delaying = semantics, such as the Custody Option.

 

 

…Brian

 

From: core [mailto:core-bounces@ietf.org] = On Behalf Of Brian Raymor
Sent: Tuesday, January 17, 2017 9:21 PM
To: core@ietf.org WG <core@ietf.org>
Subject: [core] Update on coap-tcp-tls

 

 

Most (21) of the WGLC issues have been addressed in = the editor’s draft and closed:

https://github.com/core-wg/coap-tcp-tls/milestone/4?= closed=3D1

 

7 open issues remain - https://github.c= om/core-wg/coap-tcp-tls/issues:

 

Signaling (5)

 

Could the authors/contributors (Carsten, Hannes, Kla= us) of draft-bormann-core-coap-sig-02 help clarify this set of issues - &nb= sp;https://github.com/core-wg/coap-tcp-tls/labels/request-clarificati= on – Let me know if you’d prefer a conference call to address.

 

The remaining Signaling issue explores whether there= are new requirements when responding to a Ping - https://githu= b.com/core-wg/coap-tcp-tls/issues/69. Please review the issue for backg= round and potential solutions. I’d welcome your thoughts.<= /span>

 

Securing CoAP issues (2)

 

The Securing CoAP proposal was reviewed by G=F6ran a= nd Hannes and “baked” on the list. It’s ready to be close= d:

https://github.com/core-wg/coap-tcp-tls/issues/11<= /span>

 

Bill has proposed an amendment for Securing WebSocke= ts. Any WG comments?

https://github.com/core-wg/coap-tcp-tls/issues/102

 

Thanks,

…Brian

 

 

 

 

--_000_CY1PR03MB2380030B363CB75EDBBDADA2834C0CY1PR03MB2380namp_-- From nobody Thu Feb 2 13:57:24 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2082B1299FD for ; Thu, 2 Feb 2017 13:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAKzQZdECJn2 for ; Thu, 2 Feb 2017 13:57:20 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9391299E2 for ; Thu, 2 Feb 2017 13:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v12LvGeC012205; Thu, 2 Feb 2017 22:57:16 +0100 (CET) Received: from [192.168.217.124] (p5DC7E5A6.dip0.t-ipconnect.de [93.199.229.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vDv3w20K3z3ZM1; Thu, 2 Feb 2017 22:57:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Thu, 2 Feb 2017 22:57:15 +0100 X-Mao-Original-Outgoing-Id: 507765435.483468-bfe3625a703ccb5ec19918d9e0055372 Content-Transfer-Encoding: quoted-printable Message-Id: <38DA82F4-6015-4A12-AD62-6D4D1ECFDE91@tzi.org> References: To: Brian Raymor X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Update on coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 21:57:22 -0000 On 2 Feb 2017, at 22:04, Brian Raymor = wrote: >=20 > Upon receipt of a Ping message, the receiver SHOULD return a = single Pong message with the identical token as soon as practical, = unless > there is an option with delaying semantics, such as the Custody = Option. Maybe separate the two levels of requirement here: =E2=80=94 return single Pong message with the identical token (MUST) =E2=80=94 as soon as practical, unless option in Ping with delaying = semantics (SHOULD) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Feb 2 14:04:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2371299FE for ; Thu, 2 Feb 2017 14:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q68TBz2t97x6 for ; Thu, 2 Feb 2017 14:04:02 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0132.outbound.protection.outlook.com [104.47.33.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB194129592 for ; Thu, 2 Feb 2017 14:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9VI2d6li5nMQRdse2Lv1Eyqqu30xB1J1zMZuejJkRjA=; b=AMprvK2bXRX+1Ee//2Oz6aY5mzi4LHG4B8Vi7QCXhnE8fLaTSA91hVoJqBHAQfn0UeYvnTveKXbwlJKEr1J9JkX19uRQ3D4D+ZEcQlahijJF2r0VHx9AmR8i3vc+7R3aIkH71ioqU8RDN9VWKTXYJGbtMKdDzXXtPu6ESJzsC90= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 2 Feb 2017 22:03:58 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0860.027; Thu, 2 Feb 2017 22:03:58 +0000 From: Brian Raymor To: Carsten Bormann Thread-Topic: [core] Update on coap-tcp-tls Thread-Index: AdJxScsC6iI1fqrBQMWxOzkXD5og6wMSjYyAAALTz4AAAC48UA== Date: Thu, 2 Feb 2017 22:03:58 +0000 Message-ID: References: <38DA82F4-6015-4A12-AD62-6D4D1ECFDE91@tzi.org> In-Reply-To: <38DA82F4-6015-4A12-AD62-6D4D1ECFDE91@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 2601230e-5f4a-4736-a70d-08d44bb763ab x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2380; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:c83cqvmO53yTtCMVi69qpRUrI0FK7S+PhrsnjET6IbDU2McEv3DspNVNF6zprD25EcRwA/jJOwEvku2D1GBt/dKmdzTC8KYK5z9O2dliQyifTx4EyBQ65ZkjrGK5rCbaYp1qfkdCDjXsV5ruSx+esEyIjvkDMBmicTFzJqz8U2EJpG12nwxy+UQQ5447PyI9HS2PKk0Lny8q4rjHEr5kyaFGSUsDiF77CWa78/DZxaXoUyHTQtPAHKY03+4qI+lpCqwB3s8uPgXcADvHum3Smeejt5gkMAP9bao4FbEk5MCG+UamadirnB4bCJJJ7ZdGqc+58iPDSAfpMgzjjm17+aNXfBPjIM3lMFCxAaHMIvP/9Utq1YjM+UfzBmLrU0dWDuX2Yt6/j70oWeqnXBx0RgyDcRT0BYrUwmqzExvd2LAa3z8niVhW71OtDBtsi8nO4ASF09ZuekyioRkjTMidNreR+W63vHvLgnVHaBJNAyCzqdf6h6fTmNcRehR4N4VrWCVFaAzEw2vl46GwF6gzHQ19/8PyQg4zpPd5qXCxykZeh0z8CTrFt/aJpmpfwU6u x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(7006099)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(199003)(189002)(24454002)(377454003)(13464003)(3280700002)(3846002)(102836003)(2906002)(6916009)(4326007)(66066001)(7696004)(110136003)(81156014)(2950100002)(8676002)(81166006)(8936002)(53546003)(3660700001)(15650500001)(6116002)(99286003)(55016002)(6246003)(229853002)(77096006)(5660300001)(6506006)(9686003)(6436002)(38730400001)(25786008)(5005710100001)(76176999)(189998001)(97736004)(50986999)(122556002)(10090500001)(86362001)(54356999)(101416001)(7736002)(86612001)(74316002)(92566002)(33656002)(305945005)(10290500002)(68736007)(2900100001)(53936002)(106356001)(105586002)(8990500004)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 22:03:58.7122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Update on coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 22:04:03 -0000 R29vZCBwb2ludC4NCg0KVXBvbiByZWNlaXB0IG9mIGEgUGluZyBtZXNzYWdlLCB0aGUgcmVjZWl2 ZXIgTVVTVCByZXR1cm4gYSBQb25nIG1lc3NhZ2Ugd2l0aCBhbiBpZGVudGljYWwgdG9rZW4gaW4g cmVzcG9uc2UuDQpVbmxlc3MgdGhlcmUgaXMgYW4gb3B0aW9uIHdpdGggZGVsYXlpbmcgc2VtYW50 aWNzIHN1Y2ggYXMgdGhlIEN1c3RvZHkgT3B0aW9uLCBpdCBTSE9VTEQgcmVzcG9uZCBhcyBzb29u IGFzIHByYWN0aWNhbC4NCg0KVGhhbmtzLA0KLi4uQnJpYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10gDQpT ZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMiwgMjAxNyAxOjU3IFBNDQpUbzogQnJpYW4gUmF5bW9y IDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4NCkNjOiBjb3JlQGlldGYub3JnIFdHIDxjb3Jl QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBVcGRhdGUgb24gY29hcC10Y3AtdGxzDQoN Ck9uIDIgRmViIDIwMTcsIGF0IDIyOjA0LCBCcmlhbiBSYXltb3IgPEJyaWFuLlJheW1vckBtaWNy b3NvZnQuY29tPiB3cm90ZToNCj4gDQo+ICAgICBVcG9uIHJlY2VpcHQgb2YgYSBQaW5nIG1lc3Nh Z2UsIHRoZSByZWNlaXZlciBTSE9VTEQgcmV0dXJuIGEgc2luZ2xlIFBvbmcgbWVzc2FnZSB3aXRo IHRoZSBpZGVudGljYWwgdG9rZW4gYXMgc29vbiBhcyBwcmFjdGljYWwsIHVubGVzcw0KPiAgICAg dGhlcmUgaXMgYW4gb3B0aW9uIHdpdGggZGVsYXlpbmcgc2VtYW50aWNzLCBzdWNoIGFzIHRoZSBD dXN0b2R5IE9wdGlvbi4NCg0KTWF5YmUgc2VwYXJhdGUgdGhlIHR3byBsZXZlbHMgb2YgcmVxdWly ZW1lbnQgaGVyZToNCg0K4oCUIHJldHVybiBzaW5nbGUgUG9uZyBtZXNzYWdlIHdpdGggdGhlIGlk ZW50aWNhbCB0b2tlbiAoTVVTVCkg4oCUIGFzIHNvb24gYXMgcHJhY3RpY2FsLCB1bmxlc3Mgb3B0 aW9uIGluIFBpbmcgd2l0aCBkZWxheWluZyBzZW1hbnRpY3MgKFNIT1VMRCkNCg0KR3LDvMOfZSwg Q2Fyc3Rlbg0KDQo= From nobody Sat Feb 4 01:44:28 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6806212961C for ; Sat, 4 Feb 2017 01:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDu16tDTgRkO for ; Sat, 4 Feb 2017 01:44:24 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE96129617 for ; Sat, 4 Feb 2017 01:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v149iJYl027442 for ; Sat, 4 Feb 2017 10:44:19 +0100 (CET) Received: from [192.168.217.124] (p5DC7E5A6.dip0.t-ipconnect.de [93.199.229.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vFpjH2Grvz3b02; Sat, 4 Feb 2017 10:44:19 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 507894257.759747-af2eacd7cad429b46102cb9d45ea9c47 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 4 Feb 2017 10:44:17 +0100 Message-Id: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Feb 2017 09:44:26 -0000 In CoAP, the Uri-Host option is optional in a request. RFC 7252 section 5.10.1 defines a default value for Uri-Host (and Uri-Port) based on the connection parameters (destination address and port of the UDP packet). The default value allows the client to not send the Uri-Host if the value would match, and the server to reconstruct a valid value for the host part of the URI being addressed. (I'm not mentioning Uri-Port again below, but similar considerations apply for all the cases below.) The definition based on the IP address/UDP port of course is not applicable to alternate transports. We are running into this right now with CoAP over TCP/TLS/Websockets, and will do so again with CoAP over SMS. I think we should try to maintain the property as stated in 5.10.1 that "The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers". More importantly, reconstructing the URI based on the default value and then making a request to that URI should not lead to a different place. Note that for a reliable byte stream connection, we have to provide default values for both directions, as both endpoints of the connection can play both client and server. For CoAP over TCP, it is proably OK to slightly adapt the definition of the default to the IP address and port of the end of the connection receiving the CoAP request. (It is not quite clear that the acceptor of the TCP connection could create a new connection by opening a TCP connection to host/port of where it accepted the connection from, but at least there is some address ownership.) For WebSockets, that does not quite work. The WebSocket hostname is needed to make the connection, so that should also be the default value of the Uri-Host for requests in the direction from the WebSocket client to the WebSocket server. What about the inverse direction? (In practice, it is rather unlikely that a WebSockets client also is a WebSockets server. Still, it is very useful for the CoAP endpoint at the WebSocket server to call back the CoAP endpoint at the Websocket client, even if that is based on "You, whoever just called me"". But we don't have anonymous, ephemeral hosts in URIs. Yet.) For TLS, the TCP approach would also work, unless there is SNI -- in that case the default in the direction TLS client to TLS server should shift to the SNI name. There is no way to indicate reverse SNI, though -- can we be sure that is never needed? Would a client certificate change anything here? In the last authors' call, we agreed to remove the signalling option that would allow to set a different default URI host (used to be called "Server-Name" analogously to SNI; a better name is "Default-Uri-Host"), as we weren't aware of an implementation. Do we need to keep it to solve anything of the above? Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Feb 4 03:39:00 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CFC129A32 for ; Sat, 4 Feb 2017 03:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnVxOr1KfC1t for ; Sat, 4 Feb 2017 03:38:56 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB95129A41 for ; Sat, 4 Feb 2017 03:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v14BcpaG010922 for ; Sat, 4 Feb 2017 12:38:52 +0100 (CET) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vFsFR66jFz3b17 for ; Sat, 4 Feb 2017 12:38:51 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id c85so67408524wmi.1 for ; Sat, 04 Feb 2017 03:38:51 -0800 (PST) X-Gm-Message-State: AMke39lXxFcKgtKnj4MHuiwY7Nz0WlmaRZBstGFs54POfQIVXGXp1kMzPEty3mU1TicCXqzp3r/zGBC56wzwwA== X-Received: by 10.28.34.194 with SMTP id i185mr1595727wmi.118.1486208331434; Sat, 04 Feb 2017 03:38:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.9.232 with HTTP; Sat, 4 Feb 2017 03:38:10 -0800 (PST) In-Reply-To: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> From: Klaus Hartke Date: Sat, 4 Feb 2017 12:38:10 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Feb 2017 11:38:58 -0000 Carsten Bormann wrote: > For CoAP over TCP, it is proably OK to slightly adapt the definition > of the default to the IP address and port of the end of the connection > receiving the CoAP request. +1 > For WebSockets, that does not quite work. The WebSocket hostname is > needed to make the connection, so that should also be the default > value of the Uri-Host for requests in the direction from the WebSocket > client to the WebSocket server. +1 > What about the inverse direction? See below. > For TLS, the TCP approach would also work, unless there is SNI -- in > that case the default in the direction TLS client to TLS server should > shift to the SNI name. +1 > There is no way to indicate reverse SNI, > though -- can we be sure that is never needed? Would a client > certificate change anything here? Let's say a CoAP server is the initiator of a TCP/TLS/WebSockets connection. Unless the CoAP server uses a client certificate in the TLS case, the CoAP server does not have a name other than its ephemeral transport address. This means a resource at this CoAP server cannot be identified with an absolute URI, which requires an authority component to be specified. Even if the CoAP server had a name, placing this name in the authority component of the URI is not enough to locate the CoAP server, because the CoAP server is most likely only reachable through the established connection and unable to accept new connections. Any third party would need to know that they actually need to contact the acceptor of the TCP/TLS/WebSockets connection in order to access a resource at the connection initiator. So the possible options are to either limit interactions to the CoAP server and the connection acceptor, or to let the connection acceptor make the resources of the CoAP server available to third parties by acting as a CoAP reverse proxy (or similar). This is what we describe as a "third possible configuration" in [1]. > In the last authors' call, we agreed to remove the signalling option > that would allow to set a different default URI host (used to be > called "Server-Name" analogously to SNI; a better name is > "Default-Uri-Host"), as we weren't aware of an implementation. > Do we need to keep it to solve anything of the above? As far as I'm concerned the only use case for the Server-Name signalling option is to allow a TCP connection initiator to set a default value for the Uri-Host option in the requests it sends as a CoAP client. I don't think this makes things more complicated or has a high cost due to additional security considerations, but I don't have a strong opinion if this little optimization should be included or not. Klaus [1] https://tools.ietf.org/html/draft-savolainen-core-coap-websockets-07#page-4 From nobody Mon Feb 6 09:04:33 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDBA129E86; Mon, 6 Feb 2017 09:04:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148640066564.18842.1106998020622293852.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 09:04:25 -0800 Archived-At: Cc: core-chairs@ietf.org, draft-ietf-core-etch@ietf.org, The IESG , core@ietf.org, rfc-editor@rfc-editor.org Subject: [core] Protocol Action: 'Patch and Fetch Methods for Constrained Application Protocol (CoAP)' to Proposed Standard (draft-ietf-core-etch-04.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:04:25 -0000 The IESG has approved the following document: - 'Patch and Fetch Methods for Constrained Application Protocol (CoAP)' (draft-ietf-core-etch-04.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-etch/ Technical Summary The existing Constrained Application Protocol (CoAP) methods only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired. Again similar to HTTP, the existing Constrained Application Protocol (CoAP) PUT method only allows to replace a complete resource. This also leads applications to use POST where actually a cacheable, possibly idempotent request is desired. This specification adds new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of a CoAP resource. Working Group Summary The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed. Document Quality There are no known implementations of the new COAP methods. Registration of new COAP media types was requested. Personnel Jaime Jiménez is the document shepherd. Alexey Melnikov is the responsible Area Director. From nobody Mon Feb 6 17:31:06 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F338D126FDC for ; Mon, 6 Feb 2017 17:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsYjSELtmapz for ; Mon, 6 Feb 2017 17:31:03 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0124.outbound.protection.outlook.com [104.47.42.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE51129571 for ; Mon, 6 Feb 2017 17:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CyC4y/pE1z8rHi8/cvdZ34pN42qtJh/VvgFm2ICLXW0=; b=RR/CjXv1AihqUaQ1xT990DCHevFNClMysrdSart7apZSoSpcy6l9f+O2/GIZu2v2yyUn4VKiWuZpmVT8LI+KMj16AMt8pSS6jwZYuR6y72sovGqS2mL6oTH2DJogDfJWjfgdS6B9oG0urTZXTDGmT48btj2ta1uYZzCpqjjDeeY= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2377.namprd03.prod.outlook.com (10.166.207.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 7 Feb 2017 01:31:01 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0888.025; Tue, 7 Feb 2017 01:31:01 +0000 From: Brian Raymor To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] Default values for Uri-Host with alternate transports Thread-Index: AQHSfstN6id7Cu5k/0uGeC8GF4wo7qFcdq8g Date: Tue, 7 Feb 2017 01:31:01 +0000 Message-ID: References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> In-Reply-To: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 83c693ca-e02e-479c-91f8-08d44ef8f9b0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2377; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2377; 7:3aaXmqVOjPIueSGaz03uOviI6h3MwtFFoCxv5bez0kENZzcGZabnrnCZP/QZVjRLDOVpYm7DWyd8co2Yc1P4pP/qaAXdeS5uoE3E8SwqkTuHYxzq9uBPVZhciJXqNihlc5rR2/OMumY6mKGkOtNNwqm4VQcLU8o45Jq7CGN+wAon+JLAYcvw+ktOx/ZOzP8ogEMMsTaIvVrt3Wvquw2IMmlDK9bTlo6Ik3gzKL5abCmLkB8s54bzqaA8VzaJri8xySMZz+CLs4+BOGDjsVHEKqw+fPKLqrvMcle8Ci+Mcu5QIV8fvMZ/7l9HKxwfrshJ9YLKf44C3ywg7A37duWErswOoN7/bgaHmSzxDda3enV2u3pzouzxhFi80ySOsti56tjkdaylKX0QY5MA3wmLT0Jij4H1OcCy7Ez13tPTjtsKYf7uQkllpYf5CXR4XrUCfotUfjFMcQgCl2R/aIo6VEFxVQHOPhw65S4KzQtFx8evjW7dvrz2YUfK/1HN/jDT/USIKPbU1YuR9zit5z5L8bxRQmQd7y3nIfDwO7kBw4I= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(150554046322364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(20170203043)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(6072148); SRVR:CY1PR03MB2377; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2377; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(377454003)(189002)(24454002)(199003)(57704003)(101416001)(66066001)(38730400002)(2900100001)(99286003)(106116001)(92566002)(33656002)(76176999)(6246003)(9686003)(3280700002)(8936002)(55016002)(2906002)(77096006)(81156014)(81166006)(105586002)(53936002)(6506006)(3660700001)(8676002)(50986999)(8990500004)(6436002)(5005710100001)(106356001)(10290500002)(25786008)(229853002)(86612001)(5660300001)(86362001)(68736007)(189998001)(305945005)(74316002)(7736002)(54356999)(2950100002)(122556002)(10090500001)(6306002)(7696004)(97736004)(3846002)(102836003)(6116002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2377; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 01:31:01.1154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2377 Archived-At: Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 07 Feb 2017 01:31:05 -0000 DQpUaGlzIGlzIHRyYWNrZWQgaW4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3At dGxzL2lzc3Vlcy8xMDguIEknZCB3ZWxjb21lICpicm9hZGVyKiBXRyBkaXNjdXNzaW9uIGZvciB0 aGlzIGlzc3VlLiBJdCdzIHRoZSByZW1haW5pbmcgaXNzdWUgdGhhdCdzIGJsb2NraW5nIGNvYXAt dGNwLXRscy0wNi4NCg0KT24gU2F0dXJkYXksIEZlYnJ1YXJ5IDQsIDIwMTcgMTo0NCBBTSwgQ2Fy c3RlbiBCb3JtYW5uIHdyb3RlOg0KDQo+IEZvciBXZWJTb2NrZXRzLCB0aGF0IGRvZXMgbm90IHF1 aXRlIHdvcmsuICBUaGUgV2ViU29ja2V0IGhvc3RuYW1lIGlzIG5lZWRlZCB0byBtYWtlIHRoZSBj b25uZWN0aW9uLCBzbyB0aGF0IHNob3VsZCBhbHNvIGJlIHRoZSBkZWZhdWx0IHZhbHVlIG9mIHRo ZSBVcmktSG9zdCBmb3IgcmVxdWVzdHMgaW4gdGhlIGRpcmVjdGlvbiBmcm9tIHRoZSBXZWJTb2Nr ZXQgY2xpZW50IHRvIHRoZSBXZWJTb2NrZXQgc2VydmVyLiAgDQoNClRoZXJlJ3MgYWxyZWFkeSB0 ZXh0IGluIHRoZSBXRCBmb3IgdGhpcyBjYXNlOg0KDQogICAgVGhlIFdlYlNvY2tldCBjbGllbnQg aW5jbHVkZXMgdGhlIGhvc3RuYW1lIG9mIHRoZSBXZWJTb2NrZXQgc2VydmVyDQogICAgaW4gdGhl IEhvc3QgaGVhZGVyIGZpZWxkIG9mIGl0cyBoYW5kc2hha2UgYXMgcGVyIHt7UkZDNjQ1NX19LiBU aGUgSG9zdA0KICAgIGhlYWRlciBmaWVsZCBhbHNvIGluZGljYXRlcyB0aGUgZGVmYXVsdCB2YWx1 ZSBvZiB0aGUgVXJpLUhvc3QgT3B0aW9uIGluDQogICAgcmVxdWVzdHMgZnJvbSB0aGUgV2ViU29j a2V0IGNsaWVudCB0byB0aGUgV2ViU29ja2V0IHNlcnZlci4NCg0KPiBJbiB0aGUgbGFzdCBhdXRo b3JzJyBjYWxsLCB3ZSBhZ3JlZWQgdG8gcmVtb3ZlIHRoZSBzaWduYWxsaW5nIG9wdGlvbiB0aGF0 IHdvdWxkIGFsbG93IHRvIHNldCBhIGRpZmZlcmVudCBkZWZhdWx0IFVSSSBob3N0ICh1c2VkIHRv IGJlIGNhbGxlZCAiU2VydmVyLU5hbWUiIGFuYWxvZ291c2x5IHRvIFNOSTsgYSBiZXR0ZXIgbmFt ZSBpcyAiRGVmYXVsdC1VcmktSG9zdCIpLCBhcyB3ZSB3ZXJlbid0IGF3YXJlIG9mIGFuIGltcGxl bWVudGF0aW9uLg0KPiBEbyB3ZSBuZWVkIHRvIGtlZXAgaXQgdG8gc29sdmUgYW55dGhpbmcgb2Yg dGhlIGFib3ZlPw0KDQpJIGRvbid0IHNlZSB0aGUgbmVlZCBpZiBhcHByb3ByaWF0ZSBkZWZhdWx0 cyBhcmUgYWRlcXVhdGVseSBzcGVjaWZpZWQuIE1vc3Qgb2YgdGhlIHJlbGF0ZWQgbGFuZ3VhZ2Ug aW4gdGhlIERlZmF1bHQtVXJpLUhvc3Qgd2FzIHRvIGRlc2NyaWJlIHRoZSAiYmFzZSB2YWx1ZXMi IGZvciBVcmktSG9zdCBiYXNlZCBvbiB0aGUgdHJhbnNwb3J0IC0gdGhlIHZhbHVlcyB3aGljaCBh cmUgdXNlZCBpZiBEZWZhdWx0LVVyaS1Ib3N0IChha2EgU2VydmVyLU5hbWUpIGlzIG5ldmVyIHNl bnQuICANCg0KDQo= From nobody Tue Feb 7 08:46:59 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEF5127076; Tue, 7 Feb 2017 08:46:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148648601397.16293.11128583975399478137.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 08:46:53 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-yang-cbor-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:46:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Alexander Pelov Abhinav Somaraju Randy Turner Ana Minaburo Filename : draft-ietf-core-yang-cbor-04.txt Pages : 31 Date : 2017-02-07 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 8 06:09:43 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A99B129ADC for ; Wed, 8 Feb 2017 06:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqqPnqfqbqbj for ; Wed, 8 Feb 2017 06:09:35 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30124.outbound.protection.outlook.com [40.107.3.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A483C12949F for ; Wed, 8 Feb 2017 06:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8O87g6OrRC2cUOUnSybQFgeN0piIikqx/qeXTzUj5zM=; b=EXFUDgh0QSxxLmGQuaLRGlApKo0dYXw8eyKgpwbRSo69YARmvtG+4TeV5fq+qGur3YkXGwgON3BaoPovSsvbaHA8bTZu4WwmnmcckLHP3lVn7gyJ8ddfHmxQohya6d3vbTTXLMU0eFyFdos3Fx4d+l4zzdMdWOskGVwa+QSbe+c= Received: from DB5P122CA0008.EURP122.PROD.OUTLOOK.COM (129.75.164.146) by HE1P122MB0074.EURP122.PROD.OUTLOOK.COM (129.75.166.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 8 Feb 2017 14:09:32 +0000 Received: from AM1FFO11FD025.protection.gbl (2a01:111:f400:7e00::156) by DB5P122CA0008.outlook.office365.com (2603:10a6:20:1e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16 via Frontend Transport; Wed, 8 Feb 2017 14:09:32 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.228.36) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.228.36 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.228.36) by AM1FFO11FD025.mail.protection.outlook.com (10.174.64.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.7 via Frontend Transport; Wed, 8 Feb 2017 14:09:32 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) by AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 8 Feb 2017 14:09:31 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) by AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) with mapi id 15.01.0860.032; Wed, 8 Feb 2017 14:09:30 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: [core] CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AdJ71Z2t7xvTLii1QoWlumXEa75yfQAEP+wAABxuBgAAAN+rgAACdXTQAWuqCdA= Date: Wed, 8 Feb 2017 14:09:30 +0000 Message-ID: <85d6ff1c1d5047e3b3e516660652d8df@AM3PR90MB0097.MGDPHG.emi.philips.com> References: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.122] X-MS-Office365-Filtering-Correlation-Id: 00a88b12-9680-465a-b3f2-08d4502c1a98 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: AM3PR90MB0097.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.228.36; IPV:CAL; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(2980300002)(85714005)(199003)(55904004)(189002)(13464003)(374574003)(33646002)(68736007)(23676002)(93886004)(6916009)(86362001)(55016002)(97736004)(229853002)(6306002)(189998001)(26826002)(108616004)(105586002)(3846002)(626004)(6116002)(102836003)(7696004)(6246003)(69596002)(2906002)(53936002)(53546003)(5660300001)(106466001)(305945005)(47776003)(81166006)(8676002)(24736003)(66066001)(356003)(76176999)(38730400002)(50986999)(54356999)(450100001)(92566002)(110136004)(7736002)(2900100001)(8936002)(81156014)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1P122MB0074; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD025; 1:zTvL0u4I014LUWWFk57cuW+BjukFe3bZpDeq3Vdnhqk0cRCYG9bs69zpvdD24pscS3lE5e4tcmA+7lqvqWPOeRJmkuJZcbuNV+1Rdjb3nFdg6LiTBi7P47KymOpvKSfJuYK1+XvADryo7PgCqYdV1x5Xuo3C5uqk370c/E6y4NfIGb2QaOUFyEnYw5a5/aGKxdNgZa1inFjJxjggmt0ImItStL8G1HNBreDpHWgGAzh7Br0Sb57z7kkMbtudSMjjgemEWQ3vNxt6vDHHSvhOQgkjk3OKioyHRV3t3yLv9WVMNL3Ehda2whXszxyBW3OZndSCdVvU+MDjbK6h5pyNlDbVWPpoEF4pZ13SaeNAQ3824O3GxOYMAcnNSFbiRNPeYiT/OJsd5dRx0+oedu0nyQwecEAaY1OIYEzUszNMaXK2n/zWETI+v5q5CxmmXDL8GCW+VemJwD26Fxm1Fx/BR3JnNzYhwaZrojG07mYS1c2MbQuqCzjetQtdzcYC2strYyTiCL7D34MTSrmnvq9W0lNj9lrb+gJ1RyQBCprIavFXprE6TWT2tDnsHrJ+DyFe6a46OCr+eljRodoO1MMUrQ== X-CrossPremisesHeadersPromoted: AM1FFO11FD025.protection.gbl X-CrossPremisesHeadersFiltered: AM1FFO11FD025.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1P122MB0074; X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0074; 3:69gp46/3wU56lhWewfPKc3scdsw27HmSNwngB++2XmN2K9oKGpzfwVRyqIzEJB4qM4Kh3HIdn9DJA86dqJ9vftmHDwIrYG5McyBvYmo8ByA+383gx3GDYoKDRR1PkdO0iC9yRa+FQBqsQLJHQvKCQ2Yt+gEmBMJDCCG6u3ju/fZZiZokvNiWTd5hM+p+zeK1SC6blIISSvQ88IdfnN69URwkK5o1z141yUhxbL1vw9QtR0nN4jbVA22GShymR5kFyYr5+3xGIf3fSaBJkk1Lssc0hrDhg1kg546SOvzDnLDSeZeN0TjcRlZWZyDeQSeei81xEgpQWKC07nZeUN4wtFt2N0YVxydn4hC3LhfFYv4=; 25:+QeK+u07gbEFPYt0jx9ugog7Bsqqys94cXJKj1Z7uf5Gj9sKBDMdP+Iuy5hhVeUpypcvBGExyI15rTlW2Yw5irrCIED8JeoZsaF6rxenoKmVW+dK+66mlNJ6rVG5lXkrIFMLuRjWz4ZXyjzVtHiCxFlBrLjgtZtq+DzPpbAE1PGTMOSOx/SdjI0ODYDzd0rGCZZsqJRJQuz0zZklVQV5V9cmfGMmARA7DP8ADrhfS5rR91Ze3R+DRdYlsP+Qwwpg+d596uzVAere6wS/nPlsZApIV/O7mM7qLYrqVk8hqJKfTSFr3oBxUAYiMYJXdWDOqnRMWx6SLpRyS1DfINInbQH+/VOscErNLiKj8uqL4K7ApSV9wRIpzU5OJu3x5yeTD4Ntjn2AefPucet3+YCt7lblqdJeFVA63yg+nW2xxetPLQiL2tRP7Q3pAqHlDGE5 X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0074; 31:EbHr71P19MhYP9Akp0A3coCZA1KIdel72WEQDc4J5UbL4RI2l/FMQPYcKHuQqryoQLX/8Hcylbim6icUW115T+eroKFZmpadCEU9CPM5ygJq1KulZABIWwdGdrmWWF1ZJjL60a4qVXF3oMcw6E+zvb42KCVx7Hgfy7CO9pTdQvPtfQ34tj//AoAN7KIPlOVduk0Ne6oxyO72pjVWjXTPZCLO2KF5PcMZBbE5MbbWx7aUUVn9P1Zb4/SCzSlCLXMmhBKT89aUZV/uR7+2TINmoPODlluOhDgbXLzCfB32pAI=; 20:qeYGTyK7PjLey3Aud7UZvOOxHJYlQ0iyKZ7buGl174lCzfKXwiH3B4LU6ATciE/F7aLMXCCI9r88ePO8D16fKoSilyNBGT6uttQSMxfsvHUaivqd6FYmlL8O2tVUueIKvn93meKpZX3WQyvHvF1lfmmNfhIll/pU2+C97JVZuWT0S/Nty0oxjgVv/ywBm/BzJ+OaHJrCsth7gymrQs4Xk03ut5B1n9itkUI6Aw6xwc2Bo3VRsbxYm2kaapPxrN1wSTLcCEPXXHV46803DC+K7L1ydC9X6m7v2fz/6CnytcUL0/jtbVc3hkvINAqNayG6rsq7U/RMXPlS/f8TOC8ZvMWT8jf8Ra2m0ILDeXgcP6cxMEJtRb+bb/J9dsquaWxfvx1dW7YAOixva+o8Lqnn8ZcmQGnk40a4lT4MNFH8zqyBIyoYxBEDf3m7HD0GXxmE2s38BAaHUXPi/wXL5ot4ByCSjF2Bfo0+iW7jIwZZn7TYDCKm+2/4E8iCR3yhp2z6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(180628864354917)(260087099026482); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(20170203043)(13021025)(2017020702029)(5005006)(13013025)(13023025)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(6072148); SRVR:HE1P122MB0074; BCL:0; PCL:0; RULEID:; SRVR:HE1P122MB0074; X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0074; 4:W0Q+oM4JYFaiIwPaaup4WPhLm1tJDOD8sXa6ex8fdJ30BQvJEA7FC0X/GclGndQ39pXMd3O0sjNW6QVfZaLvQZjMoxBm5smG39W/DqT7pyVvg9bX26jDt+OoOzICilvd0RFVWxJwNxYZIsOKyfU6LRFiunSynYSVJs+OxjeeUfP7I5DixcCNy1i/72xQ7vFLp3Hz/klnSE4KbsxRZLqdB/6iDyulUQot4OK/s0tevy1Cdht0MO8VWzkq11N8fUj5cOYwu3DLe97I5291Liq2XZi5Dn8TvGcZc1ZacQjY9VP9HBklvR1pmaZ3kj4IhSTr5bxbQnHOmWWwO5WAh8yj2bHqh87gXHzA/C0VzbHA3X7FifqtOjDvZYopTa9aLEfZLxEJfZANSZMsr33jGp7OGAjuqiPoo0UON0YbCcrFtVZS261PJObxyiycGjZ7gwPqXtS1q/UcAn7L+d8CrPoeXY5aRrCELRMrE5xBB1mAqovWjiX3T1O9PDKCV3wlyG3G+xxm7aUbGjufi+RqFFnqxHME8yiF+GREpTbD+oDhgGMeI6Ick3wpFnqurWcaW3tsRShercu39DbLpKKt7QUvkXAkX+f+sRHtJyns5J+NFwsScGDR51bCMAEjDvEz16tRwz4Ldw69wAqSzZUUi6QWm06pjQEkk2cQX4Xy6NA1/gLueHwcx3eB7LyWWVrTRN1cx+7MZQ7g2MSuYX8Cf3M6/LiWEAuUxhCqJxituG1XzN7LNOYvdP/imNihEwBE35TbMMAHw9LFLG4clug3UIE51bjcmyRc9rZNBCBa2h/VqCFEs++Pp6RAjn/tSfl95EZ3gHaUd/AoVD0IXk4OExrusQ== X-Forefront-PRVS: 0212BDE3BE X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQMTIyTUIwMDc0OzIzOndiR2NwZ3FTSHYrODl0ZkttZDRHQk9vekdW?= =?utf-8?B?QjI5R0NQOEMvTFgrZjNhVGNpaWRjSGNvNEZ2M1ZRL2hvRzFaeWxKbHl2N0RJ?= =?utf-8?B?TmpXa3RkNi85Q0pDS1BNU1ppQ25SbzRTTmRtRmRwL2hyQlpQSnVURkxGYnh5?= =?utf-8?B?TFF2aUdNRHB4cmZBNTFIbmgybEZMaVZISk5XOC9tWE9CVnhxV09sWDRlditH?= =?utf-8?B?WjRKQkpsZmM4SGprcnQ0TTBvWE01RUtONkVFZTNLaWhCckhhbC9nQ2lkaXF5?= =?utf-8?B?Rk4veEc2aW5lNGFTRE93MS9kUENwV2llVWNiMlpUQ2xLajNWQ2tkV0FTSkV3?= =?utf-8?B?anh5OExEVHJFWkhKd29aUmdYa2pBOTBFZXVLeVVlZVhXa3BSZXN4UUZscUhx?= =?utf-8?B?OFNTaXB5ZmdBY0dTSmpYSVoxR1dNWHN4QUFaYnRrcDNLQWZTUWpLWTlzWU05?= =?utf-8?B?dW9DTEhnQUh2UkhIOGpBalNlVVlCQm1wbHJGcW94amhuL3luYkxFQlJ4N0I5?= =?utf-8?B?WTJLcmtYSTFlRHh6U1Y4UHhzeGF0RmQ5bEhqU3RWTGYra1h0REYwWmdHNUxi?= =?utf-8?B?cjZ0SnZ2ZWNWaHNsYVlhSDV6bDBBZHRSdGpLOUEySTMzeFBZbTVxVHczZExY?= =?utf-8?B?a0gwWEJCV2dqUW0zZ0tJU2V3RWxLYzUzWjFnMVg0SkFkMzM5Y1piTXpTeEZ3?= =?utf-8?B?QVNzT3JCOFpuYnJtdVAzMnVtazJwR01wNTdoZGJwbzQ5K0lrVTYzZXJUUEJ2?= =?utf-8?B?amloWVhTbTRUNFZBbU1SeXZQcnNPaFIwZTc0MngxVGtQRVNlN2VVUkx5VFFi?= =?utf-8?B?eVB5NWFpVlllUjMzaGYyajgzVTJhYmtMd1o0WmJFN1g5aUVacDVaRC9qMnlE?= =?utf-8?B?aVg5NldQNy96WDNsajVqZENDMFRkbEcyTkRRbVJDaGNMK2dGR0drczdEWkVL?= =?utf-8?B?Q3JJS1QrVXd5S2p3SHlMdjVPN1NyUkVyQ245WmlGOEY0amU4b0NMYkJud1Zr?= =?utf-8?B?VFNablVNRTBVVEx3cmIrV3Y4aEJNbFFHTnlpcEFBbEFhNloyTE1ac21DUm9R?= =?utf-8?B?ZitRQXllS2JyOFc0YjVPNXFaV3J2RGNaMm1HV0tGWEpwdWl0dnBnaHNEOXVW?= =?utf-8?B?MmEzcSt1ZXNNMFFaZ1Budm94M2ZVcTVOQk16OGxTU3RhVWE5anZMSlo0emZS?= =?utf-8?B?eG1PSklvVUQwY2JXU3ZhWENISVFOUGhURTI2Um9DYzhxVG01aTVsbTNHRFpY?= =?utf-8?B?SUxLMkpQSk9BZzRmOHJwMEg1L3NpN1l2NUYzTjBSdVhwY1laeGJMbTZBZlY2?= =?utf-8?B?TlJSajJKTWpiVEhMUVpDTStjRE45cHBDdk5jQU5mMVFxRGMwWkVEK2paY0tY?= =?utf-8?B?Q1dRa3BXQ0ZZTDZLd2pDYW5jV3lmT1hLeEIzSDM0bHBraTVSL0Vianc5a3hH?= =?utf-8?B?QzNPOTl3TmVmZjNlNWtzeDl0eDZNUjJZbjVDZVlHcGNsR1l6bWV3eVh1M0Y4?= =?utf-8?B?YURiTTdoRFhsdWxRTFVpSVk4SXY3VVRPeGVQcWFsNm52emJSc2lLV1pZQ2cz?= =?utf-8?B?eWRxcGtLdWZQVDArNTlQU2dvd0w3b00vaE5LeC9TUE55QVZxSUl4dTBSd0gy?= =?utf-8?B?U3IvU2cwUGxuOGtMZ25KSTJFeEtvWENpa0JFY2NHVGg2ZnF4T3h0TTdhOCtT?= =?utf-8?B?RFFSYmc0bnVtY09YaHNEMHRoeURvd2Z1dUcveVhYVDJYMjNWTmhMdzJOQjhG?= =?utf-8?B?aHVUTmNXVUdQVUdNZHVnU0VsWXNFOU1XV2NQN2I1VjZPR1FEa0hEeWxzV1Za?= =?utf-8?B?NFRuUjErdmRzOWNSRmFkakNET1NoMnY4QlduYnRjcFROZ0FhVGRsYkFDR3pr?= =?utf-8?Q?MqHYNCwmuQnZAdFHJEt3H3XGlVsoImFn?= X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0074; 6:LKymy8TiWmY8/9TONdGPr1qcsujQnO8kr1N/zujhrIpzay4KaivMAIBcnYrUHCNsmewevQytY1w4ts9Sor/mMY+P5rHZvi6ndkGFU/10p0eIfAL4gnw+Sfkyd3oLwIUqmNU8oTALcOdcdBGZa5fNZxBRk8FntwNmGBt/mHYTTvilDZQqVQT7fHEKgXgaAMSiN9zYmbwf4wYpTdr2IhPtGfa8J+lqqpizYIotf5pq1wBH0rgu6BNJgVmoeyRf5W/v/snSK6K+PaD+OhVRnSIgJ8M8Qte4TJX2BCF4UBElDLNKSNcs+eo78fKsnTS6zXH73pZdmJ7A4Ff2Yp496KrOPxJRALap+fCAMNpg6BXj444mefs5rUms1ZPfA26xdll4UfG9j8CGccKcnJ8QZJVmarFL7jvMqzZg0tTI+dXGeng=; 5:W90tHCa9AL6NH9HGXjRcMsjwf+X/EEz836FhdmjFstOeEmiwq1RSntUR67iMlEJmYnMGieTllSp8IofmP5PeAcu1NRMxyTcwqpQJHUuJwxNnJIFlEQrw/TuaH+St8RX+BdFxHWCPe0d0vyGm9kHFjQ==; 24:dHNLyJfb4Yb8kW2MNUD2GEnGIKxm2RbbtKCfYivAk7jOY7Csl9VZquTrEs3BzbsmsLzLBOR3NFzyzlWDZY0V32x1TB1hgWVwgDy6k6ebLfM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0074; 7:wjHGEJBJCfr6AVG6tflV1m5Cve39WDNAI9UOps4y0Cbkd1uOa3Tb+MUDnNEeOOB5qG3y0nd9FX1YBujronpL+TJA5OxB8Sdb0TRAf7YP0VfHsvVV7rdzYXoVuZO6AdJmibWRqqFPzcFPxHqa/ahmkp1v3c3p8D6MHHUKsMWURxtxUJr95Q97fFkDfqtIE1ho2nyu1iQP0jmbKzPGjL4G05bNjJkVYv/CmqqGNcA4S/STlsrw6hH8UvNVYinOMe0ZwUUUZj2s/j/BO3s5Hx+FR8hIJXxfNUpItE3I0fBpvhXzMBm1TYkHT1yzgbd4l7Q3GgFE8fMfCsji3XfwbjazY21UcOEghl+2pHQNoWdIJy0OfJT5w4B/0iUAMf9J0k1HOQFH8EurorBqgQx3QL5SIVtjvEgd/OVdGZsJ6Z7sMp1czmVVo8NlDDrmMC5cc8kr3W8HzEt6nUVnQb16/JN9PHl1ZH1wWZ91WsoVnCnTNqSYBD8finYexXghJcqjQWCQnShwqjguvFESf8RvB5Glwg== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2017 14:09:32.0768 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.228.36]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P122MB0074 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM3PR90MB0097.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 194.171.252.122 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: HE1P122MB0074.EURP122.PROD.OUTLOOK.COM Archived-At: Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Feb 2017 14:09:42 -0000 T3IgZm9yIHRoZSBzaG9ydGVyIHRlcm06IHRoZSBIVFRQIGNvZGUgNTA3IEluc3VmZmljaWVudCBT dG9yYWdlIChmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0OTE4I3NlY3Rpb24t MTEuNSkgaXMgdmVyeSBzdWl0YWJsZSBmb3IgdGhlIHVzZSBjYXNlIG9mICdjbGllbnQgcmVxdWVz dGluZyB0b28gbXVjaCBkYXRhIHZpYSBVUkkgcXVlcnkgcGFyYW1ldGVycycuDQpDb3VsZCB3ZSBy ZXF1ZXN0IHJlZ2lzdHJhdGlvbiBvZiA1LjA3IGluIHRoZSBDb0FQIFJlc3BvbnNlIENvZGVzIHJl Z2lzdHJ5IHdpdGggZGlyZWN0IHJlZmVyZW5jZSB0byBSRkMgNDkxOCAvIGNvZGUgNTA3ID8gIChm b2xsb3dpbmcgdGhlIElFU0cgYXBwcm92YWwgcm91dGUpDQoNCmJlc3QgcmVnYXJkcw0KRXNrbw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlqaywgRXNrbw0KU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAwMSwgMjAxNyA5OjUwDQpUbzogJ0NhcnN0ZW4gQm9ybWFubicgPGNh Ym9AdHppLm9yZz47IExhdXJpIFBpaWtpdmkgPExhdXJpLlBpaWtpdmlAYXJtLmNvbT4NCkNjOiBj b3JlIChjb3JlQGlldGYub3JnKSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbY29yZV0g Q29BUCByZXNwb25zZSBjb2RlIGluIGNhc2Ugb2YgInJlc3BvbnNlIHBheWxvYWQgdG9vIGxhcmdl IiA/IDQuMTM/DQoNClRoYW5rcyBDYXJzdGVuLCBQYWRkeSwgTGF1cmksDQoNCmZvciB0aGUgY2Fz ZSBJIHJlZmVycmVkIHRvIGluZGVlZCB0aGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgbWFjaGluZS1y ZWFkYWJsZSBzbyB0aGF0IHRoZSBjbGllbnQgY2FuIGxpbWl0IGl0cyBxdWVyeSBzY29wZS4gRm9y IG91ciBjb25zdHJhaW5lZCBkZXZpY2UgY29udGV4dCBJIHdvdWxkIGF0IGZpcnN0IGV4cGVjdCBh IGZldyBhZGRpdGlvbmFsIHJlc3BvbnNlIGNvZGVzIGRlZmluZWQsIGEgcGVyaGFwcyBtb3JlIGlu dG8gdGhlIGZ1dHVyZSBhIGNvbXBsZXRlICJwcm9ibGVtIGRldGFpbCIgcGF5bG9hZC4NCg0KRm9y IHRoZSB0aW1lIGJlaW5nIGl0IGNhbiBiZSBvbmUgb2YgNS4wMCwgNS4wMSBvciA0LjAzLg0KDQpF c2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4g W21haWx0bzpjYWJvQHR6aS5vcmddDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDAxLCAyMDE3 IDg6MjINClRvOiBMYXVyaSBQaWlraXZpIDxMYXVyaS5QaWlraXZpQGFybS5jb20+DQpDYzogRGlq aywgRXNrbyA8ZXNrby5kaWprQHBoaWxpcHMuY29tPjsgY29yZSAoY29yZUBpZXRmLm9yZykgPGNv cmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIENvQVAgcmVzcG9uc2UgY29kZSBpbiBj YXNlIG9mICJyZXNwb25zZSBwYXlsb2FkIHRvbyBsYXJnZSIgPyA0LjEzPw0KDQpIaSBMYXVyaSwN Cg0KaW5kZWVkLCB0aGUgQ29SRSB3b3JsZCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgSFRUUCB3b3Js ZC4NCg0KPiBJIHByb3Bvc2UgYSBiaXQgb2YgaW5mbyBnYXRoZXJpbmcsIEkgIGltYWdpbmUgdGhl cmUgYXJlIG1vcmUgc2ltaWxhciBraW5kcyBvZiBzaXR1YXRpb25zIHdoZXJlIEhUVFAgaGFzIG5v dCBoYWQgdGhlIHJpZ2h0IGNvZGUuDQoNCldoZW4gd2UgZG8gdGhpcywgSSB3b3VsZCBsaWtlIHRv IGFwcHJvYWNoIG5ldyBjb2RlcyBub3QganVzdCB3aXRoIOKAnHdoYXQgc2hvdWxkIHRoZSBzZXJ2 ZXIgZG/igJ0gYnV0IG1vcmUgaW1wb3J0YW50bHkgd2l0aCDigJxob3cgaXMgdGhlIGNsaWVudCBn b2luZyB0byByZWFjdCBkaWZmZXJlbnRseeKAnS4gIElmIHRoZSBlcnJvciByZXNwb25zZSBpcyBq dXN0IGFib3V0IHRlbGxpbmcgd2hhdCB3ZW50IHdyb25nIHNvIGEgaHVtYW4gY2FuIGRlYnVnIHRo ZSBzaXR1YXRpb24sIGRpYWdub3N0aWMgcGF5bG9hZHMgYXJlIGZpbmUuICBJZiB3ZSBuZWVkIG1v cmUgZGV0YWlsIGluIGFuIGVycm9yIHJlc3BvbnNlIHNvIHRoZSBjbGllbnQgY2FuIGZvcm11bGF0 ZSBhIGJldHRlciByZXF1ZXN0IGJhc2VkIG9uIHRob3NlIGRldGFpbHMsIHdlIG1heSB3YW50IHRv IHN0YW5kYXJkaXplIOKAnHByb2JsZW0gZGV0YWls4oCdIHBheWxvYWRzLCBpbnNwaXJlZCBieSBS RkMgNzgwNy4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkg YmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxh dy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVj dGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29u dGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBv ZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From nobody Wed Feb 8 06:43:30 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF029129B69 for ; Wed, 8 Feb 2017 06:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOQ37uZOtwli for ; Wed, 8 Feb 2017 06:43:24 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.106]) (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 28C6F129B61 for ; Wed, 8 Feb 2017 06:43:23 -0800 (PST) Received: from [193.109.255.99] by server-2.bemta-6.messagelabs.com id A9/0A-22326-A8E2B985; Wed, 08 Feb 2017 14:43:22 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleJIrShJLcpLzFFi42LR98zp0u3Qmx1 h0H5XwWLf2/XMDoweS5b8ZApgjGLNzEvKr0hgzXj09w9jwV+Tinc357I0MC4x6WLk4hAS2MYo sWbKMkYI5xCjxKF5S5ngnIP/VrFCOJsYJb7svwWU4eRgE3CVOLrrDjuILSKgJXGkYREziC0sE C5xoeUHVDxC4v3kuUwQdpjEtOcbwOIsAioSH28dB4vzCoRK7Pt3ggViwXomidmXlrGCJDgFQi RaWm+zgNiMArISXxpXgy1gFhCXuPVkPlizhICAxJI955khbFGJl4//AfVyANVoSqzfpQ9Rrig xpfshO8QuQYmTM5+AjRQSUJU4cWgO2wRG0VlIps5C6J6FpHsWku4FjCyrGDWKU4vKUot0jY30 kooy0zNKchMzc3QNDcz0clOLixPTU3MSk4r1kvNzNzECY4YBCHYwnl4XeIhRkoNJSZQ3WXt2h BBfUn5KZUZicUZ8UWlOavEhRhkODiUJ3n26QDnBotT01Iq0zBxg9MKkJTh4lER4j4KkeYsLEn OLM9MhUqcYFaXEeV+CJARAEhmleXBtsIRxiVFWSpiXEegQIZ6C1KLczBJU+VeM4hyMSsK8E0G m8GTmlcBNfwW0mAlo8fXTs0AWlyQipKQaGO2v9OzZVnZ97omtyTkb1Tms2uaqqag6Mtw5NDP2 ZM5LroSLa/T1zh2WjDo9aZ4y262d4cK1Jss2zxA1OzVvOWt9+PdtnH/u78zQ+NfTspgrca635 FMJ+Yhlx+9vbX9/4/O/soRCgQ+750ucOcY2+fGVtVPbxe8etlpdfH3HtqMcHDuNYp6d4q5VYi nOSDTUYi4qTgQATKac6BMDAAA= X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-11.tower-48.messagelabs.com!1486564998!49138379!2 X-Originating-IP: [47.73.108.138] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6090 invoked from network); 8 Feb 2017 14:43:20 -0000 Received: from vgdpm12vr.vodafone.com (HELO voxe01hw.internal.vodafone.com) (47.73.108.138) by server-11.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 8 Feb 2017 14:43:20 -0000 Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.46) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Feb 2017 15:31:56 +0100 Received: from VOEXC04W.internal.vodafone.com (145.230.101.24) by VOEXH06W.internal.vodafone.com (47.73.211.210) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Feb 2017 15:31:55 +0100 Received: from VOEXC09W.internal.vodafone.com (145.230.101.29) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 8 Feb 2017 15:31:55 +0100 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.118]) by VOEXC09W.internal.vodafone.com ([145.230.101.29]) with mapi id 14.03.0294.000; Wed, 8 Feb 2017 15:31:52 +0100 From: "Smith, Kevin, (R&D) Vodafone Group" To: "core (core@ietf.org)" Thread-Topic: [core] CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AQHSe+ap8EBavsJo8kadePi0QO/zPwAEP+wAABxuBgAAAN+rgAACdXTQAWuqCdChUrhBkA== Date: Wed, 8 Feb 2017 14:31:51 +0000 Message-ID: References: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> <85d6ff1c1d5047e3b3e516660652d8df@AM3PR90MB0097.MGDPHG.emi.philips.com> In-Reply-To: <85d6ff1c1d5047e3b3e516660652d8df@AM3PR90MB0097.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Feb 2017 14:43:28 -0000 SGkgRXNrbywNCg0KTm90IHN1cmUgaWYgeW91IHNhdyBteSBlYXJsaWVyIHJlcGx5IChjb3BpZWQg YmVsb3cgZm9yIGNvbnZlbmllbmNlKSwgYnV0IGl0IHByb3Bvc2VkIDUwMyBiZWNhdXNlIHRoYXQg ZXhwbGljaXRseSBoaW50cyB0aGUgbmV4dCBzdGVwIHRvIHRoZSBjbGllbnQgLSB3aGljaCBpcyBj ZXJ0YWlubHkgaW4gdGhlIEhBVEVPQVMgc3Bpcml0LiBJdCBhbHNvIHNlZW1zIHRoYXQgaW5zdWZm aWNpZW50IHN0b3JhZ2UgbWF5IG5vdCBiZSB0aGUgb25seSByZWFzb24gZm9yIHRoZSBzZXJ2ZXIg bm90IHdpc2hpbmcgdG8gcmV0dXJuIGEgbGFyZ2UgcmVzcG9uc2UsIGl0IG1heSBhbHNvIGJlIGJl Y2F1c2Ugb2YgYmFuZHdpZHRoIGNvbnN0cmFpbnRzLCBuZXR3b3JrIGNvbmdlc3Rpb24gZXRjLiBT byBmb3IgdGhhdCByZWFzb24gSSB3b3VsZCBwcm9wb3NlIDUwMywgd2l0aCBSZXRyeSBIZWFkZXIg YW5kIG9wdGlvbmFsIGV4cGxhbmF0b3J5IGJvZHksIG92ZXIgNTA3Lg0KDQpBbGwgYmVzdCwNCktl dmluDQoNCi0tLS0tDQoNCkluIGdlbmVyYWwgaXQgbWFrZXMgc2Vuc2UgdG8gbGV0IHRoZSBjbGll bnQga25vdyB3aGV0aGVyIGl0IGNhbi9zaG91bGQgcmVwZWF0IHRoZSByZXF1ZXN0LiBJbiB0aGlz IGNhc2Ugd2UgY2FuIGFzc3VtZSB0aGF0ICdyZXNwb25zZSB0b28gbGFyZ2UnIGlzIGEgdGVtcG9y YXJ5IGNvbmRpdGlvbiAoaWYgbm90IHRoZW4gdGhlcmUgaXMgYSBiaWdnZXIgcHJvYmxlbSA6KSkN Cg0KVGhlIGNsaWVudCBzaG91bGQgdGhlcmVmb3JlIGJlIGluZm9ybWVkIHRoYXQgKDEpIHRoZSBj b25kaXRpb24gaXMgcGVyY2VpdmVkIHRvIGJlIHRlbXBvcmFyeSBhbmQgKDIpIGEgcmVjb21tZW5k ZWQgZGVsYXkgYmVmb3JlIHRoZSBjbGllbnQgcmVwZWF0cyB0aGUgcmVxdWVzdC4gVGhpcyBJTU8g cHV0cyB0aGUgZXJyb3IgaW4gdGhlIDV4eCByYW5nZSwgYXMgdGhlIGNsaWVudCBoYXMgbm90IGRv bmUgYW55dGhpbmcgd3JvbmcgYXMgc3VjaCwgYW5kIHRoZSBzYW1lIHJlcXVlc3QgYmVpbmcgbWFk ZSBuIHNlY29uZHMgbGF0ZXIgY291bGQgcmV0dXJuIGEgc3VjY2VzcyBjb2RlIGFuZCBhIG1hbmFn ZWFibGUgcmVzcG9uc2UuDQoNClNvIG15IHByZWZlcmVuY2Ugd291bGQgc2ltcGx5IGJlIDUwMyBT ZXJ2aWNlIFVuYXZhaWxhYmxlIFsxXSwgd2l0aCBhIFJldHJ5LUFmdGVyIGhlYWRlciBbMl06DQoN CiJUaGUgc2VydmVyIGlzIGN1cnJlbnRseSB1bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1 ZSB0byBhIHRlbXBvcmFyeSBvdmVybG9hZCBvciBzY2hlZHVsZWQgbWFpbnRlbmFuY2UsIHdoaWNo IHdpbGwgbGlrZWx5IGJlIGFsbGV2aWF0ZWQgYWZ0ZXIgc29tZSBkZWxheS4gVGhlIHNlcnZlciBN QVkgc2VuZCBhIFJldHJ5LUFmdGVyIGhlYWRlciBmaWVsZDEgdG8gc3VnZ2VzdCBhbiBhcHByb3By aWF0ZSBhbW91bnQgb2YgdGltZSBmb3IgdGhlIGNsaWVudCB0byB3YWl0IGJlZm9yZSByZXRyeWlu ZyB0aGUgcmVxdWVzdC4iDQoNClNpbmNlIDV4eCBhbHNvIHJlY29tbWVuZHMgInRoZSBzZXJ2ZXIg U0hPVUxEIHNlbmQgYSByZXByZXNlbnRhdGlvbiBjb250YWluaW5nIGFuIGV4cGxhbmF0aW9uIG9m IHRoZSBlcnJvciBzaXR1YXRpb24sIGFuZCB3aGV0aGVyIGl0IGlzIGEgdGVtcG9yYXJ5IG9yIHBl cm1hbmVudCBjb25kaXRpb24iIFszXSwgdGhlbiB0aGUgY2xpZW50IGNhbiBiZSBpbmZvcm1lZCB2 aWEgdGhlIHJlcHJlc2VudGF0aW9uIHRoYXQgJ3Jlc3BvbnNlIHRvbyBsYXJnZScgd2FzIHRoZSB0 ZW1wb3JhcnkgY2F1c2UuDQoNCkFsbCBiZXN0LA0KS2V2aW4NClZvZGFmb25lIA0KDQpbMV0gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi02LjYuNCANClsyXSBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIzMSNzZWN0aW9uLTcuMS4zDQpbM10gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi02LjYNCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRGlqaywgRXNrbw0KU2VudDogMDggRmVicnVhcnkgMjAxNyAxNDox MA0KVG86IGNvcmUgKGNvcmVAaWV0Zi5vcmcpIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtjb3JlXSBDb0FQIHJlc3BvbnNlIGNvZGUgaW4gY2FzZSBvZiAicmVzcG9uc2UgcGF5bG9hZCB0 b28gbGFyZ2UiID8gNC4xMz8NCg0KT3IgZm9yIHRoZSBzaG9ydGVyIHRlcm06IHRoZSBIVFRQIGNv ZGUgNTA3IEluc3VmZmljaWVudCBTdG9yYWdlIChmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM0OTE4I3NlY3Rpb24tMTEuNSkgaXMgdmVyeSBzdWl0YWJsZSBmb3IgdGhlIHVzZSBj YXNlIG9mICdjbGllbnQgcmVxdWVzdGluZyB0b28gbXVjaCBkYXRhIHZpYSBVUkkgcXVlcnkgcGFy YW1ldGVycycuDQpDb3VsZCB3ZSByZXF1ZXN0IHJlZ2lzdHJhdGlvbiBvZiA1LjA3IGluIHRoZSBD b0FQIFJlc3BvbnNlIENvZGVzIHJlZ2lzdHJ5IHdpdGggZGlyZWN0IHJlZmVyZW5jZSB0byBSRkMg NDkxOCAvIGNvZGUgNTA3ID8gIChmb2xsb3dpbmcgdGhlIElFU0cgYXBwcm92YWwgcm91dGUpDQoN CmJlc3QgcmVnYXJkcw0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog RGlqaywgRXNrbw0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwMSwgMjAxNyA5OjUwDQpUbzog J0NhcnN0ZW4gQm9ybWFubicgPGNhYm9AdHppLm9yZz47IExhdXJpIFBpaWtpdmkgPExhdXJpLlBp aWtpdmlAYXJtLmNvbT4NCkNjOiBjb3JlIChjb3JlQGlldGYub3JnKSA8Y29yZUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBbY29yZV0gQ29BUCByZXNwb25zZSBjb2RlIGluIGNhc2Ugb2YgInJlc3Bv bnNlIHBheWxvYWQgdG9vIGxhcmdlIiA/IDQuMTM/DQoNClRoYW5rcyBDYXJzdGVuLCBQYWRkeSwg TGF1cmksDQoNCmZvciB0aGUgY2FzZSBJIHJlZmVycmVkIHRvIGluZGVlZCB0aGUgcmVzcG9uc2Ug bmVlZHMgdG8gYmUgbWFjaGluZS1yZWFkYWJsZSBzbyB0aGF0IHRoZSBjbGllbnQgY2FuIGxpbWl0 IGl0cyBxdWVyeSBzY29wZS4gRm9yIG91ciBjb25zdHJhaW5lZCBkZXZpY2UgY29udGV4dCBJIHdv dWxkIGF0IGZpcnN0IGV4cGVjdCBhIGZldyBhZGRpdGlvbmFsIHJlc3BvbnNlIGNvZGVzIGRlZmlu ZWQsIGEgcGVyaGFwcyBtb3JlIGludG8gdGhlIGZ1dHVyZSBhIGNvbXBsZXRlICJwcm9ibGVtIGRl dGFpbCIgcGF5bG9hZC4NCg0KRm9yIHRoZSB0aW1lIGJlaW5nIGl0IGNhbiBiZSBvbmUgb2YgNS4w MCwgNS4wMSBvciA0LjAzLg0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQpTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDAxLCAyMDE3IDg6MjINClRvOiBMYXVyaSBQaWlraXZpIDxMYXVyaS5QaWlr aXZpQGFybS5jb20+DQpDYzogRGlqaywgRXNrbyA8ZXNrby5kaWprQHBoaWxpcHMuY29tPjsgY29y ZSAoY29yZUBpZXRmLm9yZykgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIENv QVAgcmVzcG9uc2UgY29kZSBpbiBjYXNlIG9mICJyZXNwb25zZSBwYXlsb2FkIHRvbyBsYXJnZSIg PyA0LjEzPw0KDQpIaSBMYXVyaSwNCg0KaW5kZWVkLCB0aGUgQ29SRSB3b3JsZCBpcyBkaWZmZXJl bnQgZnJvbSB0aGUgSFRUUCB3b3JsZC4NCg0KPiBJIHByb3Bvc2UgYSBiaXQgb2YgaW5mbyBnYXRo ZXJpbmcsIEkgIGltYWdpbmUgdGhlcmUgYXJlIG1vcmUgc2ltaWxhciBraW5kcyBvZiBzaXR1YXRp b25zIHdoZXJlIEhUVFAgaGFzIG5vdCBoYWQgdGhlIHJpZ2h0IGNvZGUuDQoNCldoZW4gd2UgZG8g dGhpcywgSSB3b3VsZCBsaWtlIHRvIGFwcHJvYWNoIG5ldyBjb2RlcyBub3QganVzdCB3aXRoIOKA nHdoYXQgc2hvdWxkIHRoZSBzZXJ2ZXIgZG/igJ0gYnV0IG1vcmUgaW1wb3J0YW50bHkgd2l0aCDi gJxob3cgaXMgdGhlIGNsaWVudCBnb2luZyB0byByZWFjdCBkaWZmZXJlbnRseeKAnS4gIElmIHRo ZSBlcnJvciByZXNwb25zZSBpcyBqdXN0IGFib3V0IHRlbGxpbmcgd2hhdCB3ZW50IHdyb25nIHNv IGEgaHVtYW4gY2FuIGRlYnVnIHRoZSBzaXR1YXRpb24sIGRpYWdub3N0aWMgcGF5bG9hZHMgYXJl IGZpbmUuICBJZiB3ZSBuZWVkIG1vcmUgZGV0YWlsIGluIGFuIGVycm9yIHJlc3BvbnNlIHNvIHRo ZSBjbGllbnQgY2FuIGZvcm11bGF0ZSBhIGJldHRlciByZXF1ZXN0IGJhc2VkIG9uIHRob3NlIGRl dGFpbHMsIHdlIG1heSB3YW50IHRvIHN0YW5kYXJkaXplIOKAnHByb2JsZW0gZGV0YWls4oCdIHBh eWxvYWRzLCBpbnNwaXJlZCBieSBSRkMgNzgwNy4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3Rl ZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3Nl bWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJv aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5k IGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0K Y29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQo= From nobody Thu Feb 9 17:05:16 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152D5129DFF for ; Thu, 9 Feb 2017 17:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkSJ9wmNeRJG for ; Thu, 9 Feb 2017 17:05:13 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0091.outbound.protection.outlook.com [104.47.40.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCCE129649 for ; Thu, 9 Feb 2017 17:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6UhcO8PKx94qJtSqHpsusHdcbR16x+teR57XZ9E4/x0=; b=Yre31NA5/+oNOhKVv6RCyyc2PnLNdovdX/SL+Nn3vgxRpbgOyXrQUWzxy7nsKaGpdvyUKhgZk7IVREqe9aYnrwN7cWhRyBrPpvLwWBQ/dy65n6t8ZPpfzqXVLlKhY5hHMnZL5ZyJEMrazi5K9fYhsRBEZGPwRsbbCE1TADGd6gI= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2377.namprd03.prod.outlook.com (10.166.207.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 01:05:11 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 01:05:11 +0000 From: Brian Raymor To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] Default values for Uri-Host with alternate transports Thread-Index: AQHSfstN6id7Cu5k/0uGeC8GF4wo7qFcdq8ggAT6u6A= Date: Fri, 10 Feb 2017 01:05:11 +0000 Message-ID: References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: bf65860c-ff11-47ee-5c35-08d45150dd23 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2377; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2377; 7:ywMg4e9qAAgLEG9e11gzLM4Z21wmQ+V3N0B8CA4MbJR4e9cC+mLUZbw+e1SbCECanXhk/+fl76EI15A55DLOJXJiE1w5s5SYxr1nshl8+LV17sMM7ybuCIEbj03P3f6+IcmLQIGOR5AxBwlFiSzJpwwTdQfIIAGrqr7A5SeBzwHLY8NcoG1ssP2rdvKcz40PXYmSK2rXUWMsRTKJcRNxU7TGGUJrOSuVyld8rVp8R3hhI8ZSemlkx11HeCcFda2ZV0d8MY+XNnDlyffaQZQ3scwoHrYDBpnnUxCIiXZpCuOdMMbcMM9DdRGnkvncYn6afZQTM1JXVQgPpa/7Hqr4h/SSnWJgAvih2I3frgjP9paNp962gqlOEA9tz3lsXH06Fiue/vP8xFHXM4YrNRG3e7IKCwXBJGZNH/p49ZvPaszNCkBHojTMf6OgSAuUT+zp+KfwzaOFUR5EhHuC1u1KGDOWLCu90exzDB9PZiy/OfrLlmBVO06xB+gWg8kGM4oJQX8YMuvmiW14x9ujY/FcgxemJV8UykbEEXeEQ48NzLo= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(150554046322364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:CY1PR03MB2377; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2377; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39840400002)(39860400002)(39410400002)(39450400003)(13464003)(24454002)(57704003)(199003)(189002)(377454003)(3846002)(3280700002)(3660700001)(66066001)(33656002)(5660300001)(101416001)(8936002)(7696004)(122556002)(54356999)(76176999)(2906002)(4326007)(86612001)(50986999)(7736002)(6246003)(53936002)(68736007)(97736004)(86362001)(2950100002)(102836003)(5005710100001)(10290500002)(189998001)(106116001)(105586002)(6116002)(106356001)(8990500004)(8676002)(81156014)(81166006)(92566002)(9686003)(10090500001)(99286003)(74316002)(2900100001)(305945005)(6436002)(38730400002)(77096006)(54906002)(229853002)(6506006)(55016002)(6306002)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2377; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 01:05:11.3446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2377 Archived-At: Cc: Hannes Tschofenig , Klaus Hartke Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Feb 2017 01:05:15 -0000 I've submitted a pull request based on the suggestions from Carsten and Kla= us - https://github.com/core-wg/coap-tcp-tls/pull/113. I'm curious if there's another alternative - to simplify and not support th= e Uri-* options on reliable transports.=20 If the main scenario as noted in RFC7252 is " Explicit Uri-Host and Uri-Por= t Options are typically used when an endpoint hosts multiple virtual server= s",=20 then as Klaus noted in the original TRAC issue - https://trac.ietf.org/trac= /core/ticket/391, this is less relevant for CoAP over reliable transports (= with perhaps the exception of CoAP over TCP): In CoAP over WebSockets, the virtual server is specified during the Web= Socket handshake in the Host header field. The Uri-Host Option is therefore not needed. A client wis= hing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connec= tion to each virtual server ... In CoAP over TLS we have the SNI extension, so I would expect that CoAP= over TLS behaves like CoAP over WebSockets: no Uri-Host Option in requests, one connection to each= virtual server. Carsten called out the same scenario in a related discussion on https://www= .ietf.org/mail-archive/web/6tisch/current/msg02195.html: (The Uri-Host option actually is about the destination of the message,= to distinguish several servers that might share an IP address/port number.= ) Thoughts? How are early CoAP over TCP implementations using these options? ...Brian -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Raymor Sent: Monday, February 6, 2017 5:31 PM To: Carsten Bormann ; core@ietf.org WG Subject: Re: [core] Default values for Uri-Host with alternate transports This is tracked in https://github.com/core-wg/coap-tcp-tls/issues/108. I'd = welcome *broader* WG discussion for this issue. It's the remaining issue th= at's blocking coap-tcp-tls-06. On Saturday, February 4, 2017 1:44 AM, Carsten Bormann wrote: > For WebSockets, that does not quite work. The WebSocket hostname is need= ed to make the connection, so that should also be the default value of the = Uri-Host for requests in the direction from the WebSocket client to the Web= Socket server. =20 There's already text in the WD for this case: The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per {{RFC6455}}. The Host header field also indicates the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server. > In the last authors' call, we agreed to remove the signalling option that= would allow to set a different default URI host (used to be called "Server= -Name" analogously to SNI; a better name is "Default-Uri-Host"), as we were= n't aware of an implementation. > Do we need to keep it to solve anything of the above? I don't see the need if appropriate defaults are adequately specified. Most= of the related language in the Default-Uri-Host was to describe the "base = values" for Uri-Host based on the transport - the values which are used if = Default-Uri-Host (aka Server-Name) is never sent. =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Feb 10 02:58:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108A11294CA for ; Fri, 10 Feb 2017 02:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=163.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_yHcmRTUg-Q for ; Fri, 10 Feb 2017 02:58:00 -0800 (PST) Received: from m13-91.163.com (m13-91.163.com [220.181.13.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2798C1270B4 for ; Fri, 10 Feb 2017 02:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=YFDVB KPmEdIZ+FSP7GEBlRq/rUX/4hJjQrEuNNtJ/bE=; b=F+RVJgPK6ZYwGqtGQPghz +3UTOd309I0F8kCMbO3d9YOPgaxRPc3dzQBT/0/7EXc0wIsnQRIyX3ls0jZB7JNB AHTi5kIhS82H4Q2ste5G7uEEspB2biJXMczrkYd4ml4a8LnrtWb5B470ecyTb8OW jRBWtgrDADM7XxZXdXZP0U= Received: from yjsslcqupt$163.com ( [119.36.151.157] ) by ajax-webmail-wmsvr91 (Coremail) ; Fri, 10 Feb 2017 18:57:55 +0800 (CST) X-Originating-IP: [119.36.151.157] Date: Fri, 10 Feb 2017 18:57:55 +0800 (CST) From: =?GBK?B?ydvC1w==?= To: =?GBK?B?Y29yZSAguaTX99fp08rP5MHQse0=?= X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160729(86883.8884) Copyright (c) 2002-2017 www.mailtech.cn 163com Content-Type: multipart/alternative; boundary="----=_Part_271524_405387236.1486724275692" MIME-Version: 1.0 Message-ID: <438f7638.115b0.15a27ac1ded.Coremail.yjsslcqupt@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: W8GowECpFEC0nJ1YT7hTAA--.12984W X-CM-SenderInfo: p1mv2zhftx13i6rwjhhfrp/xtbBRwF6QVO-13a+PwABsw X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: Subject: [core] Requirements Analysis and Message Transmission for OPC UA over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Feb 2017 10:58:02 -0000 ------=_Part_271524_405387236.1486724275692 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgLAoKCgoKoaGhoSBJbmR1c3RyaWFsIEludGVybmV0IG9mIFRoaW5ncyBpcyBhbiBhdHRyYWN0 aXZlIGFwcGxpY2F0aW9uIGFyZWEgZm9yIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29s IChDb0FQKS4gT1BDIFVuaWZpZWQgQXJjaGl0ZWN0dXJlIChPUEMgVUEpIGRlZmluZXMgYSBzZW1h bnRpYy1iYXNlZCBpbmZvcm1hdGlvbiBtb2RlbCBmb3IgaW5kdXN0cmlhbCBjb250cm9sIHN5c3Rl bSB0aGF0IGNhbiBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgb2YgSW5kdXN0cnkgNC4wIGJhc2Vk IG9uIHNlbWFudGljIGluZm9ybWF0aW9uIGV4Y2hhbmdlLiBNeSBjb2xsZWFndWVzIGFuZCBJIHB1 dCBmb3J3YXJkIHNvbWUgaWRlYXMgYWJvdXQgcmVxdWlyZW1lbnRzIGFuYWx5c2lzIGFuZCBtZXNz YWdlIHRyYW5zbWlzc2lvbiBmb3IgT1BDIFVBIG92ZXIgQ29BUCwgIHdlIGFsc28gaGF2ZSBzdWJt aXR0ZWQgdHdvIGRvY3VtZW50cyBvbmxpbmUgdG8gY29yZSBncm91cCB3b3JraW5nIG9mIElFVEYg b3JnYW5pemF0aW9uLAogaW5jbHVkaW5nImRyYWZ0LXdhbmctY29yZS1vcGN1YS10cmFuc21pc3Np b24tMDAiICAgICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13 YW5nLWNvcmUtb3BjdWEtdHJhbnNtaXNzaW9uLwogYW5kICJkcmFmdC13YW5nLWNvcmUtb3BjdWEt dHJhbnNtaXRpb24tcmVxdWlyZW1lbnRzLTAwIiAgICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1jb3JlLW9wY3VhLXRyYW5zbWl0aW9uLXJlcXVpcmVt ZW50cy8KCgoKoaGhoUxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIHJlcGx5IGFuZCBmZWVkYmFjawqh oaGhQmVzdCB3aXNoZXMsCqGhoaFMdW4gU2hhbw== ------=_Part_271524_405387236.1486724275692 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxwcmUgaWQ9ImJlc3QtY29udGVudC0xMDUzMDk2Mjc5IiBhY2N1 c2U9ImFDb250ZW50IiBjbGFzcz0iYmVzdC10ZXh0IG1iLTEwIiBzdHlsZT0id2lkdGg6IDEyMzgu MDRweDsgbWFyZ2luLXRvcDogMTBweDsgbWFyZ2luLWJvdHRvbTogMTBweDsgcGFkZGluZzogMHB4 OyBtaW4taGVpZ2h0OiA1NXB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOXB4OyBjb2xv cjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywgJ0xhbnRpbmdo ZWkgU0MnLCAnTWljcm9zb2Z0IFlhSGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYsIHRhaG9t YTsiPkhpICw8L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOXB4OyBjb2xvcjogcmdi KDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywgJ0xhbnRpbmdoZWkgU0Mn LCAnTWljcm9zb2Z0IFlhSGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYsIHRhaG9tYTsiPiA8 YnI+PGJyIHN0eWxlPSJjb250ZW50OiAmcXVvdDsmcXVvdDs7IGRpc3BsYXk6IGJsb2NrOyB3aWR0 aDogNzAwcHg7IGhlaWdodDogMHB4OyBtYXJnaW46IDIwcHggMHB4OyI+PC9zcGFuPjxwcmUgaWQ9 ImJlc3QtY29udGVudC0xMDUzMDk2Mjc5IiBhY2N1c2U9ImFDb250ZW50IiBjbGFzcz0iYmVzdC10 ZXh0IG1iLTEwIiBzdHlsZT0id2lkdGg6IDEyMzguMDRweDsgbWFyZ2luLXRvcDogMTBweDsgbWFy Z2luLWJvdHRvbTogMTBweDsgcGFkZGluZzogMHB4OyBtaW4taGVpZ2h0OiA1NXB4OyI+PGJyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjlweDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1p bHk6ICdQaW5nRmFuZyBTQycsICdMYW50aW5naGVpIFNDJywgJ01pY3Jvc29mdCBZYUhlaScsIGFy aWFsLCDLzszlLCBzYW5zLXNlcmlmLCB0YWhvbWE7IGZvbnQtc2l6ZTogMTZweDsgY29udGVudDog JnF1b3Q7JnF1b3Q7OyBkaXNwbGF5OiBibG9jazsgd2lkdGg6IDcwMHB4OyBoZWlnaHQ6IDBweDsg bWFyZ2luOiAyMHB4IDBweDsiPjxkaXY+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOXB4OyBj b2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywgJ0xhbnRp bmdoZWkgU0MnLCAnTWljcm9zb2Z0IFlhSGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYsIHRh aG9tYTsiPqGhoaEmbmJzcDs8L3NwYW4+PGZvbnQgY29sb3I9IiMzMzMzMzMiIGZhY2U9IlBpbmdG YW5nIFNDLCBMYW50aW5naGVpIFNDLCBNaWNyb3NvZnQgWWFIZWksIGFyaWFsLCDLzszlLCBzYW5z LXNlcmlmLCB0YWhvbWEiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjlweDsiPkluZHVzdHJp YWwgSW50ZXJuZXQgb2YgVGhpbmdzIGlzIGFuIGF0dHJhY3RpdmUgYXBwbGljYXRpb24gYXJlYSBm b3IgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLiBPUEMgVW5pZmllZCBB cmNoaXRlY3R1cmUgKE9QQyBVQSkgZGVmaW5lcyBhIHNlbWFudGljLWJhc2VkIGluZm9ybWF0aW9u IG1vZGVsIGZvciBpbmR1c3RyaWFsIGNvbnRyb2wgc3lzdGVtIHRoYXQgY2FuIHNhdGlzZnkgdGhl IHJlcXVpcmVtZW50cyBvZiBJbmR1c3RyeSA0LjAgYmFzZWQgb24gc2VtYW50aWMgaW5mb3JtYXRp b24gZXhjaGFuZ2UuIDwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOXB4 OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywgJ0xh bnRpbmdoZWkgU0MnLCAnTWljcm9zb2Z0IFlhSGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYs IHRhaG9tYTsiPk15IGNvbGxlYWd1ZXMgYW5kIEkmbmJzcDtwPC9zcGFuPjxmb250IGNvbG9yPSIj MzMzMzMzIiBmYWNlPSJQaW5nRmFuZyBTQywgTGFudGluZ2hlaSBTQywgTWljcm9zb2Z0IFlhSGVp LCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFob21hIj48c3BhbiBzdHlsZT0ibGluZS1oZWln aHQ6IDI5cHg7Ij51dCBmb3J3YXJkIHNvbWUgaWRlYXMgYWJvdXQmbmJzcDtyZXF1aXJlbWVudHMg YW5hbHlzaXMgYW5kIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIGZvciBPUEMgVUEgb3ZlciBDb0FQLCA8 L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJQaW5nRmFuZyBTQywgTGFu dGluZ2hlaSBTQywgTWljcm9zb2Z0IFlhSGVpLCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFo b21hIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuNzsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDog MjlweDsiPiB3ZSBhbHNvIDwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAy OXB4OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywg J0xhbnRpbmdoZWkgU0MnLCAnTWljcm9zb2Z0IFlhSGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2Vy aWYsIHRhaG9tYTsiPmhhdmUgc3VibWl0dGVkIHR3byBkb2N1bWVudHMgb25saW5lIHRvIGNvcmUg Z3JvdXAgd29ya2luZyBvZiBJRVRGIG9yZ2FuaXphdGlvbiw8L3NwYW4+PC9kaXY+PGRpdj48c3Bh biBzdHlsZT0ibGluZS1oZWlnaHQ6IDI5cHg7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQt ZmFtaWx5OiAnUGluZ0ZhbmcgU0MnLCAnTGFudGluZ2hlaSBTQycsICdNaWNyb3NvZnQgWWFIZWkn LCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFob21hOyI+IGluY2x1ZGluZyI8L3NwYW4+PHNw YW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOXB4OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250 LWZhbWlseTogJ1BpbmdGYW5nIFNDJywgJ0xhbnRpbmdoZWkgU0MnLCAnTWljcm9zb2Z0IFlhSGVp JywgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYsIHRhaG9tYTsiPmRyYWZ0LXdhbmctY29yZS1vcGN1 YS10cmFuc21pc3Npb24tMDA8L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOXB4OyBj b2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywgJ0xhbnRp bmdoZWkgU0MnLCAnTWljcm9zb2Z0IFlhSGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYsIHRh aG9tYTsiPiIgICAgICAgICAgIDwvc3Bhbj48Zm9udCBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iUGlu Z0ZhbmcgU0MsIExhbnRpbmdoZWkgU0MsIE1pY3Jvc29mdCBZYUhlaSwgYXJpYWwsIMvOzOUsIHNh bnMtc2VyaWYsIHRhaG9tYSI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOXB4OyI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1jb3JlLW9wY3VhLXRyYW5zbWlz c2lvbi88L3NwYW4+PC9mb250PjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAy OXB4OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywg J0xhbnRpbmdoZWkgU0MnLCAnTWljcm9zb2Z0IFlhSGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2Vy aWYsIHRhaG9tYTsiPiBhbmQgIjwvc3Bhbj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDI5cHg7 IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiAnUGluZ0ZhbmcgU0MnLCAnTGFu dGluZ2hlaSBTQycsICdNaWNyb3NvZnQgWWFIZWknLCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwg dGFob21hOyI+ZHJhZnQtd2FuZy1jb3JlLW9wY3VhLXRyYW5zbWl0aW9uLXJlcXVpcmVtZW50cy0w MDwvc3Bhbj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDI5cHg7IGNvbG9yOiByZ2IoNTEsIDUx LCA1MSk7IGZvbnQtZmFtaWx5OiAnUGluZ0ZhbmcgU0MnLCAnTGFudGluZ2hlaSBTQycsICdNaWNy b3NvZnQgWWFIZWknLCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFob21hOyI+IiAgICAgICAg ICAgPC9zcGFuPjxmb250IGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJQaW5nRmFuZyBTQywgTGFudGlu Z2hlaSBTQywgTWljcm9zb2Z0IFlhSGVpLCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFob21h Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDI5cHg7Ij5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC13YW5nLWNvcmUtb3BjdWEtdHJhbnNtaXRpb24tcmVxdWlyZW1lbnRz Lzwvc3Bhbj48L2ZvbnQ+PC9kaXY+PC9wcmU+PHByZSBpZD0iYmVzdC1jb250ZW50LTEwNTMwOTYy NzkiIGFjY3VzZT0iYUNvbnRlbnQiIGNsYXNzPSJiZXN0LXRleHQgbWItMTAiIHN0eWxlPSJsaW5l LWhlaWdodDogMTkuMDRweDsgd2lkdGg6IDEyMzguMDRweDsgbWFyZ2luLXRvcDogMTBweDsgbWFy Z2luLWJvdHRvbTogMTBweDsgcGFkZGluZzogMHB4OyBtaW4taGVpZ2h0OiA1NXB4OyI+PHNwYW4g c3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiAnUGluZ0ZhbmcgU0Mn LCAnTGFudGluZ2hlaSBTQycsICdNaWNyb3NvZnQgWWFIZWknLCBhcmlhbCwgy87M5Swgc2Fucy1z ZXJpZiwgdGFob21hOyBsaW5lLWhlaWdodDogMjlweDsiPjxiciBzdHlsZT0iY29udGVudDogJnF1 b3Q7JnF1b3Q7OyBkaXNwbGF5OiBibG9jazsgd2lkdGg6IDcwMHB4OyBoZWlnaHQ6IDBweDsgbWFy Z2luOiAyMHB4IDBweDsiPjwvc3Bhbj48YnIgc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7 IGZvbnQtZmFtaWx5OiAnUGluZ0ZhbmcgU0MnLCAnTGFudGluZ2hlaSBTQycsICdNaWNyb3NvZnQg WWFIZWknLCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFob21hOyBmb250LXNpemU6IDE2cHg7 IGxpbmUtaGVpZ2h0OiAyOXB4OyBjb250ZW50OiAmcXVvdDsmcXVvdDs7IGRpc3BsYXk6IGJsb2Nr OyB3aWR0aDogNzAwcHg7IGhlaWdodDogMHB4OyBtYXJnaW46IDIwcHggMHB4OyI+PGJyIHN0eWxl PSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywgJ0xh bnRpbmdoZWkgU0MnLCAnTWljcm9zb2Z0IFlhSGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYs IHRhaG9tYTsgZm9udC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogMjlweDsgY29udGVudDogJnF1 b3Q7JnF1b3Q7OyBkaXNwbGF5OiBibG9jazsgd2lkdGg6IDcwMHB4OyBoZWlnaHQ6IDBweDsgbWFy Z2luOiAyMHB4IDBweDsiPjxmb250IGZhY2U9IlBpbmdGYW5nIFNDLCBMYW50aW5naGVpIFNDLCBN aWNyb3NvZnQgWWFIZWksIGFyaWFsLCDLzszlLCBzYW5zLXNlcmlmLCB0YWhvbWEiIHN0eWxlPSJm b250LWZhbWlseTogJ1BpbmdGYW5nIFNDJywgJ0xhbnRpbmdoZWkgU0MnLCAnTWljcm9zb2Z0IFlh SGVpJywgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYsIHRhaG9tYTsgbGluZS1oZWlnaHQ6IDE5LjA0 cHg7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDI5cHg7Ij6hoaGhTG9va2luZyBmb3J3YXJk IHRvIHlvdXIgcmVwbHkgYW5kIGZlZWRiYWNrPC9zcGFuPjwvZm9udD48YnIgc3R5bGU9ImNvbG9y OiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiAnUGluZ0ZhbmcgU0MnLCAnTGFudGluZ2hl aSBTQycsICdNaWNyb3NvZnQgWWFIZWknLCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFob21h OyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiAyOXB4OyBjb250ZW50OiAmcXVvdDsmcXVv dDs7IGRpc3BsYXk6IGJsb2NrOyB3aWR0aDogNzAwcHg7IGhlaWdodDogMHB4OyBtYXJnaW46IDIw cHggMHB4OyI+PGZvbnQgZmFjZT0iUGluZ0ZhbmcgU0MsIExhbnRpbmdoZWkgU0MsIE1pY3Jvc29m dCBZYUhlaSwgYXJpYWwsIMvOzOUsIHNhbnMtc2VyaWYsIHRhaG9tYSIgc3R5bGU9ImZvbnQtZmFt aWx5OiAnUGluZ0ZhbmcgU0MnLCAnTGFudGluZ2hlaSBTQycsICdNaWNyb3NvZnQgWWFIZWknLCBh cmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFob21hOyBsaW5lLWhlaWdodDogMTkuMDRweDsiPjxz cGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjlweDsiPqGhoaFCZXN0IHdpc2hlcyw8L3NwYW4+PC9m b250PjxiciBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6ICdQaW5n RmFuZyBTQycsICdMYW50aW5naGVpIFNDJywgJ01pY3Jvc29mdCBZYUhlaScsIGFyaWFsLCDLzszl LCBzYW5zLXNlcmlmLCB0YWhvbWE7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IDI5cHg7 IGNvbnRlbnQ6ICZxdW90OyZxdW90OzsgZGlzcGxheTogYmxvY2s7IHdpZHRoOiA3MDBweDsgaGVp Z2h0OiAwcHg7IG1hcmdpbjogMjBweCAwcHg7Ij48Zm9udCBmYWNlPSJQaW5nRmFuZyBTQywgTGFu dGluZ2hlaSBTQywgTWljcm9zb2Z0IFlhSGVpLCBhcmlhbCwgy87M5Swgc2Fucy1zZXJpZiwgdGFo b21hIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdQaW5nRmFuZyBTQycsICdMYW50aW5naGVpIFNDJywg J01pY3Jvc29mdCBZYUhlaScsIGFyaWFsLCDLzszlLCBzYW5zLXNlcmlmLCB0YWhvbWE7IGxpbmUt aGVpZ2h0OiAxOS4wNHB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOXB4OyI+oaGhoUx1 biBTaGFvPC9zcGFuPjwvZm9udD48L3ByZT48L3ByZT48L2Rpdj4= ------=_Part_271524_405387236.1486724275692-- From nobody Fri Feb 10 04:44:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECE3129572 for ; Fri, 10 Feb 2017 04:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_s4fp_0me3I for ; Fri, 10 Feb 2017 04:44:08 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D9F129494 for ; Fri, 10 Feb 2017 04:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1ACi4E7016702 for ; Fri, 10 Feb 2017 13:44:04 +0100 (CET) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vKZPv66HQz3ZrQ for ; Fri, 10 Feb 2017 13:44:03 +0100 (CET) Received: by mail-it0-f41.google.com with SMTP id r185so31868670ita.0 for ; Fri, 10 Feb 2017 04:44:03 -0800 (PST) X-Gm-Message-State: AIkVDXLcLEttzMQ01ZrB5ox0pjS8tfOS8QaNUvzjjJX+R8pRc378INf+pzRJ1wyIkVu/4fYk2iojMVt3zveQmw== X-Received: by 10.36.17.9 with SMTP id 9mr27889028itf.84.1486730642571; Fri, 10 Feb 2017 04:44:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.170.5 with HTTP; Fri, 10 Feb 2017 04:43:22 -0800 (PST) In-Reply-To: References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> From: Klaus Hartke Date: Fri, 10 Feb 2017 13:43:22 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hannes Tschofenig , "core@ietf.org WG" Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Feb 2017 12:44:10 -0000 Brian Raymor wrote: > I'm curious if there's another alternative - to simplify and not support the Uri-* options on reliable transports. I assume you mean Uri-Host and Uri-Port when you say Uri-*, because not supporting Uri-Path and Uri-Query does not make sense. > " Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers" Uri-Host and Uri-Port are also used together with Uri-Scheme when talking to a CoAP forward proxy. > Thoughts? IMO we should aim for consistency. There are three decisions to be made: (Survey made is less than 5 minutes, please correct me if I'm wrong.) 1) Virtual servers are supported -or- Virtual servers are not supported * CoAP over UDP: yes * CoAP over DTLS: yes * CoAP over TCP: ? * CoAP over TLS: yes * CoAP over WebSockets: yes * HTTP/1.1 over TCP: yes * HTTP/1.1 over TLS: yes * HTTP/2 over TCP: yes * HTTP/2 over TLS: yes I think it's obvious what CoAP over TCP should do. 2) Server name in each request -or- Server name during connection setup * CoAP over UDP: each request * CoAP over DTLS: connection setup * CoAP over TCP: ? * CoAP over TLS: connection setup * CoAP over WebSockets: connection setup * HTTP/1.1 over TCP: each request * HTTP/1.1 over TLS: both * HTTP/2 over TCP: both * HTTP/2 over TLS: both For CoAP over TCP, server name during connection setup would be more efficient, but server name in each request is probably fine, too. 3) One connection per virtual server -or- Connection can be reused for multiple virtual servers with the same IP address * CoAP over UDP: n/a * CoAP over DTLS: RFC 7252 does not specify this, so most likely one connection per virtual server * CoAP over TCP: ? * CoAP over TLS: ? * CoAP over WebSockets: ? * HTTP/1.1 over TCP: one connection per virtual server * HTTP/1.1 over TLS: one connection per virtual server * HTTP/2 over TCP: connection can be reused [1] * HTTP/2 over TLS: connection can be reused [1] I don't have a strong opinion on this. Klaus [1] https://tools.ietf.org/html/rfc7540#section-9.1.1 From nobody Fri Feb 10 08:17:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086101299EB for ; Fri, 10 Feb 2017 08:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RehxVFNSD-Co for ; Fri, 10 Feb 2017 08:17:15 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65642129989 for ; Fri, 10 Feb 2017 08:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1AGHA5p015165; Fri, 10 Feb 2017 17:17:10 +0100 (CET) Received: from [192.168.1.24] (unknown [201.216.60.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vKg7p0n2Mz3ZwX; Fri, 10 Feb 2017 17:17:10 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-B529E3E7-C3E3-4D2B-8E14-99E2011DD4B9 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Fri, 10 Feb 2017 11:17:07 -0500 Content-Transfer-Encoding: 7bit Message-Id: <40D63EC0-A11D-4AB0-8FB2-471721EE2C0E@tzi.org> References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> To: Klaus Hartke Archived-At: Cc: Hannes Tschofenig , "core@ietf.org WG" Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Feb 2017 16:17:18 -0000 --Apple-Mail-B529E3E7-C3E3-4D2B-8E14-99E2011DD4B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable When discussing this, please don't forget the inverse direction -- there is n= o guidance even in ws or TLS what the URI-host should be. This needs a defau= lt.=20 Sent from mobile > On 10 Feb 2017, at 07:43, Klaus Hartke wrote: >=20 > Brian Raymor wrote: >> I'm curious if there's another alternative - to simplify and not support t= he Uri-* options on reliable transports. >=20 > I assume you mean Uri-Host and Uri-Port when you say Uri-*, because > not supporting Uri-Path and Uri-Query does not make sense. >=20 >> " Explicit Uri-Host and Uri-Port Options are typically used when an endpo= int hosts multiple virtual servers" >=20 > Uri-Host and Uri-Port are also used together with Uri-Scheme when > talking to a CoAP forward proxy. >=20 >> Thoughts? >=20 > IMO we should aim for consistency. There are three decisions to be made: >=20 > (Survey made is less than 5 minutes, please correct me if I'm wrong.) >=20 > 1) >=20 > Virtual servers are supported > -or- > Virtual servers are not supported >=20 > * CoAP over UDP: yes > * CoAP over DTLS: yes > * CoAP over TCP: ? > * CoAP over TLS: yes > * CoAP over WebSockets: yes > * HTTP/1.1 over TCP: yes > * HTTP/1.1 over TLS: yes > * HTTP/2 over TCP: yes > * HTTP/2 over TLS: yes >=20 > I think it's obvious what CoAP over TCP should do. >=20 > 2) >=20 > Server name in each request > -or- > Server name during connection setup >=20 > * CoAP over UDP: each request > * CoAP over DTLS: connection setup > * CoAP over TCP: ? > * CoAP over TLS: connection setup > * CoAP over WebSockets: connection setup > * HTTP/1.1 over TCP: each request > * HTTP/1.1 over TLS: both > * HTTP/2 over TCP: both > * HTTP/2 over TLS: both >=20 > For CoAP over TCP, server name during connection setup would be more > efficient, but server name in each request is probably fine, too. >=20 > 3) >=20 > One connection per virtual server > -or- > Connection can be reused for multiple virtual servers with the same IP add= ress >=20 > * CoAP over UDP: n/a > * CoAP over DTLS: RFC 7252 does not specify this, so most likely one > connection per virtual server > * CoAP over TCP: ? > * CoAP over TLS: ? > * CoAP over WebSockets: ? > * HTTP/1.1 over TCP: one connection per virtual server > * HTTP/1.1 over TLS: one connection per virtual server > * HTTP/2 over TCP: connection can be reused [1] > * HTTP/2 over TLS: connection can be reused [1] >=20 > I don't have a strong opinion on this. >=20 > Klaus >=20 > [1] https://tools.ietf.org/html/rfc7540#section-9.1.1 >=20 --Apple-Mail-B529E3E7-C3E3-4D2B-8E14-99E2011DD4B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
When discussing this, please don't for= get the inverse direction -- there is no guidance even in ws or TLS what the= URI-host should be. This needs a default. 

Sent from mobile

On 10 Feb 2017, at 0= 7:43, Klaus Hartke <hartke@tzi.org&= gt; wrote:

Brian Raymor wr= ote:
I'm curious if there's anothe= r alternative - to simplify and not support the Uri-* options on reliable tr= ansports.

I assume you mean Ur= i-Host and Uri-Port when you say Uri-*, because
not supporti= ng Uri-Path and Uri-Query does not make sense.

" Explicit Uri-Host and Uri-Port Options are t= ypically used when an endpoint hosts multiple virtual servers"

Uri-Host and Uri-Port are also used togethe= r with Uri-Scheme when
talking to a CoAP forward proxy.

Thoughts?
<= /blockquote>
IMO we should aim for consistency. There a= re three decisions to be made:

(Survey made= is less than 5 minutes, please correct me if I'm wrong.)

1)

Virtual servers are suppo= rted
-or-
Virtual servers are not supported<= /span>

* CoAP over UDP: yes
* CoAP= over DTLS: yes
* CoAP over TCP: ?
* CoAP ov= er TLS: yes
* CoAP over WebSockets: yes
* HT= TP/1.1 over TCP: yes
* HTTP/1.1 over TLS: yes
* HTTP/2 over TCP: yes
* HTTP/2 over TLS: yes

I think it's obvious what CoAP over TCP should do.

2)

Server name= in each request
-or-
Server name during con= nection setup

* CoAP over UDP: each request=
* CoAP over DTLS: connection setup
* CoAP o= ver TCP: ?
* CoAP over TLS: connection setup
* CoAP over WebSockets: connection setup
* HTTP/1.1 over TC= P: each request
* HTTP/1.1 over TLS: both
* H= TTP/2 over TCP: both
* HTTP/2 over TLS: both

For CoAP over TCP, server name during connection setup wou= ld be more
efficient, but server name in each request is pro= bably fine, too.

3)
=
One connection per virtual server
-or-
<= span>Connection can be reused for multiple virtual servers with the same IP a= ddress

* CoAP over UDP: n/a
* CoAP over DTLS: RFC 7252 does not specify this, so most likely one=
connection per virtual server
* CoAP over TCP: ?
* CoAP over TLS: ?
* CoAP over WebSockets: ?<= /span>
* HTTP/1.1 over TCP: one connection per virtual server
* HTTP/1.1 over TLS: one connection per virtual server
= * HTTP/2 over TCP: connection can be reused [1]
* HTTP= /2 over TLS: connection can be reused [1]

I= don't have a strong opinion on this.

Klaus=

[1] https://tools.ietf.org/html/rfc7540#section-9.1.1

= --Apple-Mail-B529E3E7-C3E3-4D2B-8E14-99E2011DD4B9-- From nobody Fri Feb 10 15:18:26 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690E01295D2 for ; Fri, 10 Feb 2017 15:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saVh41TGOemH for ; Fri, 10 Feb 2017 15:18:23 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0094.outbound.protection.outlook.com [104.47.34.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7341B128874 for ; Fri, 10 Feb 2017 15:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F9xBB4YljOVyh19jsuLJMquHoFzPWLhGtscJ2neuc40=; b=YHChiNS1qOg7nn5RGzslkWOedaZTThUUttTLq+v+6a/D+6+fZAriwaWgPEqSHm+my5P5uUD2Wj2tojplv0a9ug/D9hZghYZZpYYjO3WUjhUmEDbpuTYAU/Cj3olh6gjwKHdCdp52F+oJLnmZR0vAdscIzPYmrv5uzuxFSGApRBg= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 23:18:19 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0888.029; Fri, 10 Feb 2017 23:18:19 +0000 From: Brian Raymor To: Carsten Bormann Thread-Topic: [core] Default values for Uri-Host with alternate transports Thread-Index: AQHSfstN6id7Cu5k/0uGeC8GF4wo7qFcdq8ggAT6u6CAAMeGAIAAO7iAgABvb1A= Date: Fri, 10 Feb 2017 23:18:19 +0000 Message-ID: References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> <40D63EC0-A11D-4AB0-8FB2-471721EE2C0E@tzi.org> In-Reply-To: <40D63EC0-A11D-4AB0-8FB2-471721EE2C0E@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: ec13cfa2-a4f1-4ccb-585f-08d4520b19cc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2380; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:n68hDTMeFRn+6eaxikcskA0mT0qmKruDvhYK7Ix1BelDsPrSF8rC2X2Qe+HMnL4bTZL1RW2pkGb6uOUbY39C15bnYXhe1GOYCHNSA+5zFOyttju2o3ISzM9T6LRTaavp7mAj/Vd4j4aymHv0qARGfihixAhf7Z+vlbmtg7/8eTs2N93Rf69oHk63Ut0UTG0A02zPFqBjQH9j1ftN7Wv1+alUw4e3s3ser4YoncGw/NQyfjsREIZRC2Tj+FdWyQfoVEYoyhUFlwAfhGO0CmhhuZwBGUJW7IROm5E33i3st/+N1lyEJPD9ev+VZarve0sQiGhRG2A/ZmOqvMezjCwepU36oflnqVkKfNHkMJpmb9tMFPH/Yd/q185xcmPbK9+nAzxfmAYHKtihSp+6GglItB4WPqMsAOHA8WqoK+P1HCGTlpMdN1UvIk8kHY3kCWrUu1xN6ZqNp3RQ1TrjdcgVLB51NCEOJSgRErf5jDSyhNFfKja5ZKlUNGM948FvlGDcaoWxEhHdlNIkZIv6zz7s+L6+lT1ztXUrvvUf3MQZn24= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(6072148)(6042181); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(189002)(377454003)(101416001)(50986999)(6246003)(189998001)(3280700002)(86612001)(76176999)(54356999)(3660700001)(110136004)(305945005)(7736002)(97736004)(38730400002)(53936002)(86362001)(5660300001)(229853002)(10290500002)(6116002)(7696004)(2906002)(4326007)(6916009)(2950100002)(122556002)(8990500004)(5005710100001)(3846002)(74316002)(102836003)(81166006)(6506006)(81156014)(8936002)(105586002)(54906002)(93886004)(25786008)(106116001)(6436002)(66066001)(8676002)(106356001)(10090500001)(9686003)(92566002)(68736007)(99286003)(77096006)(33656002)(2900100001)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 23:18:19.3780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Cc: Hannes Tschofenig , "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Feb 2017 23:18:25 -0000 DQpTaW5jZSB0aGVyZSBhcmUgbXVsdGlwbGUsIGVhcmx5IGltcGxlbWVudGF0aW9ucyBvZiBDb0FQ IG92ZXIgVENQIGluIHRoZSB3aWxkLCBJIGNvbnRpbnVlIHRvIGJlIGN1cmlvdXMNCmFib3V0IHRo ZSBkZXNpZ24gY2hvaWNlcyB0aGF0IHRoZXkndmUgbWFkZSB3aGljaCBtaWdodCBoZWxwIHVzIG1h a2UgYW4gaW5mb3JtZWQgZGVjaXNpb24uIA0KDQpPbiBGcmlkYXksIEZlYnJ1YXJ5IDEwLCAyMDE3 IDg6MTcgQU0sIENhcnN0ZW4gQm9ybWFubiB3cm90ZToNCg0KPiBXaGVuIGRpc2N1c3NpbmcgdGhp cywgcGxlYXNlIGRvbid0IGZvcmdldCB0aGUgaW52ZXJzZSBkaXJlY3Rpb24gLS0NCj4gIHRoZXJl IGlzIG5vIGd1aWRhbmNlIGV2ZW4gaW4gd3Mgb3IgVExTIHdoYXQgdGhlIFVSSS1ob3N0IHNob3Vs ZCBiZS4gVGhpcyBuZWVkcyBhIGRlZmF1bHQuwqANCg0KVGhlIGRpZmZpY3VsdHkgaW4gdGhpcyBj YXNlIGlzIG9mZmVyaW5nIGEgcmVhbGlzdGljIGFuZCB1c2VmdWwgZGVmYXVsdCB3aXRob3V0IHRv byBtYW55IGNhdmVhdHMuIEFzIHlvdSBub3RlZCBpbiB5b3VyIGVhcmxpZXIgbWVzc2FnZToNCg0K PiAoSXQgaXMgbm90IHF1aXRlIGNsZWFyIHRoYXQgdGhlIGFjY2VwdG9yIG9mIHRoZSBUQ1AgY29u bmVjdGlvbiBjb3VsZCBjcmVhdGUgYSBuZXcgY29ubmVjdGlvbiBieSBvcGVuaW5nIGEgVENQIGNv bm5lY3Rpb24gdG8gaG9zdC9wb3J0IG9mIHdoZXJlDQo+IGl0IGFjY2VwdGVkIHRoZSBjb25uZWN0 aW9uIGZyb20sIGJ1dCBhdCBsZWFzdCB0aGVyZSBpcyBzb21lIGFkZHJlc3Mgb3duZXJzaGlwLikN Cg0KPiAoSW4gcHJhY3RpY2UsIGl0IGlzIHJhdGhlciB1bmxpa2VseSB0aGF0IGEgV2ViU29ja2V0 cyBjbGllbnQgYWxzbyBpcyBhIFdlYlNvY2tldHMgc2VydmVyLiAgU3RpbGwsIGl0IGlzIHZlcnkg dXNlZnVsIGZvciB0aGUgQ29BUCBlbmRwb2ludCBhdCB0aGUgV2ViU29ja2V0IHNlcnZlciB0byBj YWxsDQo+IGJhY2sgdGhlIENvQVAgZW5kcG9pbnQgYXQgdGhlIFdlYnNvY2tldCBjbGllbnQsIGV2 ZW4gaWYgdGhhdCBpcyBiYXNlZCBvbiAiWW91LCB3aG9ldmVyIGp1c3QgY2FsbGVkIG1lIiIuICAN Cj4gQnV0IHdlIGRvbid0IGhhdmUgYW5vbnltb3VzLCBlcGhlbWVyYWwgaG9zdHMgaW4gVVJJcy4g IFlldC4pDQoNCj4gVGhlcmUgaXMgbm8gd2F5IHRvIGluZGljYXRlIHJldmVyc2UgU05JLCB0aG91 Z2ggLS0gY2FuIHdlIGJlIHN1cmUgdGhhdCBpcyBuZXZlciBuZWVkZWQ/ICBXb3VsZCBhIGNsaWVu dCBjZXJ0aWZpY2F0ZSBjaGFuZ2UgYW55dGhpbmcgaGVyZT8NCg0KLi4uQnJpYW4NCg0KDQo= From nobody Fri Feb 10 15:44:31 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83491294DA for ; Fri, 10 Feb 2017 15:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GTb_CAEjFwq for ; Fri, 10 Feb 2017 15:44:28 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4195C1294D4 for ; Fri, 10 Feb 2017 15:44:28 -0800 (PST) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1486770262; h=from:subject:to:date:message-id; bh=ImqiHyAmnUtIQJaySGKuMKxFIt01ZLjMBYezWPiDQUc=; b=X7B8CLTj/pzpOCR4Q1RePtpuKZNqpZNgUaQ1ChhkXealNhXZGQ1w6F7uVqwFXzOg3gnXvj72RgR bSvU6BGwiadZjE8SArgTScfIvlI2UM4UO/AircRwftz+JdtOVkkK9zgSVzO9a5hxv5aYxv708sblv 8ibTgBqzW/KFqKnLK6Z/7qt+hB2bLY2tLQ8eXn6acpTQ7+ojIt8pTkFGXNn3qPkYbm+ev0xXbov5M 5ZOL9jXwhC3IEgTDc7tyPTYstKD4V1qcb7olYgo22z5tzfoNKkp7kgEQLqX6NEQd/si/YyseTQA9/ sWwzklc8Uo6l7yNkGThXSqFw/p2h2b36iThQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Feb 2017 15:44:21 -0800 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Feb 2017 15:42:13 -0800 From: Jim Schaad To: 'Carsten Bormann' , References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> In-Reply-To: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> Date: Fri, 10 Feb 2017 15:44:19 -0800 Message-ID: <0d8801d283f7$9a6fbaa0$cf4f2fe0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK+MlckNWlAVt+/sE5d0arlsmXP8p+J97yQ X-Originating-IP: [192.168.0.98] Archived-At: Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Feb 2017 23:44:30 -0000 Reading this makes me more worried about the fact that the OSCOAP = specification is currently setup to make the implicit endpoint explicit. The fact that this can cause problems when going in the forward = direction, the presence of a NAT (somethings a good thing even for IPv6) = will mess this up when looking at implicit rules. If you start looking = at the reverse rules and still try to be implicit, then trying to get an = explicit, and correct, URL is going to be even harder. I should look to see if the tcp draft has the ability to say - if you = send me a request I will treat it as if it came on port X rather than on = the port I am sending from.=20 This really re-enforces my opinion that OSCOAP should only validate the = explicit rather than the implicit URI-* fields. Jim > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Saturday, February 4, 2017 1:44 AM > To: core@ietf.org WG > Subject: [core] Default values for Uri-Host with alternate transports >=20 > In CoAP, the Uri-Host option is optional in a request. > RFC 7252 section 5.10.1 defines a default value for Uri-Host (and > Uri-Port) based on the connection parameters (destination address and = port > of the UDP packet). The default value allows the client to not send = the Uri- > Host if the value would match, and the server to reconstruct a valid = value for > the host part of the URI being addressed. (I'm not mentioning = Uri-Port again > below, but similar considerations apply for all the cases below.) >=20 > The definition based on the IP address/UDP port of course is not = applicable > to alternate transports. We are running into this right now with CoAP = over > TCP/TLS/Websockets, and will do so again with CoAP over SMS. >=20 > I think we should try to maintain the property as stated in 5.10.1 = that "The > default values for the Uri-Host and Uri-Port Options are sufficient = for > requests to most servers". More importantly, reconstructing the URI = based > on the default value and then making a request to that URI should not = lead > to a different place. >=20 > Note that for a reliable byte stream connection, we have to provide = default > values for both directions, as both endpoints of the connection can = play both > client and server. >=20 > For CoAP over TCP, it is proably OK to slightly adapt the definition = of the > default to the IP address and port of the end of the connection = receiving the > CoAP request. (It is not quite clear that the acceptor of the TCP = connection > could create a new connection by opening a TCP connection to host/port = of > where it accepted the connection from, but at least there is some = address > ownership.) >=20 > For WebSockets, that does not quite work. The WebSocket hostname is > needed to make the connection, so that should also be the default = value of > the Uri-Host for requests in the direction from the WebSocket client = to the > WebSocket server. What about the inverse direction? > (In practice, it is rather unlikely that a WebSockets client also is a = WebSockets > server. Still, it is very useful for the CoAP endpoint at the = WebSocket server > to call back the CoAP endpoint at the Websocket client, even if that = is based > on "You, whoever just called me"". But we don't have anonymous, > ephemeral hosts in URIs. Yet.) >=20 > For TLS, the TCP approach would also work, unless there is SNI -- in = that case > the default in the direction TLS client to TLS server should shift to = the SNI > name. There is no way to indicate reverse SNI, though -- can we be = sure that > is never needed? Would a client certificate change anything here? >=20 > In the last authors' call, we agreed to remove the signalling option = that would > allow to set a different default URI host (used to be called = "Server-Name" > analogously to SNI; a better name is "Default-Uri-Host"), as we = weren't > aware of an implementation. > Do we need to keep it to solve anything of the above? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Feb 10 15:46:49 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A88A1294D4 for ; Fri, 10 Feb 2017 15:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ODAln58g3VX for ; Fri, 10 Feb 2017 15:46:46 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F19112945F for ; Fri, 10 Feb 2017 15:46:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1486770401; h=from:subject:to:date:message-id; bh=T3DA31XwydlF7EQHMMmoUuoo2cZO64wlxefdFf8UFSY=; b=eW1KOIcbTW0ePLuBVE7dtjj5pQA6YOdMRUKpUpfleshdG7sPIVipTpc8S2edEkJ2wcduptnGer4 fce5h/4Jj3PKKm9/GXkewz8bELDvmuRfPqyt+o8KV70ZJoNCkXxfEvtF7scF733lwW83y6j7Unu5i vF9l/ngy+qB00gfDCEV0k545lPI6aVMEXLkUeKZptSL38GD6J1ckw0NSLY00Ou0L2TzgMHqdKqAVH 3LgyeNB1YDYNMVu+rNEDKHLxWSBpn2UPbHG4R6UlQBk/GcJ32MXoKHOdw7R+jzi9lzibKFFCFCa8o vyhffXrCayeKb02+vppPSINzTRqFCOK5SM/g== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Feb 2017 15:46:40 -0800 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Feb 2017 15:44:32 -0800 From: Jim Schaad To: 'Brian Raymor' , 'Carsten Bormann' , References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> In-Reply-To: Date: Fri, 10 Feb 2017 15:46:38 -0800 Message-ID: <0d8901d283f7$edbea220$c93be660$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK+MlckNWlAVt+/sE5d0arlsmXP8gIaxmOwAKXn4lifdYVH4A== X-Originating-IP: [192.168.0.98] Archived-At: Cc: 'Hannes Tschofenig' , 'Klaus Hartke' Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Feb 2017 23:46:48 -0000 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Raymor > Sent: Thursday, February 9, 2017 5:05 PM > To: Carsten Bormann ; core@ietf.org WG > Cc: Hannes Tschofenig ; Klaus Hartke > > Subject: Re: [core] Default values for Uri-Host with alternate transports > > > I've submitted a pull request based on the suggestions from Carsten and > Klaus - https://github.com/core-wg/coap-tcp-tls/pull/113. > > I'm curious if there's another alternative - to simplify and not support the Uri- > * options on reliable transports. I am not sure that the rules would be applied to reliable transports, unless that was totally end-to-end. Starting on transport A and switching to transport B is going to need the Uri-host field to make sure that it gets routed correctly by the proxy. Jim > > If the main scenario as noted in RFC7252 is " Explicit Uri-Host and Uri-Port > Options are typically used when an endpoint hosts multiple virtual servers", > then as Klaus noted in the original TRAC issue - > https://trac.ietf.org/trac/core/ticket/391, this is less relevant for CoAP over > reliable transports (with perhaps the exception of CoAP over TCP): > > In CoAP over WebSockets, the virtual server is specified during the > WebSocket handshake in the Host > header field. The Uri-Host Option is therefore not needed. A client wishing > to talk to multiple virtual > servers running on the same IP address has to open one WebSocket > connection to each virtual server ... > > In CoAP over TLS we have the SNI extension, so I would expect that CoAP > over TLS behaves like CoAP > over WebSockets: no Uri-Host Option in requests, one connection to each > virtual server. > > Carsten called out the same scenario in a related discussion on > https://www.ietf.org/mail-archive/web/6tisch/current/msg02195.html: > > (The Uri-Host option actually is about the destination of the message, to > distinguish several servers that might share an IP address/port number.) > > Thoughts? How are early CoAP over TCP implementations using these > options? > > ...Brian > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Raymor > Sent: Monday, February 6, 2017 5:31 PM > To: Carsten Bormann ; core@ietf.org WG > Subject: Re: [core] Default values for Uri-Host with alternate transports > > > This is tracked in https://github.com/core-wg/coap-tcp-tls/issues/108. I'd > welcome *broader* WG discussion for this issue. It's the remaining issue > that's blocking coap-tcp-tls-06. > > On Saturday, February 4, 2017 1:44 AM, Carsten Bormann wrote: > > > For WebSockets, that does not quite work. The WebSocket hostname is > needed to make the connection, so that should also be the default value of > the Uri-Host for requests in the direction from the WebSocket client to the > WebSocket server. > > There's already text in the WD for this case: > > The WebSocket client includes the hostname of the WebSocket server > in the Host header field of its handshake as per {{RFC6455}}. The Host > header field also indicates the default value of the Uri-Host Option in > requests from the WebSocket client to the WebSocket server. > > > In the last authors' call, we agreed to remove the signalling option that > would allow to set a different default URI host (used to be called "Server- > Name" analogously to SNI; a better name is "Default-Uri-Host"), as we > weren't aware of an implementation. > > Do we need to keep it to solve anything of the above? > > I don't see the need if appropriate defaults are adequately specified. Most of > the related language in the Default-Uri-Host was to describe the "base > values" for Uri-Host based on the transport - the values which are used if > Default-Uri-Host (aka Server-Name) is never sent. > > > _______________________________________________ > 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 From nobody Sat Feb 11 01:23:00 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757B312970F for ; Sat, 11 Feb 2017 01:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 610UovNK2WnL for ; Sat, 11 Feb 2017 01:22:57 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A15129712 for ; Sat, 11 Feb 2017 01:22:56 -0800 (PST) Received: from [192.168.91.173] ([88.128.80.215]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LfHs4-1c5N3d48qW-00oqlc for ; Sat, 11 Feb 2017 10:22:54 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <988d2c4e-dd18-c2dc-e1d6-d271ce9c5f9d@gmx.net> Date: Sat, 11 Feb 2017 10:22:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tROA61VTdQipfcVQlQWNARsmK3GQ4ocaD" X-Provags-ID: V03:K0:tL7PE4J5Gle9HndrkKSw1bckDl/3mfZJxJdZthQ7YdkpAoUJslL 2Qr6nJe8eDJ/oLvRPgVOtH1ERpLMnxkmwG1yIShiDg2OwhMVQjD/4OYLOBR98iMB+RUheAm HweADNoiUG5KJbta/44mHx5DLpOBk8g/aHdOLLeUSdyO2Mf806v3zhorTSwYKHwTIA+2x0z 6TIjiGXb7wCpQ7itMafVw== X-UI-Out-Filterresults: notjunk:1;V01:K0:cEcP2ufxko8=:hH6CeqF99Lfga8lyDdTYHt h4A8P0y7XON4WmIYSke41MRsMcqFEDupD2poiTUakJMDpo0XiawgdivPOsHBd73alSS8qYyAi kqFCUtcpa0CYhBJ6F9lsTEccZIBNyvE2BY8e9wjTCJq92+jRr8gSTiKthco/YTKD3G3t5BBgT ECJcV2eQPhXOkvkDvyJ/MUOnLtgZ+7Orfpxgp4pG21JAg4oj2BV2sz6NUGx9jlTKO8NfqyuV8 I3LHPZctvyWGRy0rHxYim8h5GyJ+vTdSIWio3V5EtKfvGcTOlLJFMAananHFKucSzfLh9aiH3 w2GQGvuUrvcngNbRZe7wqC23hY+5z89qTRTgSS//+R5+bmYdSfaKEJ6kD8052ZaQMdwZOaJ9P 3RaWpejZWTEsuJOzld+Ow7Mj59jsD+1H+Fq+NkLrHSAhn1wiFVpkgC6cSztiBAgW//CnFENwy 3lU0Zx67cIzkSOs3q/2pluqQozBlosxRUgjMHi1fQA9UIyzXOqZIlIxx3TPrOWFvmXRgZP7qf zuX4d0/hAUCVTqzFBUae8YYgCsiNnBjO4YBznJk7JZEqMXqqVhivl+P/8/zbfDwq7fNfts+3Z GRcc4+nhWkA8pgZHNIu3faG/R1KfuStfjudy/OSMn5oVk1MGPfTJyhNiYVcIul85gX1Zp/qRL Vk3BYKnbugxsxm5hIKaLPyQ248d1Ilyhx32TMjPznmsJEJBhCS9Oa+CkMfo++OPCtRHGUW6qA sDKKx51kXRemfLIVP1vGT88OkxE2Qx9YkoF1doNNBfyb8W4oqLnt6tPf+d3KPNPnPutMYlP98 ECHjlQw Archived-At: Subject: [core] Webinar about LwM2M X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 11 Feb 2017 09:22:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tROA61VTdQipfcVQlQWNARsmK3GQ4ocaD Content-Type: multipart/mixed; boundary="JcHUVETMMec7AMouqJVselbqNc3gOahr7"; protected-headers="v1" From: Hannes Tschofenig To: "core@ietf.org WG" Message-ID: <988d2c4e-dd18-c2dc-e1d6-d271ce9c5f9d@gmx.net> Subject: Webinar about LwM2M --JcHUVETMMec7AMouqJVselbqNc3gOahr7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I thought you might find it interesting to hear that I am going to speak about LwM2M in a Webinar next Monday. LwM2M re-uses work done in this group. While you may have heard me (together with Simon Lemay) talk about it before (in context of the lecture series in the ACE working group) but in the meanwhile LwM2M has advanced and version 1.0 of the spec will be published any day now. Here is the link: https://developer.mbed.org/blog/entry/Webinar-Utilizing-the-OMA-LWM2M-pro= tocol/ Ciao Hannes --JcHUVETMMec7AMouqJVselbqNc3gOahr7-- --tROA61VTdQipfcVQlQWNARsmK3GQ4ocaD 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYntfqAAoJEGhJURNOOiAtWcEH/j5AHTt7P8BnNPnvAzFJhwSt DU6kemOyso3e+B0/NH4xlZEVnX+tZUiD48495dAQePLyYjKnT8pwfe/udEwLytNR epU2/qqqiNW3vIQv+QL0Fkc40dubz2wAyMEwxuZ2DcX2LUCSY8MCS8w2oLfOeVeX cM2SV/ql3pSTEBhvKMngpmlPf/6FmGCdsb4Tz98xqmMKT7mcKB2k/mc5AmLSuJFk 975tuxjdbRjhdP9JLf3fUklY0yCoE/m0bk4Bab4EHwkLEw9XeUoAEz0AvHfbZGYZ Pfnk98uXfTbYxk+ww28TvPpHLmtLWsTukB79pH6VbsRYRq4gmKNkaMol8ibZieQ= =M3SG -----END PGP SIGNATURE----- --tROA61VTdQipfcVQlQWNARsmK3GQ4ocaD-- From nobody Mon Feb 13 07:05:09 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5C1296A1 for ; Mon, 13 Feb 2017 07:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koVJgioydzHw for ; Mon, 13 Feb 2017 07:05:00 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00127.outbound.protection.outlook.com [40.107.0.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37914129682 for ; Mon, 13 Feb 2017 07:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j4VfGNBJIGeIf6UNH8sCeJhvhbohK+64vWsGo+NbMO4=; b=F6FDdBGeOWzEAfrLsnU6cQBuNjVYZ1PmS+2mivTNsowhpv5DiCw9ABBSLGiK1wWgLdx57hQHBINdYr9mT8aA43QO56Ryo1w5jpuJ5OsqHuVWOT65QR4Xz91P0ZXzGVDhoj1VpcfrIo7BiYDxIxco2eFIK+11Wc7fN9aQOeIDtCM= Received: from AM4P122CA0004.EURP122.PROD.OUTLOOK.COM (129.75.167.82) by AM5P122MB0034.EURP122.PROD.OUTLOOK.COM (129.75.138.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 15:04:58 +0000 Received: from DB3FFO11FD013.protection.gbl (2a01:111:f400:7e04::166) by AM4P122CA0004.outlook.office365.com (2603:10a6:220:1a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16 via Frontend Transport; Mon, 13 Feb 2017 15:04:57 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.228.36) smtp.mailfrom=philips.com; vodafone.com; dkim=none (message not signed) header.d=none;vodafone.com; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.228.36 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.228.36) by DB3FFO11FD013.mail.protection.outlook.com (10.47.216.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.904.16 via Frontend Transport; Mon, 13 Feb 2017 15:04:57 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) by AM3PR90MB0100.MGDPHG.emi.philips.com (141.251.117.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 15:04:57 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) by AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) with mapi id 15.01.0888.030; Mon, 13 Feb 2017 15:04:56 +0000 From: "Dijk, Esko" To: "Smith, Kevin, (R&D) Vodafone Group" , "core (core@ietf.org)" Thread-Topic: [core] CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AdJ71Z2t7xvTLii1QoWlumXEa75yfQAEP+wAABxuBgAAAN+rgAACdXTQAWuqCdAAAPEFgAD8c7zA Date: Mon, 13 Feb 2017 15:04:56 +0000 Message-ID: <63753ac47f8c4e61b5377b50e57e0795@AM3PR90MB0097.MGDPHG.emi.philips.com> References: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> <85d6ff1c1d5047e3b3e516660652d8df@AM3PR90MB0097.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.122] X-MS-Office365-Filtering-Correlation-Id: 95f5ec2d-1e1d-49be-9b1b-08d45421acfa Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: AM3PR90MB0100.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.228.36; IPV:CAL; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(2980300002)(374574003)(55904004)(85714005)(199003)(189002)(13464003)(108616004)(229853002)(50466002)(189998001)(86362001)(2900100001)(76176999)(54356999)(24736003)(7696004)(23676002)(2950100002)(305945005)(7736002)(2906002)(5660300001)(38730400002)(356003)(626004)(66066001)(92566002)(6116002)(6246003)(8676002)(97736004)(81156014)(8936002)(47776003)(50986999)(26826002)(53546003)(81166006)(102836003)(3846002)(53936002)(68736007)(106466001)(105586002)(69596002)(8656002)(33646002)(55016002)(6306002)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P122MB0034; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD013; 1:PG+Ja57lWMqH4T5pXY6x9s13JcVTDLf2f/8WKlr5ji50sCWKMFb4wmCHu2DiB4zJ64MYrixuUtzZ3VW5fCJQAaqKQ2f3tNbKe/ijVfkhpwxBWtOOkhL0TBSnsp1w4yGjhoOAoL9kscPFluvYbp/WNRczNRcXYCL4+MypBsb3X3pm0XTkw3zwmGkaJ+5EV/mifFYJrXW8Lhus8pkQG9ZwhosNRFxOFjKlIRZz53THk1UTu+s4QF5tjc3RKgU7FzPmwvRGr18/VQF9mR5ozN7jqJrEkYnQRawaxEwbkr2CG4/Uf1rPPQK4GOx81wU7iQiK3vV4ZJFX5hOGVVO84l+qzcCxqF2xt+ZuSeCrtV+qpgG/Ze3lmw8RtnBg9SS419WnDy8iVOuPjSIs7wkw7BANZeAoT9FJPceuP8HNhF3h7DeKJbXmjjOj7W3NhgQxzbqgf3JPSnOUyYblXqj+oSfi2mpUJAM4rlPR3kwgp2xLUbRdN6PtxvcoCTHIb/C05opg X-CrossPremisesHeadersPromoted: DB3FFO11FD013.protection.gbl X-CrossPremisesHeadersFiltered: DB3FFO11FD013.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM5P122MB0034; X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 3:BWYNiTvkas1y+a2w7Kq4HiJ097Ok97Dy8uQq3oaQycb8aE3Q9plv+qyPJtVPMEMBqIAzY+kWgqmoUufbofuuL7ez6Qjho9et8PX0QoSQ3+rWRNrcv1QdnSGUco4Rjvmx7F0I7/ZJYj4tQNggekrvxRxP3Dtwl9AlwDOvMVA+kHKYEn/PdKbEwd+TYwPSH5I4PZfYco+nSOwK2uMOLgibuyB5mPESNrRCozT59Gcm1QpebtuovhjeUWybq/rG1emHDQsGe6A+Qiy1A7PPi9Q6FVZUKXCvKy8cqqBRZav8gUzENcFYG5G9N7z4mCS3GsBQifpofZEPGhmPIrLFq0Z/aArgrVYQ1pYHJwhDklaCWDw=; 25:okxAA57iuIQ5qUR7yyyJrkuB8cW0FBRa4A1t3HtyohACrEEsVHDn8Z5AcwZJQlgd2Dqbw3lhUagxobEiQqBzAcXuJqZJBxqn4VHXu7JEUkKA5dne4Nb3fiRQP7GWFpPr01JpMHjk5LNThsYSF8H4ZtBKUnUp1DEEBdAce388fDBHfDIp92OFC2vK8a7oyDyRGIIPLaGuNDF/tuXS/cygPLBxN+cCuwJBZ+TrbgrP/iozyCvVwMrMQWB5+vK26Ao4S6ED70lw4zTwxQ3xqOsg2J1ETqhYGNxRQGUKCoBOPGkIIPP0gQ7PVPNAhP51Hf0lYKCWt9VcC5S+167g8syRlBswd7p/vvlnYT/5jI991hgjID2E5lH2o2NTbYTpe83bZ8pHjf5kxyUgHk0jHm955kdC5WIufv9GlhDYHIDvfOo2fXJJCNLogK/uS1vZacSQfgCQk4aiwJXJUYYQEPTG+g== X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 31:48QrIa3tPMNzuZuLp81nO1bPHC+BdyWB08dYa4GfmD00HWonIuJxuGpAmr58UobAr6amgm3qfN4jmQd4XmyCApG2pU7nPHA8/61GadFTHOScGLWXrnnKKalJj+7QqPuCucZ7ZSOWXZ8K45Z9WJT3v0FHAnoDRoArSrW/9KNHF9Eu3QnEvy6DX5US2sCEYLvzLp+PDnr6gpdSIrnV+nN3l1wA1fLk+ahddcXOVBTlvW3y2ghIGF4OAaVWOD15reqDd7FBt5OJJ3LGgpcAm5HtNg==; 20:0gRYOkzKfmnMoqSl7UQ0iLdcbduDmZO9jbj9sTOnSk3auWa1igSK9BcRyeALZDYSVZao5srS35oNKiQzp3wRtP513nwCC4Y3ile8NzEkdDpcUvTwKwt9+0QBAx0ZIiPy4A+fofQJJ/V060LRm93Fs8VWzYuSowNHOn93Sih9/2E31Q21EU0SmADB5tXg1bv9bnifjvLBh8sFDQErKyRKDPx8ATCZrrE1kRE8/2uJD16CS3/nJonoBhfvMQDZsmAU/ZoodCWSj/ZuAHWwxPTjxRCLpRYTGoguBpG4dfEVWKbFUO4s3pJA/JQptu3KiS4RmEUplj5qeXngHXjzoFOS3XX62NATj410j+rqWwDyxUdO/LKYFDIvskdldFK1nzhL3FTir1uIY/6lncSeG/71gxDkfLruh+BUG9yD8351ext8lPqXlBfCsaZA4ArFv968pbq4Yzs2uWeNhcOpYryupQ2vb8sJf2axBws8FR9LGqe2gHBk2Gqj0R+BWwVN84iW X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(180628864354917)(260087099026482); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(13021025)(13023025)(5005006)(8121501046)(13013025)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:AM5P122MB0034; BCL:0; PCL:0; RULEID:; SRVR:AM5P122MB0034; X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 4:xk7J9zFA3dvJ+weGKVbeAf6Kyc3q+7qahJAdJZQUQqlC7myiJ80olXk+T0ED7XIaYwE2NB4u5R3Z9lOR4QjlLKWE5fExQycLAWisc0A1/KkXsvuOpeLHF7e3GaX0fq0XyYzozQb6caw1OzNcjqaWpH+6MXt8yy7txm0H+EJufhXZIbmIs8iYjwcB93QIgcCj6LDTg/oSioDubyjwKtlKSx/FVWG/EBOqgSpGu3MtAEPDRjD/E4wTl/GYtn00DMS1ILSEeJbqANF7BZa7HCdEDMWDnQsMxjT0jyHi+E4NPhekKIqcV3WNRwL5B6QkBl53CTXecCyrdfOg61EpmPbe2BgGF3VRUXkKLRrGJXRTC5FG0lUoKmvfr5/BQXntrlyh0BHDvPLi/rRIPSKWg2JWLkJAH+v+iJyiH8LuQMSohZIk9FA43P/5Rf3yGeSEg6h0qRPC3ZQB/8EHAeBrnOdnMiU6RP5O5cswr8pvmxM1vY5T6zG3ttltvzq8124oxRCuYG7yZ7EKGBiOPQA0Zkmw6bDWL7HzYstMDLujZUuX0FbqB69Lj1x1CsPNExx/i0SYNEl99e+GKFSaTa3hdg4x70dzWQRqCYsC63KzoMAxVqpaP0Ks6lO4D5O+fSA63oNlhDU9vm987QSbYMrYzxq51zfDi3KpZaceTJMOANiN72a4mT8QoYDCiP+rSG3915rKkBjyErHBweZORPh9DCI9dBL3+NypUMkP0MLDUadsHA5YtPzeXl3Dowclq1wP13NPNaGbcHknpRAfU45sAG+YsQ== X-Forefront-PRVS: 02176E2458 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQMTIyTUIwMDM0OzIzOm1sMHhBb1RZamVMcTRYcGVVeCtuT2MvM2x6?= =?utf-8?B?VFFzb2c4QnVkL0VVd294cS83SkZZKy9VdVR0MGJwNStmV1BXd1c1NSsvNWd4?= =?utf-8?B?aWxCZEtmeEJnTDFhMzUzZFlnMmRBL3VjbHZSMGVIWkcvRGpKZldlM0VjcjNs?= =?utf-8?B?cUdBTVRENzIyQzUvS3JLRGx0K1Z5aUZIdWl2NENEb0JIaTVrUlNudnZTQ290?= =?utf-8?B?b1pNbytWQ0hTQU1EWG83YUdkZlRtTHQzb0xnQ3J4Ykp5bXl4YmRmaURac1Jv?= =?utf-8?B?WmJsaXhnUk5xVjhpeStITkhvOU5HcWFyeGI0WEZXMzhySjVWaTlrekZUUEhY?= =?utf-8?B?ZUlEWVJ1a1o4M0xSVysrVGFYWGorSFJaU2tWVzlRbWx2anpnWURIVlhlZCtE?= =?utf-8?B?ekZEWDJCU3JZWkxWdzBwL0UybXhyT2dxQ2NYM1hicStqQjRhYXJLWlJ6VTBh?= =?utf-8?B?RHhZdVA1c1RIenFkZDN6SmI1YUdpRE1MR3dTNnc0OTFhemwvWFR5Rm1MbThp?= =?utf-8?B?T3VtQ2lTSGU4WTkwZ1VjN3lTM3FucjV3TGQxMGkvUHNuREZlSlpCR0Ixblp0?= =?utf-8?B?TWJ2U0lHdndGYTFSTEUxZllDSW1hRjZoLzdFYjlBWWErNEtUb3FRSzR2T0FO?= =?utf-8?B?Qm81RlE4NXJMelRyQUdGVk5iWitleUdzNWdDblJTNS9OWHVWS3daM3VnbDQy?= =?utf-8?B?MlFqSmttWWJDTVl6M2IyS09NZWlNRDNORXZyMnA1ZzN0RGp3cHJsLzFmZVlV?= =?utf-8?B?SWlhelBLUkl6RGx0akVwRnh4RjRtdTlOWkVTNEcxamdzRk96Z0ZWK3BTZWdR?= =?utf-8?B?MHdnbHNmblRESzVya1B5WTh3Wkg3QS9ZTURkMmdKOGVYQXRUK0tjVEhDcVVH?= =?utf-8?B?eGpzZEdWLzhobFJNTjZUWXNCTTFXeVBaelJxVzdpRlpCRmpscWIvVG9CbGlm?= =?utf-8?B?aVdTZHphN3FOKzFpcDZvdkYyQ1BKY3VXV0dvN1dUcWpkbnFiUytVVW1OSjht?= =?utf-8?B?WkdGc01ldmFnUlBZaUExOVlXQXVGMFF2TCt6V1RYYW9sV01tSzRLd3VyQ0pI?= =?utf-8?B?VzQ0ODRJK1ZWbjg3RTljNGtSVkVmbE1yMXJJWU5DNUZJc25RVGk5aXF6N0NV?= =?utf-8?B?d0tnSy9xN1EzVzdRdG5ZVFFSbk9POUtyNWVrMHZjb0R5aDdxRFlJTko4V1dq?= =?utf-8?B?aTcvb1MyakUzcFVZcytVUE1UcTdPZ0k4ZmdMdG9DNndQUllOZUY4aUFZUWQ0?= =?utf-8?B?TGZvVzVwMWdYc012M091M0lzSFhHZk5NUTNsUUZmVGgydlFVVmEzdCttSWor?= =?utf-8?B?OG8wVENrblh1WWIvNFc1V3A0ZE1Ybm8rQkZqU0gwK1o4RHBwK05pdlBMclBa?= =?utf-8?B?RmJ5aDQ3dlRTajFacUR2cmFIYmc5NWVSMVdXNEpBdnZ1ZFcwcTJBRnlSV2xC?= =?utf-8?B?Unh5V21WaCtPNm5xR0NqekRQVnpINGI0UlNDcHlrZDJGNkc0UXIreXpNMUxN?= =?utf-8?B?SGNKQ2NxUXpTanUrNERvN215Q0pNeVVuSTdyTEVKV0tvdW5uSVJObDBVWTB4?= =?utf-8?B?QVN3VXM2dGY1azUrZ1IrdkJldnFoTUNaNnlySURpVmZpN2o3aEZBU3BuMlpX?= =?utf-8?B?aFhmNjgzNHlVN1BOU3VVWitYUUNHanJNN2F5YlRLSDFiTFBJZUZEL1NIUjM3?= =?utf-8?B?M2Q4MTdKV1NZNEFnWGd1U0RTazRObUp1Q0dJdEhYY1VLTEVWeHBCOGhwSkxF?= =?utf-8?B?eVN1dXNiRzQvOG9TZ1J1ZHZSditDOHBCR1pOeTFMd0NTTDdNSlhjeitLV3J4?= =?utf-8?B?Y1BxeXlsRWQ3c3QrTXN2b1JzRDF0M2FJUVlGZWNNdzlvOEVnUGx5YjZmc1E1?= =?utf-8?Q?wqA8jdlwszw=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 6:yeAnUbVj+kb+T+cwyhATuLTBXAZN2AFN6vkeDFUDvE3I0qirvZKAws6Bt4RHrN3tQaE2osDxYo4+KbE0KpbcwQJx+qoKiIlAKH3ir23tuwzKcjliNubgO/xQKVm4ELUZXwXsuynNh1prZ972IJ9Jk2JAKv1uwD23oDpMGT1WmBQM1ts9VbIjP8QFUlz/QaRZFmPczJidtupaCecfFJGwuXHxWQ11uaYgzWTnS22CJQsQJ8xcrxFf2CuHrV/ynL+60QeCs396872gPoDtNATXBYJOQs0hr3jl9MjmdxoZ0fTddaRsqxuwMBdLIAecuO+VHqqfBBOO1W1sMDrKe/ndBnkRJr+8LYM5Ud15dtbr960PvgrC+jOk96xtbUguGZJjEqvvBclptzQmfG5biQEng2+n90HprAqTxzOlRvLy71o=; 5:YzKZtOiOjwkQO478v3DbujUU9x+J4umrzoaGg0fhevMguJ4It4JccOZFwrKMa12EUfWQ/18W1T86QxGJQ/iM7wLNbRycGatjS2l9W21OtGe6mulBf59GEWiZxMUr1K7joqB6wke+06xjY6Ur9Ntxrw==; 24:hsHAdESbFpINfDuoGRf9CrSpr3WrGanwhZ6O/Co6EXkf0XnOy+tdQN0jaHVYTsH9430v1BK8entWHHPMwrzqW4A3QGlfrGLAwRTRuZQTN1s= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 7:TYbqF6EQDhAhwVI1M+kIUwpL6bAg+b0jac8MmOfX+Xj3/6VIeoHl7GEM09AhWGR0KWSjU67CpWd9T6elSVjt9nJO4vkIXsD13Cb38Dr9du6TW8K4JHpH2ZId70zeZxGdzCeLhUGxYHFQCiMDG0FqOzX2LdV7zwQjvZzRgavtIK3YuMOEFL64Ule+FFhztB3zH9C+Zp/0Nx7yu1fyVh9/GGVBQC7EkBFoBCIbFsoP54QmgZg9c38xhdunFvinu5upxjlotDjrd71kE5HfXojFtFEh1vjYBaHIDI9jSdOGIyL0K8coYTlU/shgJozY2OaXLE2I3E296IuX1HC7lfHFsHL9Z3lAsvaZAwCf4cI3NRtLV5SYXSFKj1BxKKIa8ykx6IBHpFk91QUHfyFmGEG2yCIjnTNwIuSRx+Yt5T16EK2qReCMa+cSzJR6k3ckqDuI5kTIIET65X3gFuDlwYLQKBqq8snh4tQE/8Pn43tD4tyiNqBDAZHAphfIgh7twdxM72XSjVUWye5MIGeXPqmdmA== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2017 15:04:57.7905 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.228.36]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P122MB0034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM3PR90MB0097.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 194.171.252.122 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: AM5P122MB0034.EURP122.PROD.OUTLOOK.COM Archived-At: Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Feb 2017 15:05:08 -0000 SGVsbG8gS2V2aW4sDQoNCnRoZSByZXNwb25zZSBjb2RlIDUuMDMgaW1wbGllcyB0aGF0IGEgY2xp ZW50IGNvdWxkIHJldHJ5IHRoZSBleGFjdCBzYW1lIENvQVAgcmVxdWVzdCBhZnRlciBzb21lIHRp bWUuIFRoYXQgc2VlbXMgb2sgaWYgdGhlIG5ldHdvcmsgaXMgdGVtcG9yYXJpbHkgY29uZ2VzdGVk LCBvciBvdGhlciByZXNvdXJjZS1yZWxhdGVkIGlzc3VlcyBvY2N1ci4gSG93ZXZlciBpZiB0aGUg Y2xpZW50IHJlcXVlc3RzICh1c2luZyBxdWVyeSBwYXJhbWV0ZXJzKSBhIHJlcHJlc2VudGF0aW9u IHRoYXQgaXMgZnVuZGFtZW50YWxseSB0b28gbGFyZ2UsIGUuZy4gcGVyaGFwcyBpdCBkb2VzIG5v dCBmaXQgaW4gYSBzaW5nbGUgVURQIGRhdGFncmFtLCB0aGVuIHJldHJ5aW5nIGlzIHVud2FudGVk LiBTbyBmb3IgdGhhdCBjYXNlIGFjdHVhbGx5IDQuMDMgbG9va3MgZml0dGluZzsgSSBqdXN0IHNh dyB0aGUgc2VudGVuY2UgaW4gUkZDIDcyMzEgdGhlcmUgc3RhdGluZyAiSG93ZXZlciwgYSByZXF1 ZXN0IG1pZ2h0IGJlIGZvcmJpZGRlbiBmb3IgcmVhc29ucyB1bnJlbGF0ZWQgdG8gdGhlIGNyZWRl bnRpYWxzIi4gU28gdGhlIHJlYXNvbiBjb3VsZCBhbHNvIGJlIHRoYXQgIml0IGlzIGZvcmJpZGRl biB0byBhc2sgc28gbXVjaCB1c2luZyBxdWVyeSBwYXJhbWV0ZXJzLiINCg0KcmVnYXJkcw0KRXNr bw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNtaXRoLCBLZXZpbiwgKFImRCkgVm9kYWZv bmUgR3JvdXANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcgMTU6MzINClRvOiBj b3JlIChjb3JlQGlldGYub3JnKSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0g Q29BUCByZXNwb25zZSBjb2RlIGluIGNhc2Ugb2YgInJlc3BvbnNlIHBheWxvYWQgdG9vIGxhcmdl IiA/IDQuMTM/DQoNCkhpIEVza28sDQoNCk5vdCBzdXJlIGlmIHlvdSBzYXcgbXkgZWFybGllciBy ZXBseSAoY29waWVkIGJlbG93IGZvciBjb252ZW5pZW5jZSksIGJ1dCBpdCBwcm9wb3NlZCA1MDMg YmVjYXVzZSB0aGF0IGV4cGxpY2l0bHkgaGludHMgdGhlIG5leHQgc3RlcCB0byB0aGUgY2xpZW50 IC0gd2hpY2ggaXMgY2VydGFpbmx5IGluIHRoZSBIQVRFT0FTIHNwaXJpdC4gSXQgYWxzbyBzZWVt cyB0aGF0IGluc3VmZmljaWVudCBzdG9yYWdlIG1heSBub3QgYmUgdGhlIG9ubHkgcmVhc29uIGZv ciB0aGUgc2VydmVyIG5vdCB3aXNoaW5nIHRvIHJldHVybiBhIGxhcmdlIHJlc3BvbnNlLCBpdCBt YXkgYWxzbyBiZSBiZWNhdXNlIG9mIGJhbmR3aWR0aCBjb25zdHJhaW50cywgbmV0d29yayBjb25n ZXN0aW9uIGV0Yy4gU28gZm9yIHRoYXQgcmVhc29uIEkgd291bGQgcHJvcG9zZSA1MDMsIHdpdGgg UmV0cnkgSGVhZGVyIGFuZCBvcHRpb25hbCBleHBsYW5hdG9yeSBib2R5LCBvdmVyIDUwNy4NCg0K QWxsIGJlc3QsDQpLZXZpbg0KDQotLS0tLQ0KDQpJbiBnZW5lcmFsIGl0IG1ha2VzIHNlbnNlIHRv IGxldCB0aGUgY2xpZW50IGtub3cgd2hldGhlciBpdCBjYW4vc2hvdWxkIHJlcGVhdCB0aGUgcmVx dWVzdC4gSW4gdGhpcyBjYXNlIHdlIGNhbiBhc3N1bWUgdGhhdCAncmVzcG9uc2UgdG9vIGxhcmdl JyBpcyBhIHRlbXBvcmFyeSBjb25kaXRpb24gKGlmIG5vdCB0aGVuIHRoZXJlIGlzIGEgYmlnZ2Vy IHByb2JsZW0gOikpDQoNClRoZSBjbGllbnQgc2hvdWxkIHRoZXJlZm9yZSBiZSBpbmZvcm1lZCB0 aGF0ICgxKSB0aGUgY29uZGl0aW9uIGlzIHBlcmNlaXZlZCB0byBiZSB0ZW1wb3JhcnkgYW5kICgy KSBhIHJlY29tbWVuZGVkIGRlbGF5IGJlZm9yZSB0aGUgY2xpZW50IHJlcGVhdHMgdGhlIHJlcXVl c3QuIFRoaXMgSU1PIHB1dHMgdGhlIGVycm9yIGluIHRoZSA1eHggcmFuZ2UsIGFzIHRoZSBjbGll bnQgaGFzIG5vdCBkb25lIGFueXRoaW5nIHdyb25nIGFzIHN1Y2gsIGFuZCB0aGUgc2FtZSByZXF1 ZXN0IGJlaW5nIG1hZGUgbiBzZWNvbmRzIGxhdGVyIGNvdWxkIHJldHVybiBhIHN1Y2Nlc3MgY29k ZSBhbmQgYSBtYW5hZ2VhYmxlIHJlc3BvbnNlLg0KDQpTbyBteSBwcmVmZXJlbmNlIHdvdWxkIHNp bXBseSBiZSA1MDMgU2VydmljZSBVbmF2YWlsYWJsZSBbMV0sIHdpdGggYSBSZXRyeS1BZnRlciBo ZWFkZXIgWzJdOg0KDQoiVGhlIHNlcnZlciBpcyBjdXJyZW50bHkgdW5hYmxlIHRvIGhhbmRsZSB0 aGUgcmVxdWVzdCBkdWUgdG8gYSB0ZW1wb3Jhcnkgb3ZlcmxvYWQgb3Igc2NoZWR1bGVkIG1haW50 ZW5hbmNlLCB3aGljaCB3aWxsIGxpa2VseSBiZSBhbGxldmlhdGVkIGFmdGVyIHNvbWUgZGVsYXku IFRoZSBzZXJ2ZXIgTUFZIHNlbmQgYSBSZXRyeS1BZnRlciBoZWFkZXIgZmllbGQxIHRvIHN1Z2dl c3QgYW4gYXBwcm9wcmlhdGUgYW1vdW50IG9mIHRpbWUgZm9yIHRoZSBjbGllbnQgdG8gd2FpdCBi ZWZvcmUgcmV0cnlpbmcgdGhlIHJlcXVlc3QuIg0KDQpTaW5jZSA1eHggYWxzbyByZWNvbW1lbmRz ICJ0aGUgc2VydmVyIFNIT1VMRCBzZW5kIGEgcmVwcmVzZW50YXRpb24gY29udGFpbmluZyBhbiBl eHBsYW5hdGlvbiBvZiB0aGUgZXJyb3Igc2l0dWF0aW9uLCBhbmQgd2hldGhlciBpdCBpcyBhIHRl bXBvcmFyeSBvciBwZXJtYW5lbnQgY29uZGl0aW9uIiBbM10sIHRoZW4gdGhlIGNsaWVudCBjYW4g YmUgaW5mb3JtZWQgdmlhIHRoZSByZXByZXNlbnRhdGlvbiB0aGF0ICdyZXNwb25zZSB0b28gbGFy Z2UnIHdhcyB0aGUgdGVtcG9yYXJ5IGNhdXNlLg0KDQpBbGwgYmVzdCwNCktldmluDQpWb2RhZm9u ZSANCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjMxI3NlY3Rpb24tNi42 LjQgDQpbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi03LjEu Mw0KWzNdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjMxI3NlY3Rpb24tNi42DQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERpamssIEVza28NClNlbnQ6IDA4IEZlYnJ1 YXJ5IDIwMTcgMTQ6MTANClRvOiBjb3JlIChjb3JlQGlldGYub3JnKSA8Y29yZUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbY29yZV0gQ29BUCByZXNwb25zZSBjb2RlIGluIGNhc2Ugb2YgInJlc3Bv bnNlIHBheWxvYWQgdG9vIGxhcmdlIiA/IDQuMTM/DQoNCk9yIGZvciB0aGUgc2hvcnRlciB0ZXJt OiB0aGUgSFRUUCBjb2RlIDUwNyBJbnN1ZmZpY2llbnQgU3RvcmFnZSAoZnJvbSBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNDkxOCNzZWN0aW9uLTExLjUpIGlzIHZlcnkgc3VpdGFibGUg Zm9yIHRoZSB1c2UgY2FzZSBvZiAnY2xpZW50IHJlcXVlc3RpbmcgdG9vIG11Y2ggZGF0YSB2aWEg VVJJIHF1ZXJ5IHBhcmFtZXRlcnMnLg0KQ291bGQgd2UgcmVxdWVzdCByZWdpc3RyYXRpb24gb2Yg NS4wNyBpbiB0aGUgQ29BUCBSZXNwb25zZSBDb2RlcyByZWdpc3RyeSB3aXRoIGRpcmVjdCByZWZl cmVuY2UgdG8gUkZDIDQ5MTggLyBjb2RlIDUwNyA/ICAoZm9sbG93aW5nIHRoZSBJRVNHIGFwcHJv dmFsIHJvdXRlKQ0KDQpiZXN0IHJlZ2FyZHMNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IERpamssIEVza28NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDEsIDIw MTcgOTo1MA0KVG86ICdDYXJzdGVuIEJvcm1hbm4nIDxjYWJvQHR6aS5vcmc+OyBMYXVyaSBQaWlr aXZpIDxMYXVyaS5QaWlraXZpQGFybS5jb20+DQpDYzogY29yZSAoY29yZUBpZXRmLm9yZykgPGNv cmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW2NvcmVdIENvQVAgcmVzcG9uc2UgY29kZSBpbiBj YXNlIG9mICJyZXNwb25zZSBwYXlsb2FkIHRvbyBsYXJnZSIgPyA0LjEzPw0KDQpUaGFua3MgQ2Fy c3RlbiwgUGFkZHksIExhdXJpLA0KDQpmb3IgdGhlIGNhc2UgSSByZWZlcnJlZCB0byBpbmRlZWQg dGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIG1hY2hpbmUtcmVhZGFibGUgc28gdGhhdCB0aGUgY2xp ZW50IGNhbiBsaW1pdCBpdHMgcXVlcnkgc2NvcGUuIEZvciBvdXIgY29uc3RyYWluZWQgZGV2aWNl IGNvbnRleHQgSSB3b3VsZCBhdCBmaXJzdCBleHBlY3QgYSBmZXcgYWRkaXRpb25hbCByZXNwb25z ZSBjb2RlcyBkZWZpbmVkLCBhIHBlcmhhcHMgbW9yZSBpbnRvIHRoZSBmdXR1cmUgYSBjb21wbGV0 ZSAicHJvYmxlbSBkZXRhaWwiIHBheWxvYWQuDQoNCkZvciB0aGUgdGltZSBiZWluZyBpdCBjYW4g YmUgb25lIG9mIDUuMDAsIDUuMDEgb3IgNC4wMy4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXQ0K U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwMSwgMjAxNyA4OjIyDQpUbzogTGF1cmkgUGlpa2l2 aSA8TGF1cmkuUGlpa2l2aUBhcm0uY29tPg0KQ2M6IERpamssIEVza28gPGVza28uZGlqa0BwaGls aXBzLmNvbT47IGNvcmUgKGNvcmVAaWV0Zi5vcmcpIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtjb3JlXSBDb0FQIHJlc3BvbnNlIGNvZGUgaW4gY2FzZSBvZiAicmVzcG9uc2UgcGF5bG9h ZCB0b28gbGFyZ2UiID8gNC4xMz8NCg0KSGkgTGF1cmksDQoNCmluZGVlZCwgdGhlIENvUkUgd29y bGQgaXMgZGlmZmVyZW50IGZyb20gdGhlIEhUVFAgd29ybGQuDQoNCj4gSSBwcm9wb3NlIGEgYml0 IG9mIGluZm8gZ2F0aGVyaW5nLCBJICBpbWFnaW5lIHRoZXJlIGFyZSBtb3JlIHNpbWlsYXIga2lu ZHMgb2Ygc2l0dWF0aW9ucyB3aGVyZSBIVFRQIGhhcyBub3QgaGFkIHRoZSByaWdodCBjb2RlLg0K DQpXaGVuIHdlIGRvIHRoaXMsIEkgd291bGQgbGlrZSB0byBhcHByb2FjaCBuZXcgY29kZXMgbm90 IGp1c3Qgd2l0aCDigJx3aGF0IHNob3VsZCB0aGUgc2VydmVyIGRv4oCdIGJ1dCBtb3JlIGltcG9y dGFudGx5IHdpdGgg4oCcaG93IGlzIHRoZSBjbGllbnQgZ29pbmcgdG8gcmVhY3QgZGlmZmVyZW50 bHnigJ0uICBJZiB0aGUgZXJyb3IgcmVzcG9uc2UgaXMganVzdCBhYm91dCB0ZWxsaW5nIHdoYXQg d2VudCB3cm9uZyBzbyBhIGh1bWFuIGNhbiBkZWJ1ZyB0aGUgc2l0dWF0aW9uLCBkaWFnbm9zdGlj IHBheWxvYWRzIGFyZSBmaW5lLiAgSWYgd2UgbmVlZCBtb3JlIGRldGFpbCBpbiBhbiBlcnJvciBy ZXNwb25zZSBzbyB0aGUgY2xpZW50IGNhbiBmb3JtdWxhdGUgYSBiZXR0ZXIgcmVxdWVzdCBiYXNl ZCBvbiB0aG9zZSBkZXRhaWxzLCB3ZSBtYXkgd2FudCB0byBzdGFuZGFyZGl6ZSDigJxwcm9ibGVt IGRldGFpbOKAnSBwYXlsb2FkcywgaW5zcGlyZWQgYnkgUkZDIDc4MDcuDQoNCkdyw7zDn2UsIENh cnN0ZW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVn YWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3 YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1 cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2Uu DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBt YWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29yZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Mon Feb 13 09:04:34 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D0D1296F5 for ; Mon, 13 Feb 2017 09:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PWimmaRz8DK for ; Mon, 13 Feb 2017 09:04:30 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB0A1296DF for ; Mon, 13 Feb 2017 09:04:29 -0800 (PST) Received: from [85.158.139.163] by server-11.bemta-5.messagelabs.com id B4/8D-01711-B17E1A85; Mon, 13 Feb 2017 17:04:27 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRWlGSWpSXmKPExsWi75nToyv9fGG EwY/Fwhb73q5ndmD0WLLkJ1MAYxRrZl5SfkUCa0bHDsGCq14Vk05PY2tgvOHZxcjFISSwnVFi z+5ZrBDOYUaJB2+nM8E5T7bsY4NwNjNK7Nj5DSjDycEm4CpxdNcddhBbRCBQ4tKn+awgtrBAu MSFlh9Q8QiJ95PnMkHYSRL9j5YygtgsAqoS3Uf/sIHYvAKhEt+/zmOGWHCIWeLP0tNgDZwCIR Ibjy1kBrEZBWQlvjSuBrOZBcQlbj2ZD1YjISAgsWTPeWYIW1Ti5eN/QEdwANVoSqzfpQ9Rrig xpfshO8QuQYmTM5+wgNhCQDecODSHbQKj6CwkU2chdM9C0j0LSfcCRpZVjBrFqUVlqUW6hoZ6 SUWZ6RkluYmZObqGBqZ6uanFxYnpqTmJScV6yfm5mxiBEcMABDsYV7Y7H2KU5GBSEuWN3bQwQ ogvKT+lMiOxOCO+qDQntfgQowwHh5IE78GnQDnBotT01Iq0zBxg7MKkJTh4lER4D4OkeYsLEn OLM9MhUqcYFaXEeTtAEgIgiYzSPLg2WLq4xCgrJczLCHSIEE9BalFuZgmq/CtGcQ5GJWHesyB TeDLzSuCmvwJazAS0mDUObHFJIkJKqoHR+NLcngPzjKeHKJiv75nOyu739mem8HTXoiaFLRvN qw2lJ7xqvBS9u1JDiZOnrOJsWGbctXkWp/PW9WkI16p90ZbkPBK3tMvHJ+JSsp6m8H2bromiR T8Cwu1OfGPWL/FmKd7g2H/2jIFR7upfRtyrlJ6IvP7xaF5cm1RkaLseg+Xvb7Mn2yqxFGckGm oxFxUnAgB9AB8YEgMAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-13.tower-188.messagelabs.com!1487005466!87414593!2 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5592 invoked from network); 13 Feb 2017 17:04:27 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe06hw.internal.vodafone.com) (47.73.108.140) by server-13.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 13 Feb 2017 17:04:27 -0000 Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Feb 2017 18:04:25 +0100 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH08W.internal.vodafone.com (47.73.211.212) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 13 Feb 2017 18:04:24 +0100 Received: from VOEXC17W.internal.vodafone.com (145.230.101.19) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 13 Feb 2017 18:04:23 +0100 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.118]) by voexc17w.internal.vodafone.com ([145.230.101.19]) with mapi id 14.03.0294.000; Mon, 13 Feb 2017 18:04:22 +0100 From: "Smith, Kevin, (R&D) Vodafone Group" To: "Dijk, Esko" , "core (core@ietf.org)" Thread-Topic: [core] CoAP response code in case of "response payload too large" ? 4.13? Thread-Index: AQHSe+ap8EBavsJo8kadePi0QO/zPwAEP+wAABxuBgAAAN+rgAACdXTQAWuqCdChUrhBkIAH1tgAgAAnPrA= Date: Mon, 13 Feb 2017 17:04:22 +0000 Message-ID: References: <7A53EAD6-8C9B-4CD8-AA77-9D6482175AB0@tzi.org> <9238ADF7-2926-46FC-8041-7739630B2640@tzi.org> <85d6ff1c1d5047e3b3e516660652d8df@AM3PR90MB0097.MGDPHG.emi.philips.com> <63753ac47f8c4e61b5377b50e57e0795@AM3PR90MB0097.MGDPHG.emi.philips.com> In-Reply-To: <63753ac47f8c4e61b5377b50e57e0795@AM3PR90MB0097.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Feb 2017 17:04:33 -0000 SGVsbG8gRXNrbywNCg0KWWVzLCBhZ3JlZWQuIDR4eCBpcyBzYXlpbmcgdG8gdGhlIGNsaWVudCwg ImlmIHlvdSByZXBlYXQgdGhpcyBzYW1lIHJlcXVlc3QsIG5vIG1hdHRlciBob3cgbWFueSB0aW1l cyB5b3UgdHJ5LCB0aGVuIGl0IHdpbGwgZmFpbC4iIGFuZCBpZGVhbGx5ICJ0aGUgbWlzdGFrZSB5 b3UgbWFkZSBpcyB0aGlzIC0gY29ycmVjdCB0aGF0IGFuZCB5b3Ugc2hvdWxkIGJlIGZpbmUiLg0K DQo1eHggaW5kaWNhdGVzIHRoYXQgZWl0aGVyIHRoZSBzZXJ2ZXIgaXMgYnJva2VuLCBhbmQgbmVl ZHMgdG8gYmUgZml4ZWQgYmVmb3JlIGFueW9uZSBjYW4gcmV0cnksIG9yIHRoYXQgdGhlIHNlcnZl ciBpcyB0ZW1wb3JhcmlseSB1bmFibGUgdG8gc2VydmVyIHRoZSByZXNwb25zZS4gDQoNCkFzIHlv dSBzYXksIGl0IG1heSBiZSB0aGUgY2FzZSB0aGF0IGJvdGggc2l0dWF0aW9ucyBjYW4gb2NjdXIg LSBjbGllbnQgZXJyb3IgYW5kIHNlcnZlciB0ZW1wb3JhcnkgaXNzdWUgLSBpbiB3aGljaCBjYXNl IGl0J3MgdmFsaWQgdG8gaGF2ZSBib3RoIGluIHRoZSBlcnJvciBjYXRhbG9ndWUuIFRoZSBrZXkg cGFydCBpcyB0aGF0IHRoZSBjbGllbnQga25vd3Mgd2hhdCB0byBkbyBuZXh0Lg0KDQpBbGwgYmVz dCwNCktldmluDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlqaywg RXNrbyBbbWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbV0gDQpTZW50OiAxMyBGZWJydWFyeSAy MDE3IDE1OjA1DQpUbzogU21pdGgsIEtldmluLCAoUiZEKSBWb2RhZm9uZSBHcm91cCA8S2V2aW4u U21pdGhAdm9kYWZvbmUuY29tPjsgY29yZSAoY29yZUBpZXRmLm9yZykgPGNvcmVAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogW2NvcmVdIENvQVAgcmVzcG9uc2UgY29kZSBpbiBjYXNlIG9mICJyZXNw b25zZSBwYXlsb2FkIHRvbyBsYXJnZSIgPyA0LjEzPw0KDQpIZWxsbyBLZXZpbiwNCg0KdGhlIHJl c3BvbnNlIGNvZGUgNS4wMyBpbXBsaWVzIHRoYXQgYSBjbGllbnQgY291bGQgcmV0cnkgdGhlIGV4 YWN0IHNhbWUgQ29BUCByZXF1ZXN0IGFmdGVyIHNvbWUgdGltZS4gVGhhdCBzZWVtcyBvayBpZiB0 aGUgbmV0d29yayBpcyB0ZW1wb3JhcmlseSBjb25nZXN0ZWQsIG9yIG90aGVyIHJlc291cmNlLXJl bGF0ZWQgaXNzdWVzIG9jY3VyLiBIb3dldmVyIGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgKHVzaW5n IHF1ZXJ5IHBhcmFtZXRlcnMpIGEgcmVwcmVzZW50YXRpb24gdGhhdCBpcyBmdW5kYW1lbnRhbGx5 IHRvbyBsYXJnZSwgZS5nLiBwZXJoYXBzIGl0IGRvZXMgbm90IGZpdCBpbiBhIHNpbmdsZSBVRFAg ZGF0YWdyYW0sIHRoZW4gcmV0cnlpbmcgaXMgdW53YW50ZWQuIFNvIGZvciB0aGF0IGNhc2UgYWN0 dWFsbHkgNC4wMyBsb29rcyBmaXR0aW5nOyBJIGp1c3Qgc2F3IHRoZSBzZW50ZW5jZSBpbiBSRkMg NzIzMSB0aGVyZSBzdGF0aW5nICJIb3dldmVyLCBhIHJlcXVlc3QgbWlnaHQgYmUgZm9yYmlkZGVu IGZvciByZWFzb25zIHVucmVsYXRlZCB0byB0aGUgY3JlZGVudGlhbHMiLiBTbyB0aGUgcmVhc29u IGNvdWxkIGFsc28gYmUgdGhhdCAiaXQgaXMgZm9yYmlkZGVuIHRvIGFzayBzbyBtdWNoIHVzaW5n IHF1ZXJ5IHBhcmFtZXRlcnMuIg0KDQpyZWdhcmRzDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU21pdGgsIEtldmluLCAoUiZEKSBWb2RhZm9uZSBHcm91cA0KU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAxNTozMg0KVG86IGNvcmUgKGNvcmVAaWV0Zi5vcmcpIDxj b3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBDb0FQIHJlc3BvbnNlIGNvZGUgaW4g Y2FzZSBvZiAicmVzcG9uc2UgcGF5bG9hZCB0b28gbGFyZ2UiID8gNC4xMz8NCg0KSGkgRXNrbywN Cg0KTm90IHN1cmUgaWYgeW91IHNhdyBteSBlYXJsaWVyIHJlcGx5IChjb3BpZWQgYmVsb3cgZm9y IGNvbnZlbmllbmNlKSwgYnV0IGl0IHByb3Bvc2VkIDUwMyBiZWNhdXNlIHRoYXQgZXhwbGljaXRs eSBoaW50cyB0aGUgbmV4dCBzdGVwIHRvIHRoZSBjbGllbnQgLSB3aGljaCBpcyBjZXJ0YWlubHkg aW4gdGhlIEhBVEVPQVMgc3Bpcml0LiBJdCBhbHNvIHNlZW1zIHRoYXQgaW5zdWZmaWNpZW50IHN0 b3JhZ2UgbWF5IG5vdCBiZSB0aGUgb25seSByZWFzb24gZm9yIHRoZSBzZXJ2ZXIgbm90IHdpc2hp bmcgdG8gcmV0dXJuIGEgbGFyZ2UgcmVzcG9uc2UsIGl0IG1heSBhbHNvIGJlIGJlY2F1c2Ugb2Yg YmFuZHdpZHRoIGNvbnN0cmFpbnRzLCBuZXR3b3JrIGNvbmdlc3Rpb24gZXRjLiBTbyBmb3IgdGhh dCByZWFzb24gSSB3b3VsZCBwcm9wb3NlIDUwMywgd2l0aCBSZXRyeSBIZWFkZXIgYW5kIG9wdGlv bmFsIGV4cGxhbmF0b3J5IGJvZHksIG92ZXIgNTA3Lg0KDQpBbGwgYmVzdCwNCktldmluDQoNCi0t LS0tDQoNCkluIGdlbmVyYWwgaXQgbWFrZXMgc2Vuc2UgdG8gbGV0IHRoZSBjbGllbnQga25vdyB3 aGV0aGVyIGl0IGNhbi9zaG91bGQgcmVwZWF0IHRoZSByZXF1ZXN0LiBJbiB0aGlzIGNhc2Ugd2Ug Y2FuIGFzc3VtZSB0aGF0ICdyZXNwb25zZSB0b28gbGFyZ2UnIGlzIGEgdGVtcG9yYXJ5IGNvbmRp dGlvbiAoaWYgbm90IHRoZW4gdGhlcmUgaXMgYSBiaWdnZXIgcHJvYmxlbSA6KSkNCg0KVGhlIGNs aWVudCBzaG91bGQgdGhlcmVmb3JlIGJlIGluZm9ybWVkIHRoYXQgKDEpIHRoZSBjb25kaXRpb24g aXMgcGVyY2VpdmVkIHRvIGJlIHRlbXBvcmFyeSBhbmQgKDIpIGEgcmVjb21tZW5kZWQgZGVsYXkg YmVmb3JlIHRoZSBjbGllbnQgcmVwZWF0cyB0aGUgcmVxdWVzdC4gVGhpcyBJTU8gcHV0cyB0aGUg ZXJyb3IgaW4gdGhlIDV4eCByYW5nZSwgYXMgdGhlIGNsaWVudCBoYXMgbm90IGRvbmUgYW55dGhp bmcgd3JvbmcgYXMgc3VjaCwgYW5kIHRoZSBzYW1lIHJlcXVlc3QgYmVpbmcgbWFkZSBuIHNlY29u ZHMgbGF0ZXIgY291bGQgcmV0dXJuIGEgc3VjY2VzcyBjb2RlIGFuZCBhIG1hbmFnZWFibGUgcmVz cG9uc2UuDQoNClNvIG15IHByZWZlcmVuY2Ugd291bGQgc2ltcGx5IGJlIDUwMyBTZXJ2aWNlIFVu YXZhaWxhYmxlIFsxXSwgd2l0aCBhIFJldHJ5LUFmdGVyIGhlYWRlciBbMl06DQoNCiJUaGUgc2Vy dmVyIGlzIGN1cnJlbnRseSB1bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBhIHRl bXBvcmFyeSBvdmVybG9hZCBvciBzY2hlZHVsZWQgbWFpbnRlbmFuY2UsIHdoaWNoIHdpbGwgbGlr ZWx5IGJlIGFsbGV2aWF0ZWQgYWZ0ZXIgc29tZSBkZWxheS4gVGhlIHNlcnZlciBNQVkgc2VuZCBh IFJldHJ5LUFmdGVyIGhlYWRlciBmaWVsZDEgdG8gc3VnZ2VzdCBhbiBhcHByb3ByaWF0ZSBhbW91 bnQgb2YgdGltZSBmb3IgdGhlIGNsaWVudCB0byB3YWl0IGJlZm9yZSByZXRyeWluZyB0aGUgcmVx dWVzdC4iDQoNClNpbmNlIDV4eCBhbHNvIHJlY29tbWVuZHMgInRoZSBzZXJ2ZXIgU0hPVUxEIHNl bmQgYSByZXByZXNlbnRhdGlvbiBjb250YWluaW5nIGFuIGV4cGxhbmF0aW9uIG9mIHRoZSBlcnJv ciBzaXR1YXRpb24sIGFuZCB3aGV0aGVyIGl0IGlzIGEgdGVtcG9yYXJ5IG9yIHBlcm1hbmVudCBj b25kaXRpb24iIFszXSwgdGhlbiB0aGUgY2xpZW50IGNhbiBiZSBpbmZvcm1lZCB2aWEgdGhlIHJl cHJlc2VudGF0aW9uIHRoYXQgJ3Jlc3BvbnNlIHRvbyBsYXJnZScgd2FzIHRoZSB0ZW1wb3Jhcnkg Y2F1c2UuDQoNCkFsbCBiZXN0LA0KS2V2aW4NClZvZGFmb25lIA0KDQpbMV0gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi02LjYuNCANClsyXSBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzIzMSNzZWN0aW9uLTcuMS4zDQpbM10gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi02LjYNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRGlqaywgRXNrbw0KU2VudDogMDggRmVicnVhcnkgMjAxNyAxNDoxMA0KVG86IGNv cmUgKGNvcmVAaWV0Zi5vcmcpIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBD b0FQIHJlc3BvbnNlIGNvZGUgaW4gY2FzZSBvZiAicmVzcG9uc2UgcGF5bG9hZCB0b28gbGFyZ2Ui ID8gNC4xMz8NCg0KT3IgZm9yIHRoZSBzaG9ydGVyIHRlcm06IHRoZSBIVFRQIGNvZGUgNTA3IElu c3VmZmljaWVudCBTdG9yYWdlIChmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0 OTE4I3NlY3Rpb24tMTEuNSkgaXMgdmVyeSBzdWl0YWJsZSBmb3IgdGhlIHVzZSBjYXNlIG9mICdj bGllbnQgcmVxdWVzdGluZyB0b28gbXVjaCBkYXRhIHZpYSBVUkkgcXVlcnkgcGFyYW1ldGVycycu DQpDb3VsZCB3ZSByZXF1ZXN0IHJlZ2lzdHJhdGlvbiBvZiA1LjA3IGluIHRoZSBDb0FQIFJlc3Bv bnNlIENvZGVzIHJlZ2lzdHJ5IHdpdGggZGlyZWN0IHJlZmVyZW5jZSB0byBSRkMgNDkxOCAvIGNv ZGUgNTA3ID8gIChmb2xsb3dpbmcgdGhlIElFU0cgYXBwcm92YWwgcm91dGUpDQoNCmJlc3QgcmVn YXJkcw0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlqaywgRXNr bw0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwMSwgMjAxNyA5OjUwDQpUbzogJ0NhcnN0ZW4g Qm9ybWFubicgPGNhYm9AdHppLm9yZz47IExhdXJpIFBpaWtpdmkgPExhdXJpLlBpaWtpdmlAYXJt LmNvbT4NCkNjOiBjb3JlIChjb3JlQGlldGYub3JnKSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJFOiBbY29yZV0gQ29BUCByZXNwb25zZSBjb2RlIGluIGNhc2Ugb2YgInJlc3BvbnNlIHBheWxv YWQgdG9vIGxhcmdlIiA/IDQuMTM/DQoNClRoYW5rcyBDYXJzdGVuLCBQYWRkeSwgTGF1cmksDQoN CmZvciB0aGUgY2FzZSBJIHJlZmVycmVkIHRvIGluZGVlZCB0aGUgcmVzcG9uc2UgbmVlZHMgdG8g YmUgbWFjaGluZS1yZWFkYWJsZSBzbyB0aGF0IHRoZSBjbGllbnQgY2FuIGxpbWl0IGl0cyBxdWVy eSBzY29wZS4gRm9yIG91ciBjb25zdHJhaW5lZCBkZXZpY2UgY29udGV4dCBJIHdvdWxkIGF0IGZp cnN0IGV4cGVjdCBhIGZldyBhZGRpdGlvbmFsIHJlc3BvbnNlIGNvZGVzIGRlZmluZWQsIGEgcGVy aGFwcyBtb3JlIGludG8gdGhlIGZ1dHVyZSBhIGNvbXBsZXRlICJwcm9ibGVtIGRldGFpbCIgcGF5 bG9hZC4NCg0KRm9yIHRoZSB0aW1lIGJlaW5nIGl0IGNhbiBiZSBvbmUgb2YgNS4wMCwgNS4wMSBv ciA0LjAzLg0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJz dGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDAxLCAyMDE3IDg6MjINClRvOiBMYXVyaSBQaWlraXZpIDxMYXVyaS5QaWlraXZpQGFybS5j b20+DQpDYzogRGlqaywgRXNrbyA8ZXNrby5kaWprQHBoaWxpcHMuY29tPjsgY29yZSAoY29yZUBp ZXRmLm9yZykgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIENvQVAgcmVzcG9u c2UgY29kZSBpbiBjYXNlIG9mICJyZXNwb25zZSBwYXlsb2FkIHRvbyBsYXJnZSIgPyA0LjEzPw0K DQpIaSBMYXVyaSwNCg0KaW5kZWVkLCB0aGUgQ29SRSB3b3JsZCBpcyBkaWZmZXJlbnQgZnJvbSB0 aGUgSFRUUCB3b3JsZC4NCg0KPiBJIHByb3Bvc2UgYSBiaXQgb2YgaW5mbyBnYXRoZXJpbmcsIEkg IGltYWdpbmUgdGhlcmUgYXJlIG1vcmUgc2ltaWxhciBraW5kcyBvZiBzaXR1YXRpb25zIHdoZXJl IEhUVFAgaGFzIG5vdCBoYWQgdGhlIHJpZ2h0IGNvZGUuDQoNCldoZW4gd2UgZG8gdGhpcywgSSB3 b3VsZCBsaWtlIHRvIGFwcHJvYWNoIG5ldyBjb2RlcyBub3QganVzdCB3aXRoIOKAnHdoYXQgc2hv dWxkIHRoZSBzZXJ2ZXIgZG/igJ0gYnV0IG1vcmUgaW1wb3J0YW50bHkgd2l0aCDigJxob3cgaXMg dGhlIGNsaWVudCBnb2luZyB0byByZWFjdCBkaWZmZXJlbnRseeKAnS4gIElmIHRoZSBlcnJvciBy ZXNwb25zZSBpcyBqdXN0IGFib3V0IHRlbGxpbmcgd2hhdCB3ZW50IHdyb25nIHNvIGEgaHVtYW4g Y2FuIGRlYnVnIHRoZSBzaXR1YXRpb24sIGRpYWdub3N0aWMgcGF5bG9hZHMgYXJlIGZpbmUuICBJ ZiB3ZSBuZWVkIG1vcmUgZGV0YWlsIGluIGFuIGVycm9yIHJlc3BvbnNlIHNvIHRoZSBjbGllbnQg Y2FuIGZvcm11bGF0ZSBhIGJldHRlciByZXF1ZXN0IGJhc2VkIG9uIHRob3NlIGRldGFpbHMsIHdl IG1heSB3YW50IHRvIHN0YW5kYXJkaXplIOKAnHByb2JsZW0gZGV0YWls4oCdIHBheWxvYWRzLCBp bnNwaXJlZCBieSBSRkMgNzgwNy4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBh cHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRk cmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24s IG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kg YWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxp c3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29yZQ0K From nobody Tue Feb 14 12:49:48 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4822129857; Tue, 14 Feb 2017 12:49:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148710538179.9998.17059234842561298954.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 12:49:41 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 20:49:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-06.txt Pages : 47 Date : 2017-02-14 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates [RFC7641] for use with these transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 15 04:18:07 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AE0129546; Wed, 15 Feb 2017 04:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEBAT9GrsssV; Wed, 15 Feb 2017 04:18:03 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0AB129573; Wed, 15 Feb 2017 04:18:03 -0800 (PST) X-AuditID: c1b4fb3a-f72d4980000021e0-0b-58a446f9a023 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 69.E9.08672.9F644A85; Wed, 15 Feb 2017 13:18:01 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.82]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Wed, 15 Feb 2017 13:17:01 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz?= Thread-Index: AQHSh4Voyork67XijE6/jnBfSsrf9g== Date: Wed, 15 Feb 2017 12:17:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_A3E47BC75C17408592DE16BA2B60889Bericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdRfen25IIgyN/xSzuz3vEZLHv7Xpm iz8TFzM6MHssWfKTyaN1x1/2AKYoLpuU1JzMstQifbsEroz2s28ZC3brVPxt+87SwDhJu4uR k0NCwETi3IYepi5GLg4hgXWMEr+33GGEcBYzSnxb+JINpIpNwFni07NGdhBbREBNonXSK7A4 s0ATo8T16/VdjBwcwgKBEhPfm0CUhEm8uXOMEcLWk1jypwPMZhFQlfgyowvM5hWwl2g8cBFs DKOAmMT3U2uYIEaKS9x6Mp8J4jgBiSV7zjND2KISLx//Y4WwlSQW3f4MVZ8scXH3TFaImYIS J2c+YZnAKDQLyahZSMpmISmbBXQ1s4CmxPpd+hAlihJTuh+yQ9gaEq1z5kLZ1hKTTu9iQlaz gJFjFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgHB3c8ttqB+PB546HGAU4GJV4eDcEL44Q Yk0sK67MPcQowcGsJMJrY7skQog3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6Yklqdmp qQWpRTBZJg5OqQbGmO+tPlONPG0XuM7rb+upkUw7tO6AcbuNevWekzW/uLK4mcI31B4L6Tvh ZNOof3+B9nVjNl2RJM3+Ow5OGvnLt0m7S7cHrf69NvGl+/bSGQrhZsuNxTuXN4r3uVXveXt6 +o4eZyHFwkdy/3+bB/g/eGa3hdHDI+HjnRu/ZJ8msJ7bbyjQuVSJpTgj0VCLuag4EQA+s17V nwIAAA== Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: [core] =?utf-8?q?_=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 15 Feb 2017 12:18:05 -0000 --_000_A3E47BC75C17408592DE16BA2B60889Bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb1JFIFdHLA0KDQpUaGVyZSBoYXMgYmVlbiBxdWl0ZSBzb21lIHdvcmsgb24gdGhlICJD b0FQIChDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCkgb3ZlciBUQ1AsIFRMUywgYW5k IFdlYlNvY2tldHPigJ0gZHJhZnQgKGRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMpIHNpbmNl IHRoZSBsYXN0IFdHTEMuDQpCSUcgdGhhbmtzIHRvIEJyaWFuIGZvciB0aGUgdGltZSBhbmQgZWZm b3J0IGRlZGljYXRlZCBhcyBFZGl0b3IuIEl0IG5vdyBzZWVtcyBhIGdvb2QgdGltZSBmb3IgYSBm aW5hbCBXR0xDIHRvIGdldCB0aGUgbGFzdCBjb21tZW50cyBmcm9tIHRoZSBncm91cCBpbiBvcmRl ciB0byBtb3ZlIHRoZSBzcGVjaWZpY2F0aW9uIGZvcndhcmQuDQoNCkluIHBhcnRpY3VsYXIgdGhl cmUgaGFzIG5vdCBiZWVuIG11Y2ggZGlzY3Vzc2lvbiBvbiBzZWN1cmluZyBDb0FQIG92ZXIgV2Vi U29ja2V0cyAoaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy8x MDIpIGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3QgKGh0dHBzOi8vZ2l0aHViLmNvbS9j b3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTA4KSBmZWVkYmFjayB3b3VsZCBiZSB2ZXJ5IG11 Y2ggd2VsY29tZWQuIFBsZWFzZSBnbyBhaGVhZCBhbmQgY2hlY2sgdGhlIGRpc2N1c3Npb25zIG9u IHRoZSBvdGhlciBpc3N1ZXMgb2YgdGhpcyB2ZXJzaW9uOiBodHRwczovL2dpdGh1Yi5jb20vY29y ZS13Zy9jb2FwLXRjcC10bHMvbWlsZXN0b25lLzQ/Y2xvc2VkPTEgIGFuZCBvbiB0aGUgY2hhbmdl bG9nIHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0byBhc2sgdGhl IGdyb3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gc3RhdHVz IG9mIHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFsbHkgT3BlbiBT b3VyY2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC4NCg0KbGF0ZXN0IHZlcnNpb246IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2 DQpkaWZmOiBodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNv cmUtY29hcC10Y3AtdGxzLTA2LnR4dA0KY2hhbmdlbG9nOiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNiNhcHBlbmRpeC1DLjQNCg0KVGhl IFdHTEMgd2lsbCBsYXN0IG9uZSB3ZWVrLCB1bnRpbCAyMDE3LTAyLTIyIC4NCg0KVGhhbmtzIQ0K SmFpbWUgSmltw6luZXoNCg== --_000_A3E47BC75C17408592DE16BA2B60889Bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <49949E2655D07243908549D0F05BDA9E@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5EZWFyIENv UkUgV0csPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGVyZSBoYXMgYmVlbiBxdWl0ZSBzb21lIHdvcmsgb24gdGhlICZxdW90O0NvQVAg KENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sKSBvdmVyIFRDUCwgVExTLCBhbmQgV2Vi U29ja2V0c+KAnSBkcmFmdCAoZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscykgc2luY2UgdGhl IGxhc3QgV0dMQy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QklHIHRoYW5rcyB0byBCcmlh biBmb3IgdGhlIHRpbWUgYW5kIGVmZm9ydCBkZWRpY2F0ZWQgYXMgRWRpdG9yLiBJdCBub3cgc2Vl bXMgYSBnb29kIHRpbWUgZm9yIGEgZmluYWwgV0dMQyB0byBnZXQgdGhlIGxhc3QgY29tbWVudHMg ZnJvbSB0aGUgZ3JvdXAgaW4gb3JkZXIgdG8gbW92ZSB0aGUgc3BlY2lmaWNhdGlvbiBmb3J3YXJk LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SW4gcGFydGljdWxhciB0aGVyZSBoYXMgbm90IGJlZW4gbXVjaCBkaXNjdXNzaW9u IG9uIHNlY3VyaW5nIENvQVAgb3ZlciBXZWJTb2NrZXRzICg8YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEwMiIgY2xhc3M9IiI+aHR0cHM6Ly9n aXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy8xMDI8L2E+KSBhcyB3ZWxsIGFz IHRoZSBEZWZhdWx0IFVSSSBob3N0ICg8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13 Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEwOCIgY2xhc3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL2Nv cmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy8xMDg8L2E+KQ0KIGZlZWRiYWNrIHdvdWxkIGJlIHZl cnkgbXVjaCB3ZWxjb21lZC4gUGxlYXNlIGdvIGFoZWFkIGFuZCBjaGVjayB0aGUgZGlzY3Vzc2lv bnMgb24gdGhlIG90aGVyIGlzc3VlcyBvZiB0aGlzIHZlcnNpb246Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL21pbGVzdG9uZS80P2Nsb3NlZD0x IiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvbWlsZXN0 b25lLzQ/Y2xvc2VkPTE8L2E+Jm5ic3A7Jm5ic3A7YW5kDQogb24gdGhlIGNoYW5nZWxvZyBzdW1t YXJ5LiBJbiBhZGRpdGlvbiB0byB0aGF0LCBJIHdvdWxkIGxpa2UgdG8gYXNrIHRoZSBncm91cCB0 byBsZXQgbWUga25vdyB0aGVpciBjdXJyZW50IGltcGxlbWVudGF0aW9uIHN0YXR1cyBvZiB0aGUg ZHJhZnQgZm9yIHRoZSBzaGVwaGVyZCB3cml0ZXVwLCBlc3BlY2lhbGx5IE9wZW4gU291cmNlIGlt cGxlbWVudGF0aW9ucyBvZiB0aGUgZHJhZnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+bGF0ZXN0IHZlcnNp b246Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y29yZS1jb2FwLXRjcC10bHMtMDYiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2PC9hPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPmRpZmY6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNi50eHQiIGNsYXNzPSIiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY29yZS1jb2FwLXRj cC10bHMtMDYudHh0PC9hPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5jaGFuZ2Vsb2c6Jm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1j b2FwLXRjcC10bHMtMDYjYXBwZW5kaXgtQy40IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNiNhcHBlbmRpeC1DLjQ8L2E+ Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGUgV0dMQyB3aWxsIGxhc3Qgb25lIHdlZWssIHVudGlsJm5ic3A7PGIgY2xhc3M9 IiI+MjAxNy0wMi0yMjwvYj4gLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5K YWltZSBKaW3DqW5lejwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A3E47BC75C17408592DE16BA2B60889Bericssoncom_-- From nobody Thu Feb 16 15:49:06 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0269F129485; Thu, 16 Feb 2017 15:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ysou8gAXsTsK; Thu, 16 Feb 2017 15:49:03 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEBB12947C; Thu, 16 Feb 2017 15:49:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1487288939; h=from:subject:to:date:message-id; bh=4yNz420RZkLO1PFIAUBv5041j8MU+7N8MOSarVhsSLM=; b=OpYj6/gX8jfq5NHF/SzqZ3qrjiIGYOm4ahbaP5TbCVPNa2bS9dVlhrq69q2NbGuCPt3gCnUEJfM abm7ZF0PzjlR7ClY+01+QHChwfCFQShzV6+JLy2TI7uXdwBk+3ieMSP9VzvgVL2XimZ1A8urCSnhv xiXcTn8gE6xHrKypCaFaNffJGfpjA+Izss6aw86+5oweZNVeYIGfdNE3L/d7ROmd8RmgG/OUmhsfH WETLakUwsFx/x9gdFXO55t5ktIxobiMQZFDVLRjGaSQ5Bd+k0D8/rhQKouBS6vQxp6TdWHOjq/qJZ J/EErNQwzXGnYSs2buhdAUJcV6AKSCZANx0g== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Feb 2017 15:48:59 -0800 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Feb 2017 15:46:48 -0800 From: Jim Schaad To: Date: Thu, 16 Feb 2017 15:48:12 -0800 Message-ID: <122a01d288af$241b50f0$6c51f2d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKIqwsh9OLY/kocSyOqYVFeYgm4yQ== X-Originating-IP: [192.168.0.98] Archived-At: Cc: core@ietf.org Subject: [core] Should OSCOAP swallow all error conditions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 16 Feb 2017 23:49:05 -0000 In the process of trying to setup to do some error tests for the OSCOAP interop event, I have started thinking harder about the amount of times that the current document is saying that a message should be silently ignored rather than having a NAK or similar error code being transmitted. Given the re-try behavior that has been defined for CoAP, I am wondering if this is really the behavior that is desired in many cases. Currently if there is a problem with how security is setup and the OSCOAP message does not decrypt for any reason, then the same message will be received multiple times (once for each retry plus the original) each of which will potentially try and find the security context and decrypt the message. A GENERIC security conditions failed response to the first message would prevent the re-transmissions from occurring and might be the preferred behavior. As part of this I would not want to change the currently defined behavior of silently swallowing known re-plays (based on the sequence number) as there might be issues of responses being re-ordered and a NAK message arriving before a good response. I think that a generic response of "Cryptographic Failure" which is defined to have no body (and thus not be usable as an oracle) be defined and returned in many of the current situations where a message is silently consumed. Jim From nobody Thu Feb 16 16:52:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B759412961E for ; Thu, 16 Feb 2017 16:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyh5QEBsVD1Z for ; Thu, 16 Feb 2017 16:52:35 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7DB129559 for ; Thu, 16 Feb 2017 16:52:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1487292751; h=from:subject:to:date:message-id; bh=0H+or3rBcTetBckhqlE0s4nuWzyy4m8qv0k/GzSb8RM=; b=NgcKUIkkhpKhLfrGH3R2mjsW4AEkPbPep2Np7PDc9TrfBWJD1FKldgAr96Eox9GuS9JatiGsupw 11/FpXoSW4PRNAIs7JPC+RPzqS5LNIfdtHVLZ1/Qo6jAuMVcxCbqoX1L3ew3PkM41TQZ6yfUgWKbD r6FIJPea1pNdPMEZyOcVXquvkPiLcR/ZiNqd5bvtVYUjXzGPU+bdjrElC2cJ0AkD8PzNhP6+pz4+L Li8f7KCfg2KgXIOexpyExmT5DADMFG/BXQI3QjYSUS+t+zx5JnGvQSua3gcMUMxPulyOsIfi5r5Sy O/BEUV/vyBj1hyOsIiE+Bft6wPqhXEGnOVUQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Feb 2017 16:52:30 -0800 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Feb 2017 16:50:21 -0800 From: Jim Schaad To: Date: Thu, 16 Feb 2017 16:51:45 -0800 Message-ID: <122f01d288b8$04a073f0$0de15bd0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKIsJRbGAytgy16RKi4y5aG147xqA== X-Originating-IP: [192.168.0.98] Archived-At: Subject: [core] Blocking and OSCOAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 00:52:37 -0000 There has been a lot of discussions about blocking and OSCOAP both here on this list and within a smaller set of people who are looking at doing interop testing. Over the course of this there have been a couple of issues that have been identified. 1. There are differing views on the desirability of having an integrity check that covers the entire message and what the best way to do this is. I expect that there should be discussions on this at the F2F meeting. This is not an issue for random access, which makes it harder to think about for sequential access. 2. Blocking requires that two concurrent 'sessions' not exist for the same resource from the same endpoint. This is a problem with OSCOAP because most of the path and arguments for the resource are going to be hidden by placing them inside of the encrypted payload leaving only Uri-Port and Uri-Host outside of the encryption. One can do a level of blocking inside of the OSCOAP encryption, but there is nothing to prevent blocking from occurring in the wrapper layer as well. Background: If you start with two different resources that a client is trying to down load 1. URL=coap://server/resource1, Source Address=client:60000 2. URL=coap://server/resource2, Source Address=client:60000 And then you apply OSCOAP to them you get 1. URL=coap://server, OSCOAP{/resource1}, Source Address=client:60000 2. URL=coap://server, OSCOAP{/resource2}, Source Address=client:60000 Which means that although the client might think it is trying to get two different resources, the message that is being transmitted is now only dealing with a single resource name for the outer blocking. In order to deal with this, we need to have an option that can be placed outside of the encryption layer to distinguish between these two items. Note that if there is inner blocking, then this can be a unique value for each different message that comes out of the inner blocking. For this reason, it is not clear that using ETag would be a correct answer. Using ETag would allow for an observer to do passive monitoring and correlate different blocks together. Since this does not need to occur it makes ETag a poor answer. In my opinion, fixing this requires creating of a new option with an update to the blocking document so that a new value is created that could be defined from a counter of some that that is added when blocking options are added and removed when they are removed. Jim From nobody Thu Feb 16 19:16:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318B712986F; Thu, 16 Feb 2017 19:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeAMQAV1V_f5; Thu, 16 Feb 2017 19:16:02 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171A3129857; Thu, 16 Feb 2017 19:16:01 -0800 (PST) X-AuditID: c1b4fb30-2868b98000002c77-42-58a66aefb4fd Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id C7.3E.11383.FEA66A85; Fri, 17 Feb 2017 04:16:00 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 04:15:36 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" Thread-Topic: Should OSCOAP swallow all error conditions Thread-Index: AdKIqwsh9OLY/kocSyOqYVFeYgm4yQAIRwYA Date: Fri, 17 Feb 2017 03:15:35 +0000 Message-ID: References: <122a01d288af$241b50f0$6c51f2d0$@augustcellars.com> In-Reply-To: <122a01d288af$241b50f0$6c51f2d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <47304ABE6E983F40BED91E8A07AF10FC@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7ge6HrGURBkfPcFrse7ue2WLavzMs Fqunf2dzYPbYOGc6m8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIe9UxjLdggXHF57wbWBsYPQl2M nBwSAiYS7Sc2MXcxcnEICaxjlHjQNoMFwlnCKHFszXtGkCo2AReJBw2PmEASIgJNjBKP5/Yx gySYBZQljs8+zApiCwuYS7x/2cwEYosIWEg8eTKbBcI2kvjzdj8biM0ioCqx7/x8sF5eoJoj y4+B9QoJ2EvcXjUbrIZTwEHi3rcGsDmMAmIS30+tYYLYJS5x68l8JoizBSSW7DnPDGGLSrx8 /A9sjqiAnsTy52ug4koSaw9vB7qBA6hXU2L9Ln2IMdYSF7echjpfUWJK90N2iHMEJU7OfMIy gVF8FpJtsxC6ZyHpnoWkexaS7gWMrKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAiPv4Jbf BjsYXz53PMQowMGoxMNbsG9phBBrYllxZe4hRgkOZiUR3qzoZRFCvCmJlVWpRfnxRaU5qcWH GKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MDqfv63Czn+w/NyS/4WStY1z+QNSqoXb 34Q9OfLwl5bHrWeJZ75Nu3VHVs2ugn93jVZ5MN8lq/I3tfylDEEngzfvXuwhLHJYZ4/Rr3dz 8hL6npaF537b8Vqw9VrI2hZf2WrrL4X/k68qHLzx2Fr7yd773sz7VGXF7c/qbfRYMe9aVXPk cq9vR5VYijMSDbWYi4oTAVBslQa4AgAA Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Should OSCOAP swallow all error conditions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 03:16:04 -0000 SSB0aGluayBpdCBpcyBhIGdvb2QgcHJvcG9zYWwgdG8gaW50cm9kdWNlIGEgZ2VuZXJpYyBzZWN1 cml0eSBlcnJvci4gSXQgaXMNCm5vdCBhbHdheXMg4oCcY3J5cHRvZ3JhcGhpYyBmYWlsdXJl4oCd LCBidXQgc29tZSBnZW5lcmljIHNsb2dhbiB3b3VsZCBiZSBnb29kLg0KQW5kLCBhcyB5b3Ugbm90 ZSwgc29tZSBmYWlsdXJlcyBzaG91bGQgc3RpbGwgYmUgaGFuZGxlZCB3aXRob3V0IGVycm9yDQpy ZXNwb25zZS4NCg0KSSBmaWxlZCBhbiBpc3N1ZS4NCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L29zY29hcC9pc3N1ZXMvNTkNCg0KR8O2cmFuDQoNCg0KT24gMjAxNy0wMi0xNyAwMDo0OCwgIkpp bSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KPkluIHRoZSBwcm9j ZXNzIG9mIHRyeWluZyB0byBzZXR1cCB0byBkbyBzb21lIGVycm9yIHRlc3RzIGZvciB0aGUgT1ND T0FQDQo+aW50ZXJvcCBldmVudCwgSSBoYXZlIHN0YXJ0ZWQgdGhpbmtpbmcgaGFyZGVyIGFib3V0 IHRoZSBhbW91bnQgb2YgdGltZXMNCj50aGF0DQo+dGhlIGN1cnJlbnQgZG9jdW1lbnQgaXMgc2F5 aW5nIHRoYXQgYSBtZXNzYWdlIHNob3VsZCBiZSBzaWxlbnRseSBpZ25vcmVkDQo+cmF0aGVyIHRo YW4gaGF2aW5nIGEgTkFLIG9yIHNpbWlsYXIgZXJyb3IgY29kZSBiZWluZyB0cmFuc21pdHRlZC4g IEdpdmVuDQo+dGhlDQo+cmUtdHJ5IGJlaGF2aW9yIHRoYXQgaGFzIGJlZW4gZGVmaW5lZCBmb3Ig Q29BUCwgSSBhbSB3b25kZXJpbmcgaWYgdGhpcyBpcw0KPnJlYWxseSB0aGUgYmVoYXZpb3IgdGhh dCBpcyBkZXNpcmVkIGluIG1hbnkgY2FzZXMuICBDdXJyZW50bHkgaWYgdGhlcmUgaXMNCj5hDQo+ cHJvYmxlbSB3aXRoIGhvdyBzZWN1cml0eSBpcyBzZXR1cCBhbmQgdGhlIE9TQ09BUCBtZXNzYWdl IGRvZXMgbm90IGRlY3J5cHQNCj5mb3IgYW55IHJlYXNvbiwgdGhlbiB0aGUgc2FtZSBtZXNzYWdl IHdpbGwgYmUgcmVjZWl2ZWQgbXVsdGlwbGUgdGltZXMNCj4ob25jZQ0KPmZvciBlYWNoIHJldHJ5 IHBsdXMgdGhlIG9yaWdpbmFsKSBlYWNoIG9mIHdoaWNoIHdpbGwgcG90ZW50aWFsbHkgdHJ5IGFu ZA0KPmZpbmQgdGhlIHNlY3VyaXR5IGNvbnRleHQgYW5kIGRlY3J5cHQgdGhlIG1lc3NhZ2UuICBB IEdFTkVSSUMgc2VjdXJpdHkNCj5jb25kaXRpb25zIGZhaWxlZCByZXNwb25zZSB0byB0aGUgZmly c3QgbWVzc2FnZSB3b3VsZCBwcmV2ZW50IHRoZQ0KPnJlLXRyYW5zbWlzc2lvbnMgZnJvbSBvY2N1 cnJpbmcgYW5kIG1pZ2h0IGJlIHRoZSBwcmVmZXJyZWQgYmVoYXZpb3IuICBBcw0KPnBhcnQgb2Yg dGhpcyBJIHdvdWxkIG5vdCB3YW50IHRvIGNoYW5nZSB0aGUgY3VycmVudGx5IGRlZmluZWQgYmVo YXZpb3Igb2YNCj5zaWxlbnRseSBzd2FsbG93aW5nIGtub3duIHJlLXBsYXlzIChiYXNlZCBvbiB0 aGUgc2VxdWVuY2UgbnVtYmVyKSBhcyB0aGVyZQ0KPm1pZ2h0IGJlIGlzc3VlcyBvZiByZXNwb25z ZXMgYmVpbmcgcmUtb3JkZXJlZCBhbmQgYSBOQUsgbWVzc2FnZSBhcnJpdmluZw0KPmJlZm9yZSBh IGdvb2QgcmVzcG9uc2UuDQo+DQo+SSB0aGluayB0aGF0IGEgZ2VuZXJpYyByZXNwb25zZSBvZiAi Q3J5cHRvZ3JhcGhpYyBGYWlsdXJlIiB3aGljaCBpcw0KPmRlZmluZWQNCj50byBoYXZlIG5vIGJv ZHkgKGFuZCB0aHVzIG5vdCBiZSB1c2FibGUgYXMgYW4gb3JhY2xlKSBiZSBkZWZpbmVkIGFuZA0K PnJldHVybmVkIGluIG1hbnkgb2YgdGhlIGN1cnJlbnQgc2l0dWF0aW9ucyB3aGVyZSBhIG1lc3Nh Z2UgaXMgc2lsZW50bHkNCj5jb25zdW1lZC4NCj4NCj5KaW0NCj4NCj4NCg0K From nobody Sat Feb 18 21:54:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1A120727 for ; Sat, 18 Feb 2017 21:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg0jzgA0e-mA for ; Sat, 18 Feb 2017 21:54:41 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACFE1293E9 for ; Sat, 18 Feb 2017 21:46:45 -0800 (PST) X-AuditID: c1b4fb30-2868b98000002c77-38-58a9314314d7 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id FB.03.11383.34139A85; Sun, 19 Feb 2017 06:46:43 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Sun, 19 Feb 2017 06:46:06 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "core@ietf.org" Thread-Topic: [core] Blocking and OSCOAP Thread-Index: AdKIsJRbGAytgy16RKi4y5aG147xqABwuDgA Date: Sun, 19 Feb 2017 05:46:05 +0000 Message-ID: References: <122f01d288b8$04a073f0$0de15bd0$@augustcellars.com> In-Reply-To: <122f01d288b8$04a073f0$0de15bd0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <7088A255CBED6846AB5DF26C510480EA@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7ga6z4coIg6792hb73q5ntlg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXRP+kcW8E9+4oN03waGHvsuhg5OSQETCTu 3j7E3sXIxSEksI5RYt6xhWwQzhJGibYJ1xhBqtgEXCQeNDxiArFFBDwkZjetBIsLC6hLfLi3 EqiBAyiuIXHrvjxEiZHE/R+zwcpZBFQlnr9sZAOxeQUsJO5PmM8MYgsJ2Et8P/QArIZTwEFi +qVTYHFGATGJ76fWgMWZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xgtiiAnoSy5+vgYorSTQu ecIKcg6zgKbE+l36EGOsJQ79/cUMYStKTOl+yA5xjqDEyZlPWCYwis1Csm0WQvcsJN2zkHTP QtK9gJF1FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgRB3c8ttgB+PL546HGAU4GJV4eDfM XBEhxJpYVlyZe4hRgoNZSYT3ltbKCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeW pGanphakFsFkmTg4pRoYVdMmc+sFb+61qXu7wilO/aJD/887D0ze7FpT4vO0QbbaTs2YO654 m8j+qHUfe1u+zrr07MeiCQHKEWobdwRyxldu3Gag13wny+CVLte2fY7Ns+e/6T0S+v5dYdWn oIKY+efKH6/fFSzNcvriE4HZrasbPULZ502Xe9rCVMe5TE6YvafwyXxdJZbijERDLeai4kQA jnGVJqQCAAA= Archived-At: Subject: Re: [core] Blocking and OSCOAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 19 Feb 2017 05:54:42 -0000 SmltLCB0aGFua3MgZm9yIHN1bW1hcmlzaW5nIG9uIHRoZSBsaXN0IGFuZCBjb250aW51aW5nIHRo ZSBkaXNjdXNzaW9uLg0KDQpPbiAyMDE3LTAyLTE3IDAxOjUxLCAiY29yZSBvbiBiZWhhbGYgb2Yg SmltIFNjaGFhZCIgPGNvcmUtYm91bmNlc0BpZXRmLm9yZw0Kb24gYmVoYWxmIG9mIGlldGZAYXVn dXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KDQo+VGhlcmUgaGFzIGJlZW4gYSBsb3Qgb2YgZGlzY3Vz c2lvbnMgYWJvdXQgYmxvY2tpbmcgYW5kIE9TQ09BUCBib3RoIGhlcmUgb24NCj50aGlzIGxpc3Qg YW5kIHdpdGhpbiBhIHNtYWxsZXIgc2V0IG9mIHBlb3BsZSB3aG8gYXJlIGxvb2tpbmcgYXQgZG9p bmcNCj5pbnRlcm9wIHRlc3RpbmcuICBPdmVyIHRoZSBjb3Vyc2Ugb2YgdGhpcyB0aGVyZSBoYXZl IGJlZW4gYSBjb3VwbGUgb2YNCj5pc3N1ZXMNCj50aGF0IGhhdmUgYmVlbiBpZGVudGlmaWVkLg0K Pg0KPjEuICBUaGVyZSBhcmUgZGlmZmVyaW5nIHZpZXdzIG9uIHRoZSBkZXNpcmFiaWxpdHkgb2Yg aGF2aW5nIGFuIGludGVncml0eQ0KPmNoZWNrIHRoYXQgY292ZXJzIHRoZSBlbnRpcmUgbWVzc2Fn ZSBhbmQgd2hhdCB0aGUgYmVzdCB3YXkgdG8gZG8gdGhpcyBpcy4NCj4gSQ0KPmV4cGVjdCB0aGF0 IHRoZXJlIHNob3VsZCBiZSBkaXNjdXNzaW9ucyBvbiB0aGlzIGF0IHRoZSBGMkYgbWVldGluZy4g IFRoaXMNCj5pcw0KPm5vdCBhbiBpc3N1ZSBmb3IgcmFuZG9tIGFjY2Vzcywgd2hpY2ggbWFrZXMg aXQgaGFyZGVyIHRvIHRoaW5rIGFib3V0IGZvcg0KPnNlcXVlbnRpYWwgYWNjZXNzLg0KDQpJIHRo aW5rIHRoaXMgaXMgZGVzaXJhYmxlIGFuZCBJIGRpZCBub3Qgbm90ZSBhbnkgZGlzYWdyZWVtZW50 IG9uIHRoYXQNCnBvaW50LiBPbiB0aGUgdG9waWMgb2Yg4oCcaG934oCdLCBvbmUgcHJvcG9zYWwg aXMgdG8gZGVmaW5lIHNlcGFyYXRlIHJlc291cmNlcw0KY29udGFpbmluZyBjaGVja3N1bXMgb2Yg KGxhcmdlKSByZXByZXNlbnRhdGlvbnM6DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvY29yZS9nalZkRENwdEo5RGZZdnkzdWhiMzV1S3dLNTQNCg0KV291bGQgdGhhdCBu b3QgYWRkcmVzcyB0aGUgaXNzdWU/DQoNCihJdCBzZWVtcyBJIG1pc3NlZCB0byBhbnN3ZXIgeW91 ciBxdWVzdGlvbiAiSXMgdGhpcyBzb21ldGhpbmcgdG8gYmUgZG9uZQ0KYXQgdGhlIENPU0Ugb3Ig YXQgdGhlIENvQVAgbGF5ZXI/4oCdIOKAlCBJIHdvdWxkIHNheSBuZWl0aGVyLiBUaGlzIGlzIG9u IHRvcA0Kb2YgQ29BUC4gVGhlIGNoZWNrc3VtIHJlc291cmNlIGNvdWxkIGJlIGp1c3QgYSBoYXNo IG9mIHRoZSByZXByZXNlbnRhdGlvbi4NCkhlbmNlIHlvdSBjYW4gYWNjZXNzIHRoaXMgcmVzb3Vy Y2Ugd2l0aCBDb0FQIG92ZXIgeW91ciBmYXZvdXJpdGUgc2VjdXJpdHkNCnByb3RvY29sIHRvIHBy b3RlY3QgaXQgZnJvbSBjaGFuZ2UuKQ0KDQoNCg0KPg0KPjIuICBCbG9ja2luZyByZXF1aXJlcyB0 aGF0IHR3byBjb25jdXJyZW50ICdzZXNzaW9ucycgbm90IGV4aXN0IGZvciB0aGUNCj5zYW1lDQo+ cmVzb3VyY2UgZnJvbSB0aGUgc2FtZSBlbmRwb2ludC4gIFRoaXMgaXMgYSBwcm9ibGVtIHdpdGgg T1NDT0FQIGJlY2F1c2UNCj5tb3N0DQo+b2YgdGhlIHBhdGggYW5kIGFyZ3VtZW50cyBmb3IgdGhl IHJlc291cmNlIGFyZSBnb2luZyB0byBiZSBoaWRkZW4gYnkNCj5wbGFjaW5nDQo+dGhlbSBpbnNp ZGUgb2YgdGhlIGVuY3J5cHRlZCBwYXlsb2FkIGxlYXZpbmcgb25seSBVcmktUG9ydCBhbmQgVXJp LUhvc3QNCj5vdXRzaWRlIG9mIHRoZSBlbmNyeXB0aW9uLiAgT25lIGNhbiBkbyBhIGxldmVsIG9m IGJsb2NraW5nIGluc2lkZSBvZiB0aGUNCj5PU0NPQVAgZW5jcnlwdGlvbiwgYnV0IHRoZXJlIGlz IG5vdGhpbmcgdG8gcHJldmVudCBibG9ja2luZyBmcm9tIG9jY3VycmluZw0KPmluIHRoZSB3cmFw cGVyIGxheWVyIGFzIHdlbGwuDQo+DQo+QmFja2dyb3VuZDoNCj4NCj5JZiB5b3Ugc3RhcnQgd2l0 aCB0d28gZGlmZmVyZW50IHJlc291cmNlcyB0aGF0IGEgY2xpZW50IGlzIHRyeWluZyB0byBkb3du DQo+bG9hZA0KPg0KPjEuICBVUkw9Y29hcDovL3NlcnZlci9yZXNvdXJjZTEsIFNvdXJjZSBBZGRy ZXNzPWNsaWVudDo2MDAwMA0KPjIuICBVUkw9Y29hcDovL3NlcnZlci9yZXNvdXJjZTIsIFNvdXJj ZSBBZGRyZXNzPWNsaWVudDo2MDAwMA0KPg0KPkFuZCB0aGVuIHlvdSBhcHBseSBPU0NPQVAgdG8g dGhlbSB5b3UgZ2V0DQo+DQo+MS4gIFVSTD1jb2FwOi8vc2VydmVyLCBPU0NPQVB7L3Jlc291cmNl MX0sIFNvdXJjZSBBZGRyZXNzPWNsaWVudDo2MDAwMA0KPjIuICBVUkw9Y29hcDovL3NlcnZlciwg T1NDT0FQey9yZXNvdXJjZTJ9LCBTb3VyY2UgQWRkcmVzcz1jbGllbnQ6NjAwMDANCj4NCj5XaGlj aCBtZWFucyB0aGF0IGFsdGhvdWdoIHRoZSBjbGllbnQgbWlnaHQgdGhpbmsgaXQgaXMgdHJ5aW5n IHRvIGdldCB0d28NCj5kaWZmZXJlbnQgcmVzb3VyY2VzLCB0aGUgbWVzc2FnZSB0aGF0IGlzIGJl aW5nIHRyYW5zbWl0dGVkIGlzIG5vdyBvbmx5DQo+ZGVhbGluZyB3aXRoIGEgc2luZ2xlIHJlc291 cmNlIG5hbWUgZm9yIHRoZSBvdXRlciBibG9ja2luZy4gIEluIG9yZGVyIHRvDQo+ZGVhbCB3aXRo IHRoaXMsIHdlIG5lZWQgdG8gaGF2ZSBhbiBvcHRpb24gdGhhdCBjYW4gYmUgcGxhY2VkIG91dHNp ZGUgb2YNCj50aGUNCj5lbmNyeXB0aW9uIGxheWVyIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhl c2UgdHdvIGl0ZW1zLiAgTm90ZSB0aGF0IGlmDQo+dGhlcmUNCj5pcyBpbm5lciBibG9ja2luZywg dGhlbiB0aGlzIGNhbiBiZSBhIHVuaXF1ZSB2YWx1ZSBmb3IgZWFjaCBkaWZmZXJlbnQNCj5tZXNz YWdlIHRoYXQgY29tZXMgb3V0IG9mIHRoZSBpbm5lciBibG9ja2luZy4gIEZvciB0aGlzIHJlYXNv biwgaXQgaXMgbm90DQo+Y2xlYXIgdGhhdCB1c2luZyBFVGFnIHdvdWxkIGJlIGEgY29ycmVjdCBh bnN3ZXIuICBVc2luZyBFVGFnIHdvdWxkIGFsbG93DQo+Zm9yDQo+YW4gb2JzZXJ2ZXIgdG8gZG8g cGFzc2l2ZSBtb25pdG9yaW5nIGFuZCBjb3JyZWxhdGUgZGlmZmVyZW50IGJsb2Nrcw0KPnRvZ2V0 aGVyLiAgU2luY2UgdGhpcyBkb2VzIG5vdCBuZWVkIHRvIG9jY3VyIGl0IG1ha2VzIEVUYWcgYSBw b29yIGFuc3dlci4NCj4gDQo+DQo+SW4gbXkgb3BpbmlvbiwgZml4aW5nIHRoaXMgcmVxdWlyZXMg Y3JlYXRpbmcgb2YgYSBuZXcgb3B0aW9uIHdpdGggYW4NCj51cGRhdGUNCj50byB0aGUgYmxvY2tp bmcgZG9jdW1lbnQgc28gdGhhdCBhIG5ldyB2YWx1ZSBpcyBjcmVhdGVkIHRoYXQgY291bGQgYmUN Cj5kZWZpbmVkIGZyb20gYSBjb3VudGVyIG9mIHNvbWUgdGhhdCB0aGF0IGlzIGFkZGVkIHdoZW4g YmxvY2tpbmcgb3B0aW9ucw0KPmFyZQ0KPmFkZGVkIGFuZCByZW1vdmVkIHdoZW4gdGhleSBhcmUg cmVtb3ZlZC4NCg0KSnVzdCB0byBmaXJzdCByZWNhcCB0aGUgaW5uZXIgKGVuY3J5cHRlZCkgYmxv Y2sgb3B0aW9ucywgd2hpY2ggYXJlIHVzZWQgYnkNCmNsaWVudCBhbmQgc2VydmVyIGVuZC10by1l bmQuIFRoZSBpc3N1ZSB3YXMgaWYgYSBjbGllbnQgZm9yIHNvbWUgcmVhc29uDQpjb25jdXJyZW50 bHkgd291bGQgcHVzaCAoUE9TVC9QVVQgZXRjKSBtdWx0aXBsZSBsYXJnZSByZXByZXNlbnRhdGlv bnMgdG8NCnRoZSBzYW1lIHJlc291cmNlIG9uIHRoZSBzYW1lIHNlcnZlciwgc3VjaCB0aGF0IGJv dGggbWVzc2FnZXMgYXJlDQpmcmFnbWVudGVkLCB0aGVuIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gZGlz dGluZ3Vpc2ggdGhlIGRpZmZlcmVudA0KcmVwcmVzZW50YXRpb25zIHRvIGVuc3VyZSB0aGF0IGJs b2NrcyBmcm9tIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgYXJlDQpub3QgbWl4ZWQgdXAuIA0K DQpSRkM3OTU5IGRvZXMgbm90IHN1cHBvcnQgYSBzaW5nbGUgZW5kcG9pbnQgdG8gcGVyZm9ybSBt dWx0aXBsZQ0KY29uY3VycmVudGx5IHByb2NlZWRpbmcgYmxvY2std2lzZSwgYnV0IGhpbnRzIGF0 IGEgd29yay1hcm91bmQgdXNpbmcNCmRpZmZlcmVudCBjYWNoZSBrZXlzLiBDaHJpc3RpYW4gcHJv cG9zZWQgYSBuZXcgb3B0aW9uICJSZXF1ZXN0LVRhZ+KAnSwNCmFuYWxvZ291c2x5IHRvIEVUYWcs IHRoZSBuZXcgb3B0aW9uIHdvdWxkIGdlbmVyYXRlIGRpZmZlcmVudCBjYWNoZSBrZXlzDQphbmQg dGh1cyBpZGVudGlmeSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIGJlaW5nIHB1c2hlZCBieSB0 aGUgY2xpZW50Lg0KV2l0aCB0aGUgdXNlIG9mIHRoaXMgbmV3IG9wdGlvbiwgdGhlIGNoYWluaW5n IG9mIGludGVncml0eSB2YWx1ZXMgYmV0d2Vlbg0KYmxvY2tzIGN1cnJlbnRseSBpbiBPU0NPQVAg Y2FuIGJlIHJlbW92ZWQgd2hpY2ggc2ltcGxpZmllcyB0aGUgcHJvY2Vzc2luZy4NCg0KDQpTaW5j ZSBubyBvbmUgaGFzIG9iamVjdGVkIEkgZ3Vlc3MgdGhpcyBpcyBhbiBhY2NlcHRhYmxlIHNvbHV0 aW9uLCBidXQgaXQNCnN0aWxsIHJlbWFpbnMgdG8gZGVjaWRlIHdoZXRoZXIgdGhlIG5ldyBvcHRp b24gc2hvdWxkIGJlIGRlZmluZWQgaW4gT1NDT0FQDQpvciBpbiBhIHNlcGFyYXRlIGRyYWZ0Lg0K DQpXaGVuIGl0IGNvbWVzIHRvIHRoZSBvdXRlciAodW5wcm90ZWN0ZWQpIGJsb2NrIG9wdGlvbnMs IHdoaWNoIGFyZSB1c2VkIGJ5DQpwcm94aWVzIHRvIGZyYWdtZW50IE9TQ09BUCBtZXNzYWdlcywg dGhlIHNhbWUgY29uc3RydWN0aW9uIGNvdWxkIGJlDQphcHBsaWVkLiBJZiBhIHByb3h5IGlzIGNv bmN1cnJlbnRseSBmcmFnbWVudGluZyBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zDQp0byB0aGUg c2FtZSByZXNvdXJjZSwgYSB0YWcgb2YgdGhlIHJlcHJlc2VudGF0aW9uIHNob3VsZCBiZSBhZGRl ZCB0bw0KZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRoZW0uIEkgYmVsaWV2ZSB0aGlzIHNob3VsZCBz b2x2ZSB0aGUgcHJvYmxlbSBmb3INCm5ldyBwcm94eSBpbXBsZW1lbnRhdGlvbnMsIGFuZCB3b3Vs ZCBhcyBmYXIgYXMgSSBjYW4gdGVsbCBub3QgYmUgYW55DQphZGRpdGlvbmFsIGlzc3VlIHdpdGgg dHJhZmZpYyBhbmFseXNpcyBzaW5jZSBhbGwgdGhlIHByb3h5IGRvZXMgaXMNCmZyYWdtZW50aW5n IGEgbGFyZ2UgZW5jcnlwdGVkIG1lc3NhZ2UgaW50byBzbWFsbGVyIGFuZCBpbmRpY2F0ZSB0aGF0 IHRoZXkNCmJlbG9uZyB0b2dldGhlci4NCg0KQ291bGQgdGhpcyB0YWcgYmUgdGhlIG9wdGlvbiB5 b3UgYXJlIHJlZmVycmluZyB0bz8NCg0KDQpBIHdvcmstYXJvdW5kIGZvciBsZWdhY3kgcHJveGll cyAtIHRvIHdoYXQgZXh0ZW50IHRoYXQgaXMgYSBwcm9ibGVtIC0gaXMNCnRoYXQgdGhlIGNsaWVu dCBpbmNsdWRlcyBhIHRhZyB3aGljaCBpcyBub3QgcHJvdGVjdGVkIGJ5IE9TQ09BUC4gVGhpcw0K d291bGQgZW5hYmxlIGFuIG9ic2VydmVyIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gZGlmZmVyZW50 IHJlcXVlc3RzIGFuZA0Kd291bGQgY3JlYXRlIGFuIG92ZXJoZWFkLiBUaGUgZm9ybWVyIGlzIGFu eXdheSBwb3NzaWJsZSB1bmxlc3Mgc29tZQ0KbWFza2luZyBvZiByZXF1ZXN0cyBpcyBwZXJmb3Jt ZWQsIGxpa2UgY29udGludW91cyBmaWxsLWluIG9mIGR1bW15DQpyZXF1ZXN0cy4gVGhlIGxhdHRl ciBzaG91bGQgaW4gbW9zdCBjYXNlcyBiZSBuZWdsaWdpYmxlIHNpbmNlIHRoZSBzaXplIG9mDQp0 aGUgdGFnIGNhbiBiZSByZXN0cmljdGVkIHRvIHVuaXF1ZWx5IGlkZW50aWZ5aW5nIHRoZSBjb25j dXJyZW50DQpwcm9jZWVkaW5nIHJlcXVlc3RzLCBhbmQgaGVuY2UgdGFncyBjYW4gYmUgcmV1c2Vk IHdoZW4gdGhlIHRyYW5zYWN0aW9uIGlzDQpmaW5pc2hlZC4NCiANCg0KR8O2cmFuDQoNCg0KPg0K PkppbQ0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Y29yZSBtYWlsaW5nIGxpc3QNCj5jb3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Mon Feb 20 07:18:39 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA573129512; Mon, 20 Feb 2017 07:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5O-40Ofq-8x; Mon, 20 Feb 2017 07:18:34 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0098.outbound.protection.outlook.com [104.47.0.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CD21293FB; Mon, 20 Feb 2017 07:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=95gg6sIHgRpontJQDpMSU2eJN/GzqR1q9yDqMNfAjDs=; b=glZ/53hyybgOIUIJIeX+QUzoH8314CbImBxJvSDubVgwMGQtJVVraKA6kgv9TfRljgabzUiGoWlu2D3VJl67wAnXXq0+uXBxDMspw4kO/y7MxUPAY6fL7R6cvph66jTWxaTc3A9wLo/iMa/7Cnx/hBRM9dFEwmUNu35wH4qxEvY= Received: from AM5P122CA0001.EURP122.PROD.OUTLOOK.COM (129.75.138.143) by AM3P122MB0001.EURP122.PROD.OUTLOOK.COM (129.75.100.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Mon, 20 Feb 2017 15:18:30 +0000 Received: from AM1FFO11FD018.protection.gbl (2a01:111:f400:7e00::145) by AM5P122CA0001.outlook.office365.com (2603:10a6:224::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13 via Frontend Transport; Mon, 20 Feb 2017 15:18:30 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.228.36) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.228.36 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.228.36) by AM1FFO11FD018.mail.protection.outlook.com (10.174.64.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10 via Frontend Transport; Mon, 20 Feb 2017 15:18:30 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) by AM3PR90MB0100.MGDPHG.emi.philips.com (141.251.117.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 20 Feb 2017 15:18:29 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) by AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) with mapi id 15.01.0888.034; Mon, 20 Feb 2017 15:18:30 +0000 From: "Dijk, Esko" To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRs?= =?utf-8?Q?s?= Thread-Index: AQHSh4Voyork67XijE6/jnBfSsrf9qFyBJxg Date: Mon, 20 Feb 2017 15:18:30 +0000 Message-ID: <7ecb932aad934f85bd8dbd81af48fd3b@AM3PR90MB0097.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.122] X-MS-Office365-Filtering-Correlation-Id: 026ad531-f938-4160-5640-08d459a3ba24 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: AM3PR90MB0100.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.228.36; IPV:CAL; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(2980300002)(374574003)(199003)(189002)(54534003)(377424004)(55904004)(85714005)(229383001)(38730400002)(105586002)(6246003)(5660300001)(24736003)(108616004)(53546006)(110136004)(54906002)(6306002)(305945005)(55016002)(69596002)(356003)(7736002)(47776003)(626004)(66066001)(229853002)(68736007)(106466001)(230783001)(97736004)(106116001)(53936002)(86362001)(76176999)(54356999)(50986999)(8936002)(81166006)(81156014)(102836003)(2950100002)(92566002)(33646002)(6116002)(3846002)(23676002)(6916009)(7696004)(189998001)(2906002)(26826002)(50466002)(2900100001)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3P122MB0001; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD018; 1:WIVGl653igP58D/h0xrMyc20YltQcox1tjdU/xZWy6UIYkjC+NRZJOr8DBLfKOhZcSB+xyfhsFABnX2viptLglg7sxZ1AgWi6KhBJZ8iCzps3ehkyhB/YYgbaRFHriW0o89gimwZSnch1JV1blDVjg0UB4hN+rjIm8yeFwn0F0Sy9xcmLA5BYhhhrfa9W1C9eTvCQkR/V99VtxsJpy4JyxZsHbOoT/SSnWQ4mr/3+Z+MN2KQSAhmlc/UU23/DTJadvPX7WvrKYwPzeBM3Zj7l9K6vBeUgoofqD+oskN0g5I8TuUlnViYE8qs5+IXMJpkyoTlv2G/ok0BapgNWTiJirOhbgKwCSSdbZTkOTx4zFmT/NwEzDanXxntTwn0jgyf9DhrCQ/Zgw5qlFskvjXy4cW6WO7K1jUMwuZ1fWgVp/Nu6qm9nTT6KDfFm6+yWfYnAkYfDwzrEV4n0SSR87T3SdY4HJ9BkHBcSIYHy5YqeYNO9oVNH4R3NGlkREVd+Rz4 X-CrossPremisesHeadersPromoted: AM1FFO11FD018.protection.gbl X-CrossPremisesHeadersFiltered: AM1FFO11FD018.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3P122MB0001; X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0001; 3:kMM6XbtcOKhO5D2hCRJAmfUIz7CPzBtKnI+CVwvMkS5WSeVsSFYNkHJnBvgRS+bFg5vu0YfwDM1gornUTjntjzaP/vYPu01Gy+Hkcg+Z8YRRm128m6h3sOLHSODRlY3+Re6dMmPxjIfBvO6VLnqZwy4Lgvgij9oqkuGZKPRfHidCN+Pu/8+dDH3r/QKYulz9i2cx2lCQqokubzLWfikA5VGd59cgmuXc8iRGfVTkdoPDZdxKGcHDR4G4O8thAkw16M46EpQ3g8yY7a81NG1PQT5ZGoE/bnvUynSS07NmCI/yCQjYfJLxu18LlOu9xGQ8RRvGW8ZPypQ6foQlgvw0D5saggcydpbfUylyNM+Tx1I=; 25:7g6A4tHohkOm/E4y/I3qHlSf9YKGKmQKV6itOVV2gRfoYdz2wi4ulCg7m6kPSYtScKZSxsEH8qsNW1EooJogkxO3qks2HH+WuFy2RFArasez1DzmvtZqMJ5mC4h2MocBOlEE9p6yzJqzNVM7mnmJAzdBdxn8j5vZiSmEVOGjA1Tpk8poq/z0MldfVPKR6kp2gd6eBfmv4Iujoet/GRBShLcyKoylNhV2eHSrL7ysqj4Egdbx7nh71Evky1VTcRhZXTt+Lu+wJnzaTJy99y717tzLxUiO6dn6oJ/NcFkXwEakLNFMHyk9TrDmNqJ8g47mi08xiMn4OyEznUbHlXqiwCXPgb0Ear+G/OuXNXPwmskY3Ks0jLuhTGb79tGn3reS175d1hZ2AeuLWz4KkaRVSZJOO+Wt8mh7XX5zqOMZsRw9DDtEhfgaycalH3BcDpF1uTXx9SsOnUywYkefQXlxig== X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0001; 31:Vm2TYgSixWCt3LHiUfz2zc2ITXdUQveSEySBtXgMxmMf+SswUiVTt7+W2xrEqzaaO2z7nImexsI7+IGAhVplAroiRno+kcg0HgXI0BJBJhIEzE46m2lVZIeZ11KZOFsFwTqreeSk83W+wp7G0M36cpYW3UXLl4Dx2orjxc3Wyb1oTZaOiD8U8KjN/CmoZ2yznSs/VfT4w0BZxpI9Hwz7Ped8ymKoLErku5a5l0uABsPOkNBJOlWrpwg1MZaqn4TabOS4H8USuE066jKLQfcF9A==; 20:sbV4WAbLVohTvjAbZtPF21A2CkDnZF6KUFp0Hrl+vWxNNacNUFBUsiwP7Uo7PU3K1cO4PJKhrjRDYaNUUv+HdfiWu1FEKHYvNL8EkqWEb+ck935/NMLp9Mqf0yC6cLD1WCvx+bjkCfJYPhrw0dUVmMYWy/FCGiG1qwakhsjkO+rawPQpPuYMTX9N2FDDwJr7AaRIppVqK1pdFxkrn7Vvj54LJH55V/Fo5F/QQFz4wRJLDPhY2ICluaz+PEcQ6d+Gvy0aX91/INVwRaB4k4inOtXdi+qIQB++RXBbkj2nN/TTwh2VEubYjHLHgo3nboPwB7q6C9egYV3CHW51S1Cn/H3E1fII50faYsHafxu8W3pC4RCJEuWTh+Q7ZuXlnk6H4QOoyCGv0YbwZ2vqP1y02k/0vTQXgYw8LTEmuCfEbR3VWUtUL1IEmJX/0I9GVVxl8Cvium5Iqn6G3jQ2VLuQOxMuiuwDygqh+zftAyFt1xuksxjciaobJafhNbvKFV30 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(190756311086443)(158342451672863)(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(13013025)(13021025)(13023025)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:AM3P122MB0001; BCL:0; PCL:0; RULEID:; SRVR:AM3P122MB0001; X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0001; 4:pgF+mwSxtyFcXDnqlpuIT0byCp/2J+VL/1gruOJ++m2/csVI4+OslERC4B2dcYbTrzm6f8eAeINk196hUcMOPKyLhPv1VpgJDUjIOfT0uK7lxbmKmezEbhBUg4ilQRgyFfAfSTCrxMeca2aHSOSAJpgHqDhhOqTMASWP2+2WwKidsZBgVxmLNACLo9BLiGcdYmCveOc9lEX7IXX1fsDjXrfGTKz4XPOYLfHeupmKi7siKrkyPLQTzhQrvfzQTCvjHFVCARRVgTCWBOLBnZVexsDteCHfQ7WBYz9yT4hOu+8wh9WO/UOpAk1lQaBfC0OM0vkquQL9U19jSOVHsPc4VCbfAQJKKKj16j5D3H73E+N886cFdZh4PyEkJXVXS6EvjlIstVcj9uvU0sLTgD9hAWjvadp/PoG/ZKo0T3ffTBI3HhXqhYblTkt14dCRc3TlcP0fG1pMmlzxwOPuFTTGhyratD1W2rJuT3HUao2QZLPW2cdIWTrONAdSqxWFqm2XDoyuw5P7qxJ/0QBnOvm40gUmYWIfVwOZ09k1ghM1QcXz3CScVW0U56p6PwoM2Je0L7vfqnOUahhiOXqHx/R7dsXiGlN2LqL4CYg8o1IeHNFo2MHzhYKFNAeeaDljYH4nEZQ1UgDhBMFFhzb9F/0ghfdpjKsl6WXFGkzf5y9DZg60nGr81+6p3mYMCJgJt/Kb64fC8W9kz3859I9JRWl71+EX7TUqx3Bzwn8xx9VGhyA7MDIZFm1KBqA52jnqU/o4FopEZ9bTT0JkqDvnfpaHpQ== X-Forefront-PRVS: 02243C58C6 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTNQMTIyTUIwMDAxOzIzOktCMWdMeDh3Q3ljVGRSdTMxRys4WXlCcHNE?= =?utf-8?B?ZG9JU3RDVTRmNUlNbk51WWQ3MUEwSFhZSFRUYUV2VG0zdXU5ci81dzVFeTls?= =?utf-8?B?RktWSzVMN3dlRUxmTHZXWlpFUzhCSm5oYkVyL0U4UDdJaGlsUUYxcDNHdjYr?= =?utf-8?B?bWFtZVdaZG1iTEgvZktVWE0wUkNvQ0xLZ3hqYk1VMWJmTjFHYWh3Mk1QK01N?= =?utf-8?B?S1hFUmRuejUyZ0VmUStwOEdDMG5ZdnMzTEI2S0h3UFlTMkVQdnNSRGgzbmh6?= =?utf-8?B?WTRZOHZSNHdmcHVGdjFyUzUwM0YzeFE0M25jZXhKUUJtNzJJZnVJcVRxWEIx?= =?utf-8?B?bDFNaUlvRkxlWkZXTHBXTUVXOHZQNjVhdjY4Z1R0OTlnOUdDVjNYNDhmMStn?= =?utf-8?B?M09qbjMva21xaUNGeFpSZnRDeUxqT1YyQVgxYXZjcEdPSVlSNk05OUc3Mktm?= =?utf-8?B?M0VaY2kyN3k5TS9ZT2hIWHc1VHZuWHFiOWtNT3pacEx4RG1RcVhLMGtxUjQy?= =?utf-8?B?OVZjU2hWSmU0em53ZW44a2U3cVFETk51UEVtcW1abWFVRk1zMllCeFY5ZVZC?= =?utf-8?B?eVRCam1PWXIxa3c4Q3d5elFoTGdrS3djS0x4T2FKRllBYktub2tPNVUvQVFC?= =?utf-8?B?WCtZVFpFWnNHdkVXQXBWaWhWcWNyaGVHQWtROTNRd0tlR2pIcjMyQWxxSWZN?= =?utf-8?B?N0RpYjBsanpyR1h3OGhYbHVOL1QraFVtQjBCbUk2QUtRQjl6aktmTUd5akIr?= =?utf-8?B?Z3cxMW15ZkdZTks4YzdXOVhGQVdqUFc5OHNsZU80SmJwekt2VWJDYmVVNk0y?= =?utf-8?B?UVBVaGZDZVRlcHQyWXZoMXB5czVUVy9KR1pjeEVNcWg3RWpuOEo4Q3gvSm8w?= =?utf-8?B?UlA4SHpNajdCWFNtaVU4RDlSNXdSMTdKb3JaOHh2MXoyV1NhYm4rQ01yM0Nt?= =?utf-8?B?dEJmbWtDYUR0WFFXblF1UnhFOE1LSHowaEk4QVRrdkhxQ1FkWlVwMVFNSk5x?= =?utf-8?B?aEF1V292cjNDK1h2YWswY1VYK3o3TEdkdGpOUmFud1Bjb2M0MGwydTdYM0FI?= =?utf-8?B?M0FpbFZaRkJtb3BsWU5QMk0rSkdIUHZUVzFuRGdwbjAwYUtBN2NpOTl0MVYw?= =?utf-8?B?aXlhT2Q3aXlTOFRKVWhPU3FORnZSQ0VUVkI2dERlZWFrbks5Y0NQTndLVk5Q?= =?utf-8?B?bTVDS3BqWEM1ZGtaczFvOUQ1dWZOSWllMktybGdkUkZvaUhySzdUNUpTNHUw?= =?utf-8?B?c24zTWpySVQ5TTQ0L2FyVWQwZVRtekVMTktaTTRpbHp6SE5rSlRmSGluNXNV?= =?utf-8?B?N3RJbVZ4ZUhENmdMNGkwOEZkd0ZTakFMWngybTFPQWVNTnRNNEoxcTFlcitz?= =?utf-8?B?d0IrVFVVZDdRQjNmS2VUN0FyMmdVTnlDV0pyRnNXcVB6aEptL1ZNRXFhcmk0?= =?utf-8?B?QWYwMzlabzdnYmplV1Ezek5PcGFuWFdOeU1tbGhVUGt1N3hEQ3FBMDVUL2dS?= =?utf-8?B?ZU8xaXl1dXBSejh1RU9lMXVTdzg3eWY1eVp6dEFQMnRzQTNkNDJ4TldiS0Ft?= =?utf-8?B?UmtGUEtxeW81OURLN1NvVks3Qk1TVTVHOHY3UWFzMVZxYlNUd2dKckZCdDlE?= =?utf-8?B?aU1EQzZhZG8xZzZjNnRVUk42Q0M4U1VTTlJneTlySFByLzArdzBRYzRGQVho?= =?utf-8?B?Unh1TTNEb0RZbUE2U2NzaFlJUThJV001SVdBaEZKallkVm02bHV6YXlNdEtm?= =?utf-8?B?enJuUWRvUkNwMlpJTnhGV0VIckUvcVlHS3JNeDdKQTlSS2pMR3htT24zUVMv?= =?utf-8?B?WGlBb2tVZzgvZDBia25SM0NYTDFyRk1yYXpzYTdjN3paQmxERmJLcXFNTWRH?= =?utf-8?B?RHVlMGlBRHhFWGNQc0h6bDFuUW53WGpiZ0hoanovOWxmUWRBNUQva0JIbkFx?= =?utf-8?B?R0N1M1pIQlAwUi9HV3FCazdGRjZ5eG13cHVXSVRMSXdGOWcyTFcxUjFPbnBs?= =?utf-8?B?bTZyODFxV0cwa0NWMjhkVytnUGVIbFhQamlsQT09?= X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0001; 6:lgqBVRY33XLH2gO5R9aZIjK/5DV/mipugPXtOqdzz2wHgjU1BfeYXmE7avM53llfldeidKzdoXAGaC4TtoNqX44aS4dm35q2+RqxfG46hTLfhEh6pqY+o8lY0dGxufb8uAiP5Oxu9zFR4UFSv4Etw6MuyccmI+5yznRKK+BpeHGRTk1zj319HwMhDlwJJVTYY9cGJ87e0xGt6s2Jv356aa973FgZz1HOi6Tk7jNFsFlLsQrEqTyl5mz5YGQwThMJw7q5coNx4Kl97RBSd3dlPQc6cZbfI0OLvYNQUNj1H5+ZxD27rSGta1pWrvIWTsk1W2Pi+uSHO1udpqLO95Zhi/ZDznbCvaTZF1ZZSOSYYAxygeDwAhF0FHAXH5iGTv8E0BZFdsHf8anSvcMVBlTCDyk8G9FxD+e8Wr2//2kjAAE=; 5:qjaZYASoVNsN62ztt8OyJOr3N+sOkZTpF42TWwA1d9VoT/d4C/sar712+UI3vIzveL/AE/Kll0EMjOs52WsCKDiDmzHQIyJSU4mzcxT8+kwEh7997kegbsL4MrQ8TMiHXdAwrdzmUdFmCL6lGiRePc4kaULbKeqWal2rLjldZcc=; 24:Li9Q9sU6XXeRp9Ua18K97zSL4RdZdhWOy7HFokqJBuiWUu8c4VtR/FJx7kriWC0bqG4+6lOlbR2LQ85BNsfZnyEp0CRDVozVSdxZxHrpORg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM3P122MB0001; 7:yz83F1cUeixefzcQs9nEfllkVVqta/Ebv6/8ysdmITaC2wmRCnqr1OFledjn0b8Rk0xPNrJHBlzjG3DiNo2lF/nGWTkVIXxoz0+4jL47c+S439O2UvMMISMHZB2kKqfW82F075HSgSHcCQtT9VricK4OKWt/9zMlmM/dKAwd5lW1Uuf5dJ724PzVUk2zl1w5Ed3DywNq3fJ745B3jH3HSuM0bYQ+0V8s47K2L5psNk3Cqx773Nki+iuClEFnFw+PdGEPNgwwqhoNfdDK6BDvm5RJAg6JOeEJDcN4+LVOmLcgyzkikKBgyUkfhnY/SvtDf/Y4iSIZw00QYd0OE6eLjA== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2017 15:18:30.2787 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.228.36]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3P122MB0001 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM3PR90MB0097.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 194.171.252.122 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: AM3P122MB0001.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 20 Feb 2017 15:18:38 -0000 RGVhciBXRyAmIGF1dGhvcnMsDQoNCkJlbG93IG15IHJldmlldyBvZiB0aGUgZHJhZnQuIE92ZXJh bGwsIEkgZmluZCBpdCBhIHVzZWZ1bCBleHRlbnNpb24gdG8gdGhlIG92ZXJhbGwgJ0NvQVAgcHJv dG9jb2wgc3VpdGUnLiBPbiB0aGUgZGlzY3Vzc2VkIHRpY2tldHMgSSBoYXZlIG5vIGZ1cnRoZXIg aW5wdXQuDQoNCioqIFF1ZXN0aW9ucw0K4oCiIFRoZSBiaS1kaXJlY3Rpb25hbGl0eSBvZiBjb25u ZWN0aW9ucyBpcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiBOb3cgc3VwcG9zZSBhIENvQVAgY2xp ZW50IG9uIGhvc3QgMSBvcGVucyBhIFRDUCBjb25uZWN0aW9uIChhcyBhIFRDUCBjbGllbnQpIHRv IGEgVENQIHNlcnZlciBvbiBob3N0IDIsIGluIG9yZGVyIHRvIHNlbmQgYSBDb0FQIHJlcXVlc3Qg dG8gaXQuIE5vdyB0aGUgVENQIHNlcnZlciAoaG9zdCAyKSBhdCBzb21lIHBvaW50IHN1ZGRlbmx5 IHNlbmRzIGEgQ29BUCByZXF1ZXN0IChhY3RpbmcgaXRzZWxmIGFzIGEgQ29BUCBjbGllbnQpIHRv IHRoZSBUQ1AgY2xpZW50IChob3N0IDEpLiBIb3dldmVyLCB0aGVyZSBpcyBubyBDb0FQIHNlcnZl ciBob3N0ZWQgb24gaG9zdCAxLiBXaGF0IHNob3VsZCBoYXBwZW4gbm93PyBFLmcuIGlzIHRoZSBy ZXF1ZXN0IHNpbXBseSBpZ25vcmVkIG9yIGlzIHNvbWUga2luZCBvZiBlcnJvciBtZXNzYWdlIHJl dHVybmVkPw0K4oCiIFNhbWUgcXVlc3Rpb24gYXMgYWJvdmUgY2FuIGJlIHN0YXRlZCBmb3IgVExT IGFuZCBXZWJzb2NrZXRzLiBJcyB0aGUgYmVoYXZpb3IgdGhlIHNhbWUgaW4gdGhlc2UgY2FzZXM/ DQrigKIgRm9sbG93aW5nIHRoZSBhYm92ZSwgc2hvdWxkIHRoZSBDU00gbWVzc2FnZSBoYXZlIGFu IG9wdGlvbiB0byBpbmRpY2F0ZSBhIGNhcGFiaWxpdHkgb2YgImJlaW5nIGEgQ29BUCBzZXJ2ZXIi IOKApiA/DQrigKIgUGFnZSAyMDogQWx0ZXJuYXRpdmUtQWRkcmVzcyBPcHRpb24gLSB0aGUgc2Vt YW50aWNzIG9mIGluY2x1ZGluZyBtdWx0aXBsZSBvZiB0aGVzZSBvcHRpb25zIGlzIG5vdCBkZWZp bmVkLiBDYW4gdGhlIHJlY2VpdmVyIHBpY2sgYW55IG9mIHRoZSBhZGRyZXNzZXM/IE9yIGRvZXMg aXQgbmVlZCB0byB0cnkgdGhlIGZpcnN0IGFkZHJlc3MgZmlyc3Q/IEFuZCB0aGVuIGtlZXAgdHJ5 aW5nIGFsbCBhbHRlcm5hdGl2ZXMgdW50aWwgb25lIHN1Y2NlZWRzLCBvciBub3Q/DQrigKIgUGFn ZSAyOCwgU2VjdGlvbiA2LjU6IGlzIGl0IGNvcnJlY3QgdG8gY29uY2x1ZGUgdGhhdCwgZm9yIFdl YnNvY2tldCBjb25uZWN0aW9ucywgdGhlIGRlZmF1bHQgVXJpLVBvcnQgdmFsdWUgd2lsbCBiZSA4 MCBpZiB1c2luZyAiY29hcCt3cyIgc2NoZW1lIHdpdGggaXRzIGRlZmF1bHQgVENQIHBvcnQsIGFu ZCA0NDMgaWYgdXNpbmcgImNvYXBzK3dzIiBzY2hlbWUgd2l0aCBpdHMgZGVmYXVsdCBUQ1AgcG9y dD8gSnVzdCBmb3IgbXkgdW5kZXJzdGFuZGluZy4NCuKAoiBBcHBlbmRpeCBBOiBXaHkgaXMgdGhl IHVwZGF0ZSBvZiBPYnNlcnZlIFtSRkM3NjQxXSBkb25lIGluIHRoZSBBcHBlbmRpeCBhbmQgbm90 IGluIGEgbWFpbiBzZWN0aW9uPyBUaGVyZSBtdXN0IGhhdmUgYmVlbiBhIGdvb2QgcmVhc29uIHRv IHBsYWNlIGl0IHRoZXJlOyBidXQgaXQgbG9va3Mgc3RyYW5nZSBzaW5jZSBpdCBmb3JtYWxseSB1 cGRhdGVzIFJGQyA3NjQxLg0KDQoqKiBSZXZpZXcgY29tbWVudHMgLyBwcm9wb3NlZCBjb3JyZWN0 aW9ucw0K4oCiIFBhZ2UgMTAsIEZpZ3VyZSA4OiB0aGUgZmlyc3QgcGlwZSAofCkgY2hhcmFjdGVy IG9uIHRoZSBzZWNvbmQgcm93IG9mIGZpZWxkcyBzaG91bGQgYmUgcmVtb3ZlZCwgaS5lLiB0aGUg RXh0ZW5kZWQgTGVuZ3RoIGZpZWxkIHNob3VsZCB0aGVuIGJlY29tZSA0IGJ5dGVzIGluc3RlYWQg b2YgMy4NCuKAoiBQYWdlIDExOiAicHJvdmlkZWQgYnkgdGhlIFRDUC9UTFMgcHJvdG9jb2wuIiAt PiAicHJvdmlkZWQgYnkgdGhlIFRDUC9UTFMgcHJvdG9jb2xzLiIgPyAgSSBhc3N1bWUgdGhlIGlu dGVudGlvbiBoZXJlIGlzIHRvIHJlZmVyIHRvIGJvdGggcHJvdG9jb2xzIGFzIGRvbmUgZm9yIGFs bCBvdGhlciBvY2N1cnJlbmNlcyBvZiB0aGUgc3RyaW5nICJUQ1AvVExTIiBpbiB0aGUgZG9jdW1l bnQuDQrigKIgUGFnZSAxMjogIltSRkM2NDU0XSIgLSBpdCBpcyB1bmNsZWFyIHdoYXQgYXNwZWN0 IG9yIHNlY3Rpb24gb2YgUkZDIDY0NTQgaXMgcmVmZXJyZWQgdG8gaGVyZS4gIFRoYXQgUkZDIGhh cmRseSBtZW50aW9ucyBXZWJTb2NrZXRzLg0K4oCiIFBhZ2UgMTUsIFNlY3Rpb24gNCwgZmlyc3Qg YnVsbGV0OiAiUmVsYXRlZCBjaGFyYWN0ZXJpc3RpY3MiIC0+ICJMZWFybiByZWxldmFudCBjaGFy YWN0ZXJpc3RpY3MiID8gIFRoZSB2ZXJiIGlzIG1pc3NpbmcgaW4gdGhlIHNlbnRlbmNlLg0K4oCi IFBhZ2UgMTY6ICJhcyBhZGFwdGVkIHRvIHRoZSBzcGVjaWZpYyB0cmFuc3BvcnQuIiAtPiBiaXQg dW5jbGVhciB3aGF0IHRoaXMgbWVhbnMgb3IgaW50ZW5kcyB0byBzYXkuIE1heWJlIGl0IGludGVu ZHMgIndoaWNoIGlzIGFkYXB0ZWQgdG8gc3BlY2lmaWMgcmVsaWFibGUgdHJhbnNwb3J0cyBpbiBT ZWN0aW9ucyAyLjIgYW5kIDMuMiBvZiB0aGlzIGRvY3VtZW50LiIgPw0K4oCiIFBhZ2UgMTY6ICJT ZXR0aW5nIG9wdGlvbnMgaW5kaWNhdGUgYSBzZXR0aW5nIHRoYXQgd2lsbCBiZSBhcHBsaWVkIGJ5 IHRoZSBzZW5kZXIiIC0+ICJFYWNoIHNldHRpbmcgb3B0aW9uIGluZGljYXRlcyBhIHNldHRpbmcg dGhhdCB3aWxsIGJlIGFwcGxpZWQgYnkgdGhlIHNlbmRlciIgPw0K4oCiIFBhZ2UgMTk6IENvdWxk IGNsYXJpZnkgdGhlIHNlbnRlbmNlIGJlbG93IHRvIHNheSB0aGlzIGlzIGFib3V0IGhhbmRsaW5n IGEgUGluZyB3aXRoIEN1c3RvZHkgT3B0aW9uIG9ubHksIHNvIG5vdCBpbiBnZW5lcmFsIGZvciBl dmVyeSBQaW5nIG1lc3NhZ2U6DQoiVGhlIHJlY2VpdmVyIFNIT1VMRCBkZWxheSBpdHMgUG9uZyBt ZXNzYWdlIHVudGlsIGl0IGZpbmlzaGVzIHByb2Nlc3NpbmcgYWxsIHRoZSByZXF1ZXN0Lw0KICAg cmVzcG9uc2UgbWVzc2FnZXMgcmVjZWl2ZWQgcHJpb3IgdG8gdGhlIFBpbmcgbWVzc2FnZSBvbiB0 aGUgY3VycmVudCBjb25uZWN0aW9uLiINCiAgIC0+DQoiSW4gdGhhdCBjYXNlLCB0aGUgcmVjZWl2 ZXIgU0hPVUxEIGRlbGF5IGl0cyBQb25nIG1lc3NhZ2UgdW50aWwgaXQgZmluaXNoZXMgcHJvY2Vz c2luZyBhbGwgdGhlIHJlcXVlc3QvDQogICByZXNwb25zZSBtZXNzYWdlcyByZWNlaXZlZCBwcmlv ciB0byB0aGF0IFBpbmcgbWVzc2FnZSBvbiB0aGUgY3VycmVudCBjb25uZWN0aW9uLiINCuKAoiBQ YWdlIDIyOg0KICAgImNvbnRhaW4gYSBtdWx0aXBsZSBvZiAxMDI0IGJ5dGVzIChub24tZmluYWwg QkVSVCBibG9jaykgb3IgbW9yZSB0aGFuIDEwMjQgYnl0ZXMgKGZpbmFsIEJFUlQgYmxvY2spIg0K ICAgICAtPiBXaHkgY2FuJ3QgdGhlIGZpbmFsIGJsb2NrIGJlIDEwMjQgYnl0ZXM/IEkgYXNzdW1l IGEgZmluYWwgQkVSVCBibG9jayBvZiAxMDI0IGJ5dGVzIGlzIGFsbG93ZWQ7IGl0IHdvdWxkIGJl IHN0cmFuZ2UgdG8gc3dpdGNoIGJhY2sgdG8gU1pYPTYgZm9yIHRoYXQgcHVycG9zZS4gV2hhdCBh Ym91dCBiZWxvdyB0ZXh0IC0+DQogICAiY29udGFpbiBhIG11bHRpcGxlIG9mIDEwMjQgYnl0ZXMg KG5vbi1maW5hbCBCRVJUIGJsb2NrKSBvciBtb3JlIHRoYW4gMTAyMyBieXRlcyAoZmluYWwgQkVS VCBibG9jaykiDQrigKIgUGFnZSAyMzogImJsb2NrIHNpemUgZXhwb25lbnQgKDIqKihTWlgrNCkp IiAtPiAiYmxvY2sgc2l6ZSAoMioqKFNaWCs0KSkiICAgKFNpbmNlIHRoZSBleHBvbmVudCBpcyBu b3Qgc2hvd24gaW4gdGhlIG5vdGF0aW9uLCByYXRoZXIgdGhlIHJlc3VsdGluZyBzaXplIHZhbHVl KQ0K4oCiIFBhZ2UgMjU6ICJUaGV5IGFyZSBkaXN0aW5jdCBuYW1lc3BhY2VzIGFuZCBhcmUgY29u c2lkZXJlZCB0byBiZSBkaXN0aW5jdCBvcmlnaW4gc2VydmVycyIgLT4gQXNzdW1pbmcgdGhhdCAn dGhleScgcmVmZXJzIHRvIHRoZSByZXNvdXJjZXMuIFNob3VsZG4ndCB3ZSByYXRoZXIgc2F5ICJU aGV5IGFyZSBob3N0ZWQgaW4gZGlzdGluY3QgbmFtZXNwYWNlcywgYmVjYXVzZSBlYWNoIFVSSSBz Y2hlbWUgaW1wbGllcyBhIGRpc3RpbmN0IG9yaWdpbiBzZXJ2ZXIuIg0KSXQgc2VlbXMgc3RyYW5n ZSB0byBzYXkgdGhhdCBhIHJlc291cmNlIGlzIGNvbnNpZGVyZWQgdG8gYmUgbmFtZXNwYWNlLCBh bmQgYSByZXNvdXJjZSBpcyBjb25zaWRlcmVkIHRvIGJlIGFuIG9yaWdpbiBzZXJ2ZXIuIFdoaWNo IGlzIHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBzdGF0ZXMgOikNCg0KKiogTml0cw0K4oCiIFBhZ2Ug NTogU2VjdGlvbiAxLjEgbWlnaHQgYWRkIGEgc2hvcnQgbm90ZSB0aGF0ICJUQ1AvVExTIiBtZWFu cyAiVENQIG9yIFRMUyIgaW4gdGhpcyBkb2N1bWVudCwgYW5kIG5vdCAiVExTIG92ZXIgVENQIiBv ciBzby4gQnV0IHBlcmhhcHMgaXQncyBvYnZpb3VzIHRvIG1vc3QgcGVvcGxlLg0K4oCiIFBhZ2Ug OTogIm1vZGVsZWQgb24gQ29BUCBPcHRpb25zIiAtPiAibW9kZWxlZCBvbiB0aGUgT3B0aW9uIExl bmd0aCBmaWVsZCBpbiBDb0FQIE9wdGlvbnMiID8NCuKAoiBQYWdlIDEzOiAiUmV2ZXJzZSBQcm94 eSIgLT4gInJldmVyc2UtcHJveHkiICAodG8gY29tcGx5IHdpdGggUkZDIDcyNTIgdGVybWlub2xv Z3kpDQrigKIgUGFnZSAxODogImVxdWFsIG9yIGxlc3MiIC0+ICJlcXVhbCB0byBvciBsZXNzIg0K 4oCiIFBhZ2UgMjcsIEZpZ3VyZSAxOTogZmlyc3QgYWNjb2xhZGUgc2hvdWxkIGV4dGVuZCBzbGln aHRseSB0byB0aGUgcmlnaHQsIHNlY29uZCBhY2NvbGFkZSBzaG91bGQgbW92ZSBzbGlnaHRseSB0 byB0aGUgcmlnaHQuDQrigKIgUGFnZSAyOCwgU2VjdGlvbiA2LjY6IHRoZSBjaGFuZ2VzIGluZGlj YXRlZCBjb3VsZCBpbXByb3ZlIGluIHJlYWRhYmlsaXR5IGEgYml0IGJ5IGhhdmluZyBhIGZvcm0g b2YgIm9sZC9uZXcgaW5kaWNhdGlvbiIuDQrigKIgUGFnZSAzMSwgU2VjdGlvbiA4LjE6IGxpc3Qg YnVsbGV0IGNhbiBiZSByZW1vdmVkDQrigKIgR2xvYmFsOiBzL3BvcnQgY29tcG9uZW50L3BvcnQg c3ViY29tcG9uZW50Lw0K4oCiIFBhZ2UgNDM6ICJbMjAwMTpEQjg6OjFdIiAtPiAiWzIwMDE6ZGI4 OjoxXSINCg0KYmVzdCByZWdhcmRzLA0KRXNrbyBEaWprDQotLS0NCg0KRnJvbTogY29yZSBbbWFp bHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphaW1lIEppbcOpbmV6DQpT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDEzOjE3DQpUbzogY29yZUBpZXRmLm9y ZyBXRyA8Y29yZUBpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzQGll dGYub3JnDQpTdWJqZWN0OiBbY29yZV0g8J+UlCBXR0xDIGRyYWZ0LWlldGYtY29yZS1jb2FwLXRj cC10bHMNCg0KRGVhciBDb1JFIFdHLA0KDQpUaGVyZSBoYXMgYmVlbiBxdWl0ZSBzb21lIHdvcmsg b24gdGhlICJDb0FQIChDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCkgb3ZlciBUQ1As IFRMUywgYW5kIFdlYlNvY2tldHPigJ0gZHJhZnQgKGRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10 bHMpIHNpbmNlIHRoZSBsYXN0IFdHTEMuDQpCSUcgdGhhbmtzIHRvIEJyaWFuIGZvciB0aGUgdGlt ZSBhbmQgZWZmb3J0IGRlZGljYXRlZCBhcyBFZGl0b3IuIEl0IG5vdyBzZWVtcyBhIGdvb2QgdGlt ZSBmb3IgYSBmaW5hbCBXR0xDIHRvIGdldCB0aGUgbGFzdCBjb21tZW50cyBmcm9tIHRoZSBncm91 cCBpbiBvcmRlciB0byBtb3ZlIHRoZSBzcGVjaWZpY2F0aW9uIGZvcndhcmQuDQoNCkluIHBhcnRp Y3VsYXIgdGhlcmUgaGFzIG5vdCBiZWVuIG11Y2ggZGlzY3Vzc2lvbiBvbiBzZWN1cmluZyBDb0FQ IG92ZXIgV2ViU29ja2V0cyAoaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxz L2lzc3Vlcy8xMDIpIGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3QgKGh0dHBzOi8vZ2l0 aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTA4KSBmZWVkYmFjayB3b3VsZCBi ZSB2ZXJ5IG11Y2ggd2VsY29tZWQuIFBsZWFzZSBnbyBhaGVhZCBhbmQgY2hlY2sgdGhlIGRpc2N1 c3Npb25zIG9uIHRoZSBvdGhlciBpc3N1ZXMgb2YgdGhpcyB2ZXJzaW9uOiBodHRwczovL2dpdGh1 Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvbWlsZXN0b25lLzQ/Y2xvc2VkPTEgIGFuZCBvbiB0 aGUgY2hhbmdlbG9nIHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0 byBhc2sgdGhlIGdyb3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRp b24gc3RhdHVzIG9mIHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFs bHkgT3BlbiBTb3VyY2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC4NCg0KbGF0ZXN0IHZl cnNpb246IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC10 Y3AtdGxzLTA2DQpkaWZmOiBodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2LnR4dA0KY2hhbmdlbG9nOiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNiNhcHBlbmRpeC1D LjQNCg0KVGhlIFdHTEMgd2lsbCBsYXN0IG9uZSB3ZWVrLCB1bnRpbCAyMDE3LTAyLTIyIC4NCg0K VGhhbmtzIQ0KSmFpbWUgSmltw6luZXoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25m aWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUg bWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9m IHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRo ZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBv cmlnaW5hbCBtZXNzYWdlLg0K From nobody Tue Feb 21 06:04:13 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46F7129BC6; Tue, 21 Feb 2017 06:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb8JsZsqVX3X; Tue, 21 Feb 2017 06:04:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7812B129BC2; Tue, 21 Feb 2017 06:04:09 -0800 (PST) Received: from [192.168.91.176] ([195.149.223.239]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lt1yI-1cEE0q0VtS-012bG3; Tue, 21 Feb 2017 15:04:06 +0100 To: "Dijk, Esko" , "core@ietf.org WG" References: <7ecb932aad934f85bd8dbd81af48fd3b@AM3PR90MB0097.MGDPHG.emi.philips.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <3145d49b-30c7-3a51-f362-551c631ab7ad@gmx.net> Date: Tue, 21 Feb 2017 15:04:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <7ecb932aad934f85bd8dbd81af48fd3b@AM3PR90MB0097.MGDPHG.emi.philips.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FeqeCCbnMEk1fPXhKW3P3H4n4EKsh4DiS" X-Provags-ID: V03:K0:tlD4EpmmQsahPJbPS55znx1XlpcTQ20vqGzBseQGJrdn9bbSsf1 3xzVBZfZ8NTzc7eP3VKe9dyXmdRo6TC1otCpJ7qv4o6MEpR1UpcV++cE4ZaIvQURLisvSAZ SL4QyTgXnmsDFmTVzsVJ3OzZsOekRW8cAqLDcBYbsZC9lHJ866Qwx4D7gwOekJuwi13qpE+ IIFn13yRO1VWJOcDB/PiQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:dtdZiHifJbM=:dWkg5D8eBhfmoDMTSpWmNC 63KLMmA643B8kvGQGT1JesJ+mY0+F0hlqCxrsccuF8GYrNPn+fAXB4epIZZZxa3RtC5pZ8gzJ +nEbQRrD4HMImpLtq6k5kUf6W2BG49swftu+LdIM0oOo5qiHv8MVdin3wsBm+dhCTJtNh1feT pTG51KaXyww+f0SszCCpNicm1RCATdZb4AWTG1C5XTlrTu549okTilR18JZGe2hA7s+yn6nk+ 1WKhPH0JLjGRIWawwonlsWxDHwLOD3wENwJpsr9wIL+5C85yCA6ssik6UIotsejTe+gr+82/E sJr1FSQM5jlwXW4BjSdI4LXfHuAsdmkBbpq/Pz0/EJnXre6+lvrhtaDzVZlQwZ9ka2HtBWlwj JnjqAsr9HGM7Y00DmUhoWAp4oac7pJaXlEEuG0ORNnKQrWi5SXxdpHD7tumpxTHXUQUrUNMw0 AXNQdKO5/2JRBKpdrFhnvL1MByBtQujSk9JxZKizTSJ1v5c/Esp7fVsY4lVfE7SxzdNhEN/Zd jHUNumbtvyU5JwOvF16FgSrh1soyecARQtlrQzz1xeza8Y++cc1gitQpuU2Fe4Lyxs99wstuf TH+q/8vqINPPArpv0TUdGAw1QlDXmPwNTx0R+8dFwU/L1GJ9HEH8y0gGtaGmCABU3gVnUmP6l wvjtBrVY+R2hsPho6anlSH2i+/Z9xAn1qhmtGtuUwNLyaVTz4Hoxu8qFi85sM6PTXUnrYktIl paxHOU9pMt+lD7q3vTUbKgIeto6+IejXmi0DEqkuIac/pBMbyVk4SjxWelc= Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 14:04:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FeqeCCbnMEk1fPXhKW3P3H4n4EKsh4DiS Content-Type: multipart/mixed; boundary="rM4t3lvUjtTjrBup6TI6AgDf9xI1410Xt"; protected-headers="v1" From: Hannes Tschofenig To: "Dijk, Esko" , "core@ietf.org WG" Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Message-ID: <3145d49b-30c7-3a51-f362-551c631ab7ad@gmx.net> Subject: =?UTF-8?Q?Re:_[core]_=f0=9f=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= References: <7ecb932aad934f85bd8dbd81af48fd3b@AM3PR90MB0097.MGDPHG.emi.philips.com> In-Reply-To: <7ecb932aad934f85bd8dbd81af48fd3b@AM3PR90MB0097.MGDPHG.emi.philips.com> --rM4t3lvUjtTjrBup6TI6AgDf9xI1410Xt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for your detailed review, Esko. I started to address some of your comments. More later. ** Review comments / proposed corrections =E2=80=A2 Page 10, Figure 8: the first pipe (|) character on the second r= ow of fields should be removed, i.e. the Extended Length field should then become 4 bytes instead of 3. Fixed. =E2=80=A2 Page 11: "provided by the TCP/TLS protocol." -> "provided by th= e TCP/TLS protocols." ? I assume the intention here is to refer to both protocols as done for all other occurrences of the string "TCP/TLS" in the document. Since this section only talks about TCP and not TLS I removed TLS. =E2=80=A2 Page 12: "[RFC6454]" - it is unclear what aspect or section of = RFC 6454 is referred to here. That RFC hardly mentions WebSockets. I removed the sentence since it does not add any value right now. =E2=80=A2 Page 15, Section 4, first bullet: "Related characteristics" -> = "Learn relevant characteristics" ? The verb is missing in the sentence. Fixed. =E2=80=A2 Page 16: "as adapted to the specific transport." -> bit unclear= what this means or intends to say. Maybe it intends "which is adapted to specific reliable transports in Sections 2.2 and 3.2 of this document." ?= I simplified the sentence saying "See Section 3 of CoAP for the overall structure of the message format, option format, and option value format."= =E2=80=A2 Page 16: "Setting options indicate a setting that will be appli= ed by the sender" -> "Each setting option indicates a setting that will be applied by the sender" ? Sounds like a good proposal. ** Nits =E2=80=A2 Page 5: Section 1.1 might add a short note that "TCP/TLS" means= "TCP or TLS" in this document, and not "TLS over TCP" or so. But perhaps it's obvious to most people. OK. Clarified. =E2=80=A2 Page 9: "modeled on CoAP Options" -> "modeled on the Option Len= gth field in CoAP Options" ? I changed it to "The encoding of the Length field is modeled after the Option Length field of the CoAP Options." =E2=80=A2 Page 13: "Reverse Proxy" -> "reverse-proxy" (to comply with RF= C 7252 terminology) OK. =E2=80=A2 Page 18: "equal or less" -> "equal to or less" OK. =E2=80=A2 Page 27, Figure 19: first accolade should extend slightly to th= e right, second accolade should move slightly to the right. OK. =E2=80=A2 Page 28, Section 6.6: the changes indicated could improve in readability a bit by having a form of "old/new indication". =E2=80=A2 Page 31, Section 8.1: list bullet can be removed OK. =E2=80=A2 Global: s/port component/port subcomponent/ OK. =E2=80=A2 Page 43: "[2001:DB8::1]" -> "[2001:db8::1]" OK. Ciao Hannes On 02/20/2017 04:18 PM, Dijk, Esko wrote: > Dear WG & authors, >=20 > Below my review of the draft. Overall, I find it a useful extension to = the overall 'CoAP protocol suite'. On the discussed tickets I have no fur= ther input. >=20 > ** Questions > =E2=80=A2 The bi-directionality of connections is mentioned in the draf= t. Now suppose a CoAP client on host 1 opens a TCP connection (as a TCP c= lient) to a TCP server on host 2, in order to send a CoAP request to it. = Now the TCP server (host 2) at some point suddenly sends a CoAP request (= acting itself as a CoAP client) to the TCP client (host 1). However, ther= e is no CoAP server hosted on host 1. What should happen now? E.g. is the= request simply ignored or is some kind of error message returned? > =E2=80=A2 Same question as above can be stated for TLS and Websockets. = Is the behavior the same in these cases? > =E2=80=A2 Following the above, should the CSM message have an option to= indicate a capability of "being a CoAP server" =E2=80=A6 ? > =E2=80=A2 Page 20: Alternative-Address Option - the semantics of includ= ing multiple of these options is not defined. Can the receiver pick any o= f the addresses? Or does it need to try the first address first? And then= keep trying all alternatives until one succeeds, or not? > =E2=80=A2 Page 28, Section 6.5: is it correct to conclude that, for Web= socket connections, the default Uri-Port value will be 80 if using "coap+= ws" scheme with its default TCP port, and 443 if using "coaps+ws" scheme = with its default TCP port? Just for my understanding. > =E2=80=A2 Appendix A: Why is the update of Observe [RFC7641] done in th= e Appendix and not in a main section? There must have been a good reason = to place it there; but it looks strange since it formally updates RFC 764= 1. >=20 > ** Review comments / proposed corrections > =E2=80=A2 Page 10, Figure 8: the first pipe (|) character on the second= row of fields should be removed, i.e. the Extended Length field should t= hen become 4 bytes instead of 3. > =E2=80=A2 Page 11: "provided by the TCP/TLS protocol." -> "provided by = the TCP/TLS protocols." ? I assume the intention here is to refer to bot= h protocols as done for all other occurrences of the string "TCP/TLS" in = the document. > =E2=80=A2 Page 12: "[RFC6454]" - it is unclear what aspect or section o= f RFC 6454 is referred to here. That RFC hardly mentions WebSockets. > =E2=80=A2 Page 15, Section 4, first bullet: "Related characteristics" -= > "Learn relevant characteristics" ? The verb is missing in the sentence= =2E > =E2=80=A2 Page 16: "as adapted to the specific transport." -> bit uncle= ar what this means or intends to say. Maybe it intends "which is adapted = to specific reliable transports in Sections 2.2 and 3.2 of this document.= " ? > =E2=80=A2 Page 16: "Setting options indicate a setting that will be app= lied by the sender" -> "Each setting option indicates a setting that will= be applied by the sender" ? > =E2=80=A2 Page 19: Could clarify the sentence below to say this is abou= t handling a Ping with Custody Option only, so not in general for every P= ing message: > "The receiver SHOULD delay its Pong message until it finishes processin= g all the request/ > response messages received prior to the Ping message on the current = connection." > -> > "In that case, the receiver SHOULD delay its Pong message until it fini= shes processing all the request/ > response messages received prior to that Ping message on the current= connection." > =E2=80=A2 Page 22: > "contain a multiple of 1024 bytes (non-final BERT block) or more tha= n 1024 bytes (final BERT block)" > -> Why can't the final block be 1024 bytes? I assume a final BERT = block of 1024 bytes is allowed; it would be strange to switch back to SZX= =3D6 for that purpose. What about below text -> > "contain a multiple of 1024 bytes (non-final BERT block) or more tha= n 1023 bytes (final BERT block)" > =E2=80=A2 Page 23: "block size exponent (2**(SZX+4))" -> "block size (2= **(SZX+4))" (Since the exponent is not shown in the notation, rather th= e resulting size value) > =E2=80=A2 Page 25: "They are distinct namespaces and are considered to = be distinct origin servers" -> Assuming that 'they' refers to the resourc= es. Shouldn't we rather say "They are hosted in distinct namespaces, beca= use each URI scheme implies a distinct origin server." > It seems strange to say that a resource is considered to be namespace, = and a resource is considered to be an origin server. Which is what the cu= rrent text states :) >=20 > ** Nits > =E2=80=A2 Page 5: Section 1.1 might add a short note that "TCP/TLS" mea= ns "TCP or TLS" in this document, and not "TLS over TCP" or so. But perha= ps it's obvious to most people. > =E2=80=A2 Page 9: "modeled on CoAP Options" -> "modeled on the Option L= ength field in CoAP Options" ? > =E2=80=A2 Page 13: "Reverse Proxy" -> "reverse-proxy" (to comply with = RFC 7252 terminology) > =E2=80=A2 Page 18: "equal or less" -> "equal to or less" > =E2=80=A2 Page 27, Figure 19: first accolade should extend slightly to = the right, second accolade should move slightly to the right. > =E2=80=A2 Page 28, Section 6.6: the changes indicated could improve in = readability a bit by having a form of "old/new indication". > =E2=80=A2 Page 31, Section 8.1: list bullet can be removed > =E2=80=A2 Global: s/port component/port subcomponent/ > =E2=80=A2 Page 43: "[2001:DB8::1]" -> "[2001:db8::1]" >=20 > best regards, > Esko Dijk > --- >=20 > From: core [mailto:core-bounces@ietf.org] On Behalf Of Jaime Jim=C3=A9n= ez > Sent: Wednesday, February 15, 2017 13:17 > To: core@ietf.org WG > Cc: draft-ietf-core-coap-tcp-tls@ietf.org > Subject: [core] =F0=9F=94=94 WGLC draft-ietf-core-coap-tcp-tls >=20 > Dear CoRE WG, >=20 > There has been quite some work on the "CoAP (Constrained Application Pr= otocol) over TCP, TLS, and WebSockets=E2=80=9D draft (draft-ietf-core-coa= p-tcp-tls) since the last WGLC. > BIG thanks to Brian for the time and effort dedicated as Editor. It now= seems a good time for a final WGLC to get the last comments from the gro= up in order to move the specification forward. >=20 > In particular there has not been much discussion on securing CoAP over = WebSockets (https://github.com/core-wg/coap-tcp-tls/issues/102) as well a= s the Default URI host (https://github.com/core-wg/coap-tcp-tls/issues/10= 8) feedback would be very much welcomed. Please go ahead and check the di= scussions on the other issues of this version: https://github.com/core-wg= /coap-tcp-tls/milestone/4?closed=3D1 and on the changelog summary. In ad= dition to that, I would like to ask the group to let me know their curren= t implementation status of the draft for the shepherd writeup, especially= Open Source implementations of the draft. >=20 > latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tl= s-06 > diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-tcp-tl= s-06.txt > changelog: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#= appendix-C.4 >=20 > The WGLC will last one week, until 2017-02-22 . >=20 > Thanks! > Jaime Jim=C3=A9nez >=20 > ________________________________ > The information contained in this message may be confidential and legal= ly protected under applicable law. The message is intended solely for the= addressee(s). If you are not the intended recipient, you are hereby noti= fied that any use, forwarding, dissemination, or reproduction of this mes= sage is strictly prohibited and may be unlawful. If you are not the inten= ded recipient, please contact the sender by return e-mail and destroy all= copies of the original message. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --rM4t3lvUjtTjrBup6TI6AgDf9xI1410Xt-- --FeqeCCbnMEk1fPXhKW3P3H4n4EKsh4DiS 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYrEjVAAoJEGhJURNOOiAtpU4IAJ4k5NJkv/iXGHZKr+A9RLUs V/aWN63jLnzjkdG14qiuklBrt/sadrnDooRQ4wZgFm4RZtIniZKjM6bqUTL6ATgA cNY9HvkcIAAE7+AjfaX/u17ehWQUFt9cb1el1YbaAxehyhG4WRNOZ5k27eXuVpfq zy3UXvy/IRO3zPnfDwqgUFNHFNkj7PwQsi9hhCiFeM7j8+R6sSI3Mp2QHebEmjV5 4rXHOJapY8vQEP5sPusDUGEJ+/kDEYzeJj1N786/GNd2lKeVV/jxREA4Ka5TX8Nb REmNUikN2SAGl1kQVrDZn2EFfF6EGjYplaWXQ+yRVgtAnJm29rciarpy3Pbdqm8= =b0dU -----END PGP SIGNATURE----- --FeqeCCbnMEk1fPXhKW3P3H4n4EKsh4DiS-- From nobody Wed Feb 22 01:23:28 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65CB1296A4; Wed, 22 Feb 2017 01:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHhXxdvCz5Sf; Wed, 22 Feb 2017 01:23:23 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0139.outbound.protection.outlook.com [104.47.0.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DF112969C; Wed, 22 Feb 2017 01:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WhXVPjLSXXe5DjddnhiwbDFpruCbcwVCCyFtN1ZjsYg=; b=W/pqVJmAznulu3v4y53u8vgIgdAhlo+QebLPu1LjWW7F1E5sj3/gDSdO3AdRKj6P+rn+OG2lFEHiTQKxlc5+Yk3ziSWc8+DaqCyRIJq6/miopwi+BveFpvsOA/XSHP0lt+Br4LGDRL+/K3SYM5awgxk9q6qC46RvsOUaXa3FVIQ= Received: from HE1P122CA0004.EURP122.PROD.OUTLOOK.COM (2603:10a6:23:2::18) by DB5P122MB0023.EURP122.PROD.OUTLOOK.COM (2603:10a6:20:2::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Wed, 22 Feb 2017 09:23:19 +0000 Received: from AM1FFO11FD008.protection.gbl (2a01:111:f400:7e00::100) by HE1P122CA0004.outlook.office365.com (2603:10a6:23:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13 via Frontend Transport; Wed, 22 Feb 2017 09:23:20 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.228.36) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.228.36 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.228.36) by AM1FFO11FD008.mail.protection.outlook.com (10.174.64.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10 via Frontend Transport; Wed, 22 Feb 2017 09:23:19 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) by AM3PR90MB0099.MGDPHG.emi.philips.com (141.251.117.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 22 Feb 2017 09:23:19 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) by AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) with mapi id 15.01.0888.034; Wed, 22 Feb 2017 09:23:19 +0000 From: "Dijk, Esko" To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRs?= =?utf-8?Q?s_-_additional_comments?= Thread-Index: AdKM6nDt5cMs5HvrSgCpKqYuXQ1L7g== Date: Wed, 22 Feb 2017 09:23:19 +0000 Message-ID: <832633f9d14349e18a20fde166b2f95d@AM3PR90MB0097.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.122] X-MS-Office365-Filtering-Correlation-Id: 1e703bb6-8633-4794-ff49-08d45b0470d9 Content-Type: multipart/alternative; boundary="_000_832633f9d14349e18a20fde166b2f95dAM3PR90MB0097MGDPHGemip_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: AM3PR90MB0099.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.228.36; IPV:CAL; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39860400002)(39850400002)(39840400002)(2980300002)(377424004)(54534003)(55904004)(374574003)(199003)(85714005)(189002)(512874002)(84326002)(54896002)(81166006)(8936002)(81156014)(626004)(54906002)(38730400002)(110136004)(106466001)(69596002)(356003)(24736003)(105586002)(6246003)(229383001)(4326007)(2906002)(33646002)(7696004)(53936002)(66066001)(7736002)(50986999)(55016002)(86362001)(5660300001)(606005)(68736007)(790700001)(2900100001)(6916009)(236005)(230783001)(3846002)(6116002)(6306002)(102836003)(189998001)(54356999)(26826002)(97736004)(108616004)(7906003)(92566002)(229853002)(53546006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5P122MB0023; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD008; 1:LVKrH6j5DwEjvD8rWnC3G82GJFXskaXiIWsWhpFTl4C9nUxLtFTcl4QHcv9PN5HfMUwUnc3fUSbJliVSVvj7prXgsbV+Fe2ssCN/DZJCzs+ZTqRbSx4B8jqnSwCBn1f750v6QMPIfXUgA2xavmaPPpHdyem8828UbZNd+sR3Pvrdq0D2/D1h7J8PeXDKn7+l26BTecXjHBbzJoZq1fovQO6oPqhZEG7BduMjCWOdP99hjP+48vdArAmDrN9XRoaLMol3PluIoS7JxxzpIlG8ef+5vxa8UPSsuVvXyOjrgSyT7lLlFtuWXx6kJorMmM7kuV0bRUqFlhSgDoeUIjtWxUC0AcZ9F8PUVW8AaFiXtfEtv/msiLK3IGkH7XzaiTszFCmwbP06B9Cdfj62a+sVmdCND+bikFJHSlliFLuC5O7gX4hvTezRl7FCTxzL1QdpMWUq7vyuLFSKShW0OZHF2pS6Cs7J5JOKCOfTJHtjHUZUUOwjpDFDRE+Vn9x7axxe X-CrossPremisesHeadersPromoted: AM1FFO11FD008.protection.gbl X-CrossPremisesHeadersFiltered: AM1FFO11FD008.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5P122MB0023; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0023; 3:TWbNyq9y5QslytzbgreXbLaTqYStL+/k26r0/DO3yDls65zCscH5FS3lIXFSmVruAH40/mTNk0lQH2YTREzu3axHz6sSrVsdeHdVZ0W3Kf4XSJKc63JmuAwvVl8eh2PHx83a2tBDwAdnbzIAehNLocVrXRY+ULIop0rColxRwLVIvZsM9qEnhkLSMUGnNcwtQL6pRHQyBS6MP8LtnSElivRpsrv0vdUaz33P26AdaaxRfa0Fisge4hm/46crrQgWxRNxa1ZFDJ6HMVArg1uj3d53HHFaUrjnyuhVloTekIoGjcxblXg60W6kHPQxMdCoEBZpH1Ec40oMfHZq7zu7NKg5I52r5oj580sxLIPLDGM=; 25:MT9tmeZOXjLaGLJKaqp1OMWGViF6/FCN/3kB6XAQFmHLPq0BDvekx5/BXZXDz0yLuoCVkODhO/RO9vGOFASqYPT2aHr90bjZcNfVLUn9ZxbvFq6DCc2MF5CXN1bGyoMLY2OpKNwv0XFoItusuPl/Wk6m09t3GAjtjwfwO92ZhDBa8TZB4XRyYzFTfloSKvy8sOTfowQNXsnL97bL9hUd2KCagwT1o8P1UMgkbMs+lv3iGBK62j8XUtNQSiYEy+0l+8pu6iq+4yT1uUQ0YJh5RtTw/vBqGAKeYg2JnyOa1Gf5hyq0YVS7a/vbBYChTUF+kZh/Ih/Ano2ECLmoaDvgsqgpuZLXzQ21yQg755RsIb2rCy8sW0rQBomDwdCc/puliUL1qUl0LlPEAh/gxCPcJNxWXdqCThhtvlD5tqsLrUHpWghR1eYgGss8+iyjjlZE/lZgOj9ClsKjwh5LoL6WFw== X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0023; 31:WJf5R0W2eU8kzkbL+91Yr/aw1kkCxLXqRZts01nnAt8HO2c5ZYO2wiHh2bW6vHLQ6Zak/j7pFhj7jBTNeZ6q68ArEBftSPVTYzxzESxivkL17gwvsfalvmoD1D+OMDgWeet0GErlanO+/gbQxSbXbNu7i666NIj+bQQ7tV9jnqJGeS4GANkJu8kVDRAflve4d+1rZR/cc3Bg+Y24K8zPCarQSdC/LMH6Y98bbVwcBXRnCE88c8eHfr8D6Gfu+wunlm0ievlC3BeCWwPdbCMenQ==; 20:O38Bo/qVImJ5mgFzhekxJV6ywITiQfOlTM/DFwnKJWJG5khSWCVMu4Q8TC71eW2G5DG8V3dKA9iSEGgxouTE3iF60jbxRQmKvdFISBqRaYv21ccQ+jfmcgF4MrfBCfXpzfI4eci0J2LQBMHJLsZzZW+W6SWh27juDv6qHsBP8CWJ2gVyu1qdBmU8mvezdl0AZ5Q0Ru9p2AvGL+iOPg9ninSLQYx0kvMXiMhOZF2tHb8qm73k7uHG9ldNZk5ePl29GxBpRrRpYwARMpRUFR0U6wbSM/CWVfZZwebP7MErijjji91cJUWPygJo2n00sxRIfNDq1NSuKNMXSMMl3Tfd3CxHG2vREWeAZWPCPJuKjk2sGqqZzFj3deFankGUIYgnz7M8HcBwFdrWtrL+/LDLsxYFSfVl1cRRRcC7KZIPpdMoWyO/CgU7+mCsep2O02/qPSsgqKnMAilL606Z0tuPvpI5VP/KvafBL/Rk05JlQBquQBqEjqIzLJ9LzWdnmAGD X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(166708455590820)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(13023025)(13021025)(13013025)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DB5P122MB0023; BCL:0; PCL:0; RULEID:; SRVR:DB5P122MB0023; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0023; 4:q1BHpIuw0zYxNMNIESgS6bmUb0LHlKWB6FE28JkJl7g7YPbG2q1K9QN1DQqKNBf6Egv+uQmOOoDoBE4Jc8CW2UZ9Pu/bPutFbf2Jz38R4U3Gul6fZfEbUX3zI8rXkdi2+WTPu2qNWcuoLkAP1LZuSg75MJMHxli/Gbm++Fl5wb1H1V7i3U6Vz9On60gLUgO98vGvaIuudagEBc5IZSdEfnAP9LrtWRVrMLkifzRSEY7WA77r6PTNEgEj+97N2fNP0BwMNOm9EmzlWBu0HaUSlR9UuzEYW3bwFYYEAa46R67CixOeQViAgdgl1p8gT71/H5gmTmevK1P7HxDWAbptSu2Dletx51xo6PA2RHIidWkN2wL9lCTaPju4ojI2TmOUs0NUM+Lh9jsP48btmwP0PMXdn2sxr4Ha5Ra4eSIbDlnPTVAXbjJCX+4qqbHxIkFvIyJGuMTAhITcEEW+QaN139wNSGim1+jC4DFwDbwUw9PolM1k2byYWXxm1ZnBKPldIjERlmtQAIVSYhwZYJkBh/dPV2/imHpyX3FBnnzoM3wqTyw4c9Y7xzv20gMy7Qksgxez08rYx3BJamV1S7cRc99/0YvGpL+1eulTCcPF/43c6yd815VDrofFb1rqlDmwJFpbpzAw+pf2j3OPmdijfiotxnumsbHwdvmr/3+MzhGk78w9IeeTnBA7AykOZREICscBVhyZf1JnaRa5YoUsQyCOIP8eogNw7dgOaQrE+Hbr6O0zLWkVTUWuyNFAbr0bH5yLOwHInpoiLmsN5gtMVA== X-Forefront-PRVS: 022649CC2C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5P122MB0023; 23:pZt+nLLA+YQo7dwLVvbvaKdDh6Ue3J1g+T8JaRrQ6?= =?us-ascii?Q?YKnlMkJ8eJ0eLxYbq2SRhMzQ6Tu3WVzrSGbeOemQky00McmCACzFCeSO+M9S?= =?us-ascii?Q?IACSSEloj5HqkflXLNrQAVy44TftPmKI7f0PFnVnYvnYXJgJqStZLM2Kg1yO?= =?us-ascii?Q?1cAf9Kyl52WxzOljli/6mg8L8uo6hPuO56hqsztWq76OB0omwKuwOIwNVAF7?= =?us-ascii?Q?fAK06CeCOijFm5qPswx+xGYf2Qi5kfA65KAJ7K0VtWWwRAXEdSoLSC+WvegS?= =?us-ascii?Q?XRcU11EerbRi/cCq3xfC22/DZ7OykFt0yZpHYbUtOjlSwZIG4UeLYVg5NKnM?= =?us-ascii?Q?Kh1AeH8ja+CDCrlEsuu5P0F+/N3/uJ1ypESjKcYStwucGtwrYtGJTZUtzTV3?= =?us-ascii?Q?Fc23qMSQIl6ItyqlTfSvUHNwC51jGpoCpOXgV339NXqQTyKtlK6pnExfEi2v?= =?us-ascii?Q?ITSJpavFUsnGp97KYicluE46zgqseoZR6FtHL3GauNVx9G2ACnWP6HippEwO?= =?us-ascii?Q?7gVnX2FAa6i4pnJp+qM/uXdl+98hN2ZdIlJoLBl+j4Ig+Xho8BOSAaglDRSn?= =?us-ascii?Q?nc2be/zyxBCxe620CNKbs3BvFpk91OG6mCQWdiHOKS0bXoW/mXEPOVw10zDx?= =?us-ascii?Q?2yLPYUcpL7JrRWx4C6/rQCwJWqJVJROKKHWDDDDFvi8fWktPHoSAdMUm+Cwb?= =?us-ascii?Q?V1ELnHhGYFgR/JY/1byPbD/hmDZGopkfluDOplvRK/1RuT4kBRZ1GdajWOtB?= =?us-ascii?Q?oat67Xma6yxBpOcwWwZOmK7nJGdjlbq76LyEQmM2Gp0zp9bxGJRX2J/ygyb5?= =?us-ascii?Q?HBgaSxXtex9w8l/I7OdQnPD0uY2A5UulZ9T19AwCRCb1XJhmKlbBhkxU7+jK?= =?us-ascii?Q?F6Y9JXLtBu/5BGX3AkcVu4WxsMyOI8EW4MX41nIhONFi3GOX80rK5W3dqgqt?= =?us-ascii?Q?jVggLunUYguR8iUUt64SdGfRdFx1KKVXyfSUZ7esHDPJIsJRmHJkT4bkjfcx?= =?us-ascii?Q?445Htpa6uSrGNRWAxR3ne2/9GQDKcaLWbIc3TG4EblCVLZUuoQppK8DDUbsk?= =?us-ascii?Q?dtPDvgAfiIgAdZzS6p2qOOZ/W9vh3CoGmCRtYd7/yxXEPz+tMELLUmxNJGlt?= =?us-ascii?Q?cyd2pg3t5TE/hXqyIn2YOj3TfBaXvsMZ6TSkGAzFUbMg03iPHPn228KKAeqK?= =?us-ascii?Q?rKJTnVBsqrjLGxJp4RWN3snMhNTdS4ajQTjahQHNbn8kYOCcJATqjTSUODf4?= =?us-ascii?Q?Z5BZMqzD/1yy3BtZBZMD/LLv+f6OSi5l5t1JmoUKUzK/IBbNtxBuR/K4N6np?= =?us-ascii?Q?Q1+juTJ21504s25e3wOcqfPSqSoRKhjNPhNCq2ksryx1IGun+5oREB3rT72O?= =?us-ascii?Q?PCceoZqq48ey2e+Y5Ib1dJAv1R9s1lhcN3hDC0JIXoVbX3M9JBvu8AV5+j1o?= =?us-ascii?Q?kxSAtGEDVYZwwSNawBtdKoOPcjs2donxe+OERCsat0rlNpODr7M?= X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0023; 6:VozgDNg/wFHyjkToHq9WAa1wa3sDKeAq3/pXKIdaKwRuq0LaVm0dKlpCZs5q554PGCUauV061nLe8mRyhrJozHYjUuBzamcE5KfjhUQMIwnlq41HZ+Jr5prPVsNtiErfMLLj9Ca1ccZcbktNxzb2R6qZ6w930m/8I/vmsQzkDlGZq7izF2VSDlnEOfUsVvfnlI1TeQJ/Al7tXEOozTOF4eTezjsGe27ypxyfcegTmozvUjrk3XXHDEYJxI2omcMLsUeMlYIDR5HYkNW1UHLOKGYZqTSpi4Sabl473oVTO9Bic25wSgoeRY4X6Zb6UseQekFoWQBoG9xM4wYme1KosGCOuv6RiCOyDNP4VCSxLyTSEZPeYAURqJKs3npuR0MVG9oI+NRJwBm+EXayFWrWNhPTziLVtGcGW0st6F9cay8=; 5:sp3JKo/Ftq/VdlXZq2JjVqw8MZsiK8E4OhCT6dEKrQvR/qyjwoYYn6jDyDvrBpwKRSee6Gj1LZ1O18NLZkyGAP0mVeKyOtJCNt0ABiKZ3JIWgxp6mkxcUmcciK8AJVnC8JNAikRgeNXMaML+7Nq8Dhl/rxUcXdfADjPs3ZVmLBU=; 24:/djjhK6+po1FY/YdT5zQZ1+2T/DFBqNxpq6uEqrFNUsQa5Wb4Ffs63ZRzJDB/xtJw/t0IyAaU+eGnolRZk/xdBuW7HsLrNdXIFYZ6d/9roE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0023; 7:sWIldqbKodk0mZSRY4gs3g42ApYzLzJ/WZ75GWCwkougKQHqtoe3WRDTLJim3C9Bkxqpo9r0f87+94mydSdgNtlUsdi/GC9BLZsUtAkNeW+HHvHMVxMO2VE6oZxG53u6HXQCG5DYV2uik3R3jg8Bikq1A5gOw9bjjoaKCUkiCmJKE1iHXv0OLfHNgMAQ8EoWl62r5iBgTBciUeZrPV82vh30W66Y27iJpj26aMrJROfovOfb8pPah+OuRD6zrO2Wnqtw7PT2hqdIyv2FHkJkgB4SuNES53dJW6NNUixlWD94pI7VcJb5CIntLN9ctxSEEysOCMN8DIuX8o9cZzvBbA== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2017 09:23:19.6634 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.228.36]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5P122MB0023 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM3PR90MB0097.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 194.171.252.122 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: DB5P122MB0023.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls_-?= =?utf-8?q?_additional_comments?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 09:23:26 -0000 --_000_832633f9d14349e18a20fde166b2f95dAM3PR90MB0097MGDPHGemip_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UFM6IHR3byBtb3JlIHJldmlldyBjb21tZW50cyB0aGF0IHdlcmUgbm90IHlldCBpbmNsdWRlZCBp biBteSBmaXJzdCBlbWFpbDoNCg0KMS4gSW4gUkZDIDcyNTIsIHRoZSBSZXNldCBtZXNzYWdlIChS U1QpIGlzIGFsc28gdXNlZCB0byBkZWFsIHdpdGggY2VydGFpbiBjYXNlcyBvZiBtYWxmb3JtZWQg Q29BUCBtZXNzYWdlcyBvciBpbmNvcnJlY3QgZmllbGQgdmFsdWVzLiBTaW5jZSB0aGUgUlNUIG1l c3NhZ2UgaXMgbm93IHJlbW92ZWQsIEkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIHRleHQgb24gaG93 IHRvIGRlYWwgd2l0aCB0aGVzZSBjYXNlcy4gRm9yIGV4YW1wbGUgaW4gRmlndXJlIDIxIChSRkMg NzI1MikgdGhlIFRva2VuIHZhbHVlIGlzIG5vdCByZWNvZ25pemVkIHdoaWNoIGxlYWRzIHRvIGEg UlNULiBIb3cgc2hvdWxkIENvQVAtb3Zlci1yZWxpYWJsZSBkZWFsIHdpdGggdGhpcyBjYXNlIGFu ZCByZWxhdGVkIGNhc2VzPyAgQWx0aG91Z2ggdGhlIGRyYWZ0IHN1Z2dlc3RzIHRoYXQgQ2xpZW50 IChpZiB3ZSB0YWtlIHRoZSBGaWcgMjEgY2FzZSkgY291bGQgYWJvcnQgdGhlIGNvbm5lY3Rpb24s IHRoYXQgc291bmRzIHJhdGhlciBkcmFzdGljIGFuZCB1bm5lY2Vzc2FyeSDigJMgdGhlIGNsaWVu dCBhbmQgc2VydmVyIG5lZWQgdG8ga2VlcCB0YWxraW5nIHRvIGVhY2ggb3RoZXIgdHlwaWNhbGx5 LiBTaWxlbnRseSBpZ25vcmluZyBzZWVtcyBiZXR0ZXIgaW4gdGhhdCBjYXNlLiBBbmQgaW4gY2Fz ZSB0aGUgcmVjZWl2ZXIgb2YgYW4gJ2luY29ycmVjdCcgbWVzc2FnZSBkZWNpZGVzIG5vdCB0byBh Ym9ydCwgd2hhdCBzaG91bGQgaXQgZG8gaW5zdGVhZCDigJMgYW55dGhpbmcgbm9ybWF0aXZlPw0K UmVsYXRlZCBjYXNlcyBmb3IgQ29BUCBtZXNzYWdlIHJlY2VpdmVycyBhcmU6DQoNCi0gICAgICAg ICAgVG9rZW4gbm90IHJlY29nbml6ZWQgLT4gY291bGQgaGFwcGVuIGluIHRoZSBGaWd1cmUgMjEg dXNlIGNhc2UsIHNpbGVudGx5IGlnbm9yZSBzZWVtcyBiZXN0LiBPciB3b3VsZCB0aGVyZSBiZSBh IHJlYXNvbiB0byBub3RpZnkgdGhlIHJlc3BvbnNlIHNlbmRlciB0aGF0IHRoZSByZXNwb25zZSBp cyBub3QgcmVjb2duaXplZD8gKFJGQyA3MjUyIGFsbG93cyB0byBkbyB0aGlzIGF0IGxlYXN0LikN Cg0KLSAgICAgICAgICBUb2tlbiBMZW5ndGggVEtMIGlzIHdyb25nIChlLmcuIGxlbmd0aCBpcyA5 IHRvIDE1KSAtPiBjb3VsZCBiZSBzZW50IGJ5IGEgbWFsaWNpb3VzIENvQVAgZW5kcG9pbnQsIGdv b2QgcmVhc29uIHRvIGFib3J0IHBlcmhhcHMNCg0KLSAgICAgICAgICBDb2RlIHVucmVjb2duaXpl ZCAoZS5nLiAxLnh4LCAzLnh4LCAwLjMxIOKApiApIC0+IGNvdWxkIGhhcHBlbiBpZiBvbmUgb2Yg dGhlIGVuZHBvaW50cyBzdXBwb3J0cyBvdGhlci9uZXdlciBDb0FQIGZlYXR1cmVzLCBwZXJoYXBz IGFib3J0LCBvciBwZXJoYXBzIHNpbGVudGx5IGlnbm9yZT8gUG9zc2libHkgbWFsaWNpb3VzIGVu ZHBvaW50Lg0KU3VtbWFyaXppbmcgaXQgc2VlbXMgdG8gbWUgdGhlIGJlc3QgdG8gc3BlY2lmeSBh IHJlY2VpdmVyIE1BWSBhYm9ydCB0aGUgY29ubmVjdGlvbiBhbmQgYWxzbyBNVVNUIHNpbGVudGx5 IGlnbm9yZSB0aGUgbWFsZm9ybWVkIG1lc3NhZ2UuIFRoaXMgY291bGQgYmUgbWFkZSBtb3JlIGV4 cGxpY2l0IGluIHRoZSB0ZXh0Lg0KDQoyLiAgcy90b2tlbi9Ub2tlbi8gIC0+IGp1c3QgdG8gY29t cGx5IHdpdGggdGhlIFJGQyA3MjUyIG5vdGF0aW9uDQoNCkVza28NCg0KRnJvbTogY29yZSBbbWFp bHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphaW1lIEppbcOpbmV6DQpT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDEzOjE3DQpUbzogY29yZUBpZXRmLm9y ZyBXRyA8Y29yZUBpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzQGll dGYub3JnDQpTdWJqZWN0OiBbY29yZV0g8J+UlCBXR0xDIGRyYWZ0LWlldGYtY29yZS1jb2FwLXRj cC10bHMNCg0KRGVhciBDb1JFIFdHLA0KDQpUaGVyZSBoYXMgYmVlbiBxdWl0ZSBzb21lIHdvcmsg b24gdGhlICJDb0FQIChDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCkgb3ZlciBUQ1As IFRMUywgYW5kIFdlYlNvY2tldHPigJ0gZHJhZnQgKGRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10 bHMpIHNpbmNlIHRoZSBsYXN0IFdHTEMuDQpCSUcgdGhhbmtzIHRvIEJyaWFuIGZvciB0aGUgdGlt ZSBhbmQgZWZmb3J0IGRlZGljYXRlZCBhcyBFZGl0b3IuIEl0IG5vdyBzZWVtcyBhIGdvb2QgdGlt ZSBmb3IgYSBmaW5hbCBXR0xDIHRvIGdldCB0aGUgbGFzdCBjb21tZW50cyBmcm9tIHRoZSBncm91 cCBpbiBvcmRlciB0byBtb3ZlIHRoZSBzcGVjaWZpY2F0aW9uIGZvcndhcmQuDQoNCkluIHBhcnRp Y3VsYXIgdGhlcmUgaGFzIG5vdCBiZWVuIG11Y2ggZGlzY3Vzc2lvbiBvbiBzZWN1cmluZyBDb0FQ IG92ZXIgV2ViU29ja2V0cyAoaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxz L2lzc3Vlcy8xMDIpIGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3QgKGh0dHBzOi8vZ2l0 aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTA4KSBmZWVkYmFjayB3b3VsZCBi ZSB2ZXJ5IG11Y2ggd2VsY29tZWQuIFBsZWFzZSBnbyBhaGVhZCBhbmQgY2hlY2sgdGhlIGRpc2N1 c3Npb25zIG9uIHRoZSBvdGhlciBpc3N1ZXMgb2YgdGhpcyB2ZXJzaW9uOiBodHRwczovL2dpdGh1 Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvbWlsZXN0b25lLzQ/Y2xvc2VkPTEgIGFuZCBvbiB0 aGUgY2hhbmdlbG9nIHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0 byBhc2sgdGhlIGdyb3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRp b24gc3RhdHVzIG9mIHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFs bHkgT3BlbiBTb3VyY2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC4NCg0KbGF0ZXN0IHZl cnNpb246IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC10 Y3AtdGxzLTA2DQpkaWZmOiBodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2LnR4dA0KY2hhbmdlbG9nOiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNiNhcHBlbmRpeC1D LjQNCg0KVGhlIFdHTEMgd2lsbCBsYXN0IG9uZSB3ZWVrLCB1bnRpbCAyMDE3LTAyLTIyIC4NCg0K VGhhbmtzIQ0KSmFpbWUgSmltw6luZXoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25m aWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUg bWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9m IHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRo ZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBv cmlnaW5hbCBtZXNzYWdlLg0K --_000_832633f9d14349e18a20fde166b2f95dAM3PR90MB0097MGDPHGemip_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIFN5bWJv bCI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1s ZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDgxNDg1 Mzg4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxODA4 NTk2MDM0IC00Nzc5ODI0MzAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoyMC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU2LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDo5Mi4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjgu MjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE2NC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MjAwLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNi4yNXB0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjcyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDozMDguMjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5QUzogdHdvIG1vcmUgcmV2aWV3IGNvbW1lbnRzIHRoYXQgd2Vy ZSBub3QgeWV0IGluY2x1ZGVkIGluIG15IGZpcnN0IGVtYWlsOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xLiBJ biBSRkMgNzI1MiwgdGhlIFJlc2V0IG1lc3NhZ2UgKFJTVCkgaXMgYWxzbyB1c2VkIHRvIGRlYWwg d2l0aCBjZXJ0YWluIGNhc2VzIG9mIG1hbGZvcm1lZCBDb0FQIG1lc3NhZ2VzIG9yIGluY29ycmVj dCBmaWVsZCB2YWx1ZXMuIFNpbmNlIHRoZSBSU1QgbWVzc2FnZSBpcyBub3cgcmVtb3ZlZCwNCiBJ IHRoaW5rIHRoZXJlIHNob3VsZCBiZSB0ZXh0IG9uIGhvdyB0byBkZWFsIHdpdGggdGhlc2UgY2Fz ZXMuIEZvciBleGFtcGxlIGluIEZpZ3VyZSAyMSAoUkZDIDcyNTIpIHRoZSBUb2tlbiB2YWx1ZSBp cyBub3QgcmVjb2duaXplZCB3aGljaCBsZWFkcyB0byBhIFJTVC4gSG93IHNob3VsZCBDb0FQLW92 ZXItcmVsaWFibGUgZGVhbCB3aXRoIHRoaXMgY2FzZSBhbmQgcmVsYXRlZCBjYXNlcz8gJm5ic3A7 QWx0aG91Z2ggdGhlIGRyYWZ0IHN1Z2dlc3RzIHRoYXQNCiBDbGllbnQgKGlmIHdlIHRha2UgdGhl IEZpZyAyMSBjYXNlKSBjb3VsZCBhYm9ydCB0aGUgY29ubmVjdGlvbiwgdGhhdCBzb3VuZHMgcmF0 aGVyIGRyYXN0aWMgYW5kIHVubmVjZXNzYXJ5IOKAkyB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgbmVl ZCB0byBrZWVwIHRhbGtpbmcgdG8gZWFjaCBvdGhlciB0eXBpY2FsbHkuIFNpbGVudGx5IGlnbm9y aW5nIHNlZW1zIGJldHRlciBpbiB0aGF0IGNhc2UuIEFuZCBpbiBjYXNlIHRoZSByZWNlaXZlciBv ZiBhbiAnaW5jb3JyZWN0Jw0KIG1lc3NhZ2UgZGVjaWRlcyBub3QgdG8gYWJvcnQsIHdoYXQgc2hv dWxkIGl0IGRvIGluc3RlYWQg4oCTIGFueXRoaW5nIG5vcm1hdGl2ZT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlbGF0ZWQgY2Fz ZXMgZm9yIENvQVAgbWVzc2FnZSByZWNlaXZlcnMgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ub2tlbiBub3QgcmVj b2duaXplZCAtJmd0OyBjb3VsZCBoYXBwZW4gaW4gdGhlIEZpZ3VyZSAyMSB1c2UgY2FzZSwgc2ls ZW50bHkgaWdub3JlIHNlZW1zIGJlc3QuIE9yIHdvdWxkIHRoZXJlIGJlIGEgcmVhc29uIHRvIG5v dGlmeSB0aGUgcmVzcG9uc2Ugc2VuZGVyIHRoYXQgdGhlIHJlc3BvbnNlDQogaXMgbm90IHJlY29n bml6ZWQ/IChSRkMgNzI1MiBhbGxvd3MgdG8gZG8gdGhpcyBhdCBsZWFzdC4pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDoyMC4yNXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRv a2VuIExlbmd0aCBUS0wgaXMgd3JvbmcgKGUuZy4gbGVuZ3RoIGlzIDkgdG8gMTUpIC0mZ3Q7IGNv dWxkIGJlIHNlbnQgYnkgYSBtYWxpY2lvdXMgQ29BUCBlbmRwb2ludCwgZ29vZCByZWFzb24gdG8g YWJvcnQgcGVyaGFwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db2RlIHVucmVjb2duaXplZCAoZS5nLiAxLnh4LCAzLnh4 LCAwLjMxIOKApiApIC0mZ3Q7IGNvdWxkIGhhcHBlbiBpZiBvbmUgb2YgdGhlIGVuZHBvaW50cyBz dXBwb3J0cyBvdGhlci9uZXdlciBDb0FQIGZlYXR1cmVzLCBwZXJoYXBzIGFib3J0LCBvciBwZXJo YXBzIHNpbGVudGx5IGlnbm9yZT8NCiBQb3NzaWJseSBtYWxpY2lvdXMgZW5kcG9pbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5T dW1tYXJpemluZyBpdCBzZWVtcyB0byBtZSB0aGUgYmVzdCB0byBzcGVjaWZ5IGEgcmVjZWl2ZXIg TUFZIGFib3J0IHRoZSBjb25uZWN0aW9uIGFuZCBhbHNvIE1VU1Qgc2lsZW50bHkgaWdub3JlIHRo ZSBtYWxmb3JtZWQgbWVzc2FnZS4gVGhpcyBjb3VsZCBiZSBtYWRlIG1vcmUgZXhwbGljaXQgaW4N CiB0aGUgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Mi4gJm5ic3A7cy90b2tlbi9Ub2tlbi8mbmJzcDsg LSZndDsganVzdCB0byBjb21wbHkgd2l0aCB0aGUgUkZDIDcyNTIgbm90YXRpb24NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Fc2tvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gY29yZSBbbWFpbHRvOmNv cmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFpbWUgSmltw6luZXo8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyAxMzoxNzxicj4N CjxiPlRvOjwvYj4gY29yZUBpZXRmLm9yZyBXRyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5DYzo8L2I+IGRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW2NvcmVdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjgy NzY7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFdHTEMgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNw LXRsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EZWFyIENvUkUgV0csPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZXJlIGhhcyBiZWVuIHF1aXRlIHNvbWUgd29yayBvbiB0aGUgJnF1b3Q7 Q29BUCAoQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wpIG92ZXIgVENQLCBUTFMsIGFu ZCBXZWJTb2NrZXRz4oCdIGRyYWZ0IChkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzKSBzaW5j ZSB0aGUgbGFzdCBXR0xDLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QklHIHRoYW5rcyB0byBCcmlhbiBmb3IgdGhlIHRpbWUgYW5kIGVm Zm9ydCBkZWRpY2F0ZWQgYXMgRWRpdG9yLiBJdCBub3cgc2VlbXMgYSBnb29kIHRpbWUgZm9yIGEg ZmluYWwgV0dMQyB0byBnZXQgdGhlIGxhc3QgY29tbWVudHMgZnJvbSB0aGUgZ3JvdXAgaW4gb3Jk ZXIgdG8gbW92ZSB0aGUgc3BlY2lmaWNhdGlvbiBmb3J3YXJkLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwYXJ0aWN1bGFyIHRo ZXJlIGhhcyBub3QgYmVlbiBtdWNoIGRpc2N1c3Npb24gb24gc2VjdXJpbmcgQ29BUCBvdmVyIFdl YlNvY2tldHMgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRs cy9pc3N1ZXMvMTAyIj5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNz dWVzLzEwMjwvYT4pIGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3QgKDxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTA4Ij5odHRwczov L2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEwODwvYT4pDQogZmVlZGJh Y2sgd291bGQgYmUgdmVyeSBtdWNoIHdlbGNvbWVkLiBQbGVhc2UgZ28gYWhlYWQgYW5kIGNoZWNr IHRoZSBkaXNjdXNzaW9ucyBvbiB0aGUgb3RoZXIgaXNzdWVzIG9mIHRoaXMgdmVyc2lvbjombmJz cDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvbWlsZXN0 b25lLzQ/Y2xvc2VkPTEiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9t aWxlc3RvbmUvND9jbG9zZWQ9MTwvYT4mbmJzcDsmbmJzcDthbmQNCiBvbiB0aGUgY2hhbmdlbG9n IHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0byBhc2sgdGhlIGdy b3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gc3RhdHVzIG9m IHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFsbHkgT3BlbiBTb3Vy Y2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxhdGVzdCB2ZXJzaW9uOiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29h cC10Y3AtdGxzLTA2Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LWNvYXAtdGNwLXRscy0wNjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlmZjombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2LnR4 dCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNv YXAtdGNwLXRscy0wNi50eHQ8L2E+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jaGFuZ2Vsb2c6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDYjYXBwZW5k aXgtQy40Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAt dGNwLXRscy0wNiNhcHBlbmRpeC1DLjQ8L2E+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBXR0xDIHdpbGwgbGFzdCBvbmUgd2Vl aywgdW50aWwmbmJzcDs8Yj4yMDE3LTAyLTIyPC9iPiAuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphaW1lIEppbcOpbmV6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJp YWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRl ciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg YWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZA0KIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5h dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJp dGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVz dHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLjxicj4NCjwvZm9udD4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_832633f9d14349e18a20fde166b2f95dAM3PR90MB0097MGDPHGemip_-- From nobody Thu Feb 23 16:36:58 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878D2129D13 for ; Thu, 23 Feb 2017 16:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfnyCUJE9TCY for ; Thu, 23 Feb 2017 16:36:56 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (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 166F4129CFD for ; Thu, 23 Feb 2017 16:36:55 -0800 (PST) Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:54974 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ch3sT-003cUy-Ib for core@ietf.org; Fri, 24 Feb 2017 11:36:53 +1100 References: <148765205970.26029.7456261335683678446.idtracker@ietfa.amsl.com> To: core From: Christian Groves X-Forwarded-Message-Id: <148765205970.26029.7456261335683678446.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 24 Feb 2017 11:36:47 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148765205970.26029.7456261335683678446.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [core] Fwd: New Version Notification for draft-groves-core-obsattr-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 00:36:57 -0000 Hello FYI, I've submitted a draft introducing several new binding and observe attributes: o Initialization Value (iv) o Notification Band Minimum (bmn) o Notification Band Maximum (bmx) o Band Step (bst) o Sample Number Window (snw) o Sample Time Window (stw) If people think these are valuable then the goal would be to add them to draft-ietf-core-dynlink. Comments? Regards, Christian -------- Forwarded Message -------- Subject: New Version Notification for draft-groves-core-obsattr-00.txt Date: Mon, 20 Feb 2017 20:40:59 -0800 From: internet-drafts@ietf.org To: Christian Groves , Christian Groves , Weiwei Yang A new version of I-D, draft-groves-core-obsattr-00.txt has been successfully submitted by Christian Groves and posted to the IETF repository. Name: draft-groves-core-obsattr Revision: 00 Title: Additional CoAP Binding and Observe Attributes Document date: 2017-02-21 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-groves-core-obsattr-00.txt Status: https://datatracker.ietf.org/doc/draft-groves-core-obsattr/ Htmlized: https://tools.ietf.org/html/draft-groves-core-obsattr-00 Abstract: [I-D.ietf-core-dynlink] defines five CoAP Observaton attributes (minimum period, maximum period, band step, less than and greater than) to control when notifications are sent. These attributes are insufficient for some use cases. This document specifies additional attributes allowing for notification bands, initialization values, band step, sample number window and sample time window to allow for a wider range of use cases. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat . From nobody Thu Feb 23 16:42:56 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B6F129977 for ; Thu, 23 Feb 2017 16:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjY3_BhAYwTz for ; Thu, 23 Feb 2017 16:42:54 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (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 E1B9E1293F8 for ; Thu, 23 Feb 2017 16:42:53 -0800 (PST) Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:55140 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ch3yG-003crq-31 for core@ietf.org; Fri, 24 Feb 2017 11:42:52 +1100 References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: core From: Christian Groves X-Forwarded-Message-Id: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> Message-ID: <12768758-039e-0a14-eb5a-511a9489e0c7@gmail.com> Date: Fri, 24 Feb 2017 11:42:46 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [core] Fwd: New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 00:42:55 -0000 Hello all, FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources. It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned. There's also a discussion of a more complex use case utilising the FETCH method. Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink. Comments? Regards, Christian -------- Forwarded Message -------- Subject: New Version Notification for draft-groves-core-bas-00.txt Date: Mon, 20 Feb 2017 20:41:27 -0800 From: internet-drafts@ietf.org To: Christian Groves , Christian Groves , Weiwei Yang A new version of I-D, draft-groves-core-bas-00.txt has been successfully submitted by Christian Groves and posted to the IETF repository. Name: draft-groves-core-bas Revision: 00 Title: Binding Attribute Scope Document date: 2017-02-21 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 Abstract: This document specifies an additional CoAP binding attribute that allows binding attributes to be scoped to an item (sub-resource) in a collection resource. This allows synchronisation of multiple resources in a collection based on the value of one resource. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat . From nobody Thu Feb 23 19:44:54 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 820CE1294FB; Thu, 23 Feb 2017 19:44:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148790788852.21060.624486718753254690.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 19:44:48 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-dynlink-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:44:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Dynamic Resource Linking for Constrained RESTful Environments Authors : Zach Shelby Matthieu Vial Michael Koster Christian Groves Filename : draft-ietf-core-dynlink-02.txt Pages : 16 Date : 2017-02-23 Abstract: For CoAP [RFC7252] Dynamic linking of state updates between resources, either on an endpoint or between endpoints, is defined with the concept of Link Bindings. This specification defines conditional observation attributes that work with Link Bindings or with CoAP Observe [RFC7641]. Editor's note: o The git repository for the draft is found at https://github.com/ core-wg/dynlink The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-dynlink-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 23 19:47:26 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B4B12951A for ; Thu, 23 Feb 2017 19:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZsgvTegWqBr for ; Thu, 23 Feb 2017 19:47:23 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (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 632B41294FB for ; Thu, 23 Feb 2017 19:47:23 -0800 (PST) Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:61798 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ch6qn-003sHi-3q for core@ietf.org; Fri, 24 Feb 2017 14:47:21 +1100 To: core@ietf.org References: <148790788852.21060.624486718753254690.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: <4a36c7cc-21a0-c960-9c37-220ea4b9d79f@gmail.com> Date: Fri, 24 Feb 2017 14:47:14 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148790788852.21060.624486718753254690.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-dynlink-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 03:47:25 -0000 Hello all, FYI, the changes in the draft are: o General: Changed the name of the greater than attribute "gt" to "gth" and the name of the less than attribute "lt" to "lth" due to conlict with the core resource directory draft lifetime "lt" attribute. o Clause 6.1: Addressed the editor's note by changing the link target attribute to "core.binding". o AddedAppendix A for examples. Regards, Christian On 24/02/2017 2:44 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Constrained RESTful Environments of the IETF. > > Title : Dynamic Resource Linking for Constrained RESTful Environments > Authors : Zach Shelby > Matthieu Vial > Michael Koster > Christian Groves > Filename : draft-ietf-core-dynlink-02.txt > Pages : 16 > Date : 2017-02-23 > > Abstract: > For CoAP [RFC7252] Dynamic linking of state updates between > resources, either on an endpoint or between endpoints, is defined > with the concept of Link Bindings. This specification defines > conditional observation attributes that work with Link Bindings or > with CoAP Observe [RFC7641]. > > Editor's note: > > o The git repository for the draft is found at https://github.com/ > core-wg/dynlink > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-core-dynlink-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Thu Feb 23 20:27:32 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB3E129512; Thu, 23 Feb 2017 20:27:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148791045110.21198.3283159343612525771.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 20:27:31 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-interfaces-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 04:27:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Reusable Interface Definitions for Constrained RESTful Environments Authors : Zach Shelby Matthieu Vial Michael Koster Christian Groves Filename : draft-ietf-core-interfaces-08.txt Pages : 27 Date : 2017-02-23 Abstract: This document defines a set of Constrained RESTful Environments (CoRE) Link Format Interface Descriptions [RFC6690] applicable for use in constrained environments. These include the: Actuator, Paramter, Read-only parameter, Sensor, Batch, Linked Batch and Link List interfaces. The Batch, Linked Batch and Link List interfaces make use of resource collections. This document further describes how collections relate to interfaces. Many applications require a set of interface descriptions in order provide the required functionality. This document defines the concept of function sets to specify this set of interfaces and resources. _Editor's note: The git repository for the draft is found at https://github.com/core-wg/interfaces_ The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-interfaces-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 23 20:29:37 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DA412950E for ; Thu, 23 Feb 2017 20:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twNowFBzNhVf for ; Thu, 23 Feb 2017 20:29:24 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (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 CC58B129512 for ; Thu, 23 Feb 2017 20:29:23 -0800 (PST) Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:63177 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ch7VR-003vq8-V2 for core@ietf.org; Fri, 24 Feb 2017 15:29:22 +1100 To: core@ietf.org References: <148791045110.21198.3283159343612525771.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: Date: Fri, 24 Feb 2017 15:29:15 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148791045110.21198.3283159343612525771.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-interfaces-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 04:29:27 -0000 Hello all, FYI, the changes from -07 to 08: are: o Section 3.3: Modified Accepts to Accept header option. o Addressed the editor's note in Section 4.1 to clarify the use of the Accept option. Regards, Christian On 24/02/2017 3:27 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Constrained RESTful Environments of the IETF. > > Title : Reusable Interface Definitions for Constrained RESTful Environments > Authors : Zach Shelby > Matthieu Vial > Michael Koster > Christian Groves > Filename : draft-ietf-core-interfaces-08.txt > Pages : 27 > Date : 2017-02-23 > > Abstract: > This document defines a set of Constrained RESTful Environments > (CoRE) Link Format Interface Descriptions [RFC6690] applicable for > use in constrained environments. These include the: Actuator, > Paramter, Read-only parameter, Sensor, Batch, Linked Batch and Link > List interfaces. > > The Batch, Linked Batch and Link List interfaces make use of resource > collections. This document further describes how collections relate > to interfaces. > > Many applications require a set of interface descriptions in order > provide the required functionality. This document defines the > concept of function sets to specify this set of interfaces and > resources. > > _Editor's note: The git repository for the draft is found at > https://github.com/core-wg/interfaces_ > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-core-interfaces-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Fri Feb 24 06:48:10 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9301293E9 for ; Fri, 24 Feb 2017 06:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFXq8BBs-28o for ; Fri, 24 Feb 2017 06:48:07 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 8AE5D1296AB for ; Fri, 24 Feb 2017 06:42:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,201,1484002800"; d="scan'208";a="214613619" Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2017 15:42:27 +0100 From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <292A2675-FB3D-4D0D-87BC-EC784C327C4B@inria.fr> Date: Fri, 24 Feb 2017 15:42:27 +0100 To: core@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [core] Stateless-Proxy option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 14:48:08 -0000 Dear Core, As part of the work on bootstrapping in 6TiSCH working group, we are = using CoAP proxying functionality to facilitate communication between a = new node (pledge) and the Registrar. The pledge does not have global = I=10Pv6 connectivity at the time of the join so it communicates over = link-local addresses with a potentially constrained one hop neighbor = that acts as a CoAP proxy. Note that in this scenario a constrained proxy implements = forwardng-related options but does not necessarily need to implement a = cache. To relay the response back to the client, the proxy needs to keep some = state, such as IPv6 address of the client, port number and at CoAP level = the token. With limited memory, this opens up a constrained proxy to a = potential DoS attack by unauthenticated pledges.=20 One solution that we have discussed is to register a new option, = Stateless-Proxy option, that could be used by a proxy to add en-route = the state information needed for its operation. State information would = be opaque to the server who would need to echo it back in the response. Your feedback would be most welcome. Regards, Mali=C5=A1a Vu=C4=8Dini=C4=87 From nobody Fri Feb 24 08:52:57 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079B2128BA2 for ; Fri, 24 Feb 2017 08:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUvXJkmkji3J for ; Fri, 24 Feb 2017 08:52:47 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612061288B8 for ; Fri, 24 Feb 2017 08:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1OGqiZP000896 for ; Fri, 24 Feb 2017 17:52:44 +0100 (CET) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vVHGN2LcxzDH07 for ; Fri, 24 Feb 2017 17:52:44 +0100 (CET) Received: by mail-it0-f48.google.com with SMTP id 203so27373815ith.0 for ; Fri, 24 Feb 2017 08:52:44 -0800 (PST) X-Gm-Message-State: AMke39kxESDSzQ+jj958vMV/cypAmb1pHWzVxrg/H64NDScHc1c/64zq7j+poqwTnFHwD20WENfsDR/3NFY7Cg== X-Received: by 10.107.146.138 with SMTP id u132mr3732241iod.173.1487955162844; Fri, 24 Feb 2017 08:52:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.27.203 with HTTP; Fri, 24 Feb 2017 08:52:02 -0800 (PST) In-Reply-To: <292A2675-FB3D-4D0D-87BC-EC784C327C4B@inria.fr> References: <292A2675-FB3D-4D0D-87BC-EC784C327C4B@inria.fr> From: Klaus Hartke Date: Fri, 24 Feb 2017 17:52:02 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Stateless-Proxy option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 16:52:56 -0000 Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > To relay the response back to the client, the proxy needs to keep some st= ate, such as IPv6 address of the client, port number and at CoAP level the = token. With limited memory, this opens up a constrained proxy to a potentia= l DoS attack by unauthenticated pledges. > > One solution that we have discussed is to register a new option, Stateles= s-Proxy option, that could be used by a proxy to add en-route the state inf= ormation needed for its operation. State information would be opaque to the= server who would need to echo it back in the response. This is something that was actually discussed during the development of RFC 7252: storing actual state in the Token, which *is* state information that is opaque to the server and echoed back in the response. The idea was dropped, however, for security reasons (IIRC): If the information is not only a state identifier but encodes the state itself, then the server gains the ability to create arbitrary state at the client (or proxy in the role of a client). While the client/proxy may trust the server to properly process the request it sends, this doesn't mean that the (potentially subtly compromised) server can be trusted not to temper with the state information that it echoes back. So there needs to be at least an authentication tag, replay detection, etc. This might become more complicated and costly than just storing a bit of state at the client/proxy. Another issue that interferes with a stateless proxy is that a proxy in general needs to keep state for each client not only to pass a response back, but also to properly react to request retransmissions, to (re-)transmit separate responses, to perform congestion control, to return 5.04 timeout errors, etc. It is almost never the case that a proxy can simply receive a message, make some stateless modifications, and pass it on to the next hop. If you're thinking about (accidental or deliberate) DoS attacks, then you're on the right track. But this needs more thinking; a Stateless-Proxy option doesn't quickly solve the problem. Klaus From nobody Fri Feb 24 13:52:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB528129513 for ; Fri, 24 Feb 2017 13:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6tW-urjXkek for ; Fri, 24 Feb 2017 13:52:08 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 463B61294F8 for ; Fri, 24 Feb 2017 13:52:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 2542569AE; Fri, 24 Feb 2017 22:52:06 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gJ5TYGifW6Hj; Fri, 24 Feb 2017 22:52:06 +0100 (CET) Received: from [192.168.1.206] (40.red-81-33-45.dynamicip.rima-tde.net [81.33.45.40]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon23.um.es (Postfix) with ESMTPSA id 6C68969A4; Fri, 24 Feb 2017 22:52:03 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_899E9593-6F6C-4313-884A-313A76F3F05C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= In-Reply-To: <292A2675-FB3D-4D0D-87BC-EC784C327C4B@inria.fr> Date: Fri, 24 Feb 2017 22:52:02 +0100 Message-Id: <0959EA1E-BA91-4D17-A2C7-893326484BBE@um.es> References: <292A2675-FB3D-4D0D-87BC-EC784C327C4B@inria.fr> To: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: core@ietf.org Subject: Re: [core] Stateless-Proxy option X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 21:52:11 -0000 --Apple-Mail=_899E9593-6F6C-4313-884A-313A76F3F05C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mali=C5=A1a: In our draft marin-ace-wg-coap-eap we propose the concept of CoAP relay = for the bootstrapping phase. We currently have an implementation of the = concept of CoAP relay. The next step we are working on is the CoAP = stateless proxy.=20 If you have any comments, please let us know.=20 Best Regards, Dan.=20 > El 24 feb 2017, a las 15:42, Mali=C5=A1a Vu=C4=8Dini=C4=87 = escribi=C3=B3: >=20 > Dear Core, >=20 > As part of the work on bootstrapping in 6TiSCH working group, we are = using CoAP proxying functionality to facilitate communication between a = new node (pledge) and the Registrar. The pledge does not have global = I=10Pv6 connectivity at the time of the join so it communicates over = link-local addresses with a potentially constrained one hop neighbor = that acts as a CoAP proxy. >=20 > Note that in this scenario a constrained proxy implements = forwardng-related options but does not necessarily need to implement a = cache. >=20 > To relay the response back to the client, the proxy needs to keep some = state, such as IPv6 address of the client, port number and at CoAP level = the token. With limited memory, this opens up a constrained proxy to a = potential DoS attack by unauthenticated pledges.=20 >=20 > One solution that we have discussed is to register a new option, = Stateless-Proxy option, that could be used by a proxy to add en-route = the state information needed for its operation. State information would = be opaque to the server who would need to echo it back in the response. >=20 > Your feedback would be most welcome. >=20 > Regards, > Mali=C5=A1a Vu=C4=8Dini=C4=87 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_899E9593-6F6C-4313-884A-313A76F3F05C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Mali=C5=A1a:

In our draft marin-ace-wg-coap-eap we propose the concept of CoAP relay = for the bootstrapping phase. We currently have an = implementation of the concept of CoAP relay. The next step we are = working on is the CoAP stateless proxy. 

If you have any comments, please let us = know. 
Best Regards,
Dan. 





El = 24 feb 2017, a las 15:42, Mali=C5=A1a Vu=C4=8Dini=C4=87 <malisa.vucinic@inria.fr> escribi=C3=B3:

Dear = Core,

As part of the work on bootstrapping = in 6TiSCH working group, we are using CoAP proxying functionality to = facilitate communication between a new node (pledge) and the Registrar. = The pledge does not have global I=10Pv6 connectivity at the time of the = join so it communicates over link-local addresses with a potentially = constrained one hop neighbor that acts as a CoAP proxy.

Note that in this scenario a constrained proxy implements = forwardng-related options but does not necessarily need to implement a = cache.

To relay the response back to the = client, the proxy needs to keep some state, such as IPv6 address of the = client, port number and at CoAP level the token. With limited memory, = this opens up a constrained proxy to a potential DoS attack by = unauthenticated pledges.

One solution that = we have discussed is to register a new option, Stateless-Proxy option, = that could be used by a proxy to add en-route the state information = needed for its operation. State information would be opaque to the = server who would need to echo it back in the response.

Your feedback would be most welcome.

Regards,
Mali=C5=A1a Vu=C4=8Dini=C4=87


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

= --Apple-Mail=_899E9593-6F6C-4313-884A-313A76F3F05C-- From nobody Sat Feb 25 03:59:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5604E129E53 for ; Sat, 25 Feb 2017 03:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KslEdTFKw_52 for ; Sat, 25 Feb 2017 03:59:51 -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 6A094129D64 for ; Sat, 25 Feb 2017 03:59:50 -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 79AA1465FC; Sat, 25 Feb 2017 12:59:48 +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 E53571B2; Sat, 25 Feb 2017 12:59:46 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A3EC446; Sat, 25 Feb 2017 12:59:46 +0100 (CET) Received: (nullmailer pid 14120 invoked by uid 1000); Sat, 25 Feb 2017 11:59:45 -0000 Date: Sat, 25 Feb 2017 12:59:45 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Message-ID: <20170225115945.jmt27dq6dbe2e7p5@hephaistos.amsuess.com> References: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3n36mwybyicopgso" Content-Disposition: inline In-Reply-To: <8673C31D-2944-4832-8A9F-185D081B12EC@tzi.org> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Default values for Uri-Host with alternate transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Feb 2017 11:59:53 -0000 --3n36mwybyicopgso Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi & sorry for being late to the party, for the forward cases, I could well live with Uri-Host being forbidden[1] on transports that have an established default host name (especially since those tend to be those where that default host name is verified cryptographically); at least, clients should be prepared for hosts to go 4.03 on requests for other virtual hosts on a connection where another host name was verified. [1]: unless used in connection with Uri-Scheme On Sat, Feb 04, 2017 at 10:44:17AM +0100, Carsten Bormann wrote: > Still, it is very useful for the CoAP endpoint at > the WebSocket server to call back the CoAP endpoint at the Websocket > client, even if that is based on "You, whoever just called me"". But > we don't have anonymous, ephemeral hosts in URIs. Yet. The reverse case is more interesting to me, because it crops up in deployment. (Where I'm encountering it is when a node is registering with an RD from inside NAT). URIs AFAIK do not support ephemeral identifiers -- but do we need any? Protocols right now mostly do provide defaults. They might be unusable globally, eg. coap+tcp://${ip}:${high_port}, coap+sms://${number}, coap+serial://com2 or maybe even coap+ws://${ip}:${high_port}, but they are sufficient inside the application to parse responses. (I'll use "application" for the side roughly synonymously with the acceptor side her, ie. he who talks to a nameless one). The problem arises when any of those addresses should be passed on outside of the application. There, guidance for implementors might be what we need rather than a protocol solution. Once the application has identified which URIs are not usable globally (and than can be tricky), a process similar to RDF's skolemization[2] could be applied. Unless there is indication of a proper host name to use (eg. using protocol-negotiation -- Bill, how's that coming along?) and can be verified, the application would need to either mint a hostname it can claim in DNS to furtheron be forward proxy for, or mint a hostname it can at least be sure to be unique and unresolvable. [2]: https://www.w3.org/TR/rdf11-concepts/#section-skolemization An additional problem implementing this is that it might not be immediately obvious whether the default address is usable at all. While it is clear in the WebSocket case that nobody outside the WebSocket server can contact the client directly, an incoming UDP packet might or might not have been NATted. Do you know of any idea on how to clear that up, short of having a third party try? For some protocols, the address might be globally unique but accessibility not widespread (eg. coap+sms), so maybe both passing on the address and an equivalent one (again, protocol-negotiation) could be an option. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --3n36mwybyicopgso Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlixcasACgkQOY0REtOk veEgzQ/9GkoBIzM6HsuX3bkc9cyFWOV/f4QavV9WUSNWezc2/UcsB/9V8DGk6q2c rglMDoL0hB4WJGylqqEe8ucSzU6f3HZrjLpjX4vzux1xi/xejc2GUrpUHpfbTQ+T xY3KvR8GbdI/FqETV4zTs+s5vGEOXQ7rTMRqf0LLiuJu3lHhxUx+Ju7MAV9JwwNp fczfWX7LVHLexoUaRk3jn4pQl/3UULWC9jd9tO8bb1qyGoTqwSIH6UVqKHxuceyO hjLFVfx9jTyXwyN2i1tqcOn73zd1145FAUJaUC6RYkAMCBOTDszMCCMsMY9UKosU V+V+O5cM9dRnK0k6ZuRWjRCpgxtkrMQUOUGhGPeClO7pdfJqw+Kdbp07YgyPU7NU Y882w4chpCJHaSOzG9GA+Ps0t0aTPQzMV6HCDi5/AIL1Dj3scvwb7lSXphrwrq9o GOBJozy/GH1nfPYRjvK9lgBArRNjUFhRmAyH3ugtxuYMcV7KdoeN9aayo7w0svFz AzzOdbhwlwR66e1dA9YRVCWqDjsKvjbaODqxmOVN6HOamytguvosGvbeUoz8AjmZ zXTz51eF/UArr71D0ImoB8HCHJ5fZKXfWuBgbI7JsOn9wsykSLut7fC7SRpKSyYg Pi9bhSPmRD/4I/30MbvB/5Vw7iQ+grj/1KvuOJ2r97k3QcMZKMs= =ILsx -----END PGP SIGNATURE----- --3n36mwybyicopgso-- From nobody Sat Feb 25 08:34:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE24F12A16D for ; Sat, 25 Feb 2017 08:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyCJHkhQvklW for ; Sat, 25 Feb 2017 08:34:16 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 2DB3C12A16A for ; Sat, 25 Feb 2017 08:34:16 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 2C1D685D7E950 for ; Sat, 25 Feb 2017 16:34:12 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id v1PGYE1O013205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 25 Feb 2017 16:34:14 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id v1PGYDj0003166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 25 Feb 2017 16:34:13 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0301.000; Sat, 25 Feb 2017 11:34:13 -0500 From: "Carey, Timothy (Nokia - US)" To: "core@ietf.org WG" Thread-Topic: Binding Attributes in draft-groves-core-dynlink-02 Thread-Index: AdKPhIJ5tHWhI/SMR/S1s5vXPdBMHQ== Date: Sat, 25 Feb 2017 16:34:12 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A864782@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A864782US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [core] Binding Attributes in draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Feb 2017 16:34:17 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A864782US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I noticed in the latest draft the binding attributes were changed. The LWM2M uses the binding attributes in their specification that was recen= tly published. In LWM2M Greater than is gt; Less than is lt and Step is stp. In the latest dynlink draft Greater than is gth; Less than is lth and Step = is st Do we know the reason for the change? Is it possible to use lt; gt; stp as is specificed in LWM2M? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A864782US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I noticed in the latest draft the binding attributes= were changed.

The LWM2M uses the binding attributes in their speci= fication that was recently published.

In LWM2M Greater than is gt; Less than is lt and Ste= p is stp.

In the latest dynlink draft Greater than is gth; Les= s than is lth and Step is st

 

Do we know the reason for the change?

Is it possible to use lt; gt; stp as is specificed i= n LWM2M?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A864782US70UWXCHMBA0_-- From nobody Sat Feb 25 10:04:31 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F631299BA for ; Wed, 22 Feb 2017 11:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj364PEWaw0A for ; Wed, 22 Feb 2017 11:13:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F640129965 for ; Wed, 22 Feb 2017 11:13:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6C64CB80A6F; Wed, 22 Feb 2017 11:13:48 -0800 (PST) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170222191348.6C64CB80A6F@rfc-editor.org> Date: Wed, 22 Feb 2017 11:13:48 -0800 (PST) Archived-At: X-Mailman-Approved-At: Sat, 25 Feb 2017 10:04:29 -0800 Cc: text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, core@ietf.org, hartke@tzi.org, charset=UTF-8@rfc-editor.org Subject: [core] [Technical Errata Reported] RFC7252 (4946) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 19:13:50 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7252&eid=4946 -------------------------------------- Type: Technical Reported by: Klaus Hartke Section: 6.1 Original Text ------------- coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ] Corrected Text -------------- coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ] [ "#" fragment ] Notes ----- The optional fragment component allows for indirect identification of a secondary resource, as defined in Section 3.5 of RFC 3986. The fragment identifier is separated from the rest of the URI prior to a dereference; fragment identifiers are processed client-side and are not included in CoAP requests. The original text shows the syntax of coap:// URIs _after_ separating the fragment identifier, which leaves ambiguity as to whether fragment identifiers are supported or not. The corrected text shows the syntax of CoAP URIs _before_ separating the fragment identifier, which makes clear that fragment identifiers are supported. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Sat Feb 25 10:04:35 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C96129965 for ; Wed, 22 Feb 2017 11:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KgHPlIVbkbH for ; Wed, 22 Feb 2017 11:14:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE73E1299E9 for ; Wed, 22 Feb 2017 11:14:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C5E55B80ACE; Wed, 22 Feb 2017 11:14:31 -0800 (PST) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170222191431.C5E55B80ACE@rfc-editor.org> Date: Wed, 22 Feb 2017 11:14:31 -0800 (PST) Archived-At: X-Mailman-Approved-At: Sat, 25 Feb 2017 10:04:29 -0800 Cc: text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, core@ietf.org, hartke@tzi.org, charset=UTF-8@rfc-editor.org Subject: [core] [Technical Errata Reported] RFC7252 (4947) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 19:14:33 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7252&eid=4947 -------------------------------------- Type: Technical Reported by: Klaus Hartke Section: 6.2 Original Text ------------- coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty [ "?" query ] Corrected Text -------------- coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty [ "?" query ] [ "#" fragment ] Notes ----- The optional fragment component allows for indirect identification of a secondary resource, as defined in Section 3.5 of RFC 3986. The fragment identifier is separated from the rest of the URI prior to a dereference; fragment identifiers are processed client-side and are not included in CoAP requests. The original text shows the syntax of coaps:// URIs _after_ separating the fragment identifier, which leaves ambiguity as to whether fragment identifiers are supported or not. The corrected text shows the syntax of CoAP URIs _before_ separating the fragment identifier, which makes clear that fragment identifiers are supported. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Sat Feb 25 10:04:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15AE129A23 for ; Wed, 22 Feb 2017 13:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI-k-6KO93cw for ; Wed, 22 Feb 2017 13:00:04 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A8912940A for ; Wed, 22 Feb 2017 13:00:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3FA3AB81268; Wed, 22 Feb 2017 13:00:04 -0800 (PST) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170222210004.3FA3AB81268@rfc-editor.org> Date: Wed, 22 Feb 2017 13:00:04 -0800 (PST) Archived-At: X-Mailman-Approved-At: Sat, 25 Feb 2017 10:04:29 -0800 Cc: text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, core@ietf.org, hartke@tzi.org, charset=UTF-8@rfc-editor.org Subject: [core] [Technical Errata Reported] RFC7252 (4948) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 21:00:06 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7252&eid=4948 -------------------------------------- Type: Technical Reported by: Klaus Hartke Section: 5.6 Original Text ------------- For a presented request, a CoAP endpoint MUST NOT use a stored response, unless: o the presented request method and that used to obtain the stored response match, o all options match between those in the presented request and those of the request used to obtain the stored response (which includes the request URI), except that there is no need for a match of any request options marked as NoCacheKey (Section 5.4) or recognized by the Cache and fully interpreted with respect to its specified cache behavior (such as the ETag request option described in Section 5.10.6; see also Section 5.4.2), and o the stored response is either fresh or successfully validated as defined below. The set of request options that is used for matching the cache entry is also collectively referred to as the "Cache-Key". Corrected Text -------------- For a presented request, a CoAP endpoint MUST NOT use a stored response, unless: o [...] o [...] o the payload of the presented request and the payload of the request used to obtain the stored response match, and o [...] The set of request options that is used for matching the cache entry plus (if applicable) the request payload are also collectively referred to as the "Cache-Key". Notes ----- CoAP servers may return error responses in reply to requests that are invalid at the CoAP level (e.g., 4.02 Bad Option if the client includes an unrecognized option) or at the application level above (e.g., 4.00 Bad Request if the client includes a malformed payload according to application semantics). If the error response does not depend on the request payload, then it is desirable that repeated requests that differ only in the payload can be satisfied with the same cached response. E.g., repeated requests for a non-existing resource should result in a cached 4.04 Not Found response as often as possible, regardless of the payload, rather than hit the server every time. If the error response depends on the request payload, then it is not desirable that cached responses are reused for repeated requests that differ only in the payload. E.g., a client should not receive an error response for a valid request payload because another client sent an identical request but with a malformed request payload. In this case, including the request payload in the Cache-Key would give the expected result. The original text does not include the request in the Cache-Key, which may lead to unexpected results. The corrected text changes that. Since CoAP does not provide any indication in responses to distinguish between the two cases, caches generally cannot determine whether the response depends on the request payload or not and thus must always include the request payload in the Cache-Key to give the expected result. (As an exception, a cache at an origin server may be able to determine whether a cached response depends on the request payload or not, and thus can reuse responses accordingly. This already applies to responses that do not depend on the request method.) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Sat Feb 25 10:04:41 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE9C129B55 for ; Wed, 22 Feb 2017 13:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 843griAgRiah for ; Wed, 22 Feb 2017 13:21:33 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2491B129B70 for ; Wed, 22 Feb 2017 13:21:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0BF67B80240; Wed, 22 Feb 2017 13:21:33 -0800 (PST) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170222212133.0BF67B80240@rfc-editor.org> Date: Wed, 22 Feb 2017 13:21:33 -0800 (PST) Archived-At: X-Mailman-Approved-At: Sat, 25 Feb 2017 10:04:29 -0800 Cc: text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, core@ietf.org, hartke@tzi.org, charset=UTF-8@rfc-editor.org Subject: [core] [Technical Errata Reported] RFC7252 (4949) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 21:21:34 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7252&eid=4949 -------------------------------------- Type: Technical Reported by: Klaus Hartke Section: 5.10.7 Original Text ------------- If any of these reserved option numbers occurs in addition to Location-Path and/or Location-Query and are not supported, then a 4.02 (Bad Option) error MUST be returned. Corrected Text -------------- If any of these reserved option numbers occurs in addition to Location-Path and/or Location-Query and are not supported, then the response MUST be rejected (Sections 4.2 and 4.3). Notes ----- The Location-* options are used in responses. A client cannot return a 4.02 (Bad Option) response in reply to a response. The correct behavior is to reject the response. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Sat Feb 25 10:09:01 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796211293F4 for ; Sat, 25 Feb 2017 10:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCOn40YTH6Lu for ; Sat, 25 Feb 2017 10:08:57 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EC01293EE for ; Sat, 25 Feb 2017 10:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1PI8s75003233; Sat, 25 Feb 2017 19:08:54 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vVwvp4BsDzDHD1; Sat, 25 Feb 2017 19:08:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A864782@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sat, 25 Feb 2017 19:08:54 +0100 X-Mao-Original-Outgoing-Id: 509738933.946451-6dd70843c540b99bfd1e95d529af632f Content-Transfer-Encoding: quoted-printable Message-Id: References: <9966516C6EB5FC4381E05BF80AA55F77012A864782@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Carey, Timothy (Nokia - US)" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Binding Attributes in draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Feb 2017 18:08:59 -0000 (No chair hat.) > On 25 Feb 2017, at 17:34, Carey, Timothy (Nokia - US) = wrote: >=20 > Hi, > =20 > I noticed in the latest draft the binding attributes were changed. > The LWM2M uses the binding attributes in their specification that was = recently published. > In LWM2M Greater than is gt; Less than is lt and Step is stp. > In the latest dynlink draft Greater than is gth; Less than is lth and = Step is st > =20 > Do we know the reason for the change? There was a naming issue with =E2=80=9Clt=E2=80=9D being used for both = lifetime and less than. This is not a problem now, but could become one. Since lifetime was in use, attempts have been made to rename less than = (and greater than analogously), but discussion took some time (maybe = because lt and gt are the obvious names for anyone who has heard of = FORTRAN). > Is it possible to use lt; gt; stp as is specificed in LWM2M? Maybe we have missed a window in which this change (avoiding the name = collision) could have been net positive. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Feb 25 11:33:34 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EF712A23C for ; Sat, 25 Feb 2017 11:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elRKPeA8YlZk for ; Sat, 25 Feb 2017 11:33:32 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 F365B12A23B for ; Sat, 25 Feb 2017 11:33:31 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id k4so32445660otc.0 for ; Sat, 25 Feb 2017 11:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qrr5Pk7WhaKXCcok4aYvx69WzW4WIx+oNiI8Wxq8i+w=; b=iCuG+5tsPmBBC5fh+mQmEqycVNFjcT3A5NH7CGKHRj7zj9SdpwNogZ8qruOb6V3Q28 dDaNeN22gvlCOUMJ/XNmynK2WuBgXsMUbF3p0lOPb6u1Mzh01AN0/1KbVYW47ZlMheMB nmj6bRrhxh0v8g+p6IMqn39konlM7ktlaNhohIoyExMuZFNDcdUMtLepvUYxm2soBwuv vSXjgoI1fj/wQ1IwrFzgZScnYJM9bGN092wc1uzhkKxfHDg3t6ql8eZGI9RUIujea8mX As+t11ffrI32fq4vaqgMzR+C08Ol8fSAbgzZXGP2Pg5Q1Pk9PNMRy+QSp+CSByOrSgbA fRAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qrr5Pk7WhaKXCcok4aYvx69WzW4WIx+oNiI8Wxq8i+w=; b=uKiLyr7lOHf5+hJR5kB5aVnNbQbdkuhEFpRCgMfFN5oIEfyPciP9vtP+4AP8SWrxC2 5wpGUMehFppFAh0Jss7xUibtOZ7/ly+ySSQkkGC+RPL64KFYGHn3sCA3zHExAQrHnSh3 onTLHGzgEwZsxNn7EHRX9177XjhQltHs/utx+xQTem+hBUsraBjqj1wUGatPyL8i3jKy BVKIz05aAFpTkae775dfvjjDoJANACQnRV6Oh2hMQk3eA/QGqEmbxHjUZwgJMxfa7A2W PlGoHhl9c48zT8QepSVUyDdG73u5bM5eZHXL5DO3z1yAQBfsFE9b/mRdklvzlx9mhq5Y PLVg== X-Gm-Message-State: AMke39kDwPNgu5Nqr9pftF69ok5BW9uCfPPWG/Jq6nW0hCnIRMiKKifWb932TDvEIy7g8Q== X-Received: by 10.157.53.115 with SMTP id l48mr5494331ote.19.1488051211407; Sat, 25 Feb 2017 11:33:31 -0800 (PST) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id s11sm4332250oia.15.2017.02.25.11.33.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Feb 2017 11:33:30 -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: Date: Sat, 25 Feb 2017 11:33:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9966516C6EB5FC4381E05BF80AA55F77012A864782@US70UWXCHMBA05.zam.alcatel-lucent.com> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Carey, Timothy \(Nokia - US\)" , "core@ietf.org WG" Subject: Re: [core] Binding Attributes in draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Feb 2017 19:33:33 -0000 Hi Tim, Is there a name collision with "st" that required OMA LWM2M to use "stp" = instead? I used "st" in the mbed reference implementation in early 2015. Best regards, Michael > On Feb 25, 2017, at 10:08 AM, Carsten Bormann wrote: >=20 > (No chair hat.) >=20 >> On 25 Feb 2017, at 17:34, Carey, Timothy (Nokia - US) = wrote: >>=20 >> Hi, >>=20 >> I noticed in the latest draft the binding attributes were changed. >> The LWM2M uses the binding attributes in their specification that was = recently published. >> In LWM2M Greater than is gt; Less than is lt and Step is stp. >> In the latest dynlink draft Greater than is gth; Less than is lth and = Step is st >>=20 >> Do we know the reason for the change? >=20 > There was a naming issue with =E2=80=9Clt=E2=80=9D being used for both = lifetime and less than. > This is not a problem now, but could become one. > Since lifetime was in use, attempts have been made to rename less than = (and greater than analogously), but discussion took some time (maybe = because lt and gt are the obvious names for anyone who has heard of = FORTRAN). >=20 >> Is it possible to use lt; gt; stp as is specificed in LWM2M? >=20 > Maybe we have missed a window in which this change (avoiding the name = collision) could have been net positive. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat Feb 25 12:16:26 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B7412A26A for ; Sat, 25 Feb 2017 12:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h42W7nEl-wRh for ; Sat, 25 Feb 2017 12:16:23 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 1402512A267 for ; Sat, 25 Feb 2017 12:16:23 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id 65so24435046oig.1 for ; Sat, 25 Feb 2017 12:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:message-id:cc:to:mime-version; bh=1i67rAQXEHueqFiqn3XnZYjRdlDP14mbxVUoWINFYuo=; b=CjtgLVkTw6dRfb7eSoC/6jyLFsMtvR+OlhfgcTmxHlTWoMsY/mvxAONv5m5BI6sT/Y MWRL54mwfmuPKPC7eX6K1ERsONl80fUml7iQfIVjWCQpPGf3W5KlSVUgJCklxIZaHCa2 ubxWJeS2ELGVvuudh4a00gw40qMqmzAjRjsWlOD+VIEUEsNBwu3ByxhNXDf8MBpxenK1 4iCQXQXfjd1tyN6G51bB3ZxkwuYubeKNBbA/QmO+G+JJf8de2vRN0jgF95kig4YRXjkD Sd3Bu4zwbcrpl/r6Yo7mKYAufy6nDB+U8teJ02z1kjBAx8IeMkt262kLMH07JTMBlWR5 wL6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=1i67rAQXEHueqFiqn3XnZYjRdlDP14mbxVUoWINFYuo=; b=ZwO36Z5NBx9I7E/28gOwHqTn5N6V1e/hE6UXv2M48sXbdpT4kZrRQ37DySo2o3zY9f w6pIGp1HzZhhUbhwho7afSmtSAcyXcfOBXlf2FSrbUNB2DrhX78jqvRlVjepbv0SU9HM KDomxRY1ZODDciUv8LA79rbXWZUtwPDRMh4eLm+SM3sWujX6478TeBo33d9Vl0SQWnkB gFrjkoWLJiFoXa+E3kxjJGWcuiFgjrmlTlQ9uE8vA5p7FNfwxWusZdvF4GAIiG65YGpH gDk/tXkJ5RbbYvqoKOXHfgEFmocZ+bPJOfK2oVHzIeDje2xfU3Uys/XrdGtXcWafLbUH WxMw== X-Gm-Message-State: AMke39mVBpMBhFk4b4C11GD8FcLEmF01K1ke8+5zpjhqUI7iamrECW+As0jQWKWeKIQQ6A== X-Received: by 10.202.7.68 with SMTP id 65mr4880433oih.34.1488053782402; Sat, 25 Feb 2017 12:16:22 -0800 (PST) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id p66sm4301429oif.30.2017.02.25.12.16.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Feb 2017 12:16:21 -0800 (PST) From: Michael Koster Content-Type: multipart/alternative; boundary="Apple-Mail=_9C7AC008-984A-4F6C-A7A3-BFF16E69C569" Date: Sat, 25 Feb 2017 12:16:19 -0800 Message-Id: To: Christian Groves Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: [core] draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 25 Feb 2017 20:16:25 -0000 --Apple-Mail=_9C7AC008-984A-4F6C-A7A3-BFF16E69C569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Christian, I have been thinking about the use case that we exposed in OCF recently, = integrating pubsub and other cloud services into a system of existing = server-based sensors. Currently there is no well defined way to get a = sensor device to push changes to a broker or to get an actuator device = to subscribe to a topic on a broker. Likewise, there is on way to = instruct the broker to observe a resource on a sensor, or to instruct a = broker to update an actuator when a topic is published to on the broker. A binding table, on the devices or on the broker, or both, is a good = solution for this and enables the system-wide state update relationships = to be maintained in a visible, manageable way. I have a couple of comments on the current draft. 1. Why don't we use a resource type for the binding table? Its methods = and responses conform to a generic link list interface, but the content = and side effects are specialized to bindings. I thought we earlier had = used rt=3Dcore.bnd as a resource type to identify the binding table. 2. We could make the example explicitly name the href of the sensor = "switch" and the actuator "light" to help illustrate the directional = pattern of observe the link target and update the link context: = ;rel=3D"boundto";anchor=3D"/a/light";b= ind=3D"obs";pmin=3D"10";pmax=3D"60" 3. I think we will need to register the new link attribute names with = IANA: "pmin", "pmax", "lth", "gth", "stp", "bind" 4. Speaking of attributes, I don't think "bind" is strictly needed to = identify whether to push or pull; that is implied by whether the anchor = and href are local or remote. I can conceive of a case where the binding = both observes and pushes: = ;rel=3D"boundto";anchor=3D"coap://exampl= e.com/pubsub/light";pmin=3D"10";pmax=3D"60" We may instead want to identify what operations are used for both source = (link target/href) and destination (link context/anchor), perhaps change = it to the explicit: src=3Dobs; dst=3Dpush with default being observe = used on the source and update (push) used on the target.=20 Best regards, Michael= --Apple-Mail=_9C7AC008-984A-4F6C-A7A3-BFF16E69C569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Christian,

I have been thinking about the use case that we exposed in = OCF recently, integrating pubsub and other cloud services into a system = of existing server-based sensors.  Currently there is no well = defined way to get a sensor device to push changes to a broker or to get = an actuator device to subscribe to a topic on a broker. Likewise, there = is on way to instruct the broker to observe a resource on a sensor, or = to instruct a broker to update an actuator when a topic is published to = on the broker.

A= binding table, on the devices or on the broker, or both, is a good = solution for this and enables the system-wide state update relationships = to be maintained in a visible, manageable way.

I have a couple of = comments on the current draft.

1. Why don't we use a resource type for = the binding table? Its methods and responses conform to a generic link = list interface, but the content and side effects are specialized to = bindings. I thought we earlier had used rt=3Dcore.bnd as a resource type = to identify the binding table.

2. We could make the example explicitly = name the href of the sensor "switch" and the actuator "light" to help = illustrate the directional pattern of observe the link target and update = the link context:

   <coap://sensor.example.com/s/switch>;rel=3D"boundto";anch=
or=3D"/a/light";bind=3D"obs";pmin=3D"10";pmax=3D"60"

3. I think we will need to = register the new link attribute names with IANA: "pmin", "pmax", "lth", = "gth", "stp", "bind"

4. Speaking of attributes, I don't think "bind" is strictly = needed to identify whether to push or pull; that is implied by whether = the anchor and href are local or remote. I can conceive of a case where = the binding both observes and pushes:

   <coap://example.com/pubsub/switch>;rel=3D"boundto";anchor=
=3D"coap://example.com/pubsub/light";pmin=3D"10";pmax=3D"60"
We may instead want to identify what = operations are used for both source (link target/href) and destination = (link context/anchor), perhaps change it to the explicit: src=3Dobs; = dst=3Dpush with default being observe used on the source and update = (push) used on the target. 

Best regards,

Michael
= --Apple-Mail=_9C7AC008-984A-4F6C-A7A3-BFF16E69C569-- From nobody Sun Feb 26 11:17:14 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A31128AB0 for ; Sun, 26 Feb 2017 11:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgndtGxyVeHE for ; Sun, 26 Feb 2017 11:17:11 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 6E105127601 for ; Sun, 26 Feb 2017 11:17:11 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 2FE80C4B170A9; Sun, 26 Feb 2017 19:17:07 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id v1QJH9tT008040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Feb 2017 19:17:09 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id v1QJGv88030309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Feb 2017 19:17:08 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0301.000; Sun, 26 Feb 2017 14:17:07 -0500 From: "Carey, Timothy (Nokia - US)" To: Michael Koster , Carsten Bormann Thread-Topic: [core] Binding Attributes in draft-groves-core-dynlink-02 Thread-Index: AdKPhIJ5tHWhI/SMR/S1s5vXPdBMHQAN5/cAAALz8IAAGmyiIA== Date: Sun, 26 Feb 2017 19:17:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A865188@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A864782@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: 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: Cc: GARNIER Thierry , "core@ietf.org WG" Subject: Re: [core] Binding Attributes in draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 26 Feb 2017 19:17:13 -0000 TWljaGFlbCwNCg0KV2VsbCB0aGUgSUVURiBpbnRlcmZhY2VzIGRyYWZ0IGhhcyBiZWVuIGNvbnNp c3RlbnQgLSB0aGUgc3RlcCBhdHRyaWJ1dGUgaXMgInN0Ii4NCkkgd2VudCBiYWNrIGFuZCB0cmFj ZWQgdGhlIGNoYW5nZSBpbiBMV00yTSBmcm9tICJzdCIgdG8gInN0cCIuDQpJdCBvY2N1cnJlZCBi ZXR3ZWVuOiANClRoZSBGZWJydWFyeSAyMDE1IChPTUEtVFMtTGlnaHR3ZWlnaHRNMk0tVjFfMC0y MDE1MDIyOC1EKSBoYXMgInN0cCIgYW5kIHRoZSBGZWJydWFyeSAyMDE1IHZlcnNpb24gKE9NQS1U Uy1MaWdodHdlaWdodE0yTS1WMV8wLTIwMTUwMjI1LUQpIGhhcyAic3QiLg0KVGhlIGFncmVlZCB0 byBjciB0aGF0IGJyb3VnaHQgdGhhdCBjaGFuZ2Ugd2FzIE9NQS1ETS1MaWdodHdlaWdodE0yTS0y MDE1LTAwMDhSMDEtQ1JfQXR0cmlidXRlc18NCg0KSSBhZGRlZCBUaGllcnJ5IGludG8gdGhpcyBl bWFpbCAtIG1heWJlIGhlIGNhbiBhbnN3ZXIgeW91ciBxdWVzdGlvbiBiZXR0ZXIgc2luY2UgaGUg YnJvdWdodCB0aGUgb3JpZ2luYWwgQ1IgYnV0IGl0IGxvb2tzIHRvIG1lIHRvIGJlIGFuIGVkaXRv cmlhbCBwcm9ibGVtIHdoZW4gaGUgcmVzdHJ1Y3R1cmVkIHRoYXQgcGFydCBvZiB0aGUgZG9jdW1l bnQgYW5kIGNsYXJpZmllZCB0aGUgcnVsZXMgZm9yIHVzZSB3aXRoaW4gTFdNMk0uLi4gUHJvYmFi bHkganVzdCBhIHR5cG8gdGhhdCBuZWVkcyBjb3JyZWN0ZWQgaW4gdGhlIE9NQSBzcGVjLi4uDQoN CkJSLA0KVGltDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWNoYWVsIEtv c3RlciBbbWFpbHRvOm1pY2hhZWxqb2hua29zdGVyQGdtYWlsLmNvbV0gDQpTZW50OiBTYXR1cmRh eSwgRmVicnVhcnkgMjUsIDIwMTcgMTozMyBQTQ0KVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0 emkub3JnPg0KQ2M6IENhcmV5LCBUaW1vdGh5IChOb2tpYSAtIFVTKSA8dGltb3RoeS5jYXJleUBu b2tpYS5jb20+OyBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtjb3JlXSBCaW5kaW5nIEF0dHJpYnV0ZXMgaW4gZHJhZnQtZ3JvdmVzLWNvcmUtZHlubGluay0w Mg0KDQpIaSBUaW0sDQoNCklzIHRoZXJlIGEgbmFtZSBjb2xsaXNpb24gd2l0aCAic3QiIHRoYXQg cmVxdWlyZWQgT01BIExXTTJNIHRvIHVzZSAic3RwIiBpbnN0ZWFkPyBJIHVzZWQgInN0IiBpbiB0 aGUgbWJlZCByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gaW4gZWFybHkgMjAxNS4NCg0KQmVzdCBy ZWdhcmRzLA0KDQpNaWNoYWVsDQoNCj4gT24gRmViIDI1LCAyMDE3LCBhdCAxMDowOCBBTSwgQ2Fy c3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KPiANCj4gKE5vIGNoYWlyIGhhdC4p DQo+IA0KPj4gT24gMjUgRmViIDIwMTcsIGF0IDE3OjM0LCBDYXJleSwgVGltb3RoeSAoTm9raWEg LSBVUykgPHRpbW90aHkuY2FyZXlAbm9raWEuY29tPiB3cm90ZToNCj4+IA0KPj4gSGksDQo+PiAN Cj4+IEkgbm90aWNlZCBpbiB0aGUgbGF0ZXN0IGRyYWZ0IHRoZSBiaW5kaW5nIGF0dHJpYnV0ZXMg d2VyZSBjaGFuZ2VkLg0KPj4gVGhlIExXTTJNIHVzZXMgdGhlIGJpbmRpbmcgYXR0cmlidXRlcyBp biB0aGVpciBzcGVjaWZpY2F0aW9uIHRoYXQgd2FzIHJlY2VudGx5IHB1Ymxpc2hlZC4NCj4+IElu IExXTTJNIEdyZWF0ZXIgdGhhbiBpcyBndDsgTGVzcyB0aGFuIGlzIGx0IGFuZCBTdGVwIGlzIHN0 cC4NCj4+IEluIHRoZSBsYXRlc3QgZHlubGluayBkcmFmdCBHcmVhdGVyIHRoYW4gaXMgZ3RoOyBM ZXNzIHRoYW4gaXMgbHRoIGFuZCBTdGVwIGlzIHN0DQo+PiANCj4+IERvIHdlIGtub3cgdGhlIHJl YXNvbiBmb3IgdGhlIGNoYW5nZT8NCj4gDQo+IFRoZXJlIHdhcyBhIG5hbWluZyBpc3N1ZSB3aXRo IOKAnGx04oCdIGJlaW5nIHVzZWQgZm9yIGJvdGggbGlmZXRpbWUgYW5kIGxlc3MgdGhhbi4NCj4g VGhpcyBpcyBub3QgYSBwcm9ibGVtIG5vdywgYnV0IGNvdWxkIGJlY29tZSBvbmUuDQo+IFNpbmNl IGxpZmV0aW1lIHdhcyBpbiB1c2UsIGF0dGVtcHRzIGhhdmUgYmVlbiBtYWRlIHRvIHJlbmFtZSBs ZXNzIHRoYW4gKGFuZCBncmVhdGVyIHRoYW4gYW5hbG9nb3VzbHkpLCBidXQgZGlzY3Vzc2lvbiB0 b29rIHNvbWUgdGltZSAobWF5YmUgYmVjYXVzZSBsdCBhbmQgZ3QgYXJlIHRoZSBvYnZpb3VzIG5h bWVzIGZvciBhbnlvbmUgd2hvIGhhcyBoZWFyZCBvZiBGT1JUUkFOKS4NCj4gDQo+PiBJcyBpdCBw b3NzaWJsZSB0byB1c2UgbHQ7IGd0OyBzdHAgYXMgaXMgc3BlY2lmaWNlZCBpbiBMV00yTT8NCj4g DQo+IE1heWJlIHdlIGhhdmUgbWlzc2VkIGEgd2luZG93IGluIHdoaWNoIHRoaXMgY2hhbmdlIChh dm9pZGluZyB0aGUgbmFtZSBjb2xsaXNpb24pIGNvdWxkIGhhdmUgYmVlbiBuZXQgcG9zaXRpdmUu DQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQo= From nobody Sun Feb 26 11:19:45 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD13D120725 for ; Sun, 26 Feb 2017 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htd2nW1jovsZ for ; Sun, 26 Feb 2017 11:19:43 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 AED65127601 for ; Sun, 26 Feb 2017 11:19:43 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id CE3FE3800F03; Sun, 26 Feb 2017 19:19:39 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id v1QJJgJu010002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Feb 2017 19:19:42 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id v1QJGGa4027801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Feb 2017 19:19:42 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Sun, 26 Feb 2017 14:19:00 -0500 From: "Carey, Timothy (Nokia - US)" To: Carsten Bormann Thread-Topic: [core] Binding Attributes in draft-groves-core-dynlink-02 Thread-Index: AdKPhIJ5tHWhI/SMR/S1s5vXPdBMHQAN5/cAACo11KA= Date: Sun, 26 Feb 2017 19:18:59 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A8651AB@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A864782@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: 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: Cc: "core@ietf.org WG" Subject: Re: [core] Binding Attributes in draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 26 Feb 2017 19:19:44 -0000 Q2Fyc3RlbiwgDQpQcm9iYWJseSBmb3IgZ3QgYW5kIGx0OyB0aGV5IGhhdmUgYmVlbiB1c2VkIGlu IExXTTJNIHNpbmNlIGl0IGxvb2tzIGxpa2UgYXJvdW5kIDIwMTMuDQpDaGFuZ2luZyB0aGUgdmFs dWVzIHRvIGd0aCBhbmQgbHRoIHdpbGwgcHJvYmFibHkgYWZmZWN0IGltcGxlbWVudGF0aW9ucy4N Cg0KQlIsDQpUaW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4g Qm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10gDQpTZW50OiBTYXR1cmRheSwgRmVicnVhcnkg MjUsIDIwMTcgMTI6MDkgUE0NClRvOiBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBVUykgPHRpbW90 aHkuY2FyZXlAbm9raWEuY29tPg0KQ2M6IGNvcmVAaWV0Zi5vcmcgV0cgPGNvcmVAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW2NvcmVdIEJpbmRpbmcgQXR0cmlidXRlcyBpbiBkcmFmdC1ncm92ZXMt Y29yZS1keW5saW5rLTAyDQoNCihObyBjaGFpciBoYXQuKQ0KDQo+IE9uIDI1IEZlYiAyMDE3LCBh dCAxNzozNCwgQ2FyZXksIFRpbW90aHkgKE5va2lhIC0gVVMpIDx0aW1vdGh5LmNhcmV5QG5va2lh LmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gIA0KPiBJIG5vdGljZWQgaW4gdGhlIGxhdGVzdCBk cmFmdCB0aGUgYmluZGluZyBhdHRyaWJ1dGVzIHdlcmUgY2hhbmdlZC4NCj4gVGhlIExXTTJNIHVz ZXMgdGhlIGJpbmRpbmcgYXR0cmlidXRlcyBpbiB0aGVpciBzcGVjaWZpY2F0aW9uIHRoYXQgd2Fz IHJlY2VudGx5IHB1Ymxpc2hlZC4NCj4gSW4gTFdNMk0gR3JlYXRlciB0aGFuIGlzIGd0OyBMZXNz IHRoYW4gaXMgbHQgYW5kIFN0ZXAgaXMgc3RwLg0KPiBJbiB0aGUgbGF0ZXN0IGR5bmxpbmsgZHJh ZnQgR3JlYXRlciB0aGFuIGlzIGd0aDsgTGVzcyB0aGFuIGlzIGx0aCBhbmQgU3RlcCBpcyBzdA0K PiAgDQo+IERvIHdlIGtub3cgdGhlIHJlYXNvbiBmb3IgdGhlIGNoYW5nZT8NCg0KVGhlcmUgd2Fz IGEgbmFtaW5nIGlzc3VlIHdpdGgg4oCcbHTigJ0gYmVpbmcgdXNlZCBmb3IgYm90aCBsaWZldGlt ZSBhbmQgbGVzcyB0aGFuLg0KVGhpcyBpcyBub3QgYSBwcm9ibGVtIG5vdywgYnV0IGNvdWxkIGJl Y29tZSBvbmUuDQpTaW5jZSBsaWZldGltZSB3YXMgaW4gdXNlLCBhdHRlbXB0cyBoYXZlIGJlZW4g bWFkZSB0byByZW5hbWUgbGVzcyB0aGFuIChhbmQgZ3JlYXRlciB0aGFuIGFuYWxvZ291c2x5KSwg YnV0IGRpc2N1c3Npb24gdG9vayBzb21lIHRpbWUgKG1heWJlIGJlY2F1c2UgbHQgYW5kIGd0IGFy ZSB0aGUgb2J2aW91cyBuYW1lcyBmb3IgYW55b25lIHdobyBoYXMgaGVhcmQgb2YgRk9SVFJBTiku DQoNCj4gSXMgaXQgcG9zc2libGUgdG8gdXNlIGx0OyBndDsgc3RwIGFzIGlzIHNwZWNpZmljZWQg aW4gTFdNMk0/DQoNCk1heWJlIHdlIGhhdmUgbWlzc2VkIGEgd2luZG93IGluIHdoaWNoIHRoaXMg Y2hhbmdlIChhdm9pZGluZyB0aGUgbmFtZSBjb2xsaXNpb24pIGNvdWxkIGhhdmUgYmVlbiBuZXQg cG9zaXRpdmUuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0K From nobody Sun Feb 26 14:16:05 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5811294A0; Sun, 26 Feb 2017 14:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBwbvLVoV5_w; Sun, 26 Feb 2017 14:15:53 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DDD1294AC; Sun, 26 Feb 2017 14:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1QMFYuT029565; Sun, 26 Feb 2017 23:15:34 +0100 (CET) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vWfKy0nZDzDHRc; Sun, 26 Feb 2017 23:15:34 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 509840133.576226-ea67440cccb3d25d780de107b226edcf Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 26 Feb 2017 23:15:33 +0100 Message-Id: <880044A0-E3F0-436D-BB45-6751A01EDB6B@tzi.org> To: ace@ietf.org, "core@ietf.org WG" , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF98: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 26 Feb 2017 22:16:03 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF98. Remember that there is still quite some potential for changes. ACE/HOMENET/DISPATCH is a bit of a triple whammy. WUGH on LWIG will pull many constrained networks people off the github discussion. I'm not seeing any other major issues, but please do alert the respective chairs when you see one. All times are CDT (UTC-0500) -- yes, the US will be on DST already for a couple of weeks, while Europe moves over right on Mar 26th. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, March 26, 2017 0900-1700 IRTF*** icnrg, with some t2trg-related items on the = agenda MONDAY, March 27, 2017 0900-1130 Morning Session I Zurich A ART dispatch Dispatch WG Zurich D INT homenet Home Networking WG Zurich C SEC *** ace Authentication and Authorization for = Constrained Environments WG 1300-1500 Afternoon Session I Zurich E/F IRTF*** t2trg Thing-to-Thing Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich B RTG bier Bit Indexed Explicit Replication WG Zurich G RTG detnet Deterministic Networking WG Vevey 1/2 TSV tsvarea Transport Area Open Meeting 1520-1650 Afternoon Session II Zurich A SEC tokbind Token Binding WG 1710-1810 Afternoon Session III Vevey 1/2 GEN wugh WGs Using GitHub BOF Zurich E/F INT *** lwig Light-Weight Implementation Guidance WG Montreux 3 SEC curdle CURves, Deprecating and a Little more = Encryption WG Zurich C SEC oauth Web Authorization Protocol WG Zurich G TSV tsvwg Transport Area Working Group WG TUESDAY, March 28, 2017 0900-1130 Morning Session I Zurich C INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Zurich D IRTF maprg Measurement and Analysis for Protocols Zurich E/F SEC tls Transport Layer Security WG 1300-1430 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG Zurich D INT intarea Internet Area Working Group WG Zurich A RTG babel Babel routing protocol WG 1450-1620 Afternoon Session II Zurich G ART uta Using TLS in Applications WG Zurich E/F SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF 1640-1840 Afternoon Session III Zurich C INT dnssd Extensions for Scalable DNS Service = Discovery WG Zurich E/F TSV taps Transport Services WG WEDNESDAY, March 29, 2017 0900-1130 Morning Session I Zurich A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG 1300-1500 Afternoon Session I Zurich A INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Montreux 3 TSV tcpinc TCP Increased Security WG THURSDAY, March 30, 2017 0900-1130 Morning Session I Zurich D INT 6man IPv6 Maintenance WG Zurich C IRTF icnrg Information-Centric Networking Zurich E/F RTG rtgarea Routing Area Open Meeting Vevey 1/2 TSV quic QUIC WG 1300-1500 Afternoon Session I Zurich B ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Zurich G SEC acme Automated Certificate Management = Environment WG Zurich A TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Zurich A OPS v6ops IPv6 Operations WG Zurich D SEC saag Security Area Open Meeting 1740-1840 Afternoon Session III Zurich A RTG *** roll Routing Over Low power and Lossy = networks WG FRIDAY, March 31, 2017 0900-1130 Morning Session I Vevey 1/2 ART httpbis Hypertext Transfer Protocol WG Zurich E/F INT ipwave IP Wireless Access in Vehicular = Environments WG Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich C SEC oauth Web Authorization Protocol WG 1150-1320 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG From nobody Sun Feb 26 19:36:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058CC129668 for ; Sun, 26 Feb 2017 19:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlHa7bluXPwl for ; Sun, 26 Feb 2017 19:36:26 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (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 78E8A129665 for ; Sun, 26 Feb 2017 19:36:26 -0800 (PST) Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:59217 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ciC6o-002C3U-PS for core@ietf.org; Mon, 27 Feb 2017 14:36:22 +1100 To: core@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F77012A864782@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A8651AB@US70UWXCHMBA05.zam.alcatel-lucent.com> From: Christian Groves Message-ID: Date: Mon, 27 Feb 2017 14:36:21 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A8651AB@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] Binding Attributes in draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 03:36:28 -0000 Hello Tim, Given the overlap in "lt" it was either people's resource directory implementations or binding attribute implementations that would be impacted. It seemed that there were more resource directory implementations and draft-ietf-core-resource-directory was further along so it seemed the preference of the list was to change draft-ietf-core-dynlink. As editor i'll leave it up to the Chairs to determine which should change. We could leave gt as it is and only change lt if it helps. Regards, Christian On 27/02/2017 6:18 AM, Carey, Timothy (Nokia - US) wrote: > Carsten, > Probably for gt and lt; they have been used in LWM2M since it looks like around 2013. > Changing the values to gth and lth will probably affect implementations. > > BR, > Tim > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Saturday, February 25, 2017 12:09 PM > To: Carey, Timothy (Nokia - US) > Cc: core@ietf.org WG > Subject: Re: [core] Binding Attributes in draft-groves-core-dynlink-02 > > (No chair hat.) > >> On 25 Feb 2017, at 17:34, Carey, Timothy (Nokia - US) wrote: >> >> Hi, >> >> I noticed in the latest draft the binding attributes were changed. >> The LWM2M uses the binding attributes in their specification that was recently published. >> In LWM2M Greater than is gt; Less than is lt and Step is stp. >> In the latest dynlink draft Greater than is gth; Less than is lth and Step is st >> >> Do we know the reason for the change? > There was a naming issue with “lt” being used for both lifetime and less than. > This is not a problem now, but could become one. > Since lifetime was in use, attempts have been made to rename less than (and greater than analogously), but discussion took some time (maybe because lt and gt are the obvious names for anyone who has heard of FORTRAN). > >> Is it possible to use lt; gt; stp as is specificed in LWM2M? > Maybe we have missed a window in which this change (avoiding the name collision) could have been net positive. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Feb 26 22:04:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F8D129B49 for ; Sun, 26 Feb 2017 22:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I_xUA6c5_0z for ; Sun, 26 Feb 2017 22:04:02 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEA0129B0C for ; Sun, 26 Feb 2017 22:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1R63xbr029725; Mon, 27 Feb 2017 07:03:59 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vWrkR18vXzDHW6; Mon, 27 Feb 2017 07:03:59 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Mon, 27 Feb 2017 07:03:58 +0100 X-Mao-Original-Outgoing-Id: 509868238.602379-f66a7628f3fbd19fa27bcdc1d43b7dac Content-Transfer-Encoding: quoted-printable Message-Id: <108B4FE9-4A57-4BD1-BAA7-EF0AF4064448@tzi.org> References: <9966516C6EB5FC4381E05BF80AA55F77012A864782@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77012A8651AB@US70UWXCHMBA05.zam.alcatel-lucent.com> To: Christian Groves X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core@ietf.org Subject: Re: [core] Binding Attributes in draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 06:04:03 -0000 On 27 Feb 2017, at 04:36, Christian Groves = wrote: >=20 > As editor i'll leave it up to the Chairs to determine which should = change. The chairs can only channel the consensus of the WG, so please keep the = comments on this (bikesheddy, but icky) issue coming. > We could leave gt as it is and only change lt if it helps. (Chair hat off:) It seems to me personally that a change here hurts = more than it helps, both with respect to requiring a change from the = released LWM2M spec and with respect to permanently installing a POLS*) = violation in the spec. Gr=C3=BC=C3=9Fe, Carsten *) POLS: Principle of least surprise, which shouts loudly for less than = to be abbreviated lt. From nobody Sun Feb 26 23:21:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F1D129BD6 for ; Sun, 26 Feb 2017 23:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tARjOB4uvIAg for ; Sun, 26 Feb 2017 23:21:46 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (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 2019F129BD5 for ; Sun, 26 Feb 2017 23:21:46 -0800 (PST) Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:63498 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ciFct-002TBF-Gd; Mon, 27 Feb 2017 18:21:43 +1100 To: Michael Koster References: From: Christian Groves Message-ID: <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> Date: Mon, 27 Feb 2017 18:21:41 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 07:21:48 -0000 Hello Michael, Thanks for the comments. Please see below. Regards, Christian On 26/02/2017 7:16 AM, Michael Koster wrote: > Hi Christian, > > I have been thinking about the use case that we exposed in OCF > recently, integrating pubsub and other cloud services into a system of > existing server-based sensors. Currently there is no well defined way > to get a sensor device to push changes to a broker or to get an > actuator device to subscribe to a topic on a broker. Likewise, there > is on way to instruct the broker to observe a resource on a sensor, or > to instruct a broker to update an actuator when a topic is published > to on the broker. > > A binding table, on the devices or on the broker, or both, is a good > solution for this and enables the system-wide state update > relationships to be maintained in a visible, manageable way. > > I have a couple of comments on the current draft. > > 1. Why don't we use a resource type for the binding table? Its methods > and responses conform to a generic link list interface, but the > content and side effects are specialized to bindings. I thought we > earlier had used rt=core.bnd as a resource type to identify the > binding table. [CNG] I had a look through all the previous drafts (including the Shelby ones) and didn't see any examples of rt=core.bnd . Core.bnd is only used in the context of a interface description. Can you recall where it may have been used? However I can't see why we couldn't formally define a rt=core.bnd . The draft is pretty clear that a binding table is a resource. > > 2. We could make the example explicitly name the href of the sensor > "switch" and the actuator "light" to help illustrate the directional > pattern of observe the link target and update the link context: > > ;rel="boundto";anchor="/a/light";bind="obs";pmin="10";pmax="60" [CNG] OK that makes sense. > 3. I think we will need to register the new link attribute names with > IANA: "pmin", "pmax", "lth", "gth", "stp", "bind" [CNG] I agree so that we avoid the problem of query parameter overloading. I think its part of a larger issue. E.g. sect.12.4/draft-ietf-core-resource-directory-09 proposes a new CoAP RD specific registry for query parameters. Should the query parameter registry be something specific or general for CoAP? > > 4. Speaking of attributes, I don't think "bind" is strictly needed to > identify whether to push or pull; that is implied by whether the > anchor and href are local or remote. I can conceive of a case where > the binding both observes and pushes: > > ;rel="boundto";anchor="coap://example.com/pubsub/light";pmin="10";pmax="60" > > We may instead want to identify what operations are used for both > source (link target/href) and destination (link context/anchor), > perhaps change it to the explicit: src=obs; dst=push with default > being observe used on the source and update (push) used on the target. [CNG] Would introducing two attributes instead make it more complicated? Effectively we're just representing what is expressed by a single code point into 2 code points. Couldn't you cover the above use case by having two table entries? > > Best regards, > > Michael From nobody Mon Feb 27 07:25:31 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8688712A122 for ; Mon, 27 Feb 2017 07:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQKmS1oF1t7t for ; Mon, 27 Feb 2017 07:25:29 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 0DF8212A0F0 for ; Mon, 27 Feb 2017 07:25:29 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id p77so38480121ywg.1 for ; Mon, 27 Feb 2017 07:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rii52XQtck0mUVrlGdYLpmM87tOWk5TTCsMx2yuP9dM=; b=qJlO+pYct4qHlIaKC+owp9UFGu3cBvf0uy463zq42tFkyynJTKgvQqk5KFoV0KDnSP BvhEFhFw1Mp//xN/ifExgYV5Zj5qG/vn3M+x0ZL5dqalzRmysbABUyv2hcvnRmRy5BbM Zlvi08CLsTq6t7S+Yb2jgpWirTsch2XiBDzei+2wvi5QSIYL5XkXl7M8mGw1GT5diYYe sWXu6HMUoDadq5YGw7CFswNDLJBewm9JlWdR3Mf66oyrrlgPdNSrmsR/u34ipUVUu4Gd uTESV4ezWBZ1gEiDbKcFjvb/19brzB1e7ClyZLL0jUpLiG3KupLAQLc6saW+SbdNq7cR EG/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rii52XQtck0mUVrlGdYLpmM87tOWk5TTCsMx2yuP9dM=; b=AMgqOSXLGazQ/zppNKjmbZh5sJf87r4dKkk8U+/hjFoIznWYw6mtlBEv4KkRyNfEIK WTC5owPWBOfBjGY9xcCxJDqK3ioo949fTxTAweJ7eoUaoyJASD/XzUENg7dUoQMjrT2L 1jT/x3ndD5uaCsYuESQOKk0ATcWUD4cgJ1hgt5CYB/58asj28x5A+BJYQCGB8EaROUwd Qe5n/leSPkEcxxF+MGv/EEE6MopLzOWC436GEqU5wXMZL6sbQ2YzPD+xbM91MYwWmblE Y11aR8BsJeJgsonWEKAQKAgHgBvJBfPh3X2xmk1+sCjVP7ePwHCHw0DXnncGNwb7a8yv LrRg== X-Gm-Message-State: AMke39n2eS5T5M+/VI1xmEBkw6tFbXsXR2ltHK39HGjUyitjgHePRgxOE71xB+BTRTVp3A== X-Received: by 10.13.217.129 with SMTP id b123mr13241165ywe.81.1488209128026; Mon, 27 Feb 2017 07:25:28 -0800 (PST) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id p62sm6929592ywb.2.2017.02.27.07.25.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Feb 2017 07:25:27 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> Date: Mon, 27 Feb 2017 07:25:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com> References: <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 15:25:30 -0000 Hi, Clarifications below. Michael > On Feb 26, 2017, at 11:21 PM, Christian Groves = wrote: >=20 > Hello Michael, >=20 > Thanks for the comments. Please see below. >=20 > Regards, Christian >=20 >=20 > On 26/02/2017 7:16 AM, Michael Koster wrote: >> Hi Christian, >>=20 >> I have been thinking about the use case that we exposed in OCF = recently, integrating pubsub and other cloud services into a system of = existing server-based sensors. Currently there is no well defined way to = get a sensor device to push changes to a broker or to get an actuator = device to subscribe to a topic on a broker. Likewise, there is on way to = instruct the broker to observe a resource on a sensor, or to instruct a = broker to update an actuator when a topic is published to on the broker. >>=20 >> A binding table, on the devices or on the broker, or both, is a good = solution for this and enables the system-wide state update relationships = to be maintained in a visible, manageable way. >>=20 >> I have a couple of comments on the current draft. >>=20 >> 1. Why don't we use a resource type for the binding table? Its = methods and responses conform to a generic link list interface, but the = content and side effects are specialized to bindings. I thought we = earlier had used rt=3Dcore.bnd as a resource type to identify the = binding table. > [CNG] I had a look through all the previous drafts (including the = Shelby ones) and didn't see any examples of rt=3Dcore.bnd . Core.bnd is = only used in the context of a interface description. Can you recall = where it may have been used? > However I can't see why we couldn't formally define a rt=3Dcore.bnd . = The draft is pretty clear that a binding table is a resource. [MJK] Yes, I am proposing that the binding table use the core.ll = interface, which is basically a collection resource that exposes core = link-format. It can be identified as a binding table by using = rt=3Dcore.bnd as a resource type, rather than a special interface type. = I had intended to make this change when I made core.ll support create, = update, and delete operations. >>=20 >> 2. We could make the example explicitly name the href of the sensor = "switch" and the actuator "light" to help illustrate the directional = pattern of observe the link target and update the link context: >>=20 >> = ;rel=3D"boundto";anchor=3D"/a/light";b= ind=3D"obs";pmin=3D"10";pmax=3D"60" >=20 > [CNG] OK that makes sense. >> 3. I think we will need to register the new link attribute names with = IANA: "pmin", "pmax", "lth", "gth", "stp", "bind" > [CNG] I agree so that we avoid the problem of query parameter = overloading. I think its part of a larger issue. E.g. = sect.12.4/draft-ietf-core-resource-directory-09 proposes a new CoAP RD = specific registry for query parameters. Should the query parameter = registry be something specific or general for CoAP? >=20 [MJK] If we want to avoid conflicts, there will need to be some = coordination across the document-specific registries. Why not use the = IANA CoRE Parameters Registry or some evolution thereof? >>=20 >> 4. Speaking of attributes, I don't think "bind" is strictly needed to = identify whether to push or pull; that is implied by whether the anchor = and href are local or remote. I can conceive of a case where the binding = both observes and pushes: >>=20 >> = ;rel=3D"boundto";anchor=3D"coap://exampl= e.com/pubsub/light";pmin=3D"10";pmax=3D"60" >>=20 >> We may instead want to identify what operations are used for both = source (link target/href) and destination (link context/anchor), perhaps = change it to the explicit: src=3Dobs; dst=3Dpush with default being = observe used on the source and update (push) used on the target. > [CNG] Would introducing two attributes instead make it more = complicated? Effectively we're just representing what is expressed by a = single code point into 2 code points. Couldn't you cover the above use = case by having two table entries? >=20 [MJK] I think two attributes are necessary to support the case where = both links point to resources under a different netloc, where there is = no RESThook or other back channel access method to the resource. The = source link will use polling or observe, and the destination link will = use push. I also see a use case for defining, in the push binding, = whether to use PUT or POST.=20 [MJK] Even for the case where the source link is local, there is still a = choice of polling vs. reacting to resource state changes. Periodic = polling is often required to run some algorithms like PID controllers. [MJK] I think it can be easily explained using a table listing the cases = for local vs. remote and source vs. destination addresses and what the = options are.=20 From nobody Mon Feb 27 12:45:52 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2271293F8 for ; Mon, 27 Feb 2017 12:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 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, MPART_ALT_DIFF_COUNT=1.112, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utRBY44U95ZS for ; Mon, 27 Feb 2017 12:45:46 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 C449912A330 for ; Mon, 27 Feb 2017 12:45:46 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id p5so24630368pga.1 for ; Mon, 27 Feb 2017 12:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9cNg0ti9I7zcyuofi3rSmxr79gbTyhGzGENcr4lJkDI=; b=bBhqhN9NH4vUwedEs4Y/F4D82pcQB6NXLMP3/9A/aK92lirNPFjSigAv2cbo7b/0vD TDMyZ7IN9mnWDf2AuFHkYjnKGXqRbPoflcl0EzsYmEg6IXkGKDwzehHsydm6lD5EHG5s 684J8BkzsKDTRHW9ymwjPofIWOc3rFolDL4UlP6KVxWXIc/Ku0hnvithTmczQoHlJohK RuIo5ChqQsn1UHRgxayHIWZiBLAf9FoZlDHMbrp52K5lrGqASoEiZOROsk9KH1H523dk 3oLf4BsYBBgK7C3+NzKsRldZZUUAEZIwowYGcfszwZpZRrKmgeLazhrBjkuKIojYGt3c /3hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9cNg0ti9I7zcyuofi3rSmxr79gbTyhGzGENcr4lJkDI=; b=qwXPpYUsfTJRIPDwALvOkcVj3TDCLtneHzoOpdf1cZLVW2yR9rclWHpmmL0dgay1YN zC8hmFR0Krl0UdEVNNfSCKDRMJo4tm+kCbkAn+1ToZ/v/kQzfR1BUPmEZf/xtIulZOsY 36hgZ4UXxkkhJL+lqn7WoUW1Ci5NthctANui+Pq9IvL50xzT2TpAv+eSBS0M0L6vqp55 TlkgeAQ2WSuw4gpODmag8iAwTnNbRVNkiSuJi+CTfqWEaXCiUKKoy2o+Y/1kSd4kpLnR Qidb/NRKVF//Cn0vYicCzj4Tl+V6tu1KBCk7hi7fifWQxUdA8mkFFY+wnMhB7VpLzggw ShSA== X-Gm-Message-State: AMke39kbysJDBrFbjI8YUZvWS25ak1UCYYEc6mVmcW/ehvrRb7WPRdDmA7FighXGnP0Skw== X-Received: by 10.84.236.4 with SMTP id q4mr27022765plk.1.1488228346319; Mon, 27 Feb 2017 12:45:46 -0800 (PST) Received: from [172.18.40.215] ([50.225.220.36]) by smtp.gmail.com with ESMTPSA id e13sm32415002pgn.38.2017.02.27.12.45.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Feb 2017 12:45:45 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_367BA14B-3344-4D93-B654-7734E7F0546F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com> Date: Mon, 27 Feb 2017 12:45:47 -0800 Message-Id: <2FEB83DB-873A-42BE-BADF-51AE72104205@gmail.com> References: <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: [core] Adding CRUD to the core.ll interface; was Re: draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 20:45:51 -0000 --Apple-Mail=_367BA14B-3344-4D93-B654-7734E7F0546F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 27, 2017, at 7:25 AM, Michael Koster = wrote: >=20 > [MJK] Yes, I am proposing that the binding table use the core.ll = interface, which is basically a collection resource that exposes core = link-format. It can be identified as a binding table by using = rt=3Dcore.bnd as a resource type, rather than a special interface type. = I had intended to make this change when I made core.ll support create, = update, and delete operations. I am proposing to add CRUD functionality to core.ll collections, as = described in section 3.4 of CoRE Interfaces, and which is consistent = with the current draft of CoRE Resource Directory, section 5.4 = (attached)=20 Links in the collection MAY be Read, Updated, Added, or Removed using the CoRE Link-Format or JSON Merge-Patch Content-Formats on the collection resource. Reading links uses the GET method and returns an array or list containing the link-values of all selected links. Links may be added to the collection using POST or PATCH methods. Updates to links MUST use the PATCH method and MAY use query filtering to select links for updating. The PATCH method on links MUST use the JSON Merge-Patch Content-Format (application/merge- patch+json) specified in [RFC7396]. Currently, core.ll only has GET defined (Table 2), but IMO there is no = reason not to add the full set of methods including PATCH. THe query = parameter selects one or more links for updating, and the merge-patch = document is applied to each selected link. At one point we discussed putting this into a separate document that can = be referenced from both RD and CoRE Interfaces, but it seems to belong = more in interfaces, where collections are described. Is there a place I could make a pull request to for a proposed update to = Section 4.1 of the CoRE Interfaces document? I am in the middle of = updating the description in CoRE RD and could do this relatively = quickly. Also have some proposed tweaks to align b and lb interface definitoins = with OCF, but that is a separate proposal. Best regards, Michael --Apple-Mail=_367BA14B-3344-4D93-B654-7734E7F0546F Content-Type: multipart/mixed; boundary="Apple-Mail=_88AA6468-5E68-49AB-958D-08123CFBB02E" --Apple-Mail=_88AA6468-5E68-49AB-958D-08123CFBB02E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Feb 27, 2017, at 7:25 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

[MJK] Yes, I am proposing that the binding table = use the core.ll interface, which is basically a collection resource that = exposes core link-format. It can be identified as a binding table by = using rt=3Dcore.bnd as a resource type, rather than a special interface = type. I had intended to make this change when I made core.ll support = create, update, and delete operations.

I am proposing to add CRUD functionality to = core.ll collections, as described in section 3.4 of CoRE Interfaces, and = which is consistent with the current draft of CoRE Resource Directory, = section 5.4 (attached) 

   =
Links in the collection MAY be Read, Updated, Added, or Removed using
   the CoRE Link-Format or JSON Merge-Patch Content-Formats on the
   collection resource.  Reading links uses the GET method and returns
   an array or list containing the link-values of all selected links.
   Links may be added to the collection using POST or PATCH methods.
   Updates to links MUST use the PATCH method and MAY use query
   filtering to select links for updating.  The PATCH method on links
   MUST use the JSON Merge-Patch Content-Format (application/merge-
   patch+json) specified in [RFC7396].
Currently, core.ll only has GET defined = (Table 2), but IMO there is no reason not to add the full set of methods = including PATCH. THe query parameter selects one or more links for = updating, and the merge-patch document is applied to each selected = link.

At one = point we discussed putting this into a separate document that can be = referenced from both RD and CoRE Interfaces, but it seems to belong more = in interfaces, where collections are described.

Is there a place I could make a pull = request to for a proposed update to Section 4.1 of the CoRE Interfaces = document? I am in the middle of updating the description in CoRE RD and = could do this relatively quickly.

Also have some proposed tweaks to align = b and lb interface definitoins with OCF, but that is a separate = proposal.

Best = regards,

Michael

= --Apple-Mail=_88AA6468-5E68-49AB-958D-08123CFBB02E Content-Disposition: attachment; filename=draft-ietf-core-resource-directory-xx.txt Content-Type: text/plain; name="draft-ietf-core-resource-directory-xx.txt" Content-Transfer-Encoding: quoted-printable CoRE Z. Shelby Internet-Draft ARM Intended status: Standards Track M. Koster Expires: June 23, 2017 SmartThings C. Bormann Universitaet Bremen TZI P. van der Stok consultant December 20, 2016 CoRE Resource Directory draft-ietf-core-resource-directory-10pre Abstract In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 23, 2017. Shelby, et al. Expires June 23, 2017 [Page 1] =0C Internet-Draft CoRE Resource Directory December 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 5 3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6 3.2. Use Case: Home and Building Automation . . . . . . . . . 7 3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7 4. Finding a Resource Directory . . . . . . . . . . . . . . . . 8 4.1. Resource Directory Address Option (RDAO) . . . . . . . . 9 5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 10 5.1. Content Formats . . . . . . . . . . . . . . . . . . . . . 11 5.2. Base URI Discovery . . . . . . . . . . . . . . . . . . . 11 5.3. Registration . . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Simple Registration . . . . . . . . . . . . . . . . . 16 5.3.2. Simple publishing to Resource Directory Server . . . 16 5.3.3. Third-party registration . . . . . . . . . . . . . . 17 5.4. Operations on the Registration Resource . . . . . . . . . 18 5.4.1. Registration Update . . . . . . . . . . . . . . . . . 18 5.4.2. Registration Removal . . . . . . . . . . . . . . . . 20 5.4.3. Read Endpoint Links . . . . . . . . . . . . . . . . . 21 5.4.4. Update Endpoint Links . . . . . . . . . . . . . . . . 22 6. RD Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Register a Group . . . . . . . . . . . . . . . . . . . . 26 6.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 28 7. RD Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8.1. Endpoint Identification and Authentication . . . . . . . 34 8.2. Access Control . . . . . . . . . . . . . . . . . . . . . 34 8.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 35 9.2. IPv6 ND Resource Directory Address Option . . . . . . . . 35 Shelby, et al. Expires June 23, 2017 [Page 2] =0C Internet-Draft CoRE Resource Directory December 2016 9.3. RD Parameter Registry . . . . . . . . . . . . . . . . . . 35 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. Lighting Installation . . . . . . . . . . . . . . . . . 36 10.1.1. Installation Characteristics . . . . . . . . . . . . 37 10.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 38 10.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 41 10.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 41 10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 43 10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 44 10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 45 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 13.1. Normative References . . . . . . . . . . . . . . . . . . 49 13.2. Informative References . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation. The discovery of resources offered by a constrained server is very important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP Web Server is typically called Web Linking [RFC5988]. The use of Web Linking for the description and discovery of resources hosted by constrained web servers is specified by the CoRE Link Format [RFC6690]. However, [RFC6690] only describes how to discover resources from the web server that hosts them by requesting "/.well-known/core". In many M2M scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with a Resource Directory are defined. Although the examples in this document show the use of these interfaces with CoAP [RFC7252], they can be applied in an equivalent manner to HTTP [RFC7230]. Shelby, et al. Expires June 23, 2017 [Page 3] =0C Internet-Draft CoRE Resource Directory December 2016 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "byte" is used in its now customary sense as a synonym for "octet". This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC5988] and [RFC6690]. Readers should also be familiar with the terms and concepts discussed in [RFC7252]. To describe the REST interfaces defined in this specification, the URI Template format is used [RFC6570]. This specification makes use of the following additional terminology: Resource Directory A web entity that stores information about web resources and implements the REST interfaces defined in this specification for registration and lookup of those resources. Domain In the context of a Resource Directory, a domain is a logical grouping of endpoints. This specification assumes that the list of Domains supported by an RD is pre-configured by that RD. When a domain is exported to DNS, the domain value equates to the DNS domain name. Group In the context of a Resource Directory, a group is a logical grouping of endpoints for the purpose of group communications. All groups within a domain are unique. Endpoint Endpoint (EP) is a term used to describe a web server or client in [RFC7252]. In the context of this specification an endpoint is used to describe a web server that registers resources to the Resource Directory. An endpoint is identified by its endpoint name, which is included during registration, and is unique within the associated domain of the registration. Context When registering links to a Resource Directory, the Context refers to the scheme, address, port, and base path for all the links registered on behalf of an endpoint, of the general form scheme://host:port/path/ where the client may explicitly set the scheme and host, and may supply the port and path as optional Shelby, et al. Expires June 23, 2017 [Page 4] =0C Internet-Draft CoRE Resource Directory December 2016 parameters. When the context of a registration is explicitly set, the URI resolution rules in [RFC3986] MUST be applied. Commissioning Tool Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. RDAO Resource Directory Address Option. 3. Architecture and Use Cases The resource directory architecture is illustrated in Figure 1. A Resource Directory (RD) is used as a repository for Web Links [RFC5988] about resources hosted on other web servers, which are called endpoints (EP). An endpoint is a web server associated with a scheme, IP address and port (called Context), thus a physical node may host one or more endpoints. The RD implements a set of REST interfaces for endpoints to register and maintain sets of Web Links (called resource directory registration entries), and for clients to lookup resources from the RD or maintain groups. Endpoints themselves can also act as clients. An RD can be logically segmented by the use of Domains. The domain an endpoint is associated with can be defined by the RD or configured by an outside entity. This information hierarchy is shown in Figure 2. A mechanism to discover an RD using CoRE Link Format [RFC6690] is defined. Endpoints proactively register and maintain resource directory registration entries on the RD, which are soft state and need to be periodically refreshed. An endpoint is provided with interfaces to register, update and remove a resource directory registration entry. It is also possible for an RD to fetch Web Links from endpoints and add them as resource directory entries. At the first registration of a set of entries, a "registration resource" is created, the location of which is returned to the registering endpoint. The registering endpoint uses this registration resource to manage the contents of the registration entry. A lookup interface for discovering any of the Web Links held in the RD is provided using the CoRE Link Format. Shelby, et al. Expires June 23, 2017 [Page 5] =0C Internet-Draft CoRE Resource Directory December 2016 Registration Lookup, Group Interface Interfaces +----+ | | | EP |---- | | +----+ ---- | | --|- +------+ | +----+ | ----| | | +--------+ | EP | ---------|-----| RD |----|-----| Client | +----+ | ----| | | +--------+ --|- +------+ | +----+ ---- | | | EP |---- | | +----+ Figure 1: The resource directory architecture. +------------+ | Domain | <-- Name +------------+ | | | +------------+ | | Group | <-- Name, Scheme, IP, Port | +------------+ | | +------------+ | Endpoint | <-- Name, Scheme, IP, Port +------------+ | | +------------+ | Resource | <-- Target, Parameters +------------+ Figure 2: The resource directory information hierarchy. 3.1. Use Case: Cellular M2M Over the last few years, mobile operators around the world have focused on development of M2M solutions in order to expand the business to the new type of users: machines. The machines are connected directly to a mobile network using an appropriate embedded air interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing short and wide range wireless interfaces. =46rom the system design point = of view, the ambition is to design horizontal solutions that can enable utilization of machines in different applications depending on their current availability and capabilities as well as application Shelby, et al. Expires June 23, 2017 [Page 6] =0C Internet-Draft CoRE Resource Directory December 2016 requirements, thus avoiding silo like solutions. One of the crucial enablers of such design is the ability to discover resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. In a typical scenario, during a boot-up procedure (and periodically afterwards), the machines (endpoints) register with a Resource Directory (for example EPs installed on vehicles enabling tracking of their position for fleet management purposes and monitoring environment parameters) hosted by the mobile operator or somewhere else in the network, periodically a description of its own capabilities. Due to the usual network configuration of mobile networks, the EPs attached to the mobile network may not always be efficiently reachable. Therefore, a remote server is usually used to provide proxy access to the EPs. The address of each (proxy) endpoint on this server is included in the resource description stored in the RD. The users, for example mobile applications for environment monitoring, contact the RD, look up the endpoints capable of providing information about the environment using appropriate set of link parameters, obtain information on how to contact them (URLs of the proxy server) and then initiate interaction to obtain information that is finally processed, displayed on the screen and usually stored in a database. Similarly, fleet management systems provide the appropriate link parameters to the RD to look up for EPs deployed on the vehicles the application is responsible for. 3.2. Use Case: Home and Building Automation Home and commercial building automation systems can benefit from the use of M2M web services. The discovery requirements of these applications are demanding. Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time discovery is used. Both home and building automation involve peer- to-peer interactions between endpoints, and involve battery-powered sleeping devices. 3.3. Use Case: Link Catalogues Resources may be shared through data brokers that have no knowledge beforehand of who is going to consume the data. Resource Directory can be used to hold links about resources and services hosted anywhere to make them discoverable by a general class of applications. For example, environmental and weather sensors that generate data for public consumption may provide the data to an intermediary server, or broker. Sensor data are published to the intermediary upon changes Shelby, et al. Expires June 23, 2017 [Page 7] =0C Internet-Draft CoRE Resource Directory December 2016 or at regular intervals. Descriptions of the sensors that resolve to links to sensor data may be published to a Resource Directory. Applications wishing to consume the data can use RD Lookup to discover and resolve links to the desired resources and endpoints. The Resource Directory service need not be coupled with the data intermediary service. Mapping of Resource Directories to data intermediaries may be many-to-many. Metadata in web link formats like [RFC6690] are supplied by Resource Directories, which may be internally stored as triples, or relation/ attribute pairs providing metadata about resource links. External catalogs that are represented in other formats may be converted to common web linking formats for storage and access by Resource Directories. Since it is common practice for these to be URN encoded, simple and lossless structural transforms should generally be sufficient to store external metadata in Resource Directories. The additional features of Resource Directory allow domains to be defined to enable access to a particular set of resources from particular applications. This provides isolation and protection of sensitive data when needed. Resource groups may defined to allow batched reads from multiple resources. 4. Finding a Resource Directory Several mechanisms can be employed for discovering the RD, including assuming a default location (e.g. on an Edge Router in a LoWPAN), assigning an anycast address to the RD, using DHCP, or discovering the RD using .well-known/core and hyperlinks as specified in CoRE Link Format [RFC6690]. Endpoints that want to contact a Resource Directory can obtain candidate IP addresses for such servers in a number of ways. In a 6LoWPAN, good candidates can be taken from: o specific static configuration (e.g., anycast addresses), if any, o the ABRO option of 6LoWPAN-ND [RFC6775], o other ND options that happen to point to servers (such as RDNSS), o DHCPv6 options that might be defined later. o The IPv6 Neighbor Discovery Resource Directory Address Option described in Section 4.1 In networks with more inexpensive use of multicast, the candidate IP address may be a well-known multicast address, i.e. directory servers Shelby, et al. Expires June 23, 2017 [Page 8] =0C Internet-Draft CoRE Resource Directory December 2016 are found by simply sending GET requests to that well-known multicast address (see Section 5.2). Constrained nodes configured in large batches may be configured for an anycast address for the RD. Each target network environment in which some of these preconfigured nodes are to be brought up is then configured with a route for this anycast address that leads to an RD that is appropriate for the environment. As some of these sources are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate- limit requests to candidate IP addresses that don't work out. For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. 4.1. Resource Directory Address Option (RDAO) The Resource Directory Option (RDAO) using IPv6 neighbor Discovery (ND) carries information about the address of the Resource Directory (RD). This information is needed when endpoints cannot discover the Resource Directory with link-local multicast address because the endpoint and the RD are separated by a border Router (6LBR). In many circumstances the availability of DHCP cannot be guaranteed either during commissioning of the network. The presence and the use of the RD is essential during commissioning. It is possible to send multiple RDAO options in one message, indicating as many resource directory addresses. The lifetime 0x0 means that the RD address is invalid and to be removed. The RDAO format is: Shelby, et al. Expires June 23, 2017 [Page 9] =0C Internet-Draft CoRE Resource Directory December 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length =3D 3 | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + RD Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 38 Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 3. Valid Lifetime: 16-bit unsigned integer. The length of time in units of 60 seconds (relative to the time the packet is received) that this Resource Directory address is valid. A value of all zero bits (0x0) indicates that this Resource Directory address is not valid anymore. Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. RD Address: IPv6 address of the RD. Figure 3: Resource Directory Address Option 5. Resource Directory This section defines the required set of REST interfaces between a Resource Directory (RD) and endpoints. Although the examples throughout this section assume the use of CoAP [RFC7252], these REST interfaces can also be realized using HTTP [RFC7230]. In all definitions in this section, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown. Shelby, et al. Expires June 23, 2017 [Page 10] =0C Internet-Draft CoRE Resource Directory December 2016 An RD implementing this specification MUST support the discovery, registration, update, lookup, and removal interfaces defined in this section. 5.1. Content Formats Resource Directory implementations using this specification MUST support the application/link-format content format (ct=3D40). Resource Directories implementing this specification MAY support additional content formats. Any additional content format supported by a Resource Directory implementing this specification MUST have an equivalent serialization in the application/link-format content format. 5.2. Base URI Discovery Before an endpoint can make use of an RD, it must first know the RD's address and port, and the base URI information for its REST API. This section defines discovery of the RD and its base URI using the well-known interface of the CoRE Link Format [RFC6690]. It is however expected that RDs will also be discoverable via other methods depending on the deployment. Discovery of the RD base URI is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter [RFC6690] with the value "core.rd" in the query string. Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the base URI for RD Lookup operations, and "core.gp" is used to discover the base URI for RD Group operations. Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the base URI of the RD function returned and the corresponding Resource Type. When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link attribute, as shown in the example below. Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry Shelby, et al. Expires June 23, 2017 [Page 11] =0C Internet-Draft CoRE Resource Directory December 2016 points SHOULD be provided to enable the bootstrapping of unicast discovery. An RD implementation of this specification MUST support query filtering for the rt parameter as defined in [RFC6690]. The discovery request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /.well-known/core{?rt} URI Template Variables: rt :=3D Resource Type (optional). MAY contain one of the values "core.rd", "core.rd-lookup*", "core.rd-lookup-d", "core.rd- lookup-res", "core.rd-lookup-ep", "core.rd-lookup-gp", "core.rd-group" or "core.rd*" Content-Format: application/link-format (if any) Content-Format: application/link-format+json (if any) Content-Format: application/link-format+cbor (if any) The following response codes are defined for this interface: Success: 2.05 "Content" with an application/link-format, application/link-format+json, or application/link-format+cbor payload containing one or more matching entries for the RD resource. Failure: 4.04 "Not Found" is returned in case no matching entry is found for a unicast request. Failure: 4.00 "Bad Request" is returned in case of a malformed request for a unicast request. Failure: No error response to a multicast request. HTTP support : YES (Unicast only) The following example shows an endpoint discovering an RD using this interface, thus learning that the base RD resource is, in this example, at /rd and that the content-format delivered by the server hosting the resource is application/link-format (ct=3D40). Note that Shelby, et al. Expires June 23, 2017 [Page 12] =0C Internet-Draft CoRE Resource Directory December 2016 it is up to the RD to choose its base RD resource, although diagnostics and debugging is facilitated by using the base paths specified here where possible. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D40, ;rt=3D"core.rd-lookup-ep";ct=3D40, ;rt=3D"core.rd-lookup-res";ct=3D"40", ;rt=3D"core.rd-group";ct=3D40 The following example shows the way of indicating that a client may request alternate content-formats. The Content-Format code attribute "ct" MAY include a space-separated sequence of Content-Format codes as specified in Section 7.2.1 of [RFC7252], indicating that multiple content-formats are available. The example below shows the required Content-Format 40 (application/link-format) indicated as well as a more application-specific content format (picked as 65225 in this example; this is in the experimental space, not an assigned value). The base RD resource values /rd, /rd-lookup, and /rd-group are example values. Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D"40 65225", ;rt=3D"core.rd-lookup-res";ct=3D"40 65225", ;rt=3D"core.rd-lookup-ep";ct=3D"40 65225", ;rt=3D"core.rd-group";ct=3D"40 65225" 5.3. Registration After discovering the location of an RD, an endpoint MAY register its resources using the registration interface. This interface accepts a POST from an endpoint containing the list of resources to be added to the directory as the message payload in the CoRE Link Format [RFC6690], JSON CoRE Link Format (application/link-format+json), or CBOR CoRE Link Format (application/link-format+cbor) [I-D.ietf-core-links-json], along with query parameters indicating the name of the endpoint, and optionally its domain and the lifetime of the registration. It is expected that other specifications will define further parameters (see Section 9.3). The RD then creates a new registration resource in the RD and returns its location. An endpoint MUST use that location when refreshing registrations using this interface. Endpoint resources in the RD are kept active for the period indicated by the lifetime parameter. The endpoint is responsible for refreshing the entry within this period using either Shelby, et al. Expires June 23, 2017 [Page 13] =0C Internet-Draft CoRE Resource Directory December 2016 the registration or update interface. The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameters ep and d does not create multiple RD entries. A new registration may be created at any time to supersede an existing registration, replacing the registration parameters and links. The registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+rd}{?ep,d,et,lt,con} URI Template Variables: rd :=3D RD Base URI path (mandatory). This is the path of the = RD, as obtained from discovery. The value "rd" is recommended for this variable. ep :=3D Endpoint name (mandatory). The endpoint name is an identifier that MUST be unique within a domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. et :=3D Endpoint Type (optional). The semantic type of the endpoint. This parameter SHOULD be less than 63 bytes. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included in the initial registration, a default value of 86400 (24 hours) SHOULD be assumed. If the lt parameter is not included in a registration refresh or update operation, the most recently supplied value SHALL be re-used. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port/path. In the absence of this parameter the scheme of the protocol, source address and source port of the register request are assumed. This parameter is mandatory when the directory is filled by a third party such as an commissioning tool. When con is used, scheme and host are mandatory and port and path parameters are optional. If the Shelby, et al. Expires June 23, 2017 [Page 14] =0C Internet-Draft CoRE Resource Directory December 2016 endpoint uses an ephemeral port to register with, it MUST include the con: parameter in the registration to provide a valid network path. If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor The following response codes are defined for this interface: Success: 2.01 "Created" or 201 "Created". The Location header option MUST be included in the response when a new registration resource is created. This Location MUST be a stable identifier generated by the RD as it is used for all subsequent operations on this registration resource. The registration resource location thus returned is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered links, including updating and deleting links. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint with the name "node1" registering two resources to an RD using this interface. The location "/rd" is an example value of an RD base location. Req: POST coap://rd.example.com/rd?ep=3Dnode1 Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 2.01 Created Location: /rd/4521 Shelby, et al. Expires June 23, 2017 [Page 15] =0C Internet-Draft CoRE Resource Directory December 2016 A Resource Directory may optionally support HTTP. Here is an example of the same registration operation above, when done using HTTP. Req: POST /rd?ep=3Dnode1 HTTP/1.1 Host : example.com Content-Type: application/link-format Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" Res: 201 Created Location: /rd/4521 5.3.1. Simple Registration Not all endpoints hosting resources are expected to know how to upload links to a RD as described in Section 5.3. Instead, simple endpoints can implement the Simple Registration approach described in this section. An RD implementing this specification MUST implement Simple Registration. However, there may be security reasons why this form of directory discovery would be disabled. This approach requires that the endpoint makes available the hosted resources that it wants to be discovered, as links on its "/.well- known/core" interface as specified in [RFC6690]. The endpoint then finds one or more addresses of the directory server as described in Section 4. An endpoint can send (a selection of) hosted resources to a directory server for publication as described in Section 5.3.2. The directory server integrates the information it received this way into its resource directory. It MAY make the information available to further directories, if it can ensure that a loop does not form. The protocol used between directories to ensure loop-free operation is outside the scope of this document. 5.3.2. Simple publishing to Resource Directory Server An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds. The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. Shelby, et al. Expires June 23, 2017 [Page 16] =0C Internet-Draft CoRE Resource Directory December 2016 The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt, and et, in the POST request as per Section 5.3. The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. Req:(to RD server from [ff02::1]) POST coap://rd.example.com/.well-known/core?lt=3D6000;ep=3Dnode1 Content-Format: 40 payload: (empty payload) Res: 2.04 Changed (later) Req: (from RD server to [ff02::1]) GET coap://[ff02::1]/.well-known/core Accept: 40 Res: 2.05 Content payload: 5.3.3. Third-party registration For some applications, even Simple Directory Discovery may be too taxing for certain very constrained devices, in particular if the security requirements become too onerous. In a controlled environment (e.g. building control), the Resource Directory can be filled by a third device, called a commissioning tool. The commissioning tool can fill the Resource Directory from a database or other means. For that purpose the scheme, IP address and port of the registered device is indicated in the Context parameter of the registration described in Section 5.3. Shelby, et al. Expires June 23, 2017 [Page 17] =0C Internet-Draft CoRE Resource Directory December 2016 5.4. Operations on the Registration Resource After the initial registration, an endpoint should retain the returned location of the Registration Resource for further operations, including refreshing the registration in order to extend the lifetie and "keep-alive" the registration. If the lifetime of the registration expires, the RD SHOULD NOT respond to discovery queries with information from the endpoint. The RD SHOULD continue to provide access to the Registration Resource after a registration time-out occurs in order to enable the registering endpoint to eventually refresh the registration. The RD MAY eventually remove the registration resource for the purpose of resource recovery and garbage collection. If teh Registration Resource is removed, the endpoint will need to re-register. The Registration Resource may also be used to inspect the registration resource using GET, update the registration link contents using PATCH, or cancel the registration using DELETE. These operations are described in this section. 5.4.1. Registration Update The update interface is used by an endpoint to refresh or update its registration with an RD. To use the interface, the endpoint sends a POST request to the registration resource returned in the Location header option in the response returned from the intial registration operation. An update MAY update the lifetime or context registration parameters "lt", "con" as in Section 5.3 ) if the previous settings are to be retained. Parameters that are not being changed changed SHOULD NOT be included in an update. Adding parameters that have not changed increases the size of the message but does not have any other implications. Parameters MUST be included as query parameters in an update operation as in Section 5.3. Upon receiving an update request, an RD MUST reset the timeout for that endpoint and update the scheme, IP address and port of the endpoint, using the source address of the update, or the context ("con") parameter if present. If the lifetime parameter "lt" is included in the received update request, the RD MUST update the lifetime of the registration and set the timeout equal to the new lifetime. If the lifetime parameter is not included in the registration update, the most recent setting is re-used for the next registration time-out period. Shelby, et al. Expires June 23, 2017 [Page 18] =0C Internet-Draft CoRE Resource Directory December 2016 An update MAY optionally add or replace links for the endpoint by including those links in the payload of the update as a CoRE Link Format document. A link is replaced only if both the target URI and relation type match. In addition to the use of POST, as described in this section, there is an alternate way to add, replace, and delete links using PATCH as described in Section 5.4.4. The update registration request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+location}{?lt,con} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. lt :=3D Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, the previous last lifetime set on a previous update or the original registration (falling back to 86400) SHOULD be used. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port/path. In the absence of this parameter the scheme of the protocol, source address and source port of the register request are assumed. This parameter is mandatory when the directory is filled by a third party such as an commissioning tool. When con is used, scheme and host are mandatory and port and path parameters are optional. Content-Format: application/link-format (mandatory) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following response codes are defined for this interface: Success: 2.04 "Changed" or 204 "No Content" if the update was successfully processed. Shelby, et al. Expires June 23, 2017 [Page 19] =0C Internet-Draft CoRE Resource Directory December 2016 Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following example shows an endpoint updating its registration at an RD using this interface with the example location value: /rd/4521. Req: POST /rd/4521 Res: 2.04 Changed The following example shows an endpoint updating its registration with a new lifetime and context, changing an existing link, and adding a new link using this interface with the example location value /rd/4521. With the initial registration the client set the following values: o lifetime (lt)=3D500 o context (con)=3Dcoap://local-proxy-old.example.com:5683 o resource=3D ;ct=3D41;rt=3D"foobar";if=3D"sensor" Req: POST /rd/4521?lt=3D600&con=3D"coap://local-proxy.example.com:5683"= Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-f";if=3D"sensor", ;ct=3D41;rt=3D"door";if=3D"sensor" Res: 2.04 Changed 5.4.2. Registration Removal Although RD entries have soft state and will eventually timeout after their lifetime, an endpoint SHOULD explicitly remove its entry from the RD if it knows it will no longer be available (for example on shut-down). This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource. The removal request interface is specified as follows: Shelby, et al. Expires June 23, 2017 [Page 20] =0C Internet-Draft CoRE Resource Directory December 2016 Interaction: EP -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples shows successful removal of the endpoint from the RD with example location value /rd/4521. Req: DELETE /rd/4521 Res: 2.02 Deleted 5.4.3. Read Endpoint Links Some endpoints may wish to manage their links as a collection, and may need to read the current set of links stored in the registration resource, in order to determine link maintenance operations. One or more links MAY be selected by using query filtering as specified in [RFC6690] Section 4.1 The read request interface is specified as follows: Interaction: EP -> RD Method: GET Shelby, et al. Expires June 23, 2017 [Page 21] =0C Internet-Draft CoRE Resource Directory December 2016 URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" upon success with an "application/link-format", "application/link-format+cbor", or "application/link-format+json" payload. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples show successful read of the endpoint links from the RD, with example location value /rd/4521. Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" 5.4.4. Update Endpoint Links [This section will be removed before or as a result of a working- group last-call if the PATCH methods do not achieve the same level of consensus as the present document.] A PATCH update adds, removes or changes links for the endpoint by including link update information in the payload of the update as a merge-patch+json format [RFC7396] document. Shelby, et al. Expires June 23, 2017 [Page 22] =0C Internet-Draft CoRE Resource Directory December 2016 Other PATCH document formats may be used as appropriate for patching the array of objects format of a Registration Resource. In particular, a select-merge patch document format could combine the function of link selection query and link attribute replacement values. One or more links are selected for update by using query filtering as specified in [RFC6690] Section 4.1 The query filter selects the links to be modified or deleted, by matching the query parameter values to the values of the link attributes. When the query parameters are not present in the request, the payload specifies links to be added to the target document. When the query parameters are present, the attribute names and values in the query parameters select one or more links on which to apply the PATCH operation. If an attribute name specified in the PATCH document exists in any the set of selected links, all occurrences of the attribute value in the target document MUST be updated using the value from the PATCH payload. If the attribute name is not present in any selected links, the attribute MUST be added to the links. The update request interface is specified as follows: Interaction: EP -> RD Method: PATCH URI Template: /{+location}{?href,rel,rt,if,ct} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful earlier registration. href,rel,rt,if,ct :=3D link relations and attributes specified in the query in order to select particular links based on their relations and attributes. "href" denotes the URI target of the link. See [RFC6690] Sec. 4.1 Content-Format: application/merge-patch+json (mandatory) The following response codes are defined for this interface: Shelby, et al. Expires June 23, 2017 [Page 23] =0C Internet-Draft CoRE Resource Directory December 2016 Success: 2.04 "Changed" 0r 204 "No Content" in the update was successfully processed. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Registration resource does not exist (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The following examples show an endpoint adding , modifying , and removing links in RD using the Update Endpoint Links function with the example location value /rd/4521. The Registration Resource initial state is: Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" The following example shows an EP adding the link ;ct=3D41;rt=3D"humid-s";if=3D"sensor" to the collection of = links at the location /rd/4521. Req: PATCH /rd/4521 Payload: [{"href":"/sensors/humid","ct": 41, "rt": "humid-s", "if": "sensor"}] Content-Format: application/merge-patch+json Res: 2.04 Changed Shelby, et al. Expires June 23, 2017 [Page 24] =0C Internet-Draft CoRE Resource Directory December 2016 Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature", ;ct=3D41;rt=3D"light-lux";if=3D"sensor", ;ct=3D41;rt=3D"humid-s";if=3D"sensor" The following example shows an EP modifying all links at the example location /rd/4521 which are identified by href=3D"/sensors/temp", = from the initial link-value of ;rt=3D"temperature" to the = new link-value ;rt=3D"temperature-c";if=3D"sensor" by = changing the value of the link attribute "rt" and adding the link attribute if=3D"sensor" using the PATCH operation with the supplied merge- patch+json document payload. Req: PATCH /rd/4521?href=3D/sensors/temp Payload: {"rt": "temperature-c", "if": "sensor"}, Content-Format: application/merge-patch+json Res: 2.04 Changed Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"light-lux";if=3D"sensor", ;ct=3D41;rt=3D"humid-s";if=3D"sensor" This example shows an EP removing all links at the example location /rd/4521 which are identified by href=3D"/sensors/light". Req: PATCH /rd/4521?href=3D/sensors/light Payload: {} Content-Format: application/merge-patch+json Res: 2.04 Changed Shelby, et al. Expires June 23, 2017 [Page 25] =0C Internet-Draft CoRE Resource Directory December 2016 Req: GET /rd/4521 Res: 2.01 Content Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", ;ct=3D41;rt=3D"humid-s";if=3D"sensor" 6. RD Groups This section defines the REST API for the creation, management, and lookup of endpoints for group operations. Similar to endpoint registration entries in the RD, groups may be created or removed. However unlike an endpoint entry, a group entry consists of a list of endpoints and does not have a lifetime associated with it. In order to make use of multicast requests with CoAP, a group MAY have a multicast address associated with it. 6.1. Register a Group In order to create a group, a commissioning tool (CT) used to configure groups, makes a request to the RD indicating the name of the group to create (or update), optionally the domain the group belongs to, and optionally the multicast address of the group. The registration message includes the list of endpoints that belong to that group. All the endpoints in the group MUST be registered with the RD before registering a group. If an endpoint is not yet registered to the RD before registering the group, the registration message returns an error. The RD sends a blank target URI for every endpoint link when registering the group. Configuration of the endpoints themselves is out of scope of this specification. Such an interface for managing the group membership of an endpoint has been defined in [RFC7390]. The registration request interface is specified as follows: Interaction: CT -> RD Method: POST URI Template: /{+rd-group}{?gp,d,con} URI Template Variables: Shelby, et al. Expires June 23, 2017 [Page 26] =0C Internet-Draft CoRE Resource Directory December 2016 rd-group :=3D RD Group Base URI path (mandatory). This is the = path of the RD Group REST API. The value "rd-group" is recommended for this variable. gp :=3D Group Name (mandatory). The name of the group to be created or replaced, unique within that domain. The maximum length of this parameter is 63 bytes. d :=3D Domain (optional). The domain to which this group = belongs. The maximum length of this parameter is 63 bytes. Optional. When this parameter is elided, the RD MAY associate the endpoint with a configured default domain. con :=3D Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port/path. In the absence of this parameter the scheme of the protocol, source address and source port of the register request are assumed. This parameter is mandatory when the directory is filled by a third party such as an commissioning tool. When con is used, scheme and host are mandatory and port and path parameters are optional. Content-Format: application/link-format Content-Format: application/link-format+json Content-Format: application/link-format+cbor The following response codes are defined for this interface: Success: 2.01 "Created" or 201 "Created". The Location header option MUST be returned in response to a successful group CREATE operation. This Location MUST be a stable identifier generated by the RD as it is used for delete operations of the group registration resource. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". An Endpoint is not registered in the RD (e.g. may have expired). Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES Shelby, et al. Expires June 23, 2017 [Page 27] =0C Internet-Draft CoRE Resource Directory December 2016 The following example shows an EP registering a group with the name "lights" which has two endpoints to an RD using this interface. The base location value /rd-group is an example of an RD base location. Req: POST coap://rd.example.com/rd-group?gp=3Dlights Content-Format: 40 Payload: <>;ep=3D"node1", <>;ep=3D"node2" Res: 2.01 Created Location: /rd-group/12 6.2. Group Removal A group can be removed simply by sending a removal message to the location of the group registration resource which was returned when intially registering the group. Removing a group MUST NOT remove the endpoints of the group from the RD. The removal request interface is specified as follows: Interaction: CT -> RD Method: DELETE URI Template: /{+location} URI Template Variables: location :=3D This is the Location path returned by the RD as a result of a successful group registration. The following responses codes are defined for this interface: Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 4.04 "Not Found" or 404 "Not Found". Group does not exist. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES Shelby, et al. Expires June 23, 2017 [Page 28] =0C Internet-Draft CoRE Resource Directory December 2016 The following examples shows successful removal of the group from the RD with the example location value /rd-group/12. Req: DELETE /rd-group/12 Res: 2.02 Deleted 7. RD Lookup In order for an RD to be used for discovering resources registered with it, an optional lookup interface may be provided. This lookup interface is defined as a default, and it is assumed that RDs may also support lookups to return resource descriptions in alternative formats (e.g. Atom or HTML Link) or using more advanced interfaces (e.g. supporting context or semantic based lookup). RD Lookup allows lookups for domains, groups, endpoints and resources using attributes defined in this document and for use with the CoRE Link Format. The result of a lookup request is the list of links (if any) corresponding to the type of lookup. Thus, a domain lookup MUST return a list of domains, a group lookup MUST return a list of groups, an endpoint lookup MUST return a list of endpoints and a resource lookup MUST return a list of links to resources. RD Lookup does not expose registration resources directly, but returns link content from registration resource entries which satisfy RD Lookup queries. The lookup type is selected by a URI endpoint, which is indicated by a Resource Type as per Table 1 below: +-------------+--------------------+-----------+ | Lookup Type | Resource Type | Mandatory | +-------------+--------------------+-----------+ | Resource | core.rd-lookup-res | Mandatory | | Endpoint | core.rd-lookup-ep | Mandatory | | Domain | core.rd-lookup-d | Optional | | Group | core.rd-lookup-gp | Optional | +-------------+--------------------+-----------+ Table 1: Lookup Types Each endpoint and resource lookup result returns respectively the scheme (IP address and port) followed by the path part of the URI of every endpoint and resource inside angle brackets ("<>") and followed by the other parameters. Shelby, et al. Expires June 23, 2017 [Page 29] =0C Internet-Draft CoRE Resource Directory December 2016 The target of these links SHOULD be the actual location of the domain, endpoint or resource, but MAY be an intermediate proxy e.g. in the case of an HTTP lookup interface for CoAP endpoints. The domain lookup returns every lookup domain with a base RD resource value (e.g. "/rd") encapsulated within angle brackets. In case that a group does not implement any multicast address, the group lookup returns every group lookup with a group base resource value encapsulated within angle brackets (e.g. "/rd/look-up"). Otherwise, the group lookup returns the multicast address of the group inside angle brackets. Using the Accept Option, the requester can control whether this list is returned in CoRE Link Format ("application/link-format", default) or its alternate content-formats ("application/link-format+json" or "application/link-format+cbor"). The page and count parameters are used to obtain lookup results in specified increments using pagination, where count specifies how many links to return and page specifies which subset of links organized in sequential pages, each containing 'count' links, starting with link zero and page zero. Thus, specifying count of 10 and page of 0 will return the first 10 links in the result set (links 0-9). Count =3D = 10 and page =3D 1 will return the next 'page' containing links 10-19, = and so on. Multiple query parameters MAY be included in a lookup, all included parameters MUST match for a resource to be returned. The character'*' MAY be included at the end of a parameter value as a wildcard operator. RD Lookup requests MAY use any set of query parameters to match the registered attributes and relations. In addition, this interface MAY be used with queries that specify domains, endpoints, and groups. For example, a domain lookup filtering on groups would return a list of domains that contain the specified groups. An endpoint lookup filtering on groups would return a list of endpoints that are in the specified groups. The lookup interface is specified as follows: Interaction: Client -> RD Method: GET URI Template: /{+rd-lookup-base}/{lookup- type}{?d,res,ep,gp,et,rt,page,count,resource-param} Shelby, et al. Expires June 23, 2017 [Page 30] =0C Internet-Draft CoRE Resource Directory December 2016 URI Template Variables: rd-lookup-base :=3D RD Lookup Base URI path (mandatory). This is the base path for RD Lookup requests. The recommended value for this variable is: "rd-lookup". lookup-type :=3D ("ep", "res") (mandatory), ("d","gp") (optional) This variable is used to select the type of lookup to perform (endpoint, resource, domain, or group). The values are recommended defaults and MAY use other values as needed. The supported lookup-types SHOULD be listed in .well-known/core using the specified resource types. ep :=3D Endpoint name (optional). Used for endpoint, group and resource lookups. d :=3D Domain (optional). Used for domain, group, endpoint and resource lookups. res :=3D resource (optional). Used for domain, group, endpoint = and resource lookups. gp :=3D Group name (optional). Used for endpoint, group and resource lookups. page :=3D Page (optional). Parameter can not be used without the count parameter. Results are returned from result set in pages that contain 'count' links starting from index (page * count). Page numbering starts with zero. count :=3D Count (optional). Number of results is limited to = this parameter value. If the page parameter is also present, the response MUST only include 'count' links starting with the (page * count) link in the result set from the query. If the count parameter is not present, then the response MUST return all matching links in the result set. Link numbering starts with zero. rt :=3D Resource type (optional). Used for group, endpoint and resource lookups. et :=3D Endpoint type (optional). Used for group, endpoint and resource lookups. resource-param :=3D Link attribute parameters (optional). Any = link target attribute as defined in Section 4.1 of [RFC6690], used for resource lookups. Shelby, et al. Expires June 23, 2017 [Page 31] =0C Internet-Draft CoRE Resource Directory December 2016 Content-Format: application/link-format (optional) Content-Format: application/link-format+json (optional) Content-Format: application/link-format+cbor (optional) The following responses codes are defined for this interface: Success: 2.05 "Content" or 200 "OK" with an "application/link- format", "application/link-format+cbor", or "application/link- format+json" payload containing matching entries for the lookup. Failure: 4.04 "Not Found" or 404 "Not Found" in case no matching entry is found for a unicast request. Failure: No error response to a multicast request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Service could not perform the operation. HTTP support: YES The examples in this section assume CoAP hosts with a default CoAP port 61616. HTTP hosts are possible and do not change the nature of the examples. The following example shows a client performing a resource lookup with the example look-up location /rd-lookup/: Req: GET /rd-lookup/res?rt=3Dtemperature Res: 2.05 Content ;rt=3D"temperature" The following example shows a client performing an endpoint type lookup: Req: GET /rd-lookup/ep?et=3Dpower-node Res: 2.05 Content ;ep=3D"node5", ;ep=3D"node7" The following example shows a client performing a domain lookup: Shelby, et al. Expires June 23, 2017 [Page 32] =0C Internet-Draft CoRE Resource Directory December 2016 Req: GET /rd-lookup/d Res: 2.05 Content <>;d=3D"domain1", <>;d=3D"domain2" The following example shows a client performing a group lookup for all groups: Req: GET /rd-lookup/gp Res: 2.05 Content <>;gp=3D"lights1";d=3D"example.com" <>;gp=3D"lights2";d=3D"ecample.com" The following example shows a client performing a lookup for all endpoints in a particular group: Req: GET /rd-lookup/ep?gp=3Dlights1 Res: 2.05 Content ;ep=3D"node1", ;ep=3D"node2" The following example shows a client performing a lookup for all groups an endpoint belongs to: Req: GET /rd-lookup/gp?ep=3Dnode1 Res: 2.05 Content <>;gp=3D"lights1" The following example shows a client performing a paginated lookup Shelby, et al. Expires June 23, 2017 [Page 33] =0C Internet-Draft CoRE Resource Directory December 2016 Req: GET /rd-lookup/res?page=3D0&count=3D5 Res: 2.05 Content ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 Req: GET /rd-lookup/res?page=3D1&count=3D5 Res: 2.05 Content ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 ;rt=3Dsensor;ct=3D60 8. Security Considerations The security considerations as described in Section 7 of [RFC5988] and Section 6 of [RFC6690] apply. The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as described in [RFC7252]. DTLS or TLS based security SHOULD be used on all resource directory interfaces defined in this document. 8.1. Endpoint Identification and Authentication An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. Every operation performed by an Endpoint or Client on a resource directory SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key or Certificate based security. Endpoints using a Certificate MUST include the Endpoint identifier as the Subject of the Certificate, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. 8.2. Access Control Access control SHOULD be performed separately for the RD registration, Lookup, and group API base paths, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD. Such access control Shelby, et al. Expires June 23, 2017 [Page 34] =0C Internet-Draft CoRE Resource Directory December 2016 SHOULD be performed in as fine-grained a level as possible. For example access control for lookups could be performed either at the domain, endpoint or resource level. 8.3. Denial of Service Attacks Services that run over UDP unprotected are vulnerable to unknowingly become part of a DDoS attack as UDP does not require return routability check. Therefore, an attacker can easily spoof the source IP of the target entity and send requests to such a service which would then respond to the target entity. This can be used for large-scale DDoS attacks on the target. Especially, if the service returns a response that is order of magnitudes larger than the request, the situation becomes even worse as now the attack can be amplified. DNS servers have been widely used for DDoS amplification attacks. There is also a danger that NTP Servers could become implicated in denial-of-service (DoS) attacks since they run on unprotected UDP, there is no return routability check, and they can have a large amplification factor. The responses from the NTP server were found to be 19 times larger than the request. A Resource Directory (RD) which responds to wild-card lookups is potentially vulnerable if run with CoAP over UDP. Since there is no return routability check and the responses can be significantly larger than requests, RDs can unknowingly become part of a DDoS amplification attack. 9. IANA Considerations 9.1. Resource Types "core.rd", "core.rd-group", "core.rd-lookup-ep", "core.rd-lookup- res", "core.rd-lookup-d", and "core.rd-lookup-gp" resource types need to be registered with the resource type registry defined by [RFC6690]. 9.2. IPv6 ND Resource Directory Address Option This document registers one new ND option type under the subregistry "IPv6 Neighbor Discovery Option Formats": o Resource Directory address Option (38) 9.3. RD Parameter Registry This specification defines a new sub-registry for registration and lookup parameters called "RD Parameters" under "CoRE Parameters". Although this specification defines a basic set of parameters, it is Shelby, et al. Expires June 23, 2017 [Page 35] =0C Internet-Draft CoRE Resource Directory December 2016 expected that other standards that make use of this interface will define new ones. Each entry in the registry must include the human readable name of the parameter, the query parameter, validity requirements if any and a description. The query parameter MUST be a valid URI query key [RFC3986]. Initial entries in this sub-registry are as follows: +----------+-------+---------------+--------------------------------+ | Name | Query | Validity | Description | +----------+-------+---------------+--------------------------------+ | Endpoint | ep | | Name of the endpoint, max 63 | | Name | | | bytes | | Lifetime | lt | 60-4294967295 | Lifetime of the registration | | | | | in seconds | | Domain | d | | Domain to which this endpoint | | | | | belongs | | Endpoint | et | | Semantic name of the endpoint | | Type | | | | | Context | con | URI | The scheme, address and port | | | | | at which this server is | | | | | available | | Resource | res | | Name of the resource | | Name | | | | | Group | gp | | Name of a group in the RD | | Name | | | | | Page | page | Integer | Used for pagination | | Count | count | Integer | Used for pagination | +----------+-------+---------------+--------------------------------+ Table 2: RD Parameters The IANA policy for future additions to the sub-registry is "Expert Review" as described in [RFC5226]. 10. Examples Two examples are presented: a Lighting Installation example in Section 10.1 and a LWM2M example in Section 10.2. 10.1. Lighting Installation This example shows a simplified lighting installation which makes use of the Resource Directory (RD) with a CoAP interface to facilitate the installation and start up of the application code in the lights and sensors. In particular, the example leads to the definition of a Shelby, et al. Expires June 23, 2017 [Page 36] =0C Internet-Draft CoRE Resource Directory December 2016 group and the enabling of the corresponding multicast address. No conclusions must be drawn on the realization of actual installation or naming procedures, because the example only "emphasizes" some of the issues that may influence the use of the RD and does not pretend to be normative. The example uses the recommended values for the base resources: "/rd", "/rd-lookup", and "/rd-group". 10.1.1. Installation Characteristics The example assumes that the installation is managed. That means that a Commissioning Tool (CT) is used to authorize the addition of nodes, name them, and name their services. The CT can be connected to the installation in many ways: the CT can be part of the installation network, connected by WiFi to the installation network, or connected via GPRS link, or other method. It is assumed that there are two naming authorities for the installation: (1) the network manager that is responsible for the correct operation of the network and the connected interfaces, and (2) the lighting manager that is responsible for the correct functioning of networked lights and sensors. The result is the existence of two naming schemes coming from the two managing entities. The example installation consists of one presence sensor, and two luminaries, luminary1 and luminary2, each with their own wireless interface. Each luminary contains three lamps: left, right and middle. Each luminary is accessible through one endpoint. For each lamp a resource exists to modify the settings of a lamp in a luminary. The purpose of the installation is that the presence sensor notifies the presence of persons to a group of lamps. The group of lamps consists of: middle and left lamps of luminary1 and right lamp of luminary2. Before commissioning by the lighting manager, the network is installed and access to the interfaces is proven to work by the network manager. At the moment of installation, the network under installation is not necessarily connected to the DNS infra structure. Therefore, SLAAC IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in Table 3 below: Shelby, et al. Expires June 23, 2017 [Page 37] =0C Internet-Draft CoRE Resource Directory December 2016 +--------------------+--------------+ | Name | IPv6 address | +--------------------+--------------+ | luminary1 | FDFD::ABCD:1 | | luminary2 | FDFD::ABCD:2 | | Presence sensor | FDFD::ABCD:3 | | Resource directory | FDFD::ABCD:0 | +--------------------+--------------+ Table 3: interface SLAAC addresses In Section 10.1.2 the use of resource directory during installation is presented. 10.1.2. RD entries It is assumed that access to the DNS infrastructure is not always possible during installation. Therefore, the SLAAC addresses are used in this section. For discovery, the resource types (rt) of the devices are important. The lamps in the luminaries have rt: light, and the presence sensor has rt: p-sensor. The endpoints have names which are relevant to the light installation manager. In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door. The endpoint names reflect this physical location. The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively. The identifiers relevant to the Resource Directory are shown in Table 4 below: +----------------+------------------+---------------+---------------+ | Name | endpoint | resource path | resource type | +----------------+------------------+---------------+---------------+ | luminary1 | lm_R2-4-015_wndw | /light/left | light | | luminary1 | lm_R2-4-015_wndw | /light/middle | light | | luminary1 | lm_R2-4-015_wndw | /light/right | light | | luminary2 | lm_R2-4-015_door | /light/left | light | | luminary2 | lm_R2-4-015_door | /light/middle | light | | luminary2 | lm_R2-4-015_door | /light/right | light | | Presence | ps_R2-4-015_door | /ps | p-sensor | | sensor | | | | +----------------+------------------+---------------+---------------+ Table 4: Resource Directory identifiers Shelby, et al. Expires June 23, 2017 [Page 38] =0C Internet-Draft CoRE Resource Directory December 2016 The CT inserts the endpoints of the luminaries and the sensor in the RD using the Context parameter (con) to specify the interface address: Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_wndw&con=3Dcoap://[FDFD::ABCD:1] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light";d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4521 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dlm_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:2] Payload: ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015", ;rt=3D"light"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4522 Req: POST coap://[FDFD::ABCD:0]/rd ?ep=3Dps_R2-4-015_door&con=3Dcoap://[FDFD::ABCD:3] Payload: ;rt=3D"p-sensor"; d=3D"R2-4-015" Res: 2.01 Created Location: /rd/4523 The domain name d=3D"R2-4-015" has been added for an efficient lookup because filtering on "ep" name is more awkward. The same domain name is communicated to the two luminaries and the presence sensor by the CT. The group is specified in the RD. The Context parameter is set to the site-local multicast address allocated to the group. In the POST in the example below, these two endpoints and the endpoint of the presence sensor are registered as members of the group. Shelby, et al. Expires June 23, 2017 [Page 39] =0C Internet-Draft CoRE Resource Directory December 2016 Req: POST coap://[FDFD::ABCD:0]/rd-group ?gp=3Dgrp_R2-4-015;con=3D"coap//[FF05::1]" Payload: <>ep=3Dlm_R2-4-015_wndw, <>ep=3Dlm_R2-4-015_door, <>ep=3Dps_R2-4-015_door Res: 2.01 Created Location: /rd-group/501 After the filling of the RD by the CT, the application in the luminaries can learn to which groups they belong, and enable their interface for the multicast address. The luminary, knowing its domain, queries the RD for the endpoint with rt=3Dlight and d=3DR2-4-015. The RD returns all endpoints in = the domain. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep ?d=3DR2-4-015;rt=3Dlight Res: 2.05 Content ; ep=3D"lm_R2-4-015_wndw", ; ep=3D"lm_R2-4-015_door" Knowing its own IPv6 address, the luminary discovers its endpoint name. With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp ?ep=3Dlm_R2-4-015_wndw Res: 2.05 Content ;gp=3D"grp_R2-4-015" =46rom the context parameter value, the luminary learns the multicast address of the multicast group. Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in [RFC7390]. Shelby, et al. Expires June 23, 2017 [Page 40] =0C Internet-Draft CoRE Resource Directory December 2016 Req: POST //[FDFD::ABCD:1]/coap-group Content-Format: application/coap-group+json { "a": "[FF05::1]", "n": "grp_R2-4-015"} Res: 2.01 Created Location-Path: /coap-group/1 Dependent on the situation, only the address, "a", or the name, "n", is specified in the coap-group resource. 10.2. OMA Lightweight M2M (LWM2M) Example This example shows how the OMA LWM2M specification makes use of Resource Directory (RD). OMA LWM2M is a profile for device services based on CoAP(OMA Name Authority). LWM2M defines a simple object model and a number of abstract interfaces and operations for device management and device service enablement. An LWM2M server is an instance of an LWM2M middleware service layer, containing a Resource Directory along with other LWM2M interfaces defined by the LWM2M specification. CoRE Resource Directory (RD) is used to provide the LWM2M Registration interface. LWM2M does not provide for registration domains and does not currently use the rd-group or rd-lookup interfaces. The LWM2M specification describes a set of interfaces and a resource model used between a LWM2M device and an LWM2M server. Other interfaces, proxies, and applications are currently out of scope for LWM2M. The location of the LWM2M Server and RD base URI path is provided by the LWM2M Bootstrap process, so no dynamic discovery of the RD is used. LWM2M Servers and endpoints are not required to implement the ./well-known/core resource. 10.2.1. The LWM2M Object Model The OMA LWM2M object model is based on a simple 2 level class hierarchy consisting of Objects and Resources. An LWM2M Resource is a REST endpoint, allowed to be a single value or an array of values of the same data type. Shelby, et al. Expires June 23, 2017 [Page 41] =0C Internet-Draft CoRE Resource Directory December 2016 An LWM2M Object is a resource template and container type that encapsulates a set of related resources. An LWM2M Object represents a specific type of information source; for example, there is a LWM2M Device Management object that represents a network connection, containing resources that represent individual properties like radio signal strength. Since there may potentially be more than one of a given type object, for example more than one network connection, LWM2M defines instances of objects that contain the resources that represent a specific physical thing. The URI template for LWM2M consists of a base URI followed by Object, Instance, and Resource IDs: {/base-uri}{/object-id}{/object-instance}{/resource-id}{/resource- instance} The five variables given here are strings. base-uri can also have the special value "undefined" (sometimes called "null" in RFC 6570). Each of the variables object-instance, resource-id, and resource- instance can be the special value "undefined" only if the values behind it in this sequence also are "undefined". As a special case, object-instance can be "empty" (which is different from "undefined") if resource-id is not "undefined". [_TEMPLATE_TODO] base-uri :=3D Base URI for LWM2M resources or "undefined" for default (empty) base URI object-id :=3D OMNA (OMA Name Authority) registered object ID = (0-65535) object-instance :=3D Object instance identifier (0-65535) or "undefined"/"empty" (see above)) to refer to all instances of an object ID resource-id :=3D OMNA (OMA Name Authority) registered resource ID (0-65535) or "undefined" to refer to all resources within an instance resource-instance :=3D Resource instance identifier or "undefined" to refer to single instance of a resource LWM2M IDs are 16 bit unsigned integers represented in decimal (no leading zeroes except for the value 0) by URI format strings. For example, a LWM2M URI might be: /1/0/1 Shelby, et al. Expires June 23, 2017 [Page 42] =0C Internet-Draft CoRE Resource Directory December 2016 The base uri is empty, the Object ID is 1, the instance ID is 0, the resource ID is 1, and the resource instance is "undefined". This example URI points to internal resource 1, which represents the registration lifetime configured, in instance 0 of a type 1 object (LWM2M Server Object). 10.2.2. LWM2M Register Endpoint LWM2M defines a registration interface based on the REST API, described in Section 5. The base URI path of the LWM2M Resource Directory is specified to be "/rd" as recommended in Section 5.3. LWM2M endpoints register object IDs, for example , to indicate that a particular object type is supported, and register object instances, for example , to indicate that a particular instance of that object type exists. Resources within the LWM2M object instance are not registered with the RD, but may be discovered by reading the resource links from the object instance using GET with a CoAP Content-Format of application/ link-format. Resources may also be read as a structured object by performing a GET to the object instance with a Content-Format of senml+json. When an LWM2M object or instance is registered, this indicates to the LWM2M server that the object and its resources are available for management and service enablement (REST API) operations. LWM2M endpoints may use the following RD registration parameters as defined in Table 2 : ep - Endpoint Name lt - registration lifetime Endpoint Name is mandatory, all other registration parameters are optional. Additional optional LWM2M registration parameters are defined: Shelby, et al. Expires June 23, 2017 [Page 43] =0C Internet-Draft CoRE Resource Directory December 2016 +------------+-------+-------------------------------+--------------+ | Name | Query | Validity | Description | +------------+-------+-------------------------------+--------------+ | Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available | | Binding | | | Protocols | | | | | | | LWM2M | ver | 1.0 | Spec Version | | Version | | | | | | | | | | SMS Number | sms | | MSISDN | +------------+-------+-------------------------------+--------------+ Table 5: LWM2M Additional Registration Parameters The following RD registration parameters are not currently specified for use in LWM2M: et - Endpoint Type con - Context The endpoint registration must include a payload containing links to all supported objects and existing object instances, optionally including the appropriate link-format relations. Here is an example LWM2M registration payload: ,,, This link format payload indicates that object ID 1 (LWM2M Server Object) is supported, with a single instance 0 existing, object ID 3 (LWM2M Device object) is supported, with a single instance 0 existing, and object 5 (LWM2M Firmware Object) is supported, with no existing instances. 10.2.3. LWM2M Update Endpoint Registration An LWM2M Registration update proceeds as described in Section 5.4.1, and adds some optional parameter updates: lt - Registration Lifetime b - Protocol Binding sms - MSISDN link payload - new or modified links A Registration update is also specified to be used to update the LWM2M server whenever the endpoint's UDP port or IP address are changed. Shelby, et al. Expires June 23, 2017 [Page 44] =0C Internet-Draft CoRE Resource Directory December 2016 10.2.4. LWM2M De-Register Endpoint LWM2M allows for de-registration using the delete method on the returned location from the initial registration operation. LWM2M de- registration proceeds as described in Section 5.4.2. 11. Acknowledgments Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola, Linyi Tian, Chistian Amsuss, and Jan Newmarch have provided helpful comments, discussions and ideas to improve and shape this document. Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. 12. Changelog changes from -09 to -10 o removed "ins" and "exp" link-format extensions. o removed all text concerning DNS-SD. o removed inconsistency in RDAO text. o suggestions taken over from various sources o replaced "Function Set" with "REST API", "base URI", "base path" o moved simple registration to registration section changes from -08 to -09 o clarified the "example use" of the base RD resource values /rd, /rd-lookup, and /rd-group. o changed "ins" ABNF notation. o various editorial improvements, including in examples o clarifications for RDAO changes from -07 to -08 o removed link target value returned from domain and group lookup types Shelby, et al. Expires June 23, 2017 [Page 45] =0C Internet-Draft CoRE Resource Directory December 2016 o Maximum length of domain parameter 63 bytes for consistency with group o removed option for simple POST of link data, don't require a .well-known/core resource to accept POST data and handle it in a special way; we already have /rd for that o add IPv6 ND Option for discovery of an RD o clarify group configuration section 6.1 that endpoints must be registered before including them in a group o removed all superfluous client-server diagrams o simplified lighting example o introduced Commissioning Tool o RD-Look-up text is extended. changes from -06 to -07 o added text in the discovery section to allow content format hints to be exposed in the discovery link attributes o editorial updates to section 9 o update author information o minor text corrections Changes from -05 to -06 o added note that the PATCH section is contingent on the progress of the PATCH method changes from -04 to -05 o added Update Endpoint Links using PATCH o http access made explicit in interface specification o Added http examples Changes from -03 to -04: o Added http response codes Shelby, et al. Expires June 23, 2017 [Page 46] =0C Internet-Draft CoRE Resource Directory December 2016 o Clarified endpoint name usage o Add application/link-format+cbor content-format Changes from -02 to -03: o Added an example for lighting and DNS integration o Added an example for RD use in OMA LWM2M o Added Read Links operation for link inspection by endpoints o Expanded DNS-SD section o Added draft authors Peter van der Stok and Michael Koster Changes from -01 to -02: o Added a catalogue use case. o Changed the registration update to a POST with optional link format payload. Removed the endpoint type update from the update. o Additional examples section added for more complex use cases. o New DNS-SD mapping section. o Added text on endpoint identification and authentication. o Error code 4.04 added to Registration Update and Delete requests. o Made 63 bytes a SHOULD rather than a MUST for endpoint name and resource type parameters. Changes from -00 to -01: o Removed the ETag validation feature. o Place holder for the DNS-SD mapping section. o Explicitly disabled GET or POST on returned Location. o New registry for RD parameters. o Added support for the JSON Link Format. o Added reference to the Groupcomm WG draft. Shelby, et al. Expires June 23, 2017 [Page 47] =0C Internet-Draft CoRE Resource Directory December 2016 Changes from -05 to WG Document -00: o Updated the version and date. Changes from -04 to -05: o Restricted Update to parameter updates. o Added pagination support for the Lookup interface. o Minor editing, bug fixes and reference updates. o Added group support. o Changed rt to et for the registration and update interface. Changes from -03 to -04: o Added the ins=3D parameter back for the DNS-SD mapping. o Integrated the Simple Directory Discovery from Carsten. o Editorial improvements. o Fixed the use of ETags. o Fixed tickets 383 and 372 Changes from -02 to -03: o Changed the endpoint name back to a single registration parameter ep=3D and removed the h=3D and ins=3D parameters. o Updated REST interface descriptions to use RFC6570 URI Template format. o Introduced an improved RD Lookup design as its own function set. o Improved the security considerations section. o Made the POST registration interface idempotent by requiring the ep=3D parameter to be present. Changes from -01 to -02: o Added a terminology section. Shelby, et al. Expires June 23, 2017 [Page 48] =0C Internet-Draft CoRE Resource Directory December 2016 o Changed the inclusion of an ETag in registration or update to a MAY. o Added the concept of an RD Domain and a registration parameter for it. o Recommended the Location returned from a registration to be stable, allowing for endpoint and Domain information to be changed during updates. o Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. 13. References 13.1. Normative References [I-D.ietf-core-links-json] Li, K., Rahman, A., and C. Bormann, "Representing CoRE Formats in JSON and CBOR", draft-ietf-core-links-json-06 (work in progress), July 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . Shelby, et al. Expires June 23, 2017 [Page 49] =0C Internet-Draft CoRE Resource Directory December 2016 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, . 13.2. Informative References [dns-sd] "DNS-SD extracted part to be submitted separately", n.d.. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . Editorial Comments [_TEMPLATE_TODO] This text needs some help from an RFC 6570 expert. Authors' Addresses Zach Shelby ARM 150 Rose Orchard San Jose 95134 USA Phone: +1-408-203-9434 Email: zach.shelby@arm.com Shelby, et al. Expires June 23, 2017 [Page 50] =0C Internet-Draft CoRE Resource Directory December 2016 Michael Koster SmartThings 665 Clyde Avenue Mountain View 94043 USA Phone: +1-707-502-5136 Email: Michael.Koster@smartthings.com Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Peter van der Stok consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Shelby, et al. Expires June 23, 2017 [Page 51] --Apple-Mail=_88AA6468-5E68-49AB-958D-08123CFBB02E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
--Apple-Mail=_88AA6468-5E68-49AB-958D-08123CFBB02E-- --Apple-Mail=_367BA14B-3344-4D93-B654-7734E7F0546F-- From nobody Mon Feb 27 13:13:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11C412A343 for ; Mon, 27 Feb 2017 13:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiZd2ApJdkj9 for ; Mon, 27 Feb 2017 13:12:59 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C634512A0CF for ; Mon, 27 Feb 2017 13:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1RLCoTg026520; Mon, 27 Feb 2017 22:12:50 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vXDv635T0zDHsY; Mon, 27 Feb 2017 22:12:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <2FEB83DB-873A-42BE-BADF-51AE72104205@gmail.com> Date: Mon, 27 Feb 2017 22:12:49 +0100 X-Mao-Original-Outgoing-Id: 509922768.645738-cd72769a0c5a42e4d24b2e01b5c3eb81 Content-Transfer-Encoding: quoted-printable Message-Id: <6B284358-61A7-4E73-A54D-298B466E0E8F@tzi.org> References: <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com> <2FEB83DB-873A-42BE-BADF-51AE72104205@gmail.com> To: Michael Koster X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Adding CRUD to the core.ll interface; was Re: draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 21:13:01 -0000 On 27 Feb 2017, at 21:45, Michael Koster = wrote: >=20 > The PATCH method on links > MUST use the JSON Merge-Patch Content-Format (application/merge- > patch+json) specified in [RFC7396]. I=E2=80=99m not a big fan of requiring constrained nodes to do JSON. (Time for Peter and me to finish the CBOR merge-patch=E2=80=A6) The way merge-patch and query parameters work together probably needs = some explanation and some examples. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 27 13:54:39 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA24129401 for ; Mon, 27 Feb 2017 13:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s6CiL6a20qX for ; Mon, 27 Feb 2017 13:54:36 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::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 724141279EB for ; Mon, 27 Feb 2017 13:54:36 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id p5so25189612pga.1 for ; Mon, 27 Feb 2017 13:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ssXqnmmnXB72PvftyF14zKjD7bQNn0pW1C8/puYpcn4=; b=GXqJsABrI+0KEKWJwhciYwAhhwRcvpNJd/b+GJ6YvoDjxjMwN4fj6HAJSFwwwOYlqX /w5NJIRCQJPgx8Otcxhu2EyAHeSGR9WeFYBYbF2J27cd+Hac6X/kCKfIb9p5omOFnct/ rrHzV9vwQm+N6k9Ya8/exX8KQ7Mm63DWUXusRFV2lSc3tkzHa01smpwPEfT2rqcVgCwa remDrikFmFfg6o9z9Qz0aYmfubGYOYcAPdA6vMH5NfhyZrrkCb2JxcwyC5V9J0FluAnE v3xy4PPLqC8jkR65K37OndZazamyI2Qf5QMnYJ2xjiW4noz5O3GpQtf59CW7IsVDnPQH 4COQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ssXqnmmnXB72PvftyF14zKjD7bQNn0pW1C8/puYpcn4=; b=dV/9LrAhZa+18lP6JK9wjHko6P8/cpnhR4UKigIFT55Lhz/ZqUY/OBpMN/GAn2vv4y yItj3vGBHfIh5mTIsq7DNYY1b6QvCiYKH4eeSJiZT2ZEt+weYoXSBNXeDsxFguaAvVT2 YMqeejRK1CZlZftTK03hzXUfl1O1L1xLMaXm+Os11owyxYA6xoWNc4MRRfzwGdQKaXJf MqQ/TxBXWL4Zi4icWg5iII78KD+tFjgtIIc2yGtPUAZGJ/o0jAPt4hDCsWINPwPr0hC6 kgLkZp8lPuwBuzfJk9QnmkJ+xB0jbNvjDzxse5RbBGw6QJmNSzHKyaKqDSC6Z8vZ/l2G 1Bjg== X-Gm-Message-State: AMke39nfYgMpsQlxbelegs8X5K3LtEB709VFGBQ4sKs5U67Yfb50Re7/bvUUD4roLRTmuw== X-Received: by 10.84.231.134 with SMTP id g6mr27595712plk.110.1488232476043; Mon, 27 Feb 2017 13:54:36 -0800 (PST) Received: from [172.18.40.215] ([50.225.220.36]) by smtp.gmail.com with ESMTPSA id n73sm32334470pfa.9.2017.02.27.13.54.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Feb 2017 13:54:35 -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: <6B284358-61A7-4E73-A54D-298B466E0E8F@tzi.org> Date: Mon, 27 Feb 2017 13:54:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com> <2FEB83DB-873A-42BE-BADF-51AE72104205@gmail.com> <6B284358-61A7-4E73-A54D-298B466E0E8F@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Adding CRUD to the core.ll interface; was Re: draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 21:54:37 -0000 Yes, we MUST NOT require JSON...=20 I will create some examples of query selection and merge-patch updates, = and further explanation, as we will need it in RD anyway. Best regards, MIchael > On Feb 27, 2017, at 1:12 PM, Carsten Bormann wrote: >=20 > On 27 Feb 2017, at 21:45, Michael Koster = wrote: >>=20 >> The PATCH method on links >> MUST use the JSON Merge-Patch Content-Format (application/merge- >> patch+json) specified in [RFC7396]. >=20 > I=E2=80=99m not a big fan of requiring constrained nodes to do JSON. > (Time for Peter and me to finish the CBOR merge-patch=E2=80=A6) >=20 > The way merge-patch and query parameters work together probably needs = some explanation and some examples. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Mon Feb 27 15:59:15 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B029127077 for ; Mon, 27 Feb 2017 15:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svSQs-HV58R8 for ; Mon, 27 Feb 2017 15:59:12 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (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 9C993126DFB for ; Mon, 27 Feb 2017 15:59:12 -0800 (PST) Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:52112 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ciVC8-003xKe-Pc; Tue, 28 Feb 2017 10:59:08 +1100 To: Michael Koster References: <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com> From: Christian Groves Message-ID: <44c1dca2-b7ce-3056-d8fb-a6e01a5c7823@gmail.com> Date: Tue, 28 Feb 2017 10:59:05 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 23:59:14 -0000 Hello Michael, Please see below. Regards, Christian On 28/02/2017 2:25 AM, Michael Koster wrote: > Hi, > > Clarifications below. > > Michael > >> On Feb 26, 2017, at 11:21 PM, Christian Groves wrote: >> >> Hello Michael, >> >> Thanks for the comments. Please see below. >> >> Regards, Christian >> >> >> On 26/02/2017 7:16 AM, Michael Koster wrote: >>> Hi Christian, >>> >>> I have been thinking about the use case that we exposed in OCF recently, integrating pubsub and other cloud services into a system of existing server-based sensors. Currently there is no well defined way to get a sensor device to push changes to a broker or to get an actuator device to subscribe to a topic on a broker. Likewise, there is on way to instruct the broker to observe a resource on a sensor, or to instruct a broker to update an actuator when a topic is published to on the broker. >>> >>> A binding table, on the devices or on the broker, or both, is a good solution for this and enables the system-wide state update relationships to be maintained in a visible, manageable way. >>> >>> I have a couple of comments on the current draft. >>> >>> 1. Why don't we use a resource type for the binding table? Its methods and responses conform to a generic link list interface, but the content and side effects are specialized to bindings. I thought we earlier had used rt=core.bnd as a resource type to identify the binding table. >> [CNG] I had a look through all the previous drafts (including the Shelby ones) and didn't see any examples of rt=core.bnd . Core.bnd is only used in the context of a interface description. Can you recall where it may have been used? >> However I can't see why we couldn't formally define a rt=core.bnd . The draft is pretty clear that a binding table is a resource. > [MJK] Yes, I am proposing that the binding table use the core.ll interface, which is basically a collection resource that exposes core link-format. It can be identified as a binding table by using rt=core.bnd as a resource type, rather than a special interface type. I had intended to make this change when I made core.ll support create, update, and delete operations. [CNG] OK I didn't realise that you wanted to remove the binding interface in favour of using the link list interface. I think its good to reuse than to create specialised interfaces. Is there anyone who would complain with this change? > >>> 2. We could make the example explicitly name the href of the sensor "switch" and the actuator "light" to help illustrate the directional pattern of observe the link target and update the link context: >>> >>> ;rel="boundto";anchor="/a/light";bind="obs";pmin="10";pmax="60" >> [CNG] OK that makes sense. >>> 3. I think we will need to register the new link attribute names with IANA: "pmin", "pmax", "lth", "gth", "stp", "bind" >> [CNG] I agree so that we avoid the problem of query parameter overloading. I think its part of a larger issue. E.g. sect.12.4/draft-ietf-core-resource-directory-09 proposes a new CoAP RD specific registry for query parameters. Should the query parameter registry be something specific or general for CoAP? >> > [MJK] If we want to avoid conflicts, there will need to be some coordination across the document-specific registries. Why not use the IANA CoRE Parameters Registry or some evolution thereof? [CNG] Yes exactly. However do we need document specific registries? We could update the RD draft to create a generic registry for CoAP query parameters. I think this could easily be achieved by adding an extra column to the table in section 12.4/draft-ietf-core-resource-directory indicating some sort of context/scope e.g. the applicable interface description or resource types. >>> 4. Speaking of attributes, I don't think "bind" is strictly needed to identify whether to push or pull; that is implied by whether the anchor and href are local or remote. I can conceive of a case where the binding both observes and pushes: >>> >>> ;rel="boundto";anchor="coap://example.com/pubsub/light";pmin="10";pmax="60" >>> >>> We may instead want to identify what operations are used for both source (link target/href) and destination (link context/anchor), perhaps change it to the explicit: src=obs; dst=push with default being observe used on the source and update (push) used on the target. >> [CNG] Would introducing two attributes instead make it more complicated? Effectively we're just representing what is expressed by a single code point into 2 code points. Couldn't you cover the above use case by having two table entries? >> > [MJK] I think two attributes are necessary to support the case where both links point to resources under a different netloc, where there is no RESThook or other back channel access method to the resource. The source link will use polling or observe, and the destination link will use push. I also see a use case for defining, in the push binding, whether to use PUT or POST. > > [MJK] Even for the case where the source link is local, there is still a choice of polling vs. reacting to resource state changes. Periodic polling is often required to run some algorithms like PID controllers. > > [MJK] I think it can be easily explained using a table listing the cases for local vs. remote and source vs. destination addresses and what the options are. [CNG] Maybe its best to draw up the table with the options first. I agree there's options for source and destination. What I was trying to say is that rather than having to parse two parameters it may be better to have one that has a value that is a "key" to a particular combination in the table. > > > From nobody Mon Feb 27 16:21:37 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8897129457 for ; Mon, 27 Feb 2017 16:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t789h0BGFUH6 for ; Mon, 27 Feb 2017 16:21:34 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (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 B361A129400 for ; Mon, 27 Feb 2017 16:21:34 -0800 (PST) Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:52780 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ciVXo-003zBu-Oa; Tue, 28 Feb 2017 11:21:32 +1100 To: Michael Koster References: <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com> <2FEB83DB-873A-42BE-BADF-51AE72104205@gmail.com> From: Christian Groves Message-ID: <3c5bb910-0fbe-64cf-901c-6cba021d7150@gmail.com> Date: Tue, 28 Feb 2017 11:21:29 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2FEB83DB-873A-42BE-BADF-51AE72104205@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Adding CRUD to the core.ll interface; was Re: draft-groves-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 00:21:36 -0000 Hello Michael, The abstracts contains the link to the github repository: Interfaces -> https://github.com/core-wg/interfaces Dynlink -> https://github.com/core-wg/dynlink The latest versions are up there now. Regards, Christian On 28/02/2017 7:45 AM, Michael Koster wrote: > >> On Feb 27, 2017, at 7:25 AM, Michael Koster >> > wrote: >> >> [MJK] Yes, I am proposing that the binding table use the core.ll >> interface, which is basically a collection resource that exposes core >> link-format. It can be identified as a binding table by using >> rt=core.bnd as a resource type, rather than a special interface type. >> I had intended to make this change when I made core.ll support >> create, update, and delete operations. > > I am proposing to add CRUD functionality to core.ll collections, as > described in section 3.4 of CoRE Interfaces, and which is consistent > with the current draft of CoRE Resource Directory, section 5.4 (attached) > > Links in the collection MAY be Read, Updated, Added, or Removed using > the CoRE Link-Format or JSON Merge-Patch Content-Formats on the > collection resource. Reading links uses the GET method and returns > an array or list containing the link-values of all selected links. > Links may be added to the collection using POST or PATCH methods. > Updates to links MUST use the PATCH method and MAY use query > filtering to select links for updating. The PATCH method on links > MUST use the JSON Merge-Patch Content-Format (application/merge- > patch+json) specified in [RFC7396]. > Currently, core.ll only has GET defined (Table 2), but IMO there is no > reason not to add the full set of methods including PATCH. THe query > parameter selects one or more links for updating, and the merge-patch > document is applied to each selected link. > > At one point we discussed putting this into a separate document that > can be referenced from both RD and CoRE Interfaces, but it seems to > belong more in interfaces, where collections are described. > > Is there a place I could make a pull request to for a proposed update > to Section 4.1 of the CoRE Interfaces document? I am in the middle of > updating the description in CoRE RD and could do this relatively quickly. > > Also have some proposed tweaks to align b and lb interface definitoins > with OCF, but that is a separate proposal. > > Best regards, > > Michael > > > From nobody Mon Feb 27 17:39:55 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8220129471; Mon, 27 Feb 2017 17:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0lAo8ewcV6k; Mon, 27 Feb 2017 17:39:52 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0133.outbound.protection.outlook.com [104.47.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AE612944F; Mon, 27 Feb 2017 17:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fut15zuYHvprkYnM/VbXO2UiRIcA5gRCqmDSUXqW1jY=; b=f5dLCe/1Res6BzkDxDlfBGy5X7AWwNpj8R/e+AyvY08YfMLvb8ca+WFUfK5fgZxkKgB+q4WHQGCF3BjFuAHzdkZsgTDMEGkDBs9/TvG8hheNqHAcBgRGyIgi/p5PgTifEk1qRe7sG/p0FOi3FeUMKXAe9XOxG3UlCDnAr47h7Cc= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Tue, 28 Feb 2017 01:39:50 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0933.019; Tue, 28 Feb 2017 01:39:50 +0000 From: Brian Raymor To: "Dijk, Esko" , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRs?= =?utf-8?Q?s?= Thread-Index: AQHSi4yee9Z5uDeEu0iK64KUh2FUd6F9rjRA Date: Tue, 28 Feb 2017 01:39:50 +0000 Message-ID: References: <7ecb932aad934f85bd8dbd81af48fd3b@AM3PR90MB0097.MGDPHG.emi.philips.com> In-Reply-To: <7ecb932aad934f85bd8dbd81af48fd3b@AM3PR90MB0097.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: philips.com; dkim=none (message not signed) header.d=none;philips.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 9aa58126-9d7d-457f-4194-08d45f7aafb9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2380; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:Nw61j0m8/j54Hl+LovFI5bihJktL8u+ycCHpaYVOWhWz5Tg4zN+QUTBHq5Kyfcv2m1HwLXn+wp3CE6NltxM24M1I1GafefYm5+XQSj2hnEC+UJaSYGmo/vm71atX0qKervVTf7Zz0WC3seOF9F80Q9KW5Sd9vutBg4jIxtJXjo1hSQBjoyi142FrM0MMsb4q9IuuMkFzYNRfkVU5tmNuFeDehaJ86QWTL2V8QCUlUBkY+2KQWvBG0P7fD1PyICrN1asLYCZ3qDzrdcRD/TmHOzK1aI4cZwzCQ2UTpIqoZZn/9dlZ18v1rF7Cu3ouOUtNyif9xmr+wjDuEqd5ZDW19pm6lvSV4AWcE/6bhxn0prA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39860400002)(39840400002)(39450400003)(51914003)(3280700002)(10090500001)(122556002)(5660300001)(92566002)(53936002)(2906002)(10290500002)(4326007)(7736002)(8936002)(86362001)(86612001)(189998001)(229853002)(81166006)(106116001)(2950100002)(229383001)(3660700001)(76176999)(25786008)(230783001)(6436002)(66066001)(6246003)(33656002)(55016002)(6306002)(54896002)(54906002)(99286003)(5005710100001)(8990500004)(54356999)(38730400002)(77096006)(790700001)(2900100001)(6506006)(7696004)(3846002)(102836003)(74316002)(6116002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2380CF66BE0E575AA969A5A283560CY1PR03MB2380namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 01:39:50.3724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 01:39:53 -0000 --_000_CY1PR03MB2380CF66BE0E575AA969A5A283560CY1PR03MB2380namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcXVlc3Rpb25zIGFuZCBmZWVkYmFjay4gUGFydGlhbCByZXNwb25zZXMg YmVsb3cuDQoNCg0KDQoqKiBRdWVzdGlvbnMNCg0KPiDigKIgVGhlIGJpLWRpcmVjdGlvbmFsaXR5 IG9mIGNvbm5lY3Rpb25zIGlzIG1lbnRpb25lZCBpbiB0aGUgZHJhZnQuIE5vdyBzdXBwb3NlIGEg Q29BUCBjbGllbnQgb24gaG9zdCAxIG9wZW5zIGEgVENQIGNvbm5lY3Rpb24NCg0KPiAoYXMgYSBU Q1AgY2xpZW50KSB0byBhIFRDUCBzZXJ2ZXIgb24gaG9zdCAyLCBpbiBvcmRlciB0byBzZW5kIGEg Q29BUCByZXF1ZXN0IHRvIGl0LiBOb3cgdGhlIFRDUCBzZXJ2ZXIgKGhvc3QgMikgYXQgc29tZSBw b2ludCBzdWRkZW5seQ0KDQo+IHNlbmRzIGEgQ29BUCByZXF1ZXN0IChhY3RpbmcgaXRzZWxmIGFz IGEgQ29BUCBjbGllbnQpIHRvIHRoZSBUQ1AgY2xpZW50IChob3N0IDEpLiBIb3dldmVyLCB0aGVy ZSBpcyBubyBDb0FQIHNlcnZlciBob3N0ZWQgb24gaG9zdCAxLg0KDQo+IFdoYXQgc2hvdWxkIGhh cHBlbiBub3c/IEUuZy4gaXMgdGhlIHJlcXVlc3Qgc2ltcGx5IGlnbm9yZWQgb3IgaXMgc29tZSBr aW5kIG9mIGVycm9yIG1lc3NhZ2UgcmV0dXJuZWQ/DQoNCj4g4oCiIFNhbWUgcXVlc3Rpb24gYXMg YWJvdmUgY2FuIGJlIHN0YXRlZCBmb3IgVExTIGFuZCBXZWJzb2NrZXRzLiBJcyB0aGUgYmVoYXZp b3IgdGhlIHNhbWUgaW4gdGhlc2UgY2FzZXM/DQoNCj4g4oCiIEZvbGxvd2luZyB0aGUgYWJvdmUs IHNob3VsZCB0aGUgQ1NNIG1lc3NhZ2UgaGF2ZSBhbiBvcHRpb24gdG8gaW5kaWNhdGUgYSBjYXBh YmlsaXR5IG9mICJiZWluZyBhIENvQVAgc2VydmVyIiDigKYgPw0KDQoNCg0KQ2Fyc3RlbidzIHN1 Z2dlc3Rpb24gb24gYSBwcml2YXRlIHRocmVhZCBhZGRyZXNzZXMgdGhpcyBzZXQgb2YgcXVlc3Rp b25zOg0KDQogICAgIlRoZSBpbnRlbnRpb24gaXMgZm9yIHRoZSB0cmFuc3BvcnQgdG8gYmUgYmlk aXJlY3Rpb25hbC4gSWYgdGhlcmUgaXMgYSBDb0FQIGNsaWVudCwgaXQgaXMgZWFzeSB0byBoYXZl IGEgQ29BUCBzZXJ2ZXIgdGhhdCA0LjA0cyBldmVyeSByZXF1ZXN0LiBZZXMsIHRoYXQgaXMgd29y dGggbWFraW5nIGV4cGxpY2l0LiINCg0KDQoNCj4g4oCiIFBhZ2UgMjA6IEFsdGVybmF0aXZlLUFk ZHJlc3MgT3B0aW9uIC0gdGhlIHNlbWFudGljcyBvZiBpbmNsdWRpbmcgbXVsdGlwbGUgb2YgdGhl c2Ugb3B0aW9ucyBpcyBub3QgZGVmaW5lZC4gQ2FuIHRoZSByZWNlaXZlciBwaWNrIGFueSBvZiB0 aGUgYWRkcmVzc2VzPw0KDQo+IE9yIGRvZXMgaXQgbmVlZCB0byB0cnkgdGhlIGZpcnN0IGFkZHJl c3MgZmlyc3Q/IEFuZCB0aGVuIGtlZXAgdHJ5aW5nIGFsbCBhbHRlcm5hdGl2ZXMgdW50aWwgb25l IHN1Y2NlZWRzLCBvciBub3Q/DQoNCg0KDQpVbmxlc3MgQ2Fyc3RlbiBvciBIYW5uZXMgKGF1dGhv cnMgb2YgZHJhZnQtYm9ybWFubi1jb3JlLWNvYXAtc2lnLTAyKSBoYXZlIGEgcHJlZmVyZW5jZSwg SSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIGFkZHJlc3NlcyBhcmUgdW5vcmRlcmVkIChwaWNrIGFu eSkuDQoNClRyYWNrZWQgaW4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxz L2lzc3Vlcy8xMTUNCg0KDQoNCj4g4oCiIFBhZ2UgMjgsIFNlY3Rpb24gNi41OiBpcyBpdCBjb3Jy ZWN0IHRvIGNvbmNsdWRlIHRoYXQsIGZvciBXZWJzb2NrZXQgY29ubmVjdGlvbnMsIHRoZSBkZWZh dWx0IFVyaS1Qb3J0IHZhbHVlIHdpbGwgYmUgODAgaWYgdXNpbmcgImNvYXArd3MiIHNjaGVtZQ0K DQo+IHdpdGggaXRzIGRlZmF1bHQgVENQIHBvcnQsIGFuZCA0NDMgaWYgdXNpbmcgImNvYXBzK3dz IiBzY2hlbWUgd2l0aCBpdHMgZGVmYXVsdCBUQ1AgcG9ydD8gSnVzdCBmb3IgbXkgdW5kZXJzdGFu ZGluZy4NCg0KDQpJdCBkZXBlbmRzIG9uIHRoZSBkaXJlY3Rpb24uIEFzIHN0YXRlZCAiVGhlIGRl ZmF1bHQgdmFsdWUgb2YgdGhlIFVyaS1Qb3J0IE9wdGlvbiBpcyB0aGUgZGVzdGluYXRpb24gVENQ IHBvcnQuIg0KDQoNCg0KPiDigKIgQXBwZW5kaXggQTogV2h5IGlzIHRoZSB1cGRhdGUgb2YgT2Jz ZXJ2ZSBbUkZDNzY0MV0gZG9uZSBpbiB0aGUgQXBwZW5kaXggYW5kIG5vdCBpbiBhIG1haW4gc2Vj dGlvbj8NCg0KPiBUaGVyZSBtdXN0IGhhdmUgYmVlbiBhIGdvb2QgcmVhc29uIHRvIHBsYWNlIGl0 IHRoZXJlOyBidXQgaXQgbG9va3Mgc3RyYW5nZSBzaW5jZSBpdCBmb3JtYWxseSB1cGRhdGVzIFJG QyA3NjQxLg0KDQoNCg0KVGhlcmUgd2FzIGEgZGVzaXJlIHRvIGhhdmUgYSBjbGVhbiBzZXBhcmF0 aW9uIGJldHdlZW4gdGhlIHRyYW5zcG9ydCBpdHNlbGYgYW5kIHRoZSB1cGRhdGVzIHRvIFJGQyA3 NjQxLiBDYXJzdGVuIHN1Z2dlc3RlZA0KDQpjb2xsZWN0aW5nIHRoZSBjaGFuZ2VzIGluIGFuIEFw cGVuZGl4IHdoaWNoIHdhcyBhZG9wdGVkLiBNeSBvcmlnaW5hbCBwcmVmZXJlbmNlIHdhcyB0byBz ZXBhcmF0ZWx5IHVwZGF0ZSBSRkMgNzY0MS4NCg0KDQoNCg0K --_000_CY1PR03MB2380CF66BE0E575AA969A5A283560CY1PR03MB2380namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MgZm9yIHRoZSBxdWVzdGlvbnMg YW5kIGZlZWRiYWNrLiBQYXJ0aWFsIHJlc3BvbnNlcyBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+KiogUXVlc3Rpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IOKAoiBUaGUgYmktZGlyZWN0aW9uYWxpdHkgb2YgY29ubmVjdGlvbnMgaXMg bWVudGlvbmVkIGluIHRoZSBkcmFmdC4gTm93IHN1cHBvc2UgYSBDb0FQIGNsaWVudCBvbiBob3N0 IDEgb3BlbnMgYSBUQ1AgY29ubmVjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAoYXMgYSBUQ1AgY2xpZW50KSB0byBhIFRDUCBzZXJ2ZXIgb24gaG9zdCAy LCBpbiBvcmRlciB0byBzZW5kIGEgQ29BUCByZXF1ZXN0IHRvIGl0LiBOb3cgdGhlIFRDUCBzZXJ2 ZXIgKGhvc3QgMikgYXQgc29tZSBwb2ludCBzdWRkZW5seTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzZW5kcyBhIENvQVAgcmVxdWVzdCAoYWN0aW5nIGl0c2Vs ZiBhcyBhIENvQVAgY2xpZW50KSB0byB0aGUgVENQIGNsaWVudCAoaG9zdCAxKS4gSG93ZXZlciwg dGhlcmUgaXMgbm8gQ29BUCBzZXJ2ZXIgaG9zdGVkIG9uIGhvc3QgMS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgV2hhdCBzaG91bGQgaGFwcGVuIG5vdz8gRS5n LiBpcyB0aGUgcmVxdWVzdCBzaW1wbHkgaWdub3JlZCBvciBpcyBzb21lIGtpbmQgb2YgZXJyb3Ig bWVzc2FnZSByZXR1cm5lZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsg4oCiIFNhbWUgcXVlc3Rpb24gYXMgYWJvdmUgY2FuIGJlIHN0YXRlZCBmb3IgVExTIGFu ZCBXZWJzb2NrZXRzLiBJcyB0aGUgYmVoYXZpb3IgdGhlIHNhbWUgaW4gdGhlc2UgY2FzZXM/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IOKAoiBGb2xsb3dpbmcg dGhlIGFib3ZlLCBzaG91bGQgdGhlIENTTSBtZXNzYWdlIGhhdmUgYW4gb3B0aW9uIHRvIGluZGlj YXRlIGEgY2FwYWJpbGl0eSBvZiAmcXVvdDtiZWluZyBhIENvQVAgc2VydmVyJnF1b3Q7IOKApiA/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNhcnN0ZW4ncyBzdWdnZXN0aW9uIG9uIGEg cHJpdmF0ZSB0aHJlYWQgYWRkcmVzc2VzIHRoaXMgc2V0IG9mIHF1ZXN0aW9uczo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtU aGUgaW50ZW50aW9uIGlzIGZvciB0aGUgdHJhbnNwb3J0IHRvIGJlIGJpZGlyZWN0aW9uYWwuIElm IHRoZXJlIGlzIGEgQ29BUCBjbGllbnQsIGl0IGlzIGVhc3kgdG8gaGF2ZSBhIENvQVAgc2VydmVy IHRoYXQgNC4wNHMgZXZlcnkgcmVxdWVzdC4gWWVzLCB0aGF0IGlzIHdvcnRoIG1ha2luZyBleHBs aWNpdC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyDigKIgUGFnZSAy MDogQWx0ZXJuYXRpdmUtQWRkcmVzcyBPcHRpb24gLSB0aGUgc2VtYW50aWNzIG9mIGluY2x1ZGlu ZyBtdWx0aXBsZSBvZiB0aGVzZSBvcHRpb25zIGlzIG5vdCBkZWZpbmVkLiBDYW4gdGhlIHJlY2Vp dmVyIHBpY2sgYW55IG9mIHRoZSBhZGRyZXNzZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IE9yIGRvZXMgaXQgbmVlZCB0byB0cnkgdGhlIGZpcnN0IGFkZHJl c3MgZmlyc3Q/IEFuZCB0aGVuIGtlZXAgdHJ5aW5nIGFsbCBhbHRlcm5hdGl2ZXMgdW50aWwgb25l IHN1Y2NlZWRzLCBvciBub3Q/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlVubGVzcyBD YXJzdGVuIG9yIEhhbm5lcyAoYXV0aG9ycyBvZiBkcmFmdC1ib3JtYW5uLWNvcmUtY29hcC1zaWct MDIpIGhhdmUgYSBwcmVmZXJlbmNlLCBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB0aGUgYWRkcmVzc2Vz IGFyZSB1bm9yZGVyZWQgKHBpY2sgYW55KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlRyYWNrZWQgaW4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3At dGxzL2lzc3Vlcy8xMTU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyDigKIgUGFn ZSAyOCwgU2VjdGlvbiA2LjU6IGlzIGl0IGNvcnJlY3QgdG8gY29uY2x1ZGUgdGhhdCwgZm9yIFdl YnNvY2tldCBjb25uZWN0aW9ucywgdGhlIGRlZmF1bHQgVXJpLVBvcnQgdmFsdWUgd2lsbCBiZSA4 MCBpZiB1c2luZyAmcXVvdDtjb2FwJiM0Mzt3cyZxdW90OyBzY2hlbWU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgd2l0aCBpdHMgZGVmYXVsdCBUQ1AgcG9ydCwg YW5kIDQ0MyBpZiB1c2luZyAmcXVvdDtjb2FwcyYjNDM7d3MmcXVvdDsgc2NoZW1lIHdpdGggaXRz IGRlZmF1bHQgVENQIHBvcnQ/IEp1c3QgZm9yIG15IHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGRlcGVuZHMgb24gdGhlIGRpcmVjdGlvbi4gQXMgc3RhdGVkICZx dW90O1RoZSBkZWZhdWx0IHZhbHVlIG9mIHRoZSBVcmktUG9ydCBPcHRpb24gaXMgdGhlIGRlc3Rp bmF0aW9uIFRDUCBwb3J0LiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IOKAoiBBcHBlbmRpeCBBOiBXaHkgaXMgdGhlIHVwZGF0ZSBvZiBPYnNlcnZlIFtSRkM3NjQxXSBk b25lIGluIHRoZSBBcHBlbmRpeCBhbmQgbm90IGluIGEgbWFpbiBzZWN0aW9uPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGVyZSBtdXN0IGhhdmUgYmVlbiBh IGdvb2QgcmVhc29uIHRvIHBsYWNlIGl0IHRoZXJlOyBidXQgaXQgbG9va3Mgc3RyYW5nZSBzaW5j ZSBpdCBmb3JtYWxseSB1cGRhdGVzIFJGQyA3NjQxLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaGVyZSB3YXMgYSBkZXNpcmUgdG8gaGF2ZSBhIGNsZWFuIHNlcGFyYXRpb24gYmV0d2Vl biB0aGUgdHJhbnNwb3J0IGl0c2VsZiBhbmQgdGhlIHVwZGF0ZXMgdG8gUkZDIDc2NDEuIENhcnN0 ZW4gc3VnZ2VzdGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5jb2xs ZWN0aW5nIHRoZSBjaGFuZ2VzIGluIGFuIEFwcGVuZGl4IHdoaWNoIHdhcyBhZG9wdGVkLiBNeSBv cmlnaW5hbCBwcmVmZXJlbmNlIHdhcyB0byBzZXBhcmF0ZWx5IHVwZGF0ZSBSRkMgNzY0MS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR03MB2380CF66BE0E575AA969A5A283560CY1PR03MB2380namp_-- From nobody Tue Feb 28 01:27:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3302412706D; Tue, 28 Feb 2017 01:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bbhkdDN55N5; Tue, 28 Feb 2017 01:27:50 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CCC126FDC; Tue, 28 Feb 2017 01:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1S9Rk3I006510; Tue, 28 Feb 2017 10:27:46 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:f914:6d44:554a:662d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vXYC65SHrzDJ3B; Tue, 28 Feb 2017 10:27:46 +0100 (CET) From: Olaf Bergmann To: art@ietf.org, media-types@ietf.org Date: Tue, 28 Feb 2017 10:27:46 +0100 Message-ID: <87innupsvh.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Archived-At: Cc: core@ietf.org Subject: [core] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 09:27:52 -0000 --=-=-= Content-Type: text/plain Hi all, (core ML Cc'd due to specific interest in this topic) We have submitted an updated version of draft-shelby-exi-registration that documents appropriate use of the "+exi" structured syntax suffix. This document has been around since 2012 where it has been discussed in the IETF media-types mailing list. There has not been much progress since, specifically because the "application/exi" media type and the "exi" content coding deemed to be sufficient. Recent media type registration requests---in particular for application/senml+exi---indicate that there are cases where the generic exi media type and content coding header are not applicable. Any comments are welcome! Best regards Olaf --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: Received: from dspam.localhost by imap.informatik.uni-bremen.de (Dovecot) with LMTP id EZDaASJitFhdGAAACethxA for ; Mon, 27 Feb 2017 18:33:04 +0100 Return-Path: X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=6.2 tests=[DATE_IN_FUTURE_96_Q=2.896, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=disabled Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1RHWtU0003853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Feb 2017 18:33:01 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E81F12A2A1; Mon, 27 Feb 2017 09:32:55 -0800 (PST) From: internet-drafts@ietf.org To: "Carsten Bormann" , "Zach Shelby" , "Olaf Bergmann" Subject: New Version Notification for draft-shelby-exi-registration-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148821677512.21113.2713734803892289412.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 09:32:55 -0800 MIME-Version: 1.0 Content-Type: text/plain A new version of I-D, draft-shelby-exi-registration-02.txt has been successfully submitted by Olaf Bergmann and posted to the IETF repository. Name: draft-shelby-exi-registration Revision: 02 Title: The +exi Media Type Suffix Document date: 2017-02-22 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-shelby-exi-registration-02.txt Status: https://datatracker.ietf.org/doc/draft-shelby-exi-registration/ Htmlized: https://tools.ietf.org/html/draft-shelby-exi-registration-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-shelby-exi-registration-02 Abstract: Efficient XML Interchange (EXI) is an XML representation technique specified by the W3C to provide a time and space efficient encoding for XML documents. This document defines a new Structured Syntax Suffix "+exi" for use in a specific class of protocols, where "exi" content-type encoding or the generic "application/exi" media type are not applicable. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=-=-=-- From koojana.kuladinithi@tuhh.de Tue Feb 28 03:21:35 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E8112952F for ; Tue, 28 Feb 2017 03:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tuhh.de 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 QoLtrB16KQHC for ; Tue, 28 Feb 2017 03:21:32 -0800 (PST) Received: from smtp6.rz.tu-harburg.de (smtp6.rz.tu-harburg.de [134.28.205.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A6A129524 for ; Tue, 28 Feb 2017 03:21:32 -0800 (PST) Received: from mail.tu-harburg.de (mail3.rz.tu-harburg.de [134.28.202.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.tu-harburg.de", Issuer "TUHH CA in DFN-PKI Global - G01" (verified OK)) by smtp6.rz.tu-harburg.de (Postfix) with ESMTPS id 3vXbkK6tbvzGmSJ; Tue, 28 Feb 2017 12:21:29 +0100 (CET) Received: from mailspring.rz.tu-harburg.de (mailspring.rz.tu-harburg.de [134.28.202.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ckk6755@KERBEROS.TU-HARBURG.DE) by mail.tu-harburg.de (Postfix) with ESMTPSA id 3vXbkK5V9zzhXyR; Tue, 28 Feb 2017 12:21:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhh.de; s=x2017-09; t=1488280889; bh=hOvFYntVnTk0/HhdebjLiwE90xf89YiSIi1Vxh+ZGB0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=X7GnC6KDsyM7L41NPG3bWjakGU9w5uLlCi/aGwQ2gePzKBb7Fq+S0JsEHp7GQ1LZO wl50zVjdfeM1xv3xS7C57t2px+vV9usSFDWkHMsUxW3AFOlG4D6b1mMC16UdGQWxtD SoDX0kcS75Q/YEL2tonazzWfBs5rpo3/GYa4Rj6I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Koojana Kuladinithi In-Reply-To: Date: Tue, 28 Feb 2017 12:21:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D2CB866-3E1A-4460-B014-3B74E14FB776@tuhh.de> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-becker-core-coap-sms-gprs-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 11:23:10 -0000 Hi Hannes and all, we have submitted the new version of the above draft.=20 w.r.t. the current on going discussions, we would also like to get your = feedback on the section 8 of URI scheme. Is this the way to do it for = devices with telephone numbers? Koojana > On 23 Jan 2017, at 09:16, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > when I recently stumbled over this document I was unsure about the > status and reached out to the authors. Having worked in the OMA DM = group > and witnessed some fuzziness around the description of how CoAP is > carried over SMS I have been wondering whether there is interest to > finalize this work (which has also been mentioned in > = https://tools.ietf.org/html/draft-silverajan-core-coap-alternative-transpo= rts-09 > at a later stage). As it can be seen from the alternative transport > document, the WebSocket parts have now been covered in the CoAP over > TCP/TLS document. >=20 > A feature that has also been raised in the context of SMS is the = ability > to wake-up the device using an SMS so that it starts communication = over IP. >=20 > Is there any interest to finalize this work? >=20 > Ciao > Hannes >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Dr.-Ing. Koojana Kuladinithi Hamburg University of Technology Am Schwarzenberg-Campus 3, Room 1.043 21073 Hamburg Tel.: +49 40 428 78 35 33 =3D=3D=3DThe answers you seek never come to you when the mind is busy. = They come to you when the mind is still=3D=3D=3D=20 From nobody Tue Feb 28 06:05:48 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B236A129502; Tue, 28 Feb 2017 06:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKF9XrJMueEA; Tue, 28 Feb 2017 06:05:41 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 9CD5E129543; Tue, 28 Feb 2017 06:05:41 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBES7VSHNK00K72W@mauve.mrochek.com>; Tue, 28 Feb 2017 06:03:47 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBDDVH6WZK0005AQ@mauve.mrochek.com>; Tue, 28 Feb 2017 06:03:45 -0800 (PST) Message-id: <01QBES7UHX6E0005AQ@mauve.mrochek.com> Date: Tue, 28 Feb 2017 05:58:15 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 28 Feb 2017 10:27:46 +0100" <87innupsvh.fsf@aung.informatik.uni-bremen.de> References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> To: Olaf Bergmann Archived-At: Cc: media-types@ietf.org, art@ietf.org, core@ietf.org Subject: Re: [core] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 14:05:43 -0000 Has something changed about the definition of EXI that would make it actually appropriate as a media type suffix? Because unless there's been a change the reason this hasn't progressed is because it's inappropriate for it to do so. In particular, it isn't possible to process a type that ends in +exi in any significant way without knowing the type's schema. So unless there's a way of discovering that knowing nothing but the type name, +exi provides no utility. Ned > Hi all, > (core ML Cc'd due to specific interest in this topic) > We have submitted an updated version of draft-shelby-exi-registration > that documents appropriate use of the "+exi" structured syntax suffix. > This document has been around since 2012 where it has been discussed in > the IETF media-types mailing list. There has not been much progress > since, specifically because the "application/exi" media type and the > "exi" content coding deemed to be sufficient. > Recent media type registration requests---in particular for > application/senml+exi---indicate that there are cases where the generic > exi media type and content coding header are not applicable. > Any comments are welcome! > Best regards > Olaf From nobody Tue Feb 28 06:23:20 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA44A129563; Tue, 28 Feb 2017 06:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgNaS2ggHUpC; Tue, 28 Feb 2017 06:23:08 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A119412958C; Tue, 28 Feb 2017 06:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1SEN5gF012219; Tue, 28 Feb 2017 15:23:05 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:f914:6d44:554a:662d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vXgls4XyJzDJCp; Tue, 28 Feb 2017 15:23:05 +0100 (CET) From: Olaf Bergmann To: Ned Freed References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> <01QBES7UHX6E0005AQ@mauve.mrochek.com> Date: Tue, 28 Feb 2017 15:23:05 +0100 In-Reply-To: <01QBES7UHX6E0005AQ@mauve.mrochek.com> (Ned Freed's message of "Tue, 28 Feb 2017 05:58:15 -0800 (PST)") Message-ID: <87r32io0mu.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: media-types@ietf.org, art@ietf.org, core@ietf.org Subject: Re: [core] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 14:23:10 -0000 Hi Ned, Ned Freed writes: > Has something changed about the definition of EXI that would make it actu= ally > appropriate as a media type suffix? Because unless there's been a change = the > reason this hasn't progressed is because it's inappropriate for it to do = so. What has changed is the fact that +exi is in actual use. > In particular, it isn't possible to process a type that ends in +exi in a= ny > significant way without knowing the type's schema. So unless there's a way > of discovering that knowing nothing but the type name, +exi provides > no utility. Well, processing a document is one thing. But signaling that you can process a document (with or without schema) is another thing. The "+exi" suffix helps where application/exi and content-coding: exi are not applicable (e.g. in a CoAP Accept option). This is pretty much what the draft describes. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Feb 28 07:06:12 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAC1295B3; Tue, 28 Feb 2017 07:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsDZgOHDZELb; Tue, 28 Feb 2017 07:06:03 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 E37A712953F; Tue, 28 Feb 2017 07:06:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBEUCWYHF4007NZV@mauve.mrochek.com>; Tue, 28 Feb 2017 07:05:07 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBDDVH6WZK0005AQ@mauve.mrochek.com>; Tue, 28 Feb 2017 07:05:04 -0800 (PST) Message-id: <01QBEUCUSIQW0005AQ@mauve.mrochek.com> Date: Tue, 28 Feb 2017 06:46:57 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 28 Feb 2017 15:23:05 +0100" <87r32io0mu.fsf@aung.informatik.uni-bremen.de> References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> <01QBES7UHX6E0005AQ@mauve.mrochek.com> <87r32io0mu.fsf@aung.informatik.uni-bremen.de> To: Olaf Bergmann Archived-At: Cc: media-types@ietf.org, art@ietf.org, Ned Freed , core@ietf.org Subject: Re: [core] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 15:06:04 -0000 > Hi Ned, > Ned Freed writes: > > Has something changed about the definition of EXI that would make it actually > > appropriate as a media type suffix? Because unless there's been a change the > > reason this hasn't progressed is because it's inappropriate for it to do so. > What has changed is the fact that +exi is in actual use. So are many other things that don't actually make sense. Usage doesn't make something valid to register. > > In particular, it isn't possible to process a type that ends in +exi in any > > significant way without knowing the type's schema. So unless there's a way > > of discovering that knowing nothing but the type name, +exi provides > > no utility. > Well, processing a document is one thing. But signaling that you can > process a document (with or without schema) is another thing. The "+exi" > suffix helps where application/exi and content-coding: exi are not > applicable (e.g. in a CoAP Accept option). This is pretty much what the > draft describes. Hmm. Well, if this assessment of the mechanism in CoAP is valid - and I take no position on that - it sounds to me like CoAP effectively extended the semantics of media types in a fairly fundamental way. In particular, it seems like you're using them as a signalling mechanism where no data of the given type is actually involved. If that's indeed the case, then that extension to the use of media types needs to be fully and completely described, along with its security considerations, so that types intended for this usage can undergo proper review before they are registered. There is some precedent for such usage, in that there are cases where the top-level name of a media type has been used for signalling, necessitating the registration of essentially the same type under audio/ and video/. But the type still functioned as a label for actual media. Anyway, IMO you have a lot of work to do before the registration of +exi can be justified. Ned From nobody Tue Feb 28 07:59:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30955129517; Tue, 28 Feb 2017 07:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-gk744KCyRs; Tue, 28 Feb 2017 07:59:28 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A5E1204D9; Tue, 28 Feb 2017 07:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1SFxOv2009231; Tue, 28 Feb 2017 16:59:24 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:f914:6d44:554a:662d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vXjv04RLMzDJFt; Tue, 28 Feb 2017 16:59:24 +0100 (CET) From: Olaf Bergmann To: Ned Freed References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> <01QBES7UHX6E0005AQ@mauve.mrochek.com> <87r32io0mu.fsf@aung.informatik.uni-bremen.de> <01QBEUCUSIQW0005AQ@mauve.mrochek.com> Date: Tue, 28 Feb 2017 16:59:24 +0100 In-Reply-To: <01QBEUCUSIQW0005AQ@mauve.mrochek.com> (Ned Freed's message of "Tue, 28 Feb 2017 06:46:57 -0800 (PST)") Message-ID: <87efyinw6b.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: media-types@ietf.org, art@ietf.org, core@ietf.org Subject: Re: [core] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 15:59:29 -0000 Ned Freed writes: >> Well, processing a document is one thing. But signaling that you can >> process a document (with or without schema) is another thing. The "+exi" >> suffix helps where application/exi and content-coding: exi are not >> applicable (e.g. in a CoAP Accept option). This is pretty much what the >> draft describes. > > Hmm. Well, if this assessment of the mechanism in CoAP is valid - and I t= ake no > position on that - it sounds to me like CoAP effectively extended the sem= antics > of media types in a fairly fundamental way. I do not think it does, more likely was my description not accurate. What CoAP does is that it assigns a numeric value to a registered media type/content coding combination which then is used when negotiating the acceptable content type between sender and receiver. > In particular, it seems like you're using them as a signalling mechanism = where > no data of the given type is actually involved. If that's indeed the case= , then > that extension to the use of media types needs to be fully and completely > described, along with its security considerations, so that types intended > for this usage can undergo proper review before they are registered. The number is just an abbreviation of what would otherwise go into the Content-Type or Accept header together with Content-Coding. I do not see why this would be an extension to common handling of media types and their encodings? Gr=C3=BC=C3=9Fe Olaf From nobody Tue Feb 28 08:33:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1759129614 for ; Tue, 28 Feb 2017 08:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gadORfhfKcM for ; Tue, 28 Feb 2017 08:19:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630C5129613 for ; Tue, 28 Feb 2017 08:19:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 574B3B81770; Tue, 28 Feb 2017 08:19:42 -0800 (PST) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170228161942.574B3B81770@rfc-editor.org> Date: Tue, 28 Feb 2017 08:19:42 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 28 Feb 2017 08:33:41 -0800 Cc: text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, core@ietf.org, hartke@tzi.org, charset=UTF-8@rfc-editor.org Subject: [core] [Editorial Errata Reported] RFC7252 (4954) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 16:19:44 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7252&eid=4954 -------------------------------------- Type: Editorial Reported by: Klaus Hartke Section: 12.3 Original Text ------------- CoAP does not include a separate way to convey content-encoding information with a request or response, and for that reason the content-encoding is also specified for each identifier (if any). If multiple content-encodings will be used with a media type, then a separate Content-Format identifier for each is to be registered. Similarly, other parameters related to an Internet media type, such as level, can be defined for a CoAP Content-Format entry. +--------------------------+----------+----+------------------------+ | Media type | Encoding | ID | Reference | +--------------------------+----------+----+------------------------+ Corrected Text -------------- CoAP does not include a separate way to convey content-coding information with a request or response, and for that reason the content-coding is also specified for each identifier (if any). If multiple content-codings will be used with a media type, then a separate Content-Format identifier for each is to be registered. Similarly, other parameters related to an Internet media type, such as level, can be defined for a CoAP Content-Format entry. +--------------------------+----------------+----+------------------+ | Media type | Content coding | ID | Reference | +--------------------------+----------------+----+------------------+ Notes ----- A CoAP Content-Format is the combination of an Internet Media Type with an HTTP Content Coding, as correctly explained in the first paragraphs of Section 12.3. However, the next paragraph (the original text above) incorrectly uses the term "content-encoding". The correct term is "content-coding", as shown in the corrected text. Examples for _valid_ CoAP Content-Format registrations: - media type "text/plain; charset=iso-8859-1" with content-coding "deflate" - media type "image/png" with content-coding "" (no content-coding) - media type "image/png" with content-coding "identity" (same as previous, no content-coding) - media type "application/example+xml" with content-coding "exi" Examples for _invalid_ CoAP Content-Format registrations: - media type "application/coap-group+json" with content-coding "UTF-8" (UTF-8 is a character encoding, not a content-coding; should be media type "application/coap-group+json; charset=utf-8" with content-coding "identity") - media type "audio/opus" with content-coding "identity" ("audio/opus" has a required parameter "rate"; should be media type "audio/opus; rate=48000" with content-coding "identity") - media type "application/example+xml" with content-coding "identity, exi" (too many content-codings; should be media type "application/example+xml" with content-coding "identity" and, separately, media type "application/example+xml" with content-coding "exi") - media type "application/example+exi" with content-coding "identity" ("+exi" is not a registered structured syntax suffix at the time of writing of this erratum) - media type "video/ogg" with content-coding "exi" (EXI is a content-coding for XML information) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Feb 28 13:19:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BE01294E2; Tue, 28 Feb 2017 13:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu7vGAaaZr1P; Tue, 28 Feb 2017 13:19:44 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0117.outbound.protection.outlook.com [104.47.42.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477EC1296CD; Tue, 28 Feb 2017 13:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4o/CvshYQsPoKP8hSBdesguNn51K8HK44hqSpplhm4M=; b=MZnwxGFvq1tLh9wSgwNxq09I1Q9lHJOsEej6YJJ9EfwCKjGDpZWrdfbo6X/QpSoIXcexL3YXAr+W7h2n6rG7pfQ6SmN4pbSJmy+sEv4oabHHVXs/yHzvZp6TfXHpKFPaHo+CZhgoc0oCDY/turdy0bUs2FHzT0SrAYAZbEIAbZY= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2379.namprd03.prod.outlook.com (10.166.207.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Tue, 28 Feb 2017 21:19:40 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0933.019; Tue, 28 Feb 2017 21:19:40 +0000 From: Brian Raymor To: Hannes Tschofenig , "Dijk, Esko" , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz?= Thread-Index: AQHSjEtiC9iRy7chmkaoO4DhR9p0VqF+8HrA Date: Tue, 28 Feb 2017 21:19:40 +0000 Message-ID: References: <7ecb932aad934f85bd8dbd81af48fd3b@AM3PR90MB0097.MGDPHG.emi.philips.com> <3145d49b-30c7-3a51-f362-551c631ab7ad@gmx.net> In-Reply-To: <3145d49b-30c7-3a51-f362-551c631ab7ad@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: ca6b9e73-d115-4d39-de24-08d4601f81f2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2379; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2379; 7:GsAAswfY+LKO65YTimoI0dSLFmM28sYmOj9T0C+GiwKIehH25n1/EvNDFcG3YeM28jkQakbHvG8REBYjWriKcrbxEnmZ78fE7vytmy7hJ7nRqXS/aXQC3a0m7EnwewAGwwvWKx0A/0AkB3gq+9ztbPcVzqIkFHJJ8aoXTLUvUj3PzgLZmfHhjUCq+BsBxO+yEUxdYYHStlI7nmGfMYLl/xUcizIgKv94dsTiHnuWPYPXHxbbJpTynY6mZXZpl9hG9hUCAIx3is9mgIp6qnHVATfkg6dBv2t3PAia382KcZjWV9bm/UO1BOIeJx9oqj59kBsIAq0nfG0pnJ4CMpmhTYUJL8c+q9hx4GT2k1WS5LI= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(248736688235697)(260087099026482); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR03MB2379; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2379; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(24454002)(377454003)(377424004)(55904004)(13464003)(85714005)(374574003)(10290500002)(3660700001)(106116001)(122556002)(10090500001)(5005710100001)(76176999)(54356999)(92566002)(229383001)(50986999)(2900100001)(3280700002)(33656002)(2906002)(230783001)(4326008)(189998001)(66066001)(9686003)(81166006)(561944003)(55016002)(25786008)(38730400002)(99286003)(5660300001)(86362001)(77096006)(6306002)(8936002)(6246003)(102836003)(6506006)(6116002)(53546006)(7736002)(305945005)(7696004)(6436002)(53936002)(2950100002)(229853002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2379; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 21:19:40.4190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2379 Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 21:19:47 -0000 VGhhbmtzIHRvIEhhbm5lcyBmb3IgYWRkcmVzc2luZyBzb21lIG9mIHRoZSBlZGl0b3JpYWwgY29t bWVudHMuDQoNCkkgbWFkZSBhIHNlY29uZCBwYXNzIG9uIHRoZSByZW1haW5pbmcgY29tbWVudHM6 DQoNCj4+IOKAoiBQYWdlIDEyOiAiW1JGQzY0NTRdIiAtIGl0IGlzIHVuY2xlYXIgd2hhdCBhc3Bl Y3Qgb3Igc2VjdGlvbiBvZiBSRkM2NDU0DQo+PiBpcyByZWZlcnJlZCB0byBoZXJlLiAgVGhhdCBS RkMgaGFyZGx5IG1lbnRpb25zIFdlYlNvY2tldHMuDQo+IEkgcmVtb3ZlZCB0aGUgc2VudGVuY2Ug c2luY2UgaXQgZG9lcyBub3QgYWRkIGFueSB2YWx1ZSByaWdodCBub3cuDQoNCkkgcmVtb3ZlZCB0 aGUgdW51c2VkIHJlZmVyZW5jZSB0byBSRkM2NDU0Lg0KDQo+PiDigKIgUGFnZSAxOTogQ291bGQg Y2xhcmlmeSB0aGUgc2VudGVuY2UgYmVsb3cgdG8gc2F5IHRoaXMgaXMgYWJvdXQgaGFuZGxpbmcg YSBQaW5nDQo+PiB3aXRoIEN1c3RvZHkgT3B0aW9uIG9ubHksIHNvIG5vdCBpbiBnZW5lcmFsIGZv ciBldmVyeSBQaW5nIG1lc3NhZ2U6DQo+PiAiVGhlIHJlY2VpdmVyIFNIT1VMRCBkZWxheSBpdHMg UG9uZyBtZXNzYWdlIHVudGlsIGl0IGZpbmlzaGVzIHByb2Nlc3NpbmcgYWxsIHRoZSByZXF1ZXN0 Lw0KPj4gICByZXNwb25zZSBtZXNzYWdlcyByZWNlaXZlZCBwcmlvciB0byB0aGUgUGluZyBtZXNz YWdlIG9uIHRoZSBjdXJyZW50IGNvbm5lY3Rpb24uIg0KPj4gICAgLT4NCj4+ICJJbiB0aGF0IGNh c2UsIHRoZSByZWNlaXZlciBTSE9VTEQgZGVsYXkgaXRzIFBvbmcgbWVzc2FnZSB1bnRpbCBpdCBm aW5pc2hlcyBwcm9jZXNzaW5nIGFsbCB0aGUgcmVxdWVzdC8NCj4+ICAgIHJlc3BvbnNlIG1lc3Nh Z2VzIHJlY2VpdmVkIHByaW9yIHRvIHRoYXQgUGluZyBtZXNzYWdlIG9uIHRoZSBjdXJyZW50IGNv bm5lY3Rpb24uIg0KDQpPSy4NCg0KPj4g4oCiIFBhZ2UgMjI6DQo+PiAgICAiY29udGFpbiBhIG11 bHRpcGxlIG9mIDEwMjQgYnl0ZXMgKG5vbi1maW5hbCBCRVJUIGJsb2NrKSBvciBtb3JlIHRoYW4g MTAyNCBieXRlcyAoZmluYWwgQkVSVCBibG9jaykiDQo+PiAgICAgIC0+IFdoeSBjYW4ndCB0aGUg ZmluYWwgYmxvY2sgYmUgMTAyNCBieXRlcz8gSSBhc3N1bWUgYSBmaW5hbCBCRVJUIGJsb2NrIG9m IDEwMjQgYnl0ZXMgaXMgYWxsb3dlZDsNCj4+ICAgICAgICAgICBpdCB3b3VsZCBiZSBzdHJhbmdl IHRvIHN3aXRjaCBiYWNrIHRvIFNaWD02IGZvciB0aGF0IHB1cnBvc2UuIFdoYXQgYWJvdXQgYmVs b3cgdGV4dCAtPg0KPj4gICAgICAgICAgImNvbnRhaW4gYSBtdWx0aXBsZSBvZiAxMDI0IGJ5dGVz IChub24tZmluYWwgQkVSVCBibG9jaykgb3IgbW9yZSB0aGFuIDEwMjMgYnl0ZXMgKGZpbmFsIEJF UlQgYmxvY2spIg0KDQpBc3NpZ25lZCAtIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAt dGNwLXRscy9pc3N1ZXMvMTE2IC0gdG8gQ2Fyc3RlbiBmb3IgYSBxdWljayByZXZpZXcgYXMgdGhl IGRyYWZ0LWJvcm1hbm4tY29yZS1ibG9jay1iZXJ0LTAxIGF1dGhvci4NCg0KPj7igKIgUGFnZSAy MzogImJsb2NrIHNpemUgZXhwb25lbnQgKDIqKihTWlgrNCkpIiAtPiAiYmxvY2sgc2l6ZSAoMioq KFNaWCs0KSkiDQo+PiAoU2luY2UgdGhlIGV4cG9uZW50IGlzIG5vdCBzaG93biBpbiB0aGUgbm90 YXRpb24sIHJhdGhlciB0aGUgcmVzdWx0aW5nIHNpemUgdmFsdWUpDQoNCk9LLg0KDQo+PiDigKIg UGFnZSAyNTogIlRoZXkgYXJlIGRpc3RpbmN0IG5hbWVzcGFjZXMgYW5kIGFyZSBjb25zaWRlcmVk IHRvIGJlIGRpc3RpbmN0IG9yaWdpbiBzZXJ2ZXJzIg0KPj4gIC0+IEFzc3VtaW5nIHRoYXQgJ3Ro ZXknIHJlZmVycyB0byB0aGUgPj4gcmVzb3VyY2VzLiBTaG91bGRuJ3Qgd2UgcmF0aGVyIHNheSAi VGhleSBhcmUgaG9zdGVkIGluIGRpc3RpbmN0IG5hbWVzcGFjZXMsDQo+PiBiZWNhdXNlIGVhY2gg VVJJIHNjaGVtZSBpbXBsaWVzIGEgZGlzdGluY3Qgb3JpZ2luIHNlcnZlci4iDQo+PiBJdCBzZWVt cyBzdHJhbmdlIHRvIHNheSB0aGF0IGEgcmVzb3VyY2UgaXMgY29uc2lkZXJlZCB0byBiZSBuYW1l c3BhY2UsIGFuZCBhIHJlc291cmNlDQo+PiBpcyBjb25zaWRlcmVkIHRvIGJlIGFuIG9yaWdpbiBz ZXJ2ZXIuIFdoaWNoIGlzIHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBzdGF0ZXMgOikNCg0KT0suDQoN Cj4+IOKAoiBQYWdlIDI4LCBTZWN0aW9uIDYuNjogdGhlIGNoYW5nZXMgaW5kaWNhdGVkIGNvdWxk IGltcHJvdmUgaW4gcmVhZGFiaWxpdHkgYSBiaXQgYnkgaGF2aW5nIGEgZm9ybSBvZiAib2xkL25l dyBpbmRpY2F0aW9uIi4NCj4+IOKAoiBQYWdlIDMxLCBTZWN0aW9uIDguMTogbGlzdCBidWxsZXQg Y2FuIGJlIHJlbW92ZWQNCj4gT0suDQoNCkkgZGlkbid0IHNlZSB0aGUgcHJvcG9zZWQgY2hhbmdl cyBjb21wbGV0ZWQgaW4gU2VjdGlvbiA2LjYuIEknbGwgdXBkYXRlIGFuZCBhbHNvIG1ha2Ugc2lt aWxhciBjaGFuZ2VzIHRvIFNlY3Rpb24gNi43IGZvciBzeW1tZXRyeS4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRz Y2hvZmVuaWdAZ214Lm5ldF0gDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyMSwgMjAxNyA2OjA0 IEFNDQpUbzogRGlqaywgRXNrbyA8ZXNrby5kaWprQHBoaWxpcHMuY29tPjsgY29yZUBpZXRmLm9y ZyBXRyA8Y29yZUBpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29h cC10Y3AtdGxzDQoNClRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcsIEVza28uDQoNCkkg c3RhcnRlZCB0byBhZGRyZXNzIHNvbWUgb2YgeW91ciBjb21tZW50cy4gTW9yZSBsYXRlci4NCg0K DQoqKiBSZXZpZXcgY29tbWVudHMgLyBwcm9wb3NlZCBjb3JyZWN0aW9ucyDigKIgUGFnZSAxMCwg RmlndXJlIDg6IHRoZSBmaXJzdCBwaXBlICh8KSBjaGFyYWN0ZXIgb24gdGhlIHNlY29uZCByb3cg b2YgZmllbGRzIHNob3VsZCBiZSByZW1vdmVkLCBpLmUuIHRoZSBFeHRlbmRlZCBMZW5ndGggZmll bGQgc2hvdWxkIHRoZW4gYmVjb21lIDQgYnl0ZXMgaW5zdGVhZCBvZiAzLg0KDQpGaXhlZC4NCg0K 4oCiIFBhZ2UgMTE6ICJwcm92aWRlZCBieSB0aGUgVENQL1RMUyBwcm90b2NvbC4iIC0+ICJwcm92 aWRlZCBieSB0aGUgVENQL1RMUyBwcm90b2NvbHMuIiA/ICBJIGFzc3VtZSB0aGUgaW50ZW50aW9u IGhlcmUgaXMgdG8gcmVmZXIgdG8gYm90aCBwcm90b2NvbHMgYXMgZG9uZSBmb3IgYWxsIG90aGVy IG9jY3VycmVuY2VzIG9mIHRoZSBzdHJpbmcgIlRDUC9UTFMiIGluIHRoZSBkb2N1bWVudC4NCg0K U2luY2UgdGhpcyBzZWN0aW9uIG9ubHkgdGFsa3MgYWJvdXQgVENQIGFuZCBub3QgVExTIEkgcmVt b3ZlZCBUTFMuDQoNCuKAoiBQYWdlIDEyOiAiW1JGQzY0NTRdIiAtIGl0IGlzIHVuY2xlYXIgd2hh dCBhc3BlY3Qgb3Igc2VjdGlvbiBvZiBSRkMNCjY0NTQgaXMgcmVmZXJyZWQgdG8gaGVyZS4gIFRo YXQgUkZDIGhhcmRseSBtZW50aW9ucyBXZWJTb2NrZXRzLg0KDQpJIHJlbW92ZWQgdGhlIHNlbnRl bmNlIHNpbmNlIGl0IGRvZXMgbm90IGFkZCBhbnkgdmFsdWUgcmlnaHQgbm93Lg0KDQrigKIgUGFn ZSAxNSwgU2VjdGlvbiA0LCBmaXJzdCBidWxsZXQ6ICJSZWxhdGVkIGNoYXJhY3RlcmlzdGljcyIg LT4gIkxlYXJuIHJlbGV2YW50IGNoYXJhY3RlcmlzdGljcyIgPyAgVGhlIHZlcmIgaXMgbWlzc2lu ZyBpbiB0aGUgc2VudGVuY2UuDQoNCkZpeGVkLg0KDQrigKIgUGFnZSAxNjogImFzIGFkYXB0ZWQg dG8gdGhlIHNwZWNpZmljIHRyYW5zcG9ydC4iIC0+IGJpdCB1bmNsZWFyIHdoYXQgdGhpcyBtZWFu cyBvciBpbnRlbmRzIHRvIHNheS4gTWF5YmUgaXQgaW50ZW5kcyAid2hpY2ggaXMgYWRhcHRlZCB0 byBzcGVjaWZpYyByZWxpYWJsZSB0cmFuc3BvcnRzIGluIFNlY3Rpb25zIDIuMiBhbmQgMy4yIG9m IHRoaXMgZG9jdW1lbnQuIiA/DQoNCkkgc2ltcGxpZmllZCB0aGUgc2VudGVuY2Ugc2F5aW5nICJT ZWUgU2VjdGlvbiAzIG9mIENvQVAgZm9yIHRoZSBvdmVyYWxsIHN0cnVjdHVyZSBvZiB0aGUgbWVz c2FnZSBmb3JtYXQsIG9wdGlvbiBmb3JtYXQsIGFuZCBvcHRpb24gdmFsdWUgZm9ybWF0LiINCg0K 4oCiIFBhZ2UgMTY6ICJTZXR0aW5nIG9wdGlvbnMgaW5kaWNhdGUgYSBzZXR0aW5nIHRoYXQgd2ls bCBiZSBhcHBsaWVkIGJ5IHRoZSBzZW5kZXIiIC0+ICJFYWNoIHNldHRpbmcgb3B0aW9uIGluZGlj YXRlcyBhIHNldHRpbmcgdGhhdCB3aWxsIGJlIGFwcGxpZWQgYnkgdGhlIHNlbmRlciIgPw0KDQpT b3VuZHMgbGlrZSBhIGdvb2QgcHJvcG9zYWwuDQoNCioqIE5pdHMNCuKAoiBQYWdlIDU6IFNlY3Rp b24gMS4xIG1pZ2h0IGFkZCBhIHNob3J0IG5vdGUgdGhhdCAiVENQL1RMUyIgbWVhbnMgIlRDUCBv ciBUTFMiIGluIHRoaXMgZG9jdW1lbnQsIGFuZCBub3QgIlRMUyBvdmVyIFRDUCIgb3Igc28uIEJ1 dCBwZXJoYXBzIGl0J3Mgb2J2aW91cyB0byBtb3N0IHBlb3BsZS4NCg0KT0suIENsYXJpZmllZC4N Cg0K4oCiIFBhZ2UgOTogIm1vZGVsZWQgb24gQ29BUCBPcHRpb25zIiAtPiAibW9kZWxlZCBvbiB0 aGUgT3B0aW9uIExlbmd0aCBmaWVsZCBpbiBDb0FQIE9wdGlvbnMiID8NCg0KSSBjaGFuZ2VkIGl0 IHRvICJUaGUgZW5jb2Rpbmcgb2YgdGhlIExlbmd0aCBmaWVsZCBpcyBtb2RlbGVkIGFmdGVyIHRo ZSBPcHRpb24gTGVuZ3RoIGZpZWxkIG9mIHRoZSBDb0FQIE9wdGlvbnMuIg0KDQrigKIgUGFnZSAx MzogIlJldmVyc2UgUHJveHkiIC0+ICJyZXZlcnNlLXByb3h5IiAgKHRvIGNvbXBseSB3aXRoIFJG QyA3MjUyDQp0ZXJtaW5vbG9neSkNCg0KT0suDQoNCuKAoiBQYWdlIDE4OiAiZXF1YWwgb3IgbGVz cyIgLT4gImVxdWFsIHRvIG9yIGxlc3MiDQoNCk9LLg0KDQrigKIgUGFnZSAyNywgRmlndXJlIDE5 OiBmaXJzdCBhY2NvbGFkZSBzaG91bGQgZXh0ZW5kIHNsaWdodGx5IHRvIHRoZSByaWdodCwgc2Vj b25kIGFjY29sYWRlIHNob3VsZCBtb3ZlIHNsaWdodGx5IHRvIHRoZSByaWdodC4NCg0KT0suDQoN CuKAoiBQYWdlIDI4LCBTZWN0aW9uIDYuNjogdGhlIGNoYW5nZXMgaW5kaWNhdGVkIGNvdWxkIGlt cHJvdmUgaW4gcmVhZGFiaWxpdHkgYSBiaXQgYnkgaGF2aW5nIGEgZm9ybSBvZiAib2xkL25ldyBp bmRpY2F0aW9uIi4NCuKAoiBQYWdlIDMxLCBTZWN0aW9uIDguMTogbGlzdCBidWxsZXQgY2FuIGJl IHJlbW92ZWQNCg0KT0suDQoNCuKAoiBHbG9iYWw6IHMvcG9ydCBjb21wb25lbnQvcG9ydCBzdWJj b21wb25lbnQvDQoNCk9LLg0KDQoNCuKAoiBQYWdlIDQzOiAiWzIwMDE6REI4OjoxXSIgLT4gIlsy MDAxOmRiODo6MV0iDQoNCk9LLg0KDQpDaWFvDQpIYW5uZXMNCg0KDQpPbiAwMi8yMC8yMDE3IDA0 OjE4IFBNLCBEaWprLCBFc2tvIHdyb3RlOg0KPiBEZWFyIFdHICYgYXV0aG9ycywNCj4gDQo+IEJl bG93IG15IHJldmlldyBvZiB0aGUgZHJhZnQuIE92ZXJhbGwsIEkgZmluZCBpdCBhIHVzZWZ1bCBl eHRlbnNpb24gdG8gdGhlIG92ZXJhbGwgJ0NvQVAgcHJvdG9jb2wgc3VpdGUnLiBPbiB0aGUgZGlz Y3Vzc2VkIHRpY2tldHMgSSBoYXZlIG5vIGZ1cnRoZXIgaW5wdXQuDQo+IA0KPiAqKiBRdWVzdGlv bnMNCj4g4oCiIFRoZSBiaS1kaXJlY3Rpb25hbGl0eSBvZiBjb25uZWN0aW9ucyBpcyBtZW50aW9u ZWQgaW4gdGhlIGRyYWZ0LiBOb3cgc3VwcG9zZSBhIENvQVAgY2xpZW50IG9uIGhvc3QgMSBvcGVu cyBhIFRDUCBjb25uZWN0aW9uIChhcyBhIFRDUCBjbGllbnQpIHRvIGEgVENQIHNlcnZlciBvbiBo b3N0IDIsIGluIG9yZGVyIHRvIHNlbmQgYSBDb0FQIHJlcXVlc3QgdG8gaXQuIE5vdyB0aGUgVENQ IHNlcnZlciAoaG9zdCAyKSBhdCBzb21lIHBvaW50IHN1ZGRlbmx5IHNlbmRzIGEgQ29BUCByZXF1 ZXN0IChhY3RpbmcgaXRzZWxmIGFzIGEgQ29BUCBjbGllbnQpIHRvIHRoZSBUQ1AgY2xpZW50ICho b3N0IDEpLiBIb3dldmVyLCB0aGVyZSBpcyBubyBDb0FQIHNlcnZlciBob3N0ZWQgb24gaG9zdCAx LiBXaGF0IHNob3VsZCBoYXBwZW4gbm93PyBFLmcuIGlzIHRoZSByZXF1ZXN0IHNpbXBseSBpZ25v cmVkIG9yIGlzIHNvbWUga2luZCBvZiBlcnJvciBtZXNzYWdlIHJldHVybmVkPw0KPiDigKIgU2Ft ZSBxdWVzdGlvbiBhcyBhYm92ZSBjYW4gYmUgc3RhdGVkIGZvciBUTFMgYW5kIFdlYnNvY2tldHMu IElzIHRoZSBiZWhhdmlvciB0aGUgc2FtZSBpbiB0aGVzZSBjYXNlcz8NCj4g4oCiIEZvbGxvd2lu ZyB0aGUgYWJvdmUsIHNob3VsZCB0aGUgQ1NNIG1lc3NhZ2UgaGF2ZSBhbiBvcHRpb24gdG8gaW5k aWNhdGUgYSBjYXBhYmlsaXR5IG9mICJiZWluZyBhIENvQVAgc2VydmVyIiDigKYgPw0KPiDigKIg UGFnZSAyMDogQWx0ZXJuYXRpdmUtQWRkcmVzcyBPcHRpb24gLSB0aGUgc2VtYW50aWNzIG9mIGlu Y2x1ZGluZyBtdWx0aXBsZSBvZiB0aGVzZSBvcHRpb25zIGlzIG5vdCBkZWZpbmVkLiBDYW4gdGhl IHJlY2VpdmVyIHBpY2sgYW55IG9mIHRoZSBhZGRyZXNzZXM/IE9yIGRvZXMgaXQgbmVlZCB0byB0 cnkgdGhlIGZpcnN0IGFkZHJlc3MgZmlyc3Q/IEFuZCB0aGVuIGtlZXAgdHJ5aW5nIGFsbCBhbHRl cm5hdGl2ZXMgdW50aWwgb25lIHN1Y2NlZWRzLCBvciBub3Q/DQo+IOKAoiBQYWdlIDI4LCBTZWN0 aW9uIDYuNTogaXMgaXQgY29ycmVjdCB0byBjb25jbHVkZSB0aGF0LCBmb3IgV2Vic29ja2V0IGNv bm5lY3Rpb25zLCB0aGUgZGVmYXVsdCBVcmktUG9ydCB2YWx1ZSB3aWxsIGJlIDgwIGlmIHVzaW5n ICJjb2FwK3dzIiBzY2hlbWUgd2l0aCBpdHMgZGVmYXVsdCBUQ1AgcG9ydCwgYW5kIDQ0MyBpZiB1 c2luZyAiY29hcHMrd3MiIHNjaGVtZSB3aXRoIGl0cyBkZWZhdWx0IFRDUCBwb3J0PyBKdXN0IGZv ciBteSB1bmRlcnN0YW5kaW5nLg0KPiDigKIgQXBwZW5kaXggQTogV2h5IGlzIHRoZSB1cGRhdGUg b2YgT2JzZXJ2ZSBbUkZDNzY0MV0gZG9uZSBpbiB0aGUgQXBwZW5kaXggYW5kIG5vdCBpbiBhIG1h aW4gc2VjdGlvbj8gVGhlcmUgbXVzdCBoYXZlIGJlZW4gYSBnb29kIHJlYXNvbiB0byBwbGFjZSBp dCB0aGVyZTsgYnV0IGl0IGxvb2tzIHN0cmFuZ2Ugc2luY2UgaXQgZm9ybWFsbHkgdXBkYXRlcyBS RkMgNzY0MS4NCj4gDQo+ICoqIFJldmlldyBjb21tZW50cyAvIHByb3Bvc2VkIGNvcnJlY3Rpb25z IOKAoiBQYWdlIDEwLCBGaWd1cmUgODogdGhlIA0KPiBmaXJzdCBwaXBlICh8KSBjaGFyYWN0ZXIg b24gdGhlIHNlY29uZCByb3cgb2YgZmllbGRzIHNob3VsZCBiZSByZW1vdmVkLCBpLmUuIHRoZSBF eHRlbmRlZCBMZW5ndGggZmllbGQgc2hvdWxkIHRoZW4gYmVjb21lIDQgYnl0ZXMgaW5zdGVhZCBv ZiAzLg0KPiDigKIgUGFnZSAxMTogInByb3ZpZGVkIGJ5IHRoZSBUQ1AvVExTIHByb3RvY29sLiIg LT4gInByb3ZpZGVkIGJ5IHRoZSBUQ1AvVExTIHByb3RvY29scy4iID8gIEkgYXNzdW1lIHRoZSBp bnRlbnRpb24gaGVyZSBpcyB0byByZWZlciB0byBib3RoIHByb3RvY29scyBhcyBkb25lIGZvciBh bGwgb3RoZXIgb2NjdXJyZW5jZXMgb2YgdGhlIHN0cmluZyAiVENQL1RMUyIgaW4gdGhlIGRvY3Vt ZW50Lg0KPiDigKIgUGFnZSAxMjogIltSRkM2NDU0XSIgLSBpdCBpcyB1bmNsZWFyIHdoYXQgYXNw ZWN0IG9yIHNlY3Rpb24gb2YgUkZDIDY0NTQgaXMgcmVmZXJyZWQgdG8gaGVyZS4gIFRoYXQgUkZD IGhhcmRseSBtZW50aW9ucyBXZWJTb2NrZXRzLg0KPiDigKIgUGFnZSAxNSwgU2VjdGlvbiA0LCBm aXJzdCBidWxsZXQ6ICJSZWxhdGVkIGNoYXJhY3RlcmlzdGljcyIgLT4gIkxlYXJuIHJlbGV2YW50 IGNoYXJhY3RlcmlzdGljcyIgPyAgVGhlIHZlcmIgaXMgbWlzc2luZyBpbiB0aGUgc2VudGVuY2Uu DQo+IOKAoiBQYWdlIDE2OiAiYXMgYWRhcHRlZCB0byB0aGUgc3BlY2lmaWMgdHJhbnNwb3J0LiIg LT4gYml0IHVuY2xlYXIgd2hhdCB0aGlzIG1lYW5zIG9yIGludGVuZHMgdG8gc2F5LiBNYXliZSBp dCBpbnRlbmRzICJ3aGljaCBpcyBhZGFwdGVkIHRvIHNwZWNpZmljIHJlbGlhYmxlIHRyYW5zcG9y dHMgaW4gU2VjdGlvbnMgMi4yIGFuZCAzLjIgb2YgdGhpcyBkb2N1bWVudC4iID8NCj4g4oCiIFBh Z2UgMTY6ICJTZXR0aW5nIG9wdGlvbnMgaW5kaWNhdGUgYSBzZXR0aW5nIHRoYXQgd2lsbCBiZSBh cHBsaWVkIGJ5IHRoZSBzZW5kZXIiIC0+ICJFYWNoIHNldHRpbmcgb3B0aW9uIGluZGljYXRlcyBh IHNldHRpbmcgdGhhdCB3aWxsIGJlIGFwcGxpZWQgYnkgdGhlIHNlbmRlciIgPw0KPiDigKIgUGFn ZSAxOTogQ291bGQgY2xhcmlmeSB0aGUgc2VudGVuY2UgYmVsb3cgdG8gc2F5IHRoaXMgaXMgYWJv dXQgaGFuZGxpbmcgYSBQaW5nIHdpdGggQ3VzdG9keSBPcHRpb24gb25seSwgc28gbm90IGluIGdl bmVyYWwgZm9yIGV2ZXJ5IFBpbmcgbWVzc2FnZToNCj4gIlRoZSByZWNlaXZlciBTSE9VTEQgZGVs YXkgaXRzIFBvbmcgbWVzc2FnZSB1bnRpbCBpdCBmaW5pc2hlcyBwcm9jZXNzaW5nIGFsbCB0aGUg cmVxdWVzdC8NCj4gICAgcmVzcG9uc2UgbWVzc2FnZXMgcmVjZWl2ZWQgcHJpb3IgdG8gdGhlIFBp bmcgbWVzc2FnZSBvbiB0aGUgY3VycmVudCBjb25uZWN0aW9uLiINCj4gICAgLT4NCj4gIkluIHRo YXQgY2FzZSwgdGhlIHJlY2VpdmVyIFNIT1VMRCBkZWxheSBpdHMgUG9uZyBtZXNzYWdlIHVudGls IGl0IGZpbmlzaGVzIHByb2Nlc3NpbmcgYWxsIHRoZSByZXF1ZXN0Lw0KPiAgICByZXNwb25zZSBt ZXNzYWdlcyByZWNlaXZlZCBwcmlvciB0byB0aGF0IFBpbmcgbWVzc2FnZSBvbiB0aGUgY3VycmVu dCBjb25uZWN0aW9uLiINCj4g4oCiIFBhZ2UgMjI6DQo+ICAgICJjb250YWluIGEgbXVsdGlwbGUg b2YgMTAyNCBieXRlcyAobm9uLWZpbmFsIEJFUlQgYmxvY2spIG9yIG1vcmUgdGhhbiAxMDI0IGJ5 dGVzIChmaW5hbCBCRVJUIGJsb2NrKSINCj4gICAgICAtPiBXaHkgY2FuJ3QgdGhlIGZpbmFsIGJs b2NrIGJlIDEwMjQgYnl0ZXM/IEkgYXNzdW1lIGEgZmluYWwgQkVSVCBibG9jayBvZiAxMDI0IGJ5 dGVzIGlzIGFsbG93ZWQ7IGl0IHdvdWxkIGJlIHN0cmFuZ2UgdG8gc3dpdGNoIGJhY2sgdG8gU1pY PTYgZm9yIHRoYXQgcHVycG9zZS4gV2hhdCBhYm91dCBiZWxvdyB0ZXh0IC0+DQo+ICAgICJjb250 YWluIGEgbXVsdGlwbGUgb2YgMTAyNCBieXRlcyAobm9uLWZpbmFsIEJFUlQgYmxvY2spIG9yIG1v cmUgdGhhbiAxMDIzIGJ5dGVzIChmaW5hbCBCRVJUIGJsb2NrKSINCj4g4oCiIFBhZ2UgMjM6ICJi bG9jayBzaXplIGV4cG9uZW50ICgyKiooU1pYKzQpKSIgLT4gImJsb2NrIHNpemUgKDIqKihTWlgr NCkpIiAgIChTaW5jZSB0aGUgZXhwb25lbnQgaXMgbm90IHNob3duIGluIHRoZSBub3RhdGlvbiwg cmF0aGVyIHRoZSByZXN1bHRpbmcgc2l6ZSB2YWx1ZSkNCj4g4oCiIFBhZ2UgMjU6ICJUaGV5IGFy ZSBkaXN0aW5jdCBuYW1lc3BhY2VzIGFuZCBhcmUgY29uc2lkZXJlZCB0byBiZSBkaXN0aW5jdCBv cmlnaW4gc2VydmVycyIgLT4gQXNzdW1pbmcgdGhhdCAndGhleScgcmVmZXJzIHRvIHRoZSByZXNv dXJjZXMuIFNob3VsZG4ndCB3ZSByYXRoZXIgc2F5ICJUaGV5IGFyZSBob3N0ZWQgaW4gZGlzdGlu Y3QgbmFtZXNwYWNlcywgYmVjYXVzZSBlYWNoIFVSSSBzY2hlbWUgaW1wbGllcyBhIGRpc3RpbmN0 IG9yaWdpbiBzZXJ2ZXIuIg0KPiBJdCBzZWVtcyBzdHJhbmdlIHRvIHNheSB0aGF0IGEgcmVzb3Vy Y2UgaXMgY29uc2lkZXJlZCB0byBiZSBuYW1lc3BhY2UsIA0KPiBhbmQgYSByZXNvdXJjZSBpcyBj b25zaWRlcmVkIHRvIGJlIGFuIG9yaWdpbiBzZXJ2ZXIuIFdoaWNoIGlzIHdoYXQgdGhlIA0KPiBj dXJyZW50IHRleHQgc3RhdGVzIDopDQo+IA0KPiAqKiBOaXRzDQo+IOKAoiBQYWdlIDU6IFNlY3Rp b24gMS4xIG1pZ2h0IGFkZCBhIHNob3J0IG5vdGUgdGhhdCAiVENQL1RMUyIgbWVhbnMgIlRDUCBv ciBUTFMiIGluIHRoaXMgZG9jdW1lbnQsIGFuZCBub3QgIlRMUyBvdmVyIFRDUCIgb3Igc28uIEJ1 dCBwZXJoYXBzIGl0J3Mgb2J2aW91cyB0byBtb3N0IHBlb3BsZS4NCj4g4oCiIFBhZ2UgOTogIm1v ZGVsZWQgb24gQ29BUCBPcHRpb25zIiAtPiAibW9kZWxlZCBvbiB0aGUgT3B0aW9uIExlbmd0aCBm aWVsZCBpbiBDb0FQIE9wdGlvbnMiID8NCj4g4oCiIFBhZ2UgMTM6ICJSZXZlcnNlIFByb3h5IiAt PiAicmV2ZXJzZS1wcm94eSIgICh0byBjb21wbHkgd2l0aCBSRkMgDQo+IDcyNTIgdGVybWlub2xv Z3kpIOKAoiBQYWdlIDE4OiAiZXF1YWwgb3IgbGVzcyIgLT4gImVxdWFsIHRvIG9yIGxlc3MiDQo+ IOKAoiBQYWdlIDI3LCBGaWd1cmUgMTk6IGZpcnN0IGFjY29sYWRlIHNob3VsZCBleHRlbmQgc2xp Z2h0bHkgdG8gdGhlIHJpZ2h0LCBzZWNvbmQgYWNjb2xhZGUgc2hvdWxkIG1vdmUgc2xpZ2h0bHkg dG8gdGhlIHJpZ2h0Lg0KPiDigKIgUGFnZSAyOCwgU2VjdGlvbiA2LjY6IHRoZSBjaGFuZ2VzIGlu ZGljYXRlZCBjb3VsZCBpbXByb3ZlIGluIHJlYWRhYmlsaXR5IGEgYml0IGJ5IGhhdmluZyBhIGZv cm0gb2YgIm9sZC9uZXcgaW5kaWNhdGlvbiIuDQo+IOKAoiBQYWdlIDMxLCBTZWN0aW9uIDguMTog bGlzdCBidWxsZXQgY2FuIGJlIHJlbW92ZWQg4oCiIEdsb2JhbDogcy9wb3J0IA0KPiBjb21wb25l bnQvcG9ydCBzdWJjb21wb25lbnQvIOKAoiBQYWdlIDQzOiAiWzIwMDE6REI4OjoxXSIgLT4gDQo+ ICJbMjAwMTpkYjg6OjFdIg0KPiANCj4gYmVzdCByZWdhcmRzLA0KPiBFc2tvIERpamsNCj4gLS0t DQo+IA0KPiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSmFpbWUgSmltw6luZXoNCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAx NyAxMzoxNw0KPiBUbzogY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBpZXRmLm9yZz4NCj4gQ2M6IGRy YWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2NvcmVdIPCf lJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzDQo+IA0KPiBEZWFyIENvUkUgV0cs DQo+IA0KPiBUaGVyZSBoYXMgYmVlbiBxdWl0ZSBzb21lIHdvcmsgb24gdGhlICJDb0FQIChDb25z dHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCkgb3ZlciBUQ1AsIFRMUywgYW5kIFdlYlNvY2tl dHPigJ0gZHJhZnQgKGRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMpIHNpbmNlIHRoZSBsYXN0 IFdHTEMuDQo+IEJJRyB0aGFua3MgdG8gQnJpYW4gZm9yIHRoZSB0aW1lIGFuZCBlZmZvcnQgZGVk aWNhdGVkIGFzIEVkaXRvci4gSXQgbm93IHNlZW1zIGEgZ29vZCB0aW1lIGZvciBhIGZpbmFsIFdH TEMgdG8gZ2V0IHRoZSBsYXN0IGNvbW1lbnRzIGZyb20gdGhlIGdyb3VwIGluIG9yZGVyIHRvIG1v dmUgdGhlIHNwZWNpZmljYXRpb24gZm9yd2FyZC4NCj4gDQo+IEluIHBhcnRpY3VsYXIgdGhlcmUg aGFzIG5vdCBiZWVuIG11Y2ggZGlzY3Vzc2lvbiBvbiBzZWN1cmluZyBDb0FQIG92ZXIgV2ViU29j a2V0cyAoaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy8xMDIp IGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3QgKGh0dHBzOi8vZ2l0aHViLmNvbS9jb3Jl LXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTA4KSBmZWVkYmFjayB3b3VsZCBiZSB2ZXJ5IG11Y2gg d2VsY29tZWQuIFBsZWFzZSBnbyBhaGVhZCBhbmQgY2hlY2sgdGhlIGRpc2N1c3Npb25zIG9uIHRo ZSBvdGhlciBpc3N1ZXMgb2YgdGhpcyB2ZXJzaW9uOiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13 Zy9jb2FwLXRjcC10bHMvbWlsZXN0b25lLzQ/Y2xvc2VkPTEgIGFuZCBvbiB0aGUgY2hhbmdlbG9n IHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0byBhc2sgdGhlIGdy b3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gc3RhdHVzIG9m IHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFsbHkgT3BlbiBTb3Vy Y2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC4NCj4gDQo+IGxhdGVzdCB2ZXJzaW9uOiAN Cj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10 bHMtMDYNCj4gZGlmZjogDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDYudHgNCj4gdA0KPiBjaGFuZ2Vsb2c6IA0KPiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0w NiNhcHBlbmRpeC1DDQo+IC40DQo+IA0KPiBUaGUgV0dMQyB3aWxsIGxhc3Qgb25lIHdlZWssIHVu dGlsIDIwMTctMDItMjIgLg0KPiANCj4gVGhhbmtzIQ0KPiBKYWltZSBKaW3DqW5leg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90 ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBk aXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls IGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGlu ZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlDQo+IA0KDQo= From nobody Tue Feb 28 14:08:42 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C5412950F; Tue, 28 Feb 2017 14:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF4NohSoemJs; Tue, 28 Feb 2017 14:08:38 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0097.outbound.protection.outlook.com [104.47.37.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03DB128BA2; Tue, 28 Feb 2017 14:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nvhgM4IcHvFAo5MNOCl7hs/zKyK0Qy7JKoFoww320+k=; b=gq6MiaaNjGoMDz+o5rBkT4vbSBxNVinfvAJohOWEfZYl3pmGUGzqrzLmM2FHb7yhadmbreF5okJbaGBuFjmuWw8Yz4WESty36d6YQB7shqm40GMFXpygycouGzIWGeyWwhU7Sl5OWv2wmxQV46dq0xjI6P6zhCd+L1me9YF4cC0= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2377.namprd03.prod.outlook.com (10.166.207.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Tue, 28 Feb 2017 22:08:37 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0933.019; Tue, 28 Feb 2017 22:08:37 +0000 From: Brian Raymor To: "Dijk, Esko" , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRs?= =?utf-8?Q?s_-_additional_comments?= Thread-Index: AdKM6nDt5cMs5HvrSgCpKqYuXQ1L7gFHk8gA Date: Tue, 28 Feb 2017 22:08:37 +0000 Message-ID: References: <832633f9d14349e18a20fde166b2f95d@AM3PR90MB0097.MGDPHG.emi.philips.com> In-Reply-To: <832633f9d14349e18a20fde166b2f95d@AM3PR90MB0097.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: philips.com; dkim=none (message not signed) header.d=none;philips.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: cd4d24ea-17b3-4226-7897-08d460265852 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2377; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2377; 7:N1ZD8vop64qq+1Xz2AALW3CJSU+a7BSuOjJcyM+spI4cW3oN1Ha64lAVXlzmhX+v0LDnM/lMyzBL3OQdkpkk9XMDcYbKlQUddkLV2hAsJEL0WQ+vDX2KlwbyWZ/AUNGxaHlv3KSfi5yNQVnNzT0bSkkISuo0pHtwtP037ZBpoEu+1VJTS0QpRSoo88ZQ9NB0RnlP8L49XjjJ1KRbqi7RfT7eVZHoPWeaQG/Pokrx1gMAfHRwGGRYHi2S3zOD01KGxMqzxai1DzuTN2XsJTSrQanYR05bUyYBwc9ceiMJBeYzUQJqKscpToPPOUCVapDeqQ/2FBPToxlsOknrS401/H93abt263O62Jc1p8X1jcs= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:CY1PR03MB2377; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2377; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(55904004)(374574003)(377424004)(85714005)(33656002)(66066001)(10090500001)(5005710100001)(74316002)(10290500002)(102836003)(7696004)(6116002)(790700001)(50986999)(54356999)(229383001)(76176999)(4326008)(7736002)(189998001)(5660300001)(122556002)(2950100002)(38730400002)(53546006)(229853002)(6246003)(9686003)(8936002)(7906003)(81166006)(3660700001)(25786008)(55016002)(2906002)(53936002)(54906002)(54896002)(86362001)(236005)(2900100001)(230783001)(6306002)(99286003)(6436002)(6506006)(3280700002)(606005)(92566002)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2377; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2380F684B44F43B9637F8D9183560CY1PR03MB2380namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 22:08:37.0924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2377 Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls_-?= =?utf-8?q?_additional_comments?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 22:08:41 -0000 --_000_CY1PR03MB2380F684B44F43B9637F8D9183560CY1PR03MB2380namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IDEuIEluIFJGQyA3MjUyLCB0aGUgUmVzZXQgbWVzc2FnZSAoUlNUKSBpcyBhbHNvIHVzZWQg dG8gZGVhbCB3aXRoIGNlcnRhaW4gY2FzZXMgb2YgbWFsZm9ybWVkIENvQVAgbWVzc2FnZXMgb3Ig aW5jb3JyZWN0IGZpZWxkIHZhbHVlcy4NCj4gU2luY2UgdGhlIFJTVCBtZXNzYWdlIGlzIG5vdyBy ZW1vdmVkLCBJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSB0ZXh0IG9uIGhvdyB0byBkZWFsIHdpdGgg dGhlc2UgY2FzZXMuDQo+IEZvciBleGFtcGxlIGluIEZpZ3VyZSAyMSAoUkZDIDcyNTIpIHRoZSBU b2tlbiB2YWx1ZSBpcyBub3QgcmVjb2duaXplZCB3aGljaCBsZWFkcyB0byBhIFJTVC4gSG93IHNo b3VsZCBDb0FQLW92ZXItcmVsaWFibGUgZGVhbCB3aXRoIHRoaXMgY2FzZSBhbmQgcmVsYXRlZCBj YXNlcz8NCj4gQWx0aG91Z2ggdGhlIGRyYWZ0IHN1Z2dlc3RzIHRoYXQgQ2xpZW50IChpZiB3ZSB0 YWtlIHRoZSBGaWcgMjEgY2FzZSkgY291bGQgYWJvcnQgdGhlIGNvbm5lY3Rpb24sIHRoYXQgc291 bmRzIHJhdGhlciBkcmFzdGljIGFuZCB1bm5lY2Vzc2FyeSDigJMgdGhlIGNsaWVudCBhbmQgc2Vy dmVyIG5lZWQgdG8ga2VlcCB0YWxraW5nIHRvIGVhY2ggb3RoZXIgdHlwaWNhbGx5Lg0KPiBTaWxl bnRseSBpZ25vcmluZyBzZWVtcyBiZXR0ZXIgaW4gdGhhdCBjYXNlLiBBbmQgaW4gY2FzZSB0aGUg cmVjZWl2ZXIgb2YgYW4gJ2luY29ycmVjdCcgbWVzc2FnZSBkZWNpZGVzIG5vdCB0byBhYm9ydCwg d2hhdCBzaG91bGQgaXQgZG8gaW5zdGVhZCDigJMgYW55dGhpbmcgbm9ybWF0aXZlPw0KPHNuaXA+ DQo+IFN1bW1hcml6aW5nIGl0IHNlZW1zIHRvIG1lIHRoZSBiZXN0IHRvIHNwZWNpZnkgYSByZWNl aXZlciBNQVkgYWJvcnQgdGhlIGNvbm5lY3Rpb24gYW5kIGFsc28gTVVTVCBzaWxlbnRseSBpZ25v cmUgdGhlIG1hbGZvcm1lZCBtZXNzYWdlLiBUaGlzIGNvdWxkIGJlIG1hZGUgbW9yZSBleHBsaWNp dCBpbiB0aGUgdGV4dC4NCg0KVHJhY2tpbmcgaW4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cv Y29hcC10Y3AtdGxzL2lzc3Vlcy8xMTcNCg0KTXkgaW5pdGlhbCBpbnN0aW5jdCB3b3VsZCBiZSBN VVNUIGFib3J0IHRoZSBjb25uZWN0aW9uLiBDYW4gdGhvc2Ugd2l0aCBlYXJseSAoYnV0IHNoaXBw aW5nKSBpbXBsZW1lbnRhdGlvbnMgb2ZmZXIgYW55IGd1aWRhbmNlIG9uIGhvdyB0aGlzIGNhc2Ug aXMgY3VycmVudGx5IGJlaW5nIGhhbmRsZWQ/IFdoYXQgZG8gb3RoZXJzIHRoaW5rPw0KDQo+IDIu ICBzL3Rva2VuL1Rva2VuLyAgLT4ganVzdCB0byBjb21wbHkgd2l0aCB0aGUgUkZDIDcyNTIgbm90 YXRpb24NCg0KT0suDQoNCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKYWltZSBKaW3DqW5leg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAx NSwgMjAxNyAxMzoxNw0KVG86IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+IFdH IDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NCkNjOiBkcmFmdC1pZXRmLWNv cmUtY29hcC10Y3AtdGxzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3At dGxzQGlldGYub3JnPg0KU3ViamVjdDogW2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUt Y29hcC10Y3AtdGxzDQoNCkRlYXIgQ29SRSBXRywNCg0KVGhlcmUgaGFzIGJlZW4gcXVpdGUgc29t ZSB3b3JrIG9uIHRoZSAiQ29BUCAoQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wpIG92 ZXIgVENQLCBUTFMsIGFuZCBXZWJTb2NrZXRz4oCdIGRyYWZ0IChkcmFmdC1pZXRmLWNvcmUtY29h cC10Y3AtdGxzKSBzaW5jZSB0aGUgbGFzdCBXR0xDLg0KQklHIHRoYW5rcyB0byBCcmlhbiBmb3Ig dGhlIHRpbWUgYW5kIGVmZm9ydCBkZWRpY2F0ZWQgYXMgRWRpdG9yLiBJdCBub3cgc2VlbXMgYSBn b29kIHRpbWUgZm9yIGEgZmluYWwgV0dMQyB0byBnZXQgdGhlIGxhc3QgY29tbWVudHMgZnJvbSB0 aGUgZ3JvdXAgaW4gb3JkZXIgdG8gbW92ZSB0aGUgc3BlY2lmaWNhdGlvbiBmb3J3YXJkLg0KDQpJ biBwYXJ0aWN1bGFyIHRoZXJlIGhhcyBub3QgYmVlbiBtdWNoIGRpc2N1c3Npb24gb24gc2VjdXJp bmcgQ29BUCBvdmVyIFdlYlNvY2tldHMgKGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAt dGNwLXRscy9pc3N1ZXMvMTAyKSBhcyB3ZWxsIGFzIHRoZSBEZWZhdWx0IFVSSSBob3N0IChodHRw czovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEwOCkgZmVlZGJhY2sg d291bGQgYmUgdmVyeSBtdWNoIHdlbGNvbWVkLiBQbGVhc2UgZ28gYWhlYWQgYW5kIGNoZWNrIHRo ZSBkaXNjdXNzaW9ucyBvbiB0aGUgb3RoZXIgaXNzdWVzIG9mIHRoaXMgdmVyc2lvbjogaHR0cHM6 Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL21pbGVzdG9uZS80P2Nsb3NlZD0xICBh bmQgb24gdGhlIGNoYW5nZWxvZyBzdW1tYXJ5LiBJbiBhZGRpdGlvbiB0byB0aGF0LCBJIHdvdWxk IGxpa2UgdG8gYXNrIHRoZSBncm91cCB0byBsZXQgbWUga25vdyB0aGVpciBjdXJyZW50IGltcGxl bWVudGF0aW9uIHN0YXR1cyBvZiB0aGUgZHJhZnQgZm9yIHRoZSBzaGVwaGVyZCB3cml0ZXVwLCBl c3BlY2lhbGx5IE9wZW4gU291cmNlIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgZHJhZnQuDQoNCmxh dGVzdCB2ZXJzaW9uOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LWNvYXAtdGNwLXRscy0wNg0KZGlmZjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNi50eHQNCmNoYW5nZWxvZzogaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDYjYXBw ZW5kaXgtQy40DQoNClRoZSBXR0xDIHdpbGwgbGFzdCBvbmUgd2VlaywgdW50aWwgMjAxNy0wMi0y MiAuDQoNClRoYW5rcyENCkphaW1lIEppbcOpbmV6DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkg YmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxh dy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVj dGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29u dGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBv ZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== --_000_CY1PR03MB2380F684B44F43B9637F8D9183560CY1PR03MB2380namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTgz NzY3NDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x NjMwOTk2MjQ2IDQ0NDUyMDg3OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXN0YXJ0LWF0OjY0NTQ7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTA4MTQ4NTM4ODsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTgwODU5NjAzNCAtNDc3OTgy NDMwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAu MjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMTpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU2LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjkyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTI4LjI1cHQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjE2NC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMDAuMjVw dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMzYuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MjcyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMwOC4yNXB0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7IDEuIEluIFJGQyA3MjUyLCB0aGUgUmVzZXQgbWVzc2FnZSAoUlNUKSBpcyBh bHNvIHVzZWQgdG8gZGVhbCB3aXRoIGNlcnRhaW4gY2FzZXMgb2YgbWFsZm9ybWVkIENvQVAgbWVz c2FnZXMgb3IgaW5jb3JyZWN0IGZpZWxkIHZhbHVlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlNpbmNlIHRoZSBSU1QgbWVzc2FnZSBpcyBub3cgcmVtb3ZlZCwgSSB0aGluayB0 aGVyZSBzaG91bGQgYmUgdGV4dCBvbiBob3cgdG8gZGVhbCB3aXRoIHRoZXNlIGNhc2VzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIGV4YW1wbGUgaW4gRmlndXJlIDIxIChS RkMgNzI1MikgdGhlIFRva2VuIHZhbHVlIGlzIG5vdCByZWNvZ25pemVkIHdoaWNoIGxlYWRzIHRv IGEgUlNULiBIb3cgc2hvdWxkIENvQVAtb3Zlci1yZWxpYWJsZSBkZWFsIHdpdGggdGhpcyBjYXNl IGFuZCByZWxhdGVkIGNhc2VzPyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgQWx0aG91Z2ggdGhlIGRyYWZ0IHN1 Z2dlc3RzIHRoYXQgQ2xpZW50IChpZiB3ZSB0YWtlIHRoZSBGaWcgMjEgY2FzZSkgY291bGQgYWJv cnQgdGhlIGNvbm5lY3Rpb24sIHRoYXQgc291bmRzIHJhdGhlciBkcmFzdGljIGFuZCB1bm5lY2Vz c2FyeSDigJMgdGhlIGNsaWVudCBhbmQgc2VydmVyIG5lZWQgdG8NCiBrZWVwIHRhbGtpbmcgdG8g ZWFjaCBvdGhlciB0eXBpY2FsbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5T aWxlbnRseSBpZ25vcmluZyBzZWVtcyBiZXR0ZXIgaW4gdGhhdCBjYXNlLiBBbmQgaW4gY2FzZSB0 aGUgcmVjZWl2ZXIgb2YgYW4gJ2luY29ycmVjdCcgbWVzc2FnZSBkZWNpZGVzIG5vdCB0byBhYm9y dCwgd2hhdCBzaG91bGQgaXQgZG8gaW5zdGVhZCDigJMgYW55dGhpbmcgbm9ybWF0aXZlPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdW1tYXJpemlu ZyBpdCBzZWVtcyB0byBtZSB0aGUgYmVzdCB0byBzcGVjaWZ5IGEgcmVjZWl2ZXIgTUFZIGFib3J0 IHRoZSBjb25uZWN0aW9uIGFuZCBhbHNvIE1VU1Qgc2lsZW50bHkgaWdub3JlIHRoZSBtYWxmb3Jt ZWQgbWVzc2FnZS4gVGhpcyBjb3VsZCBiZSBtYWRlIG1vcmUgZXhwbGljaXQgaW4gdGhlIHRleHQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRyYWNraW5nIGluDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v Y29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzExNyI+aHR0cHM6Ly9naXRodWIuY29tL2NvcmUt d2cvY29hcC10Y3AtdGxzL2lzc3Vlcy8xMTc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGluaXRpYWwg aW5zdGluY3Qgd291bGQgYmUgTVVTVCBhYm9ydCB0aGUgY29ubmVjdGlvbi4gQ2FuIHRob3NlIHdp dGggZWFybHkgKGJ1dCBzaGlwcGluZykgaW1wbGVtZW50YXRpb25zIG9mZmVyIGFueSBndWlkYW5j ZSBvbiBob3cgdGhpcyBjYXNlIGlzIGN1cnJlbnRseSBiZWluZyBoYW5kbGVkPw0KIFdoYXQgZG8g b3RoZXJzIHRoaW5rPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Mi4gJm5ic3A7cy90b2tlbi9Ub2tlbi8mbmJzcDsgLSZndDsganVzdCB0byBjb21w bHkgd2l0aCB0aGUgUkZDIDcyNTIgbm90YXRpb24NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5PSy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBjb3JlIFs8YSBo cmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFpbWUgSmltw6luZXo8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyAxMzoxNzxicj4NCjxiPlRvOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+IFdHICZs dDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRs c0BpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRsc0BpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW2NvcmVdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssc2Fucy1zZXJpZiI+ JiMxMjgyNzY7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFdHTEMgZHJhZnQtaWV0Zi1jb3JlLWNv YXAtdGNwLXRsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5EZWFyIENvUkUgV0csPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGhhcyBiZWVuIHF1aXRlIHNvbWUgd29yayBvbiB0aGUg JnF1b3Q7Q29BUCAoQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wpIG92ZXIgVENQLCBU TFMsIGFuZCBXZWJTb2NrZXRz4oCdIGRyYWZ0IChkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz KSBzaW5jZSB0aGUgbGFzdCBXR0xDLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QklHIHRoYW5rcyB0byBCcmlhbiBmb3IgdGhlIHRpbWUg YW5kIGVmZm9ydCBkZWRpY2F0ZWQgYXMgRWRpdG9yLiBJdCBub3cgc2VlbXMgYSBnb29kIHRpbWUg Zm9yIGEgZmluYWwgV0dMQyB0byBnZXQgdGhlIGxhc3QgY29tbWVudHMgZnJvbSB0aGUgZ3JvdXAg aW4gb3JkZXIgdG8gbW92ZSB0aGUgc3BlY2lmaWNhdGlvbiBmb3J3YXJkLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwYXJ0aWN1 bGFyIHRoZXJlIGhhcyBub3QgYmVlbiBtdWNoIGRpc2N1c3Npb24gb24gc2VjdXJpbmcgQ29BUCBv dmVyIFdlYlNvY2tldHMgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAt dGNwLXRscy9pc3N1ZXMvMTAyIj5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10 bHMvaXNzdWVzLzEwMjwvYT4pIGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3QgKDxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTA4Ij5o dHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEwODwvYT4pDQog ZmVlZGJhY2sgd291bGQgYmUgdmVyeSBtdWNoIHdlbGNvbWVkLiBQbGVhc2UgZ28gYWhlYWQgYW5k IGNoZWNrIHRoZSBkaXNjdXNzaW9ucyBvbiB0aGUgb3RoZXIgaXNzdWVzIG9mIHRoaXMgdmVyc2lv bjombmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMv bWlsZXN0b25lLzQ/Y2xvc2VkPTEiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNw LXRscy9taWxlc3RvbmUvND9jbG9zZWQ9MTwvYT4mbmJzcDsmbmJzcDthbmQNCiBvbiB0aGUgY2hh bmdlbG9nIHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0byBhc2sg dGhlIGdyb3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gc3Rh dHVzIG9mIHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFsbHkgT3Bl biBTb3VyY2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxhdGVzdCB2ZXJzaW9u OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNv cmUtY29hcC10Y3AtdGxzLTA2Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jb3JlLWNvYXAtdGNwLXRscy0wNjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlmZjombmJzcDs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz LTA2LnR4dCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1j b3JlLWNvYXAtdGNwLXRscy0wNi50eHQ8L2E+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jaGFuZ2Vsb2c6Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDYj YXBwZW5kaXgtQy40Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LWNvYXAtdGNwLXRscy0wNiNhcHBlbmRpeC1DLjQ8L2E+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBXR0xDIHdpbGwgbGFzdCBv bmUgd2VlaywgdW50aWwmbmJzcDs8Yj4yMDE3LTAyLTIyPC9iPiAuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphaW1lIEppbcOp bmV6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0i Y2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmdyYXkiPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBj b25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBU aGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlv dQ0KIGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZp ZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rp b24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRh Y3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZA0KIGRlc3Ryb3kgYWxsIGNvcGllcyBv ZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_CY1PR03MB2380F684B44F43B9637F8D9183560CY1PR03MB2380namp_-- From nobody Tue Feb 28 21:54:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FEA1293E0; Tue, 28 Feb 2017 21:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIJMtYSXv88m; Tue, 28 Feb 2017 21:54:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA11127058; Tue, 28 Feb 2017 21:54:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CB3E1B81E14; Tue, 28 Feb 2017 21:54:11 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170301055411.CB3E1B81E14@rfc-editor.org> Date: Tue, 28 Feb 2017 21:54:11 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, core@ietf.org, rfc-editor@rfc-editor.org Subject: [core] RFC 8075 on Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 05:54:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8075 Title: Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) Author: A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk Status: Standards Track Stream: IETF Date: February 2017 Mailbox: angelo@castellani.net, Salvatore.Loreto@ericsson.com, Akbar.Rahman@InterDigital.com, thomas.fossati@nokia.com, esko.dijk@philips.com Pages: 40 Characters: 86096 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-core-http-mapping-17.txt URL: https://www.rfc-editor.org/info/rfc8075 DOI: 10.17487/RFC8075 This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC