From tianlinyi@huawei.com Wed Jun 1 01:03:56 2011 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 00B21E06BF for ; Wed, 1 Jun 2011 01:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRP7X9S2m7oB for ; Wed, 1 Jun 2011 01:03:54 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 14BC8E0675 for ; Wed, 1 Jun 2011 01:03:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM30036HQC8AH@szxga03-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 16:02:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM3001TBQC86K@szxga03-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 16:02:32 +0800 (CST) Received: from T34932F ([10.70.109.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LM3006JKQC8EK@szxml06-in.huawei.com> for core@ietf.org; Wed, 01 Jun 2011 16:02:32 +0800 (CST) Date: Wed, 01 Jun 2011 16:02:32 +0800 From: Linyi Tian In-reply-to: <057.b32fa055beb54b0a5bae0f7915fff78c@trac.tools.ietf.org> To: trac+core@zinfandel.tools.ietf.org, hartke@tzi.org, zach@sensinode.com Message-id: <00ca01cc2032$42737be0$c75a73a0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcwdPePcDeDE24kUSh+NqlpiU/iNjwC9CEKw References: <057.b32fa055beb54b0a5bae0f7915fff78c@trac.tools.ietf.org> Cc: core@ietf.org Subject: Re: [core] #161: Registration for 2-byte media type codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 08:03:56 -0000 I am not quite understand this ticket. Can anybody explain? In section = 5.10 Content-Type was defined as 1-2 bytes. In section 11.3 "media type = registry" it recommends M2M applications to register new media types. I = don't know what else is needed.=20 Cheers, Linyi >>-----Original Message----- >>From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of core >>issue tracker >>Sent: Saturday, May 28, 2011 9:48 PM >>To: hartke@tzi.org; zach@sensinode.com >>Cc: core@ietf.org >>Subject: [core] #161: Registration for 2-byte media type codes >> >>#161: Registration for 2-byte media type codes >> >> coap-06 currently defines a Media Type Code registry for single byte = code >> values, meant for frequently used media types. The two-byte codes are = just >> reserved for future use. >> >> In order to encourage registration of media types, a less restrictive >> registration for the codes 256-65535 will be added. >> >>-- >>--------------------------------+--------------------------------------= ----- >> Reporter: zach@=E2=80=A6 | Owner: = hartke@=E2=80=A6 >> Type: task | Status: new >> Priority: minor | Milestone: >>Component: coap | Version: >> Severity: - | Keywords: >>--------------------------------+--------------------------------------= ----- >> >>Ticket URL: >>core >> >>_______________________________________________ >>core mailing list >>core@ietf.org >>https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Wed Jun 1 09:45:06 2011 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 2D8BA130010 for ; Wed, 1 Jun 2011 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW1eDjVVrl2n for ; Wed, 1 Jun 2011 09:45:05 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id ABBA9E067E for ; Wed, 1 Jun 2011 09:45:03 -0700 (PDT) Received: from [10.16.1.3] ([194.79.18.62]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p51GioV0023598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2011 19:44:51 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-18-74495778; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 1 Jun 2011 18:44:53 +0200 Message-Id: <45956A4A-5C0D-4AC9-B929-35A6B3DF41F1@sensinode.com> References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 16:45:06 -0000 --Apple-Mail-18-74495778 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 1, 2011, at 5:46 AM, Cullen Jennings wrote: > It's a binary string that is bit wise compared and is capable of = caring a UTF-8 value. I guess this discussion is helping me get clear on = explaining what I think implementors want. I think they want to treat = these as binary strings and they are fine with requirement that these = binary strings be capable of caring UTF-8 data but there not handling it = as UTF-8 data. They are taking a more generic handling of it and don't = want to do the things UTF-8 processing would require. Does this make any = sense or sound reasonable? Exactly. So we need to define "The CoRE link format MUST use UTF-8 = encoding [RFC3629]" without mentioning NFC (as Alexey also recommended) = with a paragraph about how we expect implementations to treat this. I = will make a ticket to this extent and work on some text.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-18-74495778 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYwMTE2NDQ1 NFowIwYJKoZIhvcNAQkEMRYEFEVnTjeKA4XvbQ5yV0K/79E0VcixMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFn5NG8coZSEK+xtU0DVfYgEoExQPqlbT56vlUBDRFlUejq3hlCglTDt D2FGl6edtQPJfZXZmpPaHCQk3J/+Ks+M7TB4j2i9CfBX73HgPeXXizJ5DNgp0NGdyKGQVDIoaxiZ M9rBTFyIfnO/2/8DBVEqagIw676VFmzL7yj4dbezwt1rUh70+ka1PORgii90vtG77KOPOHcsNE8A OvHXCzMfpSIb7W752dqSumQzdyYLXoysNythBpGb/DNLl3H6Ay1drm1RZ0WVDNMKcOgWGO3k7tW6 E/0Bd3KKhT31KmdhWKXqx4AWbesDX5mWylwsHvXsPlOD40l6gTg4WpLIhuAAAAAAAAA= --Apple-Mail-18-74495778-- From tianlinyi@huawei.com Wed Jun 1 18:20:37 2011 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 4AF84E0749 for ; Wed, 1 Jun 2011 18:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4laPa-Y9vfvt for ; Wed, 1 Jun 2011 18:20:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9A27AE06A0 for ; Wed, 1 Jun 2011 18:20:35 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM500D982E813@szxga04-in.huawei.com> for core@ietf.org; Thu, 02 Jun 2011 09:20:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM500AEC2E85P@szxga04-in.huawei.com> for core@ietf.org; Thu, 02 Jun 2011 09:20:32 +0800 (CST) Received: from T34932F ([10.70.109.115]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LM5006AN2E81H@szxml04-in.huawei.com> for core@ietf.org; Thu, 02 Jun 2011 09:20:32 +0800 (CST) Date: Thu, 02 Jun 2011 09:20:32 +0800 From: Linyi Tian To: 'core' Message-id: <006801cc20c3$44492e60$ccdb8b20$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acwgi9Cm+tf7NXKoRpiGKSW9BId4TAAN1QUw Subject: [core] FW: Throughout review on Link Format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 01:20:37 -0000 Hi, All Since Zach didn't see this review at all. I guess it may be dropped by the email system. I resend it to the list for review. Cheers, Linyi -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Thursday, June 02, 2011 1:48 AM To: Linyi Tian Subject: Re: Throughout review on Link Format draft Hi! Hmmm. I didn't see this at all, thanks for resending it to me. I will take care of the editorial changes during the -07 work. Zach On Jun 1, 2011, at 11:04 AM, Linyi Tian wrote: > Hi, Zach > > > > It looks like my review was ignored or missed. So I just resend it to you without bother the list again. I would appreciate if you can take a look. > > > > Cheers, > > Linyi > > > > From: Linyi Tian [mailto:tianlinyi@huawei.com] > Sent: Friday, April 08, 2011 4:21 PM > To: 'core' > Subject: Throughout review on Link Format draft > > > I did throughout review of this draft and provides the following comments: > > Convention: > > [S1-P2] refers to [Section 1 - Paragraph 2] > > [c1] refers to [comment 1 ] > > 1. [S1-P2] [c1] Is "constrained web server" the correct term? Should we remove "web"? > > "In this document we refer to the discovery of resources hosted by a constrained web server, their attributes and other resource relations as CoRE Resource Discovery." > > > > 2. [S1-P3] [c2] Add "application/link-format as defined in section 7.4" at the end of following sentence to improve the readability. > > The CoRE Link Format is carried as a payload and is assigned an Internet media type. > > > > 3. [S1.1-P1] [S2.2-P2] > > [c3] If the resource is not hosted by the server, how to indicate this info? Since the "hosts" is the default relation type, should we define "external" instead? > > The relation types in Link Format are used to describe the resources in sensors. It is quite different with the web environment. I reviewed the RFC5988 carefully and believe that most of the relation types can't be used by Link Format. I suggest we have a table to list the ones that may be applicable to link format. > > > > 4. [S1.3] [c4] typo in "Link" term. Change "a tarfet" to "a target". > > > > 5. [S2-P3] [c5] typo in last sentence. Add "is" after "why it.useful". Change "Unicode" to "Unicode" > > See section 3 of [RFC5198], which explains why it useful to represent Unicode in a single unique form. > > > > 6. [S2.1] [c6] Examples should be added to improve the readability. I also propose to use "Base URIs" to replace "Context URI" and rephrase the text as following: > > Section 2.1 Target and Base URIs > > Each link conveys one target URI as a URI-reference inside angle brackets ("<>"). The base URI (defined in [RFC3986]) conveyed in the CoRE Link Format is by default built from the scheme and authority parts of the target URI. In the absence of scheme and authority, the base URI is built from the scheme and authority parts of the target resource which returning the set of links. > > The CoRE link format includes one or more links, each describing a resource hosted by a server using relation type "hosts". Other relations can be expressed by including an anchor parameter (which defines the base URI) along with an explicit relation parameter. This is an important difference to the way the HTTP Link Header format is used, as it is included in the header of an HTTP response for some URI (this URI is by default the base URI). Thus the HTTP Link Header is by default relating the target URI to the URI that was requested. See Section 5 of [RFC3986] for a description of how URIs are constructed from URI references. > > This example shows the base URI construction. ( I didn't update the example since I believe something wrong inside). > > REQ: GET /.well-known/core > > RES: 200 OK > > ;ct=40;rt="index";rt="Sensor Index", -------base URI is xxxx > > ;rt="TemperatureC";if="sensor", ----base URI is xxxx > > ;ct=41;rt="LightLux";if="sensor", ---base URI is xxxx > > ;anchor="/sensors/temp" > > ;rel="describedby", ---base URI is xxxx > > ;anchor="/sensors/temp";rel="alternate" ---base URI is xxxx > > > > 7. [S3.1-P2] [c7] typo. Add "be" after "The resource type attribute is not meant to ...used". > > > > 8. [S4-P2] [c8]What is the default port? > > > > 9. [S4.1-P2] [c9] Typo in the following sentence. What does "They name" mean? > > Other resource-param values refer to the link attribute they name > > > > 10.[S1.2.3-P2] [c10] resource directory service needs to be defined. How to register the link format and how to access it per sensor basis need to be defined. > > > > 11.[S2.2-P2][S5] [c11] I believe most of the relation types are not appropriate for CoAP. For example, "alternate" is used together with "type", "media" or other attributes for special meaning. You can refer to 4.12.4.1 of http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-a lternate for further details. While in the example of section 5 of Link Format, we use "alternate" to indicate the short URI which is not defined. The same issue is for "described" in the example. It is used for reference of POWER document while we use it for URI description. We'd better to have a table to list the relation types that are applicable to CoAP rather than saying that anyone can be used in section 2.2. > -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From alexey.melnikov@isode.com Sat Jun 4 13:54:23 2011 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 00F0C21F84DC for ; Sat, 4 Jun 2011 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7qkyLr9tkSR for ; Sat, 4 Jun 2011 13:54:22 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 33FF921F84DB for ; Sat, 4 Jun 2011 13:54:17 -0700 (PDT) Received: from [188.28.114.130] (188.28.114.130.threembb.co.uk [188.28.114.130]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 4 Jun 2011 21:54:14 +0100 Message-ID: <4DEA9B53.6040002@isode.com> Date: Sat, 04 Jun 2011 21:53:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cullen Jennings References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: core WG Subject: Re: [core] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 20:54:23 -0000 Cullen Jennings wrote: >On May 26, 2011, at 11:14 AM, Alexey Melnikov wrote: > =20 > >>Cullen Jennings wrote: >> =20 >> >>>On May 24, 2011, at 3:03 PM, Alexey Melnikov wrote: >>> =20 >>> >>>>Zach Shelby wrote: >>>> =20 >>>> >>>>>On May 4, 2011, at 8:29 PM, Cullen Jennings wrote: >>>>> =20 >>>>> >>[...] >> =20 >> >>>>>>Related to this, where it says the CoRE link format MUST be in UTF-= 8 and SHOULD be NFC. This seems wrong unless we are updating RFC5988. RFC= 5988 makes it clear the links are as defined in rfc3986. We don't need to= say any more or less than RFC5988. Unless someone can tell me how my imp= lementation and interoperability changes by specifying UTF-8 and NFC, I'd= like to see that removed. The phrase "MUST be compared as strings" is pr= etty vague when discussing UTF-8 strings. If people disagree here, I'm go= ing to argue that unicode has a perfectly good symbol for angstrom and if= someone wants to use that, I think they should be able to use it. Given = this is format is for machine readability, an angstrom is not the same as= a character that might look the same when printed on paper and that diff= erence should not be lost. All in all, the documents this depends on, su= ch as 5988 deal with the right level of using UTF-8. This draft should ju= st be silent on the i >>>>>>ssue and you can probably remove all mention of UTF-8. Regardless o= f the UTF-8 issues, it seems the media type registration should have bina= ry not 8bit. =20 >>>>>> >>>>>This is how I started out, but in a couple review's a couple version= s back it was suggested that we specify UTF-8 and we made a ticket for th= at. The intention is definitely to be in line with RFC5988, so I would be= more than happy to have no mention of UTF-8 in the document and instead = just say "the links are as defined in rfc3986". Again, will make a ticket= if I hear no objections. >>>>> =20 >>>>> >>>>But RFC 3986 only covers URIs and CoRE link format can include other = data? >>>>I think saying that the format contains UTF-8 is actually useful for = future extensibility. >>>> =20 >>>> >>>I think the part I am getting hung up on is what is allowed, and what = needs to be checked and enforced by everyone. I think most the WG agrees = they want implementation to treat things as just a bunch of bits that is = passed around with no bitwise changes and are compared bit for bit. >>> =20 >>> >>That is fine. But this doesn't mean that data is binary (for example). >> =20 >> >>>They are perfectly happy if these bit strings turn out to be UTF-8 str= ings and no desire to limit it to US-ASCII for the stuff that is meant fo= r humans instead of machines. I suspect you are roughly on the same page = but the question is how to get the specification to say that clearly enou= gh that implementors don't get confused. Some of this confusion is introd= uced by people that don't understand core and are arguing against it's us= e - for example I recently saw a draft presentation that claimed small co= nstrained nodes implement core would need a full XML library and unicode = string process library. I straightened out that presentation but was I li= ke the specs to be clear enough that I did not see stuff like that.=20 >>>Thoughts on how to get this clear in the main coap draft as well as he= re. >>> =20 >>> >>I think at least saying that any CORE link format payload is UTF-8 is u= seful. This tells implementations what they should generate and what they= can expect. And if they want to check for UTF-8 and reject invalid data,= they can. If you want to say more than "MUST be UTF-8", then you should = probably have separate statements about what compliant generators should = produce and what consumers should do. >> >>NFC or any other form of Unicode normalization is useful for comparison= or lookup of values. If UTF-8 data is only used for display, I don't thi= nk this is needed. >> =20 >> > >The stuff I am concerned about is not used for display to humans, but it= is used for comparisons in machine to machine applications. We can ask t= he WG but the I think the odds are pretty good no one will want to implem= ent NFC on a constrained devices. > I already proposed to drop the requirement to use NFC. I agree it is=20 expensive to implement. >As far as I can tell it's not UTF-8 as far as these devices are concerne= d. It's a binary string that is bit wise compared and is capable of carin= g a UTF-8 value. I guess this discussion is helping me get clear on expla= ining what I think implementors want. I think they want to treat these as= binary strings and they are fine with requirement that these binary stri= ngs be capable of caring UTF-8 data but there not handling it as UTF-8 da= ta. They are taking a more generic handling of it and don't want to do th= e things UTF-8 processing would require. Does this make any sense or soun= d reasonable? > =20 > Each Unicode character has a single representation in UTF-8, so=20 octet-by-octet comparisons work just fine for data in UTF-8. My question is: should invalid UTF-8 (e.g. an octet 0xFF) be allowed? If invalid UTF-8 should not be allowed, then some CORE agents can choose = to verify UTF-8 (And others will choose not to. Maybe most of them).=20 Verifying UTF-8 validity is really easy, especially when compared to=20 implementing NFC. From fluffy@cisco.com Mon Jun 6 15:14:26 2011 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 DE2B711E81D1 for ; Mon, 6 Jun 2011 15:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRyqgZ53FfFl for ; Mon, 6 Jun 2011 15:14:26 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 07B7811E8073 for ; Mon, 6 Jun 2011 15:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5760; q=dns/txt; s=iport; t=1307398465; x=1308608065; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NO4D5RXnhS+r8Unh+kAWyypPJD+uz1xNXlqKJp2VZVo=; b=E0KhM0uE750HRU1yPjb3c8VyHguSE1cSOtIf46jVFl0KIgOVzT2uaFu8 +qqwazqVVwaoqHJyZPgvKG1ae+Ok8+CWoDtlVYHuos2la/GR1ragTmtK9 gBnVPa9/nU78Dqosn8CQLSLac4TRoYxAm/sfynPO/59DAep3tJF3eaFNk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL9Q7U2rRDoI/2dsb2JhbABTphF3iHGjcZ4ShiEEhnSKBYRIixE X-IronPort-AV: E=Sophos;i="4.65,328,1304294400"; d="scan'208";a="371365516" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 06 Jun 2011 22:14:25 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p56MEOh9023509; Mon, 6 Jun 2011 22:14:24 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DEA9B53.6040002@isode.com> Date: Mon, 6 Jun 2011 16:14:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9DAC6FA4-F236-4C06-A761-245318684509@cisco.com> References: <9CF83338-EB7C-4831-8A44-8DEEF0C42D54@cisco.com> <9DC0A259-3170-4C40-BAB3-697B30FB548C@sensinode.com> <4DDC1D17.8060000@isode.com> <4DDE8A91.3070202@isode.com> <4DEA9B53.6040002@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Comments on draft-ietf-core-link-format-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2011 22:14:27 -0000 On Jun 4, 2011, at 2:53 PM, Alexey Melnikov wrote: > Cullen Jennings wrote: >=20 >> On May 26, 2011, at 11:14 AM, Alexey Melnikov wrote: >>=20 >>> Cullen Jennings wrote: >>> =20 >>>> On May 24, 2011, at 3:03 PM, Alexey Melnikov wrote: >>>> =20 >>>>> Zach Shelby wrote: >>>>> =20 >>>>>> On May 4, 2011, at 8:29 PM, Cullen Jennings wrote: >>>>>> =20 >>> [...] >>> =20 >>>>>>> Related to this, where it says the CoRE link format MUST be in = UTF-8 and SHOULD be NFC. This seems wrong unless we are updating = RFC5988. RFC5988 makes it clear the links are as defined in rfc3986. We = don't need to say any more or less than RFC5988. Unless someone can tell = me how my implementation and interoperability changes by specifying = UTF-8 and NFC, I'd like to see that removed. The phrase "MUST be = compared as strings" is pretty vague when discussing UTF-8 strings. If = people disagree here, I'm going to argue that unicode has a perfectly = good symbol for angstrom and if someone wants to use that, I think they = should be able to use it. Given this is format is for machine = readability, an angstrom is not the same as a character that might look = the same when printed on paper and that difference should not be lost. = All in all, the documents this depends on, such as 5988 deal with the = right level of using UTF-8. This draft should just be silent on the i >>>>>>> ssue and you can probably remove all mention of UTF-8. = Regardless of the UTF-8 issues, it seems the media type registration = should have binary not 8bit. =20 >>>>>> This is how I started out, but in a couple review's a couple = versions back it was suggested that we specify UTF-8 and we made a = ticket for that. The intention is definitely to be in line with RFC5988, = so I would be more than happy to have no mention of UTF-8 in the = document and instead just say "the links are as defined in rfc3986". = Again, will make a ticket if I hear no objections. >>>>>> =20 >>>>> But RFC 3986 only covers URIs and CoRE link format can include = other data? >>>>> I think saying that the format contains UTF-8 is actually useful = for future extensibility. >>>>> =20 >>>> I think the part I am getting hung up on is what is allowed, and = what needs to be checked and enforced by everyone. I think most the WG = agrees they want implementation to treat things as just a bunch of bits = that is passed around with no bitwise changes and are compared bit for = bit. >>>> =20 >>> That is fine. But this doesn't mean that data is binary (for = example). >>> =20 >>>> They are perfectly happy if these bit strings turn out to be UTF-8 = strings and no desire to limit it to US-ASCII for the stuff that is = meant for humans instead of machines. I suspect you are roughly on the = same page but the question is how to get the specification to say that = clearly enough that implementors don't get confused. Some of this = confusion is introduced by people that don't understand core and are = arguing against it's use - for example I recently saw a draft = presentation that claimed small constrained nodes implement core would = need a full XML library and unicode string process library. I = straightened out that presentation but was I like the specs to be clear = enough that I did not see stuff like that. Thoughts on how to get this = clear in the main coap draft as well as here. >>>> =20 >>> I think at least saying that any CORE link format payload is UTF-8 = is useful. This tells implementations what they should generate and what = they can expect. And if they want to check for UTF-8 and reject invalid = data, they can. If you want to say more than "MUST be UTF-8", then you = should probably have separate statements about what compliant generators = should produce and what consumers should do. >>>=20 >>> NFC or any other form of Unicode normalization is useful for = comparison or lookup of values. If UTF-8 data is only used for display, = I don't think this is needed. >>> =20 >>=20 >> The stuff I am concerned about is not used for display to humans, but = it is used for comparisons in machine to machine applications. We can = ask the WG but the I think the odds are pretty good no one will want to = implement NFC on a constrained devices. >>=20 > I already proposed to drop the requirement to use NFC. I agree it is = expensive to implement. >=20 >> As far as I can tell it's not UTF-8 as far as these devices are = concerned. It's a binary string that is bit wise compared and is capable = of caring a UTF-8 value. I guess this discussion is helping me get clear = on explaining what I think implementors want. I think they want to treat = these as binary strings and they are fine with requirement that these = binary strings be capable of caring UTF-8 data but there not handling it = as UTF-8 data. They are taking a more generic handling of it and don't = want to do the things UTF-8 processing would require. Does this make any = sense or sound reasonable? >>=20 > Each Unicode character has a single representation in UTF-8, so = octet-by-octet comparisons work just fine for data in UTF-8. >=20 > My question is: should invalid UTF-8 (e.g. an octet 0xFF) be allowed? >=20 > If invalid UTF-8 should not be allowed, then some CORE agents can = choose to verify UTF-8 (And others will choose not to. Maybe most of = them). Verifying UTF-8 validity is really easy, especially when compared = to implementing NFC. >=20 >=20 Ok - sounds like wwe are the same page. I really don't care about if = 0xFF is allowed or not. Zach's going to have a hard time writing the = text to make this clear.=20 From alper.yegin@yegin.org Fri Jun 10 01:28:05 2011 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 3FEF211E80C5 for ; Fri, 10 Jun 2011 01:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eQ9OrjzeUzY for ; Fri, 10 Jun 2011 01:28:04 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B11A111E8070 for ; Fri, 10 Jun 2011 01:28:04 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lg2Cp-1Pkv1R3tCF-00onFu; Fri, 10 Jun 2011 04:27:54 -0400 From: "Alper Yegin" To: References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> <4DCC45D3.2020304@gridmerge.com> <00bb01cc110e$8e3cb7e0$aab627a0$@yegin@yegin.org> <4DCCF405.2050500@gridmerge.com> In-Reply-To: <4DCCF405.2050500@gridmerge.com> Date: Fri, 10 Jun 2011 11:27:46 +0300 Message-ID: <012201cc2748$4abe8430$e03b8c90$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwRTK3r9qpGJ+YZRF6WafQnADFk+gV9//NA Content-Language: en-us X-Provags-ID: V02:K0:8xlGwHXhL+8oe6Zhyfc3kql9ALLHfeugnOaNdM+qW8p hy+Iwy3WrFtOyOtSazY5mz9u+8iUCoeN1LonSujEnaMN+RW6UC ABK8jI7M81yXESl3+/fehIe+MEDgxTWMfBynCzafC/LULEodN3 swtg15FkZ+AriLslwUTUQfPlOr+zROvvDmopjMoYKWx5Ep3XmC /OyfUJUZpcUcZ0cOOlIYCnhfSxrQjtnufQ3pqxb6ew= Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 08:28:05 -0000 Sorry for the delay getting back to this thread.. > >>> I'm not singling out TLS here. I think this is a fundamental > >>> distinction between channel security vs object-level security. > >> It seems fundamentally easier to encrypt on a channel basis as the > same > >> end-point credentials are used to derive keying information which > can > >> encrypt and integrity protect simultaneously, > > Using object-level security does not change that. > Perhaps I misunderstood what you meant by object-level security. The > way > you described it seemed to suggest that elements of data transacted > within the channel could be individually encrypted. My questions > surround what security material is used to perform the encryption in > each case. Individual data elements, or the whole application-layer data (which includes those individual data elements) can be encrypted using a key shared between the two end-points. Where that key comes from is a separate problem with its own solutions. What I'm seeking is the ability of CoAP to support this possibility. > >> e.g. most efficiently > >> using an AEAD cipher like AES-CCM or AES-GCM. If you start to make > the > >> encryption more granular, what do you then use as the cryptographic > >> basis for secrecy between the transacting objects? Asymmetric or > >> symmetric? > > Symmetric. > > > >> Would you use the same granularity as the channel end > >> points? > >> Or be more granular? > > Not sure I understand. Can you elaborate? > As above - what security material would you use to encrypt? The same > security material as is used for channel encryption? Or something more > granular, i.e. would each distinct element of encrypted data have its > own security material? Not necessarily. A single shared-secret key between the two end-points is sufficient. > What is the distinction? If communicating > objects > multiplex their transactions on a single channel, this could be the > case. > >> All I'm saying is there is probably more to this than meets the eye. > > Let's find out. Alper > > > > Alper > > > > > > > > From alper.yegin@yegin.org Fri Jun 10 01:39:10 2011 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 C208711E80D9 for ; Fri, 10 Jun 2011 01:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG53YCYsRSJw for ; Fri, 10 Jun 2011 01:39:09 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9C26D11E807D for ; Fri, 10 Jun 2011 01:39:09 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M3RNI-1Pdx6x3fc0-00rq36; Fri, 10 Jun 2011 04:38:48 -0400 From: "Alper Yegin" To: "'Zach Shelby'" , References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> <4DCC45D3.2020304@gridmerge.com> <00bb01cc110e$8e3cb7e0$aab627a0$@yegin@yegin.org> <4DCCF405.2050500@gridmerge.com> <7B94A27A-A5BE-42C0-9876-9CD44D7666EA@sensinode.com> In-Reply-To: <7B94A27A-A5BE-42C0-9876-9CD44D7666EA@sensinode.com> Date: Fri, 10 Jun 2011 11:38:40 +0300 Message-ID: <012b01cc2749$d0770a60$71651f20$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwRd5Z2NXRDjrOSR2yS4GZ6PfIo3AV0SLJg Content-Language: en-us X-Provags-ID: V02:K0:2pwNwfYmWuikqF/85hISyZa12NnjP97mV712srLc+Wf b1DEJspJt56Ldac/3i7wnW7O1ey//f8aQueQ/y4dsl9dBs1W44 AyK3Ex9RRe84oHYKCpDA0lZy0u5/FE2eW41d9+pjgcGbb9A5MJ HPlvZPxnqgYHIjXYBonFo4TFbScg/Pe2yQE6q98fPx/kKPNPZa EEDGd0TU7Vb+9dUsyCcRbKQ3gxjjHfi7wWB3tM/hS0= Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 08:39:10 -0000 > This object security discussion is totally orthogonal to the DTLS > security that is default in CoAP (so this really isn't relevant to > core-coap-06). > Object security is definitely interesting in this > domain, and for example the JSON signing BOF in Prague was relevant to > this. I would encourage Alper to write a draft about how to do simple > object security for CoAP. What's I'm thinking is defining an option that can carry the one-way keyed hash of CoAP header + payloads. And another option that can encrypt and encapsulate other options that require privacy. Alper > Robert is right that the security model in > the CoRE context should be an important part of that, as well as > bootstrapping considerations. > > Zach > > On May 13, 2011, at 12:04 PM, Robert Cragie wrote: > > > > > > > On 13/05/2011 2:39 AM, Alper Yegin wrote: > >>>> I'm not singling out TLS here. I think this is a fundamental > >>>> distinction between channel security vs object-level security. > >>> It seems fundamentally easier to encrypt on a channel basis as the > same > >>> end-point credentials are used to derive keying information which > can > >>> encrypt and integrity protect simultaneously, > >> Using object-level security does not change that. > > Perhaps I misunderstood what you meant by object-level security. The > way you described it seemed to suggest that elements of data transacted > within the channel could be individually encrypted. My questions > surround what security material is used to perform the encryption in > each case. > >>> e.g. most efficiently > >>> using an AEAD cipher like AES-CCM or AES-GCM. If you start to make > the > >>> encryption more granular, what do you then use as the cryptographic > >>> basis for secrecy between the transacting objects? Asymmetric or > >>> symmetric? > >> Symmetric. > >> > >>> Would you use the same granularity as the channel end > >>> points? > >>> Or be more granular? > >> Not sure I understand. Can you elaborate? > > As above - what security material would you use to encrypt? The same > security material as is used for channel encryption? Or something more > granular, i.e. would each distinct element of encrypted data have its > own security material? What is the distinction? If communicating > objects multiplex their transactions on a single channel, this could be > the case. > >>> All I'm saying is there is probably more to this than meets the > eye. > >> Let's find out. > >> > >> Alper > >> > >> > >> > >> > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 From alper.yegin@yegin.org Fri Jun 10 01:46:18 2011 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 8305A21F8486 for ; Fri, 10 Jun 2011 01:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhCle9qTCsVC for ; Fri, 10 Jun 2011 01:46:18 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id DB68F21F8480 for ; Fri, 10 Jun 2011 01:46:17 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MRF4x-1Q85xE3F9T-00ToaH; Fri, 10 Jun 2011 04:46:00 -0400 From: "Alper Yegin" To: , "'Zach Shelby'" References: <239072CD-ACC0-454D-8BD6-30AC28D425D9@cisco.com> <720981EA-6411-4A5C-AC8C-675ADA1A2DE5@cisco.com> <8BCD950E-FB93-40EE-848C-466E5152DA7C@cisco.com> <223489D8-F2DC-45D1-A690-13480534C1B2@cisco.com> <-3335568933846752161@unknownmsgid> <005101cc10d5$9697a1e0$c3c6e5a0$@yegin@yegin.org> <4DCC45D3.2020304@gridmerge.com> <00bb01cc110e$8e3cb7e0$aab627a0$@yegin@yegin.org> <4DCCF405.2050500@gridmerge.com> <7B94A27A-A5BE-42C0-9876-9CD44D7666EA@sensinode.com> <4DCD3ECE.2070906@gridmerge.com> In-Reply-To: <4DCD3ECE.2070906@gridmerge.com> Date: Fri, 10 Jun 2011 11:45:52 +0300 Message-ID: <013401cc274a$d1f77360$75e65a20$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwReUOd+dRHin4dTzaVSjNZvTcedQV0KkfQ Content-Language: en-us X-Provags-ID: V02:K0:xmdP+BIrFQAvhYllvwZQRHzumt8+uhoH4dF+bXhWDHD C8aOWoNR8tQ+4MLkDNevGhCnBUUI4tHOMk+3l1oX+P+PZgRbNP CA0rcwif8XydqO4i+0e5OvSVT0lAIvO/k35mComz5B9J+HYnlL yGuJBRhbqDLQ/XHn8UBTZKFCMzVWSvrmPnQTINi+B1pgJwtDgt Nmz7jKhxpLmZ0HvdXA0hfJ931J3jQxvmIuwSIGT7wc= Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-06 Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 08:46:18 -0000 Robert, > I wouldn't say totally orthogonal - this spun off from a discussion as > to whether DTLS was indeed the right choice for security and whether we > could define a CoAP security (for example, like RPL did). However, my > view is that DTLS is the right choice. For all kinds of deployments? I don't think so. Apparently the current spec does not think so either. There is already IPsec in it. I don't think we need to find a "right" choice in IETF anyways. As far as IETF is concerned, at least one choice has to be there (because we cannot ship such a protocol without a security mechanism) -- and that's DTLS. Since the final choice is for the system developers, architecture designers, and the deployments, they'll deal with it. They already have nosec and IPsec. Alper > > Robert > > On 13/05/2011 3:10 PM, Zach Shelby wrote: > > This object security discussion is totally orthogonal to the DTLS > security that is default in CoAP (so this really isn't relevant to > core-coap-06). Object security is definitely interesting in this > domain, and for example the JSON signing BOF in Prague was relevant to > this. I would encourage Alper to write a draft about how to do simple > object security for CoAP. Robert is right that the security model in > the CoRE context should be an important part of that, as well as > bootstrapping considerations. > > > > Zach > > > > On May 13, 2011, at 12:04 PM, Robert Cragie wrote: > > > >> > >> On 13/05/2011 2:39 AM, Alper Yegin wrote: > >>>>> I'm not singling out TLS here. I think this is a fundamental > >>>>> distinction between channel security vs object-level security. > >>>> It seems fundamentally easier to encrypt on a channel basis as the > same > >>>> end-point credentials are used to derive keying information which > can > >>>> encrypt and integrity protect simultaneously, > >>> Using object-level security does not change that. > >> Perhaps I misunderstood what you meant by object-level security. The > way you described it seemed to suggest that elements of data transacted > within the channel could be individually encrypted. My questions > surround what security material is used to perform the encryption in > each case. > >>>> e.g. most efficiently > >>>> using an AEAD cipher like AES-CCM or AES-GCM. If you start to make > the > >>>> encryption more granular, what do you then use as the > cryptographic > >>>> basis for secrecy between the transacting objects? Asymmetric or > >>>> symmetric? > >>> Symmetric. > >>> > >>>> Would you use the same granularity as the channel end > >>>> points? > >>>> Or be more granular? > >>> Not sure I understand. Can you elaborate? > >> As above - what security material would you use to encrypt? The same > security material as is used for channel encryption? Or something more > granular, i.e. would each distinct element of encrypted data have its > own security material? What is the distinction? If communicating > objects multiplex their transactions on a single channel, this could be > the case. > >>>> All I'm saying is there is probably more to this than meets the > eye. > >>> Let's find out. > >>> > >>> Alper > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core From bergmann@tzi.org Mon Jun 13 10:42:15 2011 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 D706D11E80EF for ; Mon, 13 Jun 2011 10:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgpYULblTijr for ; Mon, 13 Jun 2011 10:42:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AC33611E80EC for ; Mon, 13 Jun 2011 10:42:14 -0700 (PDT) Received: from aung.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p5DHg6XC009920; Mon, 13 Jun 2011 19:42:11 +0200 (CEST) From: Olaf Bergmann To: Shoichi Sakane Date: Mon, 13 Jun 2011 19:41:23 +0200 Message-ID: <87d3ih4oia.fsf@aung.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: core@ietf.org Subject: [core] Support for coap-06 in wireshark CoAP dissector X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 17:42:16 -0000 Hi, while debugging some CoAP stuff, I felt it convenient to have a wireshark dissector for the latest draft version coap-06. (Yet only the core protocol, block + observe are not yet in sync with the current draft versions.) You can find a patch for packet-coap.c against revision 37662 (i.e. current as of today) under the following address: I did not test it a lot as the changes are straight forward. I hope it is useful anyway. Gruesse, Olaf From internet-drafts@ietf.org Wed Jun 15 03:47:54 2011 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 804AA11E80B1; Wed, 15 Jun 2011 03:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twr+VCbEDDro; Wed, 15 Jun 2011 03:47:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203FC11E8091; Wed, 15 Jun 2011 03:47:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110615104754.10825.26344.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 03:47:54 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-link-format-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 10:47:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Work= ing Group of the IETF. Title : CoRE Link Format Author(s) : Zach Shelby Filename : draft-ietf-core-link-format-06.txt Pages : 20 Date : 2011-06-15 This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-06.txt From zach@sensinode.com Wed Jun 15 03:54:49 2011 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 47EBD11E8087; Wed, 15 Jun 2011 03:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qME8pxt8FRwu; Wed, 15 Jun 2011 03:54:48 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id D7EBF11E8074; Wed, 15 Jun 2011 03:54:47 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5FAsgwm016759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jun 2011 13:54:43 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-482--884397353; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <20110615104754.10825.26344.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 13:54:44 +0300 Message-Id: References: <20110615104754.10825.26344.idtracker@ietfa.amsl.com> To: Internet-Drafts@ietf.org X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, i-d-announce@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-link-format-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 10:54:49 -0000 --Apple-Mail-482--884397353 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This new version of link-format takes care of the UTF-8 text that we = have been polishing for quite some time, and fixed a small example = error.=20 The new UTF-8 related text reads: "Whereas the HTTP Link Header format depends on [RFC2616] for its = encoding, the CoRE Link Format is encoded as UTF-8 [RFC3629]. A decoder = of the format is not expected to (but not prohibited from) validate = UTF-8 encoding and doesn't need to perform any UTF-8 normalization. = UTF-8 data can be compared bit-wise, which allows values to contain = UTF-8 data without any added complexity for constrained nodes." Zach=20 On Jun 15, 2011, at 1:47 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 Working Group of the IETF. >=20 > Title : CoRE Link Format > Author(s) : Zach Shelby > Filename : draft-ietf-core-link-format-06.txt > Pages : 20 > Date : 2011-06-15 >=20 > This document defines Web Linking using a link format for use by > constrained web servers to describe hosted resources, their > attributes and other relationships between links. Based on the HTTP > Link Header format defined in RFC5988, the CoRE Link Format is > carried as a payload and is assigned an Internet media type. A = well- > known URI is defined as a default entry-point for requesting the > links hosted by a server. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-06.txt > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-482--884397353 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYxNTEwNTQ0 NFowIwYJKoZIhvcNAQkEMRYEFLMWa7ozWcuPek9Q7nM6mX3NfGO1MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADIk/qfP9dmeV5NEhWs16uAbFsj9DuId/EyysW3pGpB1FvjPFBnGBA9C KKQ5twDgy7Y0KW1xsKta4UOvB+gwuCaUDhPF8n8Gbygx0+gMksfqADiCf6JSndnOI9VIQmunABrR hLZ0+xKEv1KumufsR2k9HL1g08+QlKMZsEkkP6omXVjEUr9CRGnXiTa76k1z1LaifaIcVXG58KNE ZsmjqPWgkzR4gHXIGCJ22ptxyXjGN2qF+EgOFz/lTySODF4gYgOUpPsQabQHbTXjtd/kXDOVldnJ 4Q7lzPcyC0K0vnp2udbEfTiXmI2E2aRaFJdJtec7FLHkoTxtcYoGJ0bcDQUAAAAAAAA= --Apple-Mail-482--884397353-- From trac+core@trac.tools.ietf.org Wed Jun 15 11:53:16 2011 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 1C13321F856E for ; Wed, 15 Jun 2011 11:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB0XkqGmgWW4 for ; Wed, 15 Jun 2011 11:53:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 79AD121F856D for ; Wed, 15 Jun 2011 11:53:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QWvDG-0005RP-EU; Wed, 15 Jun 2011 11:53:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Wed, 15 Jun 2011 18:53:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/162 Message-ID: <057.2f42a753a9f270a64e975d49c7a5c4cd@trac.tools.ietf.org> X-Trac-Ticket-ID: 162 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #162: Add application/link-format to code registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org 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 Jun 2011 18:53:16 -0000 #162: Add application/link-format to code registry This ticket is to add a Media type code registry entry back for application/link-format (ct=40) into the base CoAP specification. As link- format has already been through WGLC it is safe to just include it into the base CoAP spec. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: new Priority: trivial | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From brian.tridium@gmail.com Thu Jun 16 07:04:28 2011 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 C7BC311E80D7 for ; Thu, 16 Jun 2011 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAHgFDDcCBlw for ; Thu, 16 Jun 2011 07:04:28 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F039711E8084 for ; Thu, 16 Jun 2011 07:04:27 -0700 (PDT) Received: by bwz13 with SMTP id 13so1516567bwz.31 for ; Thu, 16 Jun 2011 07:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=IJN9SBpsN+hV0/E8ptZ77mFPx0k3NTynHEiDb+YcX4w=; b=DQtbiOXdaAyUCXoFw5tqBwctGD1M17c2IpjUdY6n7XASdpZx0F8I0SDoYZKEF75UHT ka7B2/t/A1p8ZzFGqylXq9LS8y5qmVkcEJBnVrGcTA7PHOZlPI2xo8VLmjSLhhp/Nonp ifCWD2kz6eQk7sjF0GRK4suvMLKcUyS4ODLkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MUL1Q3huNZby473ZEZTQejFso7PA5y2Ggf9slurrzUsrh4vyILpU3KF/6o0/swJjoA FWMNOPZDahEED5f+azmCO2/bszA+mTCFGlS1A0/fFokkpaLWfi7q94FpdezGO9eTKF1n zUmXOJlsL1IvpZ71QuhCZ86NwN6rVVq99vKNg= MIME-Version: 1.0 Received: by 10.204.152.5 with SMTP id e5mr670437bkw.138.1308233066734; Thu, 16 Jun 2011 07:04:26 -0700 (PDT) Received: by 10.205.82.134 with HTTP; Thu, 16 Jun 2011 07:04:26 -0700 (PDT) Date: Thu, 16 Jun 2011 10:04:26 -0400 Message-ID: From: Brian Frank To: core Content-Type: multipart/alternative; boundary=0015175df13039e43004a5d4bf37 Subject: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 14:04:28 -0000 --0015175df13039e43004a5d4bf37 Content-Type: text/plain; charset=ISO-8859-1 The way the current spec is written a client is free to pick random Message ID with each new request. I propose to restrict this to require that a client must serially increment the Message ID for each new request. On one hand, I don't see that allowing clients use randomized Message IDs provides any value. But on the other hand knowing that Message IDs increment in order allows many potential server-side optimizations: - today a server is required to allocate a buffer of X message IDs per client. Lets say we store the last 10 message IDs received using 20 bytes. In the same 20 bytes using a sliding window bitmask we could potentially store a window of up to 144 messages received. It may or not make sense dependent on the application, but seems nice to have that implementation option. - serial Message IDs make it easy to detect out-of-order messages (if the application level needs to know) So this seems like one of those cases where taking a away a bit of dubious client flexibility provides a lot more server flexibility. On a similar note, the spec requires that a client share the same MessageId variable with communication to all destination servers. Does that actually have to be a MUST level requirement? It seems like an implementation detail to me since we can also route responses using the tuple of (addr, port, message-id). --0015175df13039e43004a5d4bf37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The way the current spec is written a client is free to pick random Message= ID with each new request. =A0I propose to restrict this to require that a = client must serially increment the Message ID for each new request.=A0
=
On one hand, I don't see that allowing clients use randomize= d Message IDs provides any value. =A0But on the other hand knowing that Mes= sage IDs increment in order allows many potential server-side optimizations= :

- today a server is required to allocate a buffer of X = message IDs per client. =A0Lets say we store the last 10 message IDs receiv= ed using 20 bytes. =A0In the same 20 bytes using a sliding window bitmask w= e could potentially store a window of up to 144 messages received. =A0It ma= y or not make sense dependent on the application, but seems nice to have th= at implementation option.

- serial Message IDs make it easy to detect out-of-orde= r messages (if the application level needs to know)

So this seems like one of those cases where taking a away a bit of dubiou= s client flexibility provides a lot more server flexibility.

On a similar note, the spec requires that a client shar= e the same MessageId variable with communication to all destination servers= . =A0Does that actually have to be a MUST level requirement? =A0It seems li= ke an implementation detail to me since we can also route responses using t= he tuple of (addr, port, message-id).
--0015175df13039e43004a5d4bf37-- From prvs=3148edb218=fewilhoit@aep.com Thu Jun 16 07:15:49 2011 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 339FD11E8208; Thu, 16 Jun 2011 07:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpR50qHsV2Cp; Thu, 16 Jun 2011 07:15:48 -0700 (PDT) Received: from mail7.aep.com (mail7.aep.com [167.239.223.109]) by ietfa.amsl.com (Postfix) with ESMTP id 0017211E8206; Thu, 16 Jun 2011 07:15:47 -0700 (PDT) Received: from pps.filterd (mail7 [127.0.0.1]) by mail7 (8.14.3/8.14.3) with SMTP id p5GEEkRw009409; Thu, 16 Jun 2011 10:15:46 -0400 Received: from dsml1dev.aepsc.com ([10.97.175.251]) by mail7.aepsc.com with ESMTP id wyk3k871u-1; Thu, 16 Jun 2011 10:15:45 -0400 In-Reply-To: References: To: Brian Frank MIME-Version: 1.0 X-KeepSent: 2E2C52E0:C228D1F6-852578B1:004D9D33; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: fewilhoit@aep.com Message-ID: Date: Thu, 16 Jun 2011 10:15:42 -0400 X-MIMETrack: Serialize by Router on DSML1DEV/SERVERS/AEPIN(Release 8.5.1FP4|July 25, 2010) at 06/16/2011 10:15:45, Serialize complete at 06/16/2011 10:15:45 Content-Type: multipart/alternative; boundary="=_alternative 004E587E852578B1_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-06-16_03:2011-06-15, 2011-06-16, 1970-01-01 signatures=0 Cc: core-bounces@ietf.org, core Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 14:15:49 -0000 This is a multipart message in MIME format. --=_alternative 004E587E852578B1_= Content-Type: text/plain; charset="US-ASCII" Brian, Good catch and I concur with both of your recommendations. CoAP is (among other things) an alternative to TCP at OSI Layer 4 . From that standpoint, monotonically increasing message IDs per connection are a significant optimization. In a disconnected pattern, the Message ID is merely a correlator; and in a highly congested environment, randomizing per client actually makes message ID collision more likely. (I continue to feel that 16 bits are not enough.) Thanks Frank Wilhoit Enterprise Information Architect Enterprise Architecture and Strategy American Electric Power Direct Dial 614.716.3878 Audinet 8.200.3878 Scraping the bottom of a different barrel, since 1958. From: Brian Frank To: core Date: 06/16/2011 10:04 AM Subject: [core] Message ID sliding window Sent by: core-bounces@ietf.org The way the current spec is written a client is free to pick random Message ID with each new request. I propose to restrict this to require that a client must serially increment the Message ID for each new request. On one hand, I don't see that allowing clients use randomized Message IDs provides any value. But on the other hand knowing that Message IDs increment in order allows many potential server-side optimizations: - today a server is required to allocate a buffer of X message IDs per client. Lets say we store the last 10 message IDs received using 20 bytes. In the same 20 bytes using a sliding window bitmask we could potentially store a window of up to 144 messages received. It may or not make sense dependent on the application, but seems nice to have that implementation option. - serial Message IDs make it easy to detect out-of-order messages (if the application level needs to know) So this seems like one of those cases where taking a away a bit of dubious client flexibility provides a lot more server flexibility. On a similar note, the spec requires that a client share the same MessageId variable with communication to all destination servers. Does that actually have to be a MUST level requirement? It seems like an implementation detail to me since we can also route responses using the tuple of (addr, port, message-id). _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --=_alternative 004E587E852578B1_= Content-Type: text/html; charset="US-ASCII" Brian,

Good catch and I concur with both of your recommendations.  CoAP is (among other things) an alternative to TCP at OSI Layer 4 .  From that standpoint, monotonically increasing message IDs per connection are a significant optimization.  In a disconnected pattern, the Message ID is merely a correlator; and in a highly congested environment, randomizing per client actually makes message ID collision more likely.  (I continue to feel that 16 bits are not enough.)

Thanks

Frank Wilhoit
Enterprise Information Architect
Enterprise Architecture and Strategy
American Electric Power
Direct Dial 614.716.3878
Audinet 8.200.3878

Scraping the bottom of a different barrel, since 1958.



From:        Brian Frank <brian.tridium@gmail.com>
To:        core <core@ietf.org>
Date:        06/16/2011 10:04 AM
Subject:        [core] Message ID sliding window
Sent by:        core-bounces@ietf.org



The way the current spec is written a client is free to pick random Message ID with each new request.  I propose to restrict this to require that a client must serially increment the Message ID for each new request. 

On one hand, I don't see that allowing clients use randomized Message IDs provides any value.  But on the other hand knowing that Message IDs increment in order allows many potential server-side optimizations:

- today a server is required to allocate a buffer of X message IDs per client.  Lets say we store the last 10 message IDs received using 20 bytes.  In the same 20 bytes using a sliding window bitmask we could potentially store a window of up to 144 messages received.  It may or not make sense dependent on the application, but seems nice to have that implementation option.

- serial Message IDs make it easy to detect out-of-order messages (if the application level needs to know)

So this seems like one of those cases where taking a away a bit of dubious client flexibility provides a lot more server flexibility.

On a similar note, the spec requires that a client share the same MessageId variable with communication to all destination servers.  Does that actually have to be a MUST level requirement?  It seems like an implementation detail to me since we can also route responses using the tuple of (addr, port, message-id)._______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--=_alternative 004E587E852578B1_=-- From cabo@tzi.org Thu Jun 16 14:36:40 2011 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 9332411E8159 for ; Thu, 16 Jun 2011 14:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od5W7oxN-opM for ; Thu, 16 Jun 2011 14:36:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1A211E80F9 for ; Thu, 16 Jun 2011 14:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p5GLaT9s016914; Thu, 16 Jun 2011 23:36:29 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6094.dip.t-dialin.net [91.62.96.148]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 74A86770; Thu, 16 Jun 2011 23:36:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 16 Jun 2011 20:07:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Frank X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 21:36:40 -0000 Brian, You lost me. > - today a server is required to allocate a buffer of X message IDs per = client. =20 Why/what for? Most servers are completely stateless, they don't need to allocate = anything. Where they do need to (non-idempotent methods like POST), they also = usually need to store responses, so there is little savings in just = being able to compress message-IDs. Can you explain the usage scenario some more where this would make a = difference? > - serial Message IDs make it easy to detect out-of-order messages (if = the application level needs to know) Danger, Will Robinson. Are you suggesting that we start giving = application semantics to message-IDs? That would be serious conflation. (Yes, we do have an out-of-order detection problem, which is addressed = in -observe. If there were a way to simplify this with message IDs, that might be = interesting -- but I think the current way is already rather simple as = it is.) Gruesse, Carsten From prvs=3148edb218=fewilhoit@aep.com Thu Jun 16 14:55:08 2011 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 74BF211E814E; Thu, 16 Jun 2011 14:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtEwH4fXyCOL; Thu, 16 Jun 2011 14:55:07 -0700 (PDT) Received: from mail5.aep.com (mail5.aep.com [167.239.223.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7370E11E8140; Thu, 16 Jun 2011 14:55:07 -0700 (PDT) Received: from pps.filterd (mail5 [127.0.0.1]) by mail5 (8.14.3/8.14.3) with SMTP id p5GLt3B0005859; Thu, 16 Jun 2011 17:55:05 -0400 Received: from dsml1dev.aepsc.com ([10.97.175.57]) by mail5.aepsc.com with ESMTP id wysrn072f-1; Thu, 16 Jun 2011 17:55:05 -0400 In-Reply-To: References: To: Carsten Bormann MIME-Version: 1.0 X-KeepSent: 169AEAF8:E8EA223E-852578B1:007724D0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: fewilhoit@aep.com Message-ID: Date: Thu, 16 Jun 2011 17:55:03 -0400 X-MIMETrack: Serialize by Router on DSML1DEV/SERVERS/AEPIN(Release 8.5.1FP4|July 25, 2010) at 06/16/2011 17:55:04, Serialize complete at 06/16/2011 17:55:04 Content-Type: multipart/alternative; boundary="=_alternative 0078658A852578B1_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-06-16_10:2011-06-16, 2011-06-16, 1970-01-01 signatures=0 Cc: core-bounces@ietf.org, core Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 21:55:08 -0000 This is a multipart message in MIME format. --=_alternative 0078658A852578B1_= Content-Type: text/plain; charset="US-ASCII" Carsten, Sequential message IDs are not an application semantic. They are a Layer 4 semantic. It appears to me that doing Layer 4 with random message IDs would require the maintenance of more state, viz. a lookup table of message IDs that have not yet been ACKed or timed out. Again, to Brian's point, clients do not gain anything from the privilege of randomizing message IDs . When I read the spec, I silently assumed that message IDs would be sequential and per-connection. Out-of-order messages and dropped messages are going to be a constant problem on RF mesh networks. It is a fine idea to supplant TCP in a semi-connected environment, but you have to get to Layer 4 somehow. thx Frank Wilhoit Enterprise Information Architect Enterprise Architecture and Strategy American Electric Power Direct Dial 614.716.3878 Audinet 8.200.3878 Scraping the bottom of a different barrel, since 1958. From: Carsten Bormann To: Brian Frank Cc: core Date: 06/16/2011 05:36 PM Subject: Re: [core] Message ID sliding window Sent by: core-bounces@ietf.org Brian, You lost me. > - today a server is required to allocate a buffer of X message IDs per client. Why/what for? Most servers are completely stateless, they don't need to allocate anything. Where they do need to (non-idempotent methods like POST), they also usually need to store responses, so there is little savings in just being able to compress message-IDs. Can you explain the usage scenario some more where this would make a difference? > - serial Message IDs make it easy to detect out-of-order messages (if the application level needs to know) Danger, Will Robinson. Are you suggesting that we start giving application semantics to message-IDs? That would be serious conflation. (Yes, we do have an out-of-order detection problem, which is addressed in -observe. If there were a way to simplify this with message IDs, that might be interesting -- but I think the current way is already rather simple as it is.) Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --=_alternative 0078658A852578B1_= Content-Type: text/html; charset="US-ASCII" Carsten,

Sequential message IDs are not an application semantic.  They are a Layer 4 semantic.  It appears to me that doing Layer 4 with random message IDs would  require the maintenance of more state, viz. a lookup table of message IDs that have not yet been ACKed or timed out.  Again, to Brian's point, clients do not gain anything from the privilege of randomizing message IDs .  When I read the spec, I silently assumed that message IDs would be sequential and per-connection.

Out-of-order messages and dropped messages are going to be a constant problem on RF mesh networks.

It is a fine idea to supplant TCP in a semi-connected environment, but you have to get to Layer 4 somehow.

thx

Frank Wilhoit
Enterprise Information Architect
Enterprise Architecture and Strategy
American Electric Power
Direct Dial 614.716.3878
Audinet 8.200.3878

Scraping the bottom of a different barrel, since 1958.



From:        Carsten Bormann <cabo@tzi.org>
To:        Brian Frank <brian.tridium@gmail.com>
Cc:        core <core@ietf.org>
Date:        06/16/2011 05:36 PM
Subject:        Re: [core] Message ID sliding window
Sent by:        core-bounces@ietf.org



Brian,

You lost me.

> - today a server is required to allocate a buffer of X message IDs per client.  

Why/what for?
Most servers are completely stateless, they don't need to allocate anything.
Where they do need to (non-idempotent methods like POST), they also usually need to store responses, so there is little savings in just being able to compress message-IDs.

Can you explain the usage scenario some more where this would make a difference?

> - serial Message IDs make it easy to detect out-of-order messages (if the application level needs to know)

Danger, Will Robinson.  Are you suggesting that we start giving application semantics to message-IDs?
That would be serious conflation.

(Yes, we do have an out-of-order detection problem, which is addressed in -observe.
If there were a way to simplify this with message IDs, that might be interesting -- but I think the current way is already rather simple as it is.)

Gruesse, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--=_alternative 0078658A852578B1_=-- From angelo.castellani@gmail.com Fri Jun 17 03:16:51 2011 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 2F592228014; Fri, 17 Jun 2011 03:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1K1owpimuVA; Fri, 17 Jun 2011 03:16:50 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C70E22800E; Fri, 17 Jun 2011 03:16:50 -0700 (PDT) Received: by qwc23 with SMTP id 23so1721477qwc.31 for ; Fri, 17 Jun 2011 03:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=yCOxUhw/jWuX+RZqDMbn2y77kN+vzXnqNEOIcX/5zdc=; b=Xj56qoBVmIIM7KyLIwljI8P2klKYXBbThOt/lnllpwQYfq9m3xYLp7uIa1nNYdViEo K3YTVRXT50jdfTzEKmvHf9ll9GqYSSmz1FxPMAA2fzB905sX4qCqwtji0pviSuylaEZz ILhPYQnd9RSr/pOCZILEIPZ1HU1vhYrfjLY60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=rtmIJZ/UkG7/HzaiDmSWyTl2O7v3NEfH08IRxWISNRXshCGKx7YZufanduu23KC9/J ZvoOsaZzyvqQtSyP6DQNJAhRB77PwPmPf8LPXXIApFa6EAEo/b39B5Og6hsvja9gA4q2 sQqJD1FnxOSShP2dbTWpJp1GlpNNbplNtAMsQ= Received: by 10.229.127.104 with SMTP id f40mr1614146qcs.48.1308305809415; Fri, 17 Jun 2011 03:16:49 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.226.131 with HTTP; Fri, 17 Jun 2011 03:16:29 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Fri, 17 Jun 2011 12:16:29 +0200 X-Google-Sender-Auth: wCXmTw5eTmPGQUhzUeerWZ8Zg04 Message-ID: To: fewilhoit@aep.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core , core-bounces@ietf.org Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 10:16:51 -0000 Dear Brian F., Frank W., you may want to take a look at this draft where sequential message IDs are discussed: http://tools.ietf.org/html/draft-castellani-core-coap-overhead-01 ( and probably you want also to take a look at this one http://tools.ietf.org/html/draft-castellani-core-transport-00 ) However this discussion seems currently out-of-scope for CoAP, which as far as I know has already closed the "bigger"-part of the design of its message-layer using different assumptions/features. I am still working on something similar for different reasons.. Best, Angelo On Thu, Jun 16, 2011 at 23:55, wrote: > Carsten, > > Sequential message IDs are not an application semantic. =A0They are a Lay= er 4 > semantic. =A0It appears to me that doing Layer 4 with random message IDs = would > =A0require the maintenance of more state, viz. a lookup table of message = IDs > that have not yet been ACKed or timed out. =A0Again, to Brian's point, cl= ients > do not gain anything from the privilege of randomizing message IDs . =A0W= hen I > read the spec, I silently assumed that message IDs would be sequential an= d > per-connection. > > Out-of-order messages and dropped messages are going to be a constant > problem on RF mesh networks. > > It is a fine idea to supplant TCP in a semi-connected environment, but yo= u > have to get to Layer 4 somehow. > > thx > > Frank Wilhoit > Enterprise Information Architect > Enterprise Architecture and Strategy > American Electric Power > Direct Dial 614.716.3878 > Audinet 8.200.3878 > > Scraping the bottom of a different barrel, since 1958. > > > > > From: =A0 =A0 =A0 =A0Carsten Bormann > To: =A0 =A0 =A0 =A0Brian Frank > Cc: =A0 =A0 =A0 =A0core > Date: =A0 =A0 =A0 =A006/16/2011 05:36 PM > Subject: =A0 =A0 =A0 =A0Re: [core] Message ID sliding window > Sent by: =A0 =A0 =A0 =A0core-bounces@ietf.org > ________________________________ > > > Brian, > > You lost me. > >> - today a server is required to allocate a buffer of X message IDs per >> client. > > Why/what for? > Most servers are completely stateless, they don't need to allocate anythi= ng. > Where they do need to (non-idempotent methods like POST), they also usual= ly > need to store responses, so there is little savings in just being able to > compress message-IDs. > > Can you explain the usage scenario some more where this would make a > difference? > >> - serial Message IDs make it easy to detect out-of-order messages (if th= e >> application level needs to know) > > Danger, Will Robinson. =A0Are you suggesting that we start giving applica= tion > semantics to message-IDs? > That would be serious conflation. > > (Yes, we do have an out-of-order detection problem, which is addressed in > -observe. > If there were a way to simplify this with message IDs, that might be > interesting -- but I think the current way is already rather simple as it > is.) > > Gruesse, Carsten > > _______________________________________________ > 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 brian.tridium@gmail.com Fri Jun 17 16:31:00 2011 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 EBDE911E8081 for ; Fri, 17 Jun 2011 16:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXZZb2vn3M0s for ; Fri, 17 Jun 2011 16:31:00 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F66511E807F for ; Fri, 17 Jun 2011 16:30:59 -0700 (PDT) Received: by bwz13 with SMTP id 13so2872721bwz.31 for ; Fri, 17 Jun 2011 16:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UW0VKVsLN7E+YXIrTzvKnnEwIQdGvWhb3Q73VpO4zkg=; b=Ow6wbN8jrE/QHn+m8a+rgpFhZnkg6Y62uf84KPyriQBMQ33vxjBpuqLWAttKMQCQrJ VKoPU/jUj4ZAkmJIrQjEdO8ZQ2Xhd1OGw0a9ZSl1v4kkN0G1jLIgigqc1I9gd7ezcFN/ 2mRJPUZ2HwxvNB5pKjfgLl1ILyCfrCHst60eE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JdfNHZFq+cPnfLXy3gWWec+Q2TOR/JqHSqYlCfl7H5GwgDfpiv5ctMHVRJUoYDznIe 1y3kobga4ZiGN0Z33ctEamWO3lUD6F+XSzlcKogIfhNgeTLtVsjIkBnNwkEd5/hUyAV6 C4R81dcHfKZ6wer0Hg9Fh1ahISpjAEvG7PZr0= MIME-Version: 1.0 Received: by 10.204.38.5 with SMTP id z5mr2035969bkd.111.1308353458946; Fri, 17 Jun 2011 16:30:58 -0700 (PDT) Received: by 10.205.82.134 with HTTP; Fri, 17 Jun 2011 16:30:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jun 2011 19:30:58 -0400 Message-ID: From: Brian Frank To: Carsten Bormann Content-Type: multipart/alternative; boundary=bcaec553ffa429423404a5f0c798 Cc: core Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 23:31:01 -0000 --bcaec553ffa429423404a5f0c798 Content-Type: text/plain; charset=ISO-8859-1 > > Most servers are completely stateless, they don't need to allocate > anything. > Where they do need to (non-idempotent methods like POST), they also usually > need to store responses, so there is little savings in just being able to > compress message-IDs. > > Because often a non-idempotent POST request might not have a response payload or the payload can be reconstructed from application state, in which case the server only needs to keep track of whether it has seen the message or not. Let's rephrase the issue: What value is there in allowing a client to not use serial IDs? I can't think of any use-case where this flexibility provides any value, but maybe something was discussed? On the other hand, there seems like lots of different use cases where serially incrementing Message IDs might have value. The spec just doesn't seem to make a good engineering trade-off on this issue. --bcaec553ffa429423404a5f0c798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Most servers are= completely stateless, they don't need to allocate anything.
Where they do need to (non-idempotent methods like POST), they also usually= need to store responses, so there is little savings in just being able to = compress message-IDs.


Because often= a non-idempotent POST request might not have a response payload or the pay= load can be reconstructed from application state, in which case the server = only needs to keep track of whether it has seen the message or not.

Let's rephrase the issue:

= What value is there in allowing a client to not use serial IDs? =A0I can= 9;t think of any use-case where this=A0flexibility=A0provides any value, bu= t maybe something was discussed?

On the other hand, there seems like lots of different u= se cases where serially incrementing Message IDs might have value.=A0
=

The spec just doesn't seem to make a good engineeri= ng trade-off on this issue.

--bcaec553ffa429423404a5f0c798-- From cabo@tzi.org Fri Jun 17 23:39:31 2011 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 D99E911E8142 for ; Fri, 17 Jun 2011 23:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBRhDKdhhJL3 for ; Fri, 17 Jun 2011 23:39:31 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2B11E807C for ; Fri, 17 Jun 2011 23:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p5I6dIWt019753; Sat, 18 Jun 2011 08:39:18 +0200 (CEST) Received: from [192.168.217.101] (p5489BBD8.dip.t-dialin.net [84.137.187.216]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6E642B95; Sat, 18 Jun 2011 08:39:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sat, 18 Jun 2011 08:39:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97F89AFB-DB55-4BFA-B625-E372FCF0761A@tzi.org> References: To: Brian Frank X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2011 06:39:32 -0000 On Jun 18, 2011, at 01:30, Brian Frank wrote: > Most servers are completely stateless, they don't need to allocate = anything. > Where they do need to (non-idempotent methods like POST), they also = usually need to store responses, so there is little savings in just = being able to compress message-IDs. >=20 >=20 > Because often a non-idempotent POST request might not have a response = payload or the payload can be reconstructed from application state, in = which case the server only needs to keep track of whether it has seen = the message or not. So this is all about optimizing one very special case. (I'd still like to understand the use case, in specific terms. If the response options/payload indeed can be reconstructed from = application state, that might also provide any deduplication needed.) > Let's rephrase the issue: >=20 > What value is there in allowing a client to not use serial IDs? =20 First of all, what does this question mean? When is a message ID "serial"? What would a server do when a client does something slightly non-serial? (Messages do get lost or reordered.) What would a server do when a client's message IDs are all over the = place? Reject the request with "your message ID's aren't as close to each other = as I'd like"? What would a server do when a client reboots? How do you ensure the = server's state has timed out quickly enough for the rebooted client to = send messages again? This gets ugly very quickly. > I can't think of any use-case where this flexibility provides any = value, but maybe something was discussed? >=20 > On the other hand, there seems like lots of different use cases where = serially incrementing Message IDs might have value.=20 >=20 > The spec just doesn't seem to make a good engineering trade-off on = this issue. The spec does the right thing from a protocol design point of view: It = does not provide a constraint where none is needed. However, if you believe supporting this specific optimization is worth = it, we could RECOMMEND (i.e., mandate at the SHOULD level) to use = message-IDs that are close (in modulo arithmetic) to recently used = message-IDs. I'm not yet convinced of the use case. Gruesse, Carsten From fluffy@cisco.com Mon Jun 20 07:40:25 2011 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 1E0CC11E8155 for ; Mon, 20 Jun 2011 07:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMzWQFojz2E9 for ; Mon, 20 Jun 2011 07:40:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 642D811E80A4 for ; Mon, 20 Jun 2011 07:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2400; q=dns/txt; s=iport; t=1308580819; x=1309790419; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=C2XgXPf7SOb+KZEFupwqbpiaHBRbpqzyKtytKu29s/E=; b=IY413HsH2GJ1BVXt3tAzrEYq6gCGjRwhNfwe9YFd8zrvkFiGH5WbrU1z w4xmxMjrKRPTv5Wdbpjtx0wdBR73NLQ4dpQsGkX4HE+e99kq7fJhl1lkP nlc64/ueKUj3idzwTYx8+f3QB3AgrYadnvOhQvv98u5jS2qEfKRJcBlIN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAMda/02rRDoG/2dsb2JhbABTl1KPC3eIc6FNnV+GKgSHIIo+hGCLQA X-IronPort-AV: E=Sophos;i="4.65,394,1304294400"; d="scan'208";a="717352745" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2011 14:40:18 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5KEeHB3015825; Mon, 20 Jun 2011 14:40:17 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2287DCB@SZXEML506-MBS.china.huawei.com> Date: Mon, 20 Jun 2011 08:40:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <54D1E77F-8B2D-4746-AEB2-EE3A9A9DAD33@cisco.com> References: <9F80F0D3-E449-415F-B773-2EC553AAD802@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2287DCB@SZXEML506-MBS.china.huawei.com> To: Likepeng X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-bormann-coap-misc-08 - Payload-Length options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 14:40:25 -0000 ok, but just to check we have the right things in the base draft, if we = want to add this later, how does the later draft negotiate such that = both sides know it is supported? On May 10, 2011, at 7:10 PM, Likepeng wrote: > I agree that it is quite useful for some cases, but I prefer it to be = a separate draft.=20 >=20 > (1) Because it is not needed (or at least optional) if we use UDP as = transport, which is the major transport under consideration now. The = information will be redundant if we can get the information from the = Payload-Length Option and from the UDP layer. And it may cause problem = if they are inconsistent. >=20 > (2) I don't think it is good to pack more than one CoAP message into = one UDP payload. It will add the complexity and I can't see too much = benefit.=20 >=20 > (3) I remember it was in the base draft before, but it was removed for = some reasons. >=20 > FYI, this is the justification from the misc-08 for the = Payload-Length: > Not all transport mappings may provide an unambiguous length of the > CoAP message. For UDP, it may also be desirable to pack more than > one CoAP message into one UDP payload (aggregation); in that case, > for all but the last message there needs to be a way to delimit the > payload of that message. >=20 > Kind Regards > Kepeng > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Cullen Jennings > Sent: Tuesday, May 10, 2011 10:13 PM > To: core WG > Subject: [core] draft-bormann-coap-misc-08 - Payload-Length options >=20 > I'd like to propose that we take the text from section 6 of this draft = defining an option to use Payload-Length options and move it to CoAP. = The main reasons I think it needs to be in the base draft is it is hard = to add later and easy to implement. Having this makes it much easier for = us to be future proof for use on non datagram transports or have = aggregation of multiple CoAP messages into a single IP datagram.=20 >=20 > It also makes it easy to figure out to use CoAP in a situation where = you have a serial line between the host and proxy that is IP connected.=20= >=20 > Cullen >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Mon Jun 20 08:58:29 2011 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 AF57D9E8029 for ; Mon, 20 Jun 2011 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAB2Xv+pGWIz for ; Mon, 20 Jun 2011 08:58:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC0F9E800D for ; Mon, 20 Jun 2011 08:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p5KFw3ZQ022147; Mon, 20 Jun 2011 17:58:03 +0200 (CEST) Received: from [192.168.217.112] (p5489BE09.dip.t-dialin.net [84.137.190.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D904B1EC; Mon, 20 Jun 2011 17:58:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <54D1E77F-8B2D-4746-AEB2-EE3A9A9DAD33@cisco.com> Date: Mon, 20 Jun 2011 17:58:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F2042D8-134B-4DAA-AEDB-9AC896283AF6@tzi.org> References: <9F80F0D3-E449-415F-B773-2EC553AAD802@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2287DCB@SZXEML506-MBS.china.huawei.com> <54D1E77F-8B2D-4746-AEB2-EE3A9A9DAD33@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-bormann-coap-misc-08 - Payload-Length options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 15:58:29 -0000 On Jun 20, 2011, at 16:40, Cullen Jennings wrote: > if we want to add this later, how does the later draft negotiate such = that both sides know it is supported? If we add this now, how does the client know the server supports it? Right now, we have no option at all that is actually mandatory (although = payloads don't make much sense without the content-type option). (I'm all for putting Payload-Length in, but the extensibility story may = not be the right reason.) Gruesse, Carsten From likepeng@huawei.com Mon Jun 20 19:10:20 2011 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 CE25911E80DB for ; Mon, 20 Jun 2011 19:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlJT6SlfiVQm for ; Mon, 20 Jun 2011 19:10:20 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 28ABC11E8071 for ; Mon, 20 Jun 2011 19:10:20 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN400150BBTRO@szxga03-in.huawei.com> for core@ietf.org; Tue, 21 Jun 2011 10:09:29 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN400G44BBTX4@szxga03-in.huawei.com> for core@ietf.org; Tue, 21 Jun 2011 10:09:29 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABB76425; Tue, 21 Jun 2011 10:09:29 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 21 Jun 2011 10:02:20 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.112]) by szxeml407-hub.china.huawei.com ([169.254.34.53]) with mapi id 14.01.0270.001; Tue, 21 Jun 2011 10:02:23 +0800 Date: Tue, 21 Jun 2011 02:02:23 +0000 From: Likepeng In-reply-to: <8F2042D8-134B-4DAA-AEDB-9AC896283AF6@tzi.org> X-Originating-IP: [10.70.109.110] To: Carsten Bormann , Cullen Jennings Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F22B6C40@szxeml506-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [core] draft-bormann-coap-misc-08 - Payload-Length options Thread-index: AQHMDxyGAgtW72J5gUi9AwGHGxkb1ZSGzM1AgD8+zgCAABW6AIABKidQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9F80F0D3-E449-415F-B773-2EC553AAD802@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2287DCB@SZXEML506-MBS.china.huawei.com> <54D1E77F-8B2D-4746-AEB2-EE3A9A9DAD33@cisco.com> <8F2042D8-134B-4DAA-AEDB-9AC896283AF6@tzi.org> Cc: core WG Subject: Re: [core] draft-bormann-coap-misc-08 - Payload-Length options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 02:10:21 -0000 > How does the client know the server supports it? Some time ago, I proposed to add one option, to indicate the supported options. Before sending the request, the client can check what options the server can support. The current situation is, the client sends request with the Payload-Length option (or the other elective options), if the server does not support it, it just ignores it. The client will have no idea if that option makes effect or not. The next time, the client will send the option again. If the option is critical, it is fine. The server will reject the message with a 4.02 (bad option) response or a reset message. For the non-confirmable request, the server will also ignore the option, which is similar to elective option. Does the group think that the proposed solution adds value for the client? Kind Regards Kepeng -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Monday, June 20, 2011 11:58 PM To: Cullen Jennings Cc: Likepeng; core WG Subject: Re: [core] draft-bormann-coap-misc-08 - Payload-Length options On Jun 20, 2011, at 16:40, Cullen Jennings wrote: > if we want to add this later, how does the later draft negotiate such that both sides know it is supported? If we add this now, how does the client know the server supports it? Right now, we have no option at all that is actually mandatory (although payloads don't make much sense without the content-type option). (I'm all for putting Payload-Length in, but the extensibility story may not be the right reason.) Gruesse, Carsten From brian.tridium@gmail.com Tue Jun 21 05:08:30 2011 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 DE20E21F84DC for ; Tue, 21 Jun 2011 05:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWXxKtJMbIxv for ; Tue, 21 Jun 2011 05:08:30 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1E9C21F84DA for ; Tue, 21 Jun 2011 05:08:29 -0700 (PDT) Received: by bwz13 with SMTP id 13so5169755bwz.31 for ; Tue, 21 Jun 2011 05:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9DyP3QCGUYynYhfJanAjxq0T97PX/OHQlZZEEucWbF0=; b=kV5EHYz9Gqn94bSCKmlm3oEoG5gjvUG8Cwlg1WJ/twRt4XZ/ydkegn74BDvLUgSzHf d+rJq7to98C7YJ+d6wG2lMIbygxUqnEOGpkHHQBomn8MxE5+wSPckIExlpcan/LcONSu IiJhZnMoEHcshiRDcvw17bK1g30H7UxRET5bM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HOIjTXkHUHLrSnuWC8MRF4Ttpwr3i7j08iLR+vxeY/dIQAi7t7X47/LUgHVBqjyq/w L6CmYOA+TksMFZpdYW/ISk2JR6nakkIuCqa48gp2W5dyQW/JluP8DQ0XmcajIg/BQ+ij cKZi6yACgXo0L5TSOmICuk2+EKpFlU8jVxYuo= MIME-Version: 1.0 Received: by 10.204.152.5 with SMTP id e5mr1188980bkw.138.1308658108719; Tue, 21 Jun 2011 05:08:28 -0700 (PDT) Received: by 10.205.82.134 with HTTP; Tue, 21 Jun 2011 05:08:28 -0700 (PDT) In-Reply-To: <97F89AFB-DB55-4BFA-B625-E372FCF0761A@tzi.org> References: <97F89AFB-DB55-4BFA-B625-E372FCF0761A@tzi.org> Date: Tue, 21 Jun 2011 08:08:28 -0400 Message-ID: From: Brian Frank To: Carsten Bormann Content-Type: multipart/alternative; boundary=0015175df130b3e38d04a637b596 Cc: core Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 12:08:31 -0000 --0015175df130b3e38d04a637b596 Content-Type: text/plain; charset=ISO-8859-1 This seems like a fairly simple question to me: which is the better engineering tradeoff: to force IDs to be allocated in order, or allow them to be generated randomly. If there are ordered: - can use a sliding window to keep track of messages received more compactly - can detect out of order messages - can more easily detect duplicate messages - safest course for clients to ensure maximum time before ID is recycled If there are not ordered: - no value On Sat, Jun 18, 2011 at 2:39 AM, Carsten Bormann wrote: > On Jun 18, 2011, at 01:30, Brian Frank wrote: > > > Most servers are completely stateless, they don't need to allocate > anything. > > Where they do need to (non-idempotent methods like POST), they also > usually need to store responses, so there is little savings in just being > able to compress message-IDs. > > > > > > Because often a non-idempotent POST request might not have a response > payload or the payload can be reconstructed from application state, in which > case the server only needs to keep track of whether it has seen the message > or not. > > So this is all about optimizing one very special case. > > (I'd still like to understand the use case, in specific terms. > If the response options/payload indeed can be reconstructed from > application state, that might also provide any deduplication needed.) > > > Let's rephrase the issue: > > > > What value is there in allowing a client to not use serial IDs? > > First of all, what does this question mean? > When is a message ID "serial"? > What would a server do when a client does something slightly non-serial? > (Messages do get lost or reordered.) > What would a server do when a client's message IDs are all over the place? > Reject the request with "your message ID's aren't as close to each other as > I'd like"? > What would a server do when a client reboots? How do you ensure the > server's state has timed out quickly enough for the rebooted client to send > messages again? > This gets ugly very quickly. > > > I can't think of any use-case where this flexibility provides any value, > but maybe something was discussed? > > > > On the other hand, there seems like lots of different use cases where > serially incrementing Message IDs might have value. > > > > The spec just doesn't seem to make a good engineering trade-off on this > issue. > > The spec does the right thing from a protocol design point of view: It does > not provide a constraint where none is needed. > > However, if you believe supporting this specific optimization is worth it, > we could RECOMMEND (i.e., mandate at the SHOULD level) to use message-IDs > that are close (in modulo arithmetic) to recently used message-IDs. > > I'm not yet convinced of the use case. > > Gruesse, Carsten > > --0015175df130b3e38d04a637b596 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems like a fairly simple question to me: which is the better enginee= ring tradeoff: to force IDs to be allocated in order, or allow them to be g= enerated randomly.

If there are ordered:
=A0 -= can use a sliding window to keep track of messages received more compactly=
=A0 - can detect out of order messages
=A0 - can more easily= detect duplicate messages
=A0 - safest course for clients to ens= ure maximum time before ID is recycled

If there ar= e not ordered:
=A0 - no value


On Sat, Jun 18, 2011 at 2:39 AM, Carsten Bormann <cabo@tzi.org> wrote:
On Jun 18, 2011, at 01:30, Brian Frank wrote:

> Most servers are completely stateless, they don't need to allocate= anything.
> Where they do need to (non-idempotent methods like POST), they also us= ually need to store responses, so there is little savings in just being abl= e to compress message-IDs.
>
>
> Because often a non-idempotent POST request might not have a response = payload or the payload can be reconstructed from application state, in whic= h case the server only needs to keep track of whether it has seen the messa= ge or not.

So this is all about optimizing one very special case.

(I'd still like to understand the use case, in specific terms.
If the response options/payload indeed can be reconstructed from applicatio= n state, that might also provide any deduplication needed.)

> Let's rephrase the issue:
>
> What value is there in allowing a client to not use serial IDs?

First of all, what does this question mean?
When is a message ID "serial"?
What would a server do when a client does something slightly non-serial? (Messages do get lost or reordered.)
What would a server do when a client's message IDs are all over the pla= ce?
Reject the request with "your message ID's aren't as close to = each other as I'd like"?
What would a server do when a client reboots? =A0How do you ensure the serv= er's state has timed out quickly enough for the rebooted client to send= messages again?
This gets ugly very quickly.

> I can't think of any use-case where this flexibility provides any = value, but maybe something was discussed?
>
> On the other hand, there seems like lots of different use cases where = serially incrementing Message IDs might have value.
>
> The spec just doesn't seem to make a good engineering trade-off on= this issue.

The spec does the right thing from a protocol design point of view: I= t does not provide a constraint where none is needed.

However, if you believe supporting this specific optimization is worth it, = we could RECOMMEND (i.e., mandate at the SHOULD level) to use message-IDs t= hat are close (in modulo arithmetic) to recently used message-IDs.

I'm not yet convinced of the use case.

Gruesse, Carsten


--0015175df130b3e38d04a637b596-- From zach@sensinode.com Thu Jun 23 06:07:37 2011 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 A253111E80D0 for ; Thu, 23 Jun 2011 06:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGAHzibYWPD4 for ; Thu, 23 Jun 2011 06:07:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDAB11E80A5 for ; Thu, 23 Jun 2011 06:07:33 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5ND7S2G009925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 23 Jun 2011 16:07:28 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-105--185231453; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 23 Jun 2011 16:07:30 +0300 Message-Id: <168A9ADF-1DE1-4F42-8206-FDBE95A64978@sensinode.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Content-type negotiation proposal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 13:07:37 -0000 --Apple-Mail-105--185231453 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Several times the WG has discussed the addition of content-type = negotiation support. Carsten has written up a proposal for how this can = be achieved in Section 2 of [draft-bormann-coap-misc-08].=20 Recently two SDOs have been designing the use of CoAP bindings, in = ZigBee SE2 and in ETSI M2M. In both of those SDOs we have run across the = need to indicate simple content-type preference in a GET request. = Because both SDOs also have an HTTP binding, they have assumed the = availability of negotiation. Attempts to solve the problem in other ways = has been awkward. I think we'll see the same trend in other M2M designs = that also support HTTP.=20 Therefore I propose a ticket to add content-type preference indication = to coap-07. In particular, the proposal is to add a new Elective option = called "Accept". Here is text lifted from coap-misc-08: "The CoAP Accept option would when included one or more times in a request, carry one or more media types, each of which is an acceptable media type for the client, in the order of preference. If no Accept option is given, the client does not express a preference. The client prefers the representation = returned by the server to be in one of the media types, but is willing to accept the response also if the server returns a representation in a different media type." One minor side effect of this change, is that the ct=3D attribute of = core-link-format would need to be allowed multiple times. This attribute = definition should anyways be moved from core-link-format and placed in = core-coap as it is CoAP specific.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-105--185231453 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYyMzEzMDcz MFowIwYJKoZIhvcNAQkEMRYEFDuWCH4xZsh4JDsaNhZCZRVwup52MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAIjDYZCoXbw8anZPxKkiEioS4R9+dUGLS+1LuyIpXiButLAuDM1XNHQ+ 6vd0aMwTVEQso/aBVe7eZXqWFTqLgRGvRr6lZ4FTmIRTbv4Rv6aIjf2Y2bpnUz9FUFYdYpB6Ns6t LABiI/Bb+ZVBWAZ7HhQvMYRsA4ab/VI//fBuLEi7inlLTLEDLQPcLw6DQmKGyOXfUVAObvb9BB3y TD51fwPz+gNTWm0/dSZLML/ro84ELFCjDhcO+1V71ldQrEpJLgqo/mI2Q0FNlm5swmKQR6h5zzWJ WIk0sNkWRtqTZmBHGbMbf8Dx90LUJ9CsJE1v74Cpxw9hjcdk20DxRWiNCXEAAAAAAAA= --Apple-Mail-105--185231453-- From brian.tridium@gmail.com Fri Jun 24 05:14:44 2011 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 874749E8007 for ; Fri, 24 Jun 2011 05:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDLUyfHaCHY0 for ; Fri, 24 Jun 2011 05:14:40 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B10469E8005 for ; Fri, 24 Jun 2011 05:14:39 -0700 (PDT) Received: by bwz13 with SMTP id 13so2592171bwz.31 for ; Fri, 24 Jun 2011 05:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s2WK7mgtdPhB7grUaNOXMGV3BThoQdDwKOGlJP/+j2U=; b=sb+nQXXp3BSHYVCTV8lFE/EPYFEFO+xX503KqMHbdNm35AsPNniW26K0rBpPtYqWVx CWKsphMfNZ5CQAuukmej6HWT8o5QxcmbTzuCwFQA0ZZ8bbpfrQ9ckd6ys/ewFMAB/dFn hjjRcdcWRCvdYKUITB9Pzz3WEkZAbXif3ojZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=E1sC7pQalulajGu3WZJCuj6NS2Iik3kpYt0x+T0KACpiZGHVxgrBjlY9eZfiqY9U8n 970cVR9KVCZqSP1YQlmLSMLPV2p7DpmBUuSwR/d5ZekUt4qQmjWQgK6oZ1erugrzOLYU /Q+N/MSt59e0EiqiEkrUv6KHbslCC3AJwNNlk= MIME-Version: 1.0 Received: by 10.204.36.134 with SMTP id t6mr1885820bkd.57.1308917678258; Fri, 24 Jun 2011 05:14:38 -0700 (PDT) Received: by 10.205.82.134 with HTTP; Fri, 24 Jun 2011 05:14:38 -0700 (PDT) In-Reply-To: <168A9ADF-1DE1-4F42-8206-FDBE95A64978@sensinode.com> References: <168A9ADF-1DE1-4F42-8206-FDBE95A64978@sensinode.com> Date: Fri, 24 Jun 2011 08:14:38 -0400 Message-ID: From: Brian Frank To: Zach Shelby Content-Type: multipart/alternative; boundary=bcaec554e08a40b8ef04a67425ba Cc: core WG Subject: Re: [core] Content-type negotiation proposal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 12:14:44 -0000 --bcaec554e08a40b8ef04a67425ba Content-Type: text/plain; charset=ISO-8859-1 +1 On Thu, Jun 23, 2011 at 9:07 AM, Zach Shelby wrote: > Hi, > > Several times the WG has discussed the addition of content-type negotiation > support. Carsten has written up a proposal for how this can be achieved in > Section 2 of [draft-bormann-coap-misc-08]. > > Recently two SDOs have been designing the use of CoAP bindings, in ZigBee > SE2 and in ETSI M2M. In both of those SDOs we have run across the need to > indicate simple content-type preference in a GET request. Because both SDOs > also have an HTTP binding, they have assumed the availability of > negotiation. Attempts to solve the problem in other ways has been awkward. I > think we'll see the same trend in other M2M designs that also support HTTP. > > Therefore I propose a ticket to add content-type preference indication to > coap-07. In particular, the proposal is to add a new Elective option called > "Accept". Here is text lifted from coap-misc-08: > > "The CoAP Accept option would > when included one or more times in a request, carry one or more media > types, each of which is an acceptable media type for the client, in > the order of preference. If no Accept option is given, the client > does not express a preference. The client prefers the representation > returned by the > server to be in one of the media types, but is willing to accept > the response also if the server returns a representation in a > different media type." > > One minor side effect of this change, is that the ct= attribute of > core-link-format would need to be allowed multiple times. This attribute > definition should anyways be moved from core-link-format and placed in > core-coap as it is CoAP specific. > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --bcaec554e08a40b8ef04a67425ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Thu, Jun 23, 2011 at 9:07 AM, Zach = Shelby <zach@sen= sinode.com> wrote:
Hi,

Several times the WG has discussed the addition of content-type negotiation= support. Carsten has written up a proposal for how this can be achieved in= Section 2 of [draft-bormann-coap-misc-08].

Recently two SDOs have been designing the use of CoAP bindings, in ZigBee S= E2 and in ETSI M2M. In both of those SDOs we have run across the need to in= dicate simple content-type preference in a GET request. Because both SDOs a= lso have an HTTP binding, they have assumed the availability of negotiation= . Attempts to solve the problem in other ways has been awkward. I think we&= #39;ll see the same trend in other M2M designs that also support HTTP.

Therefore I propose a ticket to add content-type preference indication to c= oap-07. In particular, the proposal is to add a new Elective option called = "Accept". Here is text lifted from coap-misc-08:

"The CoAP Accept option would
=A0 when included one or more times in a request, carry one or more media<= br> =A0 types, each of which is an acceptable media type for the client, in =A0 the order of preference. =A0If no Accept option is given, the client =A0 does not express a preference. The client prefers the representation r= eturned by the
=A0 =A0 =A0server to be in one of the media types, but is willing to accep= t
=A0 =A0 =A0the response also if the server returns a representation in a =A0 =A0 =A0different media type."

One minor side effect of this change, is that the ct=3D attribute of core-l= ink-format would need to be allowed multiple times. This attribute definiti= on should anyways be moved from core-link-format and placed in core-coap as= it is CoAP specific.

Zach

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode= .com
http://zachshelby.org =A0- My blog "On the Internet of Things"
http://6lowpan.net - M= y book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 = 40 7796297


_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core


--bcaec554e08a40b8ef04a67425ba-- From angelo.castellani@gmail.com Fri Jun 24 06:56:13 2011 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 6601911E8081 for ; Fri, 24 Jun 2011 06:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wcClsvJ3NPy for ; Fri, 24 Jun 2011 06:56:12 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60311E808C for ; Fri, 24 Jun 2011 06:56:11 -0700 (PDT) Received: by qyk29 with SMTP id 29so2019615qyk.10 for ; Fri, 24 Jun 2011 06:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=TdCLK65OumnBGHC4PNhEOIFZVSkoOk5I5ulssJTB+TQ=; b=Syjax5DQi1w7T8W04t9GyzMH0MhWOiXHGrnhaOv49mdMsiED294Gi+O/Wg/xPFqqLO Ggk/ou7BIQLGY0FfRZ2n3G3109LQ9QsxU4A3q/U3gaukQ6VEQ2XjcjasgqaTB4+1Hzhk sP6i2GvG77TbeqwesKj2zzPBI+H51+hEDVbqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ja8IQW1WGmw8Q7RC6aH5psWvWuzKz/+cYEGNXedcmUUbV2PqVDX4xWvObYThEYVMxN aRIBQq0q1QNu1WjP1i2I066wSdIUZ6p2R8WYIzbSvEPz6XKgHQt4LXfMWN7wG45mxSRG HIEK8xz3mTv6V+hlEpcV21BiMvjYBlv5oWFcI= Received: by 10.229.68.227 with SMTP id w35mr2484882qci.140.1308923769123; Fri, 24 Jun 2011 06:56:09 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.84.73 with HTTP; Fri, 24 Jun 2011 06:55:49 -0700 (PDT) In-Reply-To: <168A9ADF-1DE1-4F42-8206-FDBE95A64978@sensinode.com> References: <168A9ADF-1DE1-4F42-8206-FDBE95A64978@sensinode.com> From: "Angelo P. Castellani" Date: Fri, 24 Jun 2011 15:55:49 +0200 X-Google-Sender-Auth: Onzz-47HOJ1d-2RS-yn-F5pKY_g Message-ID: To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core WG Subject: Re: [core] Content-type negotiation proposal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 13:56:13 -0000 +1 I like this proposal too. Best, Angelo On Thu, Jun 23, 2011 at 15:07, Zach Shelby wrote: > Hi, > > Several times the WG has discussed the addition of content-type negotiati= on support. Carsten has written up a proposal for how this can be achieved = in Section 2 of [draft-bormann-coap-misc-08]. > > Recently two SDOs have been designing the use of CoAP bindings, in ZigBee= SE2 and in ETSI M2M. In both of those SDOs we have run across the need to = indicate simple content-type preference in a GET request. Because both SDOs= also have an HTTP binding, they have assumed the availability of negotiati= on. Attempts to solve the problem in other ways has been awkward. I think w= e'll see the same trend in other M2M designs that also support HTTP. > > Therefore I propose a ticket to add content-type preference indication to= coap-07. In particular, the proposal is to add a new Elective option calle= d "Accept". Here is text lifted from coap-misc-08: > > "The CoAP Accept option would > =A0 when included one or more times in a request, carry one or more media > =A0 types, each of which is an acceptable media type for the client, in > =A0 the order of preference. =A0If no Accept option is given, the client > =A0 does not express a preference. The client prefers the representation = returned by the > =A0 =A0 =A0server to be in one of the media types, but is willing to acce= pt > =A0 =A0 =A0the response also if the server returns a representation in a > =A0 =A0 =A0different media type." > > One minor side effect of this change, is that the ct=3D attribute of core= -link-format would need to be allowed multiple times. This attribute defini= tion should anyways be moved from core-link-format and placed in core-coap = as it is CoAP specific. > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org =A0- My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From fluffy@cisco.com Fri Jun 24 07:28:07 2011 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 5B44A11E808C for ; Fri, 24 Jun 2011 07:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.024 X-Spam-Level: X-Spam-Status: No, score=-110.024 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgZWYKzwCHa6 for ; Fri, 24 Jun 2011 07:28:06 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id AEAFD228020 for ; Fri, 24 Jun 2011 07:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=345; q=dns/txt; s=iport; t=1308925686; x=1310135286; h=mime-version:subject:from:date:cc: content-transfer-encoding:message-id:references:to; bh=SWS2UVupwBfaOlFaKkAUBwKmsyT7PNe+7G119VLR6lQ=; b=T0doS+1Rhu17E58MvE9WrZZrgwkgTqAeJpxZ45fCRkH/aJgimi+2FdCr dn8D7OsWlS5MLqT7PBjtQKoanm/0Y4TEtmSJNzwxorSquc+Mf4y5KkZx2 NRU3DypOkrUq/w+PmFe56XXETJUDslAWM1HhMvDO1SwzDea7ADL+il0eu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8IAKydBE6rRDoJ/2dsb2JhbABSLacJd4hzo2SeEYYtBIcpilKEaItK X-IronPort-AV: E=Sophos;i="4.65,419,1304294400"; d="scan'208";a="346515267" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2011 14:27:04 +0000 Received: from [192.168.4.101] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5OER0KF011402; Fri, 24 Jun 2011 14:27:03 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings Date: Thu, 23 Jun 2011 21:19:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20110623234547.6CD5D11E807C@ietfa.amsl.com> To: core WG X-Mailer: Apple Mail (2.1084) Subject: [core] CORE - Requested sessions have been scheduled for IETF 81 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 14:28:07 -0000 Tentative times for CORE sessions at IETF 81 > > CORE Session 1 (2 hours) > Wednesday, Morning Session I 0900-1130 > Room Name: 206 B > ---------------------------------------------- > CORE Session 2 (2 hours) > Thursday, Afternoon Session III 1740-1940 > Room Name: 202 > ---------------------------------------------- > > From zach@sensinode.com Sun Jun 26 23:43:47 2011 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 2D25621F8650 for ; Sun, 26 Jun 2011 23:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIFeC7cfAuLx for ; Sun, 26 Jun 2011 23:43:46 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id A7D6921F864F for ; Sun, 26 Jun 2011 23:43:41 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5R6hYDb012029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2011 09:43:35 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-174-137128574; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 27 Jun 2011 09:40:10 +0300 Message-Id: <968F233B-77F6-4BE2-A5E3-1C49064EC9F6@sensinode.com> References: <20110623234547.6CD5D11E807C@ietfa.amsl.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] CORE - Requested sessions have been scheduled for IETF 81 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 06:43:47 -0000 --Apple-Mail-174-137128574 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a 5:25 PM flight from Quebec on Thursday due to some family = pressure. So I would really, really like to move Session 2 up in the = schedule. For example Thursday morning or Wednesday afternoon.=20 Zach On Jun 24, 2011, at 7:19 AM, Cullen Jennings wrote: >=20 > Tentative times for CORE sessions at IETF 81 >=20 >=20 >>=20 >> CORE Session 1 (2 hours) >> Wednesday, Morning Session I 0900-1130 >> Room Name: 206 B >> ---------------------------------------------- >> CORE Session 2 (2 hours) >> Thursday, Afternoon Session III 1740-1940 >> Room Name: 202 >> ---------------------------------------------- >>=20 >>=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-174-137128574 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYyNzA2NDAx MFowIwYJKoZIhvcNAQkEMRYEFD2iZwkAXZn0N/LIlc8Ym7OXsupaMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABLKV4MfM8KcUj0A4jiK/EbtKoVaghcQ3erjYpUS7tQ7+ltIne4OakU+ DdChVv2N9dh8vGTZHIQ6aFjLrBslQbOPtmwZwSEo5b8nZwfVhtMULxkOOjWmRdvvkkjzDES6siwM ezYlUvzZUi6G5JTfmfVG7jTFWLCcpu850yv5vbziea9vUGM8XMF8+EkRSIMtbD+rCbu/OZFBAsCi +/RDEt5U3ry+MBOpsWGNZsS5HcrjXRSB0ZSbKifMRJJ9azuYwl6f12D31HyX0chqCdLNwiQTyxm+ KgL9wf4TTwTj60bZHUL/FJlU2EzAy1XKOod5WxOnrk5u7Lq7N8S20TzsMjEAAAAAAAA= --Apple-Mail-174-137128574-- From zach@sensinode.com Mon Jun 27 06:54:34 2011 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 950B221F85BB for ; Mon, 27 Jun 2011 06:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wbkJnTcTRQp for ; Mon, 27 Jun 2011 06:54:33 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 50EA621F8419 for ; Mon, 27 Jun 2011 06:54:29 -0700 (PDT) Received: from [213.145.205.249] ([213.145.205.249]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5RCK4f8003214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Jun 2011 15:20:05 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-35-157524713; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 27 Jun 2011 15:20:06 +0300 References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> To: core WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 13:54:34 -0000 --Apple-Mail-35-157524713 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have submitted an initial resource directory interface specification = draft, and would like to spend 10 minutes in Quebec to present it. http://tools.ietf.org/html/draft-shelby-core-resource-directory-00 Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 27, 2011 3:15:06 PM GMT+03:00 > To: zach@sensinode.com > Cc: srdjan.krco@ericsson.com, zach@sensinode.com > Subject: New Version Notification for = draft-shelby-core-resource-directory-00.txt >=20 > A new version of I-D, draft-shelby-core-resource-directory-00.txt has = been successfully submitted by Zach Shelby and posted to the IETF = repository. >=20 > Filename: draft-shelby-core-resource-directory > Revision: 00 > Title: CoRE Resource Directory > Creation date: 2011-06-27 > WG ID: Individual Submission > Number of pages: 16 >=20 > Abstract: > 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 registrer, maintain, lookup and remove resources > descriptions. Furthermore, new link attributes useful in = conjunction > with an RD are defined. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-35-157524713 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYyNzEyMjAw NlowIwYJKoZIhvcNAQkEMRYEFO/0dbe0N5EIcXO2SS7BszF/k8QiMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAEkq/FjbX3ipmbFNNUZWFrMzCklxo50DJ1159O0Mmm6ap2y5MEsH1Rwo 1Cl2FV90ueVyGZB+Vtkn+a6ZFob55LIn09k/FJBNO93vKr2ErTfXgFkVFccQIU04qGKS7VWcSSKR KF/kD3xR7HKFS4GZAzYlmIu7pQvZAFpyUf1VLsCA9xwlQnG15QBDxJJQJppM0dXaQZFSD/JZnBf1 5qpII5dmfLPigjJ4q61jqQTd8tooEy4KExQZjp3vlXBobEWkWrGgWb1GKWvbSlBwfw7A4R1NwA3Z U9AGTIVsmDPSHDUUrJS7LKJT/hrEIfaB1vybZ3ap8A+If64nv68lYPW79r4AAAAAAAA= --Apple-Mail-35-157524713-- From salvatore.loreto@ericsson.com Tue Jun 28 07:13:13 2011 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 EDC2021F869A for ; Tue, 28 Jun 2011 07:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuHXk+YoYwCS for ; Tue, 28 Jun 2011 07:13:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 78A9421F8699 for ; Tue, 28 Jun 2011 07:13:12 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-65-4e09e17671e2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 34.DE.09774.671E90E4; Tue, 28 Jun 2011 16:13:10 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 28 Jun 2011 16:13:10 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 474F7242A for ; Tue, 28 Jun 2011 17:13:10 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1070B50B72 for ; Tue, 28 Jun 2011 17:13:10 +0300 (EEST) Received: from ip-193-234-217-22.guest.ericsson.fi (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BBED34EFEA for ; Tue, 28 Jun 2011 17:13:09 +0300 (EEST) Message-ID: <4E09E175.3050800@ericsson.com> Date: Tue, 28 Jun 2011 17:13:09 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: core@ietf.org References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 14:13:14 -0000 Hi Zac, I have had a look at the draft, it looks an interesting one I have a first question, maybe it is because I have read it quickly, but I found strange that the Registration interface does not contain an attribute to register also the IP address of the sensor without it is not clear how you would target the request to the resource once you have discovered them through the Lookup interface. cheers /Sal -- Salvatore Loreto www.sloreto.com On 6/27/11 3:20 PM, Zach Shelby wrote: > We have submitted an initial resource directory interface specification draft, and would like to spend 10 minutes in Quebec to present it. > > http://tools.ietf.org/html/draft-shelby-core-resource-directory-00 > > Zach > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Date: June 27, 2011 3:15:06 PM GMT+03:00 >> To: zach@sensinode.com >> Cc: srdjan.krco@ericsson.com, zach@sensinode.com >> Subject: New Version Notification for draft-shelby-core-resource-directory-00.txt >> >> A new version of I-D, draft-shelby-core-resource-directory-00.txt has been successfully submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: draft-shelby-core-resource-directory >> Revision: 00 >> Title: CoRE Resource Directory >> Creation date: 2011-06-27 >> WG ID: Individual Submission >> Number of pages: 16 >> >> Abstract: >> 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 registrer, maintain, lookup and remove resources >> descriptions. Furthermore, new link attributes useful in conjunction >> with an RD are defined. >> >> >> >> >> The IETF Secretariat From salvatore.loreto@ericsson.com Tue Jun 28 10:40:32 2011 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 3988411E8117 for ; Tue, 28 Jun 2011 10:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPw7HDH3xU7i for ; Tue, 28 Jun 2011 10:40:31 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C603911E8115 for ; Tue, 28 Jun 2011 10:40:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-63-4e0a120dd61d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C9.A2.09774.D021A0E4; Tue, 28 Jun 2011 19:40:29 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 28 Jun 2011 19:40:29 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 86238242A for ; Tue, 28 Jun 2011 20:40:29 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4F2425104D for ; Tue, 28 Jun 2011 20:40:29 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 071E150F34 for ; Tue, 28 Jun 2011 20:40:28 +0300 (EEST) Message-ID: <4E0A120C.3030408@ericsson.com> Date: Tue, 28 Jun 2011 20:40:28 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: core@ietf.org References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> <4E09E175.3050800@ericsson.com> In-Reply-To: <4E09E175.3050800@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2011 17:40:32 -0000 On 6/28/11 5:13 PM, Salvatore Loreto wrote: > Hi Zac, > > I have had a look at the draft, it looks an interesting one > > I have a first question, maybe it is because I have read it quickly, but > I found strange that > the Registration interface does not contain an attribute to register > also the IP address of the sensor > > without it is not clear how you would target the request to the resource > once you have discovered them > through the Lookup interface. > > > cheers > /Sal > actually we can also avoid to have an IP address attribute in the interface, if we automatically store/update in the resource created/update in the RD the source IP address of the POST/PUT request of course we have to provide it back at lookup time. thoughts? cheers /Sal -- Salvatore Loreto www.sloreto.com From zach@sensinode.com Wed Jun 29 00:42:10 2011 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 3DF3B21F86F7 for ; Wed, 29 Jun 2011 00:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MC4lPpjMfIG for ; Wed, 29 Jun 2011 00:42:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id C3C2721F86E9 for ; Wed, 29 Jun 2011 00:42:08 -0700 (PDT) Received: from [192.168.0.202] (gwireccon.uab.es [158.109.91.251]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5T7ftSr005235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jun 2011 10:41:56 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-84-313635252; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4E0A120C.3030408@ericsson.com> Date: Wed, 29 Jun 2011 10:41:56 +0300 Message-Id: References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> <4E09E175.3050800@ericsson.com> <4E0A120C.3030408@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 07:42:10 -0000 --Apple-Mail-84-313635252 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sal, On Jun 28, 2011, at 8:40 PM, Salvatore Loreto wrote: > On 6/28/11 5:13 PM, Salvatore Loreto wrote: >> Hi Zac, >>=20 >> I have had a look at the draft, it looks an interesting one >>=20 >> I have a first question, maybe it is because I have read it quickly, = but >> I found strange that >> the Registration interface does not contain an attribute to register >> also the IP address of the sensor >>=20 >> without it is not clear how you would target the request to the = resource >> once you have discovered them >> through the Lookup interface. >>=20 >>=20 >> cheers >> /Sal >>=20 > actually we can also avoid to have an IP address attribute in the = interface, > if we automatically store/update in the resource created/update in the = RD > the source IP address of the POST/PUT request That is exactly what is assumed by the draft. Definitely needs to be = made clear as we have just been assuming it was obvious.=20 > of course we have to provide it back at lookup time. Yes, this is done by including the full scheme + authority in the URI = part of the link format when answering a lookup. For example: GET coap://resource-directory/rd?rt=3DTemperatureC 2.05 Content ;rt=3D"TemperatureC" ;rt=3D"TemperatureC" Where node1/node2 is replaced by the IPv6 address and possibly the port = of the nodes collected when they registered.=20 Zach >=20 > thoughts? >=20 > cheers > /Sal >=20 > --=20 > Salvatore Loreto > www.sloreto.com >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-84-313635252 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYyOTA3NDE1 N1owIwYJKoZIhvcNAQkEMRYEFP3xEpnFy/VJqqa8h2qpu7if8zrWMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAE1vU7C9arFnCWQy1fuz81rp0y+wJXNp5KbvpEF8FaifGd0TdhBf7chI 4BCQMkkA651XjFgI2vZps68M4YIbGiXEmE1pnArfM82VLTOgl5z/1U+i3qKXbLTKU6vaEAKLs4lv IzLpgmtVlQHDMVE/Sl+Rqc/SAVKgxYBjxjxWWWeeHHEwls0vCFP5xW252aJbFBuXZHLlEsTIwrlk /C60qrv38o0Ll0iVPGh0sxBlJ+D0G09iokv1t1e0+v7/NNI20IBSfhZpalo2cpGSTktrDwyTZOpP wI9rrB6taVZ0cQ8APGSnmNAIH2CA5O/qmfCOc1EzYIGk2M/Oa6f8ekR5tqEAAAAAAAA= --Apple-Mail-84-313635252-- From angelo.castellani@gmail.com Wed Jun 29 00:50:40 2011 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 3B2BA21F853E for ; Wed, 29 Jun 2011 00:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6liJwJXvCR5f for ; Wed, 29 Jun 2011 00:50:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD5C21F853A for ; Wed, 29 Jun 2011 00:50:39 -0700 (PDT) Received: by qyk9 with SMTP id 9so3140791qyk.10 for ; Wed, 29 Jun 2011 00:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=5/FbmzrhU6biWhNkFCfCASz1jUWsH6xi6+m3EsBw56I=; b=YZC22RabhCiz0K7Sk8CWMhkAVd2dQC7TFt4nxCglrps+r5Gry7dHrx31Lyk6A7H1r0 T7P/o08/XLp5tpp7xvU9sj0/LNQlCaviDvQ0yodmkmGZ8isuMMVhqCenjRu2HqfN6MkC /qTOh0HYsHA/WITUipnrAjUn/UUTrKviZ19D4= Received: by 10.229.65.144 with SMTP id j16mr355797qci.26.1309333838095; Wed, 29 Jun 2011 00:50:38 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.84.73 with HTTP; Wed, 29 Jun 2011 00:50:18 -0700 (PDT) In-Reply-To: References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> <4E09E175.3050800@ericsson.com> <4E0A120C.3030408@ericsson.com> From: "Angelo P. Castellani" Date: Wed, 29 Jun 2011 09:50:18 +0200 X-Google-Sender-Auth: 9EPtsnkhZ0UqxkwXsvfLm9y8c4o Message-ID: To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 07:50:40 -0000 On Wed, Jun 29, 2011 at 09:41, Zach Shelby wrote: > That is exactly what is assumed by the draft. Definitely needs to be made clear as we have just been assuming it was obvious. Probably also having a way to specify the source of the message will be useful in some scenario. Assume that a NAT or a proxy is involved in the process, in that case the source IP address available at the RD is not pointing to the actual source CoAP server anymore. Don't know if this can be done here using some existing coap or link-format options, or if we need a specific option to signal it. Best, Angelo From szymon.sasin@sensinode.com Wed Jun 29 00:57:18 2011 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 D885921F8760 for ; Wed, 29 Jun 2011 00:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MS5bStycOpSs for ; Wed, 29 Jun 2011 00:57:18 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id CC92621F8671 for ; Wed, 29 Jun 2011 00:57:17 -0700 (PDT) Received: from [192.168.0.123] (82-128-196-163.bb.dnainternet.fi [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5T7vBTY012582 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 29 Jun 2011 10:57:14 +0300 Message-ID: <4E0ADADA.7020506@sensinode.com> Date: Wed, 29 Jun 2011 10:57:14 +0300 From: Szymon User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: core@ietf.org References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> <4E09E175.3050800@ericsson.com> <4E0A120C.3030408@ericsson.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020804000800030004020705" Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 07:57:19 -0000 This is a cryptographically signed message in MIME format. --------------ms020804000800030004020705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Can be done, for example: ;rt=3D"TemperatureC" In addition proxy/gateway maybe could alter links and insert missing sour= ce ip? Szymon Sensinode Ltd > On Wed, Jun 29, 2011 at 09:41, Zach Shelby wrote: >> That is exactly what is assumed by the draft. Definitely needs to be m= ade clear as we have just been assuming it was obvious. > Probably also having a way to specify the source of the message will > be useful in some scenario. > > Assume that a NAT or a proxy is involved in the process, in that case > the source IP address available at the RD is not pointing to the > actual source CoAP server anymore. > > Don't know if this can be done here using some existing coap or > link-format options, or if we need a specific option to signal it. > > Best, > Angelo > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------ms020804000800030004020705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO8jCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVAwggQ4oAMCAQICEDjbaQ3SI//mPBeOra74YnswDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDA5MTAwMDAwMDBaFw0xMTA5MTAyMzU5NTlaMIIBGTEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRUw EwYDVQQDFAxTenltb24gU2FzaW4xKTAnBgkqhkiG9w0BCQEWGnN6eW1vbi5zYXNpbkBzZW5z aW5vZGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuBjJVNbnWYRQqI5+ d7kooS9cpBZkLmBJDrG2Nn7SKd3hDJz7hKqdmwyc1ukAZ/LqgfAbv6+tng2Q13DEP3kVIDsZ v964LMBcqScYN497IDZ7ZuF0LT5iIyAfM1xDQy3MUMCEUnAfeGzNNLcktNO8NBh8dhF3o942 yxfn/l0fp09J2NAPHWA2vimGsv+qSG0ftbovG/LHmLbFuPWfX/4FJzl9uDQ4KXmRfXJoWOcC JGBjc9qvmvNKKzqrn0o3ADRroOpTaw6KSPzvDQ/l7cqkyL28lCpSa6pE7baL0VsPGI6/bIYc 7DCxgU8LcYLWc6L4d8fFjfRfh984fSeLvCbU2wIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUH AwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2ln bi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAYngmMyRFMyOk+ 7toGZ6eSKyxyOI2O9oG/hQO2keURFdTtbr1FwVLXiB0d/frGwwcAgKuzbAPHCzU0biedLqG+ M75jpWt2DXznkIM14Hk55rq/L2CpUZ+nEfqN784wyk44v89zCeLE7guQ0Xj3F/wXgN1QjRcX OAevAqbk7u/KaDe7jtmX0bRRs+AuC9vhBqayYxgYbaoxm5oz+nx2WqSc9JWtsWdfg0YZEDtZ rDaxYSJv8DnhlmEk2GOz6xBSlJFyDB6KQZQw8nM+TbfnPnTuERD+ifeZjVRYlKnAbn03cFe8 9B8Kt6HBA4fX8nYqPn3WwT8OmlxTdD45h83geWmpMIIFUDCCBDigAwIBAgIQONtpDdIj/+Y8 F46trvhiezANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJU ZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDkxMDAwMDAwMFoXDTExMDkx MDIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxFTATBgNVBAMUDFN6eW1vbiBTYXNpbjEpMCcGCSqGSIb3DQEJARYac3p5 bW9uLnNhc2luQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC4GMlU1udZhFCojn53uSihL1ykFmQuYEkOsbY2ftIp3eEMnPuEqp2bDJzW6QBn8uqB8Bu/ r62eDZDXcMQ/eRUgOxm/3rgswFypJxg3j3sgNntm4XQtPmIjIB8zXENDLcxQwIRScB94bM00 tyS007w0GHx2EXej3jbLF+f+XR+nT0nY0A8dYDa+KYay/6pIbR+1ui8b8seYtsW49Z9f/gUn OX24NDgpeZF9cmhY5wIkYGNz2q+a80orOqufSjcANGug6lNrDopI/O8ND+XtyqTIvbyUKlJr qkTttovRWw8Yjr9shhzsMLGBTwtxgtZzovh3x8WN9F+H3zh9J4u8JtTbAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFs SUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBABieCYzJEUzI6T7u2gZnp5IrLHI4jY72gb+FA7aR5REV1O1uvUXBUteIHR39+sbDBwCA q7NsA8cLNTRuJ50uob4zvmOla3YNfOeQgzXgeTnmur8vYKlRn6cR+o3vzjDKTji/z3MJ4sTu C5DRePcX/BeA3VCNFxc4B68CpuTu78poN7uO2ZfRtFGz4C4L2+EGprJjGBhtqjGbmjP6fHZa pJz0la2xZ1+DRhkQO1msNrFhIm/wOeGWYSTYY7PrEFKUkXIMHopBlDDycz5Nt+c+dO4REP6J 95mNVFiUqcBufTdwV7z0Hwq3ocEDh9fydio+fdbBPw6aXFN0PjmHzeB5aakxggTsMIIE6AIB ATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEcyAhA422kN0iP/5jwXjq2u+GJ7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYyOTA3NTcxNFowIwYJKoZI hvcNAQkEMRYEFOZ9nY6tkQgUKqWYKAQt2K1C7xCmMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD Ey5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhA422kN 0iP/5jwXjq2u+GJ7MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQONtpDdIj/+Y8 F46trvhiezANBgkqhkiG9w0BAQEFAASCAQCszhZWjcFdrNE5dILaSSYAYSPt410jx8vFTeTJ PnGGNzP9CovmWIIFqQ2eS8CUFEYgg7PdFAffQOn9ivSdxsjgsmGiDtsxx06Rg0KV4cUSpHeg tQNNkI7whooEexyqKGZo0Jb3786bcK2K6lMpdFjRMqWA1Zrh6GhPJvUDQutLMQzTW6IiUl2Y /jdEEC2Zoxz+nDn5mMFV8rUhH94UEtlMCwMo2e6KOljU3kgIdhQYDl52ysycFJbpQ5CbGrrF VLlCU4RbjdBZweDTpoFe2u4yJziIdEK0mH5TS3q2XRSCg1UDz7zK7v1DW8osqWa3SWasxSPA 5mqp60HKIK7afEZVAAAAAAAA --------------ms020804000800030004020705-- From zach@sensinode.com Wed Jun 29 01:00:26 2011 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 71E7121F868D for ; Wed, 29 Jun 2011 01:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxHaYrT6iNdM for ; Wed, 29 Jun 2011 01:00:25 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 47A2621F868B for ; Wed, 29 Jun 2011 01:00:25 -0700 (PDT) Received: from [192.168.0.202] (gwireccon.uab.es [158.109.91.251]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5T80IGM014238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jun 2011 11:00:20 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-86-314739209; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 29 Jun 2011 11:00:20 +0300 Message-Id: References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> <4E09E175.3050800@ericsson.com> <4E0A120C.3030408@ericsson.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 08:00:26 -0000 --Apple-Mail-86-314739209 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 29, 2011, at 10:50 AM, Angelo P. Castellani wrote: > On Wed, Jun 29, 2011 at 09:41, Zach Shelby wrote: >> That is exactly what is assumed by the draft. Definitely needs to be = made clear as we have just been assuming it was obvious. >=20 > Probably also having a way to specify the source of the message will > be useful in some scenario. >=20 > Assume that a NAT or a proxy is involved in the process, in that case > the source IP address available at the RD is not pointing to the > actual source CoAP server anymore. >=20 > Don't know if this can be done here using some existing coap or > link-format options, or if we need a specific option to signal it. I agree, this would be useful in cases where an entity is registering on = behalf of an end-point. We have also been thinking about the need for = this. The way this should be done is to add a query string parameter to = register the authority to the POST registration request. I also include = the scheme in case that differs from the protocol being used to register = with. For example: POST coap://resource-directory/rd?authority=3Dcoap://node1:61616=20 Zach >=20 > Best, > Angelo --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-86-314739209 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYyOTA4MDAy MVowIwYJKoZIhvcNAQkEMRYEFHdI/kJpCj7XojgLXf+uOkkVBuoIMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBACxA3YnJBJob4Gy6aSUaJpru6Z5X8QQi1JQUTHmD58OWqw6V15NpS9xr Hm9rFwlB4+N3fjM6yo7v//K9IXwYty/aS9v1plKQ15z9EzFWkE/LlGUvLsVBuf5h6M93KefYoJKh FhNDfvGkMXeezSYHj3lynoTzybTOmE4a/7VVdO+av3EZdXARjCfvhpFjKLgx4QgKZZiNrmMpwHU9 6vVlwuO8uXBv0RURW7XUaTrVXAGcpvbWppopBZ/pImMQDM6ouetpeqIJ9JMnvrhqZnMt/uSWX+H+ xYVANAr+kdpr/1db5/ywAk+QlQ0lMfaLbkgBeFO9EN1NInAZpgOo5/dsW0MAAAAAAAA= --Apple-Mail-86-314739209-- From salvatore.loreto@ericsson.com Wed Jun 29 01:02:00 2011 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 9FF6421F869A for ; Wed, 29 Jun 2011 01:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQwNUGiv9Mjt for ; Wed, 29 Jun 2011 01:01:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD3721F8669 for ; Wed, 29 Jun 2011 01:01:59 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-47-4e0adbf6ebaf Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B5.26.20773.6FBDA0E4; Wed, 29 Jun 2011 10:01:58 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 29 Jun 2011 10:01:58 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 04E25242A; Wed, 29 Jun 2011 11:01:58 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C21F85117B; Wed, 29 Jun 2011 11:01:57 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6EF0351140; Wed, 29 Jun 2011 11:01:57 +0300 (EEST) Message-ID: <4E0ADBF5.1050103@ericsson.com> Date: Wed, 29 Jun 2011 11:01:57 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Angelo P. Castellani" References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> <4E09E175.3050800@ericsson.com> <4E0A120C.3030408@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "core@ietf.org" Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 08:02:00 -0000 On 6/29/11 10:50 AM, Angelo P. Castellani wrote: > On Wed, Jun 29, 2011 at 09:41, Zach Shelby wrote: >> That is exactly what is assumed by the draft. Definitely needs to be made clear as we have just been assuming it was obvious. Hi Zach, if I read the End-point Name (n) parameter definition, it is not clear it is for carrying the IP address especially an IPv6+Port... among the other because of the 63 octets limitation > Probably also having a way to specify the source of the message will > be useful in some scenario. that is really a good point to consider, > Assume that a NAT or a proxy is involved in the process, in that case > the source IP address available at the RD is not pointing to the > actual source CoAP server anymore. > the IP address you insert can not be the same of the source of the message e.g. if you have a NAT in between so consider both it is important also because the RD is a good candidate to keep open an eventual hole within a NAT > Don't know if this can be done here using some existing coap or > link-format options, or if we need a specific option to signal it. if we design the RD correctly we do not need extra options in CoAP neither in the link-format -- Salvatore Loreto www.sloreto.com > Best, > Angelo From salvatore.loreto@ericsson.com Wed Jun 29 02:49:26 2011 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 422F29E8021 for ; Wed, 29 Jun 2011 02:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGawfE2DaDb6 for ; Wed, 29 Jun 2011 02:49:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2631B21F86BE for ; Wed, 29 Jun 2011 02:49:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-07-4e0af524c7c9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 25.FD.09774.425FA0E4; Wed, 29 Jun 2011 11:49:24 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 29 Jun 2011 11:49:23 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B2BFB2950 for ; Wed, 29 Jun 2011 12:49:23 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 75F515095F for ; Wed, 29 Jun 2011 12:49:23 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2F9E050951 for ; Wed, 29 Jun 2011 12:49:23 +0300 (EEST) Message-ID: <4E0AF523.9040900@ericsson.com> Date: Wed, 29 Jun 2011 12:49:23 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: core@ietf.org References: <76503846-BE4E-435B-A7B2-9AA679D17B11@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F228783B@SZXEML506-MBS.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 09:49:26 -0000 I know I am biased here, but I do like to possibility for a client to specify the max time it is willing to wait for a response of course differently from the HTTP world, in CoRe we have to deal with sleeping sensors so maybe other then a new response code "can't provide the data in time" , as proposed by Carsten, we also need a more general response code that can be sent by a Proxy "the sensor is sleeping" more what really means inserting the Request Timeout header in a POST/PUT request: if the sensor is not able to handle the request in that interval of time, what it the right behavior? should the request simple be discarded or what? cheers /Sal -- Salvatore Loreto www.sloreto.com On 5/10/11 4:06 PM, Carsten Bormann wrote: > On May 10, 2011, at 03:17, Likepeng wrote: > >> I have a draft to let the client to define a timeout in the request: >> http://tools.ietf.org/id/draft-li-core-coap-response-mode-option-00.txt >> >> [...] >> I would like to get feedback from you on the draft. > Sure. > > 1) Get rid of the P bit. > Influencing this is none of the client's business. > It is not even useful for a client -- since the option is elective, the client cannot even rely on it being heeded. > There is no option in TCP to control whether the peer should send its data piggybacked on an ACK either. > > 2) I think I like the T part of the option. > However, it should be rephrased as > > "indicates the length of time from the time of request the response would be useful for the client". > > Because that's all we can say. If the server doesn't have the data, it doesn't have it. > > Representing T in exponential form sounds fine to me (but we have had some arguments on duration representation before). I would deliberately keep the spec open on whether the base is milliseconds or 1024s of a second -- the clocks are not going to be that precise anyway, and this might help some implementations that count in 1024s ("mibiseconds") or in whole seconds. > > 3) T should not have a default value. > > (I'm not going to repeat why that would be a mistake, see my previous messages.) > > 4) We also need a new response code, "can't provide the data in time". > > This is a code that a server that already knows it won't be able to meet the deadline can send early on. > (Note that the client cannot rely on getting the response code, because the server might have failed in the meantime.) > > We haven't really discussed the difference between what is Connection-Timeout in draft-thomson-hybi-http-timeout-00 and this option, which is similar to Request-Timeout in that draft. > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From esko.dijk@philips.com Wed Jun 29 02:53:15 2011 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 475AC9E802A for ; Wed, 29 Jun 2011 02:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pPvw1rI2C07 for ; Wed, 29 Jun 2011 02:53:14 -0700 (PDT) Received: from CH1EHSOBE012.bigfish.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2300F9E8021 for ; Wed, 29 Jun 2011 02:53:14 -0700 (PDT) Received: from mail126-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Wed, 29 Jun 2011 09:53:12 +0000 Received: from mail126-ch1 (localhost.localdomain [127.0.0.1]) by mail126-ch1-R.bigfish.com (Postfix) with ESMTP id 31D47D702E1; Wed, 29 Jun 2011 09:53:13 +0000 (UTC) X-SpamScore: -47 X-BigFish: VPS-47(zz217bL15d6O9251J9371M1432N98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail126-ch1 (localhost.localdomain [127.0.0.1]) by mail126-ch1 (MessageSwitch) id 1309341192507300_7497; Wed, 29 Jun 2011 09:53:12 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail126-ch1.bigfish.com (Postfix) with ESMTP id 6E84CE004E; Wed, 29 Jun 2011 09:53:12 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 29 Jun 2011 09:53:11 +0000 Received: from NLHILEXH05.connect1.local (172.16.153.71) by connect1.philips.com (172.16.156.49) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 29 Jun 2011 11:52:45 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLHILEXH05.connect1.local ([172.16.153.71]) with mapi; Wed, 29 Jun 2011 11:51:32 +0200 From: "Dijk, Esko" To: Brian Frank , Carsten Bormann Date: Wed, 29 Jun 2011 11:52:50 +0200 Thread-Topic: [core] Message ID sliding window Thread-Index: AcwwC83oY51slzxtTcaF4MpX/BPCKQFbQvgg Message-ID: References: <97F89AFB-DB55-4BFA-B625-E372FCF0761A@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A337AA36B3B96E4D853E6182B2F27AE2CDCAA22273NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 09:53:15 -0000 --_000_A337AA36B3B96E4D853E6182B2F27AE2CDCAA22273NLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Brian, for clarification - do you mean here ordered with a separate 16-bit MID cou= nter kept for each CoAP destination node, or ordered with simply one MID co= unter that is used for all communications (like defined in the current coap= -06 spec; a single MID variable) ? Or could a CoAP node even choose between these two ways of ordering? best regards, Esko From: core-bounces@ietf.org [mailto:core-boun= ces@ietf.org] On Behalf Of Brian Fra= nk Sent: Tuesday 21 June 2011 14:08 To: Carsten Bormann Cc: core Subject: Re: [core] Message ID sliding window This seems like a fairly simple question to me: which is the better enginee= ring tradeoff: to force IDs to be allocated in order, or allow them to be g= enerated randomly. If there are ordered: - can use a sliding window to keep track of messages received more compac= tly - can detect out of order messages - can more easily detect duplicate messages - safest course for clients to ensure maximum time before ID is recycled If there are not ordered: - no value On Sat, Jun 18, 2011 at 2:39 AM, Carsten Bormann > wrote: On Jun 18, 2011, at 01:30, Brian Frank wrote: > Most servers are completely stateless, they don't need to allocate anythi= ng. > Where they do need to (non-idempotent methods like POST), they also usual= ly need to store responses, so there is little savings in just being able t= o compress message-IDs. > > > Because often a non-idempotent POST request might not have a response pay= load or the payload can be reconstructed from application state, in which c= ase the server only needs to keep track of whether it has seen the message = or not. So this is all about optimizing one very special case. (I'd still like to understand the use case, in specific terms. If the response options/payload indeed can be reconstructed from applicatio= n state, that might also provide any deduplication needed.) > Let's rephrase the issue: > > What value is there in allowing a client to not use serial IDs? First of all, what does this question mean? When is a message ID "serial"? What would a server do when a client does something slightly non-serial? (Messages do get lost or reordered.) What would a server do when a client's message IDs are all over the place? Reject the request with "your message ID's aren't as close to each other as= I'd like"? What would a server do when a client reboots? How do you ensure the server= 's state has timed out quickly enough for the rebooted client to send messa= ges again? This gets ugly very quickly. > I can't think of any use-case where this flexibility provides any value, = but maybe something was discussed? > > On the other hand, there seems like lots of different use cases where ser= ially incrementing Message IDs might have value. > > The spec just doesn't seem to make a good engineering trade-off on this i= ssue. The spec does the right thing from a protocol design point of view: It does= not provide a constraint where none is needed. However, if you believe supporting this specific optimization is worth it, = we could RECOMMEND (i.e., mandate at the SHOULD level) to use message-IDs t= hat are close (in modulo arithmetic) to recently used message-IDs. I'm not yet convinced of the use case. Gruesse, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_A337AA36B3B96E4D853E6182B2F27AE2CDCAA22273NLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Brian,

 <= /p>

for clarification - do yo= u mean here ordered with a separate 16-bit MID counter kept for each CoAP d= estination node, or ordered with simply one MID counter that is used for all communications (like defined in the current coap-06 s= pec; a single MID variable) ? 

 <= /p>

Or could a CoAP node even= choose between these two ways of ordering?

 <= /p>

best regards,<= /span>

Esko

 <= /p>

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Brian Frank
Sent: Tuesday 21 June 2011 14:08
To: Carsten Bormann
Cc: core
Subject: Re: [core] Message ID sliding window

 

This seems like a fairly simple question to me: whic= h is the better engineering tradeoff: to force IDs to be allocated in order= , or allow them to be generated randomly.

 

If there are ordered:

  - can use a sliding window to keep track of m= essages received more compactly

  - can detect out of order messages=

  - can more easily detect duplicate messages

  - safest course for clients to ensure maximum= time before ID is recycled

 

If there are not ordered:

  - no value

 

 

On Sat, Jun 18, 2011 at 2:39 AM, Carsten Bormann <= ;cabo@tzi.org> wrote:

On Jun 18, 2011, at 0= 1:30, Brian Frank wrote:

> Most servers are completely stateless, they don't need to allocate any= thing.
> Where they do need to (non-idempotent methods like POST), they also us= ually need to store responses, so there is little savings in just being abl= e to compress message-IDs.
>
>
> Because often a non-idempotent POST request might not have a response = payload or the payload can be reconstructed from application state, in whic= h case the server only needs to keep track of whether it has seen the messa= ge or not.

So this is all about optimizing one very special cas= e.

(I'd still like to understand the use case, in specific terms.
If the response options/payload indeed can be reconstructed from applicatio= n state, that might also provide any deduplication needed.)


> Let's rephrase the issue:
>
> What value is there in allowing a client to not use serial IDs?

First of all, what does this question mean?
When is a message ID "serial"?
What would a server do when a client does something slightly non-serial? (Messages do get lost or reordered.)
What would a server do when a client's message IDs are all over the place?<= br> Reject the request with "your message ID's aren't as close to each oth= er as I'd like"?
What would a server do when a client reboots?  How do you ensure the s= erver's state has timed out quickly enough for the rebooted client to send = messages again?
This gets ugly very quickly.


> I can't think of any use-case where this flexibility provides any valu= e, but maybe something was discussed?
>
> On the other hand, there seems like lots of different use cases where = serially incrementing Message IDs might have value.
>
> The spec just doesn't seem to make a good engineering trade-off on thi= s issue.

The spec does the rig= ht thing from a protocol design point of view: It does not provide a constr= aint where none is needed.

However, if you believe supporting this specific optimization is worth it, = we could RECOMMEND (i.e., mandate at the SHOULD level) to use message-IDs t= hat are close (in modulo arithmetic) to recently used message-IDs.

I'm not yet convinced of the use case.

Gruesse, Carsten

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_A337AA36B3B96E4D853E6182B2F27AE2CDCAA22273NLCLUEXM03con_-- From matthieu.vial@non.schneider-electric.com Wed Jun 29 04:03:00 2011 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 BBEFF21F8633; Wed, 29 Jun 2011 04:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5s53eDjtmeC; Wed, 29 Jun 2011 04:03:00 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by ietfa.amsl.com (Postfix) with ESMTP id 33ECA21F8631; Wed, 29 Jun 2011 04:02:57 -0700 (PDT) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX01.eud.schneider-electric.com with ESMTP id 2011062912400243-61682 ; Wed, 29 Jun 2011 12:40:02 +0200 In-Reply-To: To: Zach Shelby MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Wed, 29 Jun 2011 13:02:38 +0200 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 29/06/2011 13:02:49, Serialize complete at 29/06/2011 13:02:49, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 29/06/2011 12:40:02, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 29/06/2011 12:40:06, Serialize complete at 29/06/2011 12:40:06 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, core WG Subject: [core] RE Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 11:03:00 -0000 Hi Zach, Your new draft and the current discussions are very interesting. I also have few questions about the draft 1) Registration procedure Why indexing the endpoints with the name and not the node id? All end points have some kind of unique identifier (EUI64,...) but not all nodes have a configured name. Also when the node changes its name we may have duplicate entries in the directory if regitration/removal is not handled properly. 2) Update procedure It seems an end point doesn't need to include again and again the link-format resource list when it refreshes its directory entry. But the exact behavior is not clear. What the rd is supposed to do when the payload is empty and the etag in the PUT request doesn't match the etag in the directory? In my opinion a noticable error code should inform the end point that it needs to perform a full refresh with a payload. 3) Lookup a)There is no way to enumerate the end points in the directory. We could make a difference between the resources /{rd-base} and /{rd-base}? /{rd-base}? would be the lookup interface and /{rd-base} a resource containing the list of /{rd-base}/ {endpoint name} links. Example GET /rd , , GET /rd? ;rt="Temperature", ;rt="Temperature" b)The result of a lookup becomes rapidly quite large because of the full target URI. c) Is there a risk of cache/etag mishandling because of the translated target URI? The problem is that the payload of a GET /rd/node1 is not the same as the payload of the corresponding PUT request. PUT /rd/node1 ;rt="Temperature" GET /rd/node1 ;rt="Temperature" Matthieu From jari.arkko@piuha.net Wed Jun 29 16:47:05 2011 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 72CB011E808E for ; Wed, 29 Jun 2011 16:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXVtSTTBhq2s for ; Wed, 29 Jun 2011 16:47:05 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id CE56711E8076 for ; Wed, 29 Jun 2011 16:47:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CA8302CC3B for ; Thu, 30 Jun 2011 02:46:59 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwlK6Ab85TlW for ; Thu, 30 Jun 2011 02:46:43 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A313D2CC39 for ; Thu, 30 Jun 2011 02:46:43 +0300 (EEST) Message-ID: <4E0BB964.3020806@piuha.net> Date: Thu, 30 Jun 2011 01:46:44 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] Message ID sliding window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 23:47:05 -0000 I actually like the freedom to use any approach to assigning message IDs. I can imagine a few reasons why it might be easier in some cases to have that freedom. As a hypothetical example, maybe I want to store only one counter but send messages to multiple other nodes. Also, as Carsten pointed out, sequential assignment is not as trivial as it sounds. What do you or the receivers do after a reboot? That being said, if you want your sender to use sequential message IDs, it can just go ahead and do it. On the receiver side the issue is more complex. COAP has acknowledgments to deal with those cases where you absolutely have to sequence some operations, and relying merely on sequence numbers would appear to not work in all cases, e.g., when a message is lost. Given the reboot problem, a simple sliding window approach might not be sufficient to keep track of which messages you have received. As a side note, I scanned the COAP draft today and did not find anything about the scope of message IDs. Presumably message ID duplicate detection etc should only apply for a given IP source and destination pair. Otherwise there will be too many collisions. Is this specified somewhere? Jari